20 Oracle Mediatorルーティング・ルールの作成
この章の内容は次のとおりです。
特定のシナリオのためのルーティング・ルールの定義の詳細は、次を参照してください:
-
Oracle Mediatorにおける複数パート・メッセージの使用
-
Oracle Mediatorにおける再順序付け
20.1 ルーティング・ルールの概要
ルーティング・ルールは、必要な仲介を実行するために定義する仲介ロジックまたは実行ロジックです。メディエータを使用すると、サービス・コンシューマとサービス・プロバイダの間でデータをルーティングできます。データはサービス間をフローするため、トランスフォーメーションが必要です。ルーティングとトランスフォーメーションの2つのタスクは、メディエータの中核となる処理内容です。ルーティング・ルールにより、メディエータで処理されたメッセージを次の宛先にどのように送信するかを指定できます。ルーティング・ルールは、メディエータによるメッセージの送信先、メッセージの送信方法、およびターゲット・サービスへの送信前にメッセージ構造に加える必要がある変更の内容を指定します。
ルーティング・ルールは、サービス操作またはイベント・サブスクリプションのいずれかでトリガーできます。サービス操作は、同期、非同期または一方向のいずれかです。ルーティング・ルールには、次の2つのタイプがあります。
-
静的ルーティング・ルール
起動コンテキストによって変更されることのない一貫して適用される静的ルールです。
-
動的ルーティング・ルール
Oracle Rules Dictionaryへのルーティング・ロジックの外部化を可能にする動的ルールです。Oracle Rules Dictionaryは、ルーティング・ロジックの動的変更を可能にします。
ルーティング・ルールの作成の詳細は、「静的ルーティング・ルールの作成方法」および「動的ルーティング・ルールの作成方法」を参照してください。標準のメッセージ交換パターンの詳細とそれらのメディエータでの処理方法は、「Oracle Mediatorのメッセージ交換パターンの理解」を参照してください。
20.1.1 静的ルーティング・ルール
起動コンテキストによって変更されることのない静的ルーティング・ルールです。この場合のルーティングは、エコー、別のサービスへのルーティングまたはイベントの公開のいずれかです。
静的ルールを定義するときは、次のタイプの情報を指定できます。
-
ターゲット・サービス
メディエータにより、指定するターゲット・サービスにメッセージが送信されます。このサービスは、WSDLインタフェースまたはJavaインタフェースとして定義できます。ターゲット・サービスの起動の詳細は、「メディエータ・サービスまたはイベントの指定方法」を参照してください。
-
実行タイプ
メディエータは、ルーティング・ルールを順次(同じスレッド内で実行)またはパラレル(異なるスレッドで実行)のいずれかで実行します。実行タイプの指定方法の詳細は、「順次実行またはパラレル実行の指定方法」を参照してください。
ノート:
同期サービス起動の場合、ルーティング・ルールは必ず順次にする必要があります。
-
リプライ、コールバックおよびフォルト・ハンドラ
同期リプライ、コールバックおよびフォルト・メッセージをメディエータで処理する方法を定義できます。ハンドラの詳細は、「レスポンス・メッセージの構成方法」、「フォルトの処理方法」および「静的ルーティング・ルール・コンポーネント」を参照してください。
20.1.1.1 静的ルールのタイプ
次のタイプのメディエータの静的ルールを定義できます。
-
フィルタ式
メッセージのコンテンツ(ペイロードまたはヘッダー)に適用するフィルタ式を定義できます。フィルタを定義する場合、コンテンツはサービスの起動前に分析されます。たとえば、メッセージに顧客IDが含まれている場合、またはその顧客IDの値が特定のパターンと一致する場合のみサービスを起動することを指定する、フィルタ式を適用できます。フィルタ式の指定方法の詳細は、「メッセージをフィルタリングする式の指定方法」を参照してください。
-
トランスフォーメーション
メディエータでは、メッセージをサービスに転送する前にメッセージ・データを変換できます。データのマッピングまたは値の割当てにより、ターゲット・ペイロードで値を設定するようトランスフォーメーションを定義できます。
XSLTマッパーを使用すると、XMLスキーマ間でメッセージを変換するために、メッセージ本文全体に適用するトランスフォーメーションを定義できます。値の割当て機能では個々のフィールドを処理します。このダイアログを使用すると、メッセージ(ペイロード、ヘッダーなど)、定数または様々なシステム・プロパティ(データ・パスに存在するアダプタのプロパティなど)から値を割り当てることができます。トランスフォーメーションの定義の詳細は、「XSLTトランスフォーメーションの作成方法」および「値の割当て方法」を参照してください。
-
式にあるヘッダー変数へのアクセス
メディエータは、現在のルーティング・ルール操作用の式の作成に使用したSOAPヘッダーを検出できます。ヘッダー・アクセスの詳細は、「フィルタおよび割当てのためのヘッダー・アクセス方法」および「フィルタおよび割当てのためのプロパティ・アクセスに使用する式の手動作成」を参照してください。
-
Schematronベースの検証
インバウンド・メッセージの様々な部分を検証するためにメディエータが使用する必要のあるSchematronファイルを指定できます。Schematronをベースにした検証の実行方法の詳細は、「セマンティク検証の使用方法」を参照してください。
-
Javaコールアウト
メディエータでは、ルーティング・ルールにJavaコールアウトを追加できます。Javaコールアウトを使用すると、メディエータを介してフローするメッセージの操作に外部のJavaクラスを使用できます。Javaコールアウトの使用方法の詳細は、「Javaコールアウトの使用方法」を参照してください。
-
ユーザー定義拡張関数
XSLTマッパーで使用可能な独自の関数セットです。ユーザー定義拡張関数の使用方法の詳細は、「ユーザー定義拡張関数を追加する手順:」を参照してください。
20.1.1.2 静的ルーティング・ルール・コンポーネント
静的ルーティング・ルールでは、次のコンポーネントを定義します。
-
リクエスト・ハンドラ: メディエータでの受信リクエストの処理方法を定義します。
-
リプライ・ハンドラ: コールしたサービスからの同期レスポンスをメディエータが処理する方法を定義します。
-
フォルト・ハンドラ: コールしたサービスからの名前付きフォルトまたは宣言済フォルトをメディエータが処理する方法を定義します。
-
コールバック・ハンドラ: コールしたサービスからの非同期レスポンスとコールバックをメディエータが処理する方法を定義します。
-
コールバックのタイムアウト・ハンドラ: 特定の非同期リクエストに対するタイムアウト処理を実行するまでに、メディエータが、非同期レスポンスとコールバックを待機する時間を定義します。
-
イベントの公開およびサービスの起動: ハンドラの構成に応じて、他のサービスのコールまたはイベントの公開を実行します。
20.1.2 動的ルーティング・ルール
動的ルーティング・ルールは、Oracle Rules DictionaryまたはDomain Value Map (DVM)へのルーティング・ロジックの外部化を可能にし、これらは、ルーティング・ルール内のルーティング・ロジックの動的変更を可能にします。動的ルーティングにより、メッセージの内容に基づいて、実行時にメッセージをメディエータから複数のターゲット・サービスに動的にルーティングできます。
動的ルーティング・ルールについては、「動的ルーティング・ルールの作成方法」で詳しく説明します。
20.1.3 順次実行およびパラレル実行
ルーティング・ルールは、順次またはパラレルで実行できます。この項では、両方の実行タイプの基本原則について説明します。操作またはイベントに順次およびパラレルの両方のルーティング・ルールがある場合は、最初に順次ルーティング・ルールが評価されてアクションが実行され、次にパラレルのルーティングがパラレル実行のためにキューに入れられます。
ノート:
リクエスト/レスポンス・インタフェースを使用するメディエータ・サービス・コンポーネントにパラレルのルーティング・ルールのみが設定されている場合、そのメディエータ・サービス・コンポーネントはコール元にレスポンスを返信しません。このタイプのメディエータ・サービス・コンポーネントは作成できますが、メディエータ・サービス・コンポーネントのコール元が、実行時にレスポンスを受信することはありません。
20.1.3.1 順次ルーティング・ルールの基本原則
メディエータは、次の原則に基づいて順次ルーティング・ルールを処理します。
-
メディエータは、ルーティングを評価し、結果の処理を順次実行します。順次ルーティングは、コール元と同じスレッドとトランザクションで評価されます。
-
メディエータは常に、受信メッセージを処理しているスレッドを介して伝播されたグローバル・トランザクションにメディエータ自体を登録します。たとえば、インバウンドJCAアダプタがメディエータを起動すると、そのメディエータは、JCAアダプタが開始したトランザクションにメディエータ自体を登録します。
-
メディエータは、順次ルーティング・ルールの実行中に、ターゲット・コンポーネントと同じスレッドを介してトランザクションを伝播します。
-
外部エンティティによって伝播されたトランザクションを、メディエータがコミットまたはロールバックすることはありません。
-
メディエータがトランザクションを管理するのは、スレッド起動メディエータにアクティブなトランザクションが存在していない場合のみです。たとえば、メディエータがインバウンドSOAPサービスから起動された場合、そのメディエータはトランザクションを開始し、成功および失敗に応じてトランザクションをコミットまたはロールバックします。
20.1.3.2 パラレルのルーティング・ルールの基本原則
メディエータは、次の原則に基づいてルーティング・ルールをパラレルで処理します。
-
メディエータは、ルーティングをキューに入れ、別々のスレッドでパラレルに評価します。
各メディエータ・サービス・コンポーネントのメッセージは、重み付けラウンド・ロビン方式で取得され、すべてのメディエータ・サービス・コンポーネントで確実にパラレル処理サイクルが受け入れられます。これは、1つ以上のメディエータ・サービス・コンポーネントで、他のコンポーネントよりも多くのメッセージが生成される場合でも同様です。使用される重み付けは、メディエータ・サービス・コンポーネントの設計時に設定されたメッセージ優先度です。メッセージ優先度の高いコンポーネントほど、多数のパラレル処理サイクルが割り当てられます。
メディエータ・サービス・コンポーネントの優先度を指定するには、メディエータ・エディタで「優先度」フィールドを設定します。優先度は0から9までの範囲で、9が最高優先度です。デフォルトの優先度は4です。
ノート:
「優先度」プロパティの適用対象は、パラレルのルーティング・ルールのみです。
-
メディエータは、各パラレル・ルールを処理するための新規トランザクションを開始します。開始されたトランザクションは、メディエータのパラレル・メッセージ・デハイドレーション・ストアへのエンキューで終了します。
たとえば、メディエータ・サービス・コンポーネントにパラレルのルーティング・ルールが1つある場合は、1つのメッセージがメディエータのパラレル・メッセージ・デハイドレーション・ストアにエンキューされます。次に、ストアに対するパラレル・メッセージ・ディスパッチャがトランザクションを開始し、データベース・ストアからメッセージを読み取り、このルーティング・ルールのターゲット・コンポーネントまたはサービスを起動します。リスナー・スレッドによって開始されるトランザクションは、完全に新規のトランザクションであり、ターゲット・コンポーネントに伝播されます。
ノート:
メッセージのデハイドレーションでは、パラレル・ルーティング・ルール対象の受信メッセージがデータベースに格納されるため、ワーカー・スレッドはそれらのメッセージを後で処理できます。
-
メディエータはトランザクションのイニシエータであるため、これらのトランザクションをコミットまたはロールバックします。
20.1.3.3 パラレル・ルーティングにおけるスレッド割当ての精細制御
専用ワーク・マネージャを指定して、メディエータ・コンポーネントのパラレル・ルーティングとエラー処理メッセージを処理できます。Oracle WebLogic Server管理コンソールを使用して、ワーク・マネージャを構成できます。ワーク・マネージャを構成する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のワーク・マネージャのプロパティの表示と構成に関する項を参照してください。
NameWorkManagerMappingsメディエータ・サービス・エンジン・プロパティを使用して、メディエータ・コンポーネントとその関連ワーク・マネージャをOracle Enterprise Manager Fusion Middleware Controlで指定します。メディエータ・ランタイム・プロパティを構成する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle Mediatorサービス・エンジン・プロパティの構成に関する項を参照してください。
NameWorkManagerMappingsプロパティには、次のキーが含まれています。
-
parallelRoutingWorkManagerName:パラレル・ルーティング用に構成されるワーク・マネージャの名前です。指定されないと、デフォルトのSOAワーク・マネージャが使用されます。 -
fullyQualifiedComponentDistinguishedName:メディエータ・コンポーネントの完全修飾名です。使用する形式は、PartitionName/CompositeName!Revision/ComponentNameです。たとえば、soaInfra/MyProject!1.0/Mediator1です。
20.2 再順序付けルール
メディエータには再シーケンサが含まれており、これは、関連がありながらも順序が正しくないメッセージを、使用されている再シーケンサのタイプと定義されているルールに基づいて適切な順序に並べ替えます。受信メッセージがランダムな順番で着信した場合、再シーケンサは、メッセージを順次または時系列の情報に基づいて並べ替え、再順序付けの構成に基づいた正しい順序でメッセージをターゲット・サービスに送信します。
メッセージの再順序付けの詳細は、「Oracle Mediatorにおける再順序付け」を参照してください。
20.3 ルーティング・ルールの定義
ルーティング・ルールは、インタフェースが定義されているメディエータにのみ定義できます。インタフェースの定義方法の詳細は、「メディエータのインタフェースの定義方法」を参照してください。
20.3.1 「ルーティング・ルール」セクションへのアクセス方法
メディエータ・エディタの「ルーティング・ルール」セクションで、ルーティング・ルールを定義します。
図20-1に、メディエータ・エディタの「ルーティング・ルール」セクションを示します。
図20-2では、「ルーティング・ルール」セクションのアイコンをリストして説明します。
次のいずれかの方法を使用して、メディエータ・エディタの「ルーティング・ルール」セクションにアクセスできます。
20.3.2 静的ルーティング・ルールの作成方法
この後の各項では、メディエータの静的ルーティング・ルールの定義(サービスおよびイベントの指定、ハンドラ、トランスフォーメーション、式、フィルタなどの定義)に関する情報および手順について説明します。
20.3.2.1 メディエータ・サービスまたはイベントの指定方法
メディエータ・コンポーネントを作成した後は、そのメディエータをインバウンド・サービス操作またはイベント・サブスクリプション、およびアウトバウンド・ターゲットに関連付けます。ターゲットは、アウトバウンド・サービス操作またはイベントの公開です。ターゲットはメディエータがメッセージを送信する次のサービスまたはイベントを指定し、起動するサービス操作も指定します。サービスまたはイベントをターゲット・タイプとして指定できます。
ソース・メッセージは、トランスフォーメーション、検証、割当てまたは順序操作の実行後に、初期のコール元にエコーして戻すこともできます。エコーは、メディエータ・コンポーネントに同期または非同期のインタフェースがある場合にのみ指定できます。エコーが同期、非同期のいずれで行われるかは、コール元のWSDLファイルによって決まります。エコー・オプションは、インバウンド・サービス操作に対してのみ使用可能で、イベント・サブスクリプションには使用できません。
エコー・オプションの目的は、メディエータのすべての機能をコール可能なサービスとして公開することによって、他のサービスへのルーティングの必要性をなくすことです。たとえば、メディエータをコールしてトランスフォーメーション、検証または割当てを実行した後、別の場所にルーティングすることなくアプリケーションにメディエータをエコーして戻すことができます。
1つのインバウンド操作またはイベントに複数のルーティングを指定できます。各ルーティングは、1つのターゲット・サービス起動またはイベントにマップされます。したがって、特定のターゲット・サービスに対して複数のサービス起動を指定したり、複数イベントを発生させるには、各ターゲットに1つのルーティング・ルールを指定する必要があります。たとえば、メッセージ・ペイロードに基づいて、サービスに定義された次の操作から、ある操作を起動できます。
-
insert
-
update
-
updateid
-
delete
このアクションを実行するため、各操作に1つずつ、4つのルーティング・ルールを作成する必要があります。その後、各ルールにフィルタ式を指定する場合は、図20-3に示すように、メッセージ・ペイロードに基づいて各メッセージ・インスタンスに適用するターゲットおよび操作を指定できます。
20.3.2.1.1 サービスを起動するには:
このステップを実行するには、WSDLドキュメントまたはJavaインタフェースでターゲット・サービスを定義する必要があります。
-
「ルーティング・ルール」セクションで、ルーティング・ルールを定義中の操作の横にある「追加」をクリックし、次に「静的ルーティング・ルール」を選択します。
図20-4に示すように、「ターゲット・タイプ」ダイアログが表示されます。
-
「サービス」をクリックします。
図20-5に示すように、「ターゲット・サービス」ダイアログが表示されます。
-
「ターゲット・サービス」ダイアログで、サービスが提供する操作に移動し、選択します。
ノート:
WSDLファイルまたはJavaインタフェースで定義されているサービスを選択できます。図20-5に示すように、サービスは複数の操作で構成できます。
-
「OK」をクリックします。
-
Javaインタフェースで定義されたターゲット・サービスを選択した場合、「必要なインタフェース」ダイアログが表示されます。「はい」をクリックして必要なWSDLファイルを作成し、次に確認ダイアログで「OK」をクリックします。
ルーティング・ルールを定義できる新規の「静的ルーティング」セクションが表示されます。
-
この章の後続の項の説明に従って、ルーティング・ルールを構成します。
20.3.2.1.2 イベントをトリガーするには:
-
「ルーティング・ルール」セクションで、ルーティング・ルールを定義中の操作の横にある「追加」をクリックし、次に「静的ルーティング・ルール」を選択します。
図20-4に示すように、「ターゲット・タイプ」ダイアログが表示されます。
-
「イベント」をクリックします。
「イベント・チューザ」ダイアログが表示されます。
-
「イベント定義」フィールドの右側にある「検索」をクリックします。
「SOAリソース・ブラウザ」ダイアログが表示されます。
-
イベント(
.edl)・ファイルを選択し、「OK」をクリックします。図20-6に示すように、選択したファイルに定義されているイベントが「イベント」フィールドに移入されます。
ノート:
既存のイベント定義ファイルを参照するかわりに、「新規イベント定義(edl)ファイルを作成します。」をクリックし、「イベント定義ファイルの作成」ダイアログのフィールドを完了して、新規ファイルを作成できます。
-
イベントを選択します。
-
「OK」をクリックします。
ルーティング・ルールを定義できる新規の「静的ルーティング」セクションが表示されます。
-
この章の後続の項の説明に従って、ルーティング・ルールを構成します。
20.3.2.2 サービスのエコーに関する必知事項
エコー・オプションには次の制限があります。
-
サービスのエコーは、メディエータのインタフェースが、次のタイプのWSDLファイルの場合のみサポートされます。
-
リクエスト/リプライ
-
リクエスト/リプライ/フォルト
-
リクエスト/コールバック
ノート:
エコー・オプションは、メディエータのインタフェースがリクエスト/リプライ/フォルト/コールバックのWSDLファイル、または一方向WSDLファイルの場合には使用できません。
-
-
エコー・オプションは、リクエスト/リプライおよびリクエスト/リプライ/フォルトのような同期操作で使用できます。
ノート:
同期操作のメディエータでは、パラレルのルーティング・ルールはサポートされないため、エコー・オプションを同期操作で使用できるのは、ルーティング・ルールが順次実行の場合のみです。
-
条件フィルタ付きの同期操作の場合は、フィルタ条件を
falseに設定していると、エコー・オプションではレスポンスがコール元に返されません。かわりに、nullレスポンスが返されます。 -
エコー・オプションを非同期操作で使用できるのは、メディエータのインタフェースにコールバック操作が指定されている場合のみです。この場合、エコーは別のスレッドで実行されます。
ノート:
非同期のエコー・オプションを使用できるのは、ルーティング・ルールがパラレル実行の場合のみです。エコー・オプションを使用する場合、非同期操作のメディエータでは、順次実行のルーティング・ルールはサポートされません。
20.3.2.3 順次実行またはパラレル実行の指定方法
ルーティング・ルールは、パラレルまたは順次のいずれかで実行できます。ルーティング・ルールの実行タイプを指定するには、「ルーティング・ルール」セクションで、「順次」または「パラレル」実行タイプを選択します。
20.3.2.4 レスポンス・メッセージの構成方法
メディエータ・ルーティング・ルールでは、レスポンス・メッセージを同期および非同期の相互作用内で処理する方法を指定できます。同期相互作用の場合は、レスポンスとフォルト・メッセージのトランスフォーメーションと割当てを指定できます。レスポンスとフォルト・メッセージを別のサービスまたはイベントに転送するか、または初期のコール元にレスポンスおよびフォルトを受信する用意がある場合は、それらを初期のコール元に戻すことができます。
非同期相互作用の場合は、トランスフォーメーションと割当て、およびレスポンスを受信するまでのタイムアウト時間を指定できます。タイムアウト時間は、秒、時、日、月または年で指定できます。タイムアウト時間のデフォルト値は無限です。コールバック・レスポンスが指定したタイムアウト時間内に返されない場合、タイムアウトしたレスポンスは別のサービス、別のイベントに転送されるか、初期のコール元に戻されます。
メディエータのレスポンスを双方向サービスにルーティングすることはできません。レスポンスを双方向サービスにルーティングする場合は、最初のメディエータと双方向サービスの間に一方向のメディエータを使用する必要があります。レスポンスを最初に一方向のメディエータに転送し、その一方向のメディエータが双方向サービスをコールする必要があります。
ノート:
-
0(ゼロ)のタイムアウト時間指定はサポートされていません。
-
コールバックを受信し、そのコールバックの処理に失敗した場合は、タイムアウト・ハンドラに指定されているアクションを処理するために、タイムアウト・ハンドラがデフォルトで起動されます。
-
通常、コール元は、100ミリ秒待機した後でコールバックを受信します。ただし、順次ルーティング・ルールと同期インタフェース・サービスへの接続を使用するブリッジ・メディエータがある場合は、ルーティング・ルールがすべて順次であるプログラムのフローが複雑となるため、コール元でのコールバックの受信準備にさらに時間がかかる場合があります。この問題は、ブリッジ・メディエータのルーティング・ルールをパラレルに変更することで回避できます。
非同期処理のタイムアウト時間を指定するには:
メディエータ・エディタの「ルーティング・ルール」セクションで、次のステップを実行します。
ノート:
ルーティング・ルールの数が多く、ルーティング・ルールの実行に要する時間がトランザクション・タイムアウトを超える場合は、トランザクション・タイムアウトの値を、すべてのルーティング・ルールの実行に要する時間より長い時間に設定する必要があります。
20.3.2.5 早すぎるコールバックの処理方法
コールバック・メッセージは、トランザクションの開始が完了する前に着信する場合があります。この場合、メディエータでの相関は失敗します。早すぎるコールバックの問題がある場合は、oracle.tip.mediator.callback.correlationWaitDuratino_in_secondsプロパティを使用して、コールバックを再試行する前にコールバック・スレッドが待機する期間(秒単位)を設定できます。
このプロパティは、composite.xmlファイル内のMediatorコンポーネントを定義するcomponent要素で定義します。次に示す例では、再試行前の待機時間は15秒です。
<component name="Mediator1">
<implementation.mediator src="Mediator1.mplan"/>
<property name="oracle.tip.mediator.callback.correlationWaitDuration_in_
seconds">15</property>
</component>
20.3.2.6 複数コールバックの処理方法
1つのメディエータで複数のコールバックを処理することはできません。複数のコールバックを受信するメディエータが含まれているコンポジット・アプリケーションがある場合、そのコンポジット・アプリケーションの動作は不明です。たとえば、図20-9に示したシナリオでは、AsyncMediatorがAsyncEchoMediator1およびAsyncEchoMediator2からのコールバック・レスポンスをFileInMediatorに転送します。このようなフローでは、AsyncMediatorは、AsyncEchoMediator1とAsyncEchoMediator2の両方からのコールバックを返すか、またはいずれか一方のコールバックを返す可能性があります。正確な動作はランダムであり、予測できません。
20.3.2.7 フォルトの処理方法
ターゲット・サービスの操作に1つ以上のフォルトがある新規ルーティング・ルールを作成する場合でも、メディエータ・エディタには、単一フォルトのルーティング・セクションが表示されます。ソース・メディエータ・サービス・コンポーネントが1つ以上のフォルトをサポートしている場合、デフォルトでは、フォルトはコール元に戻されます。ただし、ルーティングするソース・フォルト名およびターゲット・フォルト名を指定できます。サービス・ブラウザを使用して、フォルトを別のターゲットにルーティングすることもできます。
20.3.2.7.2 フォルト・ルーティング・セクションを削除するには:
メディエータ・エディタの「ルーティング・ルール」セクションで、次のステップを実行します。
-
図20-12に示すように、ターゲット・サービス・フィールドをクリックして削除するフォルト・ルーティングをハイライト表示し、「選択したフォルト・ルーティングを削除します。」をクリックします。
20.3.2.8 メッセージをフィルタリングする式の指定方法
フィルタ式ルーティング・ルールを使用すると、ペイロードに基づいてメッセージをフィルタリングできます。特定のメッセージ・インスタンスに対してフィルタ式が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"
20.3.2.8.1 メッセージをフィルタリングする式を指定するには:
式ビルダーを使用すると、フィルタ式をグラフィカルに作成できます。「式ビルダー」ダイアログには、フィルタ式の設計を支援するコンポーネントやコントロールが含まれています。
-
「ルーティング・ルール」セクションの「フィルタ式」フィールドの右側にある「式ビルダーの起動」アイコンをクリックします。
図20-13に示すように、「式ビルダー」ダイアログが表示されます。
-
「式」フィールドに値を追加するには、「変数」フィールドまたは「関数」パレットで、必要な値をダブルクリックします。変数要素、関数および手動で入力したテキストの組合せを使用して、このウィンドウで、特定のルーティング・ルールに対してメッセージ・ペイロードをフィルタリングする式を作成できます。
次の表で、「式ビルダー」ダイアログの各フィールドについて説明します。
表20-1 「式ビルダー」フィールド
フィールド 説明 式
このフィールドには、メッセージのフィルタに使用される実際の式が含まれます。フィルタ式は手動、または「変数」フィールドおよび「関数」パレットを使用して入力できます。
このフィールドの右上部に表示されている各アイコンを使用すると、最後に行った編集の取消し、最後に行った編集の再実行、または「式」フィールド全体のクリアを実行できます。
変数
このフィールドには、メディエータ・コンポーネントに対して定義されたメッセージが含まれます。Oracle JDeveloperはメディエータのWSDLファイルを解析し、メッセージ定義を「変数」フィールドに表示します。入力メッセージは
$in変数に格納され、$in.propertiesを使用して入力メッセージのプロパティにアクセスすることができます。入力メッセージが複数のパートで構成されている場合は、
$in.partnameを使用して、入力メッセージのパートにアクセスします。「関数」パレット
このリストには、式に挿入できる関数のリストが表示されます。関数を選択すると、その関数が「式」フィールドに追加されたときにどのように表示されるかを示すプレビューが「コンテンツのプレビュー」フィールドに表示され、その関数の説明が「説明」フィールドに表示されます。
コンテンツのプレビュー
このフィールドには、「変数」フィールドまたは「関数」パレットで選択した値が「式」フィールドに挿入されたときの表示状態で示されます。
説明
このフィールドには、「変数」フィールドまたは「関数」パレットで選択した値の説明が表示されます。
20.3.2.8.2 メッセージ・ペイロードのフィルタ式を指定するには:
-
「ルーティング・ルール」セクションの「フィルタ式」フィールドの右側にある「式ビルダーの起動」アイコンをクリックします。
「式ビルダー」ダイアログが表示されます。
-
「変数」フィールドで、メッセージ定義を開き、式の基になるメッセージ要素を選択します。
たとえば、図20-14で選択されたCustomerId要素が表示されます。
-
「式に挿入」をクリックします。
図20-15に示すように、式が「式」フィールドに追加されます。
-
「関数」リストから、メッセージ・ペイロードに適用する関数を選択します。たとえば、equalsを選択します。
関数は、「関数」リストの下矢印をクリックすると表示されるカテゴリ別にグループ化されます。たとえば、下矢印をクリックして「Logical Functions」を選択すると、図20-15に示すようにリストが表示されます。
-
「式に挿入」をクリックします。
選択した関数のXPath式が「式」フィールドに挿入されます。
-
式を完成します。
この例では、図20-16に示すように、顧客IDがtrueと評価されるには
1001である必要があります。 -
エラーが検出された場合、式は手動で編集するか、式の編集アイコンを使用できます。図20-17には、これらのアイコンがまとめられています。
-
「OK」をクリックします。
式が「ルーティング・ルール」セクションに追加されます。
フィルタ式の変更または削除は、「フィルタ式の追加」アイコンをダブルクリックし、「式ビルダー」の「式」フィールドで実行します。
20.3.2.9 ネイティブXSDフォーマットとXMLフォーマットとの間における変換方法
メディエータにより、インバウンド・データでは、ネイティブ・フォーマット・データをXMLデータに変換でき、アウトバウンド変換では、XMLデータをネイティブ・フォーマット・データに変換できます。そのため、たとえば、インバウンド変換を使用して、入力カンマ区切りネイティブ・データ・ファイルをXMLデータ・ファイルに変換できます。アウトバウンド変換を使用して、XMLデータをネイティブ・データ・フォーマットにターゲット・サービスで変換できます。
メディエータには次の変換機能があります。
-
インバウンド変換: インバウンド・データをネイティブ・データ・フォーマットからXMLに変換します。インバウンド変換は操作レベルで構成されます。変換されたデータは変換と割当ての操作で利用できます。
-
アウトバウンド変換: アウトバウンド・データをXMLからネイティブ・データ・フォーマットに変換します。アウトバウンド変換を各ルーティング・ルールで構成できます。ネイティブ・データはターゲット・サービスにルーティングされます。
-
変換とルーティングのみ: インバウンド・データをネイティブ・データ・フォーマットからXMLに変換し、ターゲット・サービスにルーティングします。アウトバウンドWSDLファイルがターゲット・サービスに対して作成されます。この機能は、一方向(レスポンスなし)操作を行うメディエータのみにサポートされています。
20.3.2.10 インバウンド変換を使用する方法
この項ではインバウンド変換を使用する方法について説明します。図20-18は、インバウンドWebサービスに接続したメディエータ(Mediator1)を示します。メディエータでネイティブ文字列をインバウンドWebサービスから受信し、インバウンド変換を使用してネイティブ文字列をXMLに変換します。
インバウンド・データをネイティブXSDからXMLフォーマットに変換するには:
- 「操作」セクションの下で、「ネイティブからの変換」フィールドの右側にあるアイコンをクリックします。図20-19に、Mediator1の「操作」セクションを示します。
- 入力文字列を「変数」ツリーでダブルクリックします。
string()関数で「式」フィールドに表示される入力文字列をラップ(キャスト)します。図20-20に、完了した入力文字列がある「式ビルダー」ダイアログを示します。「OK」をクリックします。 - スキーマを選択して「OK」をクリックします。「要素」フィールドは、選択スキーマから移入されます。「出力」フィールドは、メディエータにより作成される中間出力変数で移入されます。この変数は、
translateFromNative.out.some_name形式である必要があります。図20-21は、完了した「翻訳の追加」ダイアログを示しています。
20.3.2.11 アウトバウンド変換を使用する方法
この項ではアウトバウンド変換を使用する方法について説明します。図20-22は、BPELプロセスに接続したメディエータ(Mediator1)を示します。メディエータによりアウトバウンド変換を使用して、XMLデータをネイティブ文字列に変換し、この文字列をBPELプロセスにルーティングします。
アウトバウンド・データをXMLからネイティブXSDフォーマットに変換するには:
- データをメディエータからBPELプロセス(ターゲット・サービス)にルーティングするルーティング・ルールの下で、「ネイティブへの変換」フィールドの右側にあるアイコンをクリックします。図20-23に、Mediator1のルーティング・ルール・セクションを示します。
- 表示される「翻訳の追加」ダイアログで、「入力」フィールドのデフォルト入力変数をオプションで編集します。「入力」フィールドには、メディエータにより作成される中間入力変数が移入されます。この変数は、
translateToNative.in.some_name形式である必要があります。ノート:
関連するルーティング・ルールの割当てアクションや変換アクションを使用して、後で値を中間入力変数に割り当てることができます。
図20-24に、「翻訳の追加」ダイアログ・ボックスを示します。
- 出力文字列を「変数」ツリーでダブルクリックします。「OK」をクリックします。
20.3.2.12 XSLTトランスフォーメーションの作成方法
Oracle JDeveloperには、XSLTマッパーが用意されています。XSLTマッパーを使用すると、データをXMLスキーマ(XSDファイルで表されます)間で変換するためのマッパー・ファイル(XSLファイル)を指定できます。XSLTマッパーを使用することで、異なるスキーマを使用しているアプリケーション間でのデータ交換が可能になります。たとえば、受信する発注スキーマを、送信する請求書スキーマにマップできます。XSLファイルを定義した後は、そのファイルを複数のルーティング・ルール仕様で再利用できます。
20.3.2.12.1 トランスフォーメーションを作成するには:
-
「ルーティング・ルール」セクションで、「次を使用して変換」フィールドの右側にある「既存のマッパー・ファイルを選択するか、新規マッパー・ファイルを作成します。」アイコンをクリックします。「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。
-
次のいずれかを行います:
-
XSLTマップ・ファイル(.xsl)が存在する場合、「参照」をクリックして、使用するXSLTファイルを検索して選択します。「OK」をクリックします。
-
新しいXSLTマップ・ファイルを作成している場合は、「マッピングの作成」アイコンをクリックします。「トランスフォーメーション・マップの作成」ダイアログが表示されます。
-
-
「トランスフォーメーション・マップの作成」ダイアログで、「タイプ」の下で「XSLT」を選択します。
-
XSLTの「ファイル名」を適切に編集します。
-
XSLTの「ディレクトリ」を適切に編集します。デフォルト・ディレクトリは、
SOA_Project/SOA/Transformationsディレクトリです。「参照」をクリックして参照し、ディレクトリを選択します。 -
同期リプライ、コールバック・レスポンスまたはフォルト・メッセージに対して、前述のステップを繰り返します。
図20-26に示すように、同期リプライまたはフォルト・メッセージの場合、「リプライ・トランスフォーメーション・マップ」ダイアログまたは「フォルト・トランスフォーメーション・マップ」ダイアログには、「リクエストをリプライ・ペイロードに含める」オプションがあります。
-
同期相互作用の元のメッセージを含む
$initial変数を作成するには、「リクエストをリプライ・ペイロードに含める」オプションを選択します。図20-27に示すように、変数が作成されます。
ノート:
初期メッセージも複数のパートで構成されます。$initial.partnameを使用して、初期メッセージのパートにアクセスします。インバウンド・メッセージとアウトバウンド・メッセージのパートが同じ場合、データ交換にトランスフォーメーションは必要ありません。
XSLTマッパーの詳細は、「XSLTマップ・エディタを使用したトランスフォーメーションの作成」を参照してください。
20.3.2.12.2 ユーザー定義拡張関数を追加するには:
式ビルダーを使用すると、ユーザー定義拡張関数を含めることができます。
- プロジェクトの
.mplanファイルを、次のように変更します。-
拡張関数用に定義した関数ネームスペースを
Mediator要素の下に追加します。 -
関数名を
Expression要素に追加します。
これは、図20-28に示されています。
図20-28 プロジェクトの.mplanファイル – ユーザー定義拡張関数を使用するように変更済
「図20-28 プロジェクトの.mplanファイル – ユーザー定義拡張関数を使用するように変更済」の説明 -
20.3.2.13 XQueryトランスフォーメーションを作成する方法
Oracle Mediatorでは、複数のXMLスキーマ間のXQueryトランスフォーメーションがサポートされています。XQuery 1.0仕様がサポートされています。
20.3.2.13.1 XQueryトランスフォーメーションを作成するには:
-
「ルーティング・ルール」セクションで、「次を使用して変換」フィールドの右側にある「既存のマッパー・ファイルを選択するか、新規マッパー・ファイルを作成します。」アイコンをクリックします。「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。
-
次のいずれかを行います:
-
XQueryマップ・ファイル(.xqy)が存在する場合、「参照」をクリックして、使用するXQueryファイルを検索および選択します。「OK」をクリックします。
-
新しいXQueryマップ・ファイルを作成する場合、「マッピングの作成」アイコンをクリックします。「トランスフォーメーション・マップの作成」ダイアログが表示されます。
-
-
「トランスフォーメーション・マップの作成」ダイアログで、「XQuery」を「タイプ」の下で選択します。
図20-29に、「トランスフォーメーション・マップの作成」ダイアログを示します。
-
XQueryの「ファイル名」を適切に編集します。
-
XQueryの「ディレクトリ」を適切に編集します。デフォルト・ディレクトリは、
SOA_Project/SOA/Transformationsディレクトリです。「参照」をクリックして参照し、ディレクトリを選択します。 -
「外部変数」セクションの下で、外部変数をXQuery用に定義できます。「変数の追加」をクリックして、新しい外部変数を追加します。「外部変数の追加」ダイアログが表示されます。
ノート:
トランスフォーメーション入力として利用可能な暗黙メディエータ変数で外部変数が自動的に作成されます。たとえば、メディエータ入力リクエストの
in.requestは自動的に外部変数を持ちます。図20-30に、「外部変数の追加」ダイアログを示します。
-
外部変数の「名前」、「スキーマ」およびスキーマの「要素」を指定します。
-
「元」の下で、外部変数の値をマップする方法を選択します。次のいずれかから選択します。
-
プロパティ: 選択可能なプロパティがリストされます。
-
式: メディエータ暗黙変数、プロパティ、および式で使用できる関数のリストを使用して式を構築できます。「式ビルダーの起動」アイコンをクリックすると、式ビルダーを起動できます。
式ビルダーの使用方法の詳細は、「メッセージをフィルタリングする式の指定方法」および「の式ビルダーでのXPath式の構築」を参照してください。
-
定数: 外部変数のリテラル値を指定できます。
-
XMLフラグメント: 外部変数のXMLデータを指定できます。
-
-
「OK」を「外部変数の追加」ダイアログでクリックして、外部変数を追加します。「トランスフォーメーション・マップの作成」ダイアログは、外部変数で移入されます。
ノート:
外部変数を編集するには、リストから選択し「変数の更新」をクリックします。
外部変数を削除するには、リストから選択し「変数の削除」をクリックします。
-
「トランスフォーメーション・マップの作成」ダイアログで、「OK」をクリックします。「リクエスト・トランスフォーメーション・マップ」ダイアログが表示され、定義された外部変数と「マッパー・ファイル」名で移入されます。
図20-31に、「リクエスト・トランスフォーメーション・マップ」ダイアログを示します。
-
「リクエスト・トランスフォーメーション・マップ」ダイアログで、「OK」をクリックします。トランスフォーメーション・アクション詳細がメディエータのmplanファイルに追加されます。
20.3.2.13.2 XQueryトランスフォーメーションを編集するには:
-
「ルーティング・ルール」セクションで、「次を使用して変換」フィールドの右側にある「既存のマッパー・ファイルを選択するか、新規マッパー・ファイルを作成します。」アイコンをクリックします。「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。
ノート:
既存のXQuery (.xqy)マップで外部変数の追加や削除はできません。ただし、外部変数を選択して、「変数の更新」をクリックし、外部変数に関連する式や値を変更できます。
-
「マッパー・ファイル」フィールドの右側にある「マッピングの編集」アイコンをクリックします。XQueryマップがXQueryマッパーで開きます。
-
XQueryマッパーを使用する方法の詳細は、「XQueryマッパーを使用したトランスフォーメーションの作成」を参照してください。
20.3.2.14 値の割当て方法
メッセージのヘッダー、ペイロードおよびプロパティは、「値の割当て」フィールドを使用してソースからターゲットに伝播できます。図20-32に、「値の割当て」ダイアログを示します。このダイアログは、「ルーティング・ルール」セクションの「値の割当て」アイコンをクリックすると表示されます。
「値の割当て」ダイアログの左ペインにソース変数が含まれ、右ペインにターゲット変数が表示されます。値をソース変数からターゲット変数にコピーできます。また、複雑な式を作成してターゲット変数に割り当てることができます。また、リテラル(定数やXMLフラグメント)をターゲット変数に割り当てることができます。
「値の割当て」ダイアログの下部ペインに、作成した割当てが表示されます。割当ての選択と編集ができます。
20.3.2.14.1 ソース・ノードをターゲット・ノードにコピーするには:
-
ソース・ノードの横にあるプラス記号(+)をクリックして、左ペインのソース・ツリーを展開します。単純にターゲット・ツリーを右ペインで展開します。
-
次のいずれかの方法で、ソース変数をターゲット変数にコピーします。
-
適切なソース・ノードをターゲット・ノードにドラッグします。ソース・ノードとターゲット・ノードを接続する行が表示されます。割当ても下部ペインに表示されます。図20-33は、ソース・ノードをターゲット・ノードにコピーした後の「値の割当て」ダイアログを示します。
-
左ペインのソース・ノードと右ペインのターゲット・ノードを選択します。下部ペインの上にある「選択したノードからルールを作成」アイコン(緑のプラス・アイコン)をクリックして、割当てを作成します。
-
-
「OK」をクリックして割当てを作成します。
20.3.2.14.2 複雑な式を割り当てるには:
-
「ソース式の割当て」アイコンを右上隅からターゲット・ノードかキャンバス(中央ペイン)にドラッグします。「式ビルダー」が表示されます。
-
利用可能なソース変数と関数を使用して式を作成します。
必要に応じて「ヘルプ」をクリックして、「式ビルダー」ダイアログの詳細を参照してください。
-
「OK」をクリックして式ビルダーを閉じます。
-
ステップ1で式をキャンバスや中央ペインにドラッグした場合、式アイコンをキャンバスで適切なターゲット・ノードにドラッグします。これによって、式がターゲット変数にマップされます。
ノート:
割当てを編集するには、割当てを下部ペインで右クリックします。「ソース式の編集」または「ターゲット式の編集」を選択して、ソースやターゲットをそれぞれ編集します。
-
「OK」をクリックして割当てを作成します。
20.3.2.14.3 定数値とXMLフラグメントを割り当てるには:
-
「ソース・リテラルの割当て」アイコンを右上隅からターゲット・ノードかキャンバス(中央ペイン)にドラッグします。「ソース・リテラルの割当て」ダイアログが表示されます。
-
割り当てる定数値またはXMLフラグメントを入力します。
-
定数値が有効なXMLの場合、「リテラルはXMLフラグメントです」を選択します。
-
「OK」をクリックします。
-
ステップ1でソース・リテラルをキャンバスや中央ペインにドラッグした場合、ソース・リテラル・アイコンをキャンバスで適切なターゲット・ノードにドラッグします。これによって、ソース・リテラルがターゲット変数にマップされます。
ノート:
-
イベントの公開時に特定のメディエータ・プロパティに値を割り当てた場合、その値はサブスクライブするイベントに伝播されません。
この問題を回避するには、トランスフォーメーションを使用して、イベント本体の一部としてプロパティを含めます。
-
Oracle WebLogic Serverの
jca.db.userNameおよびjca.db.passwordプロパティに値を割り当てることはできません。これは、これらのデータ・ソースでは、getConnectionメソッドへのユーザー名またはパスワードの動的な設定がサポートされていないためです。
表20-2から表20-4に、メッセージの定数とプロパティ、ペイロードおよびヘッダーに関するソースからターゲットへの考えられる様々な割当てを示します。
表20-2 定数とプロパティの場合の考えられる割当て
| ソース | ターゲット | 例 |
|---|---|---|
|
プロパティ |
プロパティ |
|
|
定数 |
プロパティ |
|
表20-3 ペイロードの場合の考えられる割当て
| ソース | ターゲット | 例 |
|---|---|---|
|
XPath式 |
プロパティ |
|
|
XPath式(パート・レベルより下) |
プロパティ |
|
|
プロパティ |
XPath式(パート・レベルより下) |
|
|
定数 |
XPath式(パート・レベルより下) |
|
|
XPath式 |
XPath式 |
|
|
XPath式(パート・レベルより下) |
XPath式(パート・レベルより下) |
|
表20-4 ヘッダーの場合の考えられる割当て
| ソース | ターゲット | 例 |
|---|---|---|
|
XPath式(パート・レベルより下) |
プロパティ |
|
|
プロパティ |
XPath式(パート・レベルより下) |
|
|
定数 |
XPath式(パート・レベルより下) |
|
|
定数 |
XPath式(パート・レベルより下) |
|
|
XPath式 |
XPath式 |
|
|
XPath式(パート・レベルより下) |
XPath式(パート・レベルより下) |
|
20.3.2.15 assignアクティビティに関する必知事項
assignアクティビティについては、次の点に注意してください。
-
assignアクティビティは、
<copy>要素がメディエータのmplanに記述されている順序で実行されます。 -
割当ての順序は、「値の割当て」ダイアログの下部ペインで割当てを選択し、「上」または「下」矢印をクリックして割当てリスト内でその割当てを移動することで変更できます。
-
新しい割当てを作成する場合は、割当てリストの任意の位置に割当てを挿入できます。「値の割当て」ダイアログの下部ペインで既存の割当てを選択し、ダイアログの左上にあるリストから「新規ルールを後に挿入」または「新規ルールを前に挿入」を選択します。
-
「ネイティブからの変換」アクティビティからの出力変数および「ネイティブへの変換」アクティビティへの入力変数も、「値の割当て」ダイアログの割当てに対して使用できます。
-
「値の割当て」ダイアログの下部ペインに表示されるすべての割当ては、「OK」をクリックした後にのみメディエータのmplanに適用されます。
-
ソースがターゲットのプロパティに割り当てられている場合でも、そのソースの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が生成される可能性があります。次の例に詳細を示します。<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アクティビティによってターゲットが作成されます。次の例に詳細を示します。
<copy target="$out.request" expression="$in.body"/> <copy target="$out.header.inp1_header" expression="$in.header.inp1_header" xmlns:inp1="http://xmlns.oracle.com/psft"/>
-
ターゲット・ペイロードのいずれかの子ノードを変更する必要がある場合は、次のような2つのユースケースがあります。
-
トランスフォーメーションが使用可能な場合は、ターゲットの子ノードを指し示しているターゲットのXPath式にソース式を直接割り当てます。次の例に詳細を示します。
<copy value="ConstantModel" target="$out.request/inp1:request/ProductReq/Model" xmlns:inp1="http://xmlns.oracle.com/psft"/>
-
トランスフォーメーションが使用不可の場合は、次の2つのステップを実行します。最初に、ソース・パートをターゲット・パートに割り当て、次にターゲットの子ノードを指し示しているターゲットのXPath式にソース式を直接割り当てます。次の例に詳細を示します。
<copy target="$out.request" expression="$in.body"/> and <copy value="ConstantModel" target="$out.request/inp1:request/ProductReq/Model" xmlns:inp1="http://xmlns.oracle.com/psft"/>
-
-
ソースの子ノードの1つのみをターゲットに伝播する必要がある場合は、最初にトランスフォーメーションが起動されていないことを確認します。次に、必要な子ノードを指し示すソースのXPath式を割り当てます。次の例に詳細を示します。
<copy target="$out.request/imp1:ProductReq" expression="$in.body/imp1:request/ProductReq" xmlns:imp1="http://xmlns.oracle.com/psft"/>
このケースで、
$in.body/imp1:request/ProductReqから評価されるソース要素には、子ノードのみが含まれ、ルート要素から始まる完全なツリー構造は含まれていません。次の例に詳細を示します。<ProductReq> <Make>MAKE</Make> <Model>MODEL</Model> </ProductReq> -
メディエータに複数のassignアクティビティがあり、各ソースのXPath式が別々の子ノードを指し示している場合は、次のような2つのユースケースがあります。
-
トランスフォーメーションが使用可能な場合は、ターゲットの対応する子ノードが更新されます。
-
トランスフォーメーションが使用不可の場合、ターゲットは複数パートのターゲットであり、各パートがソースの子ノードを参照している必要があります。
-
-
ヘッダーの場合、
passThroughHeaderプロパティが設定されている場合は、次のようになります。-
トランスフォーメーションのヘッダー操作は、ターゲットのヘッダーで更新されます。
-
パート・レベルのassignアクティビティによって、ターゲットのヘッダー・パートが上書きされます。
-
パート・レベルより下のノードのassignアクティビティによって、ターゲットの対応するノードが更新されます。
-
-
(パート・レベルより下の)複数のソース・ノードが(パート・レベルより下の)同じターゲット・ノードに割り当てられている場合、そのターゲット・ノードには、assignアクティビティの最後の
copy要素の値が含まれます。次の例に詳細を示します。<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"/>
前の例で、最初の
copy要素は、2番目のcopy要素によって上書きされるため何も効果がありません。 -
XPath式の結果がリスト(複数発生)になる場合は、次の2つのユースケースがあります。
-
リストに単一の要素が含まれる場合は、XPath式が伝播されます。
-
リストに複数の要素が含まれる場合、XPath式はサポートされません。
-
-
ソースの子ノードをターゲットの子ノードに割り当てると、次のアクティビティが発生します。
-
ソースの子ノードの名前とネームスペースが、ターゲットのノード名とネームスペースによってそれぞれ上書きされます。
-
ターゲットの子ノードは、ターゲット・ノードの親ノードにあるソースの子ノードによって置換されます。
-
20.3.2.16 フィルタおよび割当てのためのヘッダー・アクセス方法
フィルタを定義するため、または割当てソースや割当てターゲットを定義するためにメディエータから式ビルダーを起動すると、WSDLファイルが解析されます。その際に、図20-34に示すように、現在のルーティング・ルール操作の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ファイルに追加されます。
たとえば、式ビルダーに次の例に示す式を入力するとします。
$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"
デフォルトでは、SOAPヘッダーはメディエータを介して渡されません。passThroughHeaderエンドポイント・プロパティを、対応するメディエータ・ルーティング・サービスに追加する必要があります。
<property name="passThroughHeader">true</property>
たとえば、このプロパティを追加するには、composite.xmlファイルを次の例に示すように変更できます。
<component name="Mediator1">
<implementation.mediator src="Mediator1.mplan"/>
<property name="passThroughHeader">true</property>
</component>
ヘッダーを渡すには、ソースとターゲットのQName(名前とネームスペース)が同じである必要があります。ソースとターゲットのQNameが異なる場合は、トランスフォーメーションまたはパートレベルの割当てのいずれかを実行する必要があります。
(トランスフォーメーションまたはassignを使用しない)passthroughメディエータの場合、ソースとターゲットのパートQNameが同じでない場合は、メディエータがメッセージ・ペイロードをターゲット・サービスに渡す際にエラーが発生していない点に注意する必要があります。ただし、この処理はターゲット・サービスでエラーになる場合があります。これは、メッセージ・ペイロードはターゲット・サービスのメッセージ構造に従って再構築されていないためです。
ノート:
-
このユーザー・インタフェースはSOAP 1.1およびSOAP 1.2の両方をサポートします。
-
自動ヘッダー検出のためには、メディエータ・サービス・コンポーネントの作成時に具体的なWSDLファイルを使用する必要があります。
-
割当てはフィルタの後に実行されます。このため、カスタム・ヘッダーで値を割り当てている場合、特定の割当てはフィルタに対して表示されません。
20.3.2.16.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"
20.3.2.17 セマンティク検証の使用方法
インバウンド・メッセージとその様々なパートは、Schematronファイルを指定して検証できます。Schematronバージョン1.5がサポートされているバージョンです。
Schematronスキーマを指定して、インバウンド・メッセージとその様々なパートを検証するステップは、次のとおりです。
セマンティク検証を使用するには:
20.3.2.18 添付の処理方法
プロジェクトのcomposite.xmlファイルにプロパティを追加することによって、メディエータが添付を処理する方法を構成できます。添付の処理の詳細は、「アタッチメント・ストリームの送信」および「での添付のパス・スルー設定のオーバーライド」を参照してください。
20.3.2.19 Javaコールアウトの使用方法
Javaコールアウトを使用すると、メディエータを介してフローするメッセージの操作に外部のJavaクラスを使用できます。操作またはイベント・サブスクリプションごとに、Javaコールアウトは1つのみサポートされます。コールアウト・クラスは、oracle.tip.mediator.common.api.IjavaCalloutインタフェースを実装する必要があります。コールアウトは、静的ルーティングおよび動的ルーティングの両方に使用できます。図20-37に、2つの操作が指定されたメディエータのサンプルを示します。2つの操作には、それぞれルーティング・ルールが1つあり、最初の操作にはコールアウト・クラスが指定されています。
20.3.2.19.1 Javaコールアウト・クラスを使用できるようにするには:
サーバーでJavaコールアウト・クラスが使用できることが必要です。このためには、次のいずれかの方法を使用します。
-
Javaクラスを
SCA-INF/classesフォルダにコピーします。 -
Javaクラスが含まれているJARファイルを
SCA-INF/libフォルダにコピーします。 -
複数のメディエータ・プロジェクトでカスタム・クラスを共有する場合:
-
カスタムJARを
<SOA_HOME>/soa/modules/oracle.soa.ext_11.1.1ディレクトリにコピーします。 -
ANTを実行します。
-
SOAサーバーを再起動します。
あるいは、次の手順を実行することもできます。
-
JARのパスを
<SOA_HOME>/soa/modules/oracle.soa.ext_11.1.1/oracle.soa.ext.jarのマニフェストに追加します。 -
SOAサーバーを再起動します。
-
oracle.soa.ext.jarを更新する必要があるステップは、soa/modules/oracle.soa.ext_11.1.1/readme.txtファイルを参照してください。
カスタム・クラスおよびJARファイルの追加の手順は、「カスタム・クラスおよびJARファイルの追加」を参照してください。
20.3.2.19.2 コールアウトのJavaクラスを入力するには:
Javaクラスを手動で入力するか、「クラス・ブラウザ」からクラスを選択できます。
-
図20-38に示すように、Javaコールアウト・クラスの名前を手動で入力するには、「コールアウト先」フィールドにクラス名を入力し始めます。Oracle JDeveloperのオートコンプリート機能によって、現在のプロジェクトのアドレスとクラスが挿入されます。
-
使用可能なクラスをリストから選択するには、「Javaコールアウト・クラスを選択します。」アイコンをクリックします。
図20-39に示すように、標準のOracle JDeveloperクラス・ブラウザが表示されます。
クラス・ブラウザは、
oracle.tip.mediator.common.api.IjavaCalloutインタフェースを実装するクラスのみが表示されるようにフィルタリングされます。
20.3.2.19.3 ペイロードのルート要素を設定するには(フィルタ式を使用している場合):
メディエータにJavaコールアウトがあり、同じメディエータでフィルタ式を使用している場合は、ペイロードのルート要素を次の例に示すように設定する必要があります。
changexmldoc = XmlUtils.getXmlDocument(ChangedDoc); String mykey = "request"; message.addPayload(mykey,changexmldoc.getDocumentElement());
20.3.2.19.4 ドメイン値マップと相互参照関数を有効にするには:
Javaコールアウトでドメイン値マップ関数または相互参照関数を使用するには、soa-xpath-exts.jarファイルをプロジェクトに追加し、コードに必要なJavaクラスをインポートする必要があります。
-
Oracle JDeveloperプロジェクト・エクスプローラで、Javaコールアウトを含むプロジェクトの名前を右クリックします。
-
「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログが表示されます。
-
図20-40に示すように、左側のパネルで、「ライブラリとクラスパス」を選択します。
-
「JAR/ディレクトリの追加」をクリックします。
図20-41に示すように、「アーカイブまたはディレクトリの追加」が表示されます。
-
エクスプローラ・ツリーで、ディレクトリを展開して
<JDEV_HOME>/jdeveloper/soa/modules/oracle.soa.fabric_11.1.1/soa-xpath-exts.jarを選択し、次に「選択」をクリックします。JARファイルが「クラスパス・エントリ」リストに表示されます。
-
「OK」をクリックします。
ノート:
ドメイン値マップ関数を使用する場合は、Javaクラスに次をインポートします。
-
oracle.tip.dvm.LookupValue -
oracle.tip.dvm.exception.DVMException
相互参照(xref)関数を使用する場合は、Javaクラスに次をインポートします。
-
oracle.tip.xref.xpath.XRefXPathFunctions -
oracle.tip.xref.exception.XRefException
20.3.2.19.5 メディエータのJavaコールアウトAPI
JavaコールアウトAPIでは、oracle.tip.mediator.common.api.IjavaCalloutおよびoracle.tip.mediator.common.api.CalloutMediatorMessageという2つのインタフェースを定義します。
表20-5では、oracle.tip.mediator.common.api.IjavaCalloutインタフェースのメソッドをリストして説明します。
表20-5 IjavaCalloutインタフェースのメソッドの説明
| メソッド | 説明 |
|---|---|
|
|
コールアウト実装クラスが初めてインスタンス化されるときに起動されます。 |
|
|
メディエータがケースの実行を開始する前にコールされます。このメソッドをカスタマイズすると、検証および拡張機能を組み込むことができます。 |
|
|
メディエータが特定のケースの実行を開始する前にコールされます。このメソッドをカスタマイズすると、ケース固有の検証および拡張機能を組み込むことができます。 |
|
|
メディエータがコールバック処理の実行を終了する前にコールされます。このメソッドをカスタマイズすると、コールバックの監査およびカスタムのフォルト・トラッキングを実行できます。 |
|
|
メディエータがケースの実行を終了した後にコールされます。このメソッドをカスタマイズすると、レスポンスの監査およびカスタムのフォルト・トラッキングを実行できます。 後処理メソッドは、すべての順次ルーティングが実行された後にコールされますが、パラレルのルーティング・ルールの完了は待機しません。 |
|
|
メディエータがケースの実行を開始した後にコールされます。このメソッドをカスタマイズすると、レスポンスの監査およびカスタムのフォルト・トラッキングを実行できます。 |
|
|
メディエータがコールバック処理の実行を終了した後にコールされます。このメソッドをカスタマイズすると、コールバックの監査およびカスタムのフォルト・トラッキングを実行できます。 |
ノート:
preRoutingRuleメソッドまたはpreRoutingメソッドで、Javaコールアウトを使用してメディエータのメッセージ・プロパティを変更した場合は、メディエータの割当て機能を使用して、変更したプロパティをアウトバウンド・メッセージに明示的にコピーする必要があります。たとえば、Javaコールアウトでjca.file.FileNameを変更している場合は、メディエータの割当て文を次のように更新する必要があります。
<assign> <copy target="$out.property.jca.file.FileName" expression="$in.property.jca.file.FileName"/> </assign>
表20-6で、CalloutMediatorMessageインタフェースのメソッドについて説明します。
表20-6 CalloutMediatorMessageインタフェースのメソッドの説明
| メソッド | 説明 |
|---|---|
|
|
メディエータ・メッセージのペイロードを設定します。 |
|
|
メディエータ・メッセージにプロパティを追加します。 |
|
|
メディエータ・メッセージにヘッダーを追加します。 |
|
|
プロパティ名を指定してメディエータ・メッセージのプロパティを取得します。 |
|
|
メディエータ・メッセージのプロパティを取得します。 |
|
|
メディエータ・メッセージのインスタンスIDを取得します。このインスタンスIDは、該当する特定のメッセージに対して作成されたメディエータ・インスタンスIDです。 |
|
|
メディエータ・メッセージのペイロードを取得します。 |
|
|
メディエータ・メッセージのヘッダーを取得します。 |
|
|
メディエータ・サービス・コンポーネントのcomponentDNを取得します。 |
ノート:
-
oracle.tip.mediator.common.api.AbstractJavaCalloutImplクラスは、IJavaCalloutインタフェースのダミー実装です。このクラスによって、IJavaCalloutインタフェースに存在するすべてのメソッドが定義されます。このため、このクラスの拡張によって、IJavaCalloutインタフェースのいくつかの特定メソッドのみをオーバーライドできます。インタフェースのダミー実装は、実装クラスによって、特定のインタフェースで宣言されているすべてのメソッドの定義が提供されることを意味しますが、空のメソッド本体を1つ以上の定義済メソッドに指定することはできます。ダミー実装クラスの拡張は、インタフェースを実装してすべてのメソッドを定義する場合と異なり、メソッドのサブセットのみをオーバーライドできるためより簡単です。
-
Javaコールアウト内で発生する処理の詳細は、メディエータの「監査証跡」画面には表示されません。
20.3.2.19.6 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.getDocumentElement());
//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.getDocumentElement());
// 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.getDocumentElement());
// 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;
}
}20.3.3 動的ルーティング・ルールの作成方法
動的ルーティングの基本的な考え方は、プロセスが経由するパスを決定する制御ロジックを、そのプロセスの実行から分離することです。動的ルーティングにより、メッセージの内容に基づいて、実行時にメッセージをメディエータから複数のターゲット・サービスに動的にルーティングできます。ドメイン値マップ(DVM)やデシジョン・コンポーネント(ビジネス・ルール)を使用すると、静的ルーティングを実行時にオーバーライドできます。
20.3.3.1 DVMを使用して静的ルーティング・ルールを動的にオーバーライドする方法
ドメイン値マップ(DVM)を使用すると、既存の静的ルーティング・ルールを動的にオーバーライドできます。新規DVMを作成したり、既存のDVMを使用すると、メディエータ・ルーティング・オプションをオーバーライドできます。
20.3.3.1.1 DVMを使用して静的ルートをオーバーライドするには:
-
メディエータ・コンポーネントをダブルクリックして、メディエータ・エディタを開きます。
-
「ルーティング・ルール」セクションの下で、変更するルーティング・ルールまで下にスクロールします。
-
「次を使用してオーバーライド」フィールドの右側で、緑色の矢印で識別されるボタンをクリックします。図20-42に、「次を使用してオーバーライド」フィールドを示します。
「ルーティングのオーバーライド」ダイアログが表示されます。
-
「ドメイン値マップの使用」を選択して、ドメイン値マップを作成したり使用します。図20-43に、「ルーティングのオーバーライド」ダイアログを示します。
-
「場所」フィールドの右側で、「新しいDVMファイルを作成します。」(緑のプラス(+)アイコン)をクリックし、新しいDVMファイルを作成します。ドメイン・マップ値の作成ダイアログが表示されます。
ノート:
また、「検索」アイコンで識別される「既存のDVMファイルを検索します。」をクリックすることで、既存のDVMファイルを選択できます。
-
ドメイン・マップ値の作成ダイアログで、「DVM名」を指定し、「ディレクトリ」を選択してDVMファイルを格納します。「OK」をクリックします。「DVMファイル作成済」ダイアログが表示されます。
-
「OK」をクリックして確定します。「ルーティングのオーバーライド」ダイアログが、新しいDVMの詳細で移入されます。新しいDVMを作成した後「ルーティングのオーバーライド」ダイアログが表示されます。
オーバーライド可能なメディエータの機能ごとに新規ドメインが作成されます。たとえば、図20-44に示すように、メディエータのフィルタ式でフィルタ・ドメインが作成されます。
-
DVMの参照列に対応する「キー・ドメイン」を選択します。
-
「値式」フィールドの右側で、「式ビルダーの起動」アイコンをクリックし、キー・ドメインに対応する値式を指定します。「式ビルダー」ダイアログが表示されます。
-
ドメイン・キーの値式に対応する式を構築して、「OK」をクリックします。式ビルダーの詳細を調べるには、「ヘルプ」ボタンを使用できます。
-
「ルーティングのオーバーライド」ダイアログで、「OK」をクリックします。
20.3.3.1.2 新規ドメインをDVMに追加するには:
-
「ルーティングのオーバーライド」ダイアログ(図20-44)で、「場所」フィールドの右側にある「DVMファイル・エディタを開きます」アイコンをクリックします。「メディエータ・オーバーライドDVMの編集」ダイアログが表示されます。図20-46は、「メディエータ・オーバーライドDVMの編集」ダイアログを示しています。
-
必要に応じて、DVMの「説明」と「名前」を編集します。
-
「マップ表」の下で、「ドメイン/値の追加」アイコン(緑のプラス(+)アイコン)をクリックします。ポップアップ・メニューが表示されます。
-
新しいドメインや列を追加するには、「ドメインの追加」を選択します。「ドメインの作成」ダイアログが表示されます。
-
新規ドメインの「名前」を指定します。「ドメインの作成」プロセスの詳細を調べるには、「ヘルプ」ボタンを使用します。
「OK」をクリックします
20.3.3.1.3 新規行をDVMに追加するには:
-
「ルーティングのオーバーライド」ダイアログ(図20-44)で、「場所」フィールドの右側にある「DVMファイル・エディタを開きます」アイコンをクリックします。「メディエータ・オーバーライドDVMの編集」ダイアログが表示されます(図20-46)。
-
「マップ表」の下で、「ドメイン/値の追加」アイコン(緑のプラス(+)アイコン)をクリックします。表示されるポップアップ・メニューから「ドメイン値の追加」を選択します。
-
それぞれの行項目をクリックすると編集できます。または、行を選択し、「ドメイン/値の編集」アイコンをクリックして行を編集します。「メディエータ・オーバーライド行の編集」ダイアログが表示されます。図20-47は、「メディエータ・オーバーライド行の編集」ダイアログを示しています。
-
必要に応じてフィールドを編集します。通常のメディエータ・ツールが編集支援で利用できます。たとえば、「変換」ドメインの隣にある「変換」ボタンをクリックすると、トランスフォーメーション・マップを作成できます。編集が完了したら、「OK」をクリックします。
20.3.3.2 デシジョン・コンポーネントを使用して静的ルーティング・ルールを動的にオーバーライドする方法
デシジョン・コンポーネントやビジネス・ルールを使用すると、既存の静的ルーティング・ルールを動的にオーバーライドできます。新規デシジョン・コンポーネントを作成したり、既存のデシジョン・コンポーネントを使用すると、メディエータ・ルーティング・オプションをオーバーライドできます。
20.3.3.2.1 デシジョン・コンポーネントを使用して静的ルートをオーバーライドするには:
-
メディエータ・コンポーネントをダブルクリックして、メディエータ・エディタを開きます。
-
「ルーティング・ルール」セクションの下で、変更するルーティング・ルールまで下にスクロールします。
-
「次を使用してオーバーライド」フィールドの右側で、緑色の矢印で識別されるボタンをクリックします。図20-48に、「次を使用してオーバーライド」フィールドを示します。
「ルーティングのオーバーライド」ダイアログが表示されます。
-
「デシジョン・コンポーネントの使用」を選択して、デシジョン・コンポーネントを作成したり使用します。
-
「デシジョン・コンポーネント」フィールドの右側で、「デシジョン・サービスの作成」(緑のプラス(+)アイコン)をクリックし、新しいデシジョン・サービス・コンポーネントを作成します。「デシジョン・サービスの作成」ダイアログが表示されます。
ノート:
また、「検索」アイコンで識別される「既存のデシジョン・サービス・コンポーネントを検索します。」をクリックすることで、既存のデシジョン・サービス・コンポーネント・ファイルを選択できます。
-
デシジョン・コンポーネントで「コンポーネント名」を指定し、サービスで「サービス名」を指定します。「OK」をクリックします。新しいデシジョン・サービス・コンポーネントが作成され、「ルーティングのオーバーライド」ダイアログに戻ります。ダイアログには、デシジョン・サービス・コンポーネントの詳細が格納されます。
このウィンドウで、新しいビジネス・ルール・サービス・コンポーネントが作成され、メディエータ・サービス・コンポーネントのSOAコンポジット内のメディエータ・サービス・コンポーネントに接続されます。
コンポジットの設計ビューを表示する場合、静的な参照接続に加えて、メディエータに接続されたビジネス・ルール・コンポーネントを表示できます。図20-49に、サンプル・コンポジットの設計ビューを示します。
ビジネス・ルール・サービス・コンポーネントには、ルール・ディクショナリが含まれています。ルール・ディクショナリは、ファクト・タイプ、ルールセット、ルール、デシジョン表など、ルール・エンジン・アーティファクトに対するメタデータ・コンテナです。ルール・ディクショナリは、ビジネス・ルール・サービス・コンポーネントの作成過程で、次のデータを使用して事前に初期化されます。
-
ファクト・タイプ・モデル
ファクト・タイプ・モデルは、ルールのモデル化に使用できるデータ・モデルです。ルール・ディクショナリには、BPELプロセスのphaseアクティビティの入力に対応するファクト・タイプ・モデルと、メディエータ・サービス・コンポーネントとビジネス・ルール・サービス・コンポーネント間の規定の一部として必要な固定データ・モデルの一部が移入されます。
-
ルールセット
ルールセットは、ルールのグループ化メカニズムとして使用されるルールのコンテナです。ルールセットはサービスとして公開できます。ビジネス・ルール・サービス・コンポーネントの作成過程で、1つのルールセットがルール・ディクショナリ内に作成されます。
-
デシジョン表(またはマトリックス)
ルール・エンジンから見ると、デシジョン表は、ルールの条件およびアクション部分のファクト・タイプ・モデルの要素が同じであるルールの集合です。デシジョン表を使用すると、ルールを表形式で表示できます。ビジネス・ルール・サービス・コンポーネントの作成過程で、ルールセット内に新規デシジョン表が作成されます。
-
デシジョン・サービス
デシジョン・サービスは、ビジネス・ルール・サービス・コンポーネントの作成過程で作成され、ルールセットをビジネス・ルール・サービス・コンポーネントのサービスとして公開します。メディエータ・サービス・コンポーネントでは、サービス・インタフェースを使用してデシジョン表を評価します。
-
20.3.3.2.2 デシジョン・コンポーネントを編集するには:
-
「ルーティングのオーバーライド」ダイアログ(図20-44)で、「デシジョン・コンポーネント」フィールドの右側にある「デシジョン・コンポーネント・エディタを開く」アイコンをクリックします。図20-50に示すようなデシジョン・コンポーネント・エディタが表示されます。
-
「デシジョン表」の下で、デシジョン表を選択し、「編集」をクリックし、デシジョン表を編集します。
デシジョン表とビジネス・ルールの使用の詳細は、「Oracle Business Rulesのスタート・ガイド」を参照してください。
20.3.4 動的ルーティング・ルールの使用に関する必知事項
メディエータで動的ルーティング・ルールを使用する場合は、次の制限に注意してください。
-
すべての指定可能メッセージ・パターン(同期、非同期、同期-非同期および一方向)がサポートされています。
-
イベントのパブリッシャおよびエコーは、関連付けられた動的ルーティング・ルールを持つことができません。
-
静的ルール・オーバーライドはリクエストに対してのみ適用されますが、レスポンスには適用されません。レスポンスをオーバーライドする必要がある場合、別のメディエータにルーティングし、リクエストとしてオーバーライドする必要があります。
-
ターゲット・ポートをオーバーライドする場合、オーバーライドするポートは同じポート・タイプである必要があります。
20.3.5 デフォルト・ルーティング・ルールの定義方法
メディエータでは、ルーティング・ルールで指定された条件に従ってメッセージが処理されます。ルーティング・ルールで指定されたいずれの条件も満たさないために、受信メッセージが処理されない場合もあります。このようなメッセージに使用するデフォルト・ルーティング・ルールを定義できます。デフォルト・ルーティング・ルールは、他のルーティング・ルールの条件がいずれも満たされない場合に実行されます。
デフォルト・ルーティング・ルールは、「静的ルーティング・ルールの作成方法」で説明したルーティング・ルールと同じです。デフォルト・ルーティング・ルールが他のルーティング・ルールと異なる唯一の点は、デフォルト・ルーティング・ルールには関連する条件がないことです。それ以外は、ターゲット・サービス、レスポンス処理、フォルト処理などすべてにおいて、デフォルト・ルーティング・ルールは他のルーティング・ルールと同じです。
ノート:
-
デフォルト・ルールは、静的ルーティング・ルールに対してのみ使用できます。
-
動的ルーティング・ルールを使用するメディエータ・サービス・コンポーネントにデフォルト・ルーティング・ルールを指定することはできません。これは、同じメディエータ・サービス・コンポーネントに静的ルーティング・ルールと動的ルーティング・ルールの両方を定義することはできないためです。
20.3.5.1 デフォルト・ルールのシナリオ
デフォルト・ルーティング・ルールは、順次ルールまたはパラレル・ルールのいずれかに設定できます。順次またはパラレルに関係なく、デフォルト・ルーティング・ルールは、他のルーティング・ルールの条件が満たされない場合に実行されることが保証されています。デフォルト・ルールが実行された場合、メディエータの監査証跡には、すべてのルーティング・ルールのフィルタ条件が満たされず、デフォルト・ルーティング・ルールのフィルタ条件が満たされて実行されたことが示されます。次の例に詳細を示します。
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
デフォルト・ルーティング・ルールも含めて、すべてのルーティング・ルールは順次またはパラレルのルーティング・ルールとして定義できるため、想定されるルーティング・ルールの動作は多数あります。次の各項では、各組合せと想定される動作について説明します。
順次のデフォルト・ルーティング・ルール
順次のデフォルト・ルーティング・ルールでは、次のシナリオが考えられます。
-
メディエータの他のルーティング・ルールがすべて順次の場合: これは、デフォルト・ルーティング・ルールも含めて、すべてのルーティング・ルールのタイプが順次である最も単純なケースです。すべてのルーティング・ルールのフィルタ条件が実行時に評価され、いずれのフィルタ条件も一致しない場合は、順次のデフォルト・ルーティング・ルールが実行されます。順次のデフォルト・ルーティング・ルールは、受信メッセージと同じトランザクションで実行されます。デフォルト・ルールの実行後に、事後Javaコールアウトが発生します。
-
メディエータのルーティング・ルールの少なくとも1つがパラレルである場合: これは、デフォルト・ルーティング・ルールが順次であり、他のルーティング・ルールの少なくとも1つがパラレルである複雑なケースです。実行時のデフォルトの動作では、最初に順次ルーティング・ルールがすべて実行された後で、パラレルのルーティング・ルールが実行されます。したがって、デフォルト・ルールは、他のすべてのルーティング・ルールがfalseであると評価された後でのみ実行する必要があるため注意が必要です。
この場合、サーバーでは、最初にパラレル・ルールのフィルタ条件が評価された後でデフォルト・ルーティング・ルールのフィルタ条件が評価されます。他のいずれのフィルタ条件も一致しない場合は、順次のデフォルト・ルーティング・ルールが実行されます。
パラレルのデフォルト・ルーティング・ルール
パラレルのデフォルト・ルーティング・ルールでは、次のシナリオが考えられます。
-
メディエータの他のルーティング・ルールがすべてパラレルの場合: これは簡単なケースです。デフォルト・ルーティング・ルールは、他のルーティング・ルールで指定されたいずれかのフィルタ条件が一致する場合は実行されません。フィルタ条件がいずれも一致しない場合は、デフォルト・ルーティング・ルールが非同期で実行されます。
-
メディエータの他のルーティング・ルールが順次またはパラレルである場合: これは複雑ですが一般的なユースケースです。使用可能な他の順次またはパラレルのルーティング・ルールがあり、デフォルト・ルーティング・ルールがパラレルの場合です。デフォルト・ルーティング・ルールは、他の順次またはパラレルのルーティング・ルール基準のいずれかが一致した場合は実行されません。条件がいずれも一致しない場合は、デフォルト・ルーティング・ルールが非同期で実行されます。
ノート:
デフォルト・ルーティング・ルールが自動的に実行されるということは、デフォルト・ルーティング・ルールが、特定のメディエータ・サービス・コンポーネントに対して実行された唯一のケースであることを意味します。同様に、メディエータ・サービス・コンポーネントに、フィルタ条件が指定されていない1つのルーティング・ルールがあり、デフォルト・ルーティング・ルールもある場合、そのデフォルト・ルーティング・ルールが実行されることはありません。
20.3.5.2 デフォルト・ルールのターゲット
デフォルト・ルーティング・ルールのターゲットは、他の既存ルーティング・ルールのサポートされているターゲットと同じです。つまり、ターゲットにはサービス、イベントまたはエコーを設定できます。同様に、デフォルト・ルーティング・ルールのターゲット・サービスからのレスポンスは、コール元に転送するか、返すことができます。ターゲット・サービスからフォルトが返された場合は、他のルーティング・ルールで処理される場合と同様に処理されます。
ノート:
他のルーティング・ルールの評価または実行時に例外が発生した場合、デフォルト・ルーティング・ルールは実行されません。
20.3.5.3 デフォルト・ルール: 検証、トランスフォーメーションおよび割当て機能
デフォルト・ルーティング・ルールのSchematron検証、トランスフォーメーションおよび割当機能は、他のルーティング・ルールと同様に動作します。
20.3.5.4 デフォルト・ルール: Javaコールアウト
事前Javaコールアウトまたは事後Javaコールアウトの現在の動作は、他のルーティング・ルールの場合と同様です。Javaコールアウト場合は、デフォルト・ルーティング・ルールは別のルーティング・ルールとみなされます。したがって、デフォルト・ルーティング・ルールが実行されるシナリオの場合、postRouting()コールバック・メソッドは、デフォルト・ルーティング・ルールが実行された後でのみ発生します。
ノート:
事後Javaコールアウトは、順次ルールの実行後に発生し、パラレル・ルールの実行の完了は待機しません。したがって、デフォルト・ルーティング・ルールが順次の場合、postRouting()コールバック・メソッドは、デフォルト・ルーティング・ルールの実行後に発生します。デフォルト・ルーティング・ルールがパラレルの場合、postRouting()コールバックは、すべての順次ルールが実行された後に発生し、パラレルのデフォルト・ルーティング・ルールの実行は待機しません。
