| Oracle® Fusion Middleware Oracle SOA Suiteの理解 12c (12.2.1.2.0) E82769-01 |
|
 前へ |
 次へ |
この章の内容は次のとおりです。
会社Xには、処理する注文をリスニングし、出荷プロバイダ(たとえば、米国郵政公社(USPSまたはUPS))を選択して、梱包および出荷サービスを起動するシステムを作成する要件があります。このシナリオで起動する梱包および出荷サービスは、「注文の梱包と出荷」で設計したPackAndShipServiceコンポジットです。
このビジネス課題に対処するために、会社Xは表7-1のコンポーネントを使用するビジネス・ソリューションを設計します。
表7-1 ビジネス・ソリューションを提供するコンポーネント
| コンポーネント | このコンポーネントがビジネス課題に対処する方法 | コンポーネントの説明 |
|---|---|---|
プロジェクト・テンプレートを含むSOAコンポジット・アプリケーション |
プロジェクト・テンプレートから作成された注文履行コンポジットは、処理する注文をリスニングし、出荷プロバイダを選択して、「注文の梱包と出荷」で作成した梱包および出荷サービス(PackAndShipService)を起動します。注文履行コンポジットは、注文がデータベース内でReadyForShipとして更新されるとトリガーされます。その後、注文メッセージの出荷速度を確認し、出荷速度および出荷先(州)に基づいた出荷方法を決定して、データベースまたはCoherenceキャッシュから優先出荷プロバイダを読み取り、梱包および出荷RESTサービスをコールします。 |
テンプレートの詳細は、表3-1を参照してください。 |
ビジネス・ルール |
ビジネス・ルール(デシジョン表)は、速度および出荷先(州)に基づいて出荷方法を決定します。出荷方法に基づいて、優先出荷プロバイダがデータベースから取得されます。 |
ビジネス・ルールを使用すると、実行時の動的な意思決定が可能になり、基礎となるアプリケーション・コードからルール・ロジックを分離しながら、ポリシー、計算および判断を自動化できます。これにより、より機動的なルール・メンテナンスが可能になり、ビジネス・アナリストは、プログラマの支援を受けずに、ルール・ロジックを変更できるようになります。その際に、ビジネス・プロセスが中断されることはありません。 |
コンポジット・センサー |
コンポジット・センサーは注文番号を追跡します。 |
コンポジット・センサーの詳細は、表3-1を参照してください。 |
REST参照 |
アウトバンドREST参照は、注文を梱包および出荷サービスに配信します。 |
RESTバインディングの詳細は、表6-1を参照してください。 |
コヒーレンス・アダプタ |
コヒーレンス・アダプタは、最初はデータベースから、後続の読取り操作はCoherenceキャッシュから適切な出荷プロバイダを読み取ります。 追加のコヒーレンス・アダプタは、データベース・アダプタのレスポンスをCoherenceキャッシュにコピーして、次回の参照時にキャッシュで出荷プロバイダを利用できるようにします。 |
Coherenceキャッシュは、データベースとクライアント・アプリケーション間の仲介として機能するデータ・オブジェクトのコレクションです。データベース・データをキャッシュにロードして、異なるアプリケーションで使用できます。Coherenceキャッシュによってデータベースの負荷が軽減され、データベース・データへのより高速なアクセスが可能になります。 |
この章の後続の項では、表7-1のコンポーネントを使用して、注文履行のビジネス課題に対処する方法について、より詳細に説明します。
会社Xでは、処理する注文のリスニング、出荷プロバイダの選択、梱包および出荷サービスの起動を処理するSOAコンポジット・アプリケーションを設計するためのビジネス要件が頻繁に発生します。この課題に対処するため、これらの機能(必要に応じて、Oracle JDeveloperで複数のアプリケーションにインポート可能)を持つFulfillOrderTemplateというプロジェクト・テンプレートを作成しています。テンプレートは、特定のプロジェクトのビジネス要件に合せてカスタマイズできます。その特定のインポート済テンプレートに対して行った変更は、以前にそのテンプレートを使用して作成したプロジェクトには伝播されません。
以前のテンプレートと同様に、FulfillOrderTemplateプロジェクト・テンプレートは、「ツール」→「プリファレンス」→「SOA」→「テンプレート」を選択して、テンプレート記憶域の場所を指定することにより、最初にOracle JDeveloperで登録されます。
会社Xは、新規SOAプロジェクトを作成する「SOAプロジェクトの作成」ウィザードを起動し、テンプレートに基づいてプロジェクトを作成することを選択します。「SOAプロジェクトの作成」ウィザードの「SOAテンプレート」を選択すると(ダイアログが更新されて選択可能な既存のテンプレートが表示される)、このプロジェクト・テンプレートが新規アプリケーションにインポートされます。「FulfillOrderTemplate」が選択され、プロジェクト名は「FulfillOrder」に短縮されます(図7-1を参照)。
作成の完了後、コンポジットは図7-2のようになります(プロジェクト・テンプレートがインポートされている)。
インポートされたプロジェクト・テンプレートは、次のコンポーネントで構成されます。
最初のデータベース・アダプタ(ReceiveOrdersReadyForShipment)。「ReadyForShip」ステータスの注文をリスニングし、データベースからレコードを読み取り、注文ごとに新規BPELプロセスをトリガーします。注文を再度読み取れないようにするには、このステータスを「ReadyForPack」に変更します。
2番目のデータベース・アダプタ(getShippingProvider)。主キーとして出荷方法IDを使用して、データベースから出荷プロバイダを読み取ります。出荷方法ごとの優先出荷プロバイダのリストはデータベースで保持されます。たとえば、USPSは、USAFirstClassの出荷(出荷方法ID =1)に使用され、UPSは、USAPriorityの出荷(出荷方法ID =2)に使用されます。
オープンのreceiveOrderToShip BPELプロセス。図7-3で表示されています。このプロセスは、ReceiveOrdersReadyForShipmentデータベース・アダプタ・サービスによって起動されます。XSLTマップは、メッセージを正規の注文メッセージに変換します。fulfillOrder BPELプロセスが起動されます(正規の注文メッセージが入力として渡される)。
履行BPELプロセス(図7-4を参照)。受信注文メッセージには、顧客によって選択された出荷速度が含まれます:
翌日出荷
2営業日出荷
標準の出荷: 3-5営業日
出荷速度は問わない
ビジネス・ルールでは、出荷速度および出荷先住所に基づいて出荷方法が決定されます。出荷方法IDは、出荷プロバイダを取得する際のデータベース・コールへの入力として使用されます。
ビジネス・ルールを使用すると、実行時に動的な意思決定を行うことができます。これにより、基礎となるアプリケーション・コードからルール・ロジックを分離しながら、ポリシー、計算および判断を自動化できます。
会社Xは、出荷方法IDを決定するためのビジネス・ルールを追加します。ビジネス・ルールは、出荷先(州)およびリクエストされた出荷速度を入力としてとり、出荷方法IDを返します。たとえば、USPSは、USAFirstClassの出荷(出荷方法ID =1)に使用され、UPSは、USAPriorityの出荷(出荷方法ID =2)に使用されます。
会社Xは、「コンポーネント」ウィンドウの「コンポーネント」セクションからSOAコンポジット・アプリケーションに「ビジネス・ルール」アイコンをドラッグします。構成の完了後、「ビジネス・ルールの作成」ダイアログは図7-5のようになります。
図7-5に示す入力ファクトと出力ファクトの両方が、スキーマ・ファイルの出荷要素タイプで定義されます(図7-6を参照)。ファクトは、ルールの推論対象のオブジェクトです。各ファクトはファクト・タイプのインスタンスです。
ビジネス・ルールの作成後、コンポジットのビジネス・ルール・サービス・コンポーネントを、ルール・エディタにアクセスするためにクリックします。ルール・エディタ内で、デシジョン表が定義されます(図7-7を参照)。デシジョン表は、数多くのルールで多数のプロパティ値の組合せを分析する必要がある場合に、よりコンパクトかつ直観的に使用できる代替のビジネス・ルール・フォーマットです。デシジョン表を使用すると、すべての組合せを網羅する、または競合する組合せが存在しないルールのセットを作成できます。
次のルール条件が配送速度に対して定義されます。ルール条件は、文のIF部分を表します。ルール条件はRules Engine内の使用可能なファクトに対する問合せのようなもので、問合せから返されるそれぞれの行に対してルールを有効にします。ルール条件は、ファクトの組合せで条件式がtrueになるたびにルールをアクティブにします。
翌日出荷
2営業日出荷
標準の出荷: 3-5営業日
どれでもよい(出荷速度は問わない)。この配送方法の場合、TX (テキサス州)の条件が設定されます。他のルール条件では州が設定されていないため、配送速度が唯一の要件になります。
次の出荷方法IDルール・アクションが、ルール条件ごとに定義されます。ルール・アクションは、文のTHEN部分を表します。THEN部分には、ルールの起動時に実行されるアクションが含まれます。ルールはアクティブ化され、優先度など競合解決メカニズムを使用して他のルールのアクティブ化の中から選択された後、起動されます。
1 - USPS: USAFirstClassの出荷用
2 - UPS: USAPriorityの出荷用
3 - USAフリー・メール
4 - UPS翌日配送の航空便
ビジネス・ルールを統合するには、「コンポーネント」ウィンドウの「SOAコンポーネント」セクションから履行プロセスに「ビジネス・ルール」アイコンをドラッグします(図7-8を参照)。
会社Xは、このアクティビティによって起動されるディクショナリを選択します。入力ファクトと出力ファクトも定義されます。入力コピー・ルールの場合、ShippingTypeが、inputVariableプロセスからビジネス・ルールのdsIn (入力ファクト)変数にコピーされます。図7-9に詳細を示します。
出力コピー・ルールの場合、ShippingMethodが、ビジネス・ルールのdsOut (出力ファクト)変数からshippingMethodIDプロセス変数にコピーされます。図7-10に詳細を示します。
設計の完了後、fulFillmentプロセスは図7-11のようになります。
前の各章で実行したように、会社Xは、メッセージのフィールドを追跡するためにコンポジット・センサーを追加します。このシナリオでは、注文番号のステータスが追跡されます。センサーが、ReceiveOrderReadyForShipmentデータベース・アダプタ・サービス上に設定されます。図7-12に詳細を示します。
図7-13の「コンポジット・センサー」ダイアログに示すように、この定義には、注文番号を追跡するためのXPath式が含まれます。
「コンポジット・センサーの作成」ダイアログの「Enterprise Manager」チェック・ボックスも選択されます。これにより、Oracle Enterprise Manager Fusion Middleware Controlの特定のビジネス・フロー・インスタンスで、「フロー・インスタンス」ページまたは「フローのトレース」ページのコンポジット・センサーの名前と値を追跡できるようになります。図7-14に詳細を示します。
RESTサービスは、「梱包BPELプロセスを使用したRESTサービスの公開」ではWebサービスの代替として使用されています。RESTはHTTPリクエストを使用して、データのポスト(作成と更新)、データの取得(問合せの作成など)、データの更新およびデータの削除を実行します。
このビジネス・シナリオの場合、会社XはREST参照を使用して、「注文の梱包と出荷」で作成したPackAndShipサービスをコールします。会社XはRESTバインディングをコンポジットの「外部参照」スイムレーンにドラッグして、次の詳細を定義します。
RESTアウトバウンド・インタフェース。
出荷RESTリソース。
POST HTTP動詞を使用し、WADLファイルに基づいたpackandShip操作バインディング。WADLでは、HTTPベースWebアプリケーション(一般的にはREST Webサービス)の判読可能なXML説明が用意されています。WADLにより、Webの既存HTTPアーキテクチャに基づいて、Webサービスの再利用が単純になります。WADLファイルを選択すると、すべての操作バインディングの詳細が「RESTバインディングの作成」ダイアログに自動的に移入されます。図7-15に詳細を示します。
構成が完了すると、会社Xは、fulfillOrder BPELプロセスをREST参照に接続します(図7-16を参照)。
構成を完了するために、会社Xは、fulfillOrderプロセスに必要なアクティビティを追加します:
invokeアクティビティはPackAndShipOrderパートナ・リンクを起動し、必要な入力変数と出力変数を定義します。
assignアクティビティは入力変数の出荷要素を、REST参照の入力変数の出荷要素にマップします。
BPELプロセスは一方向であるため、RESTサービスの戻り値を割り当てる必要はありません。
図7-17に詳細を示します。
このコンポジットで使用されるデータベース・アダプタは、データベースに定期的にアクセスします。データベースの負荷を軽減し、データベース・データへのアクセスをより高速にするために、会社Xは、コヒーレンス・アダプタをコンポジットに統合します。コヒーレンス・アダプタは、データベース・データの初回読取り時に、そのデータをキャッシュに配置します。
Coherenceキャッシュは、データベースとクライアント・アプリケーションの間の仲介として機能するデータ・オブジェクトの集合です。データベース・データをキャッシュにロードして、異なるアプリケーションで使用できます。コヒーレンス・アダプタにより、Coherenceキャッシュへのアイテムの追加、アイテムの取得、アイテムの削除、アイテムの問合せなど、有用なコヒーレンス操作を実行できます。
会社Xは、「コンポーネント」ウィンドウの「テクノロジ」セクションからコンポジットの「外部参照」スイムレーンに「コヒーレンス」アイコンをドラッグします。アダプタ構成ウィザードを使用すると、次のコヒーレンス・アダプタの詳細を構成できます。
コヒーレンス接続のJNDI名。
実行する操作。この場合、get操作がCoherenceキャッシュからデータを取得するために選択されます。
キャッシュ・タイプ(XML)。
キャッシュ名。
キー・タイプ(文字列) (invokeアクティビティのjca.coherence.Keyプロパティで後で移入)。
データベース参照レスポンス・スキーマ・ファイル(データベース参照からのレスポンスを直接Coherenceキャッシュに格納)。
アダプタの構成が完了すると、fulfillOrder BPELプロセスがコヒーレンス・アダプタに接続されます(図7-18を参照)。
構成を完了するために、会社Xは、fulfillOrderプロセスに必要なアクティビティを追加して構成します:
invokeアクティビティは次のように構成されます。
QueryCoherenceパートナ・リンクを起動します。
入力変数および出力変数を定義します。
jca.coherence.KeyプロパティをshippingMethodIDの値(「プロパティ」タブの下)に割り当てます。この値は、アダプタの起動時に入力変数として送信され、入力値をコヒーレンス問合せ呼出しに割り当てるassignアクティビティ文の作成を不要にします。
ifアクティビティは次のように構成されます。
if部分が、コヒーレンス問合せの出力変数からプロセス入力変数(出荷要素内)の出荷プロバイダ名に、出荷プロバイダ名を割り当てます。これは、「注文の梱包と出荷」で設計したPackAndShipServiceで、後で使用されます。
else部分には、getShippingProviderデータベース・アダプタの起動と、その2つのassignアクティビティが含まれます。
完了後、構成は図7-19のようになります。
会社Xは、別のコヒーレンス・アダプタをコンポジットの「外部参照」スイムレーンに追加します。このアダプタは、データベース・アダプタ・レスポンスをCoherenceキャッシュにコピーして、次回参照時にキャッシュで出荷プロバイダを利用できるようにします。
コヒーレンス・アダプタは次のように構成されます。
コヒーレンス接続のJNDI名。
実行する操作。この場合、アイテムをキャッシュに配置するためにput操作が選択されます。
キャッシュ・タイプ(XML)。
キャッシュ名。
キー・タイプ(文字列)。
shippingMethodKeyのキー値。
データベース参照レスポンスのスキーマ・ファイル。
構成を完了するために、会社Xは、履行プロセスを新規コヒーレンス・アダプタに接続します(図7-20を参照)。
構成を完了するために、会社Xは、fulfillOrderプロセスに必要なアクティビティを追加します:
invokeアクティビティは次のように構成されます。
putIntoCoherenceパートナ・リンクを起動します。
入力変数および出力変数を定義します。
jca.coherence.KeyプロパティをshippingMethodIDの値(「プロパティ」タブの下)に割り当てます。この値は、アダプタの起動時に入力変数として送信され、入力値をコヒーレンス問合せ呼出しに割り当てるassignアクティビティ文の作成を不要にします。
assignアクティビティは、コヒーレンス・アダプタの入力変数にデータベース・コールの出力変数を移入します。
構成の完了後、履行プロセスは図7-21のようになります。
図7-22に、SOAコンポジット・エディタでのこの完了したビジネス・ソリューションの表示を示します。
表7-2では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。
表7-2 関連ドキュメント
| 参照内容 | 参照先 |
|---|---|
プロジェクト・テンプレートの追加 |
『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle SOA Suiteテンプレートおよび再使用可能なサブプロセスに関する項 |
ビジネス・ルールの設計 |
『Oracle Business Process Managementによるビジネス・ルールの設計』のOracle Business Rulesの概要に関する項 『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle Business Rulesのスタート・ガイドに関する項 『Oracle Business Process Managementによるビジネス・ルールの設計』のデシジョン表の使用に関する項 |
コンポジット・センサーの作成 |
『Oracle SOA SuiteでのSOAアプリケーションの開発』のコンポジット・センサーの定義に関する項 |
REST参照の追加 |
『Oracle SOA SuiteでのSOAアプリケーションの開発』のSOAコンポジット・アプリケーションにおけるREST操作の統合に関する項 |
コヒーレンス・アダプタの構成 |
『テクノロジ・アダプタの理解』のOracle JCA Adapter for Coherenceに関する項 |
