| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、アプリケーション・ビジネス・コネクタ・サービス(ABCS)の開発、エラーおよびフォルトの処理、アダプタの使用、CAVS対応のABCSの開発、ABCSの保護、トランザクションの有効化、メッセージ配信の有効化とABCSのバージョニング、Oracle Mediatorにおける再順序付けおよびレイヤー・カスタマイズを行う方法について説明します。
この章の内容は次のとおりです。
ABCSは、リクエスタ固有かプロバイダ固有かに関係なく、実行中にカスタム・コードを最低でも2回または4回呼び出すことができます。これらは、拡張ポイントとして機能します。
同期または非同期モードのいずれかでリクエスト/レスポンス・パターンをサポートするABCSには、4つの拡張ポイントがあります。ファイア・アンド・フォーゲット・パターンをサポートするABCSには、2つの拡張ポイントがあります。アドインを開発して、これらの拡張ポイントにフックできます。顧客が開発するサービスであるこれらのアドインは、提供されたABCSへの拡張として動作します。各拡張ポイントに1つのフックを使用できるため、1つの顧客拡張のみプラグインできます。
この項では、拡張可能サービスを使用するABCSを作成して、提供されたABCSへの変更が不要なサービス実装を可能にするためのメカニズムを説明します。
リクエスト/レスポンスのリクエスタABCSの場合は、カスタム・コードを4つの拡張ポイントにフックできます。
アプリケーション・ビジネス・メッセージ(ABM)からエンタープライズ・ビジネス・メッセージ(EBM)への変換を実行する直前。構成プロパティ名: ABCSExtension.PreXformABMtoEBMを使用します。
エンタープライズ・ビジネス・サービス(EBS)を呼び出す直前。構成プロパティ名: ABCSExtension.PreInvokeEBSを使用します。
EBMからABMへの変換を実行する直前で、EBSを呼び出した後。構成プロパティ名: ABCSExtension.PostInvokeEBSを使用します。
コールバック・サービスまたはレスポンスの戻しを呼び出してEBMからABMに変換する直前。構成プロパティ名: ABCSExtension.PostXformEBMtoABMを使用します。
3番目と4番目の拡張ポイントは、リクエスト/レスポンス・パターンを実装するABCSでのみ使用できます。
ファイア・アンド・フォーゲットのリクエスタABCSの場合は、カスタム・コードを2つの拡張ポイントにフックできます。
アプリケーション・ビジネス・メッセージ(ABM)からEBMへの変換を実行する直前。構成プロパティ名: ABCSExtension.PreXformABMtoEBMを使用します。
エンタープライズ・ビジネス・サービス(EBS)を呼び出す直前。構成プロパティ名: ABCSExtension.PreInvokeEBSを使用します。
構成パラメータの詳細は、「構成パラメータ」を参照してください。
図8-1に、リクエスタ固有のABCSにおけるアクティビティの高度なフローを示します。この図は、相互作用しているEBSがリクエスト/レスポンス相互作用スタイルを使用していることを前提にしています。顧客拡張を実行して追加タスクを行うためのステップはオプションです。
図8-1 リクエスト/レスポンス相互作用スタイルの拡張
図8-2に、リクエスタ固有のABCSにおけるアクティビティの高度なフローを示します。この図は、相互作用しているEBSがファイア・アンド・フォーゲット相互作用スタイルを使用していることを前提にしています。顧客拡張を実行して追加タスクを行うためのステップはオプションです。
図8-2 ファイア・アンド・フォーゲット相互作用スタイルを使用するリクエスタ固有のABCS
リクエスタABCSの実装者が使用可能な1番目の拡張ポイントは、カスタム・メッセージの検査を実行するのに使用できます。この拡張ポイントを使用して、カスタム検証、メッセージ変更、メッセージのフィルタ処理などのタスクを実行するコードを挿入できます。カスタム・コードは、変換される直前のABMにアクセスして、拡張されたABMを返すか、またはフォルトを発生できます。
2番目の拡張ポイントは、カスタム・メッセージの拡張を実行するのに使用できます。この拡張ポイントを使用して、EBM拡張、カスタム検証などのタスクを実行するコードを挿入できます。カスタム・コードは、EBSの呼出しに使用される直前のEBMにアクセスして、拡張されたEBMを返すか、またはフォルトを発生できます。
3番目の拡張ポイントを使用して、カスタム検証、メッセージ変更、メッセージのフィルタ処理などのタスクを実行するコードを挿入できます。カスタム・コードは、ABMに変換される直前のEBMにアクセスします。カスタム・コードは、変更されたEBMを返すか、またはフォルトを発生できます。
4番目の拡張ポイントを使用して、ABM拡張、カスタム検証などのタスクを実行するコードを挿入できます。カスタム・コードは、コールバック・サービスの呼出しに使用される直前のABMにアクセスします。カスタム・コードは、変更されたABMを返すか、またはフォルトを発生できます
リクエスト/レスポンスのリクエスタABCSの場合は、カスタム・コードを4つの拡張ポイントにフックできます。
EBMからABMへの変換を実行する直前の顧客拡張。構成プロパティ名: ABCSExtension.PreXformEBMtoABMを使用します。
アプリケーション・サービスを呼び出す直前の顧客拡張。構成プロパティ名: ABCSExtension.PreInvokeABSを使用します。
ABMからEBMへの変換を実行する直前で、アプリケーション・サービスを呼び出した後の顧客拡張。構成プロパティ名: ABCSExtension.PostInvokeABSを使用します。
エンタープライズ・ビジネス・サポートを呼び出す直前で、アプリケーション・メッセージからエンタープライズ・ビジネス・メッセージへの変換後の顧客拡張。構成プロパティ名: ABCSExtension.PostXformABMtoEBMを使用します。
3番目と4番目の拡張ポイントは、リクエスト/レスポンス・パターンを実装するABCSでのみ使用できます。
ファイア・アンド・フォーゲットのリクエスタABCSの場合は、カスタム・コードを2つの拡張ポイントにフックできます。
EBMからABMへの変換を実行する直前の顧客拡張。構成プロパティ名: ABCSExtension.PreXformEBMtoABMを使用します。
アプリケーション・サービスを呼び出す直前の顧客拡張。構成プロパティ名: ABCSExtension.PreInvokeABSを使用します。
構成パラメータの詳細は、「構成パラメータ」を参照してください。
図8-3に、プロバイダ固有のABCSにおけるアクティビティの高度なフローを示します。この図は、相互作用しているEBSがリクエスト/レスポンス相互作用スタイルを使用していることを前提にしています。
図8-3 リクエスト/レスポンス相互作用スタイルを使用するプロバイダ固有のABCS
図8-4に、プロバイダ固有のABCSにおけるアクティビティの高度なフローを示します。この図は、相互作用しているEBSがファイア・アンド・フォーゲット相互作用スタイルを使用していることを前提にしています。
図8-4 ファイア・アンド・フォーゲット相互作用スタイルを使用するプロバイダ固有のABCS
プロバイダABCSの実装者が使用可能な1番目の拡張ポイントは、カスタム検証、メッセージ変更、メッセージのフィルタ処理などのタスクを実行するコードを挿入するのに使用できます。カスタム・コードは、変換される直前のEBMにアクセスします。カスタム・コードは、拡張されたEBMを返すか、またはフォルトを発生できます。
2番目の拡張ポイントは、カスタム・メッセージの拡張を実行するのに使用できます。この拡張ポイントを使用して、ABM拡張、カスタム検証などのタスクを実行するコードを挿入できます。カスタム・コードは、アプリケーション・サービスの呼出しに使用される直前のABMにアクセスします。カスタム・コードは、拡張されたABMを返すか、またはフォルトを発生できます。
3番目の拡張ポイントを使用して、カスタム検証、メッセージ変更、メッセージのフィルタ処理などのタスクを実行するコードを挿入できます。カスタム・コードは、EBMに変換される直前のABMにアクセスします。カスタム・コードは、変更されたABMを返すか、またはフォルトを発生できます。
4番目の拡張ポイントは、カスタム・メッセージの拡張を実行するのに使用できます。この拡張ポイントを使用して、EBM拡張、カスタム検証などのタスクを実行するコードを挿入できます。カスタム・コードは、コールバック・サービスの呼出しに使用される直前のEBMにアクセスします。カスタム・コードは、変更されたEBMを返すか、またはフォルトを発生できます。
各拡張ポイントは、明確に定義されたインタフェースを持つサービス操作としてモデル化されます。ABCSの作成者がこれらのインタフェースを定義します。拡張インタフェースは、カスタム・メッセージのエンリッチメントや変換、または顧客によって実装される検証用コードを実行するために、ABCSで呼び出すサービス操作で構成されます。
各ABCSには、対応する顧客拡張サービスが付随します。リクエスト/レスポンスのABCSには4つの拡張ポイントがあるため、ABCSの拡張サービスには4つのサービス操作があります。ファイア・アンド・フォーゲットのABCSの場合、対応するABCSの拡張サービスには2つのサービス操作があります。
前述したように、ABCSのすべての拡張サービスに対するサービス操作の実装では、常に同じメッセージを返す同じコード部分を呼び出します。このコード部分はサーブレットとして実装されています。
ABCSは、各拡張ポイントで適切なサービス操作を呼び出すように開発されています。オーバーヘッドを最小限にするために、関連する拡張インタフェースのサービスが実装済かどうかがチェックされます。Oracle AIAの構成プロパティには、拡張ポイントごとに1つのプロパティがあります。拡張ポイントにカスタム実装があることを示すには、プロパティをYesに設定します。これらのプロパティのデフォルト値はNoに設定されているため、ABCSは配信時にはこれらの拡張の実装を呼び出しません。
表8-1に、リクエスタABCS固有の拡張ポイントに対するサービス操作を示します。
表8-1 リクエスタABCS固有の拡張ポイントに対するサービス操作
| 拡張ポイント | サービス操作名 |
|---|---|
ABMからEBMへの変換を実行する直前 |
Pre-ProcessABM |
EBSを呼び出す直前 |
Pre-ProcessEBM |
EBMからABMへの変換を実行する直前 |
Post-ProcessEBM |
コールバック・サービスまたはレスポンスの戻しを呼び出す直前 |
Post-ProcessEBM |
表8-2に、プロバイダABCS固有の拡張ポイントに対するサービス操作を示します。
表8-2 プロバイダABCS固有の拡張ポイントに対するサービス操作
| 拡張ポイント | サービス操作名 |
|---|---|
EBMからABMへの変換を実行する直前 |
Pre-ProcessEBM |
アプリケーション・サービスを呼び出す直前 |
Pre-ProcessABM |
ABMからEBMへの変換を実行する直前 |
Post-ProcessABM |
コールバックEBSまたはレスポンスの戻しを呼び出す直前 |
Post-ProcessEBM |
ABCSと顧客拡張サービスは同一の場所に配置することをお薦めします。SOA 11gでは、複数のサービスが同じサーバーにデプロイされると、SOA 11gランタイムでネイティブの呼出しが使用されます。
拡張サービスは、ABCSトランザクションの一部として登録することをお薦めします。拡張サービスがSOA 11gテクノロジを使用して実装されるときに、拡張サービスのトランザクション・プロパティbpel.config.transactionをrequiredに設定して、その拡張サービスをABCSトランザクションに登録します。
詳細は、「AIAサービスでのトランザクションの確認方法」を参照してください。
拡張ポイントでの操作は、AIAConfigurationProperties.xmlファイルの特定パラメータの値に基づいて呼び出されます。ABCSに固有の各サービス構成セクションでは、これらのパラメータを指定する必要があります。4つの各拡張ポイントに対するパラメータは次のとおりです。
ABCSExtension.PreXformABMtoEBM
ABCSExtension.PreInvokeEBS
ABCSExtension.PostInvokeEBS
ABCSExtension.PostXformEBMtoABM
ABCSExtension.PreXformEBMtoABM
ABCSExtension.PreInvokeABS
ABCSExtension.PostInvokeABS
ABCSExtension.PostXformABMtoEBM
サービスを呼び出す場合は、これらのパラメータの値をtrueに構成する必要があります。ABCSの構成セクションでこれらのパラメータが指定されていない場合、値はデフォルトでfalseとみなされます。
この項の目的は、これらの構成プロパティを作成および利用して拡張を最適化する方法について、一連のガイドラインを開発者に提供することです。この項で提示するサービス操作名や拡張構成プロパティはすべて推奨です。
また、ここでは、拡張ポイントでのすべての呼出しについてガイドラインを提示しているわけではありません。特定のABCSごとにパラメータ数は異なる場合があります。製品管理チームやエンジニアリング・チームは、追加の拡張が必要な拡張ポイントを識別するのに最も適しています。
部門チームやパートナによって拡張できるサービスを開発するIT組織は、ABCSを拡張対応にする必要性を把握できます。このユースケースに示すように、推奨以外の追加の拡張ポイントを持つABCSを顧客が開発する必要がある場合、サービス操作名は適切な命名規則に従い、構成プロパティは現在提示されているプロパティに類似するように、適切な名前を付けることができます。
ABCSコンポジットを拡張対応サービスとして開発する場合:
ABCSはコンポジット内の1つのコンポーネント(BPELテクノロジを使用)として実装されます。
拡張サービスは、ABCSコンポジットによって外部Webサービスとして参照されます。
拡張ポイントでのサービスがOracle Fusion Middlewareプラットフォームで開発される場合、サービスは個別のコンポジットで開発されます。
ABCSコンポジットによって異なる複数の外部拡張サービスが参照される場合は、ABCSコンポジットから外部サービスへの複数のフックが存在します。つまり、図8-5に示すように、ABCSが2つの拡張ポイントで2つの異なるサービスを呼び出す場合は、コンポジットに2つの異なる外部参照があるように設計する必要があります。
図8-5 2つの異なる外部参照があるコンポジットの例
ただし、同じ外部サービスで公開されている2つの異なる操作をABCSコンポジットが呼び出す場合、図8-6に示すように、ABCSコンポジットにあるのは1つの外部参照のみです。
図8-6 外部参照が1つのコンポジットの例
拡張ポイントでは、対話において各サービスが果たす役割を指定すること、および対話のコンテキスト内でメッセージを受信するために各サービスが提供するポート・タイプを指定することによって、2つのサービス間での対話関係を設定するようにパートナ・リンクが定義されます。
これは、パートナ・リンクから提供されるサービスを表すWeb Services Description Language (WSDL)ファイルを使用して行います。WSDLは、サービス・コンシューマに対するすべてのサービス・プロバイダ・コントラクトを表すXMLドキュメントです。
WSDLによって、サービス・コントラクトは抽象WSDLと具象WSDLの2つの部分に分割されます。
抽象WSDLには、パラメータ(入力および出力タイプ)、フォルト・タイプおよびポート・タイプの構造(インタフェースと呼ばれる)を定義する、タイプやメッセージなどの要素が含まれます。
具象WSDLには、プロトコルへのバインディング、具体的なアドレスの場所、およびサービス要素が含まれます。
抽象WSDLは、設計時に外部参照サービスを定義します。このWSDLは、拡張ポイントで呼び出される操作へのインタフェースを提供します。また、アプリケーション・ビジネス・オブジェクト(ABO)およびエンタープライズ・ビジネス・オブジェクト(EBO)のスキーマを含むか、またはインポートする必要があります。通信トランスポート・プロトコル、ネットワーク・アドレスの場所などは含まれていません。
外部ポイント・サービスの定義に使用される抽象WSDLは、プロジェクト・フォルダに配置される必要があります。AIAサービスの他の抽象WSDLとは異なり、これをMDSにプッシュしないでください。
注意: 抽象WSDLは、設計時のモデル化の目的のみで一時的に使用できます。コンポジットがデプロイされるときに、バインディングを指定する必要があります。
JDeveloperを使用する場合は、次の手順に従ってコンポジットを設計します。
コンポジットを拡張対応のABCSに設計する手順は、次のとおりです。
例8-1 BPELコンポーネントから外部参照コンポーネントへの接続
<reference name="SamplesCreateCustomerSiebelReqABCSImplExtExtension"
ui:wsdlLocation="SamplesCreateCustomerSiebelReqABCSImplExtExtensionAbstract.wsdl">
<interface.wsdl
interface="http://xmlns.oracle.com/ABCSImpl/Siebel/Samples/CreateCustomerSiebelR
eqABCSImplExtExtension/V1#wsdl.interface(SamplesCreateCustomerSiebelReqABCSImpl
ExtExtensionService)"/>
<binding.ws port="" location=""/>
</reference>
具象WSDLは抽象WSDLのコピーで、拡張サービスの定義に使用されます。具象WSDLはバインディング要素も定義して、すべてのポートを結合するトランスポート・プロトコルとサービス要素に関する情報を提供し、顧客がサービス・プロバイダと相互作用するエンドポイントを提供します。
開発の開始時は、具象WSDLはサーブレットであるサンプル拡張サービスをポイントしています。サーブレットの名前はMirrorServletで、SOAコア拡張機能に付属しています。
具象WSDLは、MDSリポジトリの「ExtensionServiceLibrary」フォルダにプッシュする必要があります。
外部参照サービスを呼び出すには、ABCSのcomposite.xmlにランタイムWSDLが具象バインディングとともに指定されている必要があります。WSDLのポート・タイプには具象バインディングが必要です。つまり、コンポジット内では、要素の属性binding.wsを空にできません。
注意:
binding.ws要素のlocation属性にランタイムWSDLのURLを入力しても、抽象WSDLのみを使用するサービスの設計の規則には違反しません。その理由は、この具象WSDLにはコンポジットの設計時にもデプロイ時にもアクセスしないためです。このWSDLにアクセスするのは、コンポジットの実行時のみです。
抽象WSDLを使用して定義された外部Webサービスを参照するコンポジットをデプロイするには、binding.ws要素の属性を次に示すように入力する必要があります。
<binding.ws port="[WSDLで定義されたABCS拡張サービスのネームスペース]/V1#wsdl.endpoint(<WSDLで指定されたABCSサービスの名前>/<WSDLで指定されたポートタイプの名前>" location="[MDSでの具象WSDLの場所]" xmlns:ns="http://xmlns.oracle.com/sca/1.0"/>
ABCSサービスの名前は、抽象WSDLのdefinitions/name属性の値です。
これは、ABCSコンポジットのサービス名に対する命名規則に従います。命名規則に従って、サービスの名前は<コンポジットの名前>になるため、これはWSDLのdefinitions要素のname属性の値です。
顧客は、拡張ポイントにおけるサービスを開発およびデプロイする時点で、次のことができます。
顧客は、MDS内のサンプル具象WSDLを、拡張サービス用に開発された具象WSDLに置き換えて、ABCSを再デプロイできます。
顧客は、デプロイされたサービスの具象WSDLをポイントするようにbinding.ws.locationを変更し、ABCSを再デプロイできます。
詳細は、「AIAでのMDSの使用」を参照してください。
次の項では、一方向呼出しコールを使用するリクエスタABCSに拡張ポイントを提供するためのステップを説明します。
サービスへのリクエストのみのコールを使用するリクエスタABCSには、2つの拡張ポイントが存在できます。1番目の拡張ポイントはABMからEBMへの変換の直前で、2番目の拡張ポイントはサービスの呼出しの直前です。これらの拡張ポイントにおけるサービス操作は、それぞれPre-ProcessABMおよびPre-ProcessEBMとして定義されます。拡張ポイントにおけるサービス操作は、ペイロードを返すのみのサーブレットの呼出しです。
リクエスタABCSには、指定した順序による次のプロセス・アクティビティが必要です。
Switch
Switchアクティビティは、拡張ポイントにおけるサービス呼出しを実行するかどうかを決定します。これを行うには、AIAConfigurationProperties.xmlファイルにあるプロパティ変数の値を確認します。構成パラメータの名前はABCSExtension.PreProcessABMです。このパラメータの値がtrueであることを確認します。これを行うには、switch式で適切なAIAXPathFunctionを使用します。
Assign-Invoke-Assign
プロセス・アクティビティのAssign-Invoke-AssignサブシーケンスはSwitchアクティビティに埋め込まれています。
Assign
Assignアクティビティは、receiveステップの入力変数の値を、後続のinvokeステップの入力変数に割り当てます。
Invoke
Invokeアクティビティは、パートナ・リンクでサービス・コールを実行します。ABCS拡張ポイントのプログラミング・モデルでは、受信したのと同じペイロードを返すコントラクトをサービスに設定します。
Assign
Assignアクティビティは、サービス呼出しからのレスポンス・ペイロードの値を、後続のプロセス・アクティビティの変数に割り当てます。
図8-7にシーケンスを示します。
図8-7 拡張ポイントPre-ProcessABMの設定
リクエスタABCSには、指定した順序による次のプロセス・アクティビティが必要です。
図8-8 拡張ポイントPre-process EBMの設定
ドキュメントで使用されるサンプル拡張サービスは、入力ペイロードをミラー化するJavaサーブレットです。例8-2に示すように、エンドポイントとしてのサーブレットは、パートナ・リンク・サービスとして使用して拡張をテストできるという利点があります。これは、抽象WSDLを使用してPartnerLinkサービスを定義する拡張対応ABCSをテストする場合に役立ちます。
メソッドPreProcessABMの実装は必要ありません。SOAPリクエストはサーブレット・ペイロードとして扱われ、サーブレットはペイロード全体を出力して戻します。また、SOAPAction要素はサーブレット側で使用されないため、ダミーがレンダリングされます。
テスト・サーブレットは、Mirror.javaという名前のJavaファイルです。デプロイされると、http://[hostname].com:[portno]/Mirror/mirrorから入手できます。
例8-2 拡張をテストするサーブレット
<service name="CreateCustomerSiebelReqABCSImplExt">
<port name="CreateCustomerSiebelReqABCSImplExt"
binding="tns:CreateCustomerSiebelReqABCSImplExt_Binding">
<soap:address
location="http://{host}:{port}/MirrorServlet/mirror"/>
</port>
</service>
参加アプリケーションがフォルトを処理して渡す方法を決定するには、アプリケーションのエラー処理機能が統合プラットフォームのエラー処理機能と一致していることを確認する必要があります。
同期リクエスト/レスポンス・メッセージ交換パターン(MEP)では、要求側サービスはレスポンスを待機します。
プロバイダ・サービスでエラーが発生するたびに、例外が発生し、フォルト・メッセージが要求側サービスに伝播されます。
非同期ファイア・アンド・フォーゲットMEPでは、要求側サービスはレスポンスを待機しません。
提供側サービスでエラーが発生すると、補正が必要になる場合があります。このような場合、EBSでの補正操作を使用して補正をトリガーする必要があります。
非同期リクエスト/遅延レスポンスMEPでは、要求側サービスは一時停止モードになり、レスポンスを待機します。
提供側サービスでエラーが発生すると、要求側サービスへのレスポンスにエラーに関する詳細が含まれます。
このシナリオでのABCSおよびEBSサービスの実装の詳細は、「非同期リクエスト/遅延レスポンスMEPの実装」を参照してください。
各MEPにおけるBPELおよびMediatorプロセスでのエラー処理の実装の詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。
非同期MEPでは、送信側から開始されたメッセージは、正常に配信されて受信側で確認(確認が必要な場合)されるまで保持されます。
送信側と受信側は必ずしも参加アプリケーションである必要はありません。むしろ、これらはOracle AIA統合シナリオの論理的なマイルストンになります。各永続ストアはマイルストンを表し、データベース、ファイル・システムまたはJMS永続である場合があります。永続ポイント間でメッセージを移動できるように、統合シナリオに複数のマイルストンを構成できます。
統合フローにおける保証付きメッセージ配信のマイルストンの構成については、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。
この項では、トランスポート・アダプタおよびバージョン・アダプタの使用について説明します。
この項には次のトピックが含まれます:
これらのシナリオでは、トランスポート・アダプタを使用してABCSとインタフェースします。
Siebel、PeopleSoft、J.D. Edwards、SAPなどのパッケージ化されたアプリケーションでは、パッケージ化された各アプリケーションのアダプタを使用するルートが優先されます。これらのアダプタは、JCAリソース・アダプタとしてデプロイできます。従来のSOAPインタフェースを使用するよりも、この方法をお薦めします。
参加アプリケーションがビジネス・ロジックをWebサービスとして公開していない場合、これらのアプリケーションとの相互作用では、データベース・アダプタ、JMSアダプタなどのテクノロジ・アダプタを使用する必要があります。
トランスポート・アダプタを使用すると、当初はWebサービス・テクノロジを使用するように開発されなかったシステム/アプリケーションとの接続が可能になります。次に、アダプタを使用できるアプリケーションの例を示します。
通信にxmlを使用しないシステム
パッケージ化されたソフトウェア
データベース・システム
データソース、永続ストア(例: JMS)など
参加アプリケーションによって公開されたサービスが専用のメッセージ書式、テクノロジおよび標準をサポートしているかどうかを調べてください。機能を実装するアプリケーションが標準およびテクノロジ(XML、SOAP、JMSなど)を固有にサポートしていない場合は、ABCSで変換を実行する必要があります。
たとえば、アプリケーションはファイルのみを使用してメッセージを送受信でき、認識できる形式はEDIのみであるとします。この場合、ABCSでは、ファイル・アダプタを使用し、EDIベースのメッセージをXML形式に変換して、そのメッセージをSOAPメッセージとして公開するアプリケーションとの統合を行う必要があります。
メッセージ集約用のアダプタを使用する場合
場合によっては、複数のソースから発生した複数のレスポンスを1つのリクエストに結合する必要があります。たとえば、通信ソリューションにおける一括請求の場合、getBillDetails EBSのアプリケーション・ビジネス・コネクタ・サービスは、複数の参加アプリケーションから詳細を取得する必要があります。
メッセージ集約の設計パターンの詳細は、「AIA設計パターンの使用」を参照してください。
イベント集約用のアダプタを使用する場合
イベント集約モデルによって、イベント、エンティティまたはメッセージの集約が必要なビジネス・ユースケースで使用できる包括的な方法が提供されます。このようなシナリオでは、ビジネス・メッセージが完了する前に複数のイベントが発生し、これらの粒度が細かいメッセージ・イベントすべてが粒度の粗い1つのイベントに統合されます。
このようなユースケースでは、イベント・コンシューマ・アダプタ・サービスによってリクエスタABCSが呼び出され、集約されたイベント・メッセージがリクエスタABCSに提供されます。
イベント集約の設計パターンの詳細は、「AIA設計パターンの使用」を参照してください。
ここでは、ABCS側の観点から高度なステップを示します。
JMSコンシューマ・アダプタを開発する手順は、次のとおりです。
JMSアダプタの詳細は、『Oracle WebLogic Server JMSリソースの管理』を参照してください。
ポータルDBアダプタを開発する手順は、次のとおりです。
BPELコンポーネントを「コンポーネント」スイムレーンに追加します。
DBアダプタを外部参照サービスとして「参照」スイムレーンに追加します。
アダプタ構成ウィザードを使用して、アダプタ・サービスを構成します。
BPELコンポーネントをdbアダプタ・サービスに接続します。
BPELコンポーネントを設計モードで開き、dbアダプタ・パートナ・リンクを呼び出すinvokeアクティビティを追加します。
BPELプロセスのコーディングを完了します。
原則として、ABCSコンポジットは他のコンポーネントとともに実装された1つのコンポーネントで、これらのコンポーネント間を接続します。たとえば、次を使用するリクエスタABCSコンポジットを実装できます。
ABCSプロセス・フローを表すBPELプロセス・コンポーネント。
プロセス・コンポーネントで使用または必要なアダプタを表すBPELまたはメディエータ・ベースのアダプタ・コンポーネント。
プロセス・コンポーネントとアダプタ・コンポーネントの両方(これらが定義されたコンポジットのサービスとして使用されます)。
ABCSとTransportAdapterサービスは同じコンポジット内に存在でき、その場合のコンポジット名はABCSのコンポジット名と同じです。または、ABCSサービスとTransportAdapterサービスを別々のコンポジットとして開発することもできます。
同じトランスポート・アダプタ・サービスが複数のABCSで使用可能な場合、ABCSとインタフェースするアダプタはABCSのコンポジットとは異なるコンポジットに配置することをお薦めします。
サービス・プロバイダが新バージョンのアプリケーション・サービスをリリースすると、コンシューマ・コードを移行するときに複数のバージョンを同時に実行する必要があります。
バージョン・アダプタを使用すると、クライアントのリクエストとレスポンスで異なるリリースのサービスを使用でき、コンテンツに基づいてリクエストを適切なサービス・エンドポイントにルーティングできます。
例:
アセットの場合、統合で使用されるビュー定義は、Oracle 11.5.10とR12で異なります。
支払認可の場合、API名はOracle 11.5.10とR12で異なります。
異なるバージョンのアプリケーション間でこれらを変更するには、アプリケーション・バージョンごとに新しいアダプタ・サービスを作成する必要があります。
異なるバージョンのアプリケーション間で変更が頻繁に行われない場合は、図8-9に示すように、メディエータ・コンポーネントに基づいて、既存のコネクタ・サービスとプロバイダ・アプリケーションの間にバージョン・アダプタを導入します。
図8-9 バージョン・アダプタの導入
この方法によって、コネクタ・サービスはアプリケーションのバージョンに依存しないままです。このオプションは、変換が不要な場合、バージョン・アダプタでの入出力変換が単純でパフォーマンスに影響する拡張ロジックが含まれない場合に、検討する必要があります。
バージョン・アダプタを構成する手順は、次のとおりです。
バージョン・アダプタ・サービスは、プロバイダABCS実装サービスと実際の参加アプリケーションの間に存在する、メディエータ・ベースのコンポーネントです。
メディエータ・ベースのバージョン・アダプタ・サービスには、すべてのアプリケーション・アダプタへの参照が必要です。
この項では、コンポジット・アプリケーション検証システム(CAVS)を使用できるOracle AIAサービスの開発方法を説明します。この項には次のトピックが含まれます:
ヒント:
CAVS構成が必要なのは、シミュレータがテスト・シナリオに含まれている場合のみです。これらの構成によって、サービスがメッセージをシミュレータにルーティングするための基盤が構築されます。
CAVSの使用の詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのコンポジット・アプリケーション検証システムの概要に関する項を参照してください。
非同期でResponseEBSサービスへのコールバックを呼び出すプロバイダABCSは、その呼出しもCAVS対応にする必要があります。
開発者は、後述するように、Routing.<PartnerLinkName>.<TargetSystemID>.EndpointURIプロパティの値を入力する必要があります。
Routing.<PartnerLink>.RouteToCAVSプロパティの値がfalseに設定されている場合は、前述のプロパティをサービス構成ファイルに設定する必要があります。
CAVS対応の動的なPartnerLinkでターゲット参加アプリケーションのWebサービスを呼び出すように、プロバイダABCSをコーディングする手順は、次のとおりです。
例8-3に示すように、プロバイダABCSに対して次のサービス・レベル構成プロパティを定義します。
CAVSEndPointURL値は設計時に設定されます。
CAVSEndPointURLの設計時の設定については、「CAVSEndpointURL値設定の概要」を参照してください。
例8-4に示すように、BPELプロセスに次のネームスペース接頭辞が定義されていることを確認します。
この変数をグローバル変数セクションに追加します。
<variable name="SystemID" type="xsd:string"/>
AddTargetSystemID.xslという名前の添付ファイルをBPELプロセスの「xsl」ディレクトリに追加します。ファイル内の[ABCServiceNamespace]および[ABCServiceName]トークンが適切に置換されていることを確認します。
例8-5に示すように、BPELプロセスの最初のステップとして割当を追加します。トークンが適切に置換されていることを確認します。
例8-6に示すように、各PartnerLinkのinvokeアクティビティの前に、次の<scope>を1回追加します。
AssignDynamicPartnerlinkVariables割当アクティビティのトークンを置換して、変数を適切に設定します。
AssignPartnerlinkEndpointReference割当アクティビティのPartnerLink nameトークンを更新します。
埋込みのJavaコードの更新は不要です。
例8-3 プロバイダABCSに対するサービス・レベル構成プロパティの定義
<Property name="Default.SystemID">[DefaultTargetSystemID]</Property> <Property name="Routing.[PartnerlinkName].RouteToCAVS">[true|false]</Property> <Property name="Routing.[PartnerlinkName].[TargetSystemID].EndpointURI">[AppEndpointURL]< /Property> <Property name="Routing.[PartnerlinkName].CAVS.EndpointURI">[CAVSEndpointURL]</Property>
例8-4 BPELプロセスでのネームスペース接頭辞の定義
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa=http://schemas.xmlsoap.org/ws/2003/03/addressing xmlns:corecom=http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2
例8-5 割当の追加
<assign name="GetTargetSystemID">
<copy>
<from expression="ora:processXSLT('AddTargetSystemID.xsl',
bpws:getVariableData('[RequestEBMVariableName]', '[RequestEBMPartName]'))"/>
<to variable="[RequestEBMVariableName]"
part="[RequestEBMPartName]"/>
</copy>
<copy>
<from variable="[RequestEBMVariableName]"
part="[RequestEBMPartName]"
query="/[NamespacePrefixedEBMName]/corecom:EBMHeader/corecom:
Target/corecom:ID"/>
<to variable="SystemID"/>
</copy>
</assign>
例8-6 各PartnerLinkに対する追加
<scope name="SetDynamicPartnerlinkScope">
<variables>
<variable name="TargetEndpointLocation" type="xsd:string"/>
<variable name="EndpointReference" element="wsa:EndpointReference"/>
<variable name="ServiceName" type="xsd:string"/>
<variable name="PartnerLinkName" type="xsd:string"/>
<variable name="EBMMsgBpelVariableName" type="xsd:string"/>
<variable name="EBMMsgPartName" type="xsd:string"/>
</variables>
<sequence name="SetDynamicPartnerlinkSequence">
<assign name="AssignDynamicPartnerlinkVariables">
<copy>
<from expression="'{[ABCServiceNamespace]}[ABCServiceName]
'"/>
<to variable="ServiceName"/>
</copy>
<copy>
<from expression="'[PartnerlinkName]'"/>
<to variable="PartnerLinkName"/>
</copy>
<copy>
<from expression="'[RequestEBMVariableName]'"/>
<to variable="EBMMsgBpelVariableName"/>
</copy>
<copy>
<from expression="'[RequestEBMPartName]'"/>
<to variable="EBMMsgPartName"/>
</copy>
</assign>
<bpelx:exec name="GetTargetEndpointLocation" language="java"
version="1.5">
<![CDATA[/*------------------------------------------------------
This code snippet will derive the dynamic endpoint URI for a partnerlink.
-----------------------------------------------------------------*/
java.lang.String serviceName = (java.lang.String)getVariableData("ServiceName");
java.lang.String partnerLinkName = (java.lang.String)getVariableData("PartnerLinkName");
java.lang.String cavsEndpointPropertyName =
"Routing."+partnerLinkName+".CAVS.EndpointURI";
java.lang.String ebmMsgBpelVariableName = (java.lang.String)getVariableData("EBMMsgBpelVariableName");
java.lang.String ebmMsgPartName =
(java.lang.String)getVariableData("EBMMsgPartName");
java.lang.String systemIdBpelVariableName = "SystemID";
java.lang.String targetEndpointLocationBpelVariableName =
"TargetEndpointLocation";
java.lang.String routeToCavsPropertyName =
"Routing."+partnerLinkName+".RouteToCAVS";
java.lang.String defaultSystemIdPropertyName = "Default.SystemID";
java.lang.String targetEndpointLocation = null;
java.lang.String targetID = null;
boolean addAudits = false;
if (addAudits) addAuditTrailEntry("Partnerlink = " + partnerLinkName);
// check configuration for CAVS routing flag
try {
boolean routeToCAVS =
java.lang.Boolean.parseBoolean(oracle.apps.aia.core.config.Configuration.
getServiceProperty(serviceName, routeToCavsPropertyName));
if (addAudits) addAuditTrailEntry("RouteToCAVS = " + routeToCAVS);
if (routeToCAVS) {
targetEndpointLocation = oracle.apps.aia.core.config.Configuration.
getServiceProperty(serviceName, cavsEndpointPropertyName);
if (addAudits) addAuditTrailEntry("Endpoint = '" + targetEndpoint
Location + "' selected from configuration property " +
cavsEndpointPropertyName);
}
}
catch (oracle.apps.aia.core.config.PropertyNotFoundException e) {
if (addAudits) addAuditTrailEntry("Configuration property " + cavs
EndpointPropertyName + " not found!");
}
if (targetEndpointLocation==null || targetEndpointLocation=="") {
// check bpel variable for already retrieved target system Id
try {
targetID = (java.lang.String)getVariableData(systemIdBpel
VariableName);
if (addAudits && targetID!=null) addAuditTrailEntry("Using previously
stored Target System ID = '" + targetID + "'");
}
catch (com.oracle.bpel.client.BPELFault e) {
}
if (targetID==null || targetID=="") {
// try to get Target system ID from EBM Header
try {
oracle.xml.parser.v2.XMLElement targetIdElement =
(oracle.xml.parser.v2.XMLElement)
getVariableData(ebmMsgBpelVariableName,
ebmMsgPartName, "/*/corecom:EBMHeader[1]/corecom:Target/corecom:ID
[text()!='']");
targetID = targetIdElement.getText();
if (addAudits) addAuditTrailEntry("Target System ID = '" + targetID
+ "', selected from EBM header");
}
catch (com.oracle.bpel.client.BPELFault e) {
if (addAudits) addAuditTrailEntry("Unable to retrieve Target System
ID from message header");
}
try {
if (targetID!=null && targetID!="")
setVariableData(systemIdBpelVariableName, targetID);
}
catch (com.oracle.bpel.client.BPELFault e) {
}
}
if (targetID==null || targetID=="") {
// try to get Target system ID from configuration
try {
targetID = oracle.apps.aia.core.config.Configuration.getService
Property(serviceName, defaultSystemIdPropertyName);
if (addAudits) addAuditTrailEntry("Target System ID = '" + targetID
+ "', selected from configuration property " + defaultSystemIdPropertyName);
}
catch (oracle.apps.aia.core.config.PropertyNotFoundException e) {
if (addAudits) addAuditTrailEntry("Configuration property "
+ defaultSystemIdPropertyName + " not found!");
}
try {
if (targetID!=null && targetID!="") setVariableData(systemIdBpel
VariableName, targetID);
}
catch (com.oracle.bpel.client.BPELFault e) {
}
}
if (targetID!=null || targetID!="") {
// try to get EndpointLocation from Configuration
java.lang.String endpointPropertyName = "Routing."+partnerLinkName+
"."+targetID+".EndpointURI";
try {
targetEndpointLocation =
oracle.apps.aia.core.config.Configuration.getServiceProperty(serviceName,
endpointPropertyName);
if (addAudits) addAuditTrailEntry("Endpoint = '" +
targetEndpointLocation + "' selected from configuration property " +
endpointPropertyName);
}
catch (oracle.apps.aia.core.config.PropertyNotFoundException e) {
if (addAudits) addAuditTrailEntry("Configuration property " +
endpointPropertyName + " not found!");
}
}
}
try {
setVariableData(targetEndpointLocationBpelVariableName, targetEndpoint
Location);
}
catch (com.oracle.bpel.client.BPELFault e) {
}]]>
</bpelx:exec>
<switch name="Switch_SetEndpoint">
<case condition="string-length(bpws:getVariableData('Target
EndpointLocation'))>0">
<assign name="AssignPartnerlinkEndpointReference">
<copy>
<from>
<wsa:EndpointReference xmlns:wsa="http://schemas.
xmlsoap.org/ws/2003/03/addressing">
<wsa:Address/>
</wsa:EndpointReference>
</from>
<to variable="EndpointReference"/>
</copy>
<copy>
<from variable="TargetEndpointLocation"/>
<to variable="EndpointReference"
query="/wsa:EndpointReference/wsa:Address"/>
</copy>
<copy>
<from variable="EndpointReference"/>
<to partnerLink="[PartnerlinkName]"/>
</copy>
</assign>
</case>
<otherwise>
<empty name="Empty_NoSetEndpoint"/>
</otherwise>
</switch>
</sequence>
</scope>
プロバイダABCSでエンドポイントURIを動的に計算して動的なターゲット呼出しを実現する方法は、汎用プログラミング・モデルの概念に似ています。
メディエータ・サービスとして実装されるエンタープライズ・ビジネス・サービスのCAVS対応呼出しを行うように、リクエスタABCSをコーディングする手順は、次のとおりです。
例8-7 wsa:EndpointReference要素の入力
<switch name="Switch_CAVSEnablement">
<case condition="string-length(bpws:getVariableData('CreateCustomerPartyList_
InputVariable','CreateCustomerPartyListEBM','/custpartyebo:CreateCustomerPartyLis
tEBM/corecom:EBMHeader/corecom:MessageProcessingInstruction/corecom:DefinitionID'
))>0">
<bpelx:annotation>
<bpelx:pattern>Is_CAVS_DefinitionID</bpelx:pattern>
</bpelx:annotation>
<sequence>
<assign name="Assign_TargetEndpointLocation">
<copy>
<from variable="CreateCustomerPartyList_
InputVariable"
part="CreateCustomerPartyListEBM"
query="/
corepartyebo:CreateCustomerPartyListEBM/corecom:EBMHeader/corecom:Message
ProcessingInstruction/corecom:DefinitionID"/>
<to variable="TargetEndpointLocation"/>
</copy>
</assign>
<assign name="AssignPartnerlinkEndpointReference">
<copy>
<from>
<wsa:EndpointReference>
<wsa:Address/>
</wsa:EndpointReference>
</from>
<to variable="EndpointReference"/>
</copy>
<copy>
<from variable="TargetEndpointLocation"/>
<to variable="EndpointReference"
query="/wsa:EndpointReference/wsa:Address"/>
</copy>
<copy>
<from variable="EndpointReference"/>
<to partnerLink="SamplesCustomerPartyEBS"/>
</copy>
</assign>
</sequence>
</case>
<otherwise> <empty name="Empty_NoSetEndpoint"/> </otherwise>
</switch>
CAVSEndPointURL値は、次のように設計時に設定されます。
ABCSまたはエンタープライズ・ビジネス・フロー(EBF)が同期サービスを呼び出す場合、AIAConfigurationProperties.xmlファイルのCAVSEndPointURL値はデフォルト値のhttp://<host>:<port>/AIAValidationSystemServlet/syncresponsesimulatorに設定されます。
ABCSまたはEBFが非同期一方向サービスを呼び出す場合、AIAConfigurationProperties.xmlファイルのCAVSEndPointURL値はデフォルト値のhttp://<host>:<port>/AIAValidationSystemServlet/asyncrequestrecipientに設定されます。
ABCSまたはEBFが非同期リクエスト/遅延レスポンス・サービスを呼び出す場合、AIAConfigurationProperties.xmlファイルのCAVSEndPointURL値はデフォルト値のhttp://<host>:<port>/AIAValidationSystemServlet/asyncresponsesimulatorに設定されます。
ABCSまたはEBFがレスポンスEBSを呼び出す場合、AIAConfigurationProperties.xmlファイルのCAVSEndPointURL値はデフォルト値のhttp://<host>:<port>/AIAValidationSystemServlet/asyncresponserecipientに設定されます。
参加アプリケーションがCAVSテスト・フローに含まれている場合、テストを実行すると参加アプリケーションのデータが変更される可能性があります。したがって、同じテストを連続して実行しても、同じ結果が生成されない場合があります。CAVSは、フローに実際の参加アプリケーションを含めるというユーザーの目的をサポートするため、このようなデータ改ざんを防ぐように設計されていません。CAVSは、参加アプリケーションで実行される変更を制御できません。
ただし、CAVSのテスト・シナリオでテスト定義とシミュレータ定義を使用して、すべての参加アプリケーションおよびその他の依存性を置換する場合、この問題は該当しません。この場合、テスト・シナリオが実行された後に、すべての相互参照データがパージされます。これによって、テスト・シナリオの再実行が可能になります。
このパージは次のようにして行います。
図8-10 「システム」-「アプリケーション・レジストリ」ページのシステムおよびCAVS関連エントリ
各参加アプリケーションは、異なる時期に、異なるコンセプト、異なる認証および認可の実装を使用して開発されています。アプリケーションが統合される場合は、アプリケーション間で認証および認可情報を渡す必要があります。
セキュリティに関連する情報は、参加アプリケーションとABCSの間で交換されます。AIAアプリケーション・セキュリティ・コンテキストによって、様々なアプリケーション間における参加アプリケーションの認証および認可情報の交換が標準化されるため、すべてのアプリケーションを他のアプリケーションと統合できます。
次の質問に回答する必要があります。
アプリケーションでは認証にセキュリティ資格証明が必要か。
Yesの場合、汎用アカウントを使用できるか、またはメッセージに指定されているリクエスタの資格証明を使用する必要があるか。
これらの資格証明をどのように転送するか。WS-Securityスキームまたはカスタム・メカニズムを採用しているか。
カスタム・メカニズムの場合、ヘッダーを経由するか、またはペイロードの一部か。
次の方法の詳細は、「セキュリティに関する作業」を参照してください。
アプリケーション・セキュリティ・コンテキストをABCSの標準形式に変換する。
標準セキュリティ・コンテキストをEBSおよびEBFを介してABCSからABCSに伝播する。
標準セキュリティ・コンテキストをアプリケーション・セキュリティ・コンテキストに変換する。
SOAを使用してエンタープライズ間ワークフローをカプセル化して統合すると、複数のサービスがシステム境界を超えてトランザクションに参加できます。アプリケーション境界を超えるエンドツーエンド・ビジネス・トランザクションには、複数のアプリケーションが含まれます。強力な統合ソリューションを作成するには、単純なメッセージ交換では不十分です。
エンドツーエンド・メッセージ・フローに参加するWebサービスの多くが、非同期、ステートレス、分散および不透明であることは、重要な考慮事項です。トランザクション管理の方法を理解する必要があります。
ビジネス要件によってトランザクション要件が決まります。トランザクションの検討は設計フェーズから開始する必要があります。これを作成時まで遅らせることはできません。次のことを実行する必要があります。
ビジネス・アクティビティを構成するすべてのABCSサービスおよびEBFを識別します。
これらのアクティビティを、全体的に統一された目的を持つ意味のあるグループに編成します。
トランザクション境界ポイントを指定します。
アクティビティをグループ化すると、トランザクション境界の開始ポイントが判明するため、関連するビジネス操作がトランザクションのコンテキストで実行されます。
マイルストンが構成されない非同期ファイア・アンド・フォーゲット・パターンでは、Oracle XAの相互参照を含む同一のグローバル・トランザクションに、リクエスタ、EBSおよびプロバイダABCSが参加する必要があります。
JMSキューが設定され、参加アプリケーションがキューと相互作用する非同期MEPでは、リクエスタABCS、EBSおよびプロバイダABCSと同様に、JMSコンシューマ・アダプタもグローバル・トランザクションに参加する必要があります。
このような場合、メッセージがマイルストンに保持される前に実行中のトランザクションが中断されると、そのメッセージはJMSキューにロールバックされます。
つまり、トランザクション境界は、JMSコンシューマ・アダプタがメッセージをキューから取得すると開始され、メッセージがコンシューマ・アプリケーションに配信されるか、構成されたマイルストンにメッセージが保持された時点で終了します。
SOAベースの統合では、長時間かかるビジネス・トランザクションの多くに、非互換の信頼できるドメイン、非同時性、および非アクティブ期間が含まれ、これは、従来のACIDスタイルのトランザクション処理に関する課題です。技術上またはビジネス上の基準に基づいて、トランザクション境界を事前定義する必要があります。事前作成済の統合の設計者/アーキテクトは、論理ポイントでJMSインタフェースを使用してトランザクション境界を設定することによって、トランザクション全体を複数の部分に分割する必要があります。
再試行不可のアプリケーション・サービスには、対応する補正サービスが必要です。
再試行不可のアプリケーション・サービスを呼び出すABCSは、ロールバックの場合に補正サービスを呼び出す必要があります。
JCAアダプタを使用して実装されたアプリケーション・サービスは、セッション管理を使用するとトランザクション調整が容易になります。
トランザクションが存在する場合、Oracle Mediatorは既存のトランザクションに参加します。トランザクションが存在しない場合、Oracle Mediatorはトランザクションを開始します。連続したルーティング・ルールの場合、すべてのルールは同じトランザクションで実行され、エラーが発生するとロールバックが発行されます。
BPELコンポーネントは、デフォルトで、リクエストに基づいて新規トランザクションを作成します。つまり、BPELプロセスが呼び出されると、デフォルトで新規トランザクションが開始します。トランザクションが存在する場合、そのトランザクションは一時停止して、新規トランザクションが作成されます。実行を単一のグローバル・トランザクションに連鎖するには、プロバイダ・プロセス(コール先BPELコンポーネント)でトランザクション・フラグを設定する必要があります。
BPELエンジンは、フローの最後に到達したとき、またはブレークポイント・アクティビティ(receive、onMessage、onWait、Alarmなど)がヒットしたときに、ローカル・トランザクションを終了します。
トランザクション設計では、次の事項も考慮する必要があります。
AIA統合で採用されている呼出しパターン
ABCS -- EBS - ABCS
テクノロジ・パターン: BPEL -- MEDIATOR-BPEL
ABCS - EBS - EBF - EBS -- ABCS
テクノロジ・パターン: BPEL - MEDIATOR- BPEL - MEDIATOR- BPEL
FMWでのトランザクション・セマンティクスに基づいて、ABCS、EBSおよびエンタープライズ・ビジネス・フロー間でトランザクションを設計および構成する必要があります。
参加アプリケーション
参加アプリケーションは、アプリケーション・サービスを使用してトランザクションをサポートできる必要があります。ただし、実際に多くのアプリケーション・サービスがこれを実行できるため、ロールバックに備えて補正サービスが必要です(AIAレイヤーで編成)。
参加アプリケーション・サービス、SCAコンポジット・トランザクション・セマンティクスおよびビジネス要件の特性に特に対応するために、統合ロジックおよびトランザクション境界をAIAレイヤーに設計します。
SOA 11gでは、実行を単一のグローバル・トランザクションに連鎖するために、コール元(使用)プロセスで構成プロパティを設定する必要はありません。
コール先BPELコンポーネントで適切なトランザクション・フラグのみ設定する必要があります。これを行うには、例8-8に示すように、コンポジット・エディタのソースで、値をrequiredに指定したbpel.config.transactionをBPELコンポーネントに追加します。
このようにトランザクション・フラグを設定すると、BPELは親プロセスによって開始されるトランザクションを継承します。親プロセスがトランザクションを開始しなかった場合、BPELは新規トランザクションを作成します。グローバル・トランザクションの場合は、イニシエータがコミットするとトランザクションもコミットされます。
BPELにアダプタとのインバウンド・インタフェースがある場合は、アダプタのコンポジットで適切なトランザクション・フラグを設定する必要があります。
例8-9に、BPELアダプタ・インタフェースにトランザクション・プロパティを設定する方法を示します。
メディエータを呼び出すBPELでは、トランザクションが存在する場合、メディエータは既存のトランザクションに参加します。トランザクションが存在しない場合、メディエータはトランザクションを開始します。
例8-8 wsa:EndpointReference要素の入力
<component name="SamplesCreateCustomerSiebelReqABCSImplProcess">
<implementation.bpel
src="SamplesCreateCustomerSiebelReqABCSImplProcess.bpel"/>
<property name="bpel.config.transaction">required</property>
</component>
例8-9 PELエンドポイント要素の入力
<component name="SamplesCreateCustomerSiebelJMSConsumerProcess">
<implementation.bpel
src="SamplesCreateCustomerSiebelJMSConsumerProcess.bpel"/>
<property name="bpel.config.transaction">required</property>
</component>
次の各項では、様々なシナリオでAIAサービスをトランザクション対応にする方法を説明します。
同期BPELプロセスを呼び出すと、デフォルトで、ローカル・トランザクション内にBPELインスタンスが作成されます。このトランザクションは、適切に構成してグローバル・トランザクションに登録できます。
したがって、ABCSサービスでのトランザクション設定は例8-10に示すようになります。
この設定によって、コール元のトランザクションが存在する場合は結合され、存在しない場合は新規トランザクションが作成されます。EBSは、リクエスタABCSによって開始されたトランザクションを継承します。
メディエータは常に、受信メッセージを処理しているスレッドを介して伝播されたグローバル・トランザクションにメディエータ自体を登録します。
図8-11に、トランザクション境界を示します。
図8-11 トランザクション境界
例8-10 非同期MEPでのトランザクション設定
<component name="SamplesCreateCustomerSiebelJMSConsumerProcess">
<implementation.bpel
src="SamplesCreateCustomerSiebelReqABCSImplProcess.bpel"/>
<property name="bpel.config.transaction">required</property>
</component>
非同期BPELプロセスを呼び出すと、コール元のトランザクション内にある呼出しメッセージ表に呼出しメッセージが保持されます。コール元のトランザクションは終了します。非同期BPELは、独自のローカル・トランザクションで実行されます。コール先がコール元のトランザクション内で実行される場合、次に示すように、コール先のコンポジットでBPELコンポーネントのトランザクション・フラグをrequiredに設定する必要があります。
bpel.config.transaction=required
一方向操作の場合にコール先のシングル・スレッド実行を行うには、syncタイプのコールが必要です。次に示すように、コール先のコンポジットでBPELコンポーネントのプロパティを設定します。
bpel.config.oneWayDeliveryPolicy=sync
したがって、ABCSサービスでのトランザクション設定は例8-11に示すようになります。
リクエスタABCSにアダプタとのインバウンド・インタフェースがある場合は、アダプタのコンポジットで、bpel.config.oneWayDeliveryPolicy=syncのようにBPELコンポーネント・レベルでプロパティを設定します。
例8-12に、アダプタ・コンポーネントでトランザクション・プロパティを設定する方法を示します。
図8-12に、トランザクション境界を示します。
図8-12 非同期MEPでのトランザクション境界
例8-11 非同期MEPでのトランザクション設定
<component name="SamplesCreateCustomerSiebelReqABCSImplProcess">
<implementation.bpel
src="SamplesCreateCustomerSiebelReqABCSImplProcess.bpel"/>
<property name="bpel.config.transaction">required</property>
<property name=bpel.config.oneWayDeliveryPolicy">sync</property>
例8-12 アダプタ・コンポーネントで設定するトランザクション・プロパティ
<component name="SamplesCreateCustomerSiebelJMSConsumerProcess">
<implementation.bpel
src="SamplesCreateCustomerSiebelJMSConsumerProcess.bpel"/>
<property name="bpel.config.transaction">required</property>
<property name=bpel.config.oneWayDeliveryPolicy">sync</property>
</component>
ABCSがプロセスで非同期操作を呼び出す必要があり、ABCSと同じスレッド内だが異なるトランザクション内でその操作を実行する必要がある場合は、コール先BPELコンポジットで次の構成を設定します。
<property name="bpel.config.oneWayDeliveryPolicy">sync</property>
この場合、コール先BPELはコール元とは異なるトランザクションで実行されるため、コール先BPELコンポジットでトランザクション構成bpel.config.transactionを設定する必要はありません。
保証付きメッセージ配信とは、エラーが発生した場合でも、プロデューサからコンシューマに送信されるメッセージが失われないことを意味します。
AIAでは、非同期で信頼できるメッセージ配信のためにキューを使用します。次に例を示します
PeopleSoft CRMは、ビジネス・イベントが発生すると、メッセージをキューに直接プッシュするか、またはキューにメッセージを入れるJMSメッセージ・プロデューサ(JMSトランスポート・アダプタ)にSOAPメッセージをHTTP経由で送信できます。
PeopleSoft CRMは、メッセージがキューに入るのと同時に、そのメッセージを送信済とみなします。このメカニズムを使用して、PeopleSoft CRMアプリケーションは、CRMオンプレミスが使用可能かどうかに関係なく、新規メッセージを継続して送信できます。
JMSコンシューマ(もう1つのJMSトランスポート・アダプタ)は、メッセージをデキューして、PeopleSoft CRM ABCSを呼び出します。
PeopleSoft CRM ABCSを使用すると、EBS、CRMオンプレミスABCS、JMSメッセージ・プロデューサによって開始されたトランザクションに含まれるWebサービスでは、CRMオンプレミス・アプリケーションでタスクが正常に完了した後にのみメッセージがキューから削除されます。
サービスのバージョニングとは次の意味です。
コンポジットの名前およびサービス・コンポーネントの名前にバージョン接尾辞がある新規サービス。
サービス・コンポーネントのWSDLのターゲット・ネームスペースは、新しいバージョンを示します。
AIAネーミング標準の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。
準備フェーズでは、次のガイドラインに注意してください。
1つのABCSが事前作成済の複数の統合間で使用されます。事前作成済の統合に固有ではありません。
たとえば、EBizRequesterCreateItemABCSは、ISCM事前作成済の統合およびAgile PLM - Ebiz統合の事前作成済の統合で使用されます。
Oracle Enterprise Repositoryを使用して、サービスの存在を調べます。
サービス定義注釈はOracle Enterprise Repositoryに保持されます。Oracle Enterprise Repositoryは、事前作成済の統合を表してサービスを構成する、概念的および物理的な様々なアセットを文書化します。
バージョン接尾辞を変更せずにABCSに加えるインライン変更は、下位互換性が必要です。
バージョン間で意味的および技術的に非互換のコントラクトがある1つのサービスに対して、複数のバージョンは使用できません。
コントラクトが全体的に異なる場合は、実行される操作や動詞が同じ場合でも、既存のABCSのバージョン付けはできません。
ABCSは、アプリケーション・バージョンとは関係なくバージョン付けされます。
ABCSは、特定のアプリケーション・バージョンにバインドされません。アプリケーションでバージョン変更が行われても、同様のバージョン変更を行うためにABCSにバインドされることはありません。したがって、ABCSはアプリケーションのバージョン変更に依存しないように設計されています。
ABCSの複数のバージョンが同時に存在するのは避けてください。
たとえば、チームAがバージョン1を所有し、チームBはこのコントラクトが適切でないため、異なるMEP/コントラクトを使用してバージョン2を作成したとします。これで、チームAは、前のバージョンと矛盾するコントラクトを使用してバージョン3を作成できます。
特定の役割(リクエスタ/プロバイダ)を使用して単一のビジネス・アクティビティを実行する1つのアプリケーションに対して、複数のサービスは使用できません。
同じロジックを使用する複数のサービスに、異なる名前(コンポジットやサービスの異なる名前、またはWSDLの異なるportType)を付けないでください。
異なるロジックを使用する複数のサービスに、同じ名前を付けないでください。
EBSに定義される操作によってABCSの実装が決まります。
EBSに定義される操作は、ビジネス・アクティビティ/タスクによって指定されます。
ビジネス・アクティビティ、タスクまたはその両方のバリエーションが可能です。これらはコンテキストの形式で渡され、異なるABCSによって実装されます。
特定のアプリケーションおよびビジネス・アクティビティのABCSを作成、使用またはその両方を行う複数のチームは、コントラクトについて同意する必要があります。
この項では、Oracle Mediatorにおける再順序付け機能の概要を示し、Oracle AIAの非同期メッセージ交換パターンで設定および使用する方法を説明します。
Oracle AIAの非同期メッセージ交換パターンでは、参加アプリケーションがメッセージをOracle AIAレイヤーにプッシュし、このレイヤーでメッセージがストア・アンド・フォワード方式で処理されます。
このメッセージ交換パターンでは、同じオブジェクト・インスタンスに関連するメッセージを、メッセージが生成された順序で処理する必要があります。Oracle Mediatorのリシーケンサを使用すると、正しい処理順序を維持するのに役立ちます。
リシーケンサは、関連性はあるが順序が正しくないメッセージのストリームを再配置して順序どおりに戻すために使用します。ランダムな順序で到着した受信メッセージを順序付けしてから、ターゲット・サービスに正しい順序で送信します。
メッセージの順序は、次の永続ポイントまで維持されます。次の永続ポイントがアプリケーションでない場合、メッセージは再順序付けされる必要があります。
SiebelアプリケーションがCreateOrder/UpdateOrderメッセージを送信し、そのメッセージがJMSキューにエンキューされる統合シナリオを考えてみます。これらのメッセージは、JMSコンシューマ・アダプタ・サービスによってデキューされ、処理のために下位に送信されます。受信メッセージがJMSキューに到着するとき、ネットワークの遅延、サーバーの停止など様々な理由でメッセージがランダムな順序になる可能性があります。リシーケンサは順次または時系列の情報に基づいてメッセージを順序付けした後、正しい順序でターゲット・サービスにメッセージを送信します。
図8-13に、Siebelアプリケーションからのメッセージの受信ストリームがJMS宛先に保持され、正しい順序で処理されるユースケースを示します。
図8-13 Oracle Mediatorの再順序付け機能を使用したメッセージ順序付け
順序付けは、選択した順序付け方法に基づいて処理されます。メディエータには、3タイプのリシーケンサが用意されています。
標準リシーケンサ
FIFOリシーケンサ
ベスト・エフォート・リシーケンサ
Oracle Mediatorのリシーケンサ機能の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle Mediatorにおける再順序付けに関する項を参照してください。
これはOracle Mediatorの機能であるため、メディエータ・サービスが設計どおりに機能するように適切な場所に配置する必要があります。
この項では、再順序付け機能を使用するようにOracle Mediatorサービスを構成する方法を説明します。
メディエータ・コンポーネントのMplanファイルを設計モードで開きます。
「再順序レベル」で「操作」を選択します
注意:
メディエータでは、「再順序レベル」で「操作」または「コンポーネント」のいずれかを選択できます。操作が1つのみのメディエータ・コンポーネントでは、「再順序レベル」で「操作」または「コンポーネント」を選択したかどうかは問題ではありません。複数の操作が定義されているメディエータで「コンポーネント」オプションを選択することは、すべての操作に再順序付けが適用されることを意味します。
メディエータについて、「再順序レベル」で「操作」を選択することをお薦めします。図8-14は、再順序レベルが操作レベルで選択されたコンポジットmplanのスクリーンショットです。
図8-14 操作レベルで選択された再順序レベル
リシーケンサが機能するには、再順序付け方法に応じて、ソース・ペイロードの次の値の一方または両方を使用します。
最初はsequenceIDで、次はgroupIDです。sequenceIDはメッセージ自体の識別子として使用されます。groupIDは、リシーケンサがsequenceIDに基づいてメッセージを再編成するためにメッセージをグループ化するのに使用されます。
次の3つのオプションから再順序タイプを決定して設定します。
標準: 受信メッセージに、既知の増分および開始順序番号を使用する順序IDとして整数が含まれる場合に使用します。
ベスト・エフォート: 受信メッセージに順序IDとしてタイムスタンプが含まれる場合に使用します。
FIFO: その他のすべてのケースで使用します。
図8-15は、再順序タイプが表示されたスクリーンショットです。
図8-15 再順序タイプ
再順序オプションを設定します。
グループを決定して設定します
グループIDは受信メッセージのパラメータ(フィールドまたは属性)で、順序付けされるメッセージのグループを一意に識別します。
例: CustomerId、OrderId、ProductId、Account IDなど。
グループIDを構成するには、「再順序オプション」の「グループ」に、リシーケンサが受信メッセージのグループ化に使用するペイロードのフィールドをポイントするXPath式を設定します。これによって、特定のグループに属するメッセージが順序に従って処理されます。
例: SyncCustomerPartyListEBM/ns0:SyncCustomerPartyListEBM/ns0:DataArea/ns0:SyncCustomerPartyList/ns0:CustomerPartyAccount/corecom:Identification/corecom:ApplicationObjectKey/corecom:ID[@schemeID='AccountId']。
図8-16は、「グループ」フィールドにXPath式が表示されたスクリーンショットです。
図8-16 再順序オプション
IDを決定して設定します
IDは受信メッセージのパラメータ(フィールドまたは属性)で、順序内でのメッセージの位置を示します。
IDは、再順序付けが実行される受信メッセージのフィールドをポイントするXPath式によって宣言されます。
例: $in.SyncCustomerPartyAccountListEBM/ns0:SyncCustomerPartyAccountListEBM/ns0:DataArea/ns0:SyncCustomerPartyAccountList/ns0:CustomerPartyAccount/corecom:Identification/corecom:ApplicationObjectKey/corecom:ID /@schemeID
図8-17は、「ID」フィールドにXPath式が表示されたスクリーンショットです。
図8-17 「ID」パラメータの設定
「ベスト・エフォート」再順序モードの再順序オプションを設定します。受信メッセージは、リシーケンサに対して順序付けに使用する識別子の情報を提供できません。通常、このようなシナリオで順序付けに使用される識別子は、dateTimeタイプまたはnumericタイプです。dateTimeフィールドを順序ID XPathとして使用すると、順序付けを制御できます。
図8-18は、dateTimeオプションが選択されているスクリーンショットです。
図8-18 「ベスト・エフォート」再順序モードの再順序オプション
リシーケンサ・メディエータ・サービスがJMSコンシューマ・アダプタ・サービスとリクエスタABCSの間に配置されている場合は、メッセージがリシーケンサに到達するとJMSキューからそのメッセージが削除されるため、トランザクション境界がリシーケンサ・ストアにシフトします。
再順序付けのために着信したメッセージは、複数のグループに分割され、IDを選択する再順序付け方法に従ってグループ内のメッセージが順序付けされます。グループ内の順序付けは、他のグループのメッセージの順序とは独立して実行されます。グループ自体は相互に依存していないため、独立して処理できます。
たとえば、Update OrderメッセージのaccountIDがグループIDとして使用される場合、特定のアカウントIDを持つ着信Update Orderメッセージは、別のアカウントIDを持つUpdate Orderメッセージから独立してグループとして処理されます。
リシーケンサは、リシーケンサから直接メッセージを受信するポイントまで、正しい処理順序を維持するのに役立ちます。再順序付けされるメッセージを受信するプロセスに非同時性が導入されている場合、順序は保証されません。つまり、メッセージの順序は、次の永続ポイントまで維持されます。その後、メッセージは再順序付けされる必要があります。
グループのメッセージが失敗すると、そのグループのメッセージ処理が停止され、保留メッセージが保持されます。エラー・メッセージはエラー・ホスピタルに配置され、再試行可能なすべてのメッセージについて修正および再発行を行います。
同じグループIDのすべてのメッセージが、異なるトランザクションのシングル・スレッドで処理されます。メッセージの処理に失敗した場合、そのグループの残りのメッセージは一時停止されます。したがって、エラーが発生したメッセージを再発行してください。メッセージを再試行または中断した後にのみ、処理が次の順序から再開します。
他のグループのメッセージの処理は介入なしで続行されます。
エラーが発生したグループの新しいメッセージが着信すると、メッセージはリシーケンサ・ストアに格納されるため失われません。失敗したメッセージがOracle Enterprise Manager (OEM)コンソールまたは別のツールから再発行されると、エラーが発生した関連グループのロックが解除され、そのグループの通常処理が再開します。
メッセージをグローバル・トランザクションのフローのサービスまたはコンポーネントに配信できない場合、そのメッセージは適切なソース・マイルストンにロールバックされます。このソース・マイルストンは、キュー、トピックまたはリシーケンサに相当します。メッセージは、サービスまたはコンポーネントに配信するための再発行が可能になるまで、ここに保持されます。
メッセージ再発行ユーティリティを使用して、エラーが発生したメッセージを再発行するには、JMSコンシューマを使用してソース・マイルストンから受信メッセージがデキューされたときに、最初にメッセージ再発行パラメータを使用して受信メッセージを入力する必要があります。
これらの値を受信メッセージに入力する方法の詳細は、「メッセージ再発行値の入力」を参照してください。
メッセージ再発行ユーティリティAPIを使用すると、外部プログラムは、トランザクションで使用できるようにエラー状態のメッセージを有効にできます。通常、このユーティリティは、メッセージがエラーで終了した問題を修正するために実行されます。
再発行ユーティリティの詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのリシーケンサ・ベースの再発行に関する項を参照してください。
エラーを生成するメッセージはエラー・ホスピタルに移されます。グループはエラー状態に移り、ワーカー・スレッドで取得されません。エラー・ホスピタルを使用して、エラー生成メッセージを再発行できます。メッセージを再発行した後に、グループは通常状態に移るため、ワーカー・スレッドで取得できるようになります。
次のパラメータを使用して、リシーケンサを調整できます。
ResequencerWorkerThreadCount: リシーケンサによって使用されるスレッドの数。
ResequencerMaxGroupsLocked: スレッドでロックできる最大グループ数。
スリープ間隔: メッセージ頻度が高い場合は、スリープ間隔を低く設定します。ワーカー・スレッドがアイドル状態にならないように、ロックするグループ数にはワーカー・スレッド件数より多い値を設定することをお薦めします。デフォルトでは、ResequencerMaxGroupsLockedとResequencerWorkerThreadCountには同じ値が設定されます。
注意:
コンポジットに対してリシーケンサをオンにした後は、実行時にリシーケンサをオフにできません。
Oracleアプリケーションのコンポジットは、特定の業界のニーズにあわせて作成されます。また、各組織のビジネス固有のニーズにあわせて、これらのコンポーネントをさらにカスタマイズするためのオプションも用意されています。カスタマイズとは、新しい動作を形成するために、提供されたアーティファクトを変更することです。このオプションを使用して、Oracleから提供されるデフォルトのコンポジットをカスタマイズでき、そのコンポジットを当初の場所にデプロイすることもできます。いくつかのコンポジットをカスタマイズして、組織に固有のソリューションを作成します。
ただし、新しいバージョンがある場合にパッチまたは更新を適用すると、これらのカスタマイズが上書きされる可能性があります。上位レイヤーでのカスタマイズが更新時に失われないようにするために、カスタマイズされたレイヤーと基本プロセスは独自のメタデータ・ファイルに保持されます。基本バージョンがカスタマイズ可能な場合のみ、カスタマイズを基本コンポジット以外の外部に保持できます。ソリューションをデプロイする場合のみ、レイヤーが基本プロセスとマージされ、単一の実行可能プロセスが作成されます。
レイヤー・カスタマイズの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のSOAコンポジット・アプリケーションのカスタマイズに関する項を参照してください。
すべてのコンポジットがカスタマイズ可能か。
デフォルトの事前作成済の統合セットに提供されたサービスの場合、カスタマイズ可能なスコープがBPELフローに追加されます。事前作成済の統合でサービスのカスタマイズが可能かどうかを確認するには、事前作成済の統合の実装ガイドを参照してください。JDeveloperでカスタマイズ開発者ロールを使用してBPELを開く場合は、カスタム・ロジックをこれらのスコープに追加できます。これらのカスタマイズは基本定義とは別に保持されます。カスタム・ロジックをこれらのスコープに追加する利点は、更新時にカスタマイズが保持されることです。後続のパッチまたは新しいリリースを取り込むと、新しい基本定義に加えてこれらのカスタマイズをマージして、BPELをデプロイできます。
カスタマイズ可能なスコープを含むサービスがない事前作成済の統合は、カスタマイズできません。
カスタマイズを行う際は、次のガイドラインに準拠してください。
カスタマイズは、カスタマイズ可能なスコープがあるBPELベースのAIAアーティファクトに対してのみ可能です。他のアーティファクトに対して行ったインライン・カスタマイズは、パッチを適用したり新しいバージョンに更新すると上書きされます。
カスタマイズ可能とマークされていないコンポジットは、後でコンポジットにパッチが適用されるとマージの競合が発生するため、カスタマイズしないでください。
デフォルトで定義されている変数をカスタマイズされたコードに従ってセクションで使用すると、BPELフローの動作に悪影響を与える場合があるため、デフォルトで定義されている変数やメッセージは変更しないでください。
SOAコンポジット・アプリケーションの顧客バージョンをカスタマイズする場合は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の、顧客バージョンのカスタマイズに関する項を参照してください。
