19 メディエータ・ルーティング・ルールの作成

この章では、ルーティング・ルールの概要およびOracle Mediator（メディエータ）サービス・コンポーネントに対してルーティング・ルールを指定する方法を説明します。

項目は次のとおりです。

第19.1項「ルーティング・ルールの概要」
第19.2項「ルーティング・ルールの定義」
第19.3項「メッセージ・ルーティング用メディエータの作成」
第19.4項「メディエータを使用した非同期リクエスト・レスポンスの作成」

19.1 ルーティング・ルールの概要

Oracle Mediatorを使用すると、サービス・コンシューマとサービス・プロバイダの間でデータをルーティングできます。データはサービス間をフローするため、トランスフォーメーションが必要です。ルーティングとトランスフォーメーションの2つのタスクは、メディエータの中核となる処理内容です。ルーティング・ルールにより、メディエータで処理されたメッセージを次の宛先にどのように送信するかを指定できます。ルーティング・ルールは、メディエータによるメッセージの送信先、送信方法および変更内容を指定してから、ターゲット・サービスにメッセージを送信します。

ルーティング・ルールには、次の2つのタイプがあります。

静的ルーティング・ルール

静的に定義され、起動コンテキストによって変更されることのないメディエータ・ルーティング・ルールです。
動的ルーティング・ルール

Oracle Rules Dictionaryへのルーティング・ロジックの外部化を可能にするメディエータ・ルーティング・ルールです。Oracle Rules Dictionaryは、ルーティング・ルール内のルーティング・ロジックの動的変更を可能にします。

これらのルーティング・ルールの詳細は、第19.2.2項「静的ルーティング・ルールの作成」および第19.2.3項「動的ルーティング・ルールの作成」を参照してください。

19.2 ルーティング・ルールの定義

ルーティング・ルールは、インタフェースが定義されているメディエータにのみ定義できます。インタフェースの定義方法の詳細は、第18.3.1.2項「インタフェース定義を使用しないメディエータのインタフェースの定義方法」を参照してください。

この項の項目は、次のとおりです。

第19.2.1項「「ルーティング・ルール」パネルの使用」
第19.2.2項「静的ルーティング・ルールの作成」
第19.2.3項「動的ルーティング・ルールの作成」

19.2.1 「ルーティング・ルール」パネルの使用

ルーティング・ルールは、メディエータ・エディタの「ルーティング・ルール」パネルを使用して定義します。メディエータ・エディタには、次のいずれかの方法を使用してアクセスできます。

SOAコンポジット・エディタからアクセスする方法
1. ルーティング・ルールを指定するメディエータを示すアイコンをダブルクリックします。
2. 「ルーティング・ルール」パネルの横のプラス（+）アイコンをクリックします。
アプリケーション・ナビゲータからアクセスする方法
1. 「アプリケーション・ナビゲータ」からSOAプロジェクトを開き、次に「SOAコンテンツ」フォルダを開きます。
2. 「SOAコンテンツ」フォルダで、ルーティング・ルールを指定するメディエータの名前をダブルクリックします。メディエータ・ファイルには、mplan拡張子が付きます。
3. 「ルーティング・ルール」パネルの横のプラス（+）アイコンをクリックします。

図19-1に、「ルーティング・ルール」パネルが表示されたメディエータ・エディタを示します。

図19-1 メディエータ・エディタ - 「ルーティング・ルール」パネル

「図19-1 メディエータ・エディタ - 「ルーティング・ルール」パネル」の説明

図19-2に、「ルーティング・ルール」パネルのアイコンの要約を示します。

図19-2 「ルーティング・ルール」パネルのアイコン

「図19-2 「ルーティング・ルール」パネルのアイコン」の説明

19.2.2 静的ルーティング・ルールの作成

静的ルーティング・ルールを構成するときは、次の詳細を指定できます。

ターゲット・サービス

メッセージの送信先のサービスを指定します。ターゲット・サービスの起動方法の詳細は、第19.2.2.1項「メディエータ・サービスまたはイベントの指定」を参照してください。
実行タイプ

ルーティング・ルールの実行方法を指定します。順次またはパラレルのいずれかの実行タイプを指定します。

実行タイプの指定方法の詳細は、第19.2.2.2項「順次実行またはパラレル実行の指定」を参照してください。
リプライ、コールバックおよびフォルト・ハンドラ

同期リプライ、コールバックおよびフォルト・メッセージを処理する方法を指定します。同期リプライ、コールバックおよびフォルト・メッセージの処理方法の詳細は、第19.2.2.3項「レスポンス・メッセージの処理」と第19.2.2.5項「フォルト処理」を参照してください。
フィルタ式

適用するフィルタ式を指定します。フィルタ式では、サービスの呼出し前にメッセージのコンテンツ（ペイロードまたはヘッダー）が分析されるように指定します。たとえば、メッセージに顧客IDが含まれている場合、またはその顧客IDの値が特定のパターンと一致する場合のみサービスを起動することを指定する、フィルタ式を適用できます。フィルタ式の指定方法の詳細は、第19.2.2.6項「フィルタリング・メッセージの式の指定」を参照してください。
トランスフォーメーション

適用するトランスフォーメーションを指定します。トランスフォーメーションを使用してターゲット・ペイロードに値を設定できます。マッピングを使用するか値を割り当てて、トランスフォーメーションを実行します。

XSLTマッパーを使用すると、メッセージ本文全体に適用するトランスフォーメーションを定義し、XMLスキーマ間でメッセージを変換できます。一方、「Assign」ダイアログでは個々のフィールドを処理します。このダイアログを使用すると、メッセージ（ペイロード、ヘッダー）、定数または様々なシステム・プロパティ（データ・パスに存在するアダプタのプロパティなど）から値を割り当てることができます。トランスフォーメーションの作成方法の詳細は、第19.2.2.7項「トランスフォーメーションの作成」と第19.2.2.8項「値の割当て」を参照してください。
式にあるヘッダー変数へのアクセス

現在のルーティング・ルール操作用の式の作成に使用したSOAPヘッダーを検出します。フィルタとトランスフォーメーションのためのヘッダー・アクセス方法の詳細は、第19.2.2.9項「フィルタおよび割当てのためのヘッダー・アクセス」と第19.2.2.9.2項「フィルタおよび割当てのためのプロパティ・アクセスに使用する式の手動作成」を参照してください。
Schematronベースの検証

インバウンド・メッセージの異なるパートを検証するSchematronファイルを指定します。

Schematronをベースにした検証の実行方法の詳細は、第19.2.2.10項「セマンティク検証の使用」を参照してください。
Javaコールアウト

カスタムJavaクラス・コールアウトを起動します。 Javaコールアウトは、正規表現では十分でないときに、その正規表現をJavaコードと併用できるようにします。 Javaコールアウトの使用方法の詳細は、第19.2.2.11項「Javaコールアウトのサポート」を参照してください。
ユーザー定義拡張関数

XSLマッパーで使用可能な独自の関数セットです。ユーザー定義拡張関数の使用方法の詳細は、第19.2.2.6.1項「ユーザー定義拡張関数の使用」を参照してください。

次の各項では、サービスまたはイベント・サブスクリプションに対して定義できる様々なタイプの静的ルーティング・ルールについて説明します。

第19.2.2.1項「メディエータ・サービスまたはイベントの指定」
第19.2.2.2項「順次実行またはパラレル実行の指定」
第19.2.2.3項「レスポンス・メッセージの処理」
第19.2.2.4項「複数コールバックの処理」
第19.2.2.5項「フォルト処理」
第19.2.2.6項「フィルタリング・メッセージの式の指定」
第19.2.2.7項「トランスフォーメーションの作成」
第19.2.2.8項「値の割当て」
第19.2.2.9項「フィルタおよび割当てのためのヘッダー・アクセス」
第19.2.2.10項「セマンティク検証の使用」
第19.2.2.11項「Javaコールアウトのサポート」

19.2.2.1 メディエータ・サービスまたはイベントの指定

メディエータを作成した後は、そのメディエータをインバウンド・サービス操作またはイベント・サブスクリプションに関連付け、メディエータのターゲットを指定します。ターゲットは、アウトバウンド・サービス操作またはイベントの公開です。ターゲットはメディエータがメッセージを送信する次のサービスまたはイベントを指定し、起動するサービス操作を指定します。サービスまたはイベントをターゲット・タイプとして指定できます。

ソース・メッセージは、トランスフォーメーション、検証、割当てまたは順序操作の実行後に、初期のコール元にエコーして戻すこともできます。エコーが同期、非同期のいずれで行われるかは、コール元のWSDLファイルによって決まります。エコー・オプションは、インバウンド・サービス操作に対してのみ使用可能で、イベント・サブスクリプションには使用できません。

エコー・オプションの目的は、メディエータのすべての機能をコール可能なサービスとして公開することによって、他のサービスへのルーティングの必要性をなくすことです。たとえば、メディエータをコールしてトランスフォーメーション、検証または割当てを実行した後、別の場所にルーティングすることなくアプリケーションにメディエータをエコーして戻すことができます。

1つのインバウンド操作またはイベントに複数のルーティングを指定できます。各ルーティングは、1つのターゲット・サービス起動またはイベントにマップされます。したがって、特定のターゲット・サービスに対して複数のサービス起動を指定したり、複数イベントを発生させるには、各ターゲットに1つのルーティング・ルールを指定する必要があります。たとえば、メッセージ・ペイロードに基づいて、サービスに定義された次の操作から、ある操作を起動するとします。

insert
update
updateid
delete

