4 注文処理システムの作成
この章の内容は次のとおりです。
4.1 ビジネス課題
会社Xは、次のビジネス課題に対処する注文処理システムを設計する必要があります。
-
モバイル機器を含む、多様なクライアントは、様々なプロトコルを介して、様々なデータ・フォーマットでシステムにアクセスします。
-
新規の注文処理システムは、(開発中のモバイル・アプリケーションへの移行を準備するために)RESTインタフェースからのアクセスをサポートする必要があります。
-
既存のシステムは、XMLおよびカンマ区切り値(CSV)ファイルを使用して発注できる必要があります。これらの注文は、同じ新規の注文プロビジョニング・システムを使用して処理および履行される必要があります。
-
システムは、取引パートナとやりとりしたり、電子データ交換(EDI)サポートを提供する必要があります。
4.2 ビジネス・ソリューション
これらのビジネス課題に対処するために、会社Xは、表4-1のコンポーネントを使用するビジネス・ソリューションを設計します。
表4-1 ビジネス・ソリューションを提供するコンポーネント
| コンポーネント | このコンポーネントがビジネス課題に対処する方法 | コンポーネントの説明 |
|---|---|---|
|
SOAコンポジット・アプリケーション |
SOAコンポジット・アプリケーションは、新しい発注書を受け入れ、それらを認可するか拒否して、認可済注文を注文履行システムに転送するように設計されています。コンポジットは、次のコンポーネントから構成されます。それぞれについて、簡潔に後述します。
|
SOAコンポジット・アプリケーションの詳細は、表3-1を参照してください。 |
|
SOAプロジェクト・テンプレート |
SOAプロジェクト・テンプレートがインポートされます。テンプレートを使用して、SOAコンポジット・アプリケーションを作成します。コンポジットの事前定義済コンポーネントが、基本のシナリオを実装します:
次の操作が発生します。
|
SOAプロジェクト・テンプレートの詳細は、表3-1を参照してください。 |
|
インラインBPELサブプロセス |
インラインBPELプロセスは、(callアクティビティを使用して)「クレジット検証システムの作成」の支払検証システムを起動し、支払検証の結果に基づいてデータベース内の注文ステータスを更新します。 |
サブプロセスは、別のプロセスがコンポジット内で再使用できるBPELコードのフラグメントです。このサブプロセス拡張機能には、次の利点があります。
|
|
コンポジット・センサー |
コンポジット・センサーは注文番号を追跡します。 |
SOAコンポジット・センサーの詳細は、表3-1を参照してください。 |
|
Oracle Service Busプロキシ・サービス、パイプラインおよびビジネス・サービス |
Oracle Service Busは、多数のプロトコルやデータ・フォーマットで注文処理コンポジットが利用できるようにし、注文を検証します。 |
Oracle Service Busの詳細は、表3-1を参照してください。 |
図4-1に、このビジネス・ソリューションの実装方法の概要を示します。
この章の後続の項では、表4-1のコンポーネントを使用して、注文処理のビジネス課題に対処する方法について、より詳細に説明します。
4.2.1 SOAプロジェクト・テンプレートからのSOAコンポジット・アプリケーションの作成
「XSLT変換を使用した支払ステータスの計算」で説明しているように、テンプレートによって、既存のコンポジット、サービス・コンポーネントおよびカスタム・アクティビティを再利用できます。会社Xでは、新規の注文書の受入れと承認、および注文履行システムへの転送を処理するSOAコンポジット・アプリケーションを設計するためのビジネス要件が頻繁に発生します。このため、これらの機能(必要に応じて、Oracle JDeveloperで複数のアプリケーションにインポート可能)を持つProcessOrderTemplateというプロジェクト・テンプレートを作成しています。テンプレートは、特定のプロジェクトのビジネス要件に合せてカスタマイズできます。その特定のインポート済テンプレートに対して行った変更は、以前にそのテンプレートを使用して作成したプロジェクトには伝播されません。
ProcessOrderTemplateプロジェクト・テンプレートは、「ツール」→「プリファレンス」→「SOA」→「テンプレート」を選択して、テンプレート記憶域の場所を指定することにより、Oracle JDeveloperで登録されます。テンプレートはJARファイルとして提供されます。これにより、テンプレートが、Oracle JDeveloperでの選択用に表示されます。
プロジェクト・テンプレートは多数の事前定義済コンポーネントで構成されており、次の機能があります。
-
SOAP Webサービスから注文を受信します。
-
注文番号を作成し、注文日を現在の日付に設定して、注文ステータスを「新規」の値に設定します。
-
注文合計額を計算します。
-
データベース内の注文を「新規」のステータス値で保存します。
-
クライアントに注目確認と注文番号を返します。
会社Xは、新しいSOAプロジェクトを作成する、「SOAプロジェクトの作成」ウィザードを起動します。ウィザードの実行中に、テンプレートに基づいたプロジェクトを作成することを選択します。「SOAプロジェクトの作成」ウィザードの「SOAテンプレート」を選択すると(ダイアログが更新されて選択可能な既存のテンプレートが表示される)、このプロジェクト・テンプレートが新規アプリケーションにインポートされます。「ProcessOrderTemplate」が選択され、プロジェクト名は「ProcessOrder」に短縮されます。図4-2に詳細を示します。
インポート後、プロジェクトとその事前定義済コンポーネントは図4-3のようになります。
-
receiveOrder_clientサービスは、顧客から注文を受信します。
-
receiveOrder BPELプロセス・サービス・コンポーネントは、注文番号(クライアントに返される)および注文日を設定し、validateAndProcessOrder BPELプロセス・サービス・コンポーネントをコールします。
-
validateAndProcessOrder BPELプロセス・サービス・コンポーネントは、注文を変数に割り当て、支払の検証に使用される注文合計額を計算します。また、注文の検証と処理の一環として、3つのパートナ・リンクを起動します。
-
writeOrderToFileファイル・アダプタ参照は、ファイル・アダプタを使用して、ファイルに注文を書き込みます。
-
writeOrderToDatabase参照は、データベース・アダプタを使用して、データベースに注文を書き込みます。
-
updateOrderStatus参照は、返された値に応じて、データベース内の注文ステータスを拒否または認可に更新します。
-
4.2.2 SOAプロジェクト・テンプレートのコンテンツのカスタマイズ
テンプレートのvalidateAndProcessOrder BPELプロセスは、注文を変数に割り当て、支払の検証に使用される注文合計額を計算します。図4-4に示すプロセスのアクティビティは、次のタスクを実行します。
-
XSLT変換アクティビティは、注文合計額を計算します。
-
assignアクティビティが、注文合計額を注文メッセージに追加します。
-
scopeアクティビティ(閉じた状態にある)には、データベースやファイル内の注文ステータスの更新に関与するすべてのアクティビティが含まれています。
図4-4 validateAndProcessOrder BPELプロセスの主要なアクティビティ
「図4-4 validateAndProcessOrder BPELプロセスの主要なアクティビティ」の説明-
支払が拒否された場合、注文がキャンセルされ、データベースの注文ステータスが更新されます。
-
支払が認可された場合、データベースとファイルの注文ステータスが更新され、注文が処理されます。処理が完了すると、ステータスが「ReadyForShip」に更新されます。
-
注文処理は、最初の検証を終えた支払に対してのみ実行されます。ProcessOrderコンポジットには、この機能は含まれません。ただし、会社Xは、「クレジット検証システムの作成」でvalidatePaymentコンポジットを作成しています。会社Xは、インポートしたコンポジット・テンプレートをカスタマイズし、validatePaymentコンポジットを起動して支払を検証します。支払が認可されると、ProcessOrderコンポジットが注文を処理します。インポート済テンプレートに対するこのカスタマイズは、このテンプレートの他のプロジェクトのユーザーには伝播されません。
会社Xは、SOAP Webサービスを「外部参照」スイムレーンにドラッグし、「Webサービスの作成」ダイアログを起動して、ProcessOrderコンポジットをカスタマイズします。このダイアログから、Oracle SOA Suiteを使用して、Oracle JDeveloperの統合サーバーまたはリモート・アプリケーション・サーバー上のOracle SOA SuiteまたはOracle Service Busプロジェクトにデプロイされているサービスを参照できます。次のものを参照できます。
-
WSDL URLの選択。
-
ファイル・システム、Oracle Metadata Servicesリポジトリ(MDSリポジトリ)、UDDIレジストリまたはWeb Services Inspection Language (WSIL)ファイルからのWSDLの読取り。
validatePaymentのOracle Service Busプロキシ・サービスは、「WSDL URL」フィールドの右側にあるアイコンをクリックして選択されます。このアイコンを選択すると、サービスを参照できます。「Oracle Service BusでのSOAコンポジット・アプリケーションの登録」で作成したValidatePSプロキシ・サービスが選択されます(図4-5を参照)。
新規Webサービス(validatePaymentService)は、「Oracle Service BusでのSOAコンポジット・アプリケーションの登録」で定義したvalidatePaymentプロキシ・サービスを起動します。ポート・タイプは自動的に追加されます。図4-6に詳細を示します。
validateAndProcessOrder BPELプロセスは、SOAコンポジット・エディタの新しいvalidatePaymentService SOAP Webサービスにワイヤリングされます(図4-7を参照)。
会社Xは、次のものを追加して、validateAndProcessOrder BPELプロセスをさらにカスタマイズします。
-
validatePaymentServiceパートナ・リンクを起動するinvokeアクティビティ(validatePayment)
-
validatePayment invokeアクティビティの前のassignアクティビティ(Webサービス・コールの入力変数に正しい値を割り当てる)
-
invokeアクティビティの後のassignアクティビティ(Webサービス・コールから注文メッセージへの支払ステータスのリプライを割り当てる)図4-8に詳細を示します。
図4-8 コンポジット・テンプレートのvalidateAndProcessOrder BPELプロセスへのカスタマイズ
「図4-8 コンポジット・テンプレートのvalidateAndProcessOrder BPELプロセスへのカスタマイズ」の説明
図4-9に、完了したコンポジットを示します。
4.2.3 インラインBPELサブプロセスでの注文ステータスの更新
会社Xには、同じBPELプロセスで少なくとももう一度、validateAndProcessOrder BPELプロセスの注文ステータス更新部分を使用する要件があります。1つの方法は、すでに使用しているのと同じassignアクティビティとinvokeアクティビティを作成することです。ただし、これは間違いやすいプロセスで、変更が必要なたびに、すべての場所でそれを反映する必要があります。これを回避するために、会社Xでは、BPELサブプロセスを使用します。このロールには2つのタイプがあります。
-
スタンドアロン: 再使用されるアクティビティが多数含まれるBPELプロセスのフラグメント。スタンドアロン・サブプロセスにはインタフェースがなく、別のBPELプロセスからのみコールされます。スタンドアロン・プロセスは、他の複数のBPELプロセスへのパートナ・リンクを持つことができます。
-
インライン: 単一BPELプロセス内で再使用されるアクティビティ・グループ用。インライン・プロセスは親BPELプロセス・コードの一部であるため、コンポジット・ビューには表示されません。インライン・サブプロセスでは、callアクティビティを使用します。
インライン・サブプロセスは、会社Xのビジネス要件に適しています。
validateAndProcessOrder BPELプロセス内で、updateOrderStatusScopeという注文ステータスの更新を担当するscopeアクティビティを右クリックし、「サブプロセスに変換」を選択します。これにより、「インライン・サブプロセスの作成」ダイアログが起動します。会社Xは、サブプロセスの名前を変更し、scopeアクティビティをサブプロセスのcallアクティビティに自動的に置き換えることを選択します。図4-10に詳細を示します。
これにより、scopeアクティビティがcallアクティビティに変換されます。callアクティビティは、スタンドアロン・サブプロセスおよびインライン・サブプロセスで参照サブプロセス・コードを実行します。また、callアクティビティは、「コンポーネント」ウィンドウの「サブプロセス」部分に追加されます。このcallアクティビティは、必要に応じてBPELプロセスの他の場所にドラッグ・アンド・ドロップできます。図4-11に詳細を示します。
4.2.4 コンポジット・センサーを使用した注文番号の追跡
「コンポジット・センサーを使用した支払ステータスの追跡」で、会社Xは、注文支払のステータスを追跡するためのコンポジット・センサーを追加しました。
ここでは、コンポジット・センサーで注文番号を追跡するという追加要件があります。インポート済コンポジット・テンプレートに含まれているSOAP Webサービスreceiveorder_client (図4-3を参照)は、注文確認メッセージでorderNumberを返します。会社Xは、図4-12の「コンポジット・センサーの作成」ダイアログに示されているように、注文番号を追跡するために、このサービス(XPath式を含む)でコンポジット・センサーを定義します。
「コンポジット・センサーの作成」ダイアログの「Enterprise Manager」チェック・ボックスも選択されます(図4-13を参照)。これにより、Oracle Enterprise Manager Fusion Middleware Controlの特定のビジネス・フロー・インスタンスで、「フロー・インスタンス」ページまたは「フローのトレース」ページのコンポジット・センサーの名前と値(たとえば、OrderNumber=1234)を追跡できるようになります。Oracle Enterprise Manager Fusion Middleware ControlはWebブラウザ・ベースのグラフィカル・ユーザー・インタフェースで、デプロイ済コンポジットをモニターおよび管理するために使用します。
コンポジット・センサーの定義は、receiveorder_client SOAP Webサービス・バインディング・コンポーネント上のアイコンにカーソルを置くことにより表示されます。図4-14に詳細を示します。
4.2.5 支払認可後の注文ステータスの更新
支払が有効な場合は、注文ステータスがデータベースで「ReadyForShip」に設定されます。このステータスの更新は、「注文の履行」で説明する注文履行プロセスをトリガーします。
会社Xは、ifアクティビティを追加して、validateAndProcessOrder BPELプロセスをさらにカスタマイズします。ifアクティビティは、2つ以上のブランチのどちらを実行するかを決定するための特定のアクティビティ条件動作を定義します。ブランチのセットから、実行するアクティビティが1つだけ選択されます。このビジネス・シナリオのifアクティビティは、次のブランチで構成されます。
-
支払が認可された場合、注文が続行されます。ifブランチのassignアクティビティは、注文ステータスをデータベース内で「ReadyForShip」に更新します。
-
支払が拒否された場合、処理が終了し、未認可の支払に関して通知する電子メールが顧客に送信されます。
図4-15に詳細を示します。ifアクティビティが、「インラインBPELサブプロセスでの注文ステータスの更新」で作成したupdateOrderStatusSP callアクティビティの下に追加されます。
支払が認可された場合、式がifブランチで定義されます(図4-16を参照)。
支払が認可されると、注文処理が完了します。assignアクティビティがifブランチに追加され、注文ステータスがデータベース内で「ReadyForShip」に更新されます。図4-17に、assignアクティビティのコピー・ルールのコンテンツを示します。
図4-18に、assignアクティビティのコピー・ルールにおけるXPath式のコンテンツを示します。
支払が拒否された場合は注文処理が停止するため、elseブランチは不要で削除されます。
4.2.6 Oracle Enterprise Manager Fusion Middleware Controlでのデプロイとテスト
4.2.7 Oracle Service BusでのProcessOrderコンポジットの登録
「クレジット検証システムの作成」のvalidatePaymentコンポジットと同様に、会社Xは、Oracle Service Busを使用して、ProcessOrderコンポジットを登録し、外部顧客が利用できるようにします。
Oracle Service Busは、ProcessOrderコンポジットのコア・ビジネス・ロジックを中断させることなく、異なるプロトコルやデータ・フォーマットでこのコンポジットを使用できるようにします。また、Oracle Service Busは、注文データの検証と監査も実行します。
会社Xは、追加のプロジェクトを含めるように、「Oracle Service BusでのSOAコンポジット・アプリケーションの登録」で作成したOracle Service Busアプリケーションを更新します。これらのプロジェクトでは、パイプライン・テンプレートを使用します。
パイプライン・テンプレートは、プロキシ・サービスのプロトタイプ・メッセージ・フローの設計に使用されます。パイプライン・テンプレートによって、メッセージ・フローの一般的な形状またはパターンが定義されます。その後、パイプライン・テンプレートから具象パイプラインを生成できます。すべての具象パイプラインは、カスタム・ロジックを挿入可能な場所が指定されているパイプライン・テンプレートによって定義されるメッセージ・フローを使用します。
会社Xは、Oracle Service Busアプリケーションを右クリックし、「インポート」→「Service Busリソース」を選択して、テンプレートをインポートします。図4-21に詳細を示します。
これにより、使用するパイプライン・テンプレートを選択するための「Service Busリソースのインポート」ダイアログが起動します。完了後、インポート済テンプレートは「アプリケーション」ウィンドウに表示されます(図4-22を参照)。
図4-22 「アプリケーション」ウィンドウのインポート済Oracle Service Busパイプライン・テンプレート
「図4-22 「アプリケーション」ウィンドウのインポート済Oracle Service Busパイプライン・テンプレート」の説明
4.2.7.1 ビジネス・サービスとしてのProcessOrderコンポジットの登録
会社Xは、「外部参照」列を右クリックし、「トランスポートの挿入」→「HTTP」を選択して、コンポジットをビジネス・サービスとして登録します(図4-23を参照)。
このアクションにより、「ビジネス・サービスの作成」ウィザードが起動します。ここで、次のものを設定します。
-
トランスポート・タイプとしてのHTTP。
-
サービス・タイプとしてのProcessOrderの具象的なWSDL。
-
WSDLファイル
-
エンドポイントURIとしてのコンポジット。Oracle Service Busでは、アプリケーションのロード・バランシングやフェイルオーバーをサポートするために、ビジネス・サービスで複数のエンドポイントを持つこともできます。
4.2.7.2 パイプライン・テンプレートを使用したプロキシでの新規パイプラインの作成
会社Xは、「コンポーネント」ウィンドウからOracle JDeveloperの「コンポーネント」セクションに「パイプライン」アイコンをドラッグして、パイプライン・テンプレート(SharedSB)を作成します(図4-24を参照)。
これにより、使用するインポート済パイプライン・テンプレートを選択するための「パイプライン・サービスの作成」ダイアログが起動します。構成中に、WSDLベース・サービス用のテンプレート、パイプラインに使用する特定のWSDL(図4-25を参照)を選択し、そのパイプラインをプロキシ・サービスとして公開します。
構成の完了後、「パイプライン・サービスの作成」ダイアログは図4-26のようになります。
パイプラインがアプリケーションに表示されます(図4-27を参照)。パイプラインの黄色のアイコンは、完全に実装される前に、追加の構成が必要であることを示しています。
「ProcessPP」をダブルクリックすると、ProcessPPが編集用に表示されます。ここには、いくつかの機能(たとえば、データ検証、ルーティング、レポーティング、エラー状態のアラート、エラー処理)が部分的に構成された状態で含まれています。赤色のフラグは、追加の構成が必要な領域を示しています。「リクエストのステージ」メッセージは、パイプラインにおいてプレースホルダ情報が提供されている領域を示しています。ここで、会社Xは(変換やメッセージ・エンリッチメントなどの)カスタマイズを行えます。図4-28に詳細を示します。
テンプレートでは、パイプラインのエラー・ハンドラを定義することもできます(図4-29を参照)。事前定義されたエラー・ハンドラは、エラーとその詳細情報をコール元に返し、この処理でなんらかの不具合が発生していることを示すアラートをOracle Enterprise Manager Fusion Middleware Controlに送信します。
会社Xは、データ検証ステージを開いて、「検証」アクションを選択することでデータ検証を構成します。この部分で、ProcessOrderコンポジットで予期されるOrderスキーマ・エレメント・タイプに対して受信ペイロードを検証できます。Oracle Service Busでの検証によって、バック・エンド(正常な注文の処理が行われる)にリソースが保存されます。会社Xでは、他のすべての詳細は事前構成されているため、検証の基準となるOrderタイプのみを選択する必要があります。
会社Xは、コンポジットから返される注文番号(図4-30を参照)をレポートするように、図4-28に示したレスポンス・フローの「監査」ステージの「レポート」アクションを構成します。テンプレートでは、エラーに備えて受信注文のコピーがすでに保存されているため、それをOracle Enterprise Manager Fusion Middleware Controlにレポートします。
また、会社Xは、図4-28のテンプレートの「ルーティング」アイコンをダブルクリックし、プロパティ・インスペクタの「ルーティング」タブを選択して、「ProcessBS」ビジネス・サービスを選択することにより、ルーティング・ノードも構成します。図4-31に詳細を示します。
構成の完了後、Oracle Service Busアプリケーションは図4-32のようになります。
4.2.8 パイプライン・テンプレートのテスト
会社Xは、左スイムレーンの「ProcessPS」サービスを右クリックし、「実行」を選択してテストします(図4-33を参照)。テスト・フェーズ中には、正常な注文と不正な注文が送信されます。
4.3 関連ドキュメント
表4-2では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。
表4-2 関連ドキュメント
| 参照内容 | 参照先 |
|---|---|
|
SOAコンポジット・アプリケーションの作成 |
『Oracle SOA SuiteでのSOAアプリケーションの開発』のSOAアプリケーションの作成に関する項 |
|
コンポジット・テンプレートとインライン・サブプロセスの作成と使用 |
『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle SOA Suiteテンプレートおよび再利用可能なサブプロセスに関する項 |
|
コンポジット・センサーの作成 |
『Oracle SOA SuiteでのSOAアプリケーションの開発』のコンポジット・センサーの定義に関する項 |
|
Oracle Service Busでのビジネス・サービスの作成 |
『Oracle Service Busでのサービスの開発』のビジネス・サービスの作成と構成に関する項 |
|
パイプライン・テンプレートの使用 |
『Oracle Service Busでのサービスの開発』のパイプライン・テンプレートの使用に関する項 |