| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、エンタープライズ・ビジネス・フロー(EBF)の概要を示し、EBFを定義して実装する方法を説明します。
注意:
コンポジット・ビジネス・プロセス(CBP)は、次のリリースから非推奨となります。人間/システム相互作用のモデル化には、BPMの使用をお薦めします。
この章の内容は次のとおりです。
EBFは、複数のアプリケーションで使用可能な機能を含むビジネス・アクティビティまたはタスクを実装するために使用します。EBFは、アプリケーションで使用可能な一連の機能を1列に並べて粒度の粗いビジネス・アクティビティまたはタスクを実装したり、既存の機能を利用する新しいサービスを構成します。EBFには、システム間またはサービス間の相互作用のみ含まれます。EBFには、管理者操作が必要なアクティビティはありません。
正規の統合では、EBFはエンタープライズ・ビジネス・サービス(EBS)操作の実装で、他のEBSをコールします。アプリケーション・ビジネス・コネクタ・サービス(ABCS)やアプリケーションを直接コールすることはありません。他の統合スタイルでは、EBFを呼び出すコール元はアプリケーションまたはその他のサービスのいずれかになります。
図9-1および図9-2に、注文から現金化までのプロセス統合パックの事前作成済の統合にある複数のEBFを実装して、既存の機能を利用する方法を示します。
図9-1に、ソース・アプリケーションとターゲット・アプリケーション間で顧客を同期化するためにフローを編成するEBFを示します。ソース・アプリケーションからsync操作が呼び出されると、EBFは最初に、ターゲット・アプリケーションに顧客が存在するかどうかを確認します。そうである場合はターゲット・アプリケーションの顧客を更新し、そうでない場合はターゲット・アプリケーションに顧客を作成します。
図9-1 ソースからターゲットにフローを編成するEBFの例
図9-2に、受注を受け取り、顧客の作成、履行、およびソース・アプリケーションへのレスポンスによる更新を編成するフローを示します。
図9-2 受注フローの例
EBFを設計および実装するためのOracle Application Integration Architecture (AIA)の手法は、コントラクト最優先手法です。したがって、コントラクトはEBFの実装前に定義して作成する必要があります。
コントラクトを定義する手順は、次のとおりです。
EBFを識別します。
EBFのパターンを識別します。
リクエストおよびレスポンス(ある場合)に使用するエンタープライズ・ビジネス・メッセージ(EBM)を識別します。
新規サービスの設計に含まれる最初のタスクは、そのサービスが必要かどうかを検証することです。
識別した機能の一部またはすべてを提供するサービスがすでに存在している可能性もあります。新しいサービスまたは操作を作成する前に、個々のサービス、操作の説明、およびメタデータをレビューしてください。
EBFが必要となるのは、EBS操作を一連のタスクとともに実装する必要があり、複数のサービスを呼び出す場合です。
正規ベースの統合では、EBFは別のEBSのみ呼び出すことができます。
エンタープライズ・ビジネス・フローは、単一の操作を実装するようにモデル化されています。
EBFのメッセージ交換パターン(MEP)を識別する手順は、次のとおりです。
機能設計ドキュメント(FDD)で明らかになったビジネス・プロセス要件に基づいて、EBFをトリガーするイベントを識別します。例9-1を参照してください。
呼出しのポイントにレスポンスが返ってくるまで制御をブロックする場合は、EBFリクエスト/リプライ・パターンを選択します。これは同期コールです。
EBFの呼び出した後に、トリガー・ポイントでレスポンスを待たずに処理を続行する場合、そのEBFの呼出しは非同期コールです。
EBFの処理後にレスポンスが返されるかどうかを確認します。
リクエストとレスポンスの関連付けが必要ですか。
答えがYesの場合、これは遅延レスポンスです。EBFリクエスト/遅延レスポンス・パターンを使用してください。答えがNoの場合は、EBFファイア・アンド・フォーゲット・パターンを選択してください。
公開イベントへのサブスクリプションによって呼び出されるすべてのEBF操作は、EBSサブスクライブ・パターンを使用します。
例9-1 EBFのメッセージ交換パターン識別の例
<operation name="InterfaceSalesOrderToCustomer">
<documentation>
<svcdoc:Operation>
<svcdoc:Description>This operation is used to interface
sales order to customer</svcdoc:Description>
<svcdoc:MEP>ASYNC_REQ_RESPONSE</svcdoc:MEP>
<svcdoc:DisplayName>InterfaceSalesOrderToCustomer</svcdoc:DisplayName>
<svcdoc:LifecycleStatus>Active</svcdoc:LifecycleStatus>
<svcdoc:Scope>Public</svcdoc:Scope>
</svcdoc:Operation>
</documentation>
<input message="client:InterfaceSalesOrderToCustomerReqMsg"/>
</operation>
メッセージ構造を識別する手順は、次のとおりです。
CBPは、コールを外部サービスに編成することによって実装されます。CBPをトリガーするイベントは、CBPが処理するビジネス・オブジェクトを示します。
統合スタイルに応じて、次に説明するようにメッセージ構造が決まります。
ビジネス・オブジェクトが既存のエンタープライズ・ビジネス・メッセージ(EBM)で使用可能な場合は、そのビジネス・オブジェクトを使用します。
ビジネス・オブジェクトが既存のEBMで使用不可だが、既存のエンタープライズ・ビジネス・オブジェクト(EBO)ライブラリからアセンブル可能な場合は、そのビジネス・オブジェクトを作成します。
ビジネス・オブジェクトがEBOライブラリで使用不可の場合は、CBPのすべての関連情報と処理を取得するのに適切なペイロードを識別します。
EBF用のコントラクトを作成する手順は、次のとおりです。
