| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、Oracle Application Integration Architecture (AIA)サービスが外部ソースと相互作用する方法、およびインバウンド接続とアウトバウンド接続について説明します。最後の項では、SiebelアプリケーションおよびOracle E-Business Suiteに固有の接続の確立に関するガイドラインを説明します。
この章の内容は次のとおりです。
参加アプリケーションがビジネス・プロセスを実行します。これは、ビジネス・プロセスのイニシエータであるか、またはビジネス・プロセスの1つ以上のステップで役割を果たします。AIAレイヤーの観点から見ると、参加アプリケーションとビジネス・プロセスとの相互作用は、アウトバウンドまたはインバウンドのいずれかになります。
ビジネス・プロセスは、様々な参加アプリケーションとのアウトバウンドとインバウンド相互作用の組合せです。
図14-1に示すように、インバウンドとはAIAレイヤーへのインバウンドを意味します。
図14-1に、参加アプリケーションがビジネス・プロセスとインバウンド相互作用する方法を示します。CRMアプリケーション内のモジュールを取得するために「発行」ボタンをクリックすると、注文履行ビジネス・プロセスが開始されます。
AIAサービスによって公開されたサービスは、アプリケーションで作成されたプロキシによって呼び出されます。AIAとのインバウンド相互作用は、参加アプリケーションによるイベントの通知やブロードキャストのため、または外部ソースから情報を取得するために発生します。たとえば、CRMモジュールで勘定残高の取得ボタンをクリックすると、SOAPメッセージがHTTP経由で送信されてAIAサービスが呼び出されます。
アプリケーションは、メッセージをJMSキューとトピックにプッシュします。JMSサーバーは登録済のJMSアダプタ・エージェントをトリガーし、JMSアダプタ・エージェントはAIAサービスをトリガーします。たとえば、CRMモジュール内での顧客の作成や注文の発行によって、AIAへのこれらのイベントのブロードキャストが、JMSキューおよびトピックへのメッセージの形式でトリガーされます。
図14-1 インバウンド接続の例
図14-2に示すように、アウトバウンドとはAIAレイヤーからのアウトバウンドを意味します。
AIAサービスは、アプリケーションによって公開されたサービスを呼び出します。AIAサービスはアプリケーション・サービスまたは外部サービスを呼び出して、追加情報の取得、ビジネス・イベントの送信、またはタスクの実行のリクエストを行うことができます。たとえば、CRMモジュールで注文を作成したり、既存の顧客の注文をCRMモジュールで発行するときに請求アプリケーションで顧客を作成しますが、その顧客のプロファイルを請求アプリケーションで使用できないとします。ほとんどの製造システムは、品目が追加されるとイベントを公開しますが、このイベントには品目に関する最小限の情報しか含まれていません。イベントを使用するAIAサービスは、アプリケーション・サービスを呼び出して、その品目に関する完全な情報を取得する必要があります。
AIAサービスは、JCAアダプタを使用してアプリケーションと相互作用し、メッセージをJMSキュー/トピックにプッシュします。JMSサーバーは、アプリケーションによって登録されたJMSアダプタ・エージェントをトリガーします。
図14-2に、ビジネス・プロセスがアウトバウンド相互作用する方法を示します。このビジネス・プロセス内のステップによってCRM注文獲得アプリケーションが呼び出され、注文ステータスの更新が送信されます。
図14-2 アウトバウンド接続の例
参加アプリケーションは、インバウンドおよびアウトバウンドの相互作用で様々なタイプのメカニズムを使用します。
次の各項では、参加アプリケーションがAIAアーキテクチャと相互作用するためのガイドラインと推奨事項を示します。
この項には次のトピックが含まれます:
注意:
この項の内容は、一般的なガイドラインと推奨事項のみです。AIAサービスのプログラミング方法は参加アプリケーションの機能によって異なり、参加アプリケーションによってはこの項で説明する機能を備えていない場合があります。提供されている機能については、該当するアプリケーション固有のガイドを参照してください。
インバウンド相互作用の場合、参加アプリケーションは、AIAがWebサービスとして提供するアプリケーション・ビジネス・コネクタ・サービス(ABCS)を呼び出します。参加アプリケーションは、ABCS WSDLを使用してABCS Webサービスを呼び出します。ABCS WSDLは、スタブまたはプロキシを作成するために参加アプリケーションで使用されます。これらは参加アプリケーション内で呼び出され、ABCSの呼出しへと続きます。
図14-3に示すように、外部システムに存在する情報をフェッチする場合のみ、参加アプリケーションがWebサービス・トランスポートを利用してAIAサービスを呼び出すことをお薦めします。たとえば、CSRまたはセルフサービス・アプリケーション画面で、CRMアプリケーションを使用して請求アプリケーションから顧客の勘定残高詳細を問い合せます。
図14-3 SOAP/HTTPを使用したWebサービスの使用
その他のタイプの相互作用(顧客の作成、注文の発行など)では、相互作用が確実に信頼できてトランザクションであるために、JCAまたはJMSトランスポートのいずれかを使用することをお薦めします。参加アプリケーションにJMSまたはJCAトランスポートのいずれかを使用してイベントをAIAレイヤーに公開する機能がない場合は、Webサービス・トランスポートを使用すると、今後の処理のためにイベントをAIAレイヤーのキューに公開できます。
ABCSは参加アプリケーションからのスキーマを使用して開発されるため、アウトバウンド・メッセージ書式とABCSメッセージ書式は同じです。
インバウンド相互作用
インバウンド・メッセージには次の属性があります。
メッセージID
メッセージIDは、アプリケーションによって生成されるメッセージの一意の識別子で、メッセージにスタンプされます。たとえば、顧客IDまたは注文IDはペイロード内で一意です。
メッセージ・ペイロード名
ビジネス・オブジェクトの名前は渡される必要があります。
参加アプリケーション・インスタンス
エンティティIDの相互参照を設定するにはアプリケーション・インスタンスの一意の識別子が必要であるため、これもペイロードに含める必要があります。
イベント・セッション・ロケール
クライアント・セッションからのロケール情報によって、アプリケーションで実行されるリクエストにコンテキストが提供されます。これは、レスポンスが同じロケール・コンテキスト内にあることを確認するのに役立ちます。ロケール固有のヘッダーについては、アプリケーション・チームが検討してABMヘッダー属性を決定する必要があります。ロケール固有の情報を設定および取得することは、ABCS実装でABMのリクエストとレスポンスの変換ステップを実行する際のファクタの1つです。
アウトバウンド相互作用
アウトバウンド相互作用の場合、ABCSは、Webサービスとして公開された参加アプリケーションAPIを呼び出します。参加アプリケーションのWebサービスのWSDLは、ABCSによって使用されます。
SOAP/HTTPを使用するWebサービスを利用して、アプリケーションから情報をフェッチし、その情報をリクエスタに提供できます。これは、相互作用の信頼性に対する要件が低く、操作が情報ストアの問合せに限定される場合に役立ちます。
メッセージ書式はXML (Extensible Markup Language)です。
このモードの接続は、次の場合にAIAで使用されます。
リクエスト/レスポンス
リクエストのみ
SOAPクライアントは、HTTP GETメソッドを使用して、指定されたリソースの表現をリクエストします。SOAPサーバーは、実行可能ファイルをトリガーして出力とともにレスポンスします。これは多重呼出し不変アクションで、複数の同じリクエストの結果が単一のリクエストと同じ結果になることを意味します。
たとえば、顧客営業担当は、顧客マスター・データ管理システムに新規顧客を作成する前に、顧客が存在するかどうかをシステムに問い合せます。
SOAPクライアントは、HTTP POSTを使用して、(たとえば、HTMLフォームから)処理されるデータを特定のリソースに発行します。データは、リクエストの本文に含まれます。これによって、新規リソースの作成、既存のリソースの更新、またはその両方が発生する場合があります。これは多重呼出し不変ではないアクションであるため、同じPOSTリクエストを複数回送信すると、状態に影響を与えて、悪影響をもたらす可能性があります。
たとえば、顧客は処理対象の注文をコンポジット・アプリケーションUIから発行します。
XML形式のメッセージは処理が遅いため、メッセージのサイズを小さくしたり、圧縮技術を利用する必要があります。
HTTPは本質的にステートレス(呼出し間でデータを保持しない)であるため、コールごとに明示的なログインが必要になり、パフォーマンスのオーバーヘッドが発生します。
状態管理を伴うアトミック・トランザクションの概念はサポートされていません。回避策は、複数のリクエストで接続を再利用するセッション状態管理です(「SOAP/HTTPを使用したWebサービスでの状態管理」を参照)。
AIAでは、相互運用性を促進するために、開発およびデプロイされるWebサービスが公開済のWS-Iに準拠する必要があります。
WS-Securityを利用して、SOAPでXML暗号化およびXML署名を使用するメッセージ交換を保護するか、またはHTTP (HTTPS)を使用します。
WS-Addressingを利用して、アドレスをSOAPヘッダーに挿入します。
WS-ReliableMessagingを利用して、ソフトウェア・コンポーネント、システムまたはネットワークの障害がある場合でも、分散アプリケーション間でメッセージの信頼性のある配信が行われるようにします。
ステートレスでアトミック・トランザクションをサービスできないというHTTPの短所を解消するには、セッション管理が必要です。この項には次のトピックが含まれます:
セッションには次の3タイプがあります。
None
新規セッションがリクエストごとに開き、レスポンスが送信されると閉じます。
Stateless
最初のリクエストで新規セッションが開き、後続のリクエストではセッションは開いたままになります。セッションが閉じた場合は、再ログインが自動的(ユーザーには透過的)に発生します。ステートレス・セッションを開くには、最初のリクエストにSOAPヘッダーとしてUsernameTokenおよびPasswordTextが含まれる必要があります。
Stateful
最初のリクエストで新規セッションが開き、後続のリクエストではセッションは開いたままになります。セッションが閉じた場合、再ログインは自動的に発生しません。ステートフル・セッションを開くには、最初のリクエストにSOAPヘッダーとしてUsernameTokenおよびPasswordTextが含まれる必要があります。
StatelessまたはStatefulモードでは、WebサービスはSOAP: HEADERのSessionTokenを返す必要があります。これは、アプリケーション実装によって決まります。
SessionTokenは、Session ID、UserTokenおよびPasswordTextの暗号化です。
ステートレスまたはステートフルの各コールでは、更新されたSessionTokenが返されます。これは、再生攻撃に対して安全な方法です。
SessionTokenを更新するプロセスでは、セッションを閉じません。したがって、更新されたセッション・トークンを使用する次のコールで、再ログインはありません。セッションは開いたままになります。セッションが閉じるのは、セッション・タイプがNoneに設定されてコールがポストされるか、タイムアウトが発生した場合です。2番目のコール後には2つのセッション・トークンがあり、1つは1番目のコールで戻され、更新されたもう1つは2番目のコールから戻されます。この時点では、いずれかのSessionTokenを3番目のコールに送信できます(3番目のSessionTokenが返されます)。セッション・タイプをNoneに設定してコールをポストするとセッションIDが終了するため、すべてのセッション・トークンが無効になります。
SiebelアプリケーションのURLおよびSOAPヘッダーの例
例14-1、例14-2および例14-3に、SiebelアプリケーションのURLおよびSOAPヘッダーの例を示します。
SOAPヘッダーは次のようになります。
レスポンスは次のようになります。
例14-1 Siebelアプリケーションをコールしてログイン情報をSOAPヘッダーに渡すURL
http://sdcp1952i028.corp.siebel.com/eai_enu/start.swe?SWEExtSource= SecureWebService&SWEExtCmd=Execute&WSSOAP=1
例14-2 SOAPヘッダー
<soapenv:Header> <UsernameToken xmlns="http://siebel.com/webservices">rreddy</UsernameToken> <PasswordText xmlns="http://siebel.com/webservices">rreddy</PasswordText> <SessionType xmlns="http://siebel.com/webservices">Stateless</SessionType></soapenv:Header>
例14-3 SOAPヘッダーへのレスポンス
<SOAP-ENV:Header> <siebel-header:SessionToken xmlns:siebel-header="http://siebel.com/webservices">0f2cnvf0Ii5qsp-zk- SEyjl2p0JD-QdYLt1LYvARXQMZfAL9YL.THekJHI1cVjZbBGQckQN. cIfOGPKWKwUd6E0D4LD.VS.CKWsXw...</siebel-header:SessionToken> </SOAP-ENV:Header>
アプリケーションに対する多数の同時リクエスト/レスポンス・コールが必要なビジネス統合フローの場合は、コールごとにユーザー資格証明を送信するのではなく、セッション・トークン情報を送受信することをお薦めします。
セッション・プール・マネージャは、後続のリクエストで再利用されるセッション・トークンのプールを管理するサービスです。
セッションは、メモリーまたはデータベースのいずれかに保持されます。
ログイン資格証明とURLは、管理者がセッション・プール・マネージャで構成します。
セッション・プール・マネージャの実装はアプリケーション固有で、Webサービス・フレームワークの実装を考慮する必要があります。
この項では、SOAP/HTTPを使用したWebサービスのエラー処理について説明します。
参加アプリケーションは、フォルト・メッセージを定義したWSDLを使用する機能が必要です。
参加アプリケーションに提供されるWSDLは、BPEL (ABCS)を使用して作成される粒度の粗いリクエスト/レスポンス・サービスに対して生成されます。これらのサービスの入出力ペイロードは、参加アプリケーションが提供するスキーマです。アプリケーションが提供するフォルト・スキーマは、サービス(WSDL)の定義にアプリケーションを組み込むのに役立ちます。
参加アプリケーションからのコールが成功しない
AIAレイヤーはHTTP 4xxクライアント・エラーを返し、参加アプリケーションは手動または自動で再発行するメカニズムを備えている必要があります。
例: FMWが停止して、AIAサービスにアクセスできない。
参加アプリケーションからのコールは成功したが、システム・リソースにアクセスできない
AIAレイヤーは5xxクライアント・エラーを返し、参加アプリケーションは手動または自動で再発行するメカニズムを備えている必要があります。
例: AIAサービス実行から、相互参照データベースにアクセスできない。
参加アプリケーション・サービスのWSDLに名前付きフォルトが含まれる
この場合、WSDLには、指定のフォルト・メッセージ書式による名前付きフォルトが含まれます。AIAサービスは、ビジネス・エラーが発生すると、エラー情報をフォルト・メッセージに挿入して、コール元サービスにリプライします。参加アプリケーションは、それに応じて処理を実行します。
例: 無効なオプションが指定された注文がCRMアプリケーションからERPアプリケーションにプッシュされ、ERPアプリケーションでの検証が失敗しました。AIAサービスは、フォルトを受け取ると、適切なエラー・メッセージを作成し、そのメッセージをCRMアプリケーションのフォルト・スキーマに変換して、名前付きフォルトとして返送します。
参加アプリケーション・サービスのWSDLに名前付きフォルトが含まれない
この場合は2つの可能性があります。
WSDLレスポンス・メッセージに、エラーを指定するためのコンポーネントと要素がある
この場合、AIAサービスは、ビジネス・エラーが発生すると、エラー情報をレスポンス・メッセージのフォルト・コンポーネントと要素に挿入して、コール元サービスにリプライします。参加アプリケーションは、それに応じて処理を実行します。
WSDLに、フォルト情報を受け取るための有効な方法が指定されていない
次の2つのオプションがあります。
AIAサービスで使用されているFMWコンポーネントがSOAPフォルトをサポートしている場合は、フォルトをSOAPフォルトとして返信します。
リクエストのみとして相互作用をモデル化し、各参加アプリケーションのWebサービスが結果を受信するようにプロビジョニングします。
参加アプリケーションは、WSセキュリティのユーザー名トークン・プロファイル書式で認証情報を受け取る必要があります。これらは、リクエストを設計および復号化し、レスポンスを署名および暗号化できる必要があります。可能な場合は、SOAPヘッダー内で認証情報をxacml書式で受け取ります。
参加アプリケーションは、インバウンド相互作用のためにメッセージをキュー(JMS、AQ、MQ、MSMQなど)にエンキューできます。参加アプリケーションは、発生した様々なイベントに関するメッセージを作成し、そのメッセージを指定のキューにエンキューします。これらのキューをサブスクライブしているAIAサービスがトリガーされます。これらは実質的に非同期です。メッセージのキューへの公開は、アプリケーション内で発生したのと同じトランザクションに含まれる必要があります。
また、参加アプリケーションは、アウトバウンド相互作用のためにメッセージをキュー(JMS、AQ、MQ、MSMQなど)からデキューできます。AIAサービスは、発生した様々なイベントに関するメッセージを作成し、そのメッセージを指定のキューにエンキューします。これらのキューをサブスクライブしている参加アプリケーションは、メッセージをデキューして処理します。これらは実質的に非同期です。メッセージのキューへの公開は、AIAサービス内で発生したのと同じトランザクションに含まれる必要があります。
キューイング・メカニズムは実質的に非同期です。これは、一方向コールで構成されます。
ペイロードがないイベント通知の場合は、イベントをサブスクライブしているか、またはイベントをポーリングしているABCSアダプタがメッセージを参加アプリケーションから取得します。一連のイベントがトリガーされますが、参加アプリケーションから取得される更新済エンティティのスナップショットがイベントに対応する保証はありません。データの整合性が失われないように、イベントはユーザーがトリガーすることをお薦めします。この場合、メッセージの順序付けはできません。
イベント通知の保証付き配信を確保するには、これらの通知でAIAレイヤーからの確認を受信でき、参加アプリケーションでこれらのイベント通知の再送信や適切なエラー処理を実行できる必要があります。これらのイベントはすべて、AIAレイヤーでIDまたはタイムスタンプに基づいて保持および集約され、データの整合性を保つために定期的に処理される必要があります。
イベントが発生したためにメッセージがキューされると、メッセージはエンティティ状態のスナップショットを取得します。エンティティに一連の操作が密接に連続してある場合は、同じエンティティに対する異なる状態の一連のメッセージがキューに到着します。処理されるメッセージでネットワーク遅延やエラーが発生すると、そのような状態にあるメッセージの順序は保証できません。
いくつかの要件が満たされると、AIAサービスはメッセージを正しい順序で処理できます。
メッセージの順序付けの要件
メッセージが順序付けされるには、順序付けが必要な一連のメッセージが定義される必要があります。さらに、すべてのメッセージが順序内で識別可能であることが必要です。
順序付けされるメッセージ・セットの識別子
グループIDのような名前付きパラメータが定義されます。共通する値を持つすべてのメッセージは、同じグループ、つまり順序付けされるメッセージのセットに含まれます。
順序付けされるメッセージの識別子
順序IDのような名前付きパラメータが定義されます。このパラメータの値は、数値または日時です。この値によって、各メッセージの順序内での位置が決まります。
2つの基準のいずれかを満たすと、キュー/トピックを使用したメッセージの伝播を使用できます。
プロセスをアトミック・トランザクションに分割する必要があります。
イベント・トリガー・システムは、メッセージが処理されるまで待機できません。
次の2タイプがあります。
キュー
トピック
キュー
キューとは、処理前の要素を保持するように設計された永続的な格納メカニズムです。
注意点は次のとおりです。
キューはポイントツーポイントです。
メッセージを取得するのは1つのコンシューマのみです。
コンシューマがメッセージを使用する時点でプロデューサが実行中である必要はなく、メッセージが送信された時点でコンシューマが実行中である必要もありません。
正常に処理されたすべてのメッセージは、コンシューマによって確認されます。
キューを使用する際の考慮事項
キューを使用する際は、次の点を考慮してください。
参加アプリケーションとのインバウンドおよびアウトバウンド相互作用では、WLSJMSキューを使用することをお薦めします。
アプリケーションがAIAと互換性がなかったり、WLSJMSを使用してAIAとの間でメッセージを送受信できない場合は、サポートされている他のメッセージングを使用する必要があります。たとえば、アプリケーションと相互作用するには、ネイティブのWLSJMSで、AQJMSやTIBCOJMS、必要な外部JMSサーバーを設定する必要があります。
WLSJMSキューに対してファイル・ベースの永続ストアを構成することをお薦めします。バルク・メッセージ、ポリシーまたはビジネス要件に対してデータベース永続性の使用が必要な場合は、データベース永続性を構成します。永続ストアをファイル・ベースで構成するか、またはデータベース・ベースで構成するかは、デプロイメント時に決定できます。
SOAコア拡張機能のインストール・ドライバは、各キューのエラー・キューを自動的に作成します。
エラー・キュー名を生成するには、SOAコア拡張機能のデプロイメント計画ジェネレータのスクリプトで、注釈からリソース名を使用してキューまたはトピック名を取得し、「_ErrorQ」を接尾辞として追加します。たとえば、AIASalesOrderQueueの場合、生成されるエラー・キューはAIASalesOrderQueue_ErrorQになります。
SOAコア拡張機能のインストール・ドライバは、デプロイメント計画を使用して、WLSで作成するJMSキューごとに生成されるエラー・キュー名の作成、構成または割当を行います。
SOAコア拡張機能によって、エラー再発行ユーティリティからすべてのエラー・キューに接続するために、汎用の非XAの接続ファクトリが1つ作成されます。汎用の接続ファクトリの名前はAIAErrorQueueConnectionFactoryです。
汎用のエラー接続ファクトリは、SOAコア拡張機能インストール時に作成されます。エラー・キューの生成は、注釈に基づいて事前作成済の統合のインストール時に発生します。
統合フローのマイルストンごとに、ファイル・ベースの永続ストアとともにWLSJMSキューを使用することをお薦めします。
トピック
トピックとは、処理前の要素を保持するように設計された永続的な格納メカニズムです。処理のために、メッセージが複数のサブスクライバに配信されます。
注意点は次のとおりです。
複数のコンシューマがメッセージを取得できます。
パブリッシャとサブスクライバの間には、タイミング依存性が存在します。クライアントがサブスクライブできるように、パブリッシャはサブスクリプションを作成する必要があります。サブスクライバは、永続サブスクリプションを確立しないかぎり、引き続きアクティブなままでメッセージを受信します。この場合、サブスクライバが接続されていない間に公開されたメッセージは、再接続されるたびに再配されます。
パブリッシュ/サブスクライブ・モデルの場合は、WLSJMSトピックを使用することをお薦めします。
保証付きメッセージ配信とは、送信側システムから開始されたメッセージが正常に配信されて受信者に確認(確認が必要な場合)されるまで、そのメッセージが保持されることを意味します。この配信方法によって、メッセージはどのような状況でも失われません。
送信側と受信側は必ずしも参加アプリケーションである必要はありません。むしろ、これらはビジネス・プロセスの論理的なマイルストンになります。図14-4および図14-5に示すように、複数のマイルストンが存在できます。
図14-4 ビジネス・プロセスでの複数のマイルストンの例(1/2)
図14-5 ビジネス・プロセスでの複数のマイルストンの例(2/2)
ハードウェアまたはソフトウェア・サービスが一時的に使用不可になっている場合もメッセージの消失や配信の失敗は発生せず、メッセージは確実に配信されます。
エラー処理フレームワークには、ハードウェアまたはソフトウェア・サービスが再試行可能になるまでメッセージを保持し、訂正後にメッセージを再処理したり、既存のメッセージを破棄した後に新規メッセージを開始する手段が用意されています。
メッセージ配信は、2つの統合マイルストン間でのメッセージ処理が1つの作業単位として扱われ、単一のグローバル・トランザクションにバインドされることによって確保されます。
Oracle FMWがサポートされたJCA仕様に基づいてアプリケーションにアダプタが実装されている場合は、JCAアダプタを使用します。これらのアダプタは、オラクル社認定のサードパーティが必要なJCA仕様をサポートしている場合に、そのサードパーティから購入できます。
JCAアダプタは、トランザクション対応である必要があります。保証付き配信を確保し、参加アプリケーションを取得してXAトランザクションに登録するには、JCAアダプタおよびアプリケーションで、AIAコンポジット・ビジネス・プロセスで必要な機能を構築する必要があります。
JCAアダプタは、AQまたはJMSのキューまたはトピック・アダプタです。また、JCAアダプタは参加アプリケーションのビジネス・オブジェクトAPIを公開できます。APIの粒度では、参加アプリケーションとのチャット可能の会話が求められます。アプリケーションは粒度の粗いAPIを公開することをお薦めします(ただし、アプリケーションの実装では粒度の細かい複数のAPIを呼び出す場合があります)。この公開によってチャット可能の会話を回避でき、ビジネス・トランザクションのパフォーマンス全体が向上します。
JMSアダプタの詳細は、『Oracle WebLogic Server JMSリソースの管理』を参照してください。
次の各項では、Siebelアプリケーションとのインバウンドおよびアウトバウンド接続を確立する方法を説明します。
Siebelアプリケーションがビジネス・プロセス、ビジネス・アクティビティおよびタスクを開始する駆動アプリケーションである場合、SiebelアプリケーションはAIAサービスにリクエストを送信します。Siebelアプリケーションは、Webサービスとして公開されたAIAサービスを呼び出すか、またはメッセージを直接JMSキューにプッシュしてAIA JMSコンシューマをトリガーできます。
要求側メッセージの書式は、Siebelにネイティブであるか、またはAIAエンタープライズ・ビジネス・オブジェクト(EBO)に準拠します。
書式がネイティブの場合、SiebelツールによってSiebel統合オブジェクトのスキーマが生成され、AIAサービスの作成用に提供されます。
詳細は、統合プラットフォーム・テクノロジ: Siebelエンタープライズ・アプリケーション統合を参照してください。
Siebelツール(Siebel IDE)ではAIAサービスWSDLが必要です。SiebelツールはWSDLを調査し、プロキシを生成して実行時にAIAサービスを呼び出します。SiebelツールはSiebel統合オブジェクト用のスキーマを生成し、それらを使用してAIAリクエスタABCSを開発します。
AIAプロジェクト管理ライフサイクルのサービス構想と定義フェーズおよびサービス設計と作成フェーズの中で、次のタスクを実行します。
サービス構想と定義フェーズでのソリューション・アーキテクト向けのタスクは次のとおりです。
SiebelアプリケーションのリクエスタABCSを識別して、AIAプロジェクト定義に追加します。
新規サービスの場合は、ビジネス・アナリストと協力して、要件を詳細に把握します。
既存のサービスの場合は、ビジネス・アナリストと協力して、実行する変更の詳細を把握します。
開発者と協力して、サービスの設計を進めます。
メッセージの書式を確定します。
AIAリクエスタABCSのWSDLを確定します。
サービスのメタデータがOracle Enterprise Repositoryに取得されたことを確認します。
AIAプロジェクト定義のデプロイメント計画にサービスを追加します。
サービス設計と作成フェーズでの開発者向けのタスクは次のとおりです。
ソリューション・アーキテクトが提供するSiebelリクエスタ・アプリケーション・ビジネス・サービス定義を分析します。
Siebelアプリケーション開発と協力して、可能な設計を検討します。
Siebelからのメッセージの内容を確定します。
Siebelからメッセージのスキーマを取得して次を確認します。
リクエスタABCSを作成します。
このサービスからSiebelアプリケーション開発チームにWSDLを提供します。
例14-4 バージョン1のTargetNameSpaceの例
<xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema targetNamespace=" http://siebel.com/asi/V1" xmlns:xsd=http://www.siebel.com/xml/SWICustomerPartyIO
例14-5 必要なカスタム属性
<xsd:attribute name="Language" type="xsd:string"/> <xsd:attribute name="Locale" type="xsd:string"/> <xsd:attribute name="MessageId" type="xsd:string"/> <xsd:attribute name="EnterpriseServerName" type="xsd:string"/>
例14-6 サンプルのカスタム属性
<xsd:complexType name="ListOfSwicustomerpartyio">
<xsd:sequence> <xsd:element name="Contact" type="xsdLocal:Contact" minOccurs=
"0" maxOccurs="unbounded"/></xsd:sequence>
<xsd:attribute name="Language" type="xsd:string"/>
<xsd:attribute name="Locale" type="xsd:string"/>
<xsd:attribute name="MessageId" type="xsd:string"/>
<xsd:attribute name="EnterpriseServerName" type="xsd:string"/
</xsd:complexType>
SiebelツールはSiebel統合オブジェクト用のスキーマを生成し、それらを使用してAIAリクエスタABCSを開発します。
AIAプロジェクト管理ライフサイクルのサービス構想と定義フェーズおよびサービス設計と作成フェーズの中で、次のタスクを実行します。
サービス構想と定義フェーズでのソリューション・アーキテクト向けのタスクは次のとおりです。
サービス設計とアウトライン作成フェーズでの開発者向けのタスクは次のとおりです。
JMSキュー内のメッセージによってトリガーされるJMSコンシューマ・サービス・コンポジットを作成し、前述のABCSを呼び出します。
キューの名前を識別します。
SOAメディエータ・コンポーネントを使用してアダプタ・コンポジットを作成します。
composite.xmlに注釈を付けます。
詳細は、「イベント集約プログラミング・モデルの実装」を参照してください。
Oracle Enterprise Repositoryに収集します。
詳細は、「直接統合の実装」を参照してください。
Siebelアプリケーションのアクションまたはイベントがビジネス・プロセス、ビジネス・アクティビティまたはタスクに含まれる場合、SiebelアプリケーションはAIAサービスからリクエストを受け取ります。AIAサービスは、Webサービスとして公開されたSiebelアプリケーションを呼び出すか、またはメッセージを直接JMSキューにプッシュしてSiebel JMSコンシューマをトリガーできます。
受け取るメッセージの書式は、Siebelにネイティブであるか、またはAIAエンタープライズ・ビジネス・オブジェクト(EBO)に準拠します。書式がネイティブの場合、SiebelツールによってSiebel WebサービスのWSDLが生成され、AIAサービスによって使用されます。
Siebelツール(Siebel IDE)は、AIAプロバイダABCSの開発に使用されるWebサービスWSDLを生成します。
AIAプロジェクト管理ライフサイクルのサービス設計と作成フェーズの中で、次のタスクを実行します。
サービス設計と作成フェーズでの開発者向けのタスクは次のとおりです。
Siebel Webサービス・フレームワークは、NonおよびStatelessタイプのセッションをサポートしています。別のセッション・タイプが必要な場合は、SessionTypeをSOAPヘッダーに追加する必要があります。
Siebel認証およびセッション管理のSOAPヘッダーを使用して、ユーザー資格情報およびセッション情報を送受信できます。ログイン用にユーザー名とパスワードを送信して、次のいずれかのセッションを呼び出すことができます。
アウトバウンド・レスポンスの送信後に閉じるもの。
レスポンスの送信後も開いたままのもの。
詳細は、次を参照してください。
統合プラットフォーム・テクノロジ: Siebelエンタープライズ・アプリケーション統合の「Webサービス」のWebサービスの呼出し例に関する項
統合プラットフォーム・テクノロジ: Siebelエンタープライズ・アプリケーション統合の「Webサービス」のXMLスキーマ・ウィザードでのxsd:anyタグのマッピングに関する項
Oracle Application Integration Architecture事前作成済の統合: ユーティリティ・ガイドのセッション・プール・マネージャに関する項
セッション管理にStatelessタイプを使用します。Statelessは、Siebelセッションを永続的に保持します。
Siebel Webサービス・フレームワークのステートレス・セッションは、Webサーバーから独立しています。
すべてのレスポンスには、次のリクエストで使用する必要がある新しいSessionTokenが含まれます。
次の各項では、Oracle E-Business Suite (E-Business Suite)アプリケーションとのインバウンドおよびアウトバウンド接続を確立する方法を説明します。
E-Business Suiteアプリケーションがビジネス・プロセス、ビジネス・アクティビティまたはタスクを開始する駆動アプリケーションである場合、E-Business SuiteアプリケーションはAIAサービスにリクエストを送信します。E-Business Suiteは、コンカレント・プログラム実行可能ファイルを使用してWebサービスとして公開されたAIAサービスを呼び出すか、またはJCAアダプタ(Oracle Apps Adapter)を介してAIAレイヤーにビジネス・イベントを発生できます。JCAアダプタは、特定のビジネス・イベントをサブスクライブするように構成する必要があります。
要求側メッセージの書式は、E-Business Suiteのアプリケーション・ビジネス・メッセージ(ABM)にネイティブであるか、またはAIAエンタープライズ・ビジネス・メッセージ(EBM)に準拠します。
E-Business SuiteではAIAサービスWSDLが必要です。E-Business Suiteは、プロキシを生成してコンカレント・プログラム実行可能ファイルで使用し、実行時にAIAサービスを呼び出す必要があります。E-Business Suiteは、AIAとE-Business Suite間のコントラクト(WSDL)を定義してAIAリクエスタABCSを開発するのに使用する、スキーマ(ABM)を生成する必要があります。
AIAプロジェクト管理ライフサイクルのサービス構想と定義フェーズおよびサービス設計と作成フェーズの中で、次のタスクを実行します。
サービス構想と定義フェーズでのソリューション・アーキテクト向けのタスクは次のとおりです。
ベスト・プラクティスに従って非同期パターンを設計し、長時間実行するトランザクションを回避
非同期操作の確認のタイプを確定します。
サービスのメタデータがOracle Enterprise Repositoryに取得されたことを確認します。
AIAプロジェクト定義のデプロイメント計画にサービスを追加します。
サービス設計と作成フェーズでの開発者向けのタスクは次のとおりです。
ソリューション・アーキテクトが提供するE-Business SuiteリクエスタABS定義を分析します。
E-Business Suite開発と協力して、可能な設計を検討します。
E-Business Suiteからのメッセージの内容を確定します。
E-Business Suiteからメッセージのスキーマを取得して次を確認します。
TargetNameSpace - バージョン0より上位の場合は、接尾辞V<N> (Vはバージョンの略語、Nはバージョン番号)が必要です。バージョン番号がない場合は、バージョン0とみなされます。例14-7にバージョン0の例を示します。
リクエスタABCSを作成します。
このサービスからE-Business Suite開発チームにWSDLを提供します。
例14-7 バージョン0のTargetNameSpaceの例
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://xmlns.oracle.com/ebiz/CurrencyExchange" xmlns:db="http://xmlns.oracle.com/ebiz/CurrencyExchange" elementFormDefault="qualified"> <xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayable InvoiceListEbizDBAdapterV1" xmlns=http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayableInvoiceList EbizDBAdapterV1
エンタープライズ・ビジネス・サービス(EBS)ワークフロー・ビジネス・イベントのサブスクリプションを行うには、ビジネス・イベント・アダプタ(OAPPSアダプタ)を、サービスを呼び出してE-Business Suiteでビジネス・イベントを発生するプラグインとしてOracle JDeveloperで使用可能にします。WF_BPEL_Qがイベントへのサブスクリプションとして作成され、アダプタはWF_BPEL_Qからイベントを読み取り、メッセージがキューに到着するとアダプタ・サービスをトリガーします。
E-Business Suiteは、AIAとE-Business Suite間のコントラクト(WSDL)を定義してAIAリクエスタABCSを開発するのに使用する、スキーマ(ABM)を生成する必要があります。
ビジネス・オブジェクトによっては、生成されるABMにイベント情報のみが含まれる場合があります。このような場合は、公開されているイベント情報からビジネス・オブジェクトIDが抽出され、E-Business Suiteを問い合せてオブジェクト全体を取得します。
AIAプロジェクト管理ライフサイクルのサービス構想と定義フェーズおよびサービス設計と作成フェーズの中で、次のタスクを実行します。
サービス構想と定義フェーズでのソリューション・アーキテクト向けのタスクは次のとおりです。
E-Business SuiteのリクエスタABCSを識別して、AIAプロジェクト定義に追加します。
新しいABCSの場合は、ビジネス・アナリストと協力して、要件を詳細に把握します。
既存のABCSの場合は、ビジネス・アナリストと協力して、実行する拡張の詳細を把握します。
開発者と協力して、ABCSの設計を進めます。
ビジネス要件に従って必要なABMからAIAに通信するE-Business Suite機能に基づき、最適な接続を選択します。コンカレント・プログラム実行可能ファイルまたはビジネス・イベント・サブスクリプションを選択します。
メッセージ(ABM)の書式を確定します。
E-Business SuiteとAIA間のコントラクトを確定します。AIAリクエスタABCSのWSDLを定義します。
E-Business SuiteとAIA間のエラーまたはフォルト処理メッセージの書式を定義して確定します。
エラー処理メカニズム、およびE-Business Suiteユーザー向けに表示/記録/アラートするAIAエラー・メカニズムのスタイルを定義します。
E-Business SuiteとAIA間のMEPを確定します。
ベスト・プラクティスに従って非同期パターンを設計し、長時間実行するトランザクションを回避します。
非同期操作の確認のタイプを確定します。
サービスのメタデータがOracle Enterprise Repositoryに取得されたことを確認します。
AIAプロジェクト定義のデプロイメント計画にサービスを追加します。
サービス設計と作成フェーズでの開発者向けのタスクは次のとおりです。
ソリューション・アーキテクトが提供するE-Business SuiteリクエスタABCS定義を分析します。
E-Business Suite開発と協力して、可能な設計を検討します。
E-Business Suiteからのメッセージの内容を確定します。
E-Business Suiteからメッセージのスキーマを取得して次を確認します。
TargetNameSpace - バージョン0より上位の場合は、接尾辞V<N> (Vはバージョンの略語、Nはバージョン番号)が必要です。バージョン番号がない場合は、バージョン0とみなされます。例14-8にバージョン1の例を示します。
リクエスタABCSを作成します。
このサービスからE-Business Suite開発チームにWSDLを提供します。
E-Business Suiteのビジネス・イベントによってトリガーされるE-Business Suiteアダプタ・サービス・コンポジットを作成し、JMSプロデューサ・サービスを呼び出します。
接続ファクトリ名およびJNDI参照を識別します。
サブスクライブするビジネス・イベントを識別します。
受信メッセージまたはビジネス・イベントに対して確認されるスキーマを識別します。
SOAメディエータ・コンポーネントを使用してアダプタ・コンポジットを作成します。
ターゲット・キュー名、接続ファクトリ名およびJNDI参照を識別します。
composite.xmlに注釈を付けます。
詳細は、「イベント集約プログラミング・モデルの実装」を参照してください。
Oracle Enterprise Repositoryに収集します。
詳細は、「直接統合の実装」を参照してください。
例14-8 バージョン1のTargetNameSpaceの例
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://xmlns.oracle.com/ebiz/CurrencyExchange" xmlns:db="http://xmlns.oracle.com/ebiz/CurrencyExchange" elementFormDefault="qualified"> <xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayable InvoiceListEbizDBAdapterV1" xmlns=http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayableInvoiceList EbizDBAdapterV1
AIAサービス、コンポジット・ビジネス・プロセスまたはエンタープライズ・ビジネス・フローがE-Business Suiteへのリクエストを開始すると、E-Business SuiteアプリケーションはAIAサービスからのリクエストを受け取ります。AIAは、次のいずれかの方法でE-Business Suiteを呼び出すことができます。
データベースまたはOracle Apps Adapterを使用して、PL/SQLプロシージャまたは関数を呼び出すことができます。これらのアダプタは、Oracle JDeveloperでプラグインとして使用できます。Oracle Apps Adapterは、PL/SQLプロシージャ/関数を呼び出す前にFND Appsコンテキストを設定するDBアダプタに対するラッパーです。
ビジネス・サービス・オブジェクト(BSO)を使用して公開されたJAVAベースのWebサービスを呼び出します。Oracle- E-Business Suiteでは、Oracle E-Business Suiteアプリケーション・サーバーにホストされたサービスとしてJAVA APIを公開する直接的な方法はありません。ただし、Oracle Applicationsの技術スタックで提供されるBSO機能を使用して、Oracle Application Development Frameworkのアプリケーション・モジュールをサービスとして公開することは可能です。これらのサービスは統合リポジトリ(IRep)に到達し、リモート・アクティビティからサービスとして呼び出すことができます。
BSOの詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。
データをインタフェース表にロードし、コンカレント・プログラムをコールしてデータを処理します。AIAは、DB/Appsアダプタを使用してデータをEBSインタフェース表に挿入し、DB/Appsアダプタを使用してコンカレント・プログラムまたは後処理APIをコールし、このデータを処理します。
DBアダプタはOracle- E-Business Suite表からポーリングを行い、その統合サービスを開始できます。DBアダプタは、JDeveloperのウィザードを使用し、適切なBusinessEventまたはAPIを選択して構成する必要があります。JDeveloperは、Ebizデータベース上で実行する必要がある.sqlファイルを作成して、イベントをリスニングするためのサブスクリプションを作成します。
送信メッセージの書式は、E-Businessアプリケーション・ビジネス・メッセージ(ABM)のネイティブ書式である必要があります。
開発と設計タスクは、前述したインバウンド接続に似ています。アーキテクトまたは設計者は、E-Businessでビジネス機能が公開されている方法を識別し、E-Businessに接続するための前述の4つの方法から使用可能なパスを識別する必要があります。アーキテクトまたは設計者は、各トランスポートに関する一般的なガイドラインに基づいて、特定のビジネス要件に適したトランスポートを決定する必要があります。
AIAサービスを利用して、タスク、ビジネス・アクティビティおよびビジネス・プロセスを実装します。
この設計と開発の共通ガイドラインは、様々なリソースを使用するすべての相互作用に適用でき、インバウンドおよびアウトバウンドの両方の相互作用に適用できます。
パターンのタイプに応じて、次の点を考慮してください。
メッセージなしでイベント通知をプッシュ
保証付き配信要件を伴うイベント通知 - JCAアダプタ(使用可能な場合)を利用し、それ以外の場合はキューを使用します。
重要な状況ではないイベント通知 - Webサービスを使用します。
メッセージ付きでイベントをプッシュ
情報を要求してその情報を待機するリクエスト・イベント - JCAアダプタ(使用可能な場合)を利用するか、またはWebサービスを使用します。
状態変更を伝播するリクエスト・イベント - JCAアダプタ(使用可能な場合)を利用し、それ以外の場合はキューを使用します。
詳細は、「AIA設計パターンの使用」を参照してください。
