| Oracle® Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ 11gリリース1(11.1.1.6.2) B61433-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ 11gリリース1(11.1.1.6.2) B61433-05 |
|
前 |
次 |
この章では、Oracle Service Busのサービス・コンポジション機能について説明します。サービス構成を可能にする操作機能、メッセージ構造とメッセージ・フローの作成に関連する主要な概念について取り上げます。統合を目的とするIT設計者で、メッセージングとサービス指向アーキテクチャ(SOA)の担当者、サービス・モデル作成者または設計者を対象としています。
この章の内容は以下のとおりです。
Oracle Service Busは種類の異なるサービス・エンドポイント間でサービス・リクエストとレスポンス・メッセージを仲介し、これらの間でメッセージをインテリジェントにルーティングします。コンテンツ・ベースのルーティングは、Oracle Service Busが条件付きメッセージの処理と変換機能に基づいてサポートする仲介機能です。このルーティング機能により、SOAのエンドポイントを疎結合できるのが特に有益であり、また変換とルーティング機能を組み合せることによってサービスへの情報の付加と再利用を可能にします。
Oracle Service Busでは、サービスまたはレスポンスを複数の宛先サービスに転送する必要がある場合や、異なるバージョンのサービスをビジネス・サービスのリクエストに基づいてプロビジョニングする必要があるシナリオでは、メッセージのコンテンツに基づいた動的なメッセージのルーティングを行います。動的なルーティングは、ビジネス要件によって、リクエストの特定の条件により処理を行う場所が指定される場合に有効です。たとえば、金融機関が顧客の信用に関するレポートをリクエストするときは、その顧客または組織がある場所に基づいて複数の信用サービスを使用することになります。
動的なルーティングでは、ルーティングのロジックを決定する1つまたは複数のデータ要素の値を取得するために、メッセージは条件付きブランチ文の条件チェックを使用して分析されます。この条件チェックの結果、異なる値の組合せに、異なるビジネス・サービスの宛先が割り当てられます。メッセージは、このデータ要素の値に基づいて、複数の宛先ビジネス・サービスのいずれか1つに動的にルーティングされます。ビジネス・サービスの要件に応じて、これらの1つまたは複数の宛先に向かうレスポンス・メッセージに変換が適用されることがあります。
Oracle Service Busでは、ビジネス・サービス(エンタープライズ・サービスやデータベースなど)とサービス・クライアント(プレゼンテーション・アプリケーションやその他のビジネス・サービスなど)との間でプロキシ・サービスを介してメッセージをルーティングします。次の項では、コンテンツ・ベースのルーティングをサポートするプロキシ・サービスの設計と実装に利用できるOracle Service Busの機能について詳しく説明します。
プロキシ・サービスとは、Oracle Service Busでローカルにホストされる汎用の仲介Webサービスを定義したものです。プロキシ・サービスはITインフラストラクチャ内の他のサービスとインタフェースを通じて通信しますが、このインタフェースはサービス・プロバイダやサービス・コンシューマのビジネス・サービスと同一である場合も、同一でない場合もあります。プロキシ・サービスでは、構成済の独立したインタフェースを使用して、メッセージを複数のビジネス・サービスにルーティングできます。プロキシ・サービスの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のプロキシ・サービス: 作成および管理に関する項を参照してください。
プロキシ・サービスはOracle Service Bus管理コンソールを使用して定義と構成を行うことができます。プロキシ・サービスは、インタフェース、使用するトランスポートのタイプ、関連付けられるメッセージ処理ロジックを指定することで構成されます。プロキシ・サービスのメッセージ処理機能は、メッセージ・フローの定義を使用して実装されます。メッセージ・フローの定義の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「Oracle Service Busでのメッセージ・フローのモデリング」を参照してください。
プロキシ・サービスが複数のビジネス・サービスとのインタフェースを行う場合、メッセージ・フローの定義は、メッセージが適切なビジネス・サービスにルーティングされ、メッセージ・データがビジネス・サービスのインタフェースで必要なフォーマットにマップされるように構成されます。プロキシ・サービスの構造の詳細は、5.2項「メッセージ・フローの作成」を参照してください。
ビジネス・サービスとは、ビジネス・プロセスにおいてメッセージを交換するエンタープライズ・サービスのOracle Service Busによる定義です。ビジネス・サービスとそのインタフェースは、Oracle Service Bus管理コンソールを使用して定義および構成できます。ビジネス・サービスを構成するには、インタフェース、使用するトランスポートのタイプ、セキュリティ要件、およびその他の特性を指定します。ビジネス・サービスの定義はプロキシ・サービスと似ていますが、パイプラインを持ちません。Oracle Service Bus管理コンソールを使用して、ビジネス・サービスを構成する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のビジネス・サービスの作成および管理に関する項を参照してください。
サービス・アカウントは、ビジネス・サービスに接続するときに認証を提供するために作成できます。サービス・アカウントは要求されるユーザー名とパスワードのペアの別名リソースとして機能します。Oracle WebLogic Serverを使用して、資格証明レベルの検証を要求するビジネス・サービスのセキュリティ資格証明を直接管理できます。ビジネス・サービスのセキュリティに関する考慮事項については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。
Oracle Service Busには、任意のSOAPまたはXMLメッセージを受け入れる汎用のプロキシ・サービスを作成する機能があります。これにより、背後にあるプロトコル仕様の複雑さをサービス・コンシューマから隠すことができます。プロキシ・サービスは、受信するSOAPまたはXMLメッセージを分析して、コンテンツ・ベースのルーティング・ロジックによって動的にルーティングするように構成できます。汎用テンプレートからプロキシ・サービスを生成すると、動的なプロトコルの切替えも促進されて、実行時にエンドポイント・プロトコルを選択することができます。
メッセージ・フローとは、Oracle Service Busでプロキシ・サービスの実装に使用される定義です。メッセージ・フローの作成には、プロキシ・サービスのメッセージ・フローの定義におけるメッセージ処理ロジックの構成が関係します。このロジックには、変換、パブリッシュ、レポート、例外管理などのアクティビティが含まれます。各アクティビティは個別のアクションとしてメッセージ・フロー内に構成されます。EclipseとOracle Service Bus管理コンソールではグラフィカルなモデリング・ツールが使用でき、このツールでメッセージの作成を行うことができます。
Oracle Service Busのプロキシ・サービスの実装はメッセージ・フローの定義において、パイプラインやブランチ・ノード、ルート・ノードなどのコンポーネントを使用して定義されます。次の図は、メッセージ・フロー定義のコンポーネントの概要を示しています。
メッセージ・フローの作成の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「Oracle Service Busでのメッセージ・フローのモデリング」を参照してください。
パイプラインとは、分岐のない一方向の処理の流れを表す名前付きのステージ・シーケンスです。パイプラインは、サービスのリクエストとレスポンスに対するメッセージ・フローを指定するために使用します。パイプラインは次の3つのカテゴリに分類できます。
リクエスト・パイプライン: メッセージ・フローのリクエスト・パスの処理に使用されます。
レスポンス・パイプライン: メッセージ・フローのレスポンス・パスの処理に使用されます。
エラー・パイプライン: エラー・ハンドラとして使用されます。
ステージにある1つのサービス・レベル・リクエスト・パイプラインは、必要に応じて複数のオペレーション・パイプラインに分岐することができます(1つのオペレーションに対して最大1つのオペレーション・パイプラインと、必要に応じてデフォルトのオペレーション・パイプライン)。オペレーションはユーザーが選択する条件によって決定されます。レスポンス処理は関連するオペレーション・パイプラインから開始され、1つのサービス・レベル・レスポンス・パイプラインに結合されます。次の図に、プロキシ・サービスのオペレーション・パイプラインの例を示します。
一方向のオペレーションでは、レスポンス・パイプラインは空のメッセージで実行されます。これにより、プロキシ・サービスにレスポンスを作成でき、双方向(リクエスト/レスポンス)と一方向のオペレーションの間のブリッジングが可能になります。ブリッジング・メカニズムとは、プロキシ・サービスの入力が一方向であっても、出力は双方向(リクエスト/レスポンス)になること(またはその逆)を意味します。プロキシ・サービスは、呼び出したサービスからのレスポンスを取得するか、クライアントへのレスポンスを生成します。メッセージがビジネス・サービスまたはプロキシ・サービスにルーティングされてから、レスポンス・フローのアクションを使用してメッセージの後処理を実行することもできます。
ブランチ・ノードを使用すると、可能ないくつかのパスのうちの1つに限定して処理を進ませることができます。ブランチ処理は、単純でありながらユニークなストリング値のタグが付いたブランチをまとめた簡単なルック・アップ表を基準に行われます。メッセージ・コンテキストの変数をそのノードのルック・アップ変数として指定し、この値を使用してどのブランチに進むかが判断されます。ルック・アップ変数に一致するブランチがない場合は、デフォルトのブランチに進みます。ルック・アップ変数の値は、ブランチ・ノードに到達する前に設定する必要があります。このアプローチにより、そのブランチ・ノード自体の中での例外の発生を防ぐことができます。ブランチ・ノードでは、メッセージ・フロー・ツリー内にいくつかの子孫を持つことができます(デフォルトのブランチを含め各ブランチに1つずつ)。
ルート・ノードは他のサービスとのリクエスト通信とレスポンス通信に使用されます。ルート・ノードはプロキシ・サービスのリクエスト処理とレスポンス処理の境界を表すので、メッセージ・フロー・ツリー内に子孫を持つことはできません。ルート・ノードがリクエスト・メッセージをディスパッチすると、リクエスト処理が終了したとみなされます。ルート・ノードがレスポンス・メッセージを受信したときに、レスポンス処理が始まります。
ルート・ノードの仕様には非常に柔軟性があり、アウトバウンド変換、レスポンス変換、および条件付きルーティングに対応します。if構造とcase構造を結合(およびネスト)することができ、メッセージをルーティングするための単一のエンドポイントおよびオペレーションを定義できます。ルート・ノードの構成の方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のメッセージ・フローへのルート・ノードの追加に関する項を参照してください。
エコー・ノードはリクエスト・パイプラインの末尾からレスポンス・パイプラインの先頭にメッセージをルーティング(エコー)するルート・ノードです。メッセージは、プロキシ・サービスから別のサービスへルーティングされずに、プロキシ・サービス内に留まります。
パイプライン・ロジックは、「リクエスト・パイプライン」定義と「レスポンス・パイプライン」定義で構成される1組の定義です。リクエスト・パイプライン定義は、ビジネス・サービスまたは別のプロキシ・サービスを呼び出す前に、プロキシ・サービスへのリクエスト・メッセージに対してOracle Service Busが実行するアクションを指定します。レスポンス・パイプライン定義は、プロキシ・サービスがレスポンスを返す前に、プロキシ・サービスによって呼び出されたサービスからのレスポンスに対してOracle Service Busが実行する処理を指定します。ルーティングは、メッセージ・フローの最後にルート・ノードによって実行されます。
リクエスト・パスおよびレスポンス・パスを作成するには、リクエスト・パイプラインとレスポンス・パイプラインを合わせてペアにして、単一ルートのツリー構造に編成します。ブランチ・ノードを使用すると、これらのパイプライン・ペアを条件付きで実行して、ブランチ末尾のルート・ノードでリクエストとレスポンスのディスパッチを実行できます。パイプライン・ツリーは、パイプライン・ペア・ノード、ブランチ・ノード、ルート・ノード、またはエコー・ノードの最上位コンポーネントのインスタンスを連鎖させます。
パイプライン・ペア・ノードは、1つのリクエスト・パイプラインと1つのレスポンス・パイプラインを1つの最上位要素に結び付けたものです。リクエストの処理中にはリクエスト・パイプラインのみが実行され、レスポンス処理のためにパスを逆に辿るときにはレスポンス・パイプラインのみが実行されます。
各パイプラインは、アクションを含む一連のステージで構成されます。1つのステージは、変換やパブリッシュなどの、ユーザーが構成する処理手順です。メッセージ・フローに送られるメッセージには、メッセージのコンテンツを含む一連のメッセージ・コンテキスト変数が付けられ、パイプライン・ステージのアクションによってアクセスしたり変更することができます。
次の表に、Oracle Service Busのパイプライン・ステージ、ブランチ、およびルート・ノードでサポートされるアクションを示します。構成方法など、アクションの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「プロキシ・サービス: アクション」を参照してください。
表5-1 Oracle Service Busの通信アクション
| アクション | 説明 |
|---|---|
|
動的にパブリッシュ |
Xquery式によって識別されたサービスにメッセージをパブリッシュします。 |
|
パブリッシュ |
静的に指定されたサービスにメッセージをパブリッシュします。 |
|
パブリッシュ表 |
ゼロまたはそれ以上の静的に指定されたサービスにメッセージをパブリッシュします。切替え式の条件ロジックを使用して、どのサービスをパブリッシュに使用するか実行時に決定します。 |
|
ルーティング・オプション |
アウトバウンド・リクエストのURI、サービスの品質、モード、および再試行パラメータの一部またはすべてを変更します。 |
|
サービス・コールアウト |
Oracle Service Busに登録済みのプロキシ・サービスまたはビジネス・サービスの同期(ブロック)コールアウトを構成します。 |
|
トランスポート・ヘッダー |
メッセージのトランスポート・ヘッダーの値を設定します。 |
表5-2 Oracle Service Busのフロー制御アクション
| アクション | 説明 |
|---|---|
|
For Each |
一連の値の反復処理およびアクションのブロックを実行します。 |
|
If... Then... |
XQuery式のブール結果に基づき、1つまたは複数のアクションを条件付きで実行します。 |
|
エラーを発生させる |
指定したエラー・コードと説明を使用して例外を発生させます。 |
|
返信 |
呼出し元に即時に返信されるように指定します。成功時または失敗時の返信を選択できます。 |
|
再開 |
エラー・ハンドラによってエラーが処理された後、メッセージ・フローを再開します。 |
|
スキップ |
実行時に現在のステージの実行がスキップされて、処理がメッセージ・フローの次のステージに進むように指定します。 |
表5-3 Oracle Service Busのメッセージ処理アクション
| アクション | 説明 |
|---|---|
|
割当て |
コンテキスト変数にXQuery式の結果を割り当てます。 |
|
削除 |
コンテキスト変数や、XPath式で指定されたノードのセットを削除します。 |
|
挿入 |
XPath式で選択したノードを基準に、指定した位置にXQuery式の結果を挿入します。 |
|
Javaコールアウト |
パイプラインからJavaメソッドを呼び出します。 |
|
MFL変換 |
パイプラインで非XMLからXML、またはXMLから非XMLに変換します。 |
|
名前変更 |
コンテンツを変更せずに、XPath式で選択した要素の名前を変更します。 |
|
置換 |
XPath式で指定されたノードまたはノードのコンテンツを置換します。 |
|
検証 |
XMLスキーマ要素またはWSDLリソースに対して、XPath式で選択した要素を検証します。 |
メッセージ・フローは通常WSDLベースのサービスで使用されるため、操作に固有の処理は頻繁に実行されます。Oracle Service Busでは、操作に基づくブランチ・ノードを手動で構成する必要はなく、自動的にブランチ処理を行う構成不要のブランチ・ノードが用意されています。つまり、サービス・エンドポイントでオペレーション・ブランチが構成されていないと、メッセージの処理はメッセージ・コンテキストで指定された操作に基づいて自動的に適切な操作にブランチ処理が行われます。
Oracle Service Busには、より洗練されたメッセージ・フローを実現して高い柔軟性を提供するサービス・コールアウト・アクションが用意されています。サービス・コールアウトは、Oracle Service Busに登録されている他のサービスを呼び出す、メッセージ・フローからのメッセージ処理のリクエスト・アクションです。このアクションは一般に、複雑な動的ルーティング処理で行われる判断へのレスポンスで使用されるか、またはメッセージへの情報の追加を実行するために使用されます。サービス・コールアウト・アクションはメッセージ・フローのルーティング・ステージ内で使用され、メッセージについての何らかのアクションを実行するために宛先のサービスを呼び出します。呼び出されたサービスはメッセージ・フローにレスポンスを返し、これはローカル変数に割り当てられます。この変数は現在のメッセージ・フロー内で条件付きブランチのために使用されます。
サービス・コールアウト機能については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「Oracle Service Busでのメッセージ・フローのモデリング」にあるサービス・コールアウト・メッセージの作成に関する項を参照してください。
サービス・コールアウトを使用すると、カスタムJavaコードをプロキシ・サービス内から呼び出すことができます。Oracle Service Busでは、POJO (Plain Old Java Object、通常の従来型Javaオブジェクト)へのコールアウトを可能にするJavaコールアウト・アクションを使用したJava終了メカニズムがサポートされます。POJOからは静的メソッドにアクセスすることが可能です。POJOおよびそのパラメータは、設計時にOracle Service Bus管理コンソールに表示されます。このパラメータは、メッセージ・コンテキスト変数にマップできます。POJOへのJavaコールアウトの構成については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のJavaコールアウト・アクションの追加に関する項を参照してください。
変換は、ソースと宛先のサービスで種類の異なるメッセージのデータ型が存在し、サービスの互換性を保つためにデータのマッピングが必要となる場合に使用されます。Oracle Service Busは、XQueryおよびeXtensible Stylesheet Language Transformation (XSLT)標準を使用したデータ・マッピングに対応しています。メッセージは、次の2とおりの方法で変換されます。
メッセージ構造の再フォーマットにXQueryまたはXSLTを使用します。
特定のデータ要素を追加、削除、または置換することで、メッセージのコンテンツを操作します。
変換は開発者によって外部で作成され、Oracle Service Busにインポートされるか、またはOracle Service Bus管理コンソールのXQueryを使用してスクリプトが作成されます。変換はプロキシ・サービスのメッセージ・フロー構成に応じて、様々な場所で発生します。
Oracle Service Busにおけるメッセージ・フローは、プロキシ・サービスの実装を定義します。Oracle Service Bus管理コンソールでOracle Service Busのプロキシ・サービスを構成します。この方法は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』に説明されています。
Oracle Service Busは、XQueryおよびeXtensible Stylesheet Language Transformation (XSLT)標準を使用したデータ・マッピングに対応しています。XSLTマップは、XMLからXMLへのマッピングを記述するのに対して、XQueryマップでは、XMLからXML、XMLから非XML、非XMLからXMLへのマッピングを記述できます。変換の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のメッセージ・フローでの変換の実行に関する項を参照してください。
詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「XQuery変換」および「XSL変換」を参照してください。Oracle XQuery Mapperを使用してXQueryを作成する方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。
変換マップは、2つの互換性のないデータ型の間のマッピングを記述したものです。Oracle Service Busは、XQueryまたはeXtensible Stylesheet Language Transformation (XSLT)標準のどちらかを使用したデータ・マッピングに対応しています。XSLTマップは、XMLからXMLへのマッピングを記述するのに対して、XQueryマップでは、XMLからXML、XMLから非XML、非XMLからXMLへのマッピングを記述できます。また、MFLで記述されたデータは自動的に同等のXMLに変換され、XQueryまたはXSLTでの変換で使用できます。ターゲット・サービスで必要な場合、結果のXMLは自動的にMFLに変換されます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「XQuery変換」および「XSL変換」を参照してください。Oracle XQuery Mapperを使用してXQueryを作成する方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。
メッセージ操作は変換の一種で、メッセージの構造全体ではなくメッセージのコンテンツを操作して、メッセージを宛先のサービスと互換性のあるものにします。これは、メッセージ・フローのリクエスト・パイプラインまたはレスポンス・パイプラインに対して、追加、置換、または削除アクションを実行することによって行われます。コンテンツの操作によってメッセージを変換する場合に使用可能なアクションを次の表に示します。
| アクション | 説明 |
|---|---|
|
挿入 |
メッセージにデータ要素を挿入します。この挿入は構成中に、メッセージ・コンテキストの指定された任意の場所で、発生する可能性があります。 |
|
削除 |
メッセージからデータ要素を削除します。これは、目的の宛先でメッセージの特定のデータ要素が必要でない場合に使用されます。 |
|
置換 |
メッセージ内の一連のテキストを別のテキストで置換します。これは、たとえば、メッセージのネームスペースを置換するときに使用されます。 |
Oracle Service Busには構成されたサービスに対する堅牢で柔軟性のあるエラー処理が用意されています。エラーは次の方法で処理されます。
アサーションがtrueであることをテストし、リクエスト・パイプラインまたはレスポンス・パイプラインに失敗時の返信を送信します。
ステージ、ルート・ノード、パイプライン、またはサービス・レベルを含む複数のレベルでエラーを捕捉して処理できるようにサービスを構成します。エラーを捕捉するために構成されるレベルは、必要なサービスの動作によって変わります。
デフォルトのシステム・エラー・ハンドラでエラーを処理します。
Oracle Service Busには、検証アクションを使用して、着信または発信するメッセージをWSDLまたはXMLスキーマに対して検証する機能が用意されています。このアクションは、メッセージ・フロー内でいつでも発生する可能性があり、着信または発信するメッセージが送信先サービスのコンシューマまたはプロバイダの予期するフォーマットであることを保証します。検証でエラーとなったメッセージは、エラーをログに記録するか、またはエラーを生成できます。エラーを生成する場合、エラー・ステージを使用して他のアクションを適用することもできます。
メッセージ検証は、スキーマやWSDLの異なるバージョンに対してメッセージを検証することで、サービスのバージョン管理にも使用できます。これにより、メッセージがサービス・エンドポイントの適切なバージョンにルーティングされることが保証されます。または、メッセージの送信前にトランスフォーメーションを適用する必要があるかどうかをチェックできます。
Oracle Service Busにはエラー・ハンドラを定義することで、エラー処理を行うメカニズムが用意されています。エラー・ハンドラは、ロギング、変換、パブリッシュなどの各種アクションを実行し、適切にエラーを処理するためのパイプラインです。ステージ内でエラーが発生すると、一連の手順が実行されます。この一連の手順がそのステージのエラー・パイプラインを構成しています。
このエラー・パイプラインによってエラーを処理できる方法は以下のとおりです。
元のメッセージを代替エンドポイントにパブリッシュします。
エラー・レスポンス・メッセージを作成して、プロキシ・サービスの呼出し元に返します。
メッセージをログに記録します。
コンテキストを変更した後、パイプラインに従ってメッセージの処理を続行します。
例外を送出します。例外を送出することによって、その次に小さいスコープで指定されたエラー・パイプラインに制御が移されます。
メッセージ・フローの処理中には、様々な原因でエラーが発生します。たとえば、ユーザー名が正しく確認または認証されない場合は、セキュリティ・エラーが発生します。また、Oracle Service Busがメッセージを正常に変換または検証できない場合は、変換エラーが発生します。ルーティング・サービスが使用不能であるために、ルーティング・エラーが発生する場合などもあります。たいていのメッセージ・フロー・ロジックは特定のステージ、ルート・ノード、またはプロキシ・サービスで実行されるため、一般的に、これらのエラーは特定のステージ、ルート・ノード、またはプロキシ・サービスに起因しています。
各ステージは、ステージでエラーが発生した場合に実行される一連の手順を持つことができます。この一連の手順がそのステージのエラー・パイプラインを構成しています。また、エラー・パイプラインは、パイプライン(リクエストまたはレスポンス)またはプロキシ・サービス全体に対して定義することができます。最も小さいスコープで指定されたエラー・パイプラインがエラー時に呼び出されます。
メッセージ・フローの正確な状態を把握するためにOracle Service Bus管理コンソールを使用してメッセージを追跡することができます。これにより、エラーを目で確認できるようになります。たとえば、処理を行うために送信されたことを示す、最初にレポートされたメッセージを表示してから、このメッセージが正しく処理されなかったことを示す、次にレポートされたエラーを表示することができます。これにより、メッセージ・フローとエラー・フローの両方を完全に表示することができます。
『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「Oracle Service Busでのメッセージ・フローのモデリング」
『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の「XQuery Mapper」
『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「XQuery変換」および「XSL変換」
『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のJavaコールアウト・アクションの追加に関する項
