| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、アプリケーション・ビジネス・コネクタ・サービス(ABCS)の作成方法について説明します。ここでは、ABCSの作成を開始する前に必要な前提条件をリストし、SOAコンポジット・アプリケーションの概念を簡単に説明します。
注意:
コンポジット・ビジネス・プロセス(CBP)は、次のリリースから非推奨となります。人間/システム相互作用のモデル化には、BPMの使用をお薦めします。
この章の内容は次のとおりです。
表7-1に、ABCSを作成するための共通タスクをリストして、詳細情報へのリンクを示します。
表7-1 ABCSを作成するためのタスクの概要
| 状況 | 参照先 |
|---|---|
ファイア・アンド・フォーゲット・メッセージ交換パターン(MEP)を実装する |
非同期リクエストのみ(ファイア・アンド・フォーゲット) MEPを使用する場合 EBSにMEPを実装する場合は、「ファイア・アンド・フォーゲット・メッセージ交換パターンの実装」を参照してください。 |
非同期リクエスト/遅延レスポンスMEPを実装する |
EBSにMEPを実装する場合は、「非同期リクエスト/遅延レスポンス・メッセージ交換パターンの実装」を参照してください。 |
同期リクエスト/レスポンスMEPを実装する |
EBSにMEPを実装する場合は、「同期リクエスト/レスポンス・メッセージ交換パターンの実装」を参照してください。 |
ABCSでエンタープライズ・ビジネス・サービス(EBS)操作を呼び出す |
EBSの操作の使用に関するガイドラインは、「エンタープライズ・ビジネス・サービスの設計と開発」を参照してください |
メッセージの書式を別の書式に変換する方法の詳細が必要 |
|
ABCSと参加アプリケーションの接続方法(インバウンドとアウトバウンドの両方)に関する情報が必要 |
|
開発中のABCSをクライアント(アプリケーション、その他のサービスなど)が呼び出す方法を知る必要がある |
|
ABCSを保護する |
|
ABCSでエラーやフォルトを処理できるようにする |
|
顧客がABCSを拡張できるようにする |
|
ABCSに対応するコンポジット・アプリケーション検証システム(CAVS)のガイドラインが必要 |
|
AIAインストール・ドライバを使用して、開発中のABCSをデプロイする |
|
ABCS内からAIA構成プロパティにアクセスする |
「$SOA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configでのAIAConfigurationProperties.xmlの使用方法」。 |
ABCSの作成を開始する前に、次のことを確認してください。
関連する開発SOAサーバーがSOAコア拡張機能とともにインストールされて実行されていること。
「AIAワークステーションの設定方法」を参照してください。
アプリケーション・エンティティのスキーマ(アプリケーション・ビジネス・メッセージ[ABM]スキーマ)がメタデータ・サービス(MDS)リポジトリからアクセス可能であること。これらは、各ABCSプロジェクトに含まれません。
「AIAでのMDSの使用」を参照してください。
エンタープライズ・ビジネス・オブジェクト(EBO)およびエンタープライズ・ビジネス・メッセージ(EBM)を含むエンタープライズ・オブジェクト・ライブラリがMDSリポジトリでアクセス可能であること。EBOおよびEBMは、各ABCSプロジェクトに含まれません。
「AIAでのMDSの使用」を参照してください。
EBSまたは参加アプリケーションのすべての抽象WSDLがMDSリポジトリからアクセス可能であること。
ヒント:
開発中のABCSの抽象WSDLには、MDSからアクセスする必要があります。このルールには次の例外があります。
EBSは、PartnerLinkタイプを定義するWSDLを参照します
参加アプリケーションは、PartnerLinkタイプを定義するWSDLを参照します
JDeveloperで生成されるアダプタWSDL
ABCS拡張ポイントで定義されるサービスの抽象WSDL
詳細は、「AIAでのMDSの使用」を参照してください。
リクエスタおよびプロバイダ参加アプリケーションが識別されていること。
EBOおよびEBMが識別されていること。
EBSと参加アプリケーション間の機能マッピングが完了していること。このマッピングには次が含まれます。
EBOと参加アプリケーション・メッセージ間のデータ要素スプレッドシート・マッピング。
EBSと参加アプリケーション間の操作マッピング。
相互作用のスタイル(MEP: リクエスト/レスポンス、ファイア・アンド・フォーゲット、非同期リクエストおよび遅延レスポンス)が定義されていること。
「適切なMEPの選択」を参照してください。
参加アプリケーションとの通信プロトコルが識別されていること。
ABCSが参加アプリケーションと相互作用する方法の詳細は、「リソース接続の確立」を参照してください。
参加アプリケーション固有の要件(エラー処理、セキュリティなど)が識別されていること。
AIAサービス(ABCSおよびEBS)は、SCA構築ブロックを使用して作成されるコンポジット・アプリケーションとして開発できます。これらのサービスには、4つのSCA要素が適用されます。
サービス
SCAコンポーネントまたはコンポジットへのエントリ・ポイントを表します。
参照
特定のSCAコンポーネントの範囲外にある外部サービスへのポインタを表します。
実装タイプ
ビジネス・ロジックのコーディングに使用される特定のSCAコンポーネントに対して、実装コードのタイプを定義します。BPELおよびMediatorは実装タイプの例です。
ワイヤ
2つのコンポーネントを相互に接続できるメカニズムを表します。通常、1つのコンポーネントの参照が、別のコンポーネントによって公開されたサービスに接続されます。
SCAコンポーネントは、1つ以上のサービスの公開、1つ以上の参照の使用、1つ以上のプロパティによる特定の特性の定義、およびSCAワイヤリングを使用した1つ以上のコンポーネントへの接続が可能です。
SCAの構築ブロックを連結したりアセンブルして、コンポジット・アプリケーションを作成できます。コンポジット・アプリケーションは、大まかなビジネス機能を集約的に提供する、関連するSCAコンポーネントの構成と考えることができます。
コンポジット・アプリケーションは、大まかなビジネス機能を集約的に提供する、関連するSCAコンポーネントの構成と考えることができます。コンポジットには、コンポジットの内部実装にのみ必要なコンポーネント、およびコンテキスト内でコンポジットの範囲外とのインタフェースが不要なコンポーネントを含めることができます。
コンポーネントは、コンポジットの内部実装用のみに使用できるため、サービス、参照またはその両方を公開しなくても存在できます。
図7-1に示すリクエスタABCSコンポジットは、サービスとして公開されている1つのコンポーネントを使用して作成できます。
コンポーネントは、EBSを表す1つの参照、または他のアプリケーションとのアウトバウンド相互作用を表す複数の参照を使用できます。
図7-1 リクエスタABCSコンポジットの例
同様に、図7-2に示すプロバイダABCSコンポジットは、サービスとして公開されている1つのコンポーネントを使用して作成できます。
コンポーネントは、アプリケーションとのアウトバウンド相互作用を表す1つ以上の参照を使用できます。
図7-2 プロバイダABCSコンポジットの例
この項では、JDeveloperを使用して設計モードでABCSコンポジットを作成する方法の概要を説明します。
実行する高度なタスクは次のとおりです。
MDSにアクセスするようにJDeveloperを構成します。
「AIAでのMDSの使用」を参照してください。
ABCSの抽象WSDLを開発します。
「アプリケーション・ビジネス・コネクタ・サービスの設計」を参照してください。
JDeveloperを使用してABCSコンポジットを作成します。
「JDeveloperを使用したABCSコンポジットの作成方法」を参照してください。
BPELプロセスを開発します。
「BPELプロセスの開発」を参照してください。
JDeveloperを使用して設計モードでコンポジットを開発した後は、BPELプロセス・コンポーネントとして実装されるABCSの作成を完了する必要があります。
ABCSで、次のタスクを実行します。
メッセージ・エンリッチメント
メッセージ・ヘッダーの入力
メッセージ・コンテンツの変換
エラー処理およびロギング
拡張性
CAVS対応
セキュリティ・コンテキスト実装
ABCS開発の完了の詳細は、「ABCS開発の完了」を参照してください。
ターゲットごとに参照を追加します。
ターゲットはWebサービスまたはアダプタが可能です。
ターゲット・サービスで変換が必要な場合は、間にメディエータ・コンポーネントを作成します。
インタフェースごとにサービスを追加します。
サービスはWebサービスまたはアダプタが可能です。
アダプタ・インタフェースで変換が必要な場合は、間にメディエータ・コンポーネントを作成します。
SOA Suite 12cでは、中央リポジトリのメタデータ・サービス(MDS)が導入され、設計時および実行時にアプリケーション(およびコンポジット)をバックアップします。MDSは、共有している共通のアーティファクトを設計時および実行時に格納して使用できるバージョン管理システムに類似しています。
AIAでは、MDSリポジトリを利用して、すべての開発者が共有する共通の設計時アーティファクトを格納します。MDSには一元的にアクセス可能なエンドポイントとして、抽象WSDLの共通ディレクトリがあります。
MDSに格納されるアーティファクトには、次の内容が含まれます。
スキーマ: EBOスキーマおよびABMスキーマ
WSDL: EBS、ABCS、アダプタ・サービス、CBPおよびEBFの抽象WSDL
すべてのAIAサービスの抽象WSDLは、すべてMDSに配置されます。参照先サービスの抽象WSDLを使用して、使用するAIAサービス・コンポジット・アプリケーションを作成します。コンポジットのデプロイメントの順序に対する依存性はありません。
コンポジットのデプロイメント時は参照先サービスに対する依存性がないため、コンポジットのデプロイメントの順序に対する依存性はありません。参照先サービスは、別のサービスで参照するためにデプロイする必要はありません。これによって、サービス間で循環参照がある場合も解決されます。
ヒント:
呼び出す必要があるサービスを参照するには、常に抽象WSDLを使用してください。参照バインディング・コンポーネントでは、常に抽象WSDLを使用する必要があります。
消費アーティファクトでは具象WSDLを直接使用しないでください。
サービス・プロバイダのデプロイ済の具象WSDLを参照しないでください。
この方法については、次の段落で説明します。
これを推奨する理由については、「関心の分離」を参照してください。
AIAでのMDSの使用方法の詳細は、「AIAでのMDSの使用」を参照してください。
ヒント:
抽象WSDLは、MDSから必要なスキーマにアクセスするように変更して、MDSに移動する必要があります。
トラブルシューティングのヒント:
無効なSOAコンポジットを示すエラー・メッセージがサーバーの再起動後に表示される場合があります。これは、抽象WSDLを使用する必要がある場所で具象WSDLを参照していることが原因です。
新しいコンポジットXの最初のデプロイメント時にコンポジットYの具象WSDLを参照した場合は問題がありません。なぜでしょうか。コンポジットYは、コンポジットXのデプロイメント時には起動して稼働しています。問題はサーバーを再起動した際に発生しますが、これは、依存性を解決する正しい順序でコンポジットがアクティブ化される保証がないためです。コンポジットYの前にサービスXがアクティブ化された場合は、Yが停止しているため参照を解決できず、このため、Xのステータスは無効のままとなります。
ABCSおよびアダプタ・サービスの場合、抽象WSDLはMDSの次の場所に配置されます。
AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/<PRODUCT_CODE>/<バージョン番号>/<サービス・タイプ>
<サービス・タイプ>に設定可能な値は、RequesterABCS、ProviderABCS、AdapterServicesです。
<バージョン番号>に設定可能な値は、V1、V2です。
アーティファクトをMDSに移動するユーティリティについては、「AIAでのMDSの使用」で説明されています。
例:
AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/Siebel/V1/RequesterABCS AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/Siebel/V1/ProviderABCS
この項では、ファイア・アンド・フォーゲットMEPを実装する際に必要なガイドラインを示します。
このMEPが推奨されるシナリオの詳細は、「非同期リクエストのみ(ファイア・アンド・フォーゲット) MEPを使用する場合」を参照してください。
ファイア・アンド・フォーゲット・パターンでは、リクエスタにレスポンスが返信されません。プロバイダABCSがタスクを正常に完了できない場合は、トランザクションがロールバックされ、エラー通知が送信される必要があります。
トランザクションをモデル化する方法の詳細は、「メッセージ変換の使用」を参照してください。
フォルトの処理方法の詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。
RequesterABCSがJMSベースのトランスポート・アダプタによって呼び出される場合、JMS宛先はマイルストンとして考えることができます。このような状況では、失敗したメッセージの自動メッセージ再発行用にJMSコンシューマ・アダプタおよびリクエスタABCSを構成できます。
メッセージ再発行の詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのメッセージ再発行ユーティリティの使用に関する項を参照してください。
この項には次のトピックが含まれます:
データを自動訂正したり、リクエスタ・サービスで実行された作業を元に戻すことが必要になる場合があります。典型的なシナリオは、トランザクションでエラーが発生し、トランザクションをロールバックできない場合です。
このような状況では、リクエスタ・アプリケーションは補正サービス操作を実装し、サービス操作の名前をプロバイダABCSに渡すことができます。エラーが発生した場合、プロバイダABCSはこの補正サービス操作を呼び出します。要求側サービスに対して補正サービスを実装するための要件がある場合があります。
提供側サービスから正しい補正サービスを呼び出す手順は、次のとおりです。
リクエストEBMの作成に使用する変換の補正サービス名をEBMHeader/Sender/WSAddress/wsa:FaultTo/wsa:ServiceNameに入力します。
補正サービスの名前の例: CompensateCreateOrderSiebelReqABCSImpl
ネーミングの詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。
図7-4に、WSAddressTypeの構造を示します。
図7-4 WSAddressTypeの構造
この情報をEBSの補正操作で使用して、補正のリクエストを適切な補正サービスにルーティングします。
この項では、非同期リクエスト/遅延レスポンスMEPを実装する際に必要なガイドラインを示します。
このMEPが推奨されるシナリオの詳細は、「非同期リクエスト/遅延レスポンスMEPを使用する場合」を参照してください。
この項では、非同期リクエスト/遅延レスポンスMEPの実装方法について説明します。
このMEPを実装するには、次のことが必要です。
非同期遅延レスポンスのEBMヘッダーが入力されていること。
相関セットおよび相関IDが定義されていること。
エラー・レスポンスをリクエスタABCSまたはエラー・ハンドラ・サービスのいずれかに返信するシナリオを処理するために、リクエスタABCS、EBS、ProviderABCSおよびResponseEBSに対して適切なプログラミング・モデルが使用されていること。
この項には次のトピックが含まれます:
非同期遅延レスポンスのEBMヘッダーを入力する手順は、次のとおりです。
これは、適切な要求側サービス・インスタンスへのレスポンスの相関で使用されます。
図7-5に、CreateSalesOrderEBMTypeの構造を示します。
図7-5 CreateSalesOrderEBMTypeの構造
これは、レスポンス・メッセージを処理するためにEBSによって呼び出す必要があるサービスの名前です。ほとんどの場合、プロバイダABCSからのレスポンス・メッセージも処理する同じリクエスタABCSです。
図7-6 SWSAddressTypeの構造
この情報をEBSのレスポンス操作で使用して、提供側サービスから適切な要求側サービスにレスポンスをルーティングします。
レスポンスEBSによってルーティングされた提供側サービスからの遅延レスポンスは、Receiveアクティビティで受信されます。要求側サービスでInvokeステップが実行され、プロセスがReceiveステップに移動した後、BPELプロセス・インスタンスは一時停止してデハイドレーションされます。これは、レスポンスが受信された後に再開されます。この動作を容易にするために、ReceiveのpartnerLinkに相関セットを指定する必要があります。
リクエスタABCSプロセスは、図7-7の例のようになります。これは、相関IDの設定が必要なプロセスです。
図7-7 リクエスタABCSプロセスの例
「非同期遅延レスポンスのEBMヘッダーの入力方法」で説明しているプロセスでは、2箇所に相関を設定する必要があります。
相関セット
プロセスがデハイドレーション・ストアに進むInvokeアクティビティに対して、相関IDを追加し、相関セットを作成します。
プロバイダ/エッジ・アプリケーションからの遅延レスポンスを取得した後にデハイドレーション・ストアからプロセスが再コールされるReceiveアクティビティに対して、相関IDを追加し、相関セットを作成します。
相関プロパティ
前述したように相関セットが定義されるInvokeまたはReceiveアクティビティにリンクするpartnerLinkごとに、名前-値ペアを追加します。プロパティは常にcorrelation = correlationSetとして定義する必要があります。
この項では、次のためのプログラミング・モデルについて説明します。
エラー処理用に個別サービスを使用
RequesterABCSとEBS間でマイルストンとしてJMSキューを使用
EBSでパラレル・ルーティング・ルールを使用
このモデルでは、メッセージが正常に処理されると、プロセスを開始したリクエスタにレスポンスが返信されます。ただし、ProviderABCSで処理中にメッセージ・エラーが発生した場合は、ResponseEBSを使用して個別のエラー・ハンドラ・サービスにルーティングされます。
リクエスタABCSに到達したインバウンド・メッセージはEBSに渡され、EBSでプロバイダABCSが呼び出されてメッセージが処理されます。
メッセージが処理された後に、プロバイダABCSはメッセージをJMSキューにプッシュします。
メッセージの処理中にエラーが発生した場合は、エラー・レスポンス・メッセージが作成され、レスポンスが実際にはエラー・メッセージであることをEBMレスポンス・ヘッダーで示す必要があります。
成功した場合、レスポンスEBSはレスポンス・メッセージを開始requesterABSにルーティングします。
失敗した場合、レスポンスEBSはメッセージをエラー・ハンドラ・サービスにルーティングする必要があります。
注意:
プロバイダABCSがレスポンスまたはエラー・メッセージを送信する必要がある場合は、成功およびエラーのいずれの場合も、プロバイダABCSからJMSキューにメッセージを公開します。
図7-8に示すように、このモデルには2つのトランザクションがあります。
トランザクション1は、requesterABCSによるメッセージのデキュー、またはRequesterABCSを直接コールする外部アプリケーションで開始します。このトランザクションの場合は、プロバイダABCSがリプライまたはエラー・メッセージをJMSキューに公開して終了します。
図7-8 プログラミング・モデル1: エラー処理用に個別サービスを使用
図7-9に示すこのモデルでは、リクエスタABCSがインバウンド・メッセージをJMSマイルストンに公開します。トランザクションは、リクエスタABCSによるメッセージのデキュー、またはリクエスタABCSを直接コールする外部アプリケーションで開始します。トランザクションは、リクエスタABCSがメッセージをJMSキューに公開して終了します。
2番目のトランザクションは、JMSキューからメッセージをデキューし、EBSを呼び出して開始します。EBSは、インバウンド・メッセージを処理のためにProviderABCSにルーティングします。
メッセージ処理が成功した場合、プロバイダABCSは既存のトランザクション内でネイティブのバインディング・コールを使用して、レスポンスEBSを呼び出します。
メッセージ処理中にエラーが発生した場合、プロバイダABCSはエラー発生メッセージを別のJMSキューに公開します。レスポンスEBSはメッセージを受け取り、フォルト・ハンドラ・サービスを呼び出します
図7-9 プログラミング・モデル2: リクエスタABCSとEBS間でマイルストンとしてJMSキューを使用
ヒント:
エラーのシナリオの場合のみ、プロバイダABCS参照コンポーネントでこのキューを使用します。
リクエスタABCSに到達したインバウンド・メッセージはEBSに渡されます。EBSは、パラレル・ルーティング・ルールを使用して、メッセージ処理のためにメッセージをプロバイダABCSにルーティングします。トランザクションは、リクエスタABCSによるメッセージのデキュー、またはリクエスタABCSを直接コールする外部アプリケーションで開始します。トランザクションは、EBSでキュー済の実行用にインバウンド・メッセージが保持されたときに終了します。
図7-10に、このプログラミング・モデルを示します。
2番目のトランザクションは、EBSからメッセージをデキューして開始します。メッセージ処理が成功した場合、プロバイダABCSは既存のトランザクション内で、レスポンスEBSへのネイティブのバインディング・コールを行います。レスポンスEBSは、別のreceiveアクティビティを呼び出して、リクエスタABCSへのレスポンスをルーティングします。エラーの場合、プロバイダABCSはWebサービス・コールを行ってレスポンスEBSを呼び出し、これによって新規トランザクションが開始されます。このトランザクションでは、レスポンスEBSが直接、またはリクエスタABCSを使用して、エラー・メッセージをアプリケーションに返信します。
図7-10 プログラミング・モデル3: EBSでパラレル・ルーティング・ルールを使用
この項では、プロバイダABCSで非同期MEPを実装する際に必要なガイドラインを示します。
このMEPが推奨されるシナリオの詳細は、「非同期リクエスト/遅延レスポンスMEPを使用する場合」を参照してください。
プロバイダABCSは、一方向サービス・コール・パターンまたはリクエスト/遅延レスポンス・パターンのいずれかとして動作するように実装されます。
リクエスト/遅延レスポンス・パターンでは、プロバイダABCSは、EBSリクエスト・ルーティング・サービスからリクエスト・メッセージを受信し、そのメッセージを処理して、最後に、EBSリクエスト・ルーティング・サービスのレスポンス操作を呼び出して、要求側サービス(リクエスタABCSまたはエンタープライズ・ビジネス・フロー[EBF])に応答します。場合によっては、プロバイダABCSはレスポンスまたはエラー・メッセージ(あるいはその両方)をJMSキューに公開することもできます。EBSリクエスト・ルーティング・サービスはレスポンスを待機しません。
「プログラミング・モデル1: エラー処理用に個別サービスを使用」を参照してください。
すべてのプロバイダABCS (およびEBF)はコールバック操作を呼び出す機能を持つ必要がありますが、リクエスタがコールバックを必要とする場合のみ呼び出すためのスイッチ・ケースが必要です。EBMの動詞要素のresponseCode属性を評価して、要求側サービスでレスポンスが必要かどうかを判断します。
非同期MEPをプロバイダABCSに実装する手順は、次のとおりです。
EBMヘッダーのEBMIDは、適切な要求側サービス・インスタンスへのレスポンス・メッセージの相関で使用します。図7-11に示すように、相関を容易にするには、提供側サービスのABMからEBMへの変換で、リクエスト・メッセージのEBMヘッダーのEBMIDを、レスポンス・メッセージのEBMヘッダーのRequestEBMIDにコピーする必要があります。
図7-11 CreateSalesOrderResponseEBMType要素の構造
変数でリクエスト・メッセージのEBMHeaderをABMからEBM XSLTに渡す方法については、「メッセージ変換の使用」を参照してください。
これは、リクエストEBMのEBMヘッダーからレスポンスEBMのEBMヘッダーに関連情報をコピーするために必要です。
リクエスト/遅延レスポンス・パターンに対して、「非同期リクエスト/遅延レスポンスMEPでエラー・レスポンスを処理するためのプログラミング・モデル」で説明したプログラミング・モデルを使用する場合は、次のガイドラインに従ってください。
プログラミング・モデル1: エラー処理用に個別サービスを使用
プロバイダABCSがレスポンスまたはエラー・メッセージを送信する必要がある場合、メッセージ処理の成功とエラーの両方のシナリオで、プロバイダABCSはJMSキューにメッセージを公開する必要があります。
注意:
新規トランザクションは、JMSからメッセージをデキューして開始します。
プログラミング・モデル2: リクエスタABCSとEBS間でマイルストンとしてJMSキューを使用
メッセージ処理が成功した場合、プロバイダABCSは既存のトランザクション内でネイティブのバインディング・コールを使用して、レスポンスEBSを呼び出します。
メッセージ処理中にエラーが発生した場合、プロバイダABCSはエラー発生メッセージを別のJMSキューに公開します。レスポンスEBSはメッセージを受け取り、フォルト・ハンドラ・サービスを呼び出します
プログラミング・モデル3: EBSでパラレル・ルーティング・ルールを使用
プロバイダABCSには、レスポンスEBSコンポジットへの2つの参照があります。プロバイダABCSのEBSへの2番目の参照は、命名規則に従って名前を付けてください。
命名規則の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。
図7-12に、ResponseEBSへの2番目の参照がある非同期プロバイダABCSコンポジットを示します。2番目の参照のラベルは<EBS名>ErrorResponseEBSです。
図7-12 ResponseEBSへの2番目の参照がある非同期プロバイダABCSコンポジット
メッセージが正常に処理されると、プロバイダABCSはレスポンスEBSに対するコールバック操作を呼び出します。レスポンスEBSは、別のreceiveアクティビティを呼び出して、リクエスタABCSへのレスポンスをルーティングします。メッセージの処理中にエラーが発生した場合、プロバイダABCSは、レスポンスEBSへの2番目の参照からレスポンスEBSを呼び出します。この場合、responseEBSは、ネイティブ・コールではなく、SOAPコールを使用して呼び出されます。これを行うには、プロバイダABCSのコンポジットで、レスポンスEBSへの2番目の参照に次のプロパティを設定します。
<binding.ws port="<port>" location="<url>"/>
<property name="oracle.webservices.local.optimization type="xs:boolean">false</property>
</binding.ws>
注意:
エラーのシナリオの場合のみ、プロバイダABCS参照コンポーネントでこのプロパティを使用します。
この項では、同期リクエスト/レスポンスMEPを実装する際に必要なガイドラインを示します。
このMEPが推奨されるシナリオの詳細は、「同期リクエスト/レスポンスMEPを使用する場合」を参照してください。
このシナリオでは、リクエスタABCSはEBSを同期的に呼び出します。EBSはプロバイダABCSを呼び出してレスポンスを待機します。同期性は、リクエスタABCS、EBSおよびプロバイダABCSのWSDLで明確にする必要があります。すべてのWSDLで、入出力メッセージを使用する操作を定義する必要があります。
このMEPでは、トランザクションをサポートする必要はありません。このMEPの実装に含まれるBPELプロセスには、中間プロセスのReceive、wait、Pick、onMessageアクティビティなどのブレークポイントはありません。
トランザクションの確認方法の詳細は、「AIAサービスでのトランザクションの確認方法」を参照してください。
このMEPには一時サービス(ブレークポイント・アクティビティがないため、中間にデハイドレーションがない)の実装が含まれるため、失敗したインスタンスの場合のみBPELサービスの監査詳細を保持することをお薦めします。正常に完了した統合フローに関連付けられたサービス・インスタンスは、Oracle Enterprise Managerを使用して表示できません。この方法によって、レスポンス時間が大幅に短縮されます。
auditLevelプロパティには、監査証跡のロギング・レベルを設定します。この構成プロパティは、永続プロセスと一時プロセスの両方に適用されます。このプロパティが制御するのは、プロセスによってログに記録される監査イベントの量です。監査イベントを記録すると、audit_level表およびaudit_details表へのデータベース挿入が増えるため、パフォーマンスに影響が出ることがあります。監査情報は、Oracle Enterprise Managerコンソールからプロセスの状態を確認する目的でのみ使用されます。監査情報を保存しない場合は、Off値を使用します。監査レベルは、常にビジネス要件およびユースケースに従って選択してください。
同期のBPELプロセスの場合は、正常に完了したインスタンスのインスタンス詳細は保持しないことをお薦めします。このためには、auditLevelプロパティをサービス・コンポーネント・レベルでoffに設定します。この一般的なガイドラインは、ユースケースに基づいて個々のサービス用にオーバーライドできます。
この項では、ABCSからEBSを呼び出し、EBSの操作を使用するためのガイドラインを示します。ここでは、EBS操作の呼出し側の観点から説明するため、実装の観点からEBS操作を理解するのにも役立ちます。
この項には次のトピックが含まれます:
これらの各項では、次の状況における各動詞の詳細を説明します。
いつ動詞を使用するか
動詞を使用するときのコンテンツ・ペイロードは何か
動詞の属性は何か(ある場合)
対応するレスポンス動詞は何か(ある場合)
レスポンス動詞のコンテンツ・ペイロードは何か
Create動詞は、Createメッセージのペイロードで提供される情報を使用してビジネス・オブジェクトを作成するためのリクエストを示します。これは、ビジネス・オブジェクトのインスタンスを作成するための操作で使用されます。
Create動詞を使用する場合
サービス・リクエスタとサービス・プロバイダの両方に同じオブジェクトがある場合は、Sync動詞を使用するほうが適切です。ただし、Syncを使用するには、サービス・プロバイダがSync操作を実装していることが条件になります。
Create操作はフロントエンドの顧客管理システムでの使用が一般的で、顧客からサービス・リクエストを取得し、指定された情報に基づいて、顧客にサービスするための作業指示を作成するように作業指示システムにリクエストします。
Create動詞はコンポジット操作では使用されず、ビジネス・オブジェクトの1つ(リストの場合は1つ以上)のインスタンスが常に作成されます。
コンテンツ・ペイロード
通常、Create動詞を使用する操作のペイロードは完全なビジネス・オブジェクトで、すべてのビジネス・オブジェクトにはCreate操作を使用する2つのメッセージ(単一およびリスト)のみ含まれるのが一般的です。
動詞属性
Create動詞には、レスポンス・メッセージで必要なペイロードをCreateリクエストに通知する、オプションのResponseCode属性があります。ResponseCodeの可能な値は、ID (レスポンス・ペイロードは、作成されたオブジェクトの識別子です)またはOBJECT (レスポンス・ペイロードは、作成されたオブジェクト全体です)のいずれかに制限されます。
対応するレスポンス動詞
Create動詞は、各Create EBMのレスポンス・メッセージで使用されるCreateResponse動詞とペアになっています。CreateメッセージのResponseCode属性を設定することによって、元のリクエスト・メッセージがレスポンスを明示的にリクエストしている場合のみ、レスポンスがターゲット・アプリケーションによって提供される必要があります。
レスポンス・コンテンツ・ペイロード
レスポンス動詞のペイロード・タイプは、常にCreate Request操作のペイロード・タイプに基づきます。ユーザーのカスタマイズをサポートする必要がある場合は、別のタイプとして実装されます。
Update動詞は、Updateメッセージで提供されるペイロードを使用してオブジェクトを更新するための、サービス・プロバイダへのリクエストを示します。これは、ビジネス・オブジェクトの1つ以上のプロパティ、またはビジネス・オブジェクトの配列を更新するための操作で使用されます。
Update動詞を使用する操作は、コンテンツを作成または更新する必要があり、他の操作の編成は不可です。
Update動詞を使用する場合
Createと同様に、ビジネス・プロセスでUpdate操作が呼び出されるのは、主として、呼出しをトリガーするソース・イベントが要求側システムにおけるオブジェクトの更新でない場合です。サービス・リクエスタとサービス・プロバイダの両方に同じオブジェクトがある場合は、Sync動詞を使用するほうが適切です。ただし、Syncを使用するには、サービス・プロバイダがSync操作を実装していることが条件になります。
Update操作の例として、受け入れた品目の数量で注文書明細を更新する受入システムや、顧客の住所やその他の情報で顧客レコードを更新する注文獲得システムがあります。
Update動詞を使用するEBMのビジネス・ペイロードに含まれるコンテンツは、ターゲット・アプリケーションで更新が必要なフィールドのみであると想定されます。Update動詞は、ビジネス・コンポーネントおよび共有コンポーネントのActionCodeプロパティを使用して、処理指示をターゲット・システムに通知します。これは、階層的で複数レベルのオブジェクトで、更新が子レベルで発生する場合に必要です。
ActionCodeプロパティは、親と複数のカーディナリティ関係を持つすべてのコンポーネントのEBOに存在します。ActionCodeの可能な値は、Create、UpdateおよびDeleteです。これは、適用される処理アクションをそのビジネス・コンポーネントに通知するために、Update動詞でのみ使用されます。ActionCodeが適用されるのはオブジェクトに子ビジネス・コンポーネントがある場合のみで、ない場合はActionCodeは不要で、この情報を伝達するには動詞のみで十分です。
ActionCodeのユースケースの1つは、購買依頼がセルフサービス購買依頼システムで更新され、購買依頼のコピーを保守している購買システムに、更新されたこの情報を通知する必要がある場合です。
ユーザーが購買依頼を更新して、(1つのトランザクションで)次のアクションを実行するとします。
購買依頼ヘッダーの説明を更新します
新しい購買依頼明細(明細番号4)を追加します
購買依頼明細(明細番号3)の品目を変更します
購買依頼明細(明細2)を削除します
購買依頼明細の会計配分を変更し、新規の会計配分(明細1)を追加します
例7-1に、前述の変更を通知するインスタンスXMLドキュメントのDataAreaビジネス・ペイロードの内容を示します。
コンテンツ・ペイロード
通常、Update動詞を使用する操作のペイロードはEBO全体で、すべてのビジネス・オブジェクトにはUpdate操作を使用する2つのメッセージ(単一およびリスト)のみ含まれるのが一般的です。
EBOのサブセットの更新が必要な状況が発生した場合、複数の更新メッセージが存在し、それぞれペイロードが異なる可能性があります。SalesOrderLineのみ含まれるペイロードがあるUpdateSalesOrderLineEBMメッセージはその一例です。
動詞属性
Update動詞には、レスポンス・メッセージで必要なペイロードをUpdateリクエストに通知するための、オプションのResponseCode属性があります。ResponseCodeの可能な値は、ID (レスポンス・ペイロードは、作成されたオブジェクトの識別子です)またはOBJECT (レスポンス・ペイロードは、作成されたオブジェクト全体です)のいずれかに制限されます。
対応するレスポンス動詞
Update動詞は、各Update EBMのレスポンス・メッセージで使用されるUpdateResponse動詞とペアになっています。UpdateメッセージのResponseCode属性を設定することによって、元のリクエスト・メッセージがレスポンスを明示的にリクエストしている場合のみ、レスポンスがターゲット・アプリケーションによって提供される必要があります。Updateリクエストで指定されるResponseCodeに応じて、レスポンスのペイロードはIDまたは更新済のオブジェクト全体のいずれかです。
レスポンス・コンテンツ・ペイロード
レスポンス動詞のペイロード・タイプは、常にUpdate Request操作のペイロード・タイプに基づきます。ユーザーのカスタマイズをサポートする必要がある場合は、別のタイプとして実装されます。
例7-1 Update
<UpdateRequisition actionCode="Update"> Root Action Code not processed <Description>New Description</Description> <RequisitionLine actionCode="Update"> Indicates that some property or association of this line is being updated. In this example, the accounting distribution Percentage has been updated for Line 1, and a new AccountingDistribution line has been added <Identification> <ID>1</ID> </Identification> < RequisitionAccountingDistribution actionCode="UPDATE"> <Identification> <ID>1</ID> </Identification> <AccountingDistribution> <Percentage>15</Percentage> </AccountingDistribution> < /RequisitionAccountingDistribution> < RequisitionAccountingDistribution actionCode="ADD"> <Identification> <ID>3</ID> </Identification> <AccountingDistribution> <Percentage>15</Percentage> </AccountingDistribution> < /RequisitionAccountingDistribution> </RequisitionLine> <RequisitionLine actionCode="DELETE"> Indicates this line has been deleted <Identification> <ID>2</ID> </Identification> </RequisitionLine> <RequisitionLine actionCode="UPDATE"> <Identification> <ID>3</ID> </Identification> <ItemReference> <Identification> <ID>1001</ID> </Identification> </ItemReference> </RequisitionLine> </RequisitionLine> <RequisitionLine actionCode="ADD"> Indicates this line has been added <Identification> <ID>4</ID> </Identification> <ItemReference> <Identification> <ID>1005</ID> </Identification> </ItemReference> </RequisitionLine> </UpdateRequisition>
Delete動詞は、Deleteメッセージのペイロードで提供されるオブジェクト識別を使用して特定するビジネス・オブジェクトを削除するための、サービス・プロバイダへのリクエストです。
Delete動詞を使用する場合
Delete動詞は、ビジネス・オブジェクトを削除する操作で使用されます。
Delete動詞を使用する操作は、コンテンツを削除する必要があり、他の操作の編成は不可です。
注意:
現在、AIAでは、ビジネス・オブジェクトのコンポーネントに対するDeleteの使用はサポートされておらず、Delete Purchase Order Lineは可能です。
コンテンツ・ペイロード
Delete動詞のペイロードは、削除するビジネス・オブジェクトを一意に識別するidentification要素のみである必要があります。
動詞属性
Delete動詞には、レスポンス・メッセージで必要なペイロードをUpdateリクエストに通知するための、オプションのResponseCode属性があります。DeleteのResponseCodeの可能な値は、ID (レスポンス・ペイロードは、作成されたオブジェクトの識別子です)のみです。
対応するレスポンス動詞
Delete動詞は、各Delete EBMのレスポンス・メッセージで使用されるDeleteResponse動詞とペアになっています。DeleteメッセージのResponseCode属性を設定することによって、元のリクエスト・メッセージがレスポンスを明示的にリクエストしている場合のみ、レスポンスがターゲット・アプリケーションによって提供される必要があります。ResponseCodeの可能な値はIDのみです。
Sync動詞は、Syncメッセージで提供されるペイロードを使用してオブジェクトに関する情報を同期するための、サービス・プロバイダへのリクエストを示します。
Sync動詞を使用する場合
Sync動詞は、操作のペイロードを受け取り、必要に応じてビジネス・オブジェクトを作成または更新する操作をアプリケーションが提供する状況で使用されます。
Sync動詞を使用する操作は、コンテンツを作成または更新する必要があり、他の操作の編成は不可です。
Syncが使用されるのはバッチ・トランザクションが一般的で、オブジェクトの現在の状態は判明しているが、前回の同期と現在の同期の間でどのように変更されたかが不明な場合です。また、Syncを使用して、オブジェクトの各インスタンスを同期できます。通常、Syncのイニシエータは、同期されるデータを所有するシステムです。
Sync操作を使用することは、ソース・システムとターゲット・システムの両方にオブジェクトが存在し、Syncによってソースとターゲットのコンテンツが同じになることを意味します。Syncは二重の処理指示が含まれる点で他の動詞と異なり、コンテンツの作成および既存のコンテンツの更新の両方を行うことができます。
Syncのコンテンツは、メッセージを生成するシステム内のオブジェクトの現在の状態を反映します。このモードでは、1つのSyncメッセージに名詞のインスタンスを複数含めることができ、インスタンスに特定の変更インディケータはありません。ソース・システムでメッセージが生成され、そのメッセージをサブスクライブするすべてのシステムでデータを同期して、メッセージのコンテンツを反映する必要があります。
Syncは頻繁に変更されないマスター・データ管理シナリオの場合に最も実践的な方法で、データをリアルタイムに同期するのは運用上の観点から実践的ではなく必要ありません。
Sync動詞にはオプションのsyncActionCode属性があり、Syncメッセージの受信者に必要な処理動作をさらに指示するのに使用できます。syncActionCodeの可能な値は次のとおりです。
CREATE_REPLACE:
syncActionCodeが指定されていない場合は、これがSyncのデフォルト動作です。syncActionCode属性が指定されていないか、syncActionCode属性値がNULLまたはCREATE_REPLACEのSyncメッセージを受信するターゲット・システムでは、ターゲット・システムにオブジェクトが存在しない場合はオブジェクトを作成し、存在する場合は、Syncメッセージで提供された定義にオブジェクト全体を置き換える必要があります。
CREATE_UPDATE:
syncActionCodeの値がCREATE_UPDATEのSyncメッセージは、ターゲット・システムにオブジェクトが存在しない場合はオブジェクトを作成し、存在する場合は、Syncメッセージで提供されたコンテンツでオブジェクトを更新するように処理される必要があります。
コンテンツ・ペイロード
一般的に、EBOごとにSyncメッセージは1つのみで(単一およびリスト実装による)、メッセージのペイロードはEBO全体です。
ビジネス・オブジェクト全体を同期するには、常にSyncを使用する必要があります。ビジネス・オブジェクトの異なる名前のビューが複数存在するが、ビジネス・オブジェクトの特定のコンポーネントは同期しない場合、複数のSyncメッセージが存在する可能性があります。
ヒント:
SyncのOAGIS実装とは異なり、Oracle AIAでは、追加、変更、置換および削除を示す特定の属性がSyncにありませんでした。Syncのエンタープライズ・オブジェクト・ライブラリ(EOL)実装は、メッセージ・ペイロードで指定された内容にターゲット・オブジェクトを正確に変更するための動詞です。Syncはコンテンツの削除には使用できず、コンテンツを削除する場合は明示的な削除操作を使用する必要があります。
動詞属性
Sync動詞には、レスポンス・メッセージで必要なペイロードをSyncリクエストに通知するための、オプションのResponseCode属性があります。SyncのResponseCodeの可能な値は、OBJECT (レスポンス・ペイロードは、作成または更新されたオブジェクト全体です)およびID (レスポンスは、作成または更新されたオブジェクトのIDのみです)に制限されます。
対応するレスポンス動詞
Sync動詞は、各Sync EBMのレスポンス・メッセージで使用されるSyncResponse動詞とペアになっています。SyncメッセージのResponseCode属性を設定することによって、元のリクエスト・メッセージがレスポンスを明示的にリクエストしている場合のみ、レスポンスがターゲット・アプリケーションによって提供される必要があります。
注意:
設計の意図は、2つの動詞を同じ目的で使用することを避けることです。Sync動詞はオブジェクトの作成もサポートしていますが、ソース・システムとターゲット・システムの両方にオブジェクトが存在するシナリオで主に使用することを意図しています。つまり、Syncを動詞として使用する意味は、同期するオブジェクトがソースとターゲットの両方に存在するという事実を受信アプリケーションに通知することです。これに対して、CreateまたはUpdateは、作成または更新するオブジェクトがソース・システムに存在しないという事実を通知するために使用します。
レスポンス動詞コンテンツ・ペイロード
レスポンス動詞のペイロード・タイプは、常にSync Request操作のペイロード・タイプに基づきます。ユーザーのカスタマイズをサポートする必要がある場合は、別のタイプとして実装されます。
Validate動詞は、メッセージのペイロードで提供されるコンテンツを検証するための、サービス・プロバイダへのリクエストです。これは、データの有効性を検証するための操作で使用されます。
Validate動詞を使用する場合
Validate動詞を使用する操作では、ビジネス・オブジェクトの作成や更新は実行されず、他の操作の編成として内部的に実装できます。たとえば、承認のために注文書を検証する場合は、予算があるかどうか、サプライヤがアクティブかどうか、明細に品目が必要な購買依頼が有効かどうかなどを検証します。
コンテンツ・ペイロード
Validateカテゴリに該当する操作のペイロードには、ビジネス・オブジェクト、ビジネス・オブジェクトのビジネス・コンポーネント、またはその他のユーザー定義ペイロードがあります。
動詞属性
なし。
対応するレスポンス動詞
Validate動詞は、各Validate EBMのレスポンス・メッセージで使用されるValidateResponse動詞とペアになっています。Validate動詞は、常に同期的に実装されます。
レスポンス・コンテンツ・ペイロード
Validate操作のレスポンス・ペイロードはユーザー定義が可能です。
Process動詞は、サービスに関連付けられたビジネス・オブジェクトに対応する操作を実行するための、サービス・プロバイダへのリクエストです。通常は、他の複数の操作を編成したり、特定のビジネス結果を達成するのに必要な操作で使用されます。
Process動詞を使用する場合
Processは、特定のビジネス・オブジェクト・アクションに対して複数の動詞が使用されるのを避けるために、コンテンツが更新されるがCreate/Update/Deleteカテゴリには該当しないすべてのビジネス操作をカテゴリ化する単独の動詞として使用されます。
Process動詞を使用する操作は、常に1つ以上のビジネス・オブジェクトが作成または更新される必要があり、他の操作の編成を表すことができます。
Process動詞は、単一のビジネス・オブジェクトに対して動作する操作でも使用できますが、Update操作を使用して通信できないビジネス上の特定の意味があります。通常、このようなアクションは、異なるアクセス制御、およびアクションの実行時に適用可能な特定のビジネス・ルールを使用してアプリケーションに実装されます。このようなアクションの例として、状態の変更、機器のメーター値の更新などがあります。
Process動詞によって複数の操作を実行できるため、特定のEBSで複数のProcess動詞を使用することも可能です。
ヒント:
Process動詞を実装する操作は、同期または非同期で実装できます。これは、動詞を使用するすべての操作で一貫性のある実装パターンが適用される他の動詞とは異なります。
コンテンツ・ペイロード
Process動詞によって実行される操作の特性により、操作が実行されるビジネス・オブジェクトに含まれないが、操作によって実装されるビジネス・ルールでは必要なプロパティや値が必要になる場合があります。たとえば、受注の承認では、承認の一部としてコメントを記録できますが、コメント自体は受注のプロパティではありません。
通常、Process動詞を使用する操作のリクエストおよびレスポンス・ペイロードはアプリケーションのメソッド・シグネチャを反映できる必要があり、ペイロードを形成するコンテンツは、サービス操作が関連付けられたビジネス・オブジェクトから取得する必要があるという制限はありません。
これをサポートするために、各Process操作のペイロードはEBO定義からのコンテンツに制限されません。これは、EBMビジネス・コンテンツがEBOコンテンツまたはそのサブセットと同じ必要がある他のすべてのEBOと異なります。
注意:
現在、AIAでは、他のビジネス・コンポーネントからのコンテンツを使用するProcess EBMペイロードのアセンブルをサポートしていません。したがって、顧客パーティに対して定義されるクレジット検証のProcess操作では、Sales Order EBOからのコンテンツを含めてメッセージ・ペイロードを作成できません。
他の汎用動詞で使用されるリスト・パターンも適用可能ですが、一般的には適用しません。つまり、EBSには、Process操作の単一およびリスト実装の両方、またはいずれか1つが存在できます。すべてのEBOに対して単一およびリストの両方が一貫して作成される他の汎用動詞とは異なり、Processは対応する操作の要件によって動作します。
動詞属性
なし。
対応するレスポンス動詞
Process動詞は、各Process EBMのレスポンス・メッセージで使用されるProcessResponse動詞とペアになっています。
レスポンス動詞ペイロード
レスポンス動詞のペイロードは、各Process操作に固有で、操作の目的によって決まります。Process動詞のペイロードと同様に、レスポンスのコンテンツはEBOのコンテンツに制限されるという制限はありません。
Query動詞は、Queryメッセージのペイロードで提供されるコンテンツを使用してビジネス・オブジェクトに対して問合せを実行し、問合せに関連付けられた対応するレスポンス・メッセージを使用して問合せ結果を返すための、サービス・プロバイダへのリクエストです。オプションで、リクエスタはレスポンス・ペイロードの特定のサブセットをリクエストできます。
Query動詞を使用する場合
他の動詞と同様に、単一およびリスト・パターンが問合せにも適用されます。次の各項では、これらの各パターンに対するQueryの使用がリストされています。
ヒント:
同じ動詞が両方のパターンに適用されますが、適用可能な実装および属性は完全に異なります。
1つのインスタンスのみを返す単一オブジェクト問合せ
単一オブジェクト問合せ操作は、コール元がEBOを識別子で参照できる単純なIDによる取得操作です。これは、オブジェクトのIDを指定し、オプションでQueryCodeとResponseCodeをパラメータとその値のセットとともに指定して、ビジネス・オブジェクトの単一インスタンスをリクエストします。オブジェクトの識別子は、Query EBMのDataAreaで指定されます。
単一オブジェクト問合せでは、問合せで複数のオブジェクトが返される可能性を最小限にするために、他の問合せ基準はサポートされておらず、単純問合せのレスポンス・ペイロードは、問い合せるオブジェクトの単一インスタンスに制限されます。
単一オブジェクト問合せには次の要素が含まれます。
Query要素内のQueryCode (オプション)
単一オプション問合せのQueryCodeは主に、問合せのDataAreaで指定されるIdentification要素の補足として使用されます。問合せコードは、問合せを正常に実行するためにIDに加えて問合せサービス・プロバイダに通知する必要がある場合に、単一オブジェクト問合せで使用できます。コードは、問合せを調整したり、問合せコードに基づいて問い合せるオブジェクトを選択するために使用できます。
ヒント:
これを実現するために、サービス・プロバイダはこのようなコードの処理を実装する必要があります。現在、Oracle AIAでは、EOLの一部として汎用の問合せコードは事前定義されていません。
Query要素内のResponseCode (オプション)
ResponseCodeは、EBOのレスポンス・コンテンツをレスポンス・オブジェクトの特定のサブセットにフィルタ処理するように問合せサービス・プロバイダに指示する事前定義されたコードです。
汎用問合せの戻りペイロードは常にEBO全体で、デフォルトでは、QuerySalesOrder操作のレスポンス・ペイロードは常に、明細や出荷などを含むSalesOrder全体です。リクエスタがサービス・プロバイダに対して、子コンポーネントは不要でSalesOrderヘッダーのみを提供するようにリクエストする場合は、ResponseCodeをサービス・プロバイダへの指示として使用し、それに従ってレスポンス・ペイロードを作成できます。
ヒント:
これを実現するために、サービス・プロバイダはこのようなコードの処理を実装する必要があります。現在、Oracle AIAでは、EOLの一部として汎用のリクエストまたはレスポンス・コードは事前定義されていません。
コンテンツ・ペイロード
単一オブジェクト問合せのペイロードは常に、問い合せるオブジェクトのIDです。例7-2に示すように、これはDataAreaのIdentification要素内で指定します。
動詞属性
単純問合せにはオプションのgetAllTranslationsIndicatorがあり、翻訳可能なすべての要素について、サービス・プロバイダがすべての翻訳をレスポンスに挿入する必要があるかどうかを指定します。デフォルトでは、リクエストの言語でのみデータを返します。
前の説明に基づいて、複数の方法で単純問合せを作成できます。
IDのみを使用する単純問合せ:
単一オブジェクトの問合せ例として、ID="3006"を使用した注文書の問合せがあります。この例では、他のコードやパラメータは必要ありません。
QueryCodeを使用する単純問合せ:
例として、個人顧客と組織顧客の区別を保守するアプリケーションを考えてみます。単一顧客問合せサービスが存在しますが、問合せを正常に実行するために、サービス・プロバイダは問い合せるIDが組織に属するか個人に属するかを指示される必要があります。この場合は、QueryCodeを使用して個人/組織情報を通知できます。
複数のインスタンスを返すことができるリスト問合せ
単一オブジェクト問合せでは、IDによる単純検索以外の検索基準をサポートしておらず、オブジェクトの1つのインスタンスのみ返すことができます。その他の問合せはすべてリスト問合せとして扱われます。
リスト問合せは、問合せへのレスポンスで複数のレコードを返すことができ、複雑な問合せを作成する機能をサポートしています。
リスト問合せは、次の要素を使用して実装されます。
Query要素内のQueryCode (オプション)
リスト問合せのQueryCodeは、サービス・プロバイダがリスト問合せを使用して作成できる問合せを制限する方法として機能します。QueryCodeを使用しない場合、サービス・プロバイダは一般的に、後述するQueryCriteria要素を使用して通知できるすべての問合せをサポートできます。
これを実現するために、サービス・プロバイダはこのようなコードの処理を実装する必要があります。現在、Oracle AIAでは、EOLの一部として汎用の問合せコードは事前定義されていません。
Query要素内のResponseCode (オプション)
ResponseCodeは、EBOのレスポンス・コンテンツをレスポンス・オブジェクトの特定のサブセットにフィルタ処理するように問合せサービス・プロバイダに指示する事前定義されたコードです。リスト問合せの場合、これは問合せのResponseFilter要素を指定するかわりの代替メカニズムとして機能できます。
汎用問合せの戻りペイロードは、常にEBO全体です。たとえば、デフォルトでは、QuerySalesOrder操作のレスポンス・ペイロードは常に、明細や出荷などを含むSalesOrder全体です。リクエスタがサービス・プロバイダに対して、子コンポーネントは不要でSalesOrderヘッダーのみを提供するようにリクエストする場合は、ResponseCodeをサービス・プロバイダへの指示として使用し、それに従ってレスポンス・ペイロードを作成できます。
これを実現するために、サービス・プロバイダはこのようなコードの処理を実装する必要があります。現在、Oracle AIAでは、EOLの一部として汎用のリクエストまたはレスポンス・コードは事前定義されていません。
QueryCriteria (1からn個のインスタンス)
QueryCriteria要素を使用すると、ユーザーは、問い合せるオブジェクトの特定ノード上に複雑な問合せ文を作成できます。リスト問合せでは、少なくとも1つのQueryCriteria要素を指定する必要があります。
問い合せるオブジェクトの複数ノードに問合せ範囲がわたる場合、1つの問合せに複数のQueryCriteria要素が存在できます。複数の問合せ基準は、1つの問合せ基準の結果セットが2番目の基準でフィルタ処理されて、レコードのサブセットがさらに絞り込まれていく部分選択に似ています。
各QueryCriteria要素の構成は次のとおりです。
QualifiedElementPath (0または1個のインスタンス):
これを使用すると、ユーザーはQueryCriteriaを適用するノードを指定できます。要素が問合せに含まれていない場合、要素が含まれているが値がないかNULL値の場合、または要素の値が/の場合、問合せ基準はオブジェクトのルート要素に適用されます。
QueryExpression (1個のインスタンスのみ、オプションで他のQueryExpressionがネストする): この要素は、実際の問合せのコンテナです。QueryExpressionはネストされた構造で、これによって複雑な問合せを定義できます。各QueryExpressionの構成は次のとおりです。
logicalOperatorCode属性(可能な値はANDまたはORのいずれか)。これらの属性を指定して、QueryExpression内のコンテンツ(ネストされた複数のQueryExpressionまたはValueExpressionのリスト)に対して実行される論理演算を指定できます。
1つ以上のQueryExpressionまたは1つ以上のValueExpressionの選択。
1つのQueryExpressionに他の複数のQueryExpressionを含めることができ、その場合は問合せ内で複数のANDまたはOR演算を結合する必要があります。
問合せが1つのANDまたはOR演算子を使用して表すことができる場合は、外側のQueryExpression内に複数のValueExpressionを使用して作成できます。
ValueExpression (1個以上のインスタンス):
各ValueExpressionは、QualifiedElementPath (QualifiedElementPathが存在しない場合はルート・ノード)で表されるノード内での特定ノードへの値の割当を表します。ValueExpressionは次を使用して指定されます。
問合せ値が割り当てられるノード(simpleXPath式として表される)、またはコード(ドキュメントに要素が見つからない場合)のいずれかを表すElementPath要素。たとえば、/SalesOrderLine/Status/CodeまたはStatusCodeです。ElementPathに含まれるのがコードかXpath式かを示す明示的な方法はありません。
ElementPathに割り当てられた値を含むValue要素(例: Approved)。
ElementPathに割り当てられた値に適用可能な演算子を指定するqueryOperatorCode属性。可能な演算子は、EQUALS、NOT_EQUALS、GREATER_THAN、GREATER_THAN_EQUALS、LESS_THAN、LESS_THAN_EQUALS、CONTAINS、DOES_NOT_CONTAIN、LIKE、NOT_LIKE、LIKE_IGNORE_CASE、NOT_LIKE_IGNORE_CASE、IS_BLANK、IS_NOT_BLANK、BETWEEN、NOT_BETWEEN、IN、NOT_INです。
SortElement (0個以上のインスタンス):
例7-4に示すように、各QueryCriteriaには1つ以上のSortElementを定義できます。SortElementを使用して、SortElementに指定された基準を使用して問合せ結果セットをソートするようにリクエストします。各SortElementにはオプションのsortDirectionCode属性があり、ソート順としてASC (昇順)またはDESC (降順)を識別します。
例7-4では、QueryExpressionの結果セットがOrderDateTimeの降順およびDescriptionの昇順にソートされます。
複数のQueryCriteriaが存在する場合は、例7-5に示すように、それぞれに独自のSortElementがあります。1つのQueryCriteriaの結果セットがソートされた後に、次のQueryCriteriaフィルタが適用され、そのQueryCriteriaで指定されたSortElementを使用して結果のサブセットがソートされます。
例7-5では、SalesOrderルート問合せがOrderDateTimeとDescriptionによってソートされ、子ノードのSalesOrderLineは価格でソートされます。
QueryCriteriaの例
例7-3は、単一のQueryCriteria要素、およびValueExpression要素のみが含まれる単一のQueryExpression要素を持つ問合せの例です。実行される問合せはQuery SalesOrderで、"SalesOrder/CurrencyCode = "USD" AND "SalesOrder/OrderDateTime = "2003-12-04"です。問合せ式はルート・ノードに定義されているため、QualifiedElementPathはありません(オプション)。
これは、QueryExpression内にネストされた2つのValueExpressionとしてモデル化されています。QueryExpressionにあるlogicalOperatorCodeは、2つのValueExpressionで実行される演算(AND)を示します。
図7-13は、単一のQueryCriteriaおよびネストされたQueryExpressionを持つ問合せの例です。実行される問合せはQuery SalesOrdersで、SalesOrder/CurrencyCode=USD AND SalesOrder/OrderDateTime<2003-12-04 OR SalesOrder/Description CONTAINS "BMW 520i"です。両方の問合せ式はルート・ノードに定義されているため、QualifiedElementPathはありません(オプション)。
注意: ネストされたQueryExpressionが存在する場合、それらはすべて同じQualifiedElementPath上にあります。
これは、外部のQueryExpression内にネストされた2つのQueryExpressionとしてモデル化されています。
外部のQueryExpressionは、内部の2つのQueryExpressionに適用されるオペランド(OR)を識別します。図7-13に示すように、ValueExpressionには、実際の問合せデータとともに、データ要素に適用される問合せ演算子が含まれます。
図7-13 ネストされたQuery Expressionを持つ問合せの例
例7-6は、複数のQueryCriteriaを持つ問合せの例です。複数のQueryCriteriaが存在する場合、それらに適用可能な論理演算は存在せず、1番目のQueryCriteria要素で指定された問合せが実行され、次に2番目のQueryCriteriaが1番目の結果に適用されるのと同等です。
実行される問合せはQuery CustomerPartyで、Type = GOLD、結果セットはステータスが"ACTIVE"なアカウントのみにフィルタ処理されます。
これは2つのQueryCriteriaとして実装されます。1番目は、CustomerPartyを問い合せて、TYPEが"GOLD"の顧客をすべて取得します。この問合せは、CustomerPartyルート・ノードで実行されます。
次に、この問合せの結果セットは、2番目のQuery Criteriaを適用してフィルタ処理されます。これは、CustomerParty/Accountノードを問い合せて、STATUS = "ACTIVE"のCustomerPartyアカウントをすべて取得します。
ResponseFilter (0から1個のインスタンス)
ResponseFilterを使用すると、リクエスタは対象または対象外の子ノードを指定できます。除外された子ノードは、問合せへのレスポンスが作成されるときに挿入されません。この機能が参加アプリケーションによってサポートされている場合は、問合せから除外されたノードを問い合せないことによってパフォーマンスが向上します。
例7-7に、QueryInvoiceメッセージへのレスポンスでInvoiceLineのみ戻すリクエストを示します。
例7-8は、ChargeとPaymentTermを除くすべてのQueryInvoiceメッセージ・コンテンツを戻す例です。
ヒント:
理論上は問合せを作成する方法は無限にあり、サービス・プロバイダはQueryCriteriaが指定される可能なすべての方法を処理できないため、問合せを処理するための包括的なフレームワークを使用しないと、このオプションを実際に実装するのは困難です。
コンテンツ・ペイロード
リスト問合せで使用できるコンテンツ・ペイロードはなく、問合せはDataAreaの動詞要素内で完全に定義されます。
動詞属性
getAllTranslationsIndicator(オプション):
問合せにはオプションのgetAllTranslationsIndicatorがあり、翻訳可能なすべての要素について、サービス・プロバイダがすべての翻訳をレスポンスに挿入する必要があるかどうかを指定します。デフォルトでは、リクエストの言語でのみデータを返します。
recordSetStart(オプション):
これは、問合せサービス・プロバイダに対して、問合せ結果セットからレコードのサブセットを返し、この属性に指定した番号を最初のレコードの索引に付けるように指示します。
例として、結果セットに200レコードを返す問合せを考えてみます。リクエスタがrecordSetStartパラメータを"101"に設定して問合せを呼び出した場合、サービス・プロバイダはこの値を処理し、結果セットの101番目から200番目のレコードを含む結果セットを作成する必要があります。
recordSetCount(オプション):
この属性は、サービス・プロバイダに対して、問合せへのレスポンスでレコード件数とともに同じ属性を返すように指示します。この属性を使用しない場合、問合せへのレスポンスでレコード・セット件数は不要です。
maxItems(オプション):
これは、問合せサービス・プロバイダに対して、問合せレスポンスで返されるレコードの最大数がこの属性に指定した値を超えないように指示します。
問合せの結果セットには問合せ基準を満たす複数のレコードが含まれる場合がありますが、問合せサービス・リクエスタは特定のレコード数のみを一度に処理できます。たとえば、問合せによって1000レコードの結果セットが作成されましたが、問合せリクエスタは一度に100レコードのみ処理できます。サービス・リクエスタはmaxItems属性を使用して、サービス・プロバイダに対してレスポンスで100レコードのみ返すように指示できます。
対応するレスポンス動詞
Query動詞は、各Query EBMのレスポンス・メッセージで使用されるQueryResponse動詞とペアになっています。
レスポンス動詞ペイロード
通常、レスポンス動詞のペイロードはビジネス・オブジェクト全体です。
例7-2 単一オブジェクト問合せのコンテンツ・ペイロード
<QueryAccountBalanceAdjustmentEBM>
<corecom:EBMHeader>
</corecom:EBMHeader>
<DataArea>
<Query>
</Query>
<QueryAccountBalanceAdjustment>
<corecom:Identification>
<corecom:ID>1005</corecom:ID>
</corecom:Identification>
<Custom/>
</QueryAccountBalanceAdjustment>
</DataArea>
</QueryAccountBalanceAdjustmentEBM>
例7-3 単一のQueryCriteriaに対するSortElementの定義
<Query>
<QueryCriteria>
<QueryExpression logicalOperatorCode="AND">
<ValueExpression queryOperatorCode="EQUALS">
<ElementPath>/SalesOrderBase/CurrencyCode</ElementPath>
<Value>USD</Value>
</ValueExpression>
<ValueExpression queryOperatorCode="GREATER_THAN_EQUALS">
<ElementPath>/SalesOrderBase/OrderDateTime</ElementPath>
<Value>2003-12-04</Value>
</ValueExpression>
</QueryExpression>
</QueryCriteria>
</Query>
例7-4 複数のQueryCriteriaに対するSortElementの定義
<QueryCriteria>
<QueryExpression>
<ValueExpression>
</ValueExpression>
</QueryExpression>
<SortElement sortDirection="DESC">/OrderDateTime</SortElement>
<SortElement sortDirection="ASC">/Description</SortElement>
</QueryCriteria>
例7-5 単一のQueryCriteria要素および単一のQueryExpressionを持つ問合せの例
<QueryCriteria>
<QueryExpression>
<ValueExpression>
</ValueExpression>
</QueryExpression>
<SortElement sortDirection="DESC">/OrderDateTime</SortElement>
<SortElement sortDirection="ASC">/Description</SortElement>
</QueryCriteria>
<QueryCriteria>
<QualifiedElementPath>/SalesOrderLine/SalesOrderLineBase</QualifiedElementPath>
<QueryExpression>
...
</QueryExpression>
<SortElement>/SalesOrderLine/SalesOrderLineBase/ListPrice</SortElement>
</QueryCriteria>
例7-6 複数のQueryCriteriaを持つ問合せの例
<Query>
<QueryCriteria>
<QueryExpression>
<ValueExpression queryOperatorCode="EQUALS">
<ElementPath>/Type</ElementPath>
<Value>GOLD</Value>
</ValueExpression>
</QueryExpression>
<SortElement>/LastName</SortElement>
</QueryCriteria>
<QueryCriteria>
<QualifiedElementPath>/CustomerAccount</QualifiedElementPath>
<QueryExpression>
<ValueExpression queryOperatorCode="EQUALS">
<ElementPath>/CustomerAccount/Status/Code</ElementPath>
<Value>ACTIVE</Value>
</ValueExpression>
</QueryExpression>
</QueryCriteria>
</Query>
例7-7 QueryInvoiceメッセージへの単一の戻しのリクエスト
<Query>
<QueryCriteria>
</QueryCriteria>
<ResponseFilter>
<ChildComponentPath>InvoiceLine</ChildComponentPath>
</ResponseFilter>
</Query>
例7-8 QueryInvoiceメッセージへの特定のメッセージ戻しのリクエスト
<Query>
<QueryCriteria>
</QueryCriteria>
<ResponseFilter>
<ExclusionIndicator>true</ExclusionIndicator>
<ElementPath>Charge</ElementPath>
<ElementPath>PaymentTerm</ElementPath>
</ResponseFilter>
</Query>
この項は、ABCSの作成が完了していることを前提としています。ここでは、ABCSを呼び出す様々な方法について説明します。
ABCSは、アプリケーションまたは別のサービスによって呼び出すことができます。このサービスがAIAアーティファクトの場合は、トランスポート・アダプタまたはEBSのいずれかになります。この項では、3つのシナリオでそれぞれ実行する内容を説明します。
この項には次のトピックが含まれます:
アプリケーションとABCSとのインバウンド相互作用の場合:
参加アプリケーションの識別から開始します。
各参加アプリケーションの統合機能を分析します。
アプリケーション・プロバイダ(開発者)と協力して、必要な機能を実現するためにアプリケーションと相互作用する最適な方法を決定します。
相互作用メカニズムには次のいずれかを使用できます。
SOAP Webサービス
イベント/キュー
JCA
参加アプリケーションとABCS間の相互作用にメッセージ・キュー・アダプタまたはJCAアダプタを使用する場合は、アプリケーションから関連する詳細を取得します。
これらの詳細は、アダプタの構成で使用されます。構成によってWSDLが作成されます。環境固有の詳細が、WSDLに直接ではなく、サーバー上の関連リソース・ファイルに構成されていることを確認してください。
トランスポート・アダプタによってリクエスタABCSが呼び出されると、ABCSとトランスポート・アダプタ間の相互作用ではSOAP Webサービスまたはネイティブのバインディングのいずれかを使用します。
詳細は、「トランスポート・アダプタとのインタフェース」で指定します。
アダプタとABCS間におけるインバウンド接続の確立の詳細は、「リソース接続の確立」を参照してください。
