| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、エンタープライズ・ビジネス・サービス(EBS)の概要を示し、EBSの設計、プロセスEBS用のWSDLの作成、メッセージ・ルーティングの処理、Oracle Mediatorを使用したEBSの作成、ファイア・アンド・フォーゲット・メッセージ交換パターンの実装、同期リクエスト/レスポンス・メッセージ交換パターンの実装、および非同期リクエスト/遅延レスポンス・メッセージ交換パターンの実装の各方法について説明します。
この章の内容は次のとおりです。
EBSは、Oracle Application Integration Architecture (AIA)の基礎です。EBSは、アプリケーションまたは実装に依存しない、タスクを実行するためのWebサービス定義を表し、そのアーキテクチャによってEBSを使用した分散処理が促進されます。EBSは自己完結型であるため、他のサービスから独立して使用できます。さらに、別のEBS内で使用できます。
EBSの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのエンタープライズ・ビジネス・サービスの理解に関する項を参照してください。
EBSを作成する必要があるのは、標準モデルを使用した複数のソース・アプリケーションとターゲット・アプリケーション間でビジネス・プロセス統合が実行される場合です。
EBSの目的は、次のとおりです。
要求側サービスと提供側サービス間の仲介を提供します。
リクエスタ・アプリケーション・ビジネス・コネクタ・サービス(ABCS)、EBSまたはエンタープライズ・ビジネス・フロー(EBF)から呼び出される様々な操作を提供します。
操作に対する様々なルーティング・ルールの評価に基づいて、適切なEBS、EBFまたはプロバイダABCSに操作をルーティングします。
Oracle AIAでは、EBSの作成に、Oracle SOA Suiteで使用できるメディエータ・テクノロジが利用されます。
EBSは、メディエータ・ルーティング・サービスとして実装されます。メディエータ・サービスには、EBSの複数操作の保持、各操作に対するルーティング・ルールの作成、XSLT変換の実行、および各ルーティング・ルールに対するエンドポイントの定義を実行するための複雑なメカニズムがあります。
Oracleメディエータの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle Mediatorのサービス・コンポーネントの使用方法の部を参照してください。
EBS操作は、同期または非同期のメッセージ交換パターン(MEP)としてモデル化できます。
EBSのタイプは、次のとおりです。
ビジネス・アクティビティ
これらは、システム間の相互作用を含む一連のステップがある自立型ビジネス作業単位を表します。これらは、ABCSまたはEBFを介した実装によってメディエータ・サービスとして公開されます。
タスク
これらは、エンタープライズ・データの集計されたリアルタイムのビューを提供します。これらは主に、エンタープライズ・ビジネス・オブジェクト(EBO)とそのビジネス・コンポーネントを実行対象とする、作成、読取り、更新、削除(CRUD)操作です。これらは、ABCSを介した実装によってメディエータ・サービスとして公開されます。この結果、データ・レベルでのポイントツーポイント・リンク、およびデータソースのデータ・モデルへの直接依存がなくなります。
EBSタイプの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのエンタープライズ・ビジネス・サービスの理解に関する項を参照してください。
SOAコア拡張機能には、EBSライブラリが同梱されています。EBSライブラリは、エンタープライズ・オブジェクト・ライブラリに存在するすべてのEBOに対して提供されたサービス定義で構成されます。これらはWSDLファイルとして提供されています。EBSに存在するサービス操作は通常、CRUD操作およびエンティティに固有のいくつかの操作です。
エンタープライズ・ビジネス・サービス・ライブラリ内のデータ・サービス・タイプのEBS WSDLの操作はすべて、非同期の一方向サービスとしてモデル化されます。唯一の例外は問合せ操作と検証操作です。これらは、名前付きフォルトとともに同期リクエスト/レスポンス操作としてモデル化されます。
SOAコア拡張機能で提供されている、AIAComponents/EnterpriseServiceLibraryフォルダの下にあるサンプルWSDLを確認できます。
新しいサービスまたは操作の作成を決定する前に、各WSDL、その操作の説明およびメタデータを確認してください。
作成する新しいEBSは、タイプがアクティビティ・サービスであり、開発中の統合ソリューションの要件を満たす操作を含んでいる必要があります。
新しいEBSは、異なるWSDLに配置する必要があり、エンティティEBSのWSDLには追加しないでください。
この項には次のトピックが含まれます:
EBSを設計および実装する手法はコントラクト優先の手法であり、つまり、EBSの実装前にコントラクトが定義および作成されます。EBSのコントラクトは、WSDLドキュメントとして定義されます。
タスクEBSの場合、SOAコア拡張機能のエンタープライズ・サービス・ライブラリからWSDLを使用します。
同期リクエスト/レスポンスMEPをサポートするサービス操作は、1つのポート・タイプで定義します。操作には、入力、出力およびフォルト・メッセージが定義されている必要があります。
ファイア・アンド・フォーゲットMEPをサポートするサービス操作は、1つのポート・タイプで定義し、操作に入力メッセージが定義されている必要があります。
非同期リクエスト/遅延レスポンス・パターンをサポートするサービス操作には2つの操作が必要であり、1つはリクエスト・メッセージを送信する操作、もう1つはレスポンス・メッセージを処理する操作です。これらの2つの操作それぞれに入力メッセージが必要です。2つの異なるportTypeが、各操作に対して1つずつ存在します。レスポンス・メッセージを処理するサービス操作は、接尾辞がResponseのポート・タイプに存在する必要があります。
EBS WSDLには2種類のportTypeが必要です。
同期リクエスト/レスポンス操作およびリクエストのみの操作をモデル化するために使用するすべての操作用のportType。名前にRequestは指定しません。
非同期レスポンス操作用のportType。名前にResponseを指定します。
各portTypeに対して2つのメディエータ・ルーティング・サービスを作成する必要があります。
EBSを設計する際は、次の事項を考慮してください。
サービスの目的
企業では特定のビジネス機能に対してEBSを1つのみ設定する必要があり、そのEBSはいずれのアプリケーションにも依存しない必要があります。
サービスで、EBS WSDLに定義された複数のビジネス操作を実装できます。
ビジネス・オブジェクトに対するすべてのビジネス操作の実装が必要です。
サービスにレスポンス操作も含まれている必要があり、これは非同期リクエスト/レスポンス・パターンに必要です。
サービスの呼出し方法
サービスは、HTTPトランスポートを使用してWebサービスとして呼び出されます。
コール側のクライアントがこのサービスと同じ場所にある場合、パフォーマンスの改善およびトランザクションの伝播のために、最適化されたバインディングを使用したローカル呼出しになるようにコールを構成できます。
サービスの呼出し元
アプリケーションでエンタープライズ・ビジネス・メッセージ(EBM)を送信でき、リクエスタABCSのすべての機能を実行できる場合に、サービスをアプリケーションによって呼び出すことができます。
アプリケーションにこのサービスを直接呼び出す機能がない場合は、リクエスタABCSによってこのサービスが呼び出されます。
複数ビジネス・オブジェクト全体を編成するEBFフローでこのサービスを呼び出すこともできます。
アプリケーションとの相互作用方法
アプリケーションでEBMメッセージを受信できる場合は、EBSで、HTTPを使用してアプリケーションをWebサービス・コールとしてコールできます。
そうでない場合は、プロバイダABCSを作成してコールする必要があります。
クライアントとEBS間の相互作用のタイプ
クライアントは、3つのMEPのいずれかを使用してEBSをコールできます。
EBSライブラリのエンティティEBSのWSDLに対するMEPは事前定義されているため、プロセスEBSのWSDLを設計する必要があります。EBSは、複数の操作を含むようにモデル化されています。各操作では、特定のビジネス・シナリオ要件に対するEBSが実行され、実質的に粒度が細かくなっています。したがって、各操作は、異なる相互作用スタイルまたはパターンをサポートするようにモデル化できます。
図5-1に、EBSパターンの設定における決定ポイントを示します。
図5-1 EBS操作の相互作用パターンの識別
EBSタイプの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのエンタープライズ・ビジネス・サービスの理解に関する項を参照してください。
EBSは、エラーを再スローして呼出し元クライアントに戻すように構成する必要があります。アプリケーション・エラー処理機能が、統合プラットフォームのエラー処理機能と一致していることを確認します。
エラー処理の詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。
呼出し元クライアント(リクエスタABCSまたはアプリケーション)がリモートの場合、EBSは、セキュリティの章の説明に従ってセキュリティに対応する必要があります。
セキュリティの詳細は、「セキュリティに関する作業」を参照してください。
EBSの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのエンタープライズ・ビジネス・サービスの理解に関する項を参照してください。
Oracle Fusion MiddlewareのSOAトランザクション・セマンティクスに基づいて、ABCS、EBSおよびEBF全体でトランザクションを設計および構成できます。
詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。
この項には次のトピックが含まれます:
これらの項では、WSDLの各セクションの入力方法について説明します。
WSDLを作成する際は、次のことを考慮します。
OracleのJDeveloperおよびテキスト編集ツールをWSDLの作成に使用できます。
EBO用のEBMスキーマ・モジュールをWSDLで参照する必要があります。
WSDLでは、中央の場所で管理されているスキーマ・モジュールを参照する必要があります。
「AIA開発でのOracle AIAネーミング標準」の説明に従って、サービス、ターゲット・ネームスペース、メッセージ、操作、ポート・タイプなどを作成するための命名規則に従う必要があります。
WSDLタイプ・セクションのメッセージ構造を定義する手順は、次のとおりです。
メッセージ定義
それぞれの操作に対して、選択したパターンに応じて、リクエストを送信するためのメッセージ、およびレスポンスを受信するための別のメッセージ(オプション)を作成する必要があります。
リクエストを送信するためのメッセージは、ReqMsgが続く操作と同じである必要があります。
レスポンス・メッセージは、RespMsgが続く操作と同じである必要があります。
portType定義
各操作のportType名を定義する必要があり、それはサービス名と同じである必要があります。パターンに基づいて、メッセージ定義セクションに、入力および出力要素に指定されるメッセージ名を定義しました。サービスがデプロイされると、メディエータによって、サービスがポート・タイプに追加され、具象WSDLのサービス・セクションに挿入されるサービス名が形成されます。
サービス・インタフェースの注釈付け
WSDLの各セクションで、セクションの詳細に注釈を付けることができるドキュメンテーションが許可されます。WSDL作成者は、セクション全体に、既存のEBS WSDLに注釈を付ける方法と同じように注釈を付ける必要があります。
この項には次のトピックが含まれます:
EBSルーティング・サービス操作のルーティング・ルールは、受信メッセージをルーティングするターゲット・エンド・ポイントを決定するために使用されます。
ルーティング・ルールを作成する際は、次のガイドラインに従います。
ルーティング・ルールは、第一に機能に関して、さらに常に特定の統合トポロジを考慮して定義する必要があります。
ほとんどの場合、ルーティング・ロジックをEBSのルーティング・ルールで実行する必要があります。
ただし、EBSのすべてのルーティング・ルールで、ヘッダーにスタンプされた既存のターゲット・システムIDを確認し、優先する必要があります。EBSルールでは、ターゲット・システムIDが入力されることは想定しないでください。
リクエスタABCSでは、ターゲット・システムの決定、またはEBMヘッダーのターゲット・システムIDのスタンプは実行しないでください。
いずれのEBS操作でも、考えられる各ターゲット・アプリケーション・システム・インスタンスにルーティング・ルールが必要です。
たとえば、SEBL_01とSEBL_02の2つのSiebelプロバイダ・アプリケーション・システム・インスタンスが存在する場合は、両方のルールが同じSiebelプロバイダABCSをターゲットとしている場合でも、それぞれにルーティング・ルールが必要です。
別の方法として、機能要件で、アプリケーション・タイプの単一のインスタンスのみが実行時にメッセージを受信できることを指定した場合は、単一のルールを使用でき、実行時に使用される1つのインスタンスのIDをスタンプするためにXSLTが呼び出されます。
EBS操作に同じアプリケーション・タイプの複数のプロバイダ・アプリケーション・システム・インスタンス(SEBL_01とSEBL_02など)がある場合は、各インスタンスのルーティング・ルールでは、複数インスタンス間で共有されるプロバイダABCSが、呼び出して相互参照するインスタンスを識別できるように、XSLTによってEBMヘッダーに適切なシステム・インスタンスIDをスタンプする必要があります。
EBS操作が同期リクエスト/リプライ・パターンまたは非同期リクエスト/遅延レスポンス・パターンである場合、ルーティング・ルールは、Oracle AIAシステムの実際のトポロジでは相互に排他的である必要があります。
ルーティング・ルールは、メディエータ・ルーティング・サービスの一部として、事前作成済の統合とともに提供されます。
これらのルールは、提供されているトポロジに対して機能するように設計されています。システム・インスタンスの追加など、提供されているトポロジに対する変更を実装する場合は、ルーティング・ルールの独自の完全なセットを実装する必要があります。
標準のルーティング・ルール句の構造は、次のとおりです。
(cavs_check)および(ruleset_check)および((target_system_identified_check)または((target_system_absent_check)および(topology_specific_clauses))
表5-1に、ルーティング・ルール句および関連XPath式を示します。
表5-1 ルーティング・ルール句
| 句 | XPath式 |
|---|---|
cavs_check) = |
MessageProcessingInstruction/EnvironmentCode='PRODUCTION' or not(MessageProcessingInstruction/EnvironmentCode/text())) |
ruleset_check) = |
TBD |
target_system_identified_check) = |
EBMHeader/Target/ApplicationTypeCode='SIEBEL' |
target_system_absent_check) = |
not(EBMHeader/Target/ID/text()) |
O2C2 OOTB (topology_specific_clauses) = |
aia:getSystemType(EBMHeader/Sender/ID)!='SIEBEL' |
表5-2に、統合済サプライ・チェーン管理の事前作成済の統合の一部として提供されているルーティング・ルールをいくつか示します。
表5-2 提供されているルーティング・ルール
| ターゲット | SiebelプロバイダABCS |
|---|---|
XPath Filter: |
(MessageProcessingInstruction/EnvironmentCode='PRODUCTION' or not(MessageProcessingInstruction/EnvironmentCode/text( )))and (EBMHeader/Target/ApplicationTypeCode='SIEBEL' or ( not(EBMHeader/Target/ID/text()) and aia:getSystemType(EBMHeader/Sender/ID)!='SIEBEL' ) ) |
変換: |
なし |
説明: |
MessageProcessingInstruction/EnvironmentCode='PRODUCTION'またはまったく指定されていないこと、かつターゲット・アプリケーション・タイプはSiebelが指定されているか、またはターゲットが指定されていないこと、かつ送信側アプリケーション・タイプがSiebelではないこと。 |
ターゲット: |
Oracle EBusinessプロバイダABCS |
XPath Filter: |
(MessageProcessingInstruction/EnvironmentCode='PRODUCTION' or not(MessageProcessingInstruction/EnvironmentCode/ text())) and ( EBMHeader/Target/ ApplicationTypeCode='EBIZ' or ( not(EBMHeader/Target/ID/text()) and aia:getSystemType(EBMHeader/Sender/ID)!='EBIZ' ) ) |
変換: |
なし |
説明: |
MessageProcessingInstruction/EnvironmentCode='PRODUCTION'またはまったく指定されていないこと、かつターゲット・アプリケーション・タイプはEBizが指定されているか、またはターゲットが指定されていないこと、かつ送信側アプリケーション・タイプがEBizではないこと。 |
ターゲット: |
CAVS |
XPath Filter: |
MessageProcessingInstruction/EnvironmentCode='CAVS' |
変換: |
なし |
説明: |
MessageProcessingInstruction/EnvironmentCode='CAVS' |
ルーティング・ルールは、EBSサービスで定義された各操作に対して指定されます。システムでは、ルーティング・ルールを使用して、受信EBMのルーティング先をEBF、EBS、ABCSまたはコンポジット・アプリケーション検証システム(CAVS)のいずれにするかが決定されます。ルーティング・ルールは、メディエータ・ルーティング・ルールのフィルタで、XPath式として指定されます。
すべてのルールが評価されて、ルール評価に基づいてメッセージがエンド・ポイントにルーティングされるため、ルーティング・ルールは相互に排他的である必要があります。
最低でも、各EBS操作にこれらのルールが必要です。
CAVS対応用の1つのルーティング・ルール。
このルールでは、EBMヘッダー→MessageProcessingInstruction→EnvironmentCodeがCAVSに設定されているかどうかを確認する必要があります。
プロバイダABCSまたはEBFに接続するための1つ以上のルーティング・ルール。
これらのルーティング・ルールに指定されたフィルタ式で、メッセージがテスト・メッセージではないことを保証する必要があります。
各ABCSまたはEBFに対して、1つのルーティング・ルールが存在します。条件は次のいずれかです。
EBMヘッダーに入力されたターゲット・システムABCS
ターゲット・システムABCSを決定するためのSalesOrderEBSルーティング・ルールのフィルタ式の例は、次のとおりです。
この場合、フィルタには、EBMヘッダーのターゲット・システムABCSが事前に入力されていて、「ルーティングのオーバーライド」インディケータが「False」に設定されているかどうかを確認する式があります。
/sordebo:QuerySalesOrderEBM/ns5:EBMHeader/ns5:Target/ns5:ID = "SEBL78_01" and /sordebo: Query SalesOrderEBM/ns5:EBMHeader/ns5:Target/ns5: Override RoutingIndicator = "false"
コンテンツベース・ルーティング
この場合、ターゲット・システムABCSを決定するためにEBMのコンテンツが評価されます。フィルタ式で、ターゲット・システムの情報がEBMヘッダーに事前入力されなかったことを確認する必要があります。
式の例:
starts-with(/sordebo: CreateSalesOrderEBM /sordebo: DataArea/sordebo: CreateSalesOrder/sordebo: SalesOrderLine /sordebo:SalesOrderLineSchedule/ns5:ShipToPartyReference /ns5:LocationReference /ns5:Address/ns5:CountrySubDivisionCode,'9') and /sordebo:CreateSalesOrderEBM/ns5:EBMHeader /ns5:Target/ns5:ID = ""
パラレル・ルーティング
各ターゲット・サービスでその独自のトランザクションを呼び出し、ターゲット・サービスを再試行する場合は、EBSでパラレル・ルーティングを使用する必要があります。
詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」を参照してください。
エラー処理およびロギングの有効化
EBSでは、クライアントまたは管理者が中央のエラー・ハンドラを介してプロセスを再発行または再トリガーできるようにエラーを処理する必要があります。
詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。
EBSでは、リクエスタABCS、EBFまたは別のEBSのリクエストを、使用可能な多数のプロバイダABCSのいずれかにルーティングできます。ターゲット・システムを識別する必要があるのは、作成操作の場合のみです。他のすべての操作については、Xref関数lookupPopulatedColumnsを使用して、エンティティのデータの同期が完了しているシステムが識別されます。次に示したステップを組み合せると、適切なABCSになります。
EBSでターゲット・システムを識別する手順は、次のとおりです。
コンテンツベース・ルーティングの使用。
EBSのルーティング・ルールはメッセージのコンテンツに基づき、ターゲットABCSの決定に使用されます。これは、作成操作の場合のみ使用されます。これは、EBMヘッダーのターゲット・システム情報が空で、まだ設定されていない場合です。
ターゲット・システムは、決定するとEBMヘッダーに設定されます。この情報は、後続のすべてのサービス(他のEBSまたはABCSなど)で使用されます。
EBMヘッダーのターゲット・システム情報の使用。
ターゲット・システム情報がEBMに設定されている場合は、これが適切なABCSへのルーティングに使用されます。
作成以外の操作の場合はXREFを使用。
作成以外のすべての操作では、ターゲット・システムは決定されていて、相互参照IDが設定されています。この場合、XREF関数lookupPopulatedColumnsを使用して、エンティティのデータの同期が完了しているシステムが識別されます。
Oracle Mediatorコンポーネントを使用すると、EBSコンポジットにコンポーネントを作成できます。
Oracle AIAでは、EBSサービスの開発に任意のテクノロジを使用できますが、ほとんどの場合メディエータを使用します。
両方の非同期MEP (ファイア・アンド・フォーゲットとリクエスト/遅延レスポンス)を実装するには、EBS WSDLを作成した後、MEPに応じて1つまたは2つのメディエータ・ルーティング・サービスを作成する必要があります。次に、それぞれのMEPに対するガイドラインに従って、リクエスタ・サービスとプロバイダ・サービスを実装します。
要求側サービスは、リクエスタABCS (BPELプロセス)、EBF (BPELプロセス)または参加アプリケーションです。
提供側サービスは、プロバイダABCS (BPELプロセス)、EBF (BPELプロセス)または参加アプリケーションです。
この項には次のトピックが含まれます:
ファイア・アンド・フォーゲット・パターンのイニシエータは、レスポンスを待機または予測しない要求側サービスです。要求側サービスは、参加アプリケーション、リクエスタABCS ImplまたはEBFです。これらのそれぞれの場合で、リクエスト・ペイロードはEBMリクエストである必要があります。
ABCS (リクエスタとプロバイダの両方)の有効化の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」、「ABCSの作成」および「ABCS開発の完了」を参照してください。
EBFの有効化の詳細は、「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。
EBSの一方向コールを使用したファイア・アンド・フォーゲット・パターンを実装する手順は、次のとおりです。
注意:
これらのステップは、要求側サービスと提供側サービスに必要な通常のステップに追加します。
エンティティEBSの場合、SOAコア拡張機能のエンタープライズ・サービス・ライブラリからWSDLを使用します。
同期リクエスト/レスポンスMEPをサポートするサービス操作は、1つのポートタイプで定義し、操作で入力、出力およびフォルト・メッセージが定義されている必要があります。
ファイア・アンド・フォーゲットMEPをサポートするサービス操作は、1つのポート・タイプで定義し、操作で入力メッセージが設定されている必要があります。
非同期リクエスト/レスポンス・パターンをサポートするサービス操作には2つの操作が必要であり、1つはリクエスト・メッセージを送信する操作、もう1つはレスポンス・メッセージを処理する操作です。
これらの2つの操作それぞれで独立した入力メッセージが設定される必要があります。各操作に1つずつ、2つの異なるportTypeが必要です。レスポンス・メッセージを処理するサービス操作は、接尾辞がResponseのportTypeに存在する必要があります。
EBS WSDLには2つのportTypeが必要です。
同期リクエスト、レスポンス操作およびリクエストのみの操作をモデル化するために使用するすべての操作用のportType。名前にRequestは指定しないでください。
非同期レスポンス操作用のportType。名前にResponseを指定する必要があります。
2つのメディエータ・ルーティング・サービスを各portTypeに対して作成する必要があります。
一方向コールEBSを使用した非同期ファイア・アンド・フォーゲット・パターンに対するメディエータ・ルーティング・サービスを作成する手順は、次のとおりです。
非同期ファイア・アンド・フォーゲットMEPのメディエータ・プロジェクトを作成する手順は、次のとおりです。
リクエストEBSのルーティング・ルールは、同期リクエスト/レスポンス・セクションに対するルーティング・ルールと同じです。
詳細は、「同期リクエスト/レスポンスMEPのルーティング・サービスの作成方法」を参照してください。
提供側サービスのエラーの影響を相殺するために、一方向コールの要求側サービスで補正をトリガーする操作をEBSに追加できます。これは、EBSに補正操作を設定することによって実行できます。
一方向コールとしてモデル化される補正操作は、独立した操作です。リクエストportTypeのリクエストのみの各操作には、補正をトリガーするための操作が必要です。
例: CompensateCreateCustomer、CompensateCreateOrder。
補正操作は、ビジネス例外によって回復不能なエラーが発生する可能性が高い場合に呼び出されます。従来の再試行および再発行ができず、要求側サービスで訂正が実行される必要があります。
この状況では、参加アプリケーションの補正アクションWebサービスまたはAPIを利用する、適切な補正を実装する必要があります。
エラー処理では、一部のエラーに対して補正アクションが実行されて、EBSの補正操作が提供側サービスから呼び出されることを保証する必要があります。EBSの補正操作は、適切な補正サービスにルーティングされます。
EBSの補正操作を呼び出す手順は、次のとおりです。
図5-3に、補正操作を含むファイア・アンド・フォーゲット・パターンを示します。
図5-3 補正操作を含むファイア・アンド・フォーゲット・パターン
2つのルーティング・ルールが必要です。
補正操作ルーティング・サービスのルーティング・ルールを有効化する手順は、次のとおりです。
EBSの補正操作に対するルーティング・ルール。
要求側サービスの<EBO Name>ResponseEBM\corecom:EBMHeader\Sender\ WSAddress/ WSAddress/wsa:FaultTo/wsa:ServiceNameに入力された情報は、補正のリクエストを、EBSの補正操作の適切な補正サービスにルーティングするために使用されます。
このルーティング・ルールをEBSの補正操作に含めます。
<EBO Name>ResponseEBM\corecom:EBMHeader\Sender\ WSAddress/ WSAddress/wsa:FaultTo/wsa:ServiceName = <Compensating Service Name>
CAVSに対するルーティング・ルール。
CAVSで作成したテスト・ケースのタイプが非同期遅延レスポンスである場合は、レスポンス・メッセージをCAVSエンドポイントに移動して、テストに合格/失敗するように相関付けることができます。これが発生するには、CAVSシステム・エンドポイントに対する明示的なinvokeが存在する必要があります: http://host:port/AIAValidationSystemServlet/asyncresponserecipient。
同期リクエスト/リプライ・パターンのイニシエータは、レスポンスを待機および予測する要求側サービスです。要求側サービスは、参加アプリケーション、リクエスタABCS ImplまたはEBFです。これらのそれぞれの場合で、リクエスト・ペイロードはEBMリクエストで、レスポンス・ペイロードはEBMレスポンスです。
この項には次のトピックが含まれます:
ABCS (リクエスタとプロバイダの両方)の有効化の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」、「ABCSの作成」および「ABCS開発の完了」を参照してください。
EBFの有効化の詳細は、「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。
EBSで同期リクエスト/リプライMEPを実装する手順は、次のとおりです。
ルーティング・サービスを含むメディエータ・プロジェクトを作成します。
要求側サービスのリクエストを、EBSのルーティング・サービスの適切な提供側サービスにルーティングするルーティング・ルールを作成します。
フォルト・ポリシーに基づいて、ロギングおよび通知用のエラー処理を実装します。
同期リクエスト/レスポンスMEPのメディエータ・プロジェクトを作成する手順は、次のとおりです。
メディエータ・プロジェクトを作成する際は、次のガイドラインに従います。
リクエスト/遅延レスポンス・パターンのイニシエータは、リクエストEBSを呼び出し、レスポンスを待機する要求側サービスです。要求側サービスは、参加アプリケーション、リクエスタABCS ImplまたはEBFです。これらのそれぞれの場合で、リクエスト・ペイロードはEBMリクエストで、レスポンス・ペイロードはEBMレスポンスです。
提供側サービスのエラーの場合、エラー情報を含むレスポンス・メッセージが作成され、処理のために要求側サービスに返されます。
この項には次のトピックが含まれます:
ABCS (リクエスタとプロバイダの両方)の有効化の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」、「ABCSの作成」および「ABCS開発の完了」を参照してください。
EBFの有効化の詳細は、「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。
EBSの2つの一方向コールを使用したリクエスト/遅延レスポンス・パターンを実装する手順は、次のとおりです。
注意:
要求側サービスと提供側サービスに必要な通常のステップに加えて、これらのステップを実行します。
図5-4に、リクエスト/遅延レスポンス・パターンを示します。
図5-4 リクエスト/遅延レスポンス・パターン
メディエータ・ルーティング・アーキテクチャを作成する手順は、次のとおりです。
リクエスト/遅延レスポンスMEPのルーティング・サービスを作成する手順は、次のとおりです。
注意:
これらのガイドラインは、非同期メッセージ交換パターンの実装に追加します。
非同期リクエスト/遅延レスポンスEBSの場合、ルーティング・ルールをリクエストとレスポンスの両方に対して作成する必要があります。
リクエストEBSのルーティング・ルール
リクエストEBSのルーティング・ルールは、同期リクエスト/レスポンスの項で説明しているルーティング・ルールと同じです。
詳細は、「同期リクエスト/レスポンスMEPのルーティング・サービスの作成方法」を参照してください。
レスポンスEBSのルーティング・ルール
2つのルーティング・ルールが必要です。
レスポンスEBSのルーティング・ルールを作成する手順は、次のとおりです。
複数の参加アプリケーションの複数の要求側サービスでリクエストEBSを呼び出し、遅延レスポンスを待機している場合は、レスポンスを適切な要求側サービスにルーティングする必要があります。
図5-5に示すように、リクエストEBSを呼び出す前に、EBMHeader/Sender/WSAddress/wsa:ReplyTo/wsa:ServiceNameに要求側サービスの要求側サービス名の名前(アプリケーション・ビジネス・メッセージ(ABM)からEBMへの変換)を設定します。
図5-5 WSAddressタイプ要素の構造
提供側サービスでは、この情報はリクエストEBMからレスポンスEBMに転送されます。この情報は、次のように、ルーティング・ルールをフィルタに組み込むことによって、レスポンスEBSで使用されます。
<EBO Name>ResponseEBM\corecom:EBMHeader\Sender\ WSAddress/wsa:ReplyTo/wsa:ServiceName = <Requesting Service Name>
このルールの評価のターゲット・エンドポイントは、要求側サービスに設定する必要があります。
レスポンスEBSによるレスポンスの返送を待機しているリクエストEBSのすべての要求側サービスに対して、前述のようにルーティング・ルールを指定します。
エラー処理の実装
詳細は、「保証付きメッセージ配信を確保するための非同期メッセージ交換パターンに対するエラー処理およびリカバリの実装」を参照してください。
非同期リクエスト/遅延レスポンスMEPでは、要求側サービスは、レスポンスを待機する一時停止モードです。提供側サービスにエラーがある場合は、要求側サービスへのレスポンスにエラーの詳細が含まれます。
非同期リクエスト/遅延レスポンスMEPのエラーを処理する手順は、次のとおりです。
ABCS (リクエスタとプロバイダの両方)の有効化の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」、「ABCSの作成」および「ABCS開発の完了」を参照してください。