各操作に1つずつ、4つのルーティングを作成する必要があります。その後、フィルタ式を指定する場合は、図19-3に示すように、メッセージ・ペイロードに基づいて各メッセージ・インスタンスに適用するターゲットおよび操作を指定できます。

図19-3 インバウンド操作に対する複数のルーティング

「図19-3 インバウンド操作に対する複数のルーティング」の説明

サービスを起動する手順は、次のとおりです。

「ルーティング・ルール」パネルで、「追加」をクリックします。

図19-4に示すように、「ターゲット・タイプ」ダイアログが表示されます。

図19-4 「ターゲット・タイプ」ダイアログ

「図19-4 「ターゲット・タイプ」ダイアログ」の説明
「サービス」をクリックします。
「ターゲット・サービス」ダイアログで、図19-5に示すように、サービスが提供する操作に移動し、選択します。

図19-5 「ターゲット・サービス」ダイアログ

「図19-5 「ターゲット・サービス」ダイアログ」の説明

注意:
図19-5に示すように、サービスは複数の操作で構成できます。
「OK」をクリックします。

イベントを発生させる手順は、次のとおりです。

「ルーティング・ルール」パネルで、「追加」をクリックします。

図19-6に示すように、「ターゲット・タイプ」ダイアログが表示されます。
「イベント」をクリックします。

「イベント・チューザ」ダイアログが表示されます。
「イベント定義」フィールドの右側にある「検索」をクリックします。

SCAリソース・ブラウザ・ダイアログが表示されます。
イベント・ファイルを1つ選択して、「OK」をクリックします。

図19-6に示すように、選択したファイルに定義されているイベントが「イベント」フィールドに移入されます。

図19-6 「イベント・チューザ」ダイアログ

「図19-6 「イベント・チューザ」ダイアログ」の説明
イベントを選択します。
「OK」をクリックします。

サービスをエコーする手順は、次のとおりです。

「ルーティング・ルール」パネルで、「追加」をクリックします。

次の図に示すように、「ターゲット・タイプ」ダイアログが表示されます。

図19-7 「ターゲット・タイプ」ダイアログ

「図19-7 「ターゲット・タイプ」ダイアログ」の説明
「エコー」をクリックします。

次の図に、同期エコーのルーティング・ルールを示します。

注意:
非同期エコーの場合は、戻りのアイコンが点線になります。

図19-8 エコー操作をサポートするメディエータのサンプル

「図19-8 エコー操作をサポートするメディエータのサンプル」の説明

エコー・オプション使用上の制限

エコー・オプションには次の制限があります。

エコー・オプションは、メディエータのインタフェースが、次のタイプのWSDLファイルの場合のみサポートされます。

リクエスト/リプライ
リクエスト/リプライ/フォルト
リクエスト/コールバック

注意:

エコー・オプションは、メディエータ・インタフェースがリクエスト/リプライ/フォルト/コールバックのWSDLファイルの場合には使用できません。

エコー・オプションは、リクエスト/リプライおよびリクエスト/リプライ/フォルトのような同期操作で使用できます。

注意:

エコー・オプションを同期操作で使用できるのは、ルーティング・ルールが順次実行の場合のみです。これは、同期操作のメディエータでは、パラレルのルーティング・ルールはサポートされないためです。

条件フィルタを設定している同期操作の場合は、フィルタ条件をfalseに設定していると、エコー・オプションではレスポンスがコール元に返されません。かわりに、nullレスポンスがコール元に返されます。

エコー・オプションを非同期操作で使用できるのは、メディエータ・インタフェースにコールバック操作が指定されている場合のみです。この場合、エコーは別のスレッドで実行されます。

注意:

非同期のエコー・オプションを使用できるのは、ルーティング・ルールがパラレル実行の場合のみです。エコー・オプションを使用するために、非同期操作のメディエータでは、順次実行のルーティング・ルールはサポートされません。

19.2.2.2 順次実行またはパラレル実行の指定

ルーティング・ルールの実行タイプを指定できます。ルーティング・ルール実行タイプには、パラレルまたは順次を指定できます。ルーティング・ルールの実行タイプを指定するには、「ルーティング・ルール」パネルから「順次」または「パラレル」の実行タイプを選択します。

この項では、次の項目について説明します。

順次ルーティング・ルールの基本原則
パラレルのルーティング・ルールの基本原則

順次ルーティング・ルールの基本原則

順次実行では、ルーティングが評価され、アクションが順に実行されます。順次ルーティングは、コール元と同じスレッドとトランザクションで評価されます。
メディエータは常に、受信メッセージを処理しているスレッドを介して伝播されたグローバル・トランザクションにメディエータ自体を登録します。たとえば、インバウンドJCAアダプタがメディエータを起動すると、そのメディエータは、JCAアダプタが開始したトランザクションにメディエータ自体を登録します。
メディエータは、順次ルーティング・ルールの実行中に、ターゲット・コンポーネントと同じスレッドを介してトランザクションを伝播します。
外部エンティティによって伝播されたトランザクションを、メディエータがコミットまたはロールバックすることはありません。
メディエータがトランザクションを管理するのは、スレッド起動メディエータにアクティブなトランザクションが存在していない場合のみです。たとえば、メディエータがインバウンドSOAPサービスから起動された場合、そのメディエータはトランザクションを開始し、成功および失敗に応じてトランザクションをコミットまたはロールバックします。

パラレルのルーティング・ルールの基本原則

パラレル実行では、ルーティングはキューに入れられ別々のスレッドでパラレルに評価されます。

各パラレル・ルールを処理するために、メディエータによって新規トランザクションが開始されます。開始されたトランザクションは、パラレル・メッセージ・デハイドレーション・ストアへのメディエータのエンキューで終了します。

たとえば、メディエータ・コンポーネントにパラレルのルーティング・ルールが1つある場合は、1つのメッセージがメディエータのパラレル・メッセージ・デハイドレーション・ストアにエンキューされます。次に、ストアに対するパラレル・メッセージ・ディスパッチャがトランザクションを開始し、データベース・ストアからメッセージを読み取り、このルーティング・ルールのターゲット・コンポーネントまたはサービスを起動します。リスナー・スレッドによって開始されるこのトランザクションは、完全に新規のトランザクションであり、ターゲット・コンポーネントに伝播されます。

注意:

メッセージのデハイドレーションは、後でワーカー・スレッドで処理できるように、受信メッセージをパラレルのルーティング・ルール用のデータベースに格納することを意味します。

パラレル実行では、メディエータはトランザクションの開始元であるため、これらのトランザクションをコミットまたはロールバックします。

操作またはイベントに順次およびパラレルの両方のルーティング・ルールがある場合は、最初に順次ルーティング・ルールが評価されてアクションが実行され、次にパラレルのルーティングがパラレル実行のためにキューに入れられます。

注意:

メディエータでは、同期インタフェースを使用するメディエータに対するルーティング・ルールのパラレル実行はサポートされていません。

19.2.2.3 レスポンス・メッセージの処理

レスポンス・メッセージを同期および非同期の相互作用内で処理する方法を指定できます。同期相互作用の場合は、レスポンスとフォルト・メッセージのトランスフォーメーションと割当てを指定できます。レスポンスとフォルト・メッセージを別のサービスまたはイベントに転送できます。あるいは、初期のコール元にレスポンスおよびフォルトを受信する用意がある場合は、それらを初期のコール元に戻すことができます。

非同期相互作用の場合は、レスポンスを受信するまでのタイムアウト時間を指定できます。タイムアウト時間は、秒、時、日、月または年で指定できます。タイムアウト時間のデフォルト値は無限です。コールバック・レスポンスが指定したタイムアウト時間内に返されない場合、タイムアウトしたレスポンスは別のサービス、イベントに転送されるか、初期のコール元に戻されます。

メディエータのレスポンスを双方向サービスにルーティングすることはできません。レスポンスを双方向サービスにルーティングする場合は、最初のメディエータと双方向サービスの間に一方向のメディエータを使用する必要があります。レスポンスを最初に一方向のメディエータに転送し、その一方向のメディエータが双方向サービスをコールする必要があります。

注意:

0（ゼロ）のタイムアウト時間指定はサポートされていません。
コールバックは受信したが、コールバックの処理に失敗した場合は、タイムアウト・ハンドラに指定されているアクションを処理するために、タイムアウト・ハンドラがデフォルトで起動されます。
通常、コール元は、100ミリ秒待機した後でコールバックを受信します。しかし、順次ルーティング・ルールと同期インタフェース・サービスへの接続を使用するブリッジ・メディエータがある場合は、ルーティング・ルールがすべて順次であるプログラムのフローが複雑となるため、コール元でのコールバックの受信準備にさらに時間がかかる場合があります。この問題は、ブリッジ・メディエータのルーティング・ルールをパラレルに変更することで回避できます。

タイムアウト時間の指定

タイムアウト時間を指定する手順は、次のとおりです。

「コールバック」セクションの「<<ターゲット操作>>」フィールドにある「ターゲット・サービス操作を参照します。」アイコンをクリックします。

「ターゲット・タイプ」ダイアログが表示されます。
「サービス」または「イベント」を選択します。

選択した内容によって「ターゲット・サービス」ダイアログまたは「イベント・チューザ」ダイアログが表示されます。
サービスまたはイベントを選択します。
「OK」をクリックします。

タイムアウトしたレスポンスが、指定したサービスまたはイベントに転送されます。

注意:

ルーティング・ルールの数が多く、ルーティング・ルールの実行に要する時間がトランザクション・タイムアウトを超える場合は、トランザクション・タイムアウトの値を、すべてのルーティング・ルールの実行に要する時間より長い時間に設定する必要があります。

19.2.2.4 複数コールバックの処理

1つのメディエータで複数のコールバックを処理することはできません。複数のコールバックを受信するメディエータが含まれているコンポジット・アプリケーションがある場合、そのコンポジット・アプリケーションの動作は不明です。たとえば、図19-9に示したシナリオについて考えてみます。このシナリオでは、AsyncMediatorがAsyncEchoMediator1およびAsyncEchoMediator2からのコールバック・レスポンスをFileInMediatorに転送します。このようなフローでは、AsyncMediatorは、AsyncEchoMediator1とAsyncEchoMediator2の両方からのコールバックを返すか、またはいずれか一方のコールバックを返す可能性があります。正確な動作は確率的であり、予測できません。

図19-9 複数のコールバックを処理するメディエータのサンプル

「図19-9 複数のコールバックを処理するメディエータのサンプル」の説明

19.2.2.5 フォルト処理

ターゲット・サービスのWSDL操作に1つ以上のフォルトがある新規ルーティング・ルールを作成する場合でも、メディエータ・エディタ・ウィンドウには、単一フォルトのルーティング・セクションが表示されます。ソース・メディエータ・サービスが1つ以上のフォルトをサポートする場合、デフォルトでは、フォルトはコール元に戻されます。ただし、ソース・フォルト名およびターゲット・フォルト名をルーティングすることを指定できます。サービス・ブラウザを使用して、フォルトを別のターゲットにルーティングすることもできます。

別のフォルトをルーティングするには、次の図に示すように、「別のフォルト・ルーティングを追加します。」ボタンをクリックします。

図19-10 2番目のフォルトの追加

「図19-10 2番目のフォルトの追加」の説明

この結果、別のフォルト・セクションがルーティング・ルールに追加されます。次の図では、2番目のフォルトはファイル・アダプタ・サービスにルーティングされています。

図19-11 2番目のフォルトの追加

「図19-11 2番目のフォルトの追加」の説明

注意:

異なるトランスフォーメーションを使用して、同一のフォルトを多数の異なるターゲットにルーティングすることが可能です。

フォルト・ルーティングのターゲットを選択しているときに、フォルト・ルーティング・セクションを削除する場合は、図19-12に示すように、「選択したフォルト・ルーティングを削除します。」をクリックします。

図19-12 フォルト・ルーティングの削除

「図19-12 フォルト・ルーティングの削除」の説明

別の方法として、次の図に示すように、「ターゲット・タイプ」ダイアログで「ターゲットのクリア」をクリックします。

図19-13 「ターゲット・タイプ」ダイアログ

「図19-13 「ターゲット・タイプ」ダイアログ」の説明

19.2.2.6 フィルタリング・メッセージの式の指定

フィルタ式ルーティング・ルールを使用すると、ペイロードに基づいてメッセージをフィルタリングできます。特定のメッセージ・インスタンスに対してフィルタ式がtrueに評価されると、そのメッセージはルーティング・ルールに指定されているターゲット・サービスまたはイベントに送信されます。

たとえば、アメリカとカナダの異なる2国にいる顧客にデータをルーティングするとします。ただし、アメリカの顧客には、携帯型の製品系列に関する通知のみを、カナダの顧客には固定電話型の製品系列の通知のみを送信します。このルーティングのためには、メッセージをターゲット顧客に送信するコンポーネントと操作の各組合せについてルーティング・ルールを定義する必要があります。さらに、アメリカまたはカナダの顧客にメッセージを送信するルーティング・ルールには、フィルタ式を指定します。

フィルタ式のメッセージ・プロパティまたはメッセージ・ヘッダーを定義することもできます。

フィルタ式のメッセージ・プロパティ

次の2つは、フィルタ式のメッセージ・プロパティの例です。

$in.property.custom.Priority = '1'

$in.property.tracking.ecid = '2'

フィルタ式のメッセージ・ヘッダー

次の2つは、フィルタ式のメッセージ・ヘッダーの例です。

$in.header.wsse_Security/wsse:Security/Priority = '234'

$in.header.wsse_Security/wsse:Security/Priority = '234'

このフィルタ式のメッセージ・ヘッダーが機能するには、.mplanファイルのルート要素に次の属性を追加する必要があります。

wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

図19-14に示すように、フィルタ式は、「式ビルダー」ダイアログを使用して指定できます。「式ビルダー」ダイアログは、「ルーティング・ルール」パネルの「フィルタ式」フィールドの右側にあるアイコンをクリックすると表示されます。

図19-14 「式ビルダー」ダイアログ

「図19-14 「式ビルダー」ダイアログ」の説明

「式ビルダー」ダイアログには、フィルタ式の設計を支援するコンポーネントやコントロールが含まれています。つまり、「式」フィールドに値を追加するには、「変数」フィールドまたは「関数」パレットで、必要な値をダブルクリックします。変数要素、関数および手動で入力したテキストの組合せを使用して、このウィンドウで、特定のルーティング・ルールに対してメッセージ・ペイロードをフィルタリングする式を作成できます。

次に、「式ビルダー」ダイアログの各フィールドについて説明します。

「式」フィールド

フィルタ式を入力できます（手動、または「変数」フィールドおよびこのフィールド内の「関数」パレットを使用）。

このフィールドの右上部に表示されている各アイコンを使用すると、最後に行った編集の取消し、最後に行った編集の再実行、または「式」フィールド全体の消去を実行できます。
「変数」フィールド

このフィールドには、メディエータに対して定義されたメッセージが含まれます。 Oracle JDeveloperはメディエータのWSDLファイルを解析し、メッセージ定義を「変数」フィールドに表示します。入力メッセージは$in変数の中に格納されます。$in.propertiesを使用して、入力メッセージのプロパティにアクセスできます。

入力メッセージが複数のパートで構成されている場合は、図19-15に示すように、$in.<partname>を使用して、入力メッセージのパートにアクセスできます。

図19-15 「式ビルダー」内の複数パート・メッセージ

「図19-15 「式ビルダー」内の複数パート・メッセージ」の説明
「関数」パレット

このリストを使用すると、様々な関数を選択して式に挿入できます。関数を選択すると、その関数が「式」フィールドに追加されたときにどのように表示されるかを示すプレビューが「コンテンツのプレビュー」フィールドに表示され、その関数の説明が「説明」フィールドに表示されます。
コンテンツのプレビュー

このフィールドには、「変数」フィールドまたは「関数」パレットで選択した値が「式」フィールドに挿入されたときの表示状態で示されます。
説明

このフィールドには、「変数」フィールドまたは「関数」パレットで選択した値の説明が表示されます。

メッセージ・ペイロードのフィルタ式を指定する手順は、次のとおりです。

「ルーティング・ルール」パネルで、フィルタ式の追加アイコン（図19-2を参照）をクリックします。

「式ビルダー」ダイアログが表示されます。
「変数」フィールドで、メッセージ定義を開き、式の基礎を形成するメッセージ要素を選択します。たとえば、図19-16では、CustomerID要素が選択された状態が示されています。

図19-16 「式ビルダー」ダイアログ – 変数要素の選択

「図19-16 「式ビルダー」ダイアログ – 変数要素の選択」の説明
「式に挿入」をクリックします。

図19-17に示すように、式が「式」フィールドに追加されます。

図19-17 「式ビルダー」ダイアログ – 変数要素の挿入

「図19-17 「式ビルダー」ダイアログ – 変数要素の挿入」の説明
「関数」リストから、メッセージ・ペイロードに適用する関数を選択します。たとえば、equalsを選択します。

関数は、「関数」リストの下矢印をクリックすると表示されるカテゴリ別にリストされます。たとえば、下矢印をクリックして「Logical Functions」を選択すると、図19-17に示すようにリストが表示されます。「Logical Functions」リストで関数を選択すると、その関数の説明が「説明」ボックスに表示されます。
「式に挿入」をクリックします。

選択した関数のXPath式が「式」フィールドに挿入されます。
式を完成します。この例では、図19-18に示すように、値1001を入力します。

図19-18 サンプルの「式ビルダー」ダイアログ – 値の入力後

「図19-18 サンプルの「式ビルダー」ダイアログ – 値の入力後」の説明
式は手動で編集するか、式の編集アイコンを使用できます。図19-19には、これらのアイコンがまとめられています。

図19-19 式の編集アイコン

「図19-19 式の編集アイコン」の説明
「OK」をクリックします。

式が「ルーティング・ルール」パネルに追加されます。

フィルタ式の変更または削除は、フィルタ式の追加アイコンをダブルクリックし、「式ビルダー」の「式」フィールドで実行します。

19.2.2.6.1 ユーザー定義拡張関数の使用

式ビルダーを使用すると、ユーザー定義拡張関数を使用できます。ユーザー定義拡張関数を使用する手順は、次のとおりです。

XPath関数を作成します。
Jaxen XPath関数を、サーバー側のxpath-function.xmlファイルのメディエータ・コンポーネントに登録します。
JDeveloperを開きます。
式ビルダーで式をカスタマイズします。
JDeveloperプロジェクトをWLSにデプロイします。
ユーザー定義拡張関数を格納したJARファイルをbeahome/user_projects/domains/soainfra/autodeploy/soa-infra/APP-INF/libディレクトリにコピーします。
プロジェクトの.mplanファイルを、次のように変更します。
- 拡張関数用に定義した関数ネームスペースをMediator要素の下に追加します。
- 関数名をExpression要素に追加します。
図19-20に、この変更操作を示します。

図19-20 プロジェクトの.mplanファイル – ユーザー定義拡張関数を使用するように変更済

「図19-20 プロジェクトの.mplanファイル – ユーザー定義拡張関数を使用するように変更済」の説明
適切なペイロードでテスト・ページを起動します。

19.2.2.7 トランスフォーメーションの作成

Oracle JDeveloperには、XSLTデータ・マッパー・ツールが用意されています。このツールを使用すると、データをXMLスキーマ（XSDファイルで表されます）間で変換するためのマッパー・ファイル（XSLファイル）を指定できます。このツールを使用することで、異なるスキーマを使用するアプリケーション間でのデータ交換が可能になります。たとえば、受信したソース注文書スキーマを、送信する請求書スキーマにマップできます。XSLファイルを定義した後は、そのファイルを複数のルーティング・ルール仕様で再利用できます。

「ルーティング・ルール」パネルの「次を使用して変換」フィールドの右側にあるトランスフォーメーション・マップ・アイコンをクリックすると、「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。このダイアログで、既存のXSLファイルを選択するか、またはデータ・マッパー・ツールを使用して必要なトランスフォーメーションを実行する新規XSLファイルを作成します。

また、同期リプライ、コールバック・レスポンス・メッセージまたはフォルト・メッセージのトランスフォーメーションを指定できます。同期リプライまたはフォルト・メッセージの場合、「リプライ・トランスフォーメーション・マップ」ダイアログまたは「フォルト・トランスフォーメーション・マップ」ダイアログには、「リクエストをリプライ・ペイロードに含める」オプションがあります。図19-21に、このオプションが表示された「リプライ・トランスフォーメーション・マップ」ダイアログを示します。

図19-21 「リプライ・トランスフォーメーション・マップ」ダイアログ

「図19-21 「リプライ・トランスフォーメーション・マップ」ダイアログ」の説明

このオプションを選択すると、図19-22に示すように、同期相互作用の元のメッセージを含む$initial変数が作成されます。

図19-22 XSLファイルの初期変数

「図19-22 XSLファイルの初期変数」の説明

初期メッセージも複数のパートで構成されます。$initial.<partname>を使用して、初期メッセージのパートにアクセスできます。

注意:

インバウンド・メッセージとアウトバウンド・メッセージのパートが同じ場合、データ交換にトランスフォーメーションは必要ありません。

データ・マッパー・ツールの詳細は、第45章「XSLTマッパーを使用したトランスフォーメーションの作成」を参照してください。

19.2.2.8 値の割当て

ターゲット・メッセージのプロパティは、「値の割当て」フィールドを使用して指定できます。図19-23に、「値の割当て」ダイアログを示します。このダイアログは、「ルーティング・ルール」パネルの「値の割当て」アイコンをクリックすると表示されます。

図19-23 「値の割当て」ダイアログ

「図19-23 「値の割当て」ダイアログ」の説明

ターゲット・メッセージのプロパティを設定する手順は、次のとおりです。

「値の割当て」ダイアログの「追加」をクリックします。

図19-24に示すように、「値の割当て」ダイアログが表示されます。

図19-24 「値の割当て」ダイアログ

「図19-24 「値の割当て」ダイアログ」の説明
「From」セクションで、「タイプ」ボックスから次のオプションのいずれかを選択します。
- プロパティ: ターゲット・メッセージにプロパティの値を割り当てる場合に選択します。「プロパティ」リストには、事前に定義されたプロパティのリストが表示されます。任意のユーザー定義プロパティ名を入力することもできます。
- 式: ターゲット・メッセージに式の値を割り当てる場合に選択します。「式」フィールドの右側にある「式ビルダーの起動」アイコンをクリックすると、図19-14に示すような「式ビルダー」ダイアログが表示されます。
  
  「式ビルダー」ダイアログの詳細は、第19.2.2.6項「フィルタリング・メッセージの式の指定」を参照してください。
- 定数: ターゲット・メッセージに定数値を割り当てる場合に選択します。
「To」セクションで、次のオプションのいずれかを選択します。
- プロパティ: メッセージ・プロパティに値をコピーする場合に選択します。「式ビルダー」ダイアログの「変数」フィールドには、出力メッセージを格納する$out変数が表示されます。$out.propertiesを使用すると、出力メッセージのプロパティにアクセスできます。
- 式: 式に値をコピーする場合に選択します。「式」フィールドの右側にある「式ビルダーの起動」アイコンをクリックすると、「式ビルダー」ダイアログが表示されます。「式ビルダー」ダイアログの「変数」フィールドには、出力メッセージを格納する$out変数が表示されます。 $out.<partname>を使用すると、出力メッセージ全体または出力メッセージのパートにアクセスできます。 <partname>の後に値を割り当てることはできません。たとえば、図19-25では、式は$out.requestであり、この式を変更してrequestの後に値を追加することはできません。
図19-25に、定数値が式として指定されている、サンプルの「値の割当て」ダイアログを示します。

図19-25 移入後の「値の割当て」ダイアログ

「図19-25 移入後の「値の割当て」ダイアログ」の説明
「値の割当て」ダイアログの「OK」をクリックします。
「OK」をクリックします。「ルーティング・ルール」パネルの「値の割当て」フィールドに式が追加されます。

注意:

イベントの公開時に特定のメディエータ・プロパティに値を割り当てた場合、その値はイベントのサブスクライブに伝播されません。

この問題を回避するには、トランスフォーメーションを使用して、イベント本体の一部としてプロパティを指定します。
WebLogic Serverのjca.db.userNameおよびjca.db.passwordプロパティに値を割り当てることはできません。これは、これらのデータ・ソースでは、getConnectionメソッドへのユーザー名またはパスワードの動的な設定がサポートされていないためです。
デフォルトでは、SOAPヘッダーはメディエータを介して渡されません。 passThroughHeaderエンドポイント・プロパティを、対応するメディエータ・ルーティング・サービスに追加する必要があります。このプロパティを追加するには、Composite.xmlファイルを次のように変更します。
```
<component name="Mediator1">
     <implementation.mediator src="Mediator1.mplan"/>
     <property name="passThroughHeader">true</property>
</component>
```

19.2.2.9 フィルタおよび割当てのためのヘッダー・アクセス

フィルタを定義するため、または割当てソースや割当てターゲットを定義するためにメディエータから式ビルダーを起動すると、WSDLファイルが解析されます。その際に、図19-26に示すように、現在のルーティング・ルール操作のSOAPヘッダーが自動的に検出され、このSOAPヘッダーが変数として、inフォルダまたはoutフォルダにheader./ns_elementName/のように表示されます。ここで、nsはネームスペース接頭辞、elementNameはヘッダー・スキーマのルート要素名です。

次に例を示します。

例1

ネームスペース接頭辞wsseおよびns1がWSDLファイルまたは.mplanファイルにすでに定義されている場合、XPath式は次のように記述できます。

$in.header.wsse_Security/wsse:Security/ns1:Foo/Priority

例2

WSDLファイルにネームスペースが事前定義されていないスキーマを使用する場合、式ビルダーでは、接頭辞のかわりに{full_namespace}を入力できる機能が提供されます。さらに、式ビルダーによって一意の接頭辞が生成され、接頭辞の定義が.mplanファイルに追加されます。

たとえば、式ビルダーに次の式を入力するとします。

$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ファイルには、次の定義が含まれます。


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"

図19-26 「式ビルダー」ダイアログ - 自動ヘッダー検出

「図19-26 「式ビルダー」ダイアログ - 自動ヘッダー検出」の説明

デフォルトでは、SOAPヘッダーはメディエータを介して渡されません。次のエンドポイント・プロパティを、対応するメディエータ・ルーティング・サービスに追加する必要があります。

<property name="passThroughHeader">true</property>

たとえば、このプロパティを追加するには、Composite.xmlファイルを次のように変更できます。

<component name="Mediator1">
     <implementation.mediator src="Mediator1.mplan"/>
     <property name="passThroughHeader">true</property>
</component>

注意:

このUIはSOAP 1.1およびSOAP 1.2の両方をサポートします。
自動ヘッダー検出のためには、メディエータ・コンポーネントの作成時に具体的なWSDLファイルを使用する必要があります。
割当てはフィルタの後に実行されます。このため、カスタム・ヘッダーで値を割り当てている場合、特定の割当てはフィルタに対して表示されません。

19.2.2.9.1 フィルタおよび割当てのためのヘッダー・アクセスに使用する式の手動作成

ユースケースによっては、WSDLファイルからヘッダー・スキーマを識別できない場合があります。たとえば、メッセージに付加されたセキュリティ・ヘッダーや、抽象的なWSDLファイルを使用して作成されたメディエータのヘッダーなどです。そのようなヘッダーにアクセスするには、式ビルダーにXPathを手動で入力する必要があります。

ヘッダー式の構文は、次のとおりです。

$in.header.<header root element namespace prefix>_<header root element name>/<xpath>

次のヘッダーがあるとします。

<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'

割当て式は次のようになります。

<copy target="$out.property.jca.jms.priority"
 expression="$in.header.wsse_Security/wsse:Security/Priority"/>

これらの式が機能するには、.mplanファイルのルート要素に次の属性を追加する必要があります。

wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

19.2.2.9.2 フィルタおよび割当てのためのプロパティ・アクセスに使用する式の手動作成

フィルタ式の例は、次のとおりです。

$in.property.tracking.ecid = '2'

割当て式の例は、次のとおりです。

<copy target="$out.property.tracking.ecid"  value="$in.property.tracking.ecid"/>

19.2.2.10 セマンティク検証の使用

インバウンド・メッセージとその様々なパートは、Schematronファイルを指定して検証できます。 Schematronバージョン1.5がサポートされているバージョンです。

Schematronスキーマを指定して、インバウンド・メッセージとその様々なパートを検証する手順は、次のとおりです。

