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