| Oracle Fusion Middleware Oracle SOA Suite開発者ガイド 11g リリース1 (11.1.1.5.0) B56238-04 |
|
 前 |
 次 |
この章では、ルーティング・ルールの概要およびOracle Mediatorサービス・コンポーネントに対してルーティング・ルールを指定する方法を説明します。
項目は次のとおりです。
Oracle Mediatorを使用すると、サービス・コンシューマとサービス・プロバイダの間でデータをルーティングできます。データはサービス間をフローするため、トランスフォーメーションが必要です。ルーティングとトランスフォーメーションの2つのタスクは、Oracle Mediatorの中核となる処理内容です。ルーティング・ルールにより、Oracle Mediatorで処理されたメッセージを次の宛先にどのように送信するかを指定できます。ルーティング・ルールは、Oracle Mediatorによるメッセージの送信先、メッセージの送信方法、およびターゲット・サービスへの送信前にメッセージ構造に加える必要がある変更の内容を指定します。
ルーティング・ルールには、次の2つのタイプがあります。
静的ルーティング・ルール
起動コンテキストによって変更されることのない一貫して適用される静的ルールです。
動的ルーティング・ルール
Oracle Rules Dictionaryへのルーティング・ロジックの外部化を可能にする動的ルールです。Oracle Rules Dictionaryは、ルーティング・ロジックの動的変更を可能にします。
ルーティング・ルールの作成の詳細は、第19.2.2項「静的ルーティング・ルールの作成方法」および第19.2.3項「動的ルーティング・ルールの作成方法」を参照してください。
ルーティング・ルールは、インタフェースが定義されているOracle Mediatorにのみ定義できます。インタフェースの定義方法の詳細は、第18.4.1.3項「Oracle Mediatorのインタフェースの定義方法」を参照してください。
メディエータ・エディタの「ルーティング・ルール」セクションで、ルーティング・ルールを定義します。
「ルーティング・ルール」セクションにアクセスする手順は、次のとおりです。
次のいずれかの方法を使用して、メディエータ・エディタの「ルーティング・ルール」セクションにアクセスできます。
SOAコンポジット・エディタからアクセスする方法
ルーティング・ルールを指定するOracle Mediatorを示すアイコンをダブルクリックします。
「ルーティング・ルール」セクションが表示されない場合は、「ルーティング・ルール」セクションの横のプラス(+)アイコンをクリックします。
アプリケーション・ナビゲータからアクセスする方法
「アプリケーション・ナビゲータ」からSOAプロジェクトを開き、次に「SOAコンテンツ」フォルダを開きます。
「SOAコンテンツ」フォルダで、ルーティング・ルールを指定するOracle Mediatorファイルの名前をダブルクリックします。
Oracle Mediatorファイルには、MPLAN拡張子が付きます。
「ルーティング・ルール」セクションが表示されない場合は、「ルーティング・ルール」セクションの横のプラス(+)アイコンをクリックします。
図19-1に、メディエータ・エディタの「ルーティング・ルール」セクションを示します。
図19-2では、「ルーティング・ルール」セクションのアイコンをリストして説明します。
静的ルーティング・ルールを定義するときは、次の情報およびルールのタイプを構成できます。
ターゲット・サービス
Oracle Mediatorにより、指定するターゲット・サービスにメッセージが送信されます。このサービスは、WSDLインタフェースまたはJavaインタフェースとして定義できます。ターゲット・サービスの起動の詳細は、第19.2.2.1項「Oracle Mediatorサービスまたはイベントの指定方法」を参照してください。
実行タイプ
Oracle Mediatorは、ルーティング・ルールを順次またはパラレルのいずれかで実行します。実行タイプの指定方法の詳細は、第19.2.2.3項「順次実行またはパラレル実行の指定方法」を参照してください。
リプライ、コールバックおよびフォルト・ハンドラ
同期リプライ、コールバックおよびフォルト・メッセージをOracle Mediatorで処理する方法を定義できます。ハンドラの詳細は、第19.2.2.4項「レスポンス・メッセージの構成方法」および第19.2.2.6項「フォルトの処理方法」を参照してください。
フィルタ式
メッセージのコンテンツ(ペイロードまたはヘッダー)に適用するフィルタ式を定義できます。フィルタを定義する場合、コンテンツはサービスの起動前に分析されます。たとえば、メッセージに顧客IDが含まれている場合、またはその顧客IDの値が特定のパターンと一致する場合のみサービスを起動することを指定する、フィルタ式を適用できます。フィルタ式の指定方法の詳細は、第19.2.2.7「メッセージをフィルタリングする式の指定方法」を参照してください。
トランスフォーメーション
Oracle Mediatorでは、メッセージをサービスに転送する前にメッセージ・データを変換できます。データのマッピングまたは値の割当てにより、ターゲット・ペイロードで値を設定するようトランスフォーメーションを定義できます。
XSLTマッパーを使用すると、XMLスキーマ間でメッセージを変換するために、メッセージ本文全体に適用するトランスフォーメーションを定義できます。値の割当て機能では個々のフィールドを処理します。このダイアログを使用すると、メッセージ(ペイロード、ヘッダーなど)、定数または様々なシステム・プロパティ(データ・パスに存在するアダプタのプロパティなど)から値を割り当てることができます。トランスフォーメーションの定義方法の詳細は、第19.2.2.8項「トランスフォーメーションの作成方法」および第19.2.2.9項「値の割当て方法」を参照してください。
式にあるヘッダー変数へのアクセス
Oracle Mediatorは、現在のルーティング・ルール操作用の式の作成に使用したSOAPヘッダーを検出できます。ヘッダー・アクセス方法の詳細は、第19.2.2.11項「フィルタおよび割当てのためのヘッダー・アクセス方法」および第19.2.2.11.2項「フィルタおよび割当てのためのプロパティ・アクセスに使用する式の手動作成」を参照してください。
Schematronベースの検証
インバウンド・メッセージの様々な部分を検証するためにOracle Mediatorが使用する必要のあるSchematronファイルを指定できます。Schematronをベースにした検証の実行方法の詳細は、第19.2.2.12項「セマンティク検証の使用方法」を参照してください。
Javaコールアウト
カスタムJavaクラス・コールアウトにより、正規表現のみでは十分でないときに、その正規表現をJavaコードと併用できるようにします。Javaコールアウトの使用方法の詳細は、第19.2.2.13 Javaコールアウトの使用方法」を参照してください。
ユーザー定義拡張関数
XSLTマッパーで使用可能な独自の関数セットです。ユーザー定義拡張関数の使用方法の詳細は、「ユーザー定義拡張関数を追加する手順」を参照してください。
Oracle Mediatorコンポーネントを作成した後は、そのOracle Mediatorをインバウンド・サービス操作またはイベント・サブスクリプション、およびアウトバウンド・ターゲットに関連付けます。ターゲットは、アウトバウンド・サービス操作またはイベントの公開です。ターゲットはOracle Mediatorがメッセージを送信する次のサービスまたはイベントを指定し、起動するサービス操作も指定します。サービスまたはイベントをターゲット・タイプとして指定できます。
ソース・メッセージは、トランスフォーメーション、検証、割当てまたは順序操作の実行後に、初期のコール元にエコーして戻すこともできます。エコーは、Oracle Mediatorコンポーネントに同期または非同期のインタフェースがある場合にのみ指定できます。エコーが同期、非同期のいずれで行われるかは、コール元のWSDLファイルによって決まります。エコー・オプションは、インバウンド・サービス操作に対してのみ使用可能で、イベント・サブスクリプションには使用できません。
エコー・オプションの目的は、Oracle Mediatorのすべての機能をコール可能なサービスとして公開することによって、他のサービスへのルーティングの必要性をなくすことです。たとえば、Oracle Mediatorをコールしてトランスフォーメーション、検証または割当てを実行した後、別の場所にルーティングすることなくアプリケーションにOracle Mediatorをエコーして戻すことができます。
1つのインバウンド操作またはイベントに複数のルーティングを指定できます。各ルーティングは、1つのターゲット・サービス起動またはイベントにマップされます。したがって、特定のターゲット・サービスに対して複数のサービス起動を指定したり、複数イベントを発生させるには、各ターゲットに1つのルーティング・ルールを指定する必要があります。たとえば、メッセージ・ペイロードに基づいて、サービスに定義された次の操作から、ある操作を起動できます。
insert
update
updateid
delete
このため、各操作に1つずつ、4つのルーティング・ルールを作成する必要があります。その後、各ルールにフィルタ式を指定する場合は、図19-3に示すように、メッセージ・ペイロードに基づいて各メッセージ・インスタンスに適用するターゲットおよび操作を指定できます。
サービスを起動する手順は、次のとおりです。
この手順を実行するには、WSDLドキュメントまたはJavaインタフェースでターゲット・サービスを定義する必要があります。
「ルーティング・ルール」セクションで、ルーティング・ルールを定義中の操作の横にある「追加」をクリックし、次に「静的ルーティング・ルール」を選択します。
図19-4に示すように、「ターゲット・タイプ」ダイアログが表示されます。
「サービス」をクリックします。
図19-5に示すように、「ターゲット・サービス」ダイアログが表示されます。
「ターゲット・サービス」ダイアログで、サービスが提供する操作に移動し、選択します。
「OK」をクリックします。
Javaインタフェースで定義されたターゲット・サービスを選択した場合、必要なインタフェースダイアログが表示されます。「はい」をクリックして必要なWSDLファイルを作成し、次に確認ダイアログで「OK」をクリックします。
ルーティング・ルールを定義できる新規の「静的ルーティング」セクションが表示されます。
この章の後続の項の説明に従って、ルーティング・ルールを構成します。
イベントをトリガーする手順は、次のとおりです。
「ルーティング・ルール」セクションで、ルーティング・ルールを定義中の操作の横にある「追加」をクリックし、次に「静的ルーティング・ルール」を選択します。
図19-4に示すように、「ターゲット・タイプ」ダイアログが表示されます。
「イベント」をクリックします。
「イベント・チューザ」ダイアログが表示されます。
「イベント定義」フィールドの右側にある「検索」をクリックします。
「SOAリソース・ブラウザ」ダイアログが表示されます。
イベント(.edl)・ファイルを選択し、「OK」をクリックします。
図19-6に示すように、選択したファイルに定義されているイベントが「イベント」フィールドに移入されます。
|
注意: 既存のイベント定義ファイルを参照するかわりに、「新規イベント定義(edl)ファイルを作成します。」をクリックし、「イベント定義ファイルの作成」ダイアログのフィールドを完了して、新規ファイルを作成できます。 |
イベントを選択します。
「OK」をクリックします。
ルーティング・ルールを定義できる新規の「静的ルーティング」セクションが表示されます。
この章の後続の項の説明に従って、ルーティング・ルールを構成します。
サービスをエコーする手順は、次のとおりです。
エコー・オプションには次の制限があります。
サービスのエコーは、Oracle Mediatorのインタフェースが、次のタイプのWSDLファイルの場合のみサポートされます。
リクエスト/リプライ
リクエスト/リプライ/フォルト
リクエスト/コールバック
|
注意: エコー・オプションは、Oracle Mediatorインタフェースがリクエスト/リプライ/フォルト/コールバックのWSDLファイル、または一方向WSDLファイルの場合には使用できません。 |
エコー・オプションは、リクエスト/リプライおよびリクエスト/リプライ/フォルトのような同期操作で使用できます。
|
注意: 同期操作のOracle Mediatorでは、パラレルのルーティング・ルールはサポートされないため、エコー・オプションを同期操作で使用できるのは、ルーティング・ルールが順次実行の場合のみです。 |
条件フィルタ付きの同期操作の場合は、フィルタ条件をfalseに設定していると、エコー・オプションではレスポンスがコール元に返されません。かわりに、nullレスポンスが返されます。
エコー・オプションを非同期操作で使用できるのは、Oracle Mediatorインタフェースにコールバック操作が指定されている場合のみです。この場合、エコーは別のスレッドで実行されます。
|
注意: 非同期のエコー・オプションを使用できるのは、ルーティング・ルールがパラレル実行の場合のみです。エコー・オプションを使用する場合、非同期操作のOracle Mediatorでは、順次実行のルーティング・ルールはサポートされません。 |
ルーティング・ルールは、パラレルまたは順次のいずれかで実行できます。ルーティング・ルールの実行タイプを指定するには、「ルーティング・ルール」セクションで、「順次」または「パラレル」実行タイプを選択します。
順次ルーティング・ルールの基本原則
Oracle Mediatorは、次の原則に基づいて順次ルーティング・ルールを処理します。
Oracle Mediatorは、ルーティングを評価し、結果の処理を順次実行します。順次ルーティングは、コール元と同じスレッドとトランザクションで評価されます。
Oracle Mediatorは常に、受信メッセージを処理しているスレッドを介して伝播されたグローバル・トランザクションにOracle Mediator自体を登録します。たとえば、インバウンドJCAアダプタがOracle Mediatorを起動すると、そのOracle Mediatorは、JCAアダプタが開始したトランザクションにOracle Mediator自体を登録します。
Oracle Mediatorは、順次ルーティング・ルールの実行中に、ターゲット・コンポーネントと同じスレッドを介してトランザクションを伝播します。
外部エンティティによって伝播されたトランザクションを、Oracle Mediatorがコミットまたはロールバックすることはありません。
Oracle Mediatorがトランザクションを管理するのは、スレッド起動Oracle Mediatorにアクティブなトランザクションが存在していない場合のみです。たとえば、Oracle MediatorがインバウンドSOAPサービスから起動された場合、そのOracle Mediatorはトランザクションを開始し、成功および失敗に応じてトランザクションをコミットまたはロールバックします。
パラレルのルーティング・ルールの基本原則
Oracle Mediatorは、次の原則に基づいてルーティング・ルールをパラレルで処理します。
Oracle Mediatorは、ルーティングをキューに入れ、別々のスレッドでパラレルに評価します。
各Oracle Mediatorサービス・コンポーネントのメッセージは、重み付けラウンド・ロビン方式で取得され、すべてのOracle Mediatorサービス・コンポーネントで確実にパラレル処理サイクルが受け入れられます。これは、1つ以上のOracle Mediatorサービス・コンポーネントで、他のコンポーネントよりも多くのメッセージが生成される場合でも同様です。使用される重み付けは、Oracle Mediatorサービス・コンポーネントの設計時に設定されたメッセージ優先度です。メッセージ優先度の高いコンポーネントほど、多数のパラレル処理サイクルが割り当てられます。
Oracle Mediatorサービス・コンポーネントの優先度を指定するには、メディエータ・エディタで「優先度」フィールドを設定します。優先度は0から9までの範囲で、9が最高優先度です。デフォルトの優先度は4です。
|
注意: 「優先度」プロパティの適用対象は、パラレルのルーティング・ルールのみです。 |
Oracle Mediatorは、各パラレル・ルールを処理するための新規トランザクションを開始します。開始されたトランザクションは、Oracle Mediatorのパラレル・メッセージ・デハイドレーション・ストアへのエンキューで終了します。
たとえば、Oracle Mediatorサービス・コンポーネントにパラレルのルーティング・ルールが1つある場合は、1つのメッセージがOracle Mediatorのパラレル・メッセージ・デハイドレーション・ストアにエンキューされます。次に、ストアに対するパラレル・メッセージ・ディスパッチャがトランザクションを開始し、データベース・ストアからメッセージを読み取り、このルーティング・ルールのターゲット・コンポーネントまたはサービスを起動します。リスナー・スレッドによって開始されるトランザクションは、完全に新規のトランザクションであり、ターゲット・コンポーネントに伝播されます。
|
注意: メッセージのデハイドレーションでは、パラレル・ルーティング・ルール対象の受信メッセージがデータベースに格納されるため、ワーカー・スレッドはそれらのメッセージを後で処理できます。 |
Oracle Mediatorはトランザクションの開始元であるため、これらのトランザクションをコミットまたはロールバックします。
操作またはイベントに順次およびパラレルの両方のルーティング・ルールがある場合は、最初に順次ルーティング・ルールが評価されてアクションが実行され、次にパラレルのルーティングがパラレル実行のためにキューに入れられます。
|
注意: リクエスト/レスポンス・インタフェースを使用するOracle Mediatorサービス・コンポーネントにパラレルのルーティング・ルールのみが設定されている場合、そのOracle Mediatorサービス・コンポーネントはコール元にレスポンスを返信しません。このタイプのOracle Mediatorサービス・コンポーネントは作成できますが、Oracle Mediatorサービス・コンポーネントのコール元が、実行時にレスポンスを受信することはありません。 |
Oracle Mediatorルーティング・ルールでは、レスポンス・メッセージを同期および非同期の相互作用内で処理する方法を指定できます。同期相互作用の場合は、レスポンスとフォルト・メッセージのトランスフォーメーションと割当てを指定できます。レスポンスとフォルト・メッセージを別のサービスまたはイベントに転送するか、または初期のコール元にレスポンスおよびフォルトを受信する用意がある場合は、それらを初期のコール元に戻すことができます。
非同期相互作用の場合は、トランスフォーメーションと割当て、およびレスポンスを受信するまでのタイムアウト時間を指定できます。タイムアウト時間は、秒、時、日、月または年で指定できます。タイムアウト時間のデフォルト値は無限です。コールバック・レスポンスが指定したタイムアウト時間内に返されない場合、タイムアウトしたレスポンスは別のサービス、別のイベントに転送されるか、初期のコール元に戻されます。
Oracle Mediatorのレスポンスを双方向サービスにルーティングすることはできません。レスポンスを双方向サービスにルーティングする場合は、最初のOracle Mediatorと双方向サービスの間に一方向のOracle Mediatorを使用する必要があります。レスポンスを最初に一方向のOracle Mediatorに転送し、その一方向のOracle Mediatorが双方向サービスをコールする必要があります。
|
注意:
|
非同期処理のタイムアウト時間を指定する手順は、次のとおりです。
メディエータ・エディタの「ルーティング・ルール」セクションで、次の手順を実行します。
「コールバック」セクションで、「タイムアウト期間」フィールド側の「<<ターゲット操作>>」フィールドの横にある「ターゲット・サービス操作を参照します。」アイコンをクリックします。
「ターゲット・タイプ」ダイアログが表示されます。
「サービス」、「イベント」または「初期コール元」を選択します。
「サービス」または「イベント」を選択した場合は、選択した内容によって「ターゲット・サービス」または「イベント・チューザ」が表示されます。
サービスまたはイベントを選択します。
「OK」をクリックします。
「タイムアウト期間」フィールドで、タイムアウト期間の単位数を入力し、ドロップダウン・リストから時間の単位を選択します。
タイムアウトしたレスポンスが、指定したサービスまたはイベントに転送されます。
|
注意: ルーティング・ルールの数が多く、ルーティング・ルールの実行に要する時間がトランザクション・タイムアウトを超える場合は、トランザクション・タイムアウトの値を、すべてのルーティング・ルールの実行に要する時間より長い時間に設定する必要があります。 |
1つのOracle Mediatorで複数のコールバックを処理することはできません。複数のコールバックを受信するOracle Mediatorが含まれているコンポジット・アプリケーションがある場合、そのコンポジット・アプリケーションの動作は不明です。たとえば、図19-9に示したシナリオでは、AsyncMediatorがAsyncEchoMediator1およびAsyncEchoMediator2からのコールバック・レスポンスをFileInMediatorに転送します。このようなフローでは、AsyncMediatorは、AsyncEchoMediator1とAsyncEchoMediator2の両方からのコールバックを返すか、またはいずれか一方のコールバックを返す可能性があります。正確な動作はランダムであり、予測できません。
ターゲット・サービスの操作に1つ以上のフォルトがある新規ルーティング・ルールを作成する場合でも、メディエータ・エディタには、単一フォルトのルーティング・セクションが表示されます。ソースOracle Mediatorサービス・コンポーネントが1つ以上のフォルトをサポートしている場合、デフォルトでは、フォルトはコール元に戻されます。ただし、ルーティングするソース・フォルト名およびターゲット・フォルト名を指定できます。サービス・ブラウザを使用して、フォルトを別のターゲットにルーティングすることもできます。
追加のフォルト・ルーティングを定義する手順は、次のとおりです。
メディエータ・エディタの「ルーティング・ルール」セクションで、次の手順を実行します。
図19-10に示すように、「フォルト」セクションで、「別のフォルト・ルーティングを追加します。」ボタンをクリックします。
別のフォルト・セクションがルーティング・ルールボックスに表示されます。
新規フォルトに対して、ターゲット・サービス、トランスフォーメーションおよび値の割当てを構成します。
図19-11に、ファイル・アダプタ・サービスにルーティングされている2番目のフォルトを示します。
|
注意: 異なるトランスフォーメーションを使用して、複数のターゲットに同じフォルトをルーティングできます。 |
フォルト・ルーティング・セクションを削除する手順は、次のとおりです。
メディエータ・エディタの「ルーティング・ルール」セクションで、次の手順を実行します。
図19-12に示すように、ターゲット・サービス・フィールドをクリックして削除するフォルト・ルーティングをハイライト表示し、「選択したフォルト・ルーティングを削除します。」をクリックします。
フィルタ式ルーティング・ルールを使用すると、ペイロードに基づいてメッセージをフィルタリングできます。特定のメッセージ・インスタンスに対してフィルタ式がtrueと評価されると、そのメッセージはルーティング・ルールに指定されているターゲット・サービスまたはイベントに送信されます。
たとえば、アメリカとカナダのような異なる2国にいる顧客にデータをルーティングする場合、アメリカの顧客には携帯の製品系列に関する通知のみを、カナダの顧客には固定電話の製品系列の通知のみを送信するとします。このルーティングのためには、メッセージをターゲット顧客に送信するコンポーネントと操作の各組合せについてルーティング・ルールを定義する必要があります。さらに、アメリカまたはカナダの顧客にメッセージを送信するルーティング・ルールには、フィルタ式を指定します。
フィルタ式のメッセージ・プロパティまたはメッセージ・ヘッダーを定義することもできます。
フィルタ式のメッセージ・プロパティ
例19-1に、フィルタ式のメッセージ・プロパティの2つ例を示します。
フィルタ式のメッセージ・ヘッダー
例19-2に、フィルタ式のメッセージ・ヘッダーの2つ例を示します。
例19-2 フィルタ式のメッセージ・ヘッダー
$in.header.wsse_Security/wsse:Security/Priority = '234' $in.header.wsse_Security/wsse:Security/Priority = '234'
このフィルタ式のメッセージ・ヘッダーが機能するには、.mplanファイルのルート要素に例19-3に示す属性を追加する必要があります。
例19-3 追加する属性
wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity- secext-1.0.xsd"
メッセージをフィルタリングする式を指定する手順は、次のとおりです。
式ビルダーを使用すると、フィルタ式をグラフィカルに作成できます。「式ビルダー」ダイアログには、フィルタ式の設計を支援するコンポーネントやコントロールが含まれています。
「ルーティング・ルール」セクションの「フィルタ式」フィールドの右側にある「式ビルダーの起動」アイコンをクリックします。
図19-13に示すように、「式ビルダー」ダイアログが表示されます。
「式」フィールドに値を追加するには、「変数」フィールドまたは「関数」パレットで、必要な値をダブルクリックします。変数要素、関数および手動で入力したテキストの組合せを使用して、このウィンドウで、特定のルーティング・ルールに対してメッセージ・ペイロードをフィルタリングする式を作成できます。
次に、「式ビルダー」ダイアログの各フィールドについて説明します。
式
このフィールドには、メッセージのフィルタに使用される実際の式が含まれます。フィルタ式は手動、または「変数」フィールドおよび「関数」パレットを使用して入力できます。
このフィールドの右上部に表示されている各アイコンを使用すると、最後に行った編集の取消し、最後に行った編集の再実行、または「式」フィールド全体の消去を実行できます。
変数
このフィールドには、Oracle Mediatorコンポーネントに対して定義されたメッセージが含まれます。Oracle JDeveloperはOracle MediatorのWSDLファイルを解析し、メッセージ定義を「変数」フィールドに表示します。入力メッセージは$in変数に格納され、$in.propertiesを使用して入力メッセージのプロパティにアクセスすることができます。
入力メッセージが複数のパートで構成されている場合は、$in.partnameを使用して、入力メッセージのパートにアクセスできます。
「関数」パレット
このリストには、式に挿入できる関数のリストが表示されます。関数を選択すると、その関数が「式」フィールドに追加されたときにどのように表示されるかを示すプレビューが「コンテンツのプレビュー」フィールドに表示され、その関数の説明が「説明」フィールドに表示されます。
コンテンツのプレビュー
このフィールドには、「変数」フィールドまたは「関数」パレットで選択した値が「式」フィールドに挿入されたときの表示状態で示されます。
「説明」フィールド
このフィールドには、「変数」フィールドまたは「関数」パレットで選択した値の説明が表示されます。
メッセージ・ペイロードのフィルタ式を指定する手順は、次のとおりです。
「ルーティング・ルール」セクションの「フィルタ式」フィールドの右側にある「式ビルダーの起動」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。
「変数」フィールドで、メッセージ定義を開き、式の基になるメッセージ要素を選択します。
たとえば、図19-14で選択されたCustomerId要素が表示されます。
「式に挿入」をクリックします。
図19-15に示すように、式が「式」フィールドに追加されます。
「関数」リストから、メッセージ・ペイロードに適用する関数を選択します。たとえば、equalsを選択します。
関数は、「関数」リストの下矢印をクリックすると表示されるカテゴリ別にグループ化されます。たとえば、下矢印をクリックして「Logical Functions」を選択すると、図19-15に示すようにリストが表示されます。
「式に挿入」をクリックします。
選択した関数のXPath式が「式」フィールドに挿入されます。
式を完成します。
この例では、図19-16に示すように、顧客IDがtrueと評価されるには1001である必要があります。
エラーが検出された場合、式は手動で編集するか、式の編集アイコンを使用できます。図19-17には、これらのアイコンがまとめられています。
「OK」をクリックします。
式が「ルーティング・ルール」セクションに追加されます。
フィルタ式の変更または削除は、フィルタ式の追加アイコンをダブルクリックし、「式ビルダー」の「式」フィールドで実行します。
Oracle JDeveloperには、XSLTマッパーが用意されています。XSLTマッパーを使用すると、データをXMLスキーマ(XSDファイルで表されます)間で変換するためのマッパー・ファイル(XSLファイル)を指定できます。XSLTマッパーを使用することで、異なるスキーマを使用しているアプリケーション間でのデータ交換が可能になります。たとえば、受信した注文書スキーマを、送信する請求書スキーマにマップできます。XSLファイルを定義した後は、そのファイルを複数のルーティング・ルール仕様で再利用できます。
トランスフォーメーションを作成する手順は、次のとおりです。
「ルーティング・ルール」セクションで、「次を使用して変換」フィールドの右側にある「既存のマッパー・ファイルを選択するか、新規マッパー・ファイルを作成します。」アイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。既存のXSLファイルを選択するか、XSLTマッパーを使用して必要なトランスフォーメーションを実行する新規XSLファイルを作成できます。
次のいずれかを実行します:
マッピング・ファイルが存在する場合は、「既存のマッパー・ファイルの使用」を選択し、次に「参照」をクリックして、使用するマッパー・ファイルを検索および選択します。
マッパー・ファイルを作成するには、「新規マッパー・ファイルの作成」を選択し、次に入力情報を入力します。
同期リプライ、コールバック・レスポンスまたはフォルト・メッセージに対して、前述の手順を繰り返します。
図19-18に示すように、同期リプライまたはフォルト・メッセージの場合、「リプライ・トランスフォーメーション・マップ」ダイアログまたは「フォルト・トランスフォーメーション・マップ」ダイアログには、「リクエストをリプライ・ペイロードに含める」オプションがあります。
同期相互作用の元のメッセージを含む$initial変数を作成するには、「リクエストをリプライ・ペイロードに含める」オプションを選択します。
図19-19に示すように、変数が作成されます。
|
注意: 初期メッセージも複数のパートで構成されます。$initial.partnameを使用して、初期メッセージのパートにアクセスできます。
インバウンド・メッセージとアウトバウンド・メッセージのパートが同じ場合、データ交換にトランスフォーメーションは必要ありません。 |
XSLTマッパーの詳細は、第37章「XSLTマッパーを使用したトランスフォーメーションの作成」を参照してください。
ユーザー定義拡張関数を追加する手順は、次のとおりです。
式ビルダーを使用すると、ユーザー定義拡張関数を含めることができます。
XPath関数を作成します。
Jaxen XPath関数を、サーバーのxpath-function.xmlファイルのOracle Mediatorサービス・コンポーネントに登録します。
Oracle JDeveloperを起動します。
式ビルダーで式をカスタマイズします。
Oracle JDeveloperプロジェクトをOracle WebLogic Serverにデプロイします。
ユーザー定義拡張関数を格納したJARファイルを$BEAHOME/user_projects/domains/soainfra/autodeploy/soa-infra/APP-INF/libディレクトリにコピーします。
プロジェクトの.mplanファイルを、次のように変更します。
拡張関数用に定義した関数ネームスペースをMediator要素の下に追加します。
関数名をExpression要素に追加します。
図19-20に、この変更操作を示します。
図19-20 プロジェクトの.mplanファイル – ユーザー定義拡張関数を使用するように変更済
適切なペイロードでテスト・ページを起動します。
メッセージのヘッダー、ペイロードおよびプロパティは、「値の割当て」フィールドを使用してソースからターゲットに伝播できます。図19-21に、「値の割当て」ダイアログを示します。このダイアログは、「ルーティング・ルール」セクションの「値の割当て」アイコンをクリックすると表示されます。
ターゲット・メッセージのプロパティを設定する手順は、次のとおりです。
「値の割当て」ダイアログの「追加」をクリックします。
図19-22に示すように、「値の割当て」ダイアログが表示されます。
「From」セクションで、「タイプ」ボックスから次のオプションのいずれかを選択します。
プロパティ: ターゲット・メッセージにプロパティの値を割り当てる場合に選択します。「プロパティ」リストには、事前に定義されたプロパティのリストが表示されます。任意のユーザー定義プロパティ名を入力することもできます。
式: ターゲット・メッセージに式の値を割り当てる場合に選択します。「式」フィールドの右側にある「式ビルダーの起動」アイコンをクリックすると、図19-13に示すような「式ビルダー」ダイアログが表示されます。
「式ビルダー」ダイアログの詳細は、第19.2.2.7項「メッセージをフィルタリングする式の指定方法」を参照してください。
定数: ターゲット・メッセージに定数値を割り当てる場合に選択します。
「To」セクションで、次のオプションのいずれかを選択します。
プロパティ: メッセージ・プロパティに値をコピーする場合に選択します。「式ビルダー」ダイアログの「変数」フィールドには、出力メッセージを格納する$out変数が表示されます。$out.propertyを使用すると、出力メッセージのプロパティにアクセスできます。
式: 式に値をコピーする場合に選択します。「式」フィールドの右側にある「式ビルダーの起動」アイコンをクリックすると、「式ビルダー」ダイアログが表示されます。「式ビルダー」ダイアログの「変数」フィールドには、出力メッセージを格納する$out変数が表示されます。$out.partnameを使用すると、出力メッセージ全体または出力メッセージのパートにアクセスできます。
図19-23に、定数値が式として指定されている、サンプルの「値の割当て」ダイアログを示します。
「値の割当て」ダイアログの「OK」をクリックします。
「OK」をクリックします。「ルーティング・ルール」セクションの「値の割当て」フィールドに式が追加されます。
|
注意:
|
表19-1から表19-3に、メッセージの定数とプロパティ、ペイロードおよびヘッダーに関するソースからターゲットへの考えられる様々な割当てを示します。
表19-1 定数とプロパティの場合の考えられる割当て
| ソース | ターゲット | 例 |
|---|---|---|
|
プロパティ |
プロパティ |
|
|
定数 |
プロパティ |
|
表19-2 ペイロードの場合の考えられる割当て
| ソース | ターゲット | 例 |
|---|---|---|
|
XPath式 |
プロパティ |
|
|
XPath式(パート・レベルより下) |
プロパティ |
|
|
プロパティ |
XPath式(パート・レベルより下) |
|
|
定数 |
XPath式(パート・レベルより下) |
|
|
XPath式 |
XPath式 |
|
|
XPath式(パート・レベルより下) |
XPath式(パート・レベルより下) |
|
表19-3 ヘッダーの場合の考えられる割当て
| ソース | ターゲット | 例 |
|---|---|---|
|
XPath式(パート・レベルより下) |
プロパティ |
|
|
プロパティ |
XPath式(パート・レベルより下) |
|
|
定数 |
XPath式(パート・レベルより下) |
|
|
定数 |
XPath式(パート・レベルより下) |
|
|
XPath式 |
XPath式 |
|
|
XPath式(パート・レベルより下) |
XPath式(パート・レベルより下) |
|
assignアクティビティについては、次の点に注意してください。
assignアクティビティは、Oracle Mediatorの<copy>要素に記述されている順序で実行されます。
ソースがターゲットのプロパティに割り当てられている場合でも、そのソースのXPath式は常にリーフ・ノードを参照する必要があります。リーフ・ノードを参照していない場合、ソースの子ノードの値はすべて連結されて、ターゲットのプロパティに割り当てられます。例19-4に詳細を示します。
例19-4 リーフ・ノードを参照するXPath式
<copy target="$out.property.jca.file.FileName" expression="$in.body/imp1:request/ProductReq/Make" xmlns:imp1="http://xmlns.oracle.com/psft"/>
|
注意: リーフ・ノードとは、子ノードのないノードです。 |
定数またはプロパティがターゲットのXPath式に割り当てられる場合でも、そのターゲットのXPath式は常にリーフ・ノードを指し示す必要があります。リーフ・ノードを指し示していない場合、リーフ以外のノードには文字列値のみが含まれ、.xsdファイルに従って無効なXMLが生成される可能性があります。例19-5に詳細を示します。
例19-5 リーフ・ノードを指し示すターゲットのXPath式
<copy target="$out.request/inp1:request/ProductReq/Make" value="NewMakeValue" xmlns:inp1="http://xmlns.oracle.com/psft"/>
この例では、$out.request/inp1:request/ProductReq/Makeがリーフ・ノードを参照しています。
トランスフォーメーションが使用可能な場合は、ソース・パートをターゲット・パートに割り当てても、そのターゲットは上書きされます。これは、トランスフォーメーションの最初にassignアクティビティが発生するためです。トランスフォーメーションが使用不可の場合は、assignアクティビティによってターゲットが作成されます。例19-6に詳細を示します。
ターゲット・ペイロードのいずれかの子ノードを変更する必要がある場合は、次のような2つのユースケースがあります。
ソースの子ノードの1つのみをターゲットに伝播する必要がある場合は、最初にトランスフォーメーションが起動されていないことを確認します。次に、必要な子ノードを指し示すソースのXPath式を割り当てます。例19-9に詳細を示します。
例19-9 ソースの1つの子ノードがターゲットに伝播される場合
<copy target="$out.request/imp1:ProductReq" expression="$in.body/imp1:request/ProductReq" xmlns:imp1="http://xmlns.oracle.com/psft"/>
このケースで、$in.body/imp1:request/ProductReqから評価されるソース要素には、子ノードのみが含まれ、ルート要素から始まる完全なツリー構造は含まれていません。例19-10に詳細を示します。
Oracle Mediatorに複数のassignアクティビティがあり、各ソースのXPath式が別々の子ノードを指し示している場合は、次のような2つのユースケースがあります。
トランスフォーメーションが使用可能な場合は、ターゲットの対応する子ノードが更新されます。
トランスフォーメーションが使用不可の場合、ターゲットは複数パートのターゲットであり、各パートがソースの子ノードを参照している必要があります。
ヘッダーの場合、passThroughHeaderプロパティが設定されている場合は、次のようになります。
トランスフォーメーションのヘッダー操作は、ターゲットのヘッダーで更新されます。
パート・レベルのassignアクティビティによって、ターゲットのヘッダー・パートが上書きされます。
パート・レベルより下のノードのassignアクティビティによって、ターゲットの対応するノードが更新されます。
(パート・レベルより下の)複数のソース・ノードが(パート・レベルより下の)同じターゲット・ノードに割り当てられている場合、そのターゲット・ノードには、assignアクティビティの最後のcopy要素の値が含まれます。例19-11に詳細を示します。
例19-11 同じターゲット・ノードに複数のソース・ノードが割り当てられる場合
<copy target="$out.request/imp1:request/ProductReq/Make" expression="$in.body/imp1:request/ProductReq/Model" xmlns:imp1="http://xmlns.oracle.com/psft"/> <copy target="$out.request/imp1:request/ProductReq/Make" expression="$in.body/imp1:request/Description" xmlns:imp1="http://xmlns.oracle.com/psft"/>
例19-11で、最初のcopy要素は、2番目のcopy要素によって上書きされるため何も効果がありません。
XPath式の結果がリスト(複数発生)になる場合は、次の2つのユースケースがあります。
リストに単一の要素が含まれる場合は、XPath式が伝播されます。
リストに複数の要素が含まれる場合、XPath式はサポートされません。
ソースの子ノードをターゲットの子ノードに割り当てると、次のアクティビティが発生します。
ソースの子ノードの名前とネームスペースが、ターゲットのノード名とネームスペースによってそれぞれ上書きされます。
ターゲットの子ノードは、ターゲット・ノードの親ノードにあるソースの子ノードによって置換されます。
フィルタを定義するため、または割当てソースや割当てターゲットを定義するためにOracle Mediatorから式ビルダーを起動すると、WSDLファイルが解析されます。その際に、図19-24に示すように、現在のルーティング・ルール操作のSOAPヘッダーが自動的に検出され、このSOAPヘッダーが変数として、inフォルダまたはoutフォルダにheader./ns_elementName/のように表示されます。ここで、nsはネームスペース接頭辞、elementNameはヘッダー・スキーマのルート要素名です。
次の例で詳細を示します。
例1: ネームスペース接頭辞wsseおよびns1がすでに定義されている場合
ネームスペース接頭辞wsseおよびns1がWSDLファイルまたは.mplanファイルにすでに定義されているとします。この場合、XPath式は次のように記述できます。
$in.header.wsse_Security/wsse:Security/ns1:Foo/Priority
例2: WSDLファイルにネームスペースが事前定義されていないスキーマの場合
WSDLファイルにネームスペースが事前定義されていないスキーマを使用するとします。この場合、式ビルダーでは、接頭辞のかわりに{full_namespace}を入力できる機能が提供されます。さらに、式ビルダーによって一意の接頭辞が生成され、接頭辞の定義が.mplanファイルに追加されます。
たとえば、式ビルダーに例19-12に示す式を入力するとします。
例19-12 式
$in.header.{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-sec
ext-1.0.xsd}_Security/
{"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xs
d"}:
Security/{"http://www.globalcompany.com/ns/OrderBooking"}:Foo/Priority
.mplanファイルには、例19-13に示すコンテンツが含まれています。
例19-13 .mplanファイルのコンテンツ
xmlns:ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity- secext-1.0.xsd" xmlns:ns2="http://www.globalcompany.com/ns/OrderBooking" ... expression="$in.header.ns1_Security/ns1:Security/ns2:Foo/Priority"
デフォルトでは、SOAPヘッダーはOracle Mediatorを介して渡されません。passThroughHeaderエンドポイント・プロパティを、対応するOracle Mediatorルーティング・サービスに追加する必要があります。
<property name="passThroughHeader">true</property>
たとえば、このプロパティを追加するには、composite.xmlファイルを例19-14に示すように変更できます。
例19-14 passThroughHeaderプロパティ
<component name="Mediator1">
<implementation.mediator src="Mediator1.mplan"/>
<property name="passThroughHeader">true</property>
</component>
ヘッダーを渡すには、ソースとターゲットのQName(名前とネームスペース)が同じである必要があります。ソースとターゲットのQNameが異なる場合は、トランスフォーメーションまたはパートレベルの割当てのいずれかを実行する必要があります。
(トランスフォーメーションまたはassignを使用しない)passthrough Oracle Mediatorの場合、ソースとターゲットのパートQNameが同じでない場合は、Oracle Mediatorがメッセージ・ペイロードをターゲット・サービスに渡す際にエラーが発生していない点に注意する必要があります。ただし、この処理はターゲット・サービスでエラーになる場合があります。これは、メッセージ・ペイロードはターゲット・サービスのメッセージ構造に従って再構築されていないためです。
|
注意:
|
ユースケースによっては、WSDLファイルからヘッダー・スキーマを識別できない場合があります。たとえば、メッセージに付加されたセキュリティ・ヘッダーや、抽象的なWSDLファイルを使用して作成されるOracle Mediatorのヘッダーなどです。そのようなヘッダーにアクセスするには、式ビルダーにXPath式を手動で入力する必要があります。
例19-15に、ヘッダー式の構文を示します。
例19-15 ヘッダー式の構文
$in.header.<header root element namespace prefix>_<header root element name>/<xpath>
例19-16に示すヘッダーがあるとします。
例19-16 ヘッダーの構文
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-sec ext-1.0.xsd"> <Priority>234</Priority> </wsse:Security>
フィルタ式は次のようになります。
$in.header.wsse_Security/wsse:Security/Priority = '234'
割当て式は例19-17に示すようになります。
例19-17 代入式
<copy target="$out.property.jca.jms.priority" expression="$in.header.wsse_Security/wsse:Security/Priority"/>
これらの式が機能するには、.mplanファイルのルート要素に例19-18に示す属性を追加する必要があります。
フィルタ式の例は、次のとおりです。
$in.property.tracking.ecid = '2'
割当て式の例は、次のとおりです。
<copy target="$out.property.tracking.ecid" value="$in.property.tracking.ecid"/>
インバウンド・メッセージとその様々なパートは、Schematronファイルを指定して検証できます。Schematronバージョン1.5がサポートされているバージョンです。
Schematronスキーマを指定して、インバウンド・メッセージとその様々なパートを検証する手順は、次のとおりです。
セマンティク検証を使用する手順は、次のとおりです。
「セマンティックの検証」フィールドの右側にある検証ファイルの選択アイコンをクリックします。
「検証」ダイアログが表示されます。
「追加」をクリックします。
「検証の追加」ダイアログが表示されます。
「パート」リストから、メッセージ・パートを選択します。
「ファイル」フィールドの右側にある「検索」をクリックします。
「SOAリソース・ブラウザ」ダイアログが表示されます。
Schematronファイルを選択し、「OK」をクリックします。
|
注意:
|
図19-25に示すように、「検証の追加」ダイアログが更新されます。
「OK」をクリックします。
図19-26に示すように、「検証」ダイアログが更新されます。
「追加」をクリックして別のメッセージ・パートのSchematronファイルを指定するか、「OK」をクリックします。
Schematronスキーマの作成方法の詳細は、次の場所から入手できるリソースを参照してください。
|
注意: セマンティク検証では、各要素名の長さをチェックした場合、異なる入力セットに対して要素名が変わる場合があります。これは、パーサーが空白をテスト・ノードとして処理するため、ノード間に空白がある場合に発生します。 |
Javaコールアウトを使用すると、Oracle Mediatorを介してフローするメッセージの操作に外部のJavaクラスを使用できます。操作またはイベント・サブスクリプションごとに、Javaコールアウトは1つのみサポートされます。コールアウト・クラスは、oracle.tip.mediator.common.api.IjavaCalloutインタフェースを実装する必要があります。コールアウトは、静的ルーティングおよび動的ルーティングの両方に使用できます。図19-27に、2つの操作が指定されたOracle Mediatorのサンプルを示します。2つの操作には、それぞれルーティング・ルールが1つあり、最初の操作にはコールアウト・クラスが指定されています。
Javaコールアウト・クラスを使用できるようにする手順は、次のとおりです。
サーバーでJavaコールアウト・クラスが使用できることが必要です。このためには、次のいずれかの方法を使用します。
JavaクラスをSCA-INF/classesフォルダにコピーします。
Javaクラスが含まれているJARファイルをSCA-INF/libフォルダにコピーします。
Javaクラスが含まれているJARファイルを$DOMAIN_HOME/libフォルダにコピーします。
Javaコールアウト・クラスを複数のOracle Mediatorで使用できるようにするには、Javaクラスが含まれているJARファイルを$DOMAIN_HOME/libフォルダにコピーする必要があります。
コールアウトのJavaクラスを入力する手順は、次のとおりです。
Javaクラスを手動で入力するか、「クラス・ブラウザ」からクラスを選択できます。
図19-28に示すように、Javaコールアウト・クラスの名前を手動で入力するには、「コールアウト先」フィールドにクラス名を入力し始めます。Oracle JDeveloperのオートコンプリート機能によって、現在のプロジェクトのアドレスとクラスが挿入されます。
使用可能なクラスをリストから選択するには、「Javaコールアウト・クラスを選択します。」アイコンをクリックします。
図19-29に示すように、標準のOracle JDeveloperクラス・ブラウザが表示されます。
クラス・ブラウザは、oracle.tip.mediator.common.api.IjavaCalloutインタフェースを実装するクラスのみが表示されるようにフィルタリングされます。
ペイロードのルート要素を設定する手順(フィルタ式を使用している場合)は、次のとおりです。
Oracle MediatorにJavaコールアウトがあり、同じOracle Mediatorでフィルタ式を使用している場合は、ペイロードのルート要素を例19-19に示すように設定する必要があります。
例19-19 ペイロードのルート要素の設定
changexmldoc = XmlUtils.getXmlDocument(ChangedDoc); String mykey = "request"; message.addPayload(mykey,changexmldoc.getDocumentElement());
ドメイン値マップと相互参照関数を有効にする手順は、次のとおりです。
Javaコールアウトでドメイン値マップ関数または相互参照関数を使用するには、soa-xpath-exts.jarファイルをプロジェクトに追加し、コードに必要なJavaクラスをインポートする必要があります。
Oracle JDeveloperプロジェクト・エクスプローラで、Javaコールアウトを含むプロジェクトの名前を右クリックします。
「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログが表示されます。
図19-30に示すように、左側のパネルで、「ライブラリとクラスパス」を選択します。
「JAR/ディレクトリの追加」をクリックします。
図19-31に示すように、「アーカイブまたはディレクトリの追加」が表示されます。
エクスプローラ・ツリーで、ディレクトリを展開して<JDEV_HOME>/jdeveloper/soa/modules/oracle.soa.fabric_11.1.1/soa-xpath-exts.jarを選択し、次に「選択」をクリックします。
JARファイルが「クラスパス・エントリ」リストに表示されます。
「OK」をクリックします。
|
注意: ドメイン値マップ関数を使用する場合は、Javaクラスに次をインポートします。
相互参照(xref)関数を使用する場合は、Javaクラスに次をインポートします。
|
Oracle Mediator JavaコールアウトAPI
JavaコールアウトAPIでは、oracle.tip.mediator.common.api.IjavaCalloutおよびoracle.tip.mediator.common.api.CalloutMediatorMessageという2つのインタフェースを定義します。
表19-4では、oracle.tip.mediator.common.api.IjavaCalloutインタフェースのメソッドをリストして説明します。
表19-4 IjavaCalloutインタフェースのメソッドの説明
| メソッド | 説明 |
|---|---|
|
|
コールアウト実装クラスが初めてインスタンス化されるときに起動されます。 |
|
|
Oracle Mediatorがケースの実行を開始する前にコールされます。このメソッドをカスタマイズすると、検証および拡張機能を組み込むことができます。 |
|
|
Oracle Mediatorが特定のケースの実行を開始する前にコールされます。このメソッドをカスタマイズすると、ケース固有の検証および拡張機能を組み込むことができます。 |
|
|
Oracle Mediatorがコールバック処理の実行を終了する前にコールされます。このメソッドをカスタマイズすると、コールバックの監査およびカスタムのフォルト・トラッキングを実行できます。 |
|
|
Oracle Mediatorがケースの実行を終了した後にコールされます。このメソッドをカスタマイズすると、レスポンスの監査およびカスタムのフォルト・トラッキングを実行できます。 |
|
|
Oracle Mediatorがケースの実行を開始した後にコールされます。このメソッドをカスタマイズすると、レスポンスの監査およびカスタムのフォルト・トラッキングを実行できます。 |
|
|
Oracle Mediatorがコールバック処理の実行を終了した後にコールされます。このメソッドをカスタマイズすると、コールバックの監査およびカスタムのフォルト・トラッキングを実行できます。 |
|
注意: preRoutingRuleメソッドまたはpreRoutingメソッドで、Javaコールアウトを使用してOracle Mediatorのメッセージ・プロパティを変更した場合は、Oracle Mediatorの割当て機能を使用して、変更したプロパティをアウトバウンド・メッセージに明示的にコピーする必要があります。たとえば、Javaコールアウトでjca.file.FileNameを変更している場合は、Oracle Mediatorの割当て文を次のように更新する必要があります。
<assign> <copy target="$out.property.jca.file.FileName" expression="$in.property.jca.file.FileName"/> </assign> |
表19-5で、CalloutMediatorMessageインタフェースのメソッドについて説明します。
表19-5 CalloutMediatorMessageインタフェースのメソッドの説明
| メソッド | 説明 |
|---|---|
|
|
Oracle Mediatorメッセージのペイロードを設定します。 |
|
|
Oracle Mediatorメッセージにプロパティを追加します。 |
|
|
Oracle Mediatorメッセージにヘッダーを追加します。 |
|
|
プロパティ名を指定してOracle Mediatorメッセージのプロパティを取得します。 |
|
|
Oracle Mediatorメッセージのプロパティを取得します。 |
|
|
Oracle MediatorメッセージのインスタンスIDを取得します。このインスタンスIDは、該当する特定のメッセージに対して作成されたOracle MediatorインスタンスIDです。 |
|
|
Oracle Mediatorメッセージのペイロードを取得します。 |
|
|
Oracle Mediatorメッセージのヘッダーを取得します。 |
|
|
Oracle Mediatorサービス・コンポーネントのcomponentDNを取得します。 |
|
注意:
|
脚注1インタフェースのダミー実装は、実装クラスによって、特定のインタフェースで宣言されているすべてのメソッドの定義が提供されることを意味しますが、空のメソッド本体を1つ以上の定義済メソッドに指定することはできます。ダミー実装クラスの拡張は、インタフェースを実装してすべてのメソッドを定義する場合と異なり、メソッドのサブセットのみを上書きできるためより簡単です。
Javaコールアウト・クラスのサンプル
例19-20は、Javaコールアウト・クラスのサンプルを示しています。
例19-20 Javaコールアウト・クラスのサンプル
package qa.as11tests.javacallout;
import com.collaxa.cube.persistence.dto.XmlDocument;
import com.oracle.bpel.client.NormalizedMessage;
import java.util.logging.Logger;
import java.util.Map;
import java.util.Iterator;
import oracle.tip.mediator.common.api.CalloutMediatorMessage;
import oracle.tip.mediator.common.api.ExternalMediatorMessage;
import oracle.tip.mediator.common.api.IJavaCallout;
import oracle.tip.mediator.common.api.MediatorCalloutException;
import oracle.tip.mediator.metadata.CaseType;
import oracle.tip.mediator.utils.XmlUtils;
import oracle.tip.pc.services.functions.ExtFunc;
import oracle.xml.parser.v2.XMLDocument;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.Node;
public class JavaCalloutSanity implements IJavaCallout {
Logger logger = Logger.getLogger("Callout");
public JavaCalloutSanity() { }
public void initialize(Logger logger) throws MediatorCalloutException {
this.logger = logger;
this.logger.info("Initializing...");
}
public boolean preRouting(CalloutMediatorMessage calloutMediatorMessage) {
System.out.println("Pre routing...");
String sPayload = "null";
String sPayload_org = "null";
for (Iterator msgIt = calloutMediatorMessage.getPayload().entrySet().iterator();
msgIt.hasNext(); ) {
Map.Entry msgEntry = (Map.Entry)msgIt.next();
Object msgKey = msgEntry.getKey();
Object msgValue = msgEntry.getValue();
if (msgKey.equals("request"))
sPayload = XmlUtils.convertDomNodeToString((Node)msgValue);
}
sPayload_org = sPayload;
String tobeReplaced = "CHANGE_THIS";
String replaceWith = "JAVA_CALLOUT_||_PRE_ROUTING";
int start = sPayload.indexOf(tobeReplaced);
StringBuffer sb = new StringBuffer();
sb.append(sPayload.substring(0, start));
sb.append(replaceWith);
sb.append(sPayload.substring(start + tobeReplaced.length()));
String changedPayload = sb.toString();
String uid;
try {
uid = ExtFunc.generateGuid();
} catch (Exception e) {
}
XMLDocument changedoc;
try {
changedoc = XmlUtils.getXmlDocument(changedPayload);
String mykey = "request";
calloutMediatorMessage.addPayload(mykey,changedoc);
//calloutMediatorMessage.getPayload().put(mykey, changedoc);
} catch (Exception e) {
}
System.out.println("Changed from : \n"+sPayload_org+"\nTo\n"+changedPayload);
System.out.println("End Pre routing...\n\n");
return false;
}
public boolean postRouting(CalloutMediatorMessage calloutMediatorMessage,
CalloutMediatorMessage calloutMediatorMessage1,
Throwable throwable) throws MediatorCalloutException {
System.out.println("Start Post routing...");
String sPayload = "null";
String sPayload_org = "null";
for (Iterator msgIt = calloutMediatorMessage1.getPayload().entrySet().iterator();
msgIt.hasNext(); ) {
Map.Entry msgEntry = (Map.Entry)msgIt.next();
Object msgKey = msgEntry.getKey();
Object msgValue = msgEntry.getValue();
if(msgKey.equals("reply"))
sPayload = XmlUtils.convertDomNodeToString((Node)msgValue);
}
sPayload_org = sPayload;
String tobeReplaced = "POST_ROUTING_RULE_REQUEST_REPLY";
String replaceWith = "POST_ROUTING_RULE_REQUEST_REPLY_||_POSTROUTING_||_JAVA_CALLOUT_WORKING";
int start = sPayload.indexOf(tobeReplaced);
StringBuffer sb = new StringBuffer();
sb.append(sPayload.substring(0, start));
sb.append(replaceWith);
sb.append(sPayload.substring(start + tobeReplaced.length()));
String changedPayload = sb.toString();
XMLDocument changedoc;
try {
changedoc = XmlUtils.getXmlDocument(changedPayload);
String mykey = "reply";
calloutMediatorMessage1.addPayload(mykey,changedoc.getDocumentElement());
// calloutMediatorMessage1.getPayload().put(mykey, changedoc.getDocumentElement());
} catch (Exception f) {
}
System.out.println("Changed from : \n"+sPayload_org+"\nTo\n"+
changedPayload);
System.out.println("End Post routing...\n\n");
return false;
}
public boolean preRoutingRule(CaseType caseType,
CalloutMediatorMessage calloutMediatorMessage) {
System.out.println("\nStart PreRoutingRule.\n");
String sPayload = "null";
String sPayload_org = "null";
for (Iterator msgIt =
calloutMediatorMessage.getPayload().entrySet().iterator();
msgIt.hasNext(); ) {
Map.Entry msgEntry = (Map.Entry)msgIt.next();
Object msgKey = msgEntry.getKey();
Object msgValue = msgEntry.getValue();
if(msgKey.equals("request"))
sPayload = XmlUtils.convertDomNodeToString((Node)msgValue);
}
sPayload_org = sPayload;
String tobeReplaced = "PRE_ROUTING";
String replaceWith = "PRE_ROUTING_||_PRE_ROUTING_RULE";
int start = sPayload.indexOf(tobeReplaced);
StringBuffer sb = new StringBuffer();
sb.append(sPayload.substring(0, start));
sb.append(replaceWith);
sb.append(sPayload.substring(start + tobeReplaced.length()));
String changedPayload = sb.toString();
XMLDocument changedoc;
try {
changedoc = XmlUtils.getXmlDocument(changedPayload);
String mykey = "request";
calloutMediatorMessage.addPayload(mykey,changedoc);
// calloutMediatorMessage.getPayload().put(mykey, changedoc);
} catch (Exception e) {
}
System.out.println("Changed from : \n"+sPayload_org+"\nTo\n"+changedPayload);
System.out.println("End PreRoutingRule.\n\n");
return true;
}
public boolean postRoutingRule(CaseType caseType,
CalloutMediatorMessage calloutMediatorMessage,
CalloutMediatorMessage calloutMediatorMessage1,
Throwable throwable) {
System.out.println("Start PostRoutingRule.");
String req_sPayload = "null";
String req_sPayload_org = "null";
String rep_sPayload = "null";
String rep_sPayload_org = "null";
for (Iterator msgIt =
calloutMediatorMessage.getPayload().entrySet().iterator();
msgIt.hasNext(); ) {
Map.Entry msgEntry = (Map.Entry)msgIt.next();
Object msgKey = msgEntry.getKey();
Object msgValue = msgEntry.getValue();
if(msgKey.equals("request"))
req_sPayload = XmlUtils.convertDomNodeToString((Node)msgValue);
}
req_sPayload_org = req_sPayload;
String tobeReplaced = "PRE_ROUTING_RULE";
String replaceWith = "PRE_ROUTING_RULE_||_POST_ROUTING_RULE_REQUEST";
int start = req_sPayload.indexOf(tobeReplaced);
StringBuffer sb = new StringBuffer();
sb.append(req_sPayload.substring(0, start));
sb.append(replaceWith);
sb.append(req_sPayload.substring(start + tobeReplaced.length()));
String changedPayload = sb.toString();
XMLDocument changedoc;
try {
changedoc = XmlUtils.getXmlDocument(changedPayload);
String mykey = "request";
calloutMediatorMessage.addPayload(mykey,changedoc);
// calloutMediatorMessage.getPayload().put(mykey, changedoc);
} catch (Exception e) {
}
for (Iterator msgIt =
calloutMediatorMessage1.getPayload().entrySet().iterator();
msgIt.hasNext(); ) {
Map.Entry msgEntry = (Map.Entry)msgIt.next();
Object msgKey = msgEntry.getKey();
Object msgValue = msgEntry.getValue();
if(msgKey.equals("reply"))
rep_sPayload = XmlUtils.convertDomNodeToString((Node)msgValue);
}
rep_sPayload_org = rep_sPayload;
tobeReplaced = "PRE_ROUTING_RULE";
replaceWith = "PRE_ROUTING_RULE_||_POST_ROUTING_RULE_REQUEST_REPLY";
start = rep_sPayload.indexOf(tobeReplaced);
sb = new StringBuffer();
sb.append(rep_sPayload.substring(0, start));
sb.append(replaceWith);
sb.append(rep_sPayload.substring(start + tobeReplaced.length()));
changedPayload = sb.toString();
try {
changedoc = XmlUtils.getXmlDocument(changedPayload);
String mykey = "reply";
calloutMediatorMessage1.addPayload(mykey,changedoc.getDocumentElement());
// calloutMediatorMessage1.getPayload().put(mykey, changedoc.getDocumentElement());
} catch (Exception e) {
}
System.out.println("Changed from : \n"+req_sPayload_org+"\nTo\n"+changedPayload);
System.out.println("End postRoutingRule\n\n");
return true;
}
}
動的ルーティングの基本的な考え方は、プロセスが経由するパスを決定する制御ロジックを、そのプロセスの実行から分離することです。動的ルーティングのシナリオでは、デシジョン・マトリックスによって各ルーティングに対して選択されるレベル2タイプのサービスが決定されます。レベル2タイプのサービスのデシジョンに影響を与える要因は、チャネル、顧客タイプなどです。このソリューションによって、ビジネス・アナリストはルーティングを変更せずに、このデシジョン・マトリックスを外部から変更できます。アウトバウンド・サービスを決定するためには、デシジョン・マトリックスを評価する必要があります。
動的ルーティング・ルールを作成する手順は、次のとおりです。
図19-32に示すように、メディエータ・エディタの動的ルーティング・ルールのオプションを使用します。
このウィンドウで、新しいビジネス・ルール・サービス・コンポーネントが作成され、Oracle Mediatorサービス・コンポーネントのSOAコンポジット内のOracle Mediatorサービス・コンポーネントに接続されます。ビジネス・ルール・サービス・コンポーネントとOracle Mediatorサービス・コンポーネント間のワイヤ・リンクは、実装の詳細とみなされ、図19-33に示すように、SOAコンポジット・エディタでは点線で表示されます。
図19-33 ビジネス・ルール・サービス・コンポーネントとOracle Mediatorサービス・コンポーネント間のワイヤ・リンクが表示されたSOAコンポジット・エディタ
ビジネス・ルール・サービス・コンポーネントには、ルール・ディクショナリが含まれています。ルール・ディクショナリは、ファクト・タイプ、ルールセット、ルール、デシジョン表など、ルール・エンジン・アーチファクトに対するメタデータ・コンテナです。ルール・ディクショナリは、ビジネス・ルール・サービス・コンポーネントの作成過程で、次のデータを使用して事前に初期化されます。
ファクト・タイプ・モデル
ファクト・タイプ・モデルは、ルールのモデル化に使用できるデータ・モデルです。ルール・ディクショナリには、BPELプロセスのphaseアクティビティの入力に対応するファクト・タイプ・モデルと、Oracle Mediatorサービス・コンポーネントとビジネス・ルール・サービス・コンポーネント間の規定の一部として必要な固定データ・モデルの一部が移入されます。
ルールセット
ルールセットは、ルールのグループ化メカニズムとして使用されるルールのコンテナです。ルールセットはサービスとして公開できます。ビジネス・ルール・サービス・コンポーネントの作成過程で、1つのルールセットがルール・ディクショナリ内に作成されます。
デシジョン表(またはマトリックス)
ルール・エンジンから見ると、デシジョン表は、ルールの条件およびアクション部分のファクト・タイプ・モデルの要素が同じであるルールの集合です。デシジョン表を使用すると、ルールを表形式で表示できます。ビジネス・ルール・サービス・コンポーネントの作成過程で、ルールセット内に新規デシジョン表が作成されます。
デシジョン・サービス
デシジョン・サービスは、ビジネス・ルール・サービス・コンポーネントの作成過程で作成され、ルールセットをビジネス・ルール・サービス・コンポーネントのサービスとして公開します。Oracle Mediatorサービス・コンポーネントでは、サービス・インタフェースを使用してデシジョン表を評価します。
phaseアクティビティの必要なアーチファクトがすべて作成されると、ウィザードでは、フェーズ・デシジョン・マトリックス(PDM)のモデル化が開始されます。Oracle JDeveloperのビジネス・ルール・デザイナが起動され、フェーズ・デシジョン・マトリックスを編集できるようになります。図19-34に、ビジネス・ルール・デザイナ内のデシジョン表のサンプルを示します。
動的ルーティングを作成した後は、「動的ルールの編集」をクリックして、関連デシジョン・マトリックスを変更できます。ビジネス・ルール・デザイナが起動され、ビジネス・ルール・サービス・コンポーネントの関連デシジョン表の変更が可能になります。Oracle Mediatorサービス・コンポーネントに対して動的ルーティングを作成した後は、その動的ルーティングを削除しないかぎり、静的ルーティングに戻ることはできません。現在、これら2つのタイプのルーティングを組み合せて使用するオプションはありません。
動的ルーティング・オプションを選択した後のメディエータ・エディタは、図19-35のようになります。
ソース・ビューは次のように変更されます。
<Mediator name="Shipment" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/sca/1.0/mediator">
<operation name="execute" deliveryPolicy="AllOrNothing" priority="0">
<switch decisionServiceRef="Phase1DecisionService"
decisionServiceOperation="executeFunction"></switch>
</operation>
</Mediator>
switch要素には、デシジョン・サービス参照および操作の詳細が含まれています。これによって、Oracle Mediatorサービス・コンポーネントは、動的ルーティング・デシジョンを取得するためのデシジョン・サービスを実行時に起動できます。動的デシジョンは、実行時のビジネス・ルール・サービス・エンジン・ユーザー構成によって返されます。
外部サービスの起動には、bindingInfoという特別な属性が含まれます。この属性には、起動を動的にするためのバインディング情報が含まれています。
Oracle Mediatorで動的ルーティング・ルールを使用する場合は、次の制限に注意してください。
現在は、SOAPバインディングのみがサポートされています。composite.xmlファイルには、ダミーのSOAPバインディングが作成されます。このエンドポイントは、NMプロパティを介して実行時にOracle Mediatorによって上書きされます。このため、アウトバウンド・サービスはSOAPを介してのみコールできます。
動的ルーティング・ルールによってペイロード操作が制限されます。割当て、トランスフォーメーションまたは検証は実行できません。
参照WSDLファイル(レイヤー2またはコールした参照)には、自動的に作成されるフェーズ参照と同じ抽象的なWSDLファイルが必要です。
動的ルーティングは、同期インタフェースまたは一方向インタフェースを使用するOracle Mediatorには使用できません。
Oracle Mediatorでは、ルーティング・ルールで指定された条件に従ってメッセージが処理されます。ルーティング・ルールで指定されたいずれの条件も満たさないために、受信メッセージが処理されない場合もあります。このようなメッセージに使用するデフォルト・ルーティング・ルールを定義できます。デフォルト・ルーティング・ルールは、他のルーティング・ルールの条件がいずれも満たされない場合に実行されます。
デフォルト・ルーティング・ルールは、第19.2.2項「静的ルーティング・ルールの作成方法」で説明したルーティング・ルールと同じです。デフォルト・ルーティング・ルールが他のルーティング・ルールと異なる唯一の点は、デフォルト・ルーティング・ルールには関連する条件がないことです。それ以外は、ターゲット・サービス、レスポンス処理、フォルト処理などすべてにおいて、デフォルト・ルーティング・ルールは他のルーティング・ルールと同じです。
|
注意:
|
デフォルト・ルーティング・ルールは、順次ルールまたはパラレル・ルールのいずれかに設定できます。順次またはパラレルに関係なく、デフォルト・ルーティング・ルールは、他のルーティング・ルールの条件が満たされない場合に実行されることが保証されています。デフォルト・ルールが実行された場合、Oracle Mediatorの監査証跡には、すべてのルーティング・ルールのフィルタ条件が満たされず、デフォルト・ルーティング・ルールのフィルタ条件が満たされて実行されたことが示されます。例19-21に詳細を示します。
例19-21 デフォルト・ルールのシナリオ
ActivityJan 7, 2010 4:35:15 PM Message onCase "fileout2.Write" Jan 7, 2010 4:35:15 PM Message Evaluation of xpath condition " No Filter (DEFAULT CASE) " resulted true
デフォルト・ルーティング・ルールも含めて、すべてのルーティング・ルールは順次またはパラレルのルーティング・ルールとして定義できるため、想定されるルーティング・ルールの動作は多数あります。次の各項では、各組合せと想定される動作について説明します。
順次のデフォルト・ルーティング・ルール
順次のデフォルト・ルーティング・ルールでは、次のシナリオが考えられます。
Oracle Mediatorの他のルーティング・ルールがすべて順次の場合: これは、デフォルト・ルーティング・ルールも含めて、すべてのルーティング・ルールのタイプが順次である最も単純なケースです。すべてのルーティング・ルールのフィルタ条件が実行時に評価され、いずれのフィルタ条件も一致しない場合は、順次のデフォルト・ルーティング・ルールが実行されます。順次のデフォルト・ルーティング・ルールは、受信メッセージと同じトランザクションで実行されます。デフォルト・ルールの実行後に、事後Javaコールアウトが発生します。
Oracle Mediatorのルーティング・ルールの少なくとも1つがパラレルである場合: これは、デフォルト・ルーティング・ルールが順次であり、他のルーティング・ルールの少なくとも1つがパラレルである複雑なケースです。実行時のデフォルトの動作では、最初に順次ルーティング・ルールがすべて実行された後で、パラレルのルーティング・ルールが実行されます。したがって、デフォルト・ルールは、他のすべてのルーティング・ルールがfalseであると評価された後でのみ実行する必要があるため注意が必要です。
この場合、サーバーでは、最初にパラレル・ルールのフィルタ条件が評価された後でデフォルト・ルーティング・ルールのフィルタ条件が評価されます。他のいずれのフィルタ条件も一致しない場合は、順次のデフォルト・ルーティング・ルールが実行されます。
パラレルのデフォルト・ルーティング・ルール
パラレルのデフォルト・ルーティング・ルールでは、次のシナリオが考えられます。
Oracle Mediatorの他のルーティング・ルールがすべてパラレルの場合: これは簡単なケースです。デフォルト・ルーティング・ルールは、他のルーティング・ルールで指定されたいずれかのフィルタ条件が一致する場合は実行されません。フィルタ条件がいずれも一致しない場合は、デフォルト・ルーティング・ルールが非同期で実行されます。
Oracle Mediatorの他のルーティング・ルールが順次またはパラレルである場合: これは複雑ですが一般的なユースケースです。使用可能な他の順次またはパラレルのルーティング・ルールがあり、デフォルト・ルーティング・ルールがパラレルの場合です。デフォルト・ルーティング・ルールは、他の順次またはパラレルのルーティング・ルール基準のいずれかが一致した場合は実行されません。条件がいずれも一致しない場合は、デフォルト・ルーティング・ルールが非同期で実行されます。
|
注意: デフォルト・ルーティング・ルールが自動的に実行されるということは、デフォルト・ルーティング・ルールが、特定のOracle Mediatorサービス・コンポーネントに対して実行された唯一のケースであることを意味します。同様に、Oracle Mediatorサービス・コンポーネントに、フィルタ条件が指定されていない1つのルーティング・ルールがあり、デフォルト・ルーティング・ルールもある場合、そのデフォルト・ルーティング・ルールが実行されることはありません。 |
デフォルト・ルーティング・ルールのターゲットは、他の既存ルーティング・ルールのサポートされているターゲットと同じです。つまり、ターゲットにはサービス、イベントまたはエコーを設定できます。同様に、デフォルト・ルーティング・ルールのターゲット・サービスからのレスポンスは、コール元に転送するか、返すことができます。ターゲット・サービスからフォルトが返された場合は、他のルーティング・ルールで処理される場合と同様に処理されます。
|
注意: 他のルーティング・ルールの評価または実行時に例外が発生した場合、デフォルト・ルーティング・ルールは実行されません。 |
デフォルト・ルーティング・ルールのSchematron検証、トランスフォーメーションおよび割当機能は、他のルーティング・ルールと同様に動作します。
事前Javaコールアウトまたは事後Javaコールアウトの現在の動作は、他のルーティング・ルールの場合と同様です。Javaコールアウトの目的では、デフォルト・ルーティング・ルールは別のルーティング・ルールとみなされます。したがって、デフォルト・ルーティング・ルールが実行されるシナリオの場合、postRouting()コールバック・メソッドは、デフォルト・ルーティング・ルールが実行された後でのみ発生します。
|
注意: 事後Javaコールアウトは、順次ルールの実行後に発生し、パラレル・ルールの実行の完了は待機しません。したがって、デフォルト・ルーティング・ルールが順次の場合、postRouting()コールバック・メソッドは、デフォルト・ルーティング・ルールの実行後に発生します。デフォルト・ルーティング・ルールがパラレルの場合、postRouting()コールバックは、すべての順次ルールが実行された後に発生し、パラレルのデフォルト・ルーティング・ルールの実行は待機しません。 |
ルーティング・ルールをデフォルト・ルーティング・ルールとして設定するには、図19-2に示すデフォルト・ルーティング・ルールとして設定アイコンをクリックします。.mplanファイルは、図19-36に示すように変わります。
図19-36 デフォルト・ルーティング・ルールが設定されたOracle Mediatorの.mplanファイル
CustomerRouterユースケースは、SOAコンポジット・サンプル・アプリケーションのOracle Mediatorを使用してメッセージをルーティングする方法の概要を説明します。この項で説明するサンプル・ファイルをダウンロードするには、次のURLを参照してください。
https://soasamples.samplecode.oracle.com
ファイルは、Oracle Mediatorの基本的なルーティング・サンプルにあります。
CustomerRouterユースケースは次の手順で構成されます。
ReadCustという名前のアダプタ・サービスにより、レガシーのcustomerファイルがディレクトリから取得されます。
ReadCustアダプタ・サービスがファイル・データをCustomerRouter Oracle Mediatorに送信します。
CustomerRouter Oracle MediatorはXMLメッセージ・ペイロードにフィルタを適用し、メッセージをUSCustomer参照とCanadaCustomer参照のどちらにルーティングするか決定します。
次にCustomerRouter Oracle Mediatorはメッセージをアダプタ参照で必要となる構造に変換します。
外部参照はメッセージを関連する外部アプリケーションに配信します。
図19-37は、CustomerRouterユースケースの概要を示しています。
この項では、ユースケースの作成、構築およびデプロイの設計時タスクを説明します。
Oracle JDeveloperのアプリケーションおよびプロジェクトを作成する手順は、次のとおりです。
Oracle JDeveloperで「ファイル」をクリックし、「新規」を選択します。
「新規ギャラリ」ダイアログが表示されます。
「新規ギャラリ」で「一般」ノードを開き、「アプリケーション」カテゴリを選択します。
「項目」リストで「SOAアプリケーション」を選択し、「OK」をクリックします。
SOAアプリケーションの作成ウィザードが表示されます。
「アプリケーション名」フィールドにCustomerRouterと入力し、「次へ」をクリックします。
「プロジェクトの名前付け」ページが表示されます。
「プロジェクト名」フィールドにCustomerRouterProjectと入力し、「次へ」をクリックします。
SOA設定の構成ページが表示されます。
「コンポジット・テンプレート」リストから「空のコンポジット」を選択し、「終了」をクリックします。
Oracle JDeveloperの「アプリケーション・ナビゲータ」には新規のアプリケーションやプロジェクトが移入され、SOAコンポジット・エディタには空白のパレットがあります。
「ファイル」メニューから「すべて保存」を選択します。
CustomerRouter Oracle Mediatorサービス・コンポーネントを作成する手順は、次のとおりです。
「コンポーネント・パレット」から「SOA」を選択します。
「メディエータ」アイコンを「コンポーネント」セクションにドラッグ・アンド・ドロップします。
「メディエータの作成」ダイアログが表示されます。
「名前」フィールドに、CustomerRouterと入力します。
「テンプレート」リストから、「インタフェースを後で定義」を選択します。
「OK」をクリックします。
CustomerRouterという名前のOracle Mediatorが作成されます。
ディレクトリからXMLファイルを読み取るには、ReadCustという名前のファイル・アダプタ・サービスを作成する必要があります。
|
注意: Oracle Mediatorは、Oracle Real Application Clusters(Oracle RAC)の計画的停止に対して実行する際、同じファイルを2回処理する可能性があります。これは、ファイル・アダプタがXAに準拠していないアダプタであるためです。したがって、グローバル・トランザクションに組み入れると、各ファイルを1回のみ処理するXAインタフェース仕様に逸脱する可能性があります。 |
ファイル・アダプタ・サービスを作成する手順は、次のとおりです。
「コンポーネント・パレット」から「SOA」を選択します。
「ファイル・アダプタ」を選択し、「公開されたサービス」スイムレーンにドラッグします。
アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。
「サービス名」ページが表示されます。
「サービス名」フィールドに、ReadCustと入力します。
「次へ」をクリックします。
「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。
「操作」ページが表示されます。
「操作タイプ」フィールドで、「Read File」を選択します。
「操作名」フィールドで、ReadをReadFileに置換します。
「次へ」をクリックします。
「ファイル・ディレクトリ」ページが表示されます。
「着信ファイル用のディレクトリ(物理パス)」フィールドに、ファイルの読取り先のディレクトリを入力します。たとえば、C:\Customer\Inと入力します。
「次へ」をクリックします。
「ファイルのフィルタ処理」ページが表示されます。
「インクルード・ファイルの名前パターン」フィールドに*.xmlと入力し、「次へ」をクリックします。
「ファイル・ポーリング」ページが表示されます。
「ポーリング頻度」フィールドの値を10秒に変更し、「次へ」をクリックします。
「メッセージ」ページが表示されます。
「URL」フィールドの右側にある「検索」をクリックします。
「タイプ・チューザ」ダイアログが表示されます。
「スキーマ・ファイルのインポート」をクリックします。
「スキーマ・ファイルのインポート」ダイアログが表示されます。
「URL」フィールドの右側にある「検索」をクリックし、Samplesフォルダに存在するLegacyCustomer.xsdファイルを選択します。
「OK」をクリックします。
図19-38に示すように、「タイプ・エクスプローラ」→「インポートしたスキーマ」→「LegacyCustomer.xsd」の順にナビゲーション・ツリーを開き、「CustomerData」を選択します。
「OK」をクリックします。
図19-39に示すように、アダプタ構成ウィザードが表示されます。
「次へ」をクリックします。
「終了」ページが表示されます。
「終了」をクリックします。
「ファイル」メニューから「すべて保存」を選択します。
USCustomerファイル・アダプタ参照を作成します。
ファイル・アダプタ参照を作成する手順は、次のとおりです。
「コンポーネント・パレット」から「SOA」を選択します。
「ファイル・アダプタ」を選択し、「外部参照」スイムレーンにドラッグします。
アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。
「サービス名」ページが表示されます。
「サービス名」フィールドに、USCustomerと入力します。
「次へ」をクリックします。
「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。
「操作」ページが表示されます。
「次へ」をクリックします。
「操作」ページが表示されます。
「操作タイプ」フィールドで、「Write File」を選択します。
「操作名」フィールドにWriteFileと入力します。
「次へ」をクリックします。
「ファイル構成」ページが表示されます。
「発信ファイルのディレクトリ(物理パス)」フィールドに、ファイルを書き込むディレクトリの名前を入力します。
たとえば、C:\Customer\outと入力します。
ファイル・ネーミング規則フィールドにcustomer_%SEQ%.xmlと入力して、「次へ」をクリックします。
「メッセージ」ページが表示されます。
「URL」フィールドの右側にある「検索」をクリックします。
「タイプ・チューザ」ダイアログが表示されます。
「スキーマ・ファイルのインポート」をクリックします。
「スキーマ・ファイルのインポート」ダイアログが表示されます。
「URL」フィールドの右側にある「検索」をクリックし、Samplesフォルダに存在するUSCustomer.xsdファイルを選択します。
「OK」をクリックします。
「タイプ・エクスプローラ」→「インポートしたスキーマ」→「USCustomer.xsd」の順にナビゲーション・ツリーを開き、「Customer」を選択します。
「OK」をクリックします。
「次へ」をクリックします。
「終了」ページが表示されます。
「終了」をクリックします。
「ファイル」メニューから「すべて保存」をクリックします。
CanCustomer.xsdファイルを使用して、同様にCanadaCustomerという別のファイル・アダプタ参照を作成します。
図19-40は、このタスク終了後に、SOAコンポジット・エディタがどのように表示されるかを示しています。
図19-40 アダプタ・サービスと参照があるOracle Mediatorサービス・コンポーネント
メッセージが経由するReadCustアダプタ・サービスから外部参照へのパスを指定する必要があります。
ルーティング・ルールを指定する手順は、次のとおりです。
図19-41に示すように、ReadCustサービスをCustomerRouter Oracle Mediatorに接続します。
この操作により、ファイルを入力ディレクトリから読み込む間に、CustomerRouter Oracle Mediatorを起動するファイル・アダプタ・サービスが指定されます。
図19-41 ReadCustサービスからCustomerRouter Oracle Mediatorへの接続
メディエータ・エディタで、CustomerRouter Oracle Mediatorをダブルクリックします。
「ルーティング・ルール」セクションで、ReadFileの最も右側にある「追加」をクリックし、次に「静的ルーティング・ルール」をクリックします。
「ターゲット・タイプ」ダイアログが表示されます。
「サービス」をクリックします。
「ターゲット・サービス」ダイアログが表示されます。
図19-42に示すように、「CustomerRouterProject」→「参照」→「USCustomer」の順に移動し、「WriteFile」を選択します。
「OK」をクリックします。
「ルーティング・ルール」セクションが表示されます。
「<<フィルタ式>>」フィールドの横にある「フィルタ」アイコンをクリックして、このルーティング・ルールのフィルタ式を作成します。
「式ビルダー」ダイアログが表示されます。
「変数」フィールドで、「変数」→「in」→「body」→「imp1:CustomerData」の順に移動し、「Country」を選択します。
「Country」をダブルクリックします。
図19-43に示すように、「Country」ノードが「式」フィールドに追加されます。
式を次のように変更します。
$in.CustomerData/imp1:CustomerData/Country='US'
「OK」をクリックします。
「ルーティング・ルール」セクションの「<<フィルタ式>>」フィールドに式が移入されます。
「次を使用して変換」フィールドの右側にあるアイコンをクリックします。
図19-44に示すように、「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。
「新規マッパー・ファイルの作成」を選択し、「OK」をクリックします。
図19-45に示すように、「CustomerData_To_Customer.xsl」ファイルが追加されます。
図19-45 「CustomerData_To_Customer.xsl」ファイル – 初期状態
「imp1:CustomerData」ソース要素を「imp1:Customer」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。
「自動マップ中」オプションから、「祖先名を考慮した要素の一致」の選択を解除します。
図19-46に、「自動マップ・プリファレンス」ダイアログを示します。
「OK」をクリックします。
図19-47に示すように、「CustomerData_To_Customer.xsl」ファイルが表示されます。
図19-47 「CustomerData_To_Customer.xsl」タブ – 自動マップ接続
「ファイル」メニューから「すべて保存」を選択します。
ステップ3から17を繰り返し、ターゲット・サービスにCanadaCustomer参照を作成します。「式ビルダー」ダイアログで、次の式を指定します。
|
注意: 手順を繰り返すときは、メディエータ・エディタを閉じるか、またはエディタの上にあるCustomerRouter.mplanタブをクリックして、メディエータ・エディタを再度開く必要があります。 |
$in.CustomerData/imp1:CustomerData/Country='CA'
この項で説明した手順をすべて実行すると、図19-37に示すように、SOAコンポジット・エディタが表示されます。
SOAコンポジット・アプリケーションをデプロイするには、アプリケーション・サーバー接続が必要です。アプリケーション・サーバー接続の作成方法の詳細は、第40.7.1.1.1項「アプリケーション・サーバー接続の作成」を参照してください。
次の手順で、CustomerRouterProjectコンポジット・アプリケーションをアプリケーション・サーバーにデプロイします。
アプリケーション・デプロイメント・プロファイルの作成
アプリケーション・サーバーへのアプリケーション・デプロイメント・プロファイルのデプロイ
これらの手順の詳細は、第40.7.1項「Oracle JDeveloperでの単一のSOAコンポジットのデプロイ」を参照してください。
デプロイしたCustomerRouterProjectアプリケーションは、入力XMLファイルを入力フォルダにコピーすることで実行できます。ペイロード・ファイルは、指定した出力ディレクトリに書き込まれます。
実行中のインスタンスの監視には、次のURLにあるOracle Enterprise Manager Fusion Middleware Controlを使用できます。
http://hostname:port_number/em
ここで、hostnameは、Oracle SOA Suiteインフラストラクチャをインストールしたホストです。port_numberは、Oracle Enterprise Manager Fusion Middleware Controlがインストールされているサーバーのポートです。
これらの手順の詳細は、第40.7.1項「Oracle JDeveloperでの単一のSOAコンポジットのデプロイ」を参照してください。
このサンプルでは、Oracle Mediatorを使用した非同期リクエスト・レスポンスのシナリオを示します。サンプルのコンポジットにはOracle Mediatorを起動するクライアントBPELプロセスがあり、Oracle MediatorはサーバーBPELプロセスを起動します。起動はすべて非同期リクエスト・レスポンスとして行われます。
図19-48は、AsyncMediatorユースケースの概要を示しています。
この項で説明するサンプル・ファイルをダウンロードするには、次のURLを参照してください。
https://soasamples.samplecode.oracle.com
この項では、ユースケースの作成、構築およびデプロイの設計時タスクを説明します。これらのタスクは、表示されている順番で実行する必要があります。
Oracle JDeveloperのアプリケーションおよびプロジェクトを作成する手順は、次のとおりです。
Oracle JDeveloperで「ファイル」をクリックし、「新規」を選択します。
「新規ギャラリ」ダイアログが表示されます。
「新規ギャラリ」で「一般」ノードを開き、「アプリケーション」カテゴリを選択します。
「項目」リストで「SOAアプリケーション」を選択し、「OK」をクリックします。
SOAアプリケーションの作成ウィザードが表示されます。
「アプリケーション名」フィールドにAsyncMediatorと入力し、「次へ」をクリックします。
「プロジェクトの名前付け」ページが表示されます。
「プロジェクト名」フィールドにAsyncMediatorSampleと入力し、「次へ」をクリックします。
SOA設定の構成ページが表示されます。
「コンポジット・テンプレート」リストで「空のコンポジット」を選択し、「終了」をクリックします。
Oracle JDeveloperの「アプリケーション・ナビゲータ」には新規のアプリケーションやプロジェクトが移入され、SOAコンポジット・エディタには空白のパレットがあります。
「ファイル」メニューから「すべて保存」をクリックします。
サーバーBPELプロセスを作成する手順は、次のとおりです。
「アプリケーション・ナビゲータ」で、「composite.xml」をダブルクリックします。SOAコンポジット・エディタが表示されます。
「コンポーネント・パレット」から「SOA」を選択します。
「BPELプロセス」を「コンポーネント」セクションにドラッグ・アンド・ドロップします。
「BPELプロセスの作成」ダイアログが表示されます。
「名前」フィールドに、ServerBPELProcessと入力します。
「テンプレート」リストから、「非同期BPELプロセス」を選択します。
「SOAPサービスとして公開」の選択を解除して、「OK」をクリックします。SOAコンポジット・エディタにServerBPELProcessが作成されます。
Mediatorという名前のOracle Mediatorサービス・コンポーネントを作成する手順は、次のとおりです。
「コンポーネント・パレット」から「SOA」を選択します。
「メディエータ」を「コンポーネント」セクションにドラッグ・アンド・ドロップします。
「メディエータの作成」ダイアログが表示されます。
「名前」フィールドに、Mediatorと入力します。
「テンプレート」リストから、「非同期インタフェース」を選択します。
「SOAPバインディングを持つコンポジット・サービスの作成」の選択を解除します。
「OK」をクリックします。
図19-49に示すように、Mediatorという名前のOracle Mediatorが作成されます。
図19-49 コンポジット・ウィンドウ内のOracle MediatorとServerBPELProcess
「Mediator」Oracle Mediatorをダブルクリックします。
メディエータ・エディタが表示されます。
「ルーティング・ルール」セクションで、executeの最も右側にある「追加」をクリックし、次に「静的ルーティング・ルール」を選択します。
「ターゲット・タイプ」ダイアログが表示されます。
「サービス」を選択します。
「ターゲット・サービス」ダイアログが表示されます。
図19-50に示すように、「AsyncMediatorSample」→「BPELプロセス」→「ServerBPELProcess」→「サービス」→「serverbpelprocess_client」→「process」の順に移動します。
「OK」をクリックします。
「<<フィルタ式>>」フィールドの下の「次を使用して変換」フィールドの右側にあるアイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。
「新規マッパー・ファイルの作成」を選択し、「OK」をクリックします。
XSLTマッパーが表示され、singleString_To_process.xslというターゲット・ファイルが追加されます。
「cb1:input」ソース要素を「client:input」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。
「自動マップ中」オプションから、「祖先名を考慮した要素の一致」の選択を解除し、「OK」をクリックします。
図19-51に示すように、XSLTマッパーが表示されます。
「ルーティング・ルール」セクションで、「コールバック」にある「次を使用して変換」フィールドの右側にあるアイコンをクリックします。
「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。
「新規マッパー・ファイルの作成」を選択し、「OK」をクリックします。
XSLTマッパーが表示され、processResponse_To_singleString.xslというターゲット・ファイルが追加されます。
「client:processResponse」ソース要素を「cb1:singleString」ターゲット要素にドラッグ・アンド・ドロップします。
「自動マップ・プリファレンス」ダイアログが表示されます。
「自動マップ中」オプションから、「祖先名を考慮した要素の一致」の選択を解除し、「OK」をクリックします。
クライアントBPELプロセスを作成する手順は、次のとおりです。
「アプリケーション・ナビゲータ」で、「composite.xml」をダブルクリックします。SOAコンポジット・エディタが表示されます。
「コンポーネント・パレット」から「SOA」を選択します。
「BPELプロセス」を「コンポーネント」セクションにドラッグ・アンド・ドロップします。
「BPELプロセスの作成」ダイアログが表示されます。
「名前」フィールドに、ClientBPELProcessと入力します。
「テンプレート」リストから、「非同期BPELプロセス」を選択します。
「OK」をクリックします。
SOAコンポジット・エディタにClientBPELProcessが作成されます。
「ClientBPELProcess」BPELプロセスを「Mediator」Oracle Mediatorにドラッグ・アンド・ドロップします。SOAコンポジット・エディタは、図19-48に示すように表示されます。
invokeアクティビティを作成する手順は、次のとおりです。
「ClientBPELProcess」をダブルクリックします。Oracle BPELデザイナが表示されます。
「コンポーネント・パレット」から設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。
invokeアクティビティをダブルクリックします。「Invoke」ダイアログが表示されます。
「名前」フィールドに、InvokeMediatorと入力します。
「パートナ・リンク」フィールドの横の「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。
「操作 - execute」を選択して、「OK」をクリックします。
「Invoke」ダイアログで、「変数」フィールドの右側にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
「変数」フィールドにInvokeMediator_execute_InputVariable_1と入力し、「OK」をクリックします。「Invoke」ダイアログが表示されます。
「OK」をクリックします。Oracle BPELデザイナが表示されます。
receiveアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」から設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。
receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。
「名前」フィールドに、ReceiveFromMediatorと入力します。
「パートナ・リンク」フィールドの横の「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。
「操作 - callback」を選択して、「OK」をクリックします。
「Receive」ダイアログで、「変数」フィールドの右側にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。
「インスタンスの作成」を選択して、「OK」をクリックします。Oracle BPELデザイナが表示されます。
assignアクティビティを作成する手順は、次のとおりです。
「コンポーネント・パレット」からassignアクティビティをドラッグし、設計領域のReceiveFromMediatorアクティビティとInvokeMediatorアクティビティの間にドロップします。
assignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。
「名前」フィールドに、AssignRequestと入力します。
「コピー操作」タブをクリックします。「Assign」ダイアログが表示されます。
「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。
図19-52に示すように、トリガー・ファイル名とファイル変数の間にコピー操作を作成します。
「コピー操作の作成」ダイアログで「OK」をクリックします。
図19-53に示すように、「OK」をクリックしてOracle BPELデザイナに戻ります。
図19-53 Oracle JDeveloper - ClientBPELProcess.bpel
「ファイル」メニューから「すべて保存」を選択します。
assignアクティビティをServerBPELProcessで作成する手順は、次のとおりです。
「ServerBPELProcess」BPELプロセスをダブルクリックします。Oracle BPELデザイナが表示されます。
「コンポーネント・パレット」からassignアクティビティをドラッグし、設計領域のreceiveInputアクティビティとcallbackClientアクティビティの間にドロップします。
assignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。
「コピー操作」タブをクリックします。
「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。
図19-54に示すように、トリガー・ファイル名とファイル変数の間にコピー操作を作成します。
「コピー操作の作成」ダイアログで「OK」をクリックします。
図19-55に示すように、「OK」をクリックしてOracle BPELデザイナに戻ります。
図19-55 Oracle JDeveloper - ServerBPELProcess.bpel
「ファイル」メニューから「すべて保存」を選択します。
SOAコンポジット・アプリケーションをデプロイするには、アプリケーション・サーバー接続が必要です。アプリケーション・サーバー接続の作成方法の詳細は、第40.7.1.1.1項「アプリケーション・サーバー接続の作成」を参照してください。
次の手順で、EventMediatorAppコンポジット・アプリケーションをOracle WebLogic Serverにデプロイします。
アプリケーション・デプロイメント・プロファイルの作成
アプリケーション・サーバーへのアプリケーションのデプロイ
これらの手順の詳細は、第40.7.1項「Oracle JDeveloperでの単一のSOAコンポジットのデプロイ」を参照してください。