「セマンティックの検証」フィールドの右側にある検証ファイルの選択アイコンをクリックします。

「検証」ダイアログが表示されます。
「追加」をクリックします。

「検証の追加」ダイアログが表示されます。
「パート」リストから、メッセージ・パートを選択します。
「ファイル」フィールドの右側にある「検索」をクリックします。

SCAリソース・ブラウザ・ダイアログが表示されます。

Schematronファイルを選択し、「OK」をクリックします。

注意:

通常、Schematronファイルの拡張子は.schです。
選択したSchematronファイルが空の場合、エラー・メッセージまたは警告は表示されません。

図19-27に示すように、「検証の追加」ダイアログが更新されます。

図19-27 「検証の追加」ダイアログ

「図19-27 「検証の追加」ダイアログ」の説明

「OK」をクリックします。

図19-28に示すように、「検証」ダイアログが更新されます。

図19-28 「検証」ダイアログ

「図19-28 「検証」ダイアログ」の説明

「追加」をクリックして別のメッセージ・パートのSchematronファイルを指定するか、「OK」をクリックします。

Schematronスキーマの作成方法の詳細は、次の場所から入手できるリソースを参照してください。

http://www.schematron.com

注意:

セマンティク検証では、各要素名の長さをチェックした場合、異なる入力セットに対して要素名が変わる場合があります。これは、パーサーが空白をテスト・ノードとして処理するため、ノード間に空白がある場合に発生します。

19.2.2.11 Javaコールアウトのサポート

Javaコールアウトを使用すると、メディエータを介してフローするメッセージの操作に外部のJavaクラスを使用できます。 WSDL操作またはイベント・サブスクリプションごとに、Javaコールアウトは1つのみサポートされます。コールアウト・クラスは、oracle.tip.mediator.common.api.IjavaCalloutインタフェースを実装する必要があります。コールアウトは、静的ルーティングおよび動的ルーティングの両方に使用できます。図19-29に、2つの操作が指定されたメディエータのサンプルを示します。2つの操作には、それぞれルーティング・ルールが1つあり、最初の操作にはコールアウト・クラスが指定されています。

図19-29 Javaコールアウトをサポートするメディエータのサンプル

「図19-29 Javaコールアウトをサポートするメディエータのサンプル」の説明

サーバーでJavaコールアウト・クラスが使用できることが必要です。このためには、次のいずれかの方法を使用します。

JavaクラスをSCA-INF/classesフォルダにコピーします。
Javaクラスが含まれているJARをSCA-INF/libフォルダにコピーします。
Javaクラスが含まれているJARを$DOMAIN_HOME/libフォルダにコピーします。

Javaコールアウト・クラスを複数のメディエータで使用できるようにするには、Javaクラスが含まれているJARを$DOMAIN_HOME/libフォルダにコピーする必要があります。

図19-30に示すように、「コールアウト先」フィールドには、Javaコールアウト・クラスの名前を手動で入力できます。この場合は、JDeveloperのオートコンプリート機能によって、完全なアドレスが、現在のプロジェクトにあるクラスに基づいて自動的に表示されます。

図19-30 「コールアウト先」フィールド

「図19-30 「コールアウト先」フィールド」の説明

図19-31に示すように、「Javaコールアウト・クラスを選択します。」ボタンをクリックして、標準のJDeveloperクラス・ブラウザを起動することもできます。

図19-31 JDeveloperクラス・ブラウザ

「図19-31 JDeveloperクラス・ブラウザ」の説明

クラス・ブラウザは、oracle.tip.mediator.common.api.IjavaCalloutインタフェースを実装するクラスのみが表示されるようにフィルタリングされます。

メディエータにJavaコールアウトがあり、同じメディエータでフィルタ式を使用している場合は、ペイロードのルート要素を次のように設定する必要があります。

changexmldoc = XmlUtils.getXmlDocument(ChangedDoc);
String mykey = "request";
message.addPayload(mykey,changexmldoc.getDocumentElement());

表19-1で、oracle.tip.mediator.common.api.IjavaCalloutインタフェースのメソッドについて説明します。

表19-1 IjavaCalloutインタフェースのメソッドの説明

メソッド	説明
`initialize`	コールアウト実装クラスが初めてインスタンス化されるときに起動されます。
`preRouting`	メディエータがケースの実行を開始する前にコールされます。このメソッドをカスタマイズすると、検証および拡張機能を組み込むことができます。
`preRoutingRule`	メディエータが特定のケースの実行を開始する前にコールされます。このメソッドをカスタマイズすると、ケース固有の検証および拡張機能を組み込むことができます。
`preCallbackRouting`	メディエータがコールバック処理の実行を終了する前にコールされます。このメソッドをカスタマイズすると、コールバックの監査およびカスタムのフォルト・トラッキングを実行できます。
`postRouting`	メディエータがケースの実行を終了した後にコールされます。このメソッドをカスタマイズすると、レスポンスの監査およびカスタムのフォルト・トラッキングを実行できます。
`postRoutingRule`	メディエータがケースの実行を開始した後にコールされます。このメソッドをカスタマイズすると、レスポンスの監査およびカスタムのフォルト・トラッキングを実行できます。
`postCallbackRouting`	メディエータがコールバック処理の実行を終了した後にコールされます。このメソッドをカスタマイズすると、コールバックの監査およびカスタムのフォルト・トラッキングを実行できます。

注意:

preRoutingRuleメソッドまたはpreRoutingメソッドで、Javaコールアウトを使用してメディエータのメッセージ・プロパティを変更した場合は、メディエータの割当て機能を使用して、変更したプロパティをアウトバウンド・メッセージに明示的にコピーする必要があります。たとえば、Javaコールアウトでjca.file.FileNameを変更している場合は、メディエータの割当て文を次のように更新する必要があります。

<assign>
<copy target="$out.property.jca.file.FileName" expression="$in.property.jca.file.FileName"/>
</assign>

表19-2で、CalloutMediatorMessageインタフェースのメソッドについて説明します。

表19-2 CalloutMediatorMessageインタフェースのメソッドの説明

メソッド	説明
`addPayload`	メディエータ・メッセージのペイロードを設定します。
`addProperty`	メディエータ・メッセージにプロパティを追加します。
`addHeader`	メディエータ・メッセージにヘッダーを追加します。
`getProperty`	プロパティ名を指定してメディエータ・メッセージのプロパティを取得します。
`getProperties`	メディエータ・メッセージのプロパティを取得します。
`getId`	メディエータ・メッセージのインスタンスIDを取得します。このインスタンスIDは、該当する特定のメッセージに対して作成されたメディエータ・インスタンスIDです。
`getPayload`	メディエータ・メッセージのペイロードを取得します。
`getHeaders`	メディエータ・メッセージのヘッダーを取得します。
`getComponentDN`	メディエータ・コンポーネントのcomponentDNを取得します。

注意:

oracle.tip.mediator.common.api.AbstractJavaCalloutImplクラスは、IJavaCalloutインタフェースのダミー実装^脚注1です。このクラスによって、IJavaCalloutインタフェースに存在するすべてのメソッドが定義されます。このため、このクラスの拡張によって、IJavaCalloutインタフェースのいくつかの特定メソッドのみを上書きできます。
Javaコールアウト内で発生する処理の詳細は、メディエータの「監査証跡」画面には表示されません。

^脚注1インタフェースのダミー実装は、実装クラスによって、特定のインタフェースで宣言されているすべてのメソッドの定義が提供されることを意味しますが、空のメソッド本体を1つ以上の定義済メソッドに指定することはできます。ダミー実装クラスの拡張は、インタフェースを実装してすべてのメソッドを定義する場合と異なり、メソッドのサブセットのみを上書きできるためより簡単です。

Javaコールアウト・クラスのサンプル

次の例は、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;
    }
}

19.2.3 動的ルーティング・ルールの作成

動的ルーティングの基本的な考え方は、プロセスが経由するパスを決定する制御ロジックを、そのプロセスの実行から分離することです。動的ルーティングのシナリオでは、各ルーティングに対して選択されるレベル2タイプのサービスの決定にデシジョン・マトリックスが使用されます。レベル2タイプのサービスのデシジョンに影響を与える要因は、チャネル、顧客タイプなどです。このソリューションによって、ビジネス・アナリストはルーティングを変更せずに、このデシジョン・マトリックスを外部から変更できます。アウトバウンド・サービスを決定するためには、デシジョン・マトリックスを評価する必要があります。

動的ルーティング・ルールは、図19-32に示すように、メディエータ・エディタ・ウィンドウの動的ルーティング・ルールのオプションを使用して作成できます。

図19-32 動的ルーティング・ルールのオプションが表示されたメディエータ・エディタ・ウィンドウ

「図19-32 動的ルーティング・ルールのオプションが表示されたメディエータ・エディタ・ウィンドウ」の説明

このウィンドウで、新しいビジネス・ルール・コンポーネントが作成され、メディエータ・コンポーネントのSCAコンポジット内のメディエータ・コンポーネントに接続されます。ビジネス・ルール・コンポーネントとメディエータ・コンポーネント間のワイヤ・リンクは、実装の詳細とみなされ、図19-33に示すように、SCAエディタでは点線で表示されます。

図19-33 ビジネス・ルール・コンポーネントとメディエータ・コンポーネント間のワイヤ・リンクが表示されたSCAエディタ

「図19-33 ビジネス・ルール・コンポーネントとメディエータ・コンポーネント間のワイヤ・リンクが表示されたSCAエディタ」の説明

ビジネス・ルール・コンポーネントは、ルール・ディクショナリで構成されます。ルール・ディクショナリは、ファクト・タイプ、ルールセット、ルール、デシジョン表など、ルール・エンジン・アーチファクトに対するメタデータ・コンテナです。ルール・ディクショナリは、ビジネス・ルール・コンポーネントの作成過程で、次のデータを使用して事前に初期化されます。

ファクト・タイプ・モデル

ファクト・タイプ・モデルは、ルールのモデル化に使用できるデータ・モデルです。ルール・ディクショナリには、phaseアクティビティの入力に対応するファクト・タイプ・モデルと、メディエータ・コンポーネントとビジネス・ルール・コンポーネント間の規定の一部として必要な固定データ・モデルの一部が移入されます。
ルールセット

ルールセットはルールのコンテナであり、ルールのグループ化メカニズムとして使用されます。ルールセットはサービスとして公開できます。ビジネス・ルール・コンポーネントの作成過程で、1つのルールセットがルール・ディクショナリ内に作成されます。
デシジョン表（またはマトリックス）

ルール・エンジンから見ると、デシジョン表は、ルールの条件およびアクション部分のファクト・タイプ・モデルの要素が同じであるルールの集合です。デシジョン表を使用すると、ルールを表形式で表示できます。ビジネス・ルール・コンポーネントの作成過程で、ルールセット内に新規デシジョン表が作成されます。
デシジョン・サービス

デシジョン・サービスは、ビジネス・ルール・コンポーネントの作成過程で作成され、ルールセットをビジネス・ルールSCAコンポーネントのサービスとして公開します。メディエータ・コンポーネントでは、サービス・インタフェースを使用してデシジョン表を評価します。

phaseアクティビティの必要なアーチファクトがすべて作成されると、ウィザードでは、フェーズ・デシジョン・マトリックス（PDM）のモデル化が開始されます。 JDeveloperのルール・デザイナ・ウィンドウが起動され、フェーズ・デシジョン・マトリックスを編集できるようになります。図19-34に、ルール・デザイナ内のデシジョン表のサンプルを示します。

図19-34 ルール・デザイナ内のデシジョン表のサンプル

「図19-34 ルール・デザイナ内のデシジョン表のサンプル」の説明

動的ルーティングを作成した後は、「動的ルールの編集」をクリックして、関連デシジョン・マトリックスを変更できます。ルール・デザイナが起動され、ビジネス・ルール・コンポーネントの関連デシジョン表の変更が可能になります。メディエータ・コンポーネントに対して動的ルーティングを作成した後は、その動的ルーティングを削除しないかぎり、静的ルーティングに戻ることはできません。現在、これら2つのタイプのルーティングを組み合せて使用するオプションはありません。

動的ルーティング・オプションを選択した後のメディエータのmplanファイルは、次のようになります。

図19-35 動的ルーティング・ルールを使用するメディエータのメディエータmplanファイル

「図19-35 動的ルーティング・ルールを使用するメディエータのメディエータmplanファイル」の説明

ソース・ビューは次のように変更されます。

<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要素には、デシジョン・サービス参照および操作の詳細が含まれています。これによって、メディエータ・コンポーネントは、動的ルーティング・デシジョンを取得するためのデシジョン・サービスを実行時に起動できます。動的デシジョンは、実行時のルール・エンジン・ユーザー構成によって返されます。

外部サービスの起動には、bindingInfoという特別な属性が含まれます。この属性には、起動を動的にするためのバインディング情報が含まれています。

動的ルーティング・ルールを使用するメディエータの制限

次に、動的ルーティング・ルールを使用するメディエータの制限をいくつか示します。

現在は、SOAPバインディングのみがサポートされています。 composite.xmlファイルには、ダミーのSOAPバインディングが作成されます。このエンドポイントは、NMプロパティを介して実行時にメディエータによって上書きされます。このため、アウトバウンド・サービスはSOAPを介してのみコールできます。
動的ルーティング・ルールによってペイロード操作が制限されます。割当て、トランスフォーメーションまたは検証は実行できません。
参照WSDLファイル（レイヤー2またはコールした参照）には、自動作成されるフェーズ参照と同じ抽象的なWSDLファイルが必要です。
動的ルーティングは、同期インタフェースまたは一方向インタフェースを使用するメディエータには使用できません。

19.3 メッセージ・ルーティング用メディエータの作成

CustomerRouterユースケースは、SOAコンポジット・サンプル・アプリケーションのメディエータを使用し、ペイロードに基づいてメッセージをルーティングする方法の概要を説明します。この項で説明するサンプル・ファイルをダウンロードするには、次のURLを参照してください。

http://www.oracle.com/technology/sample_code/products/mediator

CustomerRouterユースケースは次の手順で構成されます。

ReadCustという名前のアダプタ・サービスにより、レガシーのcustomerファイルがディレクトリから取り出されます。
ReadCustアダプタ・サービスがファイル・データをCustomerRouterメディエータに送信します。
CustomerRouterメディエータはXMLメッセージ・ペイロードにフィルタを適用し、メッセージをUSCustomer参照とCanadaCustomer参照のどちらにルーティングするか決定します。
次にCustomerRouterメディエータはメッセージをアダプタ参照で必要となる構造に変換します。
外部参照はメッセージを関連する外部アプリケーションに配信します。

図19-36は、CustomerRouterユースケースの概要を示しています。

図19-36 CustomerRouterユースケースの概要

「図19-36 CustomerRouterユースケースの概要」の説明

19.3.1 CustomerRouterユースケースの作成手順

この項では、ユースケースの作成、構築およびデプロイの設計時タスクを説明します。これらのタスクは、表示されている順番で実行する必要があります。

第19.3.1.1項「タスク1: Oracle JDeveloperのアプリケーションおよびプロジェクトの作成」
第19.3.1.2項「CustomerRouterメディエータ・コンポーネントの作成」
第19.3.1.3項「ファイル・アダプタ・サービスの作成」
第19.3.1.4項「ファイル・アダプタ参照の作成」
第19.3.1.5項「ルーティング・ルールの指定」
第19.3.1.6項「Oracle Application Server接続の作成」
第19.3.1.7項「CustomerRouterProjectのデプロイ」

19.3.1.1 タスク1: Oracle Jdeveloperのアプリケーションおよびプロジェクトの作成

ユースケース用のアプリケーションおよびプロジェクトを作成する手順は、次のとおりです。

Oracle JDeveloperで「ファイル」をクリックし、「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。
「新規ギャラリ」で「一般」ノードを開き、「アプリケーション」カテゴリを選択します。
「項目」リストで「SOAアプリケーション」を選択し、「OK」をクリックします。

SOAアプリケーションの作成ウィザードが表示されます。
「アプリケーション名」フィールドにCustomerRouterと入力し、「次へ」をクリックします。

「プロジェクトの名前付け」画面が表示されます。
「プロジェクト名」フィールドにCustomerRouterProjectと入力し、「次へ」をクリックします。

SOA設定の構成画面が表示されます。
「コンポジット・テンプレート」リストで「空のコンポジット」を選択し、「終了」をクリックします。

Oracle JDeveloperの「アプリケーション・ナビゲータ」には新規のアプリケーションやプロジェクトが移入され、「設計」タブには空白のパレットがあります。
「ファイル」メニューから「すべて保存」をクリックします。

19.3.1.2 CustomerRouterメディエータ・コンポーネントの作成

CustomerRouterという名前のメディエータを作成する手順は、次のとおりです。

「コンポーネント・パレット」から「SOA」を選択します。
「メディエータ」を「コンポーネント」設計領域にドラッグ・アンド・ドロップします。

「メディエータの作成」ダイアログが表示されます。
「名前」フィールドにCustomerRouterと入力します。
テンプレートから、「インタフェースを後で定義」を選択します。
「OK」をクリックします。

CustomerRouterという名前のメディエータが作成されます。

19.3.1.3 ファイル・アダプタ・サービスの作成

ディレクトリからXMLファイルを読み取るには、ReadCustという名前のファイル・アダプタ・サービスを作成する必要があります。

注意:

メディエータは、Oracle RACの計画的停止に対して実行する際、同じファイルを2回処理する可能性があります。これは、ファイル・アダプタがXAに準拠していないアダプタであるためです。このため、グローバル・トランザクションに組み入れると、各ファイルを1回のみ処理するXAインタフェース仕様に逸脱する可能性があります。

ファイル・アダプタ・サービスを作成する手順は、次のとおりです。

「コンポーネント・パレット」から「SOA」を選択します。
「ファイル・アダプタ」を選択し、「公開されたサービス」設計領域にドラッグします。

アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。

「サービス名」ページが表示されます。
「サービス名」フィールドに、ReadCustと入力します。
「次へ」をクリックします。

「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。

「操作」ページが表示されます。
「操作タイプ」フィールドで、「Read File」を選択します。
「操作名」フィールドで、ReadをReadFileに置換します。
「次へ」をクリックします。

「ファイル・ディレクトリ」ページが表示されます。
「着信ファイル用のディレクトリ(物理パス)」フィールドに、ファイルの読取り先のディレクトリを入力します。たとえば、C:\Customer\Inと入力します。
「次へ」をクリックします。

「ファイルのフィルタ処理」ページが表示されます。
「インクルード・ファイルの名前パターン」フィールドに*.xmlと入力し、「次へ」をクリックします。

「ファイル・ポーリング」ページが表示されます。
「ポーリング頻度」フィールドの値を10秒に変更し、「次へ」をクリックします。

「メッセージ」ページが表示されます。
「URL」フィールドの右側にある「検索」をクリックします。

「タイプ・チューザ」ダイアログが表示されます。
「スキーマ・ファイルのインポート」をクリックします。

「スキーマ・ファイルのインポート」ダイアログが表示されます。
「URL」フィールドの右側にある「検索」をクリックし、Samplesフォルダに存在するLegacyCustomer.xsdファイルを選択します。
「OK」をクリックします。
図19-37に示すように、「タイプ・エクスプローラ」→「インポートしたスキーマ」→「LegacyCustomer.xsd」の順にナビゲーション・ツリーを開き、「CustomerData」を選択します。

図19-37 「タイプ・チューザ」 - CustomerData

「図19-37 「タイプ・チューザ」 - CustomerData」の説明
「OK」をクリックします。

図19-38に示すように、アダプタ構成ウィザードが表示されます。

図19-38 アダプタ構成ウィザード – 「メッセージ」ページ

「図19-38 アダプタ構成ウィザード – 「メッセージ」ページ」の説明
「次へ」をクリックします。

「終了」ページが表示されます。
「終了」をクリックします。
「ファイル」メニューから「すべて保存」をクリックします。

19.3.1.4 ファイル・アダプタ参照の作成

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-39は、このタスク終了後に、SOAコンポジット・エディタがどのように表示されるかを示しています。

図19-39 アダプタ・サービスと参照があるメディエータ・コンポーネント

「図19-39 アダプタ・サービスと参照があるメディエータ・コンポーネント」の説明

19.3.1.5 ルーティング・ルールの指定

メッセージが経由するReadCustアダプタ・サービスから外部参照へのパスを指定する必要があります。

ルーティング・ルールを指定する手順は、次のとおりです。

図19-40に示すように、ReadCustサービスをCustomerRouterメディエータに接続します。

この操作により、ファイルを入力ディレクトリから読み込む間に、CustomerRouterメディエータを起動するファイル・アダプタ・サービスが指定されます。

図19-40 ReadCustサービスからCustomerRouterメディエータへの接続

「図19-40 ReadCustサービスからCustomerRouterメディエータへの接続」の説明
図19-41に示すように、「CustomerRouter」メディエータをダブルクリックして、CustomerRouter.mplanエディタを開きます。

図19-41 メディエータ・エディタ内のCustomerRouterメディエータ

「図19-41 メディエータ・エディタ内のCustomerRouterメディエータ」の説明
「ルーティング・ルール」セクションで、ReadFileの最も右側にある「追加」をクリックし、次に「静的ルーティング・ルール」をクリックします。

「ターゲット・タイプ」ダイアログが表示されます。
「サービス」をクリックします。

「ターゲット・サービス」ダイアログが表示されます。
図19-42に示すように、「CustomerRouterProject」→「参照」→「USCustomer」の順に移動し、「WriteFile」を選択します。

図19-42 「ターゲット・サービス」ダイアログ

「図19-42 「ターゲット・サービス」ダイアログ」の説明
「OK」をクリックします。

図19-43に示すように、「ルーティング・ルール」パネルが表示されます。

図19-43 「ルーティング・ルール」パネル - MapCustomerDataの追加

「図19-43 「ルーティング・ルール」パネル - MapCustomerDataの追加」の説明
「<<フィルタ式>>」フィールドの横にある「フィルタ」アイコンをクリックして、このルーティング・ルールのフィルタ式を作成します。

「式ビルダー」ダイアログが表示されます。
「変数」フィールドで、「変数」→「in」→「body」→「imp1:CustomerData」の順に移動し、「Country」を選択します。
「Country」をダブルクリックします。

図19-44に示すように、Countryノードが「式」フィールドに追加されます。

図19-44 「式ビルダー」ダイアログ

「図19-44 「式ビルダー」ダイアログ」の説明

式を次のように変更します。


$in.CustomerData/imp1:CustomerData/Country='US'

「OK」をクリックします。

図19-45に示すように、「ルーティング・ルール」パネルの「<<フィルタ式>>」フィールドに式が移入されます。

図19-45 移入後の「ルーティング・ルール」パネルの「フィルタ」フィールド

「図19-45 移入後の「ルーティング・ルール」パネルの「フィルタ」フィールド」の説明
「次を使用して変換」フィールドの右側にあるアイコンをクリックします。

図19-46に示すように、「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

図19-46 リクエスト・トランスフォーメーション・マップ

「図19-46 リクエスト・トランスフォーメーション・マップ」の説明
「新規マッパー・ファイルの作成」を選択し、「OK」をクリックします。

図19-47に示すように、「CustomerData_To_Customer.xsl」タブが追加されます。

図19-47 「CustomerData_To_Customer.xsl」タブ – 初期状態

「図19-47 「CustomerData_To_Customer.xsl」タブ – 初期状態」の説明
「imp1:CustomerData」ソース要素を「imp1:Customer」ターゲット要素にドラッグ・アンド・ドロップします。

「自動マップ・プリファレンス」ダイアログが表示されます。
「自動マップ中」オプションから、「祖先名を考慮した要素の一致」の選択を解除します。

図19-48に、「自動マップ・プリファレンス」ダイアログを示します。

図19-48 「自動マップ・プリファレンス」ダイアログ

「図19-48 「自動マップ・プリファレンス」ダイアログ」の説明
「OK」をクリックします。

図19-49に示すように、「CustomerData_To_Customer.xsl」タブが表示されます。

図19-49 「CustomerData_To_Customer.xsl」タブ – 自動マップ接続

「図19-49 「CustomerData_To_Customer.xsl」タブ – 自動マップ接続」の説明
「ファイル」メニューから「すべて保存」をクリックします。

手順3～17を繰り返し、ターゲット・サービスにCanadaCustomer参照を指定します。「式ビルダー」ダイアログで、次の式を指定します。

注意:

手順を繰り返すときは、マッパー・エディタを閉じるか、またはCustomerRouter.mplanタブをクリックして、メディエータ・エディタを再度開く必要があります。


$in.CustomerData/imp1:CustomerData/Country='CA'

図19-50は、ターゲット・サービスとしてCanadaCustomer参照を指定した後、メディエータ・エディタがどのように表示されるかを示しています。

図19-50 ターゲット・サービスが定義された「ルーティング・ルール」パネル

「図19-50 ターゲット・サービスが定義された「ルーティング・ルール」パネル」の説明

この項で説明した手順をすべて実行すると、図19-36に示すように、SOAコンポジット・エディタが表示されます。

19.3.1.6 Oracle Application Server接続の作成

SOAコンポジット・アプリケーションをデプロイするには、Oracle Application Server接続が必要です。 Oracle Application Server接続の作成の詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

19.3.1.7 CustomerRouterProjectのデプロイ

次の手順で、CustomerRouterProjectコンポジット・アプリケーションをOracle Application Serverにデプロイします。

アプリケーション・デプロイメント・プロファイルの作成
Oracle Application Serverへのアプリケーション・デプロイメント・プロファイルのデプロイ

これらの手順の詳細は、第43.2項「Oracle JDeveloperでの単一のSOAコンポジットのデプロイ」を参照してください。

19.3.2 CustomerRouterProjectアプリケーションの実行と監視

デプロイしたCustomerRouterProjectアプリケーションは、入力xmlファイルを入力フォルダにコピーすることで実行できます。ファイルは、ペイロードに基づいて、指定された出力ディレクトリに作成されます。

実行中のインスタンスの監視には、次のURLにあるOracle Enterprise Managerコンソールを使用できます。

http://hostname:portnumber/em

ここで、hostnameは、Oracle SOA Suiteインフラストラクチャをインストールしたホストです。portnumberは、Enterprise Managerがインストールされているサーバーのポートです。

これらの手順の詳細は、第43.2項「Oracle JDeveloperでの単一のSOAコンポジットのデプロイ」を参照してください。

19.4 メディエータを使用した非同期リクエスト・レスポンスの作成

このサンプルでは、メディエータを使用した非同期リクエスト・レスポンスのシナリオを示します。サンプルのコンポジットにはメディエータを起動するクライアントBPELプロセスがあり、メディエータはサーバーBPELプロセスを起動します。起動はすべて非同期リクエスト・レスポンスとして行われます。

図19-51は、AsyncMediatorユースケースの概要を示しています。

図19-51 AsyncMediatorユースケースの概要

「図19-51 AsyncMediatorユースケースの概要」の説明

この項で説明するサンプル・ファイルをダウンロードするには、次のURLを参照してください。

http://www.oracle.com/technology/sample_code/products/mediator

19.4.1 AsyncMediatorユースケースの作成手順

第19.4.1.1項「タスク1: Oracle JDeveloperのアプリケーションおよびプロジェクトの作成」
第19.4.1.2項「タスク2: サーバーBPELプロセスの作成」
第19.4.1.3項「タスク3: メディエータ・コンポーネントの作成」
第19.4.1.4項「タスク4: クライアントBPELプロセスの作成」
第19.4.1.5項「タスク5: invoke、receiveおよびassignアクティビティの作成」
第19.4.1.6項「タスク6: Oracle Application Server接続の構成」
第19.4.1.7項「タスク7: コンポジット・アプリケーションのデプロイ」

19.4.1.1 タスク1: Oracle Jdeveloperのアプリケーションおよびプロジェクトの作成

ユースケース用のアプリケーションおよびプロジェクトを作成する手順は、次のとおりです。

Oracle JDeveloperで「ファイル」をクリックし、「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。
「新規ギャラリ」で「一般」ノードを開き、「アプリケーション」カテゴリを選択します。
「項目」リストで「SOAアプリケーション」を選択し、「OK」をクリックします。

SOAアプリケーションの作成ウィザードが表示されます。
「アプリケーション名」フィールドにAsyncMediatorと入力し、「次へ」をクリックします。

「プロジェクトの名前付け」画面が表示されます。
「プロジェクト名」フィールドにAsyncMediatorSampleと入力し、「次へ」をクリックします。

SOA設定の構成画面が表示されます。
「コンポジット・テンプレート」リストで「空のコンポジット」を選択し、「終了」をクリックします。

Oracle JDeveloperの「アプリケーション・ナビゲータ」には新規のアプリケーションやプロジェクトが移入され、「設計」タブには空白のパレットがあります。
「ファイル」メニューから「すべて保存」をクリックします。

19.4.1.2 タスク2: サーバーBPELプロセスの作成

サーバーBPELプロセスを作成する手順は、次のとおりです。

「アプリケーション・ナビゲータ」で、「composite.xml」をダブルクリックします。「composite.xml」ウィンドウが表示されます。
「コンポーネント・パレット」から「SOA」を選択します。
「BPELプロセス」を「コンポーネント」設計領域にドラッグ・アンド・ドロップします。

「BPELプロセスの作成」ダイアログが表示されます。
「名前」フィールドに、ServerBPELProcessと入力します。
「テンプレート」フィールドで、「非同期BPELプロセス」を選択します。
「SOAPサービスとして公開」の選択を解除して、「OK」をクリックします。「composite.xml」ウィンドウにServerBPELProcessが作成されます。

19.4.1.3 タスク3: メディエータ・コンポーネントの作成

Mediatorという名前のメディエータを作成する手順は、次のとおりです。

「コンポーネント・パレット」から「SOA」を選択します。
「メディエータ」を「コンポーネント」設計領域にドラッグ・アンド・ドロップします。

「メディエータの作成」ダイアログが表示されます。
「名前」フィールドにMediatorと入力し、「テンプレート」から「非同期インタフェース」を選択します。
「SOAPバインディングを持つコンポジット・サービスの作成」の選択を解除します。
「OK」をクリックします。

図19-52に示すように、Mediatorという名前のメディエータが作成されます。

図19-52 コンポジット・ウィンドウ内のMediatorとServerBPELProcess

「図19-52 コンポジット・ウィンドウ内のMediatorとServerBPELProcess」の説明
「Mediator」メディエータをダブルクリックします。

「Mediator.mplan」ウィンドウが表示されます。
「ルーティング・ルール」セクションで、executeの最も右側にある「追加」をクリックし、次に「静的ルーティング・ルール」をクリックします。

「ターゲット・タイプ」ダイアログが表示されます。
「サービス」を選択します。

「ターゲット・サービス」ダイアログが表示されます。
図19-53に示すように、「AsyncMediatorSample」→「BPELプロセス」→「ServerBPELProcess」→「サービス」→「serverbpelprocess_client」の順に移動し、「process」を選択します。

図19-53 「ターゲット・サービス」ダイアログ

「図19-53 「ターゲット・サービス」ダイアログ」の説明
「OK」をクリックします。

図19-54に示すように、「ルーティング・ルール」パネルが表示されます。

図19-54 「ルーティング・ルール」パネル - initiateの追加

「図19-54 「ルーティング・ルール」パネル - initiateの追加」の説明
「<<フィルタ式>>」フィールドの下の「次を使用して変換」フィールドの右側にあるアイコンをクリックします。

「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。
「新規マッパー・ファイルの作成」を選択し、「OK」をクリックします。

「singleString_To_process.xsl」タブが追加されます。
「cb1:input」ソース要素を「client:input」ターゲット要素にドラッグ・アンド・ドロップします。

「自動マップ・プリファレンス」ダイアログが表示されます。
「自動マップ中」オプションから、「祖先名を考慮した要素の一致」の選択を解除し、「OK」をクリックします。図19-55に示すように、「singleString_To_process.xsl」ウィンドウが表示されます。

図19-55 「singleString_To_process.xsl」ウィンドウ

「図19-55 「singleString_To_process.xsl」ウィンドウ」の説明
「ルーティング・ルール」パネルで、「コールバック」にある「次を使用して変換」フィールドの右側にあるアイコンをクリックします。

「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。
「新規マッパー・ファイルの作成」を選択し、「OK」をクリックします。

「processResponse_To_singleString.xsl」タブが追加されます。
「client:processResponse」ソース要素を「cb1:singleString」ターゲット要素にドラッグ・アンド・ドロップします。

「自動マップ・プリファレンス」ダイアログが表示されます。
「自動マップ中」オプションから、「祖先名を考慮した要素の一致」の選択を解除し、「OK」をクリックします。

19.4.1.4 タスク4: クライアントBPELプロセスの作成

クライアントBPELプロセスを作成する手順は、次のとおりです。

「アプリケーション・ナビゲータ」で、「composite.xml」をダブルクリックします。「composite.xml」ウィンドウが表示されます。
「コンポーネント・パレット」から「SOA」を選択します。
「BPELプロセス」を「コンポーネント」設計領域にドラッグ・アンド・ドロップします。

「BPELプロセスの作成」ダイアログが表示されます。
「名前」フィールドに、ClientBPELProcessと入力します。
「テンプレート」フィールドで、「非同期BPELプロセス」を選択します。
「OK」をクリックします。「composite.xml」ウィンドウにClientBPELProcessが作成されます。
「ClientBPELProcess」BPELプロセスを「Mediator」メディエータにドラッグ・アンド・ドロップします。図19-51に示すように、composite.xmlが表示されます。

19.4.1.5 タスク5: invoke、receiveおよびassignアクティビティの作成

invokeアクティビティを作成する手順は、次のとおりです。

「ClientBPELProcess」をダブルクリックします。「ClientBPELProcess.bpel」ページが表示されます。
「コンポーネント・パレット」から設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。
invokeアクティビティをダブルクリックします。「Invoke」ダイアログが表示されます。
「名前」フィールドにInvokeMediatorと入力します。
「パートナ」フィールドの横の「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。
「操作 - execute」を選択して、「OK」をクリックします。
「Receive」ダイアログで、「変数」フィールドの右側にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
「変数」フィールドにInvokeMediator_execute_InputVariable_1と入力し、「OK」をクリックします。「Invoke」ダイアログが表示されます。
「OK」をクリックします。「Oracle JDeveloper ClientBPELProcess.bpel」ページが表示されます。

receiveアクティビティを作成する手順は、次のとおりです。

「コンポーネント・パレット」から設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。
receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。
「名前」フィールドにReceiveFromMediatorと入力します。
「パートナ」フィールドの横の「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。
「操作 - callback」を選択して、「OK」をクリックします。
「Receive」ダイアログで、「変数」フィールドの右側にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。
「インスタンスの作成」を選択して、「OK」をクリックします。「Oracle JDeveloper ClientBPELProcess.bpel」ページが表示されます。

assignアクティビティを作成する手順は、次のとおりです。

「コンポーネント・パレット」からassignアクティビティをドラッグし、設計領域のReceiveFromMediatorアクティビティとInvokeMediatorアクティビティの間にドロップします。
assignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。
「名前」フィールドにAssignRequestと入力します。
「コピー操作」タブをクリックします。「Assign」ダイアログが表示されます。
「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。
図19-56に示すように、トリガー・ファイル名とファイル変数の間にコピー操作を作成します。

図19-56 「コピー操作の作成」ダイアログ

「図19-56 「コピー操作の作成」ダイアログ」の説明
「コピー操作の作成」ダイアログで「OK」をクリックします。
図19-57に示すように、「OK」をクリックして、「Oracle JDeveloper ClientBPELProcess.bpel」ページに戻ります。

図19-57 Oracle JDeveloper - ClientBPELProcess.bpel

「図19-57 Oracle JDeveloper - ClientBPELProcess.bpel」の説明
「ファイル」から「すべて保存」をクリックします。

assignアクティビティを「ServerBPELProcess.bpel」ウィンドウで作成する手順は、次のとおりです。

「ServerBPELProcess.bpel」BPELプロセスをダブルクリックします。「ServerBPELProcess.bpel」ウィンドウが表示されます。
「コンポーネント・パレット」からassignアクティビティをドラッグし、設計領域のreceiveInputアクティビティとcallbackClientアクティビティの間にドロップします。
assignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。
「コピー操作」タブをクリックします。「Assign」ダイアログが表示されます。
「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。
図19-58に示すように、トリガー・ファイル名とファイル変数の間にコピー操作を作成します。

図19-58 「コピー操作の作成」ダイアログ

「図19-58 「コピー操作の作成」ダイアログ」の説明
「コピー操作の作成」ダイアログで「OK」をクリックします。
図19-59に示すように、「OK」をクリックして、「Oracle JDeveloper ServerBPELProcess.bpel」ページに戻ります。

図19-59 Oracle JDeveloper - ServerBPELProcess.bpel

「図19-59 Oracle JDeveloper - ServerBPELProcess.bpel」の説明
「ファイル」から「すべて保存」をクリックします。

19.4.1.6 タスク6: Oracle Application Server接続の構成

SOAコンポジット・アプリケーションをデプロイするには、Oracle Application Server接続が必要です。 Oracle Application Server接続の作成の詳細は、第19.3.1.6項「Oracle Application Server接続の作成」を参照してください。

19.4.1.7 タスク7: コンポジット・アプリケーションのデプロイ

次の手順で、EventMediatorAppコンポジット・アプリケーションをOracle Application Serverにデプロイします。

アプリケーション・デプロイメント・プロファイルの作成
Oracle Application Serverへのアプリケーションのデプロイ

これらの手順の詳細は、第43.2項「Oracle JDeveloperでの単一のSOAコンポジットのデプロイ」を参照してください。