| Oracle® Fusion Middleware Oracle Service Bus管理者ガイド 11g リリース1(11.1.1.5.0) B61436-03 |
|
 前 |
 次 |
Oracle Service Busにおけるメッセージ・フローは、プロキシ・サービスの実装を定義します。Oracle Service Busプロキシ・サービスは、Oracle Service Bus管理コンソールまたはEclipse用のOracle Service Busプラグインで作成および構成できます。この項では、メッセージ・フローについて説明し、メッセージ・フローを設計する際のガイドラインを示します。
以下の項では、Oracle Service Busのメッセージ・フローについて説明します。
Oracle Service Bus管理コンソールでメッセージ・フローを作成および構成する手順については、以下を参照してください。
Eclipseでのメッセージ・フローの作成と構成の手順は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の次のトピックを参照してください。
プロキシ・サービスの操作に関する項
プロキシ・サービス・メッセージ・フローの操作に関する項
メッセージ・フローは、プロキシ・サービスを介してメッセージが流れるときのメッセージのルーティングと操作のロジックを定義するコンポーネントで構成されます。各ノードは、メッセージ・フローでメッセージをルーティングするように構成されます。また、ステージとアクションには、メッセージの処理とトランスフォーメーションに関するルールが含まれます。
メッセージ・フローのほとんどの処理ロジックは、パイプラインで処理されます。パイプラインとは、分岐のない一方向の処理の流れを表す名前付きのステージ・シーケンスです。パイプラインは、以下のカテゴリに分類されます。
リクエスト・パイプライン:メッセージ・フローのリクエスト・パスを処理します。
レスポンス・パイプライン:メッセージ・フローのレスポンス・パスを処理します。
エラー・パイプライン:メッセージ・フローのステージとノードのエラー、およびメッセージ・フロー(サービス)レベルのエラーを処理します。
プロキシ・サービスの処理ロジックを実装するには、リクエスト・パイプラインとレスポンス・パイプラインをペアにしてパイプライン・ペア・ノードを作成します。これらのパイプライン・ペア・ノードを他のノードと結合して単一ルートのツリー構造を作成することで、フロー全体を制御できます。
表37-1に、メッセージ・フローを定義する際に使用できるコンポーネントを示します。
表37-1 メッセージ・フローのコンポーネント
| コンポーネント・タイプ | サマリー |
|---|---|
|
開始ノード |
すべてのメッセージ・フローは開始ノードで始まります。すべてのメッセージは、開始ノードを介してメッセージ・フローに入ります。また、すべてのレスポンス・メッセージが開始ノードを介してクライアントに返されます。開始ノードで構成するものはありません。 |
|
パイプライン・ペア・ノード |
パイプライン・ペア・ノードは、1つのリクエスト・パイプラインと1つのレスポンス・パイプラインを1つの最上位要素に統合したものです。メッセージ・フローでは、パイプライン・ペア・ノードが持つことができる直接の子孫は1つだけです。リクエスト処理中にOracle Service Busがパイプライン・ペア・ノードを処理すると、リクエスト・パイプラインだけが実行されます。Oracle Service Busがレスポンス・パイプラインを処理すると、実行パスが反転されます。 |
|
ステージ |
リクエスト・パイプライン、レスポンス・パイプライン、およびエラー・ハンドラには、ステージを含めることができます。ステージでは、パイプラインを通過するメッセージを処理するアクションを構成します。 37.3項「ステージおよびルート・ノードでのアクションの構成」も参照してください。 |
|
エラー・ハンドラ |
ノードまたはステージで発生する可能性のあるエラーを処理するために、ノードまたはステージにエラー・ハンドラを追加できます。 37.7項「メッセージ・フローでのエラー処理」も参照してください。 |
|
ブランチ・ノード |
ブランチ・ノードを使用すると、可能ないくつかのパスのうちの1つに限定して処理を進めることができます。WSDLベースのサービスでは、オペレーション・ブランチがサポートされます。オペレーション・ブランチでは、分岐はWSDLで定義された操作に基づいています。XPathベースの切替えテーブルで定義された条件では、条件付きブランチがサポートされます。 37.2項「メッセージ・フローの分岐」も参照してください。 |
|
ルート・ノード |
ルート・ノードでは、別のサービスとのリクエスト/レスポンス通信が実行されます。ルート・ノードはプロキシ・サービスに関するリクエスト処理とレスポンス処理の境界を表します。ルート・ノードがリクエスト・メッセージをディスパッチすると、リクエスト処理が終了したと見なされます。ルート・ノードがレスポンス・メッセージを受信したときに、レスポンス処理が始まります。ルート・ノードは、リクエスト・トランスフォーメーション、レスポンス・トランスフォーメーション、および条件付きルーティングに対応します。 ルート・ノードはリクエスト処理とレスポンス処理の境界を表すので、メッセージ・フロー内に子孫を持つことはできません。 37.3項「ステージおよびルート・ノードでのアクションの構成」も参照してください。 |
図37-1は、メッセージ・フロー定義のコンポーネントの概要を示しています。
メッセージ・フローの必須コンポーネントは、開始ノードとルート・ノードだけです。メッセージ・フローで連鎖できる他のコンポーネントに制限はありません。ルート・ノードを1つ作成し、フローのすべてのロジックを格納できます。また、間にブランチ・ノードを配置せずに2つのパイプライン・ペア・ノードを接続することもできます。ブランチ・ノードを使用する場合、各ブランチ・ノードはそれぞれ異なる要素で開始できます。あるブランチはルート・ノードで終了し、別のブランチではパイプライン・ペアが後続し、さらに別のブランチでは子孫を持たないようにすることができます(実行時に、子孫を持たないブランチを実行すると、レスポンス処理がすぐに開始されます)。
ただし、一般には、メッセージ・フローは次の形式のいずれかで設計します。
非オペレーション・サービス(操作を含むWSDLに基づいていないサービス)のフローでは、ルートにパイプライン・ペアが1つあり、その後にルート・ノードを配置します。
オペレーション・サービスのフローでは、ルートにパイプライン・ペアが1つあり、その後にオペレーションに基づくブランチ・ノードを配置します。さらに、各ブランチにはパイプライン・ペアが1つあり、その後にルート・ノードを配置します。
表37-2と表37-3に、一般的なメッセージ・フローでリクエスト・メッセージおよびレスポンス・メッセージが処理される仕組みを簡単に示します。
表37-2 メッセージ・フローでのリクエスト・メッセージのパス
| メッセージ・フロー・ノード | メッセージ処理の内容 |
|---|---|
|
リクエスト処理 |
リクエスト処理コンテナ。 |
|
開始ノード |
開始ノードでリクエスト処理が開始されます。 |
|
パイプライン・ペア・ノード |
リクエスト・パイプラインだけが実行されます。 |
|
ブランチ・ノード |
ブランチ・テーブルを評価し、関連するブランチに進みます。 |
|
ルート・ノード |
リクエスト・トランスフォーメーションと共にルーティングが実行されます。 メッセージ・フローでは、ルーティングが実行されるかどうかに関係なく、ルート・ノードはリクエストの処理からレスポンスの処理への移行を表します。ルート・ノードでは、メッセージ・フローの方向は逆方向になります。リクエスト・パスにルート・ノードが含まれていない場合、レスポンスを待機せずに、レスポンス処理は逆方向で開始されます。 |
メッセージ・フローでは、2種類の分岐がサポートされています。操作ブランチ・ノードで構成される操作ブランチと、条件付きブランチ・ノードで構成される条件付きブランチです。
メッセージ・フローでWSDLベースのプロキシ・サービスを定義する場合、操作固有の処理が必要となります。メッセージ・フローにオペレーション・ブランチ・ノードを作成すると、WSDLで定義された操作に基づいて分岐ロジックを作成できます。
プロキシ・サービスが複数の操作を含むWSDLに基づいている場合は、オペレーション・ブランチを使用する必要があります。この場合、オペレーション・ブランチ・ノードを使用して、操作ごとにメッセージを個別に処理することを検討できます。
メッセージのドキュメント・タイプなど、指定した条件に基づいて分岐する場合は、条件付きブランチを使用します。
条件付きブランチでは、ルックアップ表に基づいて分岐が行われます。ルックアップ表に含まれる各ブランチは、QuantityEqualToOrLessThan150やQuantityMoreThan150のような単純で一意の文字列値でタグ付けされています。
(たとえば、メッセージ・フロー内の前のステージで宣言された)メッセージ・コンテキスト内の変数の値に基づいて分岐するように条件付きブランチを構成できます。また、ブランチ自体で定義されたXPath式の結果に基づいて分岐するように条件を構成することもできます。
実行時に、変数または式が評価され、その結果値を使用してどのブランチに進むかが判断されます。値と一致するブランチがない場合は、デフォルト・ブランチに進みます。ブランチ・ノードでは、メッセージ・フローに複数の子孫を持つことができます。ブランチごとにデフォルト・ブランチが1つ含まれます。デフォルト・ブランチを必ず定義する必要があります。ブランチ・ノードに到達する前にルックアップ変数の値が設定されるように、プロキシ・サービスを設計します。
たとえば、ルックアップ変数を使用する次のケースについて考えてみます。プロキシ・サービスのタイプが任意のSOAPまたは任意のXMLであり、条件付きブランチを実行できるようにメッセージのタイプを特定する必要があるとします。この場合、メッセージ・タイプを特定するステージ・アクションを設計した後に、メッセージ・タイプに基づいて処理を分ける条件付きブランチ・ノードをフロー内に設計できます。
今度は、条件付きブランチ・ノードでXPath式を使用するケースを考えてみます。注文の数量に基づいて分岐させるとします。この数量は、$body内の既知の場所から取得できる変数によって渡されます。
数量を取得する次のXPath式を定義できます。
declare namespace openuri="http://www.openuri.org/"; declare namespace com="oracle.com/demo/orders/cmnCust"; ./openuri:processCust/com:cmnCust/com:Order_Items/com:Item/com:Quantity
メッセージ・フローの下位に向かって、条件(<500など)が式に対して評価されます。最初に満たされた条件によって、次に進むべきブランチが決まります。どの分岐条件も満たされない場合は、デフォルト・ブランチに進みます。
条件付きブランチを使用して、最上位のフロー・ビューでメッセージ・フローのルーティングの代替方法を公開できます。たとえば、メッセージ・フローの初期の既知の条件(メッセージ・タイプなど)に基づいて、サービスAまたはサービスBを呼び出す状況について考えてみます。ルート・ノードのルーティング・テーブルに条件付きブランチを構成できます。ただし、フローの最上位だけを調べる場合、この方法では分岐がやや困難になります。かわりに、条件付きブランチ・ノードを使用して、メッセージ・フロー自体にこのブランチを公開し、各ブランチのサブフローとして単純なルート・ノードを使用できます。
メッセージ・フロー、ステージ、またはルート・ノードのどの場所にブランチを構成するかを決定する前に、ビジネス・シナリオを検討してください。メッセージ・フローにブランチを構成する場合、ブランチ・ノードから多数のブランチが分岐すると、設計インタフェースが煩雑になる可能性があることに注意してください。
アクションは、パイプライン・ステージ、エラー・ハンドラ・ステージ、およびルート・ノードでメッセージを処理する手順を提供します。次の項で説明するように、Oracle Service Bus管理コンソールまたはEclipse用のOracle Service Busプラグインで使用できるアクションは、コンテキストによって決まります。
関連項目
『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のプロキシ・サービス・メッセージ・フローの操作に関する項
通信アクションは、メッセージ・フローを制御します。各通信アクションを表37-4に示します。
表37-4 通信アクション
| アクション | 用途 | 使用できる場所 |
|---|---|---|
|
動的にパブリッシュ |
Xquery式で指定されたサービスにメッセージをパブリッシュします。 |
|
|
パブリッシュ |
メッセージの静的に指定された対象サービスを特定し、メッセージをパッケージ化してその対象サービスに送信する方法を構成します。 |
|
|
パブリッシュ表 |
ゼロまたはそれ以上の静的に指定されたサービスにメッセージをパブリッシュします。切替え式の条件ロジックを使用して、どのサービスをパブリッシュに使用するか実行時に決定します。 |
|
|
ルーティング・オプション |
アウトバウンド・リクエストのURI、サービスの品質、モード、再試行パラメータ、メッセージ優先度の各プロパティの一部またはすべてを変更します。 |
|
|
サービス・コールアウト |
Oracle Service Busに登録済みのプロキシ・サービスまたはビジネス・サービスの同期(ブロック)コールアウトを構成します。37.5項「サービス・コールアウト・メッセージの作成」を参照してください。 |
|
|
トランスポート・ヘッダー |
メッセージのヘッダー値を設定します。37.3.5項「メッセージ・フローでのトランスポート・ヘッダーの構成」を参照してください。 |
|
フロー制御アクションは、条件付きルーティング、条件付きループおよびエラー処理を実装します。また、フロー制御アクションを使用して、呼出し元に成功を通知したり、ステージの残りのアクションをスキップしたりすることもできます。各フロー制御アクションを表37-5に示します。
表37-5 フロー制御アクション
| アクション | 用途 | 使用できる場所 |
|---|---|---|
|
For each |
値のシーケンスを反復処理し、アクションのブロックを実行します。 |
|
|
If... then... |
XQuery式のブール結果に基づいて、1つのアクションまたは一連のアクションを条件付きで実行します。 |
|
|
エラーの生成 |
指定されたエラー・コード(文字列)と記述を含む例外を発生させます。 |
|
|
返信 |
呼出し元に即時返信を送信します。 返信アクションは、リクエスト・パイプライン、レスポンス・パイプライン、またはエラー・パイプラインで使用できます。成功時または失敗時に返信するように構成できます。HTTPインバウンド・トランスポートでの失敗時の返信の場合、返信アクションでは、呼出し元に即時に返信されるように指定します。 |
|
|
再開 |
エラー・ハンドラによってエラーが処理された後、メッセージ・フローを再開します。このアクションにパラメータはありません。このアクションは、エラー・ハンドラでのみ使用できます。 |
|
|
スキップ |
実行時に現在のステージの実行がスキップされ、メッセージ・フローの次のステージに処理を進めます。このアクションにはパラメータがなく、リクエスト・パイプライン、レスポンス・パイプライン、エラー・パイプラインで使用できます。 |
|
このカテゴリのアクションは、メッセージ・フローを処理します。各メッセージ処理アクションを表37-6に示します。
表37-6 メッセージ処理アクション
| アクション | 用途 | 使用できる場所 |
|---|---|---|
|
割当て |
コンテキスト変数にXQuery式の結果を割り当てます。 |
|
|
削除 |
XPath式で指定されたコンテキスト変数または一連のノードを削除します。 |
|
|
挿入 |
XPath式で選択したノードを基準として特定された場所にXQuery式の結果を挿入します。 |
|
|
Javaコールアウト |
メッセージ・フロー内からJavaメソッド(EJBビジネス・サービス)を呼び出します。 |
|
|
MFL変換 |
メッセージ・パイプラインで、XMLから非XMLまたは非XMLからXMLにメッセージ・コンテンツを変換します。MFLは、バイナリ・データのレイアウトを記述するために使用する特別なXMLドキュメントです。Oracle独自の言語を使用して、フォーマットされたバイナリ・データをXMLデータに、またはXMLデータをバイナリ・データに変換するルールを定義します。 |
|
|
名前変更 |
要素のコンテンツを変更せずに、XPath式で選択した要素の名前を変更します。 |
|
|
置換 |
XPath式で指定されたノードまたはノードのコンテンツを置き換えます。ノードまたはそのコンテンツは、XQuery式が返した値で置換されます。 置換アクションでは、単純な値、要素、属性を置き換えることができます。XQuery式から何も返されない状態は、アクションがノード全体を置き換えるか、ノードコンテンツのみを置き換えるかにより、識別されたノードを削除すること、または空のノードを作成することと同じです。 置換アクションは一連の更新アクションの1つです。 |
|
|
検証 |
XMLスキーマ要素またはWSDLリソースに対して、XPath式で選択した要素を検証します。検証できるのは、グローバル要素のみです。Oracle Service Busはローカル要素に対する検証に対応していません。 |
|
このカテゴリのアクションを使用して、ステージ内のメッセージ・フローでの必要に応じて、エラーのログ記録またはレポート、およびアラートの生成を行います。各レポート・アクションを表37-7に示します。
表37-7 レポート・アクション
| アクション | 用途 | 使用できる場所 |
|---|---|---|
|
アラート |
パイプラインのメッセージ・コンテキストに基づいてアラートを生成し、アラート宛先に送信します。SLAアラートと異なり、アラートアクションで生成された通知は、主にビジネスでの使用、またはエラーの報告を目的とし、システムの状態を監視するものではありません。アラート宛先の構成と選択は、この点を考慮して行う必要があります。 パイプライン・アラートがサービスで有効になっていない場合や、ドメイン・レベルで有効になっている場合は、メッセージを処理するときに構成済みのアラート・アクションが省略されます。 |
|
|
ログ |
ログに記録するメッセージを作成し、メッセージをログに記録するときに使用する一連の属性を定義します。 |
|
|
レポート |
プロキシ・サービスのメッセージ・レポートを有効にします。 |
|
トランスポート・ヘッダー・アクションは、通信タイプのアクションです。このアクションは、パイプライン・ステージとエラー・ハンドラ・ステージで使用できます。
トランスポート・ヘッダー・アクションを構成するときに、以下のオプションを使用できます。
「パイプラインを介してすべてのヘッダーを渡す」オプションは、実行時にトランスポート・ヘッダー・アクションによって、インバウンド・メッセージからアウトバウンド・メッセージまたはアウトバウンド・メッセージからインバウンド・メッセージにすべてのヘッダーをパススルーすることを示します。ソース・ヘッダー・セットのすべてのヘッダーはターゲット・ヘッダー・セットにコピーされ、ターゲット・ヘッダー・セットの既存の値はすべて上書きされます。
「インバウンド・リクエストからヘッダーをコピー」オプションと「アウトバウンド・レスポンスからヘッダーをコピー」オプションは、実行時にトランスポート・ヘッダー・アクションによって、このオプションが関連付けられている特定のヘッダーをインバウンド・メッセージからアウトバウンド・メッセージまたはアウトバウンド・メッセージからインバウンド・メッセージにコピーすることを示します。
これらのオプションは、シナリオに合せて使用します。どちらのオプションを使用しても、ソース・ヘッダー・セットのヘッダーがターゲット・ヘッダー・セットにコピーされ、ターゲット・セットの既存の値はすべて上書きされます。「パイプラインを介してすべてのヘッダーを渡す」オプションは、ヘッダー固有のヘッダーをコピー・オプションの前に実行されます。つまり、特定のトランスポート・ヘッダー・アクションの構成で、「パイプラインを介してすべてのヘッダーを渡す」を選択した場合、特定のヘッダーに対してヘッダーをコピー・オプションを選択する必要はありません。
ただし、「パイプラインを介してすべてのヘッダーを渡す」を選択してすべてのヘッダーをコピーし、その後特定のヘッダーに対して「ヘッダーの削除」を選択して、個々のヘッダーを削除するようにアクションを構成できます。
|
注意: トランスポート・ヘッダーはトランスポート・タイプに固有であるため、パススルー(またはコピー)オプションは、同じトランスポート・タイプのサービス間でヘッダーをコピーする場合にのみ使用することをお薦めします。トランスポート・タイプが異なるサービス間でヘッダーを渡す(またはコピーする)と、渡されるヘッダーが対象のトランスポートで受け入れられない場合にエラーが発生することがあります。同じ理由で、「ヘッダーを設定」オプションを使用してヘッダー名を指定するときにも注意が必要です。 |
トランスポート・ヘッダー・アクションを使用して、アウトバウンド・リクエスト(ルート、パブリッシュ、またはサービス・コールアウトの各アクションでプロキシ・サービスが送信するメッセージ)とインバウンド・レスポンス(プロキシ・サービスがクライアントに返信するレスポンス・メッセージ)のトランスポート・ヘッダーの値を構成できます。通常、ヘッダー値に対して次の操作を実行できます。
XQuery式を使用して指定します。
ソースから対象サービスにパススルーします。
ソースから対象サービスへの移動時に削除します。
トランスポート・ヘッダー・アクションを使用すると、$inboundまたは$outboundのヘッダーを設定、削除、またはパススルーできます。これらのヘッダーを設定または削除した後に、$inboundまたは$outboundをログに書き込むと、変更の影響を確認できます。ただし、メッセージが送信されるときにOracle Service Busバインディング・レイヤーによって$inboundまたは$outboundの一部のヘッダーが変更または削除され、そのため基礎になるトランスポートでこれらのヘッダーの一部が無視されて、そのトランスポート固有の値が使用されることがあります。重要な違いは、バインディング・レイヤーによるヘッダーの変更は$inboundおよび$outboundに対して直接行われますが、トランスポートによる変更はメッセージのワイヤ形式だけに影響するという点です。たとえば、アウトバウンドのContent-Lengthヘッダーの値を指定することはできますが、メッセージの送信時に、この値はバインディング・レイヤーによって$outboundから削除されます。したがって、この変更はレスポンス・パスで確認できます(たとえば、$outboundをログに記録すると、変更された値を確認できます)。$outboundにUser-Agentヘッダーを設定した場合、HTTPトランスポートではこの設定が無視され、トランスポート独自の値が使用されます。ただし、$outboundの値が変更されることはありません。
表37-8に、実行時に無視または上書きされるトランスポート・ヘッダーと、特定のトランスポート・ヘッダーに関するその他の制限を示します。
表37-8 トランスポート・ヘッダー・アクションで指定するトランスポート・ヘッダーの値の制限
| トランスポート | 制限の説明 | アウトバウンド・リクエスト・ヘッダー | インバウンド・レスポンス・ヘッダー |
|---|---|---|---|
|
HTTP |
Oracle Service Busランタイムは、メッセージのディスパッチ準備中にバインディング・レイヤーでこれらのヘッダーを上書きする場合があります。これらのヘッダーが変更された場合、それに応じて |
Content-Type |
Content-Type |
|
HTTP |
メッセージの送信時に、基になるトランスポートでこれらのヘッダーが無視され、別の値が使用される場合があります。トランスポートによって行われた変更は、 |
|
|
|
JMS |
リクエストが一方向のサービスまたは
|
JMSCorrelationID |
JMSCorrelationID |
|
JMS |
メッセージの存続時間をミリ秒単位で設定する必要があります。受信したメッセージの結果値は、クライアントが指定する存続時間の値と、送信時またはパブリッシュ時のGMTの合計になります脚注 1 。 |
JMSExpiration |
JMSExpiration |
|
JMS |
Oracle Service Busランタイムはこれらのヘッダーを設定します。つまり、設計時にこれらのヘッダーに対して行った指定内容は実行時に上書きされます。 |
|
|
|
JMS |
IBM MQではクライアント・アプリケーションで一部のプロパティを設定できないため、IBM MQ宛先に関連するこれらのヘッダーを設定すると、実行時例外が発生します。 |
|
|
|
JMS |
「パイプラインを介してすべてのヘッダーを渡す」オプションも指定されている場合、これらのヘッダーを削除することはできません。 |
|
|
|
FTPおよびファイル |
制限はありません。つまり、ユーザーはファイル・トランスポートおよびFTPトランスポートのヘッダー脚注 3 を設定または削除することができ、ユーザーによる指定はOracle Service Busランタイムで優先されます。 |
N/A |
N/A |
|
電子メール |
Oracle Service Busランタイムはこれらのヘッダーを設定します。つまり、設計時にこれらのヘッダーに対して行った指定内容は実行時に上書きされます。 |
Content-Type |
Content-Type |
|
電子メール |
Oracle Service Busはアウトバウンド・リクエストでこれらのヘッダーを使用しません。これらを動的に(つまり、これらを これらのヘッダーは |
|
N/A |
脚注 1 たとえば、JMSExpirationヘッダーを1000に設定し、送信時にGMTが1,000,000(System.currentTimeMillis()の結果)である場合、JMSメッセージのJMSExpirationプロパティの結果値は1,000,1000になります。
脚注 2 JMS_IBMという接頭辞の付いたヘッダー名は、IBM MQサーバーがホストする宛先に関連して使用されます。
脚注 3 FTPプロキシとファイル・プロキシには、「fileName」というトランスポート・リクエスト・ヘッダーがあります。このリクエスト・ヘッダーの値は、ポーリング対象となるファイルの名前です。
|
注意: inboundコンテキスト変数とoutboundコンテキスト変数を設定する場合や、Oracle Service Bus Test Consoleを使用してプロキシ・サービスまたはビジネス・サービスをテストする場合は、トランスポート・ヘッダーとメタデータの設定のときと同じ制限が適用されます。 |
トランスフォーメーション・マップは、2つのデータ型の間のマッピングを記述したものです。Oracle Service Busは、XQueryおよびeXtensible Stylesheet Language Transformation (XSLT)標準を使用したデータ・マッピングに対応しています。XSLTマップでは、XMLからXMLへのマッピングを記述します。XQueryマップでは、XMLからXML、XMLから非XML、および非XMLからXMLへの各マッピングを記述できます。
メッセージ・フロー内にトランスフォーメーションを指定する位置は、以下の条件によって異なります。
メッセージ・フォーマットがターゲット・サービスに依存する場合。つまり、メッセージ・フォーマットが、ルートの宛先で受け入れられるフォーマットであることが必要な場合です。これに該当するのは、トランスフォーメーションがルート・ノードまたはパブリッシュ・アクションの1つで実行されるときです。
パブリッシュ・アクションで、メッセージのターゲット・サービスを判別し、メッセージのパッケージおよびサービスへの送信方法を構成します。Oracle Service Busには、パブリッシュ・テーブル・アクションも用意されています。パブリッシュ・テーブル・アクションは、切替え式条件テーブルにラップされた一連のルートで構成されます。これは、単一のXQuery式の結果に基づいて各種ルートを選択できる短縮形の構文です。
ルートの宛先に関係なく、リクエストまたはレスポンス・メッセージに対してトランスフォーメーションを実行するかどうか。この場合、リクエストまたはレスポンス・パイプライン・ステージでトランスフォーメーションを構成できます。
トランスフォーメーションをパブリッシュ・アクション内に設計した場合、トランスフォーメーションは$outbound変数およびメッセージ関連の変数($header、$bodyおよび$attachments)のローカル・コピーを保持します。パブリッシュ・アクションでアウトバウンド・メッセージに行った変更は、パブリッシュされるメッセージにのみ反映されます。つまり、パブリッシュ・アクションで行った変更は、メッセージ・フローがその次のアクションに進む前にロールバックされます。
たとえば、メッセージ・フローで大口の発注書を処理するときに、管理者宛てに発注書の要約を電子メールで送信する必要がある場合について考えます。このような場合、リクエスト・パイプラインにパブリッシュ・アクションを含めると、着信メッセージのSOAP本体に発注書の要約が作成されます。パブリッシュ・アクションでは、発注書データが発注書の要約に変換されます。たとえば、発注書の要約には添付ファイルは必要ないため、$attachmentsのすべての添付ファイルを削除できます。
WS-Addressingヘッダーに基づく2つの宛先の一方にメッセージをルーティングする必要があるとします。この場合、コンテンツ・ベースのルーティングです。また、もう一方の宛先では、SOAP本体のドキュメントの新しいバージョンが必要であるとします。このような場合、条件に基づいて2つの宛先の一方にルーティングされるように、ルート・ノードを構成できます。2つ目の宛先のためにドキュメントを変換するように、ルート・ノードでトランスフォーメーションを構成します。
アウトバウンド・コンテキスト変数($outbound)の制御要素を設定して、アウトバウンド・メッセージに関するシステムの動作を調整することもできます(たとえば、サービスの品質を設定できます)。
inbound変数とoutbound変数の下位要素、およびメッセージ・コンテキストの変数の値を使用してメッセージのコンテンツが作成される仕組みについては、39.4項「inbound変数とoutbound変数」および39.9項「ディスパッチするメッセージの作成」を参照してください。
関連項目
『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のXQuery Mapperに関する項
Oracle Service Busがサービス・コールアウト・アクションを通じてサービスを呼び出す場合は、メッセージ・コンテキストの変数の値を使用してメッセージのコンテンツが作成されます。アウトバウンド・メッセージのメッセージ・コンテンツは、ターゲット・サービスの種類に応じて異なって処理されます。
以下のトピックで説明するように、メッセージ・コンテンツの作成方法は、対象サービスのタイプ、およびSOAP本体とペイロード(パラメータまたはドキュメント)のどちらを構成するかによって異なります。
次のようなSOAPドキュメント・スタイルのサービス(EJBドキュメントおよびドキュメントにラップされたサービスを含む)のメッセージを作成できます。
リクエスト・ドキュメントが割り当てられた変数にはSOAP本文が含まれます。
SOAPリクエスト・ヘッダーに割り当てられた変数にはSOAPヘッダーが含まれます。
レスポンスは単一のXMLドキュメント(SOAP本体のコンテンツとSOAPヘッダー(指定されている場合))である必要があります。
SOAPドキュメント・スタイルのサービスへのコールアウト時にメッセージが作成されるしくみを説明するために、次のように構成されたサービス・コールアウト・アクションについて考えてみます。
リクエスト・ドキュメント変数: myreq
レスポンス・ドキュメント変数: myresp
SOAPリクエスト・ヘッダー: reqheader
SOAPレスポンス・ヘッダー: respheader
また、実行時にリクエスト・ドキュメント変数myreqが次のXMLにバインドされていることを前提とします。
例37-1 リクエスト変数(myreq)のコンテンツ
<sayHello xmlns="http://www.openuri.org/">
<intVal>100</intVal>
<string>Hello Oracle</string>
</sayHello>
実行時に、SOAPリクエスト・ヘッダー変数reqheaderは、次のSOAPヘッダーにバインドされます。
例37-2 SOAPリクエスト・ヘッダー変数(reqheader)のコンテンツ
<soap:Header xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
<wsa:Action>...</wsa:Action>
<wsa:To>...</wsa:To>
<wsa:From>...</wsa:From>
<wsa:ReplyTo>...</wsa:ReplyTo>
<wsa:FaultTo>...</wsa:FaultTo>
</soap:Header>
このシナリオ例では、外部サービスに送信されるメッセージの本文全体は例37-3のようになります(myreq変数とreqheader変数のコンテンツは太字で示しています)。
例37-3 サービス・コールアウト・アクションの結果としてサービスに送信されるメッセージ
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
<wsa:Action>...</wsa:Action>
<wsa:To>...</wsa:To>
<wsa:From>...</wsa:From>
<wsa:ReplyTo>...</wsa:ReplyTo>
<wsa:FaultTo>...</wsa:FaultTo>
</soap:Header>
<soapenv:Body>
<sayHello xmlns="http://www.openuri.org/">
<intVal>100</intVal>
<string>Hello Oracle</string>
</sayHello>
</soapenv:Body>
</soapenv:Envelope>
前述のサービス・コールアウト・アクションの構成に基づいて、サービスからのレスポンスがmyresp変数に割り当てられます。外部サービスからのレスポンス全体は、例37-4のようになります。
例37-4 サービス・コールアウト・アクションの結果としてサービスから送信されるレスポンス・メッセージ
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.
org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<env:Header/>
<env:Body env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<m:sayHelloResponse xmlns:m="http://www.openuri.org/">
<result xsi:type="xsd:string">This message brought to you by Hello Oracle and the number 100
</result>
</m:sayHelloResponse>
</env:Body>
</env:Envelope>
このシナリオでは、myresp変数に例37-5に示す値が割り当てられます。
次のようなSOAP RPCスタイルのサービス(EJB RPCサービスを含む)のメッセージを作成できます。
リクエスト・メッセージは、メッセージ・コンテキスト変数からアセンブルされます。
SOAP本体は、SOAP RPC形式(操作ラッパー、パラメータ・ラッパーなど)に基づいて作成されます。
SOAPヘッダーは、SOAPリクエスト・ヘッダーに指定された変数のコンテンツです(変数が指定されている場合)。
partを要素として使用 - パラメータ値は変数のコンテンツです。
partを単純型として使用 - パラメータ値は変数のコンテンツの文字列表現です。
partを複合型として使用 - パラメータは、パラメータ名の後にある変数のコンテンツのルートの名前変更に対応します。
レスポンス・メッセージは、以下のようにアセンブルされます。
出力コンテンツはSOAPヘッダーのコンテンツです(SOAPヘッダーが指定されている場合)。
partを要素として使用 - 出力コンテンツはパラメータの子要素です。子要素は1つだけです。
partを単純型/複合型として使用 - 出力コンテンツはパラメータ自体です。
SOAP RPCスタイルのサービスへのコールアウト時にメッセージが作成されるしくみを説明するために、次のように構成された例について考えてみます。
メッセージ・コンテキスト変数input1は値100にバインドされています。
メッセージ・コンテキスト変数input2は文字列値Hello Oracleにバインドされています。
サービス・コールアウト・アクションが次のように構成されています。
リクエスト・パラメータ intval: input1
リクエスト・パラメータ string: input2
レスポンス・パラメータ result: output1
このシナリオでは、サービスへのアウトバウンド・メッセージの本文は例37-6のようになります。
例37-6 アウトバウンド・メッセージのコンテンツ
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<sayHello2 xmlns="http://www.openuri.org/">
<intVal>100</intVal>
<string >Hello Oracle</string>
</sayHello2>
</soapenv:Body>
</soapenv:Envelope>
コールされたサービスによって返されるレスポンスは、例37-7のようになります。
例37-7 helloWorldサービスからのレスポンス・メッセージのコンテンツ
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<env:Header/>
<env:Body env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<m:sayHello2Response xmlns:m="http://www.openuri.org/">
<result xsi:type="n1:HelloWorldResult" xmlns:n1="java:">
<message xsi:type="xsd:string">
This message brought to you by Hello Oracle and the number 100
</message>
</result>
</m:sayHello2Response>
</env:Body>
</env:Envelope>
メッセージ・コンテキスト変数output1には、例37-8に示す値が割り当てられます。
次のようなXMLサービスのメッセージを作成できます。
リクエスト・メッセージは、リクエスト・ドキュメントが割り当てられた変数のコンテンツです。
リクエスト変数のコンテンツは、単一のXMLドキュメントである必要があります。
出力ドキュメントは、レスポンス・メッセージです。
XMLサービスへのコールアウト時にメッセージが作成されるしくみを説明するために、次のように構成されたサービス・コールアウト・アクションを例にとります。
リクエスト・ドキュメント変数: myreq
レスポンス・ドキュメント変数: myresp
また、実行時にリクエスト・ドキュメント変数myreqが次のXMLにバインドされていることを前提とします。
メッセージング・サービスの場合の特徴は以下のとおりです。
リクエスト・メッセージはリクエスト変数のコンテンツです。コンテンツには単純なテキスト、XML、または<binary-content ref=.../>参照XMLのインスタンスによって表されるバイナリ・データを使用できます。
レスポンス・メッセージはバイナリとして扱われるため、実際にどのようなコンテンツを受信したかにかかわらず、レスポンス変数には<binary-content ref= ... />参照XMLのインスタンスが格納されます。
たとえば、リクエスト・メッセージのコンテキスト変数myreqが<hello>there</hello>という形式のXMLドキュメントにバインドされる場合、アウトバウンド・メッセージには厳密にこのペイロードが格納されます。レスポンス・メッセージのコンテキスト変数(myresp)は、次のような参照要素にバインドされます。
<binary-content ref=" cid:1850733759955566502-2ca29e5c.1079b180f61.-7fd8"/>
エラー処理は、メッセージ・フロー、パイプライン、ルート・ノード、およびステージ・レベルで構成できます。サービス・コールアウトの結果として外部サービスから受け取るエラーのタイプには、トランスポート・エラー、SOAPフォルト、予期されるレスポンスに一致しないレスポンスなどがあります。
faultコンテキスト変数の設定は、返されるエラーのタイプごとに異なります。fault変数のコンテンツに基づいて、ビジネス・ロジックとエラー処理ロジックを構築できます。$faultの詳細は、39.6項「fault変数」を参照してください。
外部サービスからトランスポート・エラーを受け取り、トランスポート・プロバイダからOracle Service Busにエラー・レスポンス・ペイロードが返されない場合(たとえば、HTTP 403のエラー・コードが返される場合)、サービス・コールアウト・アクションは例外をスローします。これにより、パイプラインでエラーが発生します。ユーザーが構成したエラー・ハンドラのfault変数は、例37-11に示すメッセージと同様にフォーマットされたメッセージにバインドされます。
例37-11 Oracle Service Busのfault変数のコンテンツ - トンラスポート・エラー、エラー・レスポンス・ペイロードなし
<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-380000</con:errorCode>
<con:reason>Not Found</con:reason>
<con:details>
.......
</con:details>
<con:location>
<con:node>PipelinePairNode1</con:node>
<con:Pipeline>PipelinePairNode1_request</con:Pipeline>
<con:Stage>Stage1</con:Stage>
</con:location>
</con:fault>
トランスポート・エラーに関連付けられたペイロードがある場合(たとえばビジネス・サービスからHTTP 500のエラー・コードを受け取り、レスポンス内にXMLペイロードがある場合)、カスタム・エラー・コードBEA-382502のメッセージ・コンテキスト・エラーが生成されます。
サービスがHTTPまたはJMSトランスポートを使用している場合に、そのサービスからのレスポンスの結果としてBEA-382502エラーレスポンス・コードがトリガーされるには、次の条件が満たされる必要があります。
(HTTP)レスポンス・コードは200または202以外のコードである必要があります。
(JMS)レスポンスにエラー・レスポンスであることを示すプロパティが設定されている必要があります(トランスポート・メタデータのステータス・コードが1に設定されている場合はエラーを示します)。
コンテンツ・タイプがtext/xmlである必要があります。
サービスがAnySoapまたはWSDLベースのSOAPである場合、サービスにSOAPエンベロープが必要です。SOAPエンベロープ内の本体はXML形式でなければなりません(テキストは不可)。
サービスのタイプがAnyXMLである、またはタイプがテキストであるメッセージング・サービスでXMLコンテンツが不成功レスポンス・コード(200または202以外の任意のコード)と共に返されます。
トランスポートがHTTPの場合、ErrorResponseDetail要素にはレスポンスとともに返されるHTTPエラー・コードも含まれます。fault内のErrorResponseDetail要素には、サービスから受信したエラー・レスポンス・ペイロードが含まれます。ErrorResponseDetail要素の例を例37-12に示します。
例37-12 Oracle Service Busのfault変数のコンテンツ - トランスポート・エラー、エラー・レスポンス・ペイロードあり
<ctx:Fault xmlns:ctx="http://www.bea.com/wli/sb/context">
<ctx:errorCode>BEA-382502<ctx:errorCode>
<ctx:reason> Service callout has received an error response from the server</ctx:reason>
<ctx:details>
<alsb:ErrorResponseDetail xmlns:alsb="http://www.oracle.com/...">
<alsb:detail> <![CDATA[
. . .
]]>
</alsb:detail> <alsb:http-response-code>500</alsb:http-response-code>
</alsb:ErrorResponseDetail>
</ctx:details>
<ctx:location>. . .</ctx:location>
</ctx:Fault>
外部サービスがSOAPフォルトを返した場合、Oracle Service Busランタイムは、カスタム・エラー・コードとフォルトの詳細を示す説明を含むコンテキスト変数$faultを設定します。そのために、SOAPフォルトの<SOAP-ENV:Fault>要素の下にある3つの要素のコンテンツが抽出され、Oracle Service Busのfault要素の作成に使用されます。
サービスが次のエラーを返すシナリオを例にとります。
例37-13 サービス・コールアウトから返されるSOAPフォルト
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Client</faultcode>
<faultstring>Application Error</faultstring>
<detail>
<message>That's an Error!</message>
<errorcode>1006</errorcode>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
<faultcode>、<faultstring>、<detail>の各要素が抽出され、<alsb:ReceivedFault>要素にラップされます。例37-15のfaultcode要素にはQNameが含まれ、関連するすべてのネームスペース宣言が保持されます。トランスポートがHTTPの場合、ReceivedFault要素にはフォルト・レスポンスとともに返されるHTTPエラー・コードも含まれます。
生成される<alsb:ReceivedFault>要素、およびカスタム・エラー・コードとエラー文字列は、faultコンテキスト変数のコンテンツの作成に使用されます。この例では、例37-14と同様の形式になります。
例37-14 Oracle Service Busのfault変数のコンテンツ - SOAPフォルト
<ctx:Fault xmlns:ctx="http://www.bea.com/wli/sb/context">
<ctx:errorCode>BEA-382500<ctx:errorCode>
<ctx:reason> service callout received a soap Fault response</ctx:reason>
<ctx:details>
<alsb:ReceivedFault xmlns:alsb="http://www.oracle.com/...">
<alsb:faultcode
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">SOAP-ENV:Clien
</alsb:faultcode>
<alsb:faultstring>Application Error</alsb:faultstring>
<alsb:detail>
<message>That's an Error!</message>
<errorcode>1006</errorcode>
</alsb:detail>
<alsb:http-response-code>500</alsb:http-response-code>
</alsb:ReceivedFault>
</ctx:details>
<ctx:location> </ctx:location>
</ctx:Fault>
|
注意: ユニークなエラー・コードBEA-382500は、サービス・コールアウト・アクションがSOAPフォルト・レスポンスを受け取ったときに備えて予約されています。 |
プロキシ・サービスのランタイムが予期していないレスポンス・メッセージがサービスから返された場合、メッセージ・コンテキスト・フォルトが生成され、カスタム・エラー・コードBEA-382501で初期化されます。フォルトの詳細にはレスポンスのSOAP-Body要素のコンテンツが含まれます。トランスポートがHTTPの場合、ReceivedFault要素にはフォルト・レスポンスとともに返されるHTTPエラー・コードも含まれます。
例37-15に、サービス・コールアウトで生成されるフォルトの詳細のXMLスキーマ定義を示します。
例37-15 サービス・コールアウトで生成されるフォルトの詳細のXMLスキーマ
<xs:complexType name="ReceivedFaultDetail">
<xs:sequence>
<xs:element name="faultcode" type="xs:QName"/>
<xs:element name="faultstring" type="xs:string"/>
<xs:element name="detail" minOccurs="0" >
<xs:complexType>
<xs:sequence>
<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" />
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax" />
</xs:complexType>
</xs:element>
<xs:element name="http-response-code" type="xs:int" minOccurs="0"/>\
type="xs:int" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="UnrecognizedResponseDetail">
<xs:sequence>
<xs:element name="detail" minOccurs="0" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="ErrorResponseDetail">
<xs:sequence>
<xs:element name="detail" minOccurs="0" type="xs:string" />
</xs:sequence>
</xs:complexType>
次のパラグラフで説明するプロセスでは、エラー・ハンドラ・ステージのエラー処理パイプラインを構成します。また、エラー・パイプラインは、パイプライン(リクエストまたはレスポンス)またはプロキシ・サービス全体に対して定義することができます。
ステージ・レベルのエラー・ハンドラがエラー処理に呼び出されます。ステージ・レベルのエラー・ハンドラが特定タイプのエラーを処理できない場合、パイプライン・エラー・ハンドラが呼び出されます。パイプライン・レベルのエラー・ハンドラもエラーを処理できない場合は、サービス・レベルのエラー・ハンドラが呼び出されます。サービス・レベルのエラー・ハンドラも処理できない場合、システムがエラーを処理します。表37-9に、メッセージ・フローの様々なレベルにおけるエラー・ハンドラのスコープの概要を示します。
表37-9 エラー・ハンドラのスコープ
| レベル | スコープ |
|---|---|
|
ステージ |
ステージ内のすべてのエラーを処理します。 |
|
パイプライン |
パイプラインのステージの未処理のエラーと共に、パイプラインのすべてのエラーを処理します。 |
|
サービス |
サービスのパイプラインの未処理のエラーと共に、パイプラインのすべてのエラーを処理します。 注意: WS-Securityエラーはすべてこのレベルで処理されます。 |
|
システム |
パイプラインで処理されないすべてのエラーを処理します。 |
|
注意: エラー・ハンドラのスコープには例外があります。たとえば、ステージ・レベルの非XMLトランスフォーメーションによって送出される例外を捕捉するのは、サービス・レベルのエラー・ハンドラのみです。プロキシ・サービスの送信レスポンス・メッセージ用にXMLからMFLに変換する場合、このトランスフォーメーションは常にバインディング・レイヤーで発生します。したがって、たとえば、非XML出力でステージ・レベルの必須フィールドが欠落している場合、サービス・レベルのエラー・ハンドラだけがこのエラーを捕捉できます。 |
エラー・メッセージとエラー処理の詳細は第24章「プロキシ・サービス: エラー・ハンドラ」を参照してください。
アサーションがtrueであるかどうかを確認するテストをコンフィグレーションすることでエラーを処理できます。このテストは様々なレベルで繰り返すことができます。下位レベルでエラー・ハンドラのない状態でエラーが発生した場合、メッセージ・フローの上位レベルのエラー・ハンドラによって処理することもできます。
通常、メッセージ・フローのステージ・レベルで特定のエラーを処理し、下位レベルでは処理されないエラーのより一般的なデフォルト処理に上位レベルのエラー・ハンドラを使用する方が簡単です。予期されるエラーをパイプラインで明示的に処理し、予期されないエラーをサービス・レベルのハンドラで処理することをお薦めします。
|
注意: サービス・レベルで処理できるのは、WS-Security関連のエラーのみです。 |
メッセージ処理中に発生したエラーに関する情報はすべて、事前定義されたコンテキスト変数(fault変数)に保持されます。エラーが発生すると、この変数に情報が格納されてから、適切なエラー・ハンドラが呼び出されます。このfault変数はエラー・ハンドラ・パイプラインでのみ定義され、リクエスト・パイプラインやレスポンス・パイプライン、ルート・ノードやブランチ・ノードでは設定されません。$faultの詳細は、39.2項「事前定義されたコンテキスト変数」を参照してください。
リクエスト/レスポンス型のインバウンド・メッセージでのエラー発生時には、多くの場合、エラーが発生した理由を説明するメッセージを送信元に返送する必要があります。そのためには、送信するレスポンスに対してメッセージ・コンテキスト変数を構成した後、失敗時の返信アクションを使用します。たとえば、HTTPメッセージが失敗した場合は、失敗時の返信でHTTP 500ステータスが生成されます。JMSメッセージが失敗した場合は、失敗時の返信でJMS_BEA_Errorプロパティがtrueに設定されます。Oracle Service Busのエラー・アクションについては、第24章「プロキシ・サービス: エラー・ハンドラ」を参照してください。
プロキシ・サービスが呼び出したサービスがSOAPフォルトまたはトランスポート・エラーを返すと、エラー処理パイプラインが呼び出されます。受信したSOAPフォルトはすべて$bodyに格納されるため、$bodyを変更せずに失敗時の返信を実行すると、サービスの呼出し元のクライアントには元のSOAPフォルトが返されます。返信アクションが構成されていない場合、システム・エラー・ハンドラによって新しいSOAPフォルト・メッセージが生成されます。プロキシ・サービスでは、HTTPエラー・ステータスが設定されたか、JMSプロパティSERVER_Errorがtrueに設定されているためにSOAPフォルトが返されたと認識されます。
用途によっては、エラー・レポートが必要な場合があります。このような場合は、レポート・アクションを使用します。たとえば、リクエスト・パイプラインで追跡用にメッセージをレポートするレポート・アクションを実行した後、ルート・ノードによって呼び出されたサービスが失敗するというシナリオを想定します。このような場合、メッセージはレポート・システムによってログに記録されますが、メッセージが正常に処理されたという保証はありません。メッセージが正常に受信されたことを示すだけです。
Oracle Service Bus管理コンソールでは、メッセージを追跡することによって、メッセージ・フローの正確な流れを把握することができます。これにより、メッセージが処理のために送信されたことをレポートする元のメッセージだけでなく、メッセージが正常に処理されなかったことをレポートする以降のエラーも確認できます。レポート・アクションを構成し、実行時にレポートされるデータを使用する方法については、第22章「プロキシ・サービス: アクション」を参照してください。
この例では、エラー・ハンドラにレポート・アクションと返信アクションを構成する方法を示します。図37-2に示すメッセージ・フローには、validate loan applicationステージのエラー・ハンドラが含まれています。この例のエラー・ハンドラは、1つのステージが構成された単純なメッセージ・フローであり、Oracle Service Bus管理コンソールには、図37-2のように表示されます。
図37-3に示すように、このステージはアクション(置換、レポート、および返信)で構成されています。
アクションによって、パイプライン・エラー・ハンドラのステージの動作が次のように制御されます。
置換 - body変数の指定した要素のコンテンツが、faultコンテキスト変数のコンテンツで置換されます。body変数の要素はXPath式で指定します。コンテンツは、XQuery式で返される値で置換されます。この例では$fault/ctx:reason/text()です。
レポート - このアクションで構成されたエラー・ハンドラが呼び出されると、レポート・アクションのメッセージがOracle Service Busレポート・データ・ストリームに書き込まれます。JMSレポート・プロバイダによって、メッセージがOracle Service Busダッシュボードでレポートされます。Oracle Service Busには、メッセージ・データを1つ以上のレポート・プロバイダに配信する機能があります。メッセージ・データは、メッセージの本文、およびメッセージに関連付けられた他の任意の変数(ヘッダーやinbound変数など)から取り込むことができます。レポート・プロバイダに配信されたメッセージは、メッセージのトラッキングや規制の監査などの機能に使用できます。
エラーが発生すると、faultコンテキスト変数のコンテンツがレポートされます。キー名はerrorCodeです。キー値は./ctx:errorCodeというXPath式を使用してfault変数から抽出されます。キーと値のペアをキー識別子として使用して、実行時にダッシュボードでこれらのメッセージを識別します。
レポート・アクションを構成し、実行時にレポートされるデータを使用する場合、第22章「プロキシ・サービス: アクション」を参照してください。
返信 - 実行時に、loanGateway3プロキシ・サービスの呼出し元に即時返信が送信され、メッセージにフォルトが含まれていたことが示されます(図37-3を参照)。この返信は「失敗時」です。
構成の詳細は、第24章「プロキシ・サービス: エラー・ハンドラ」を参照してください。
作成するプロキシ・サービスから呼び出す必要があるサービスがわからない場合に、動的ルーティングを使用できます。
どのプロキシ・サービスでも、以下のいずれかの方法を使用して、メッセージを動的にルーティングできます。
Oracle Service Busの完全修飾サービス名を動的に設定し、動的ルート・アクションまたは動的パブリッシュ・アクションを使用するように、メッセージ・フロー・パイプラインでXQuery式を設計します。
|
注意: 動的ルーティングはルート・ノードで使用でき、動的パブリッシュはリクエスト・パイプラインまたはレスポンス・パイプラインのステージで使用できます。 |
この方法を使用すると、プロキシ・サービスでは、エンドポイント・ビジネス・サービスのサービス・アカウントを動的に使用して、ユーザー名とパスワードをそのアウトバウンド・リクエストに送信します。たとえば、プロキシ・サービスがビジネス・サービスAにリクエストをルーティングする場合、プロキシ・サービスではビジネス・サービスAのサービス・アカウントを使用して、ユーザー名とパスワードをそのアウトバウンド・リクエストに送信します。37.8.1項「動的ルーティングの実装」を参照してください。
ビジネス・サービスにメッセージをルーティングまたはパブリッシュするように、プロキシ・サービスを構成します。次に、ルート・アクションまたはパブリッシュ・アクションのリクエスト・アクション・セクションで、サービスのURIを動的に指定するルーティング・オプション・アクションを追加します。
この方法を使用すると、リクエストの送信先のURIに関係なく、ユーザー名とパスワードをそのアウトバウンド・リクエストに送信するために、プロキシ・サービスは静的に定義されたビジネス・サービスのサービス・アカウントを使用します。
この方法の使用方法については、37.8.1項「動的ルーティングの実装」を参照してください。
|
注意: この方法は、インタフェースの概要が確定している場合に使用します。インタフェースの概要には、メッセージのタイプ、ポート・タイプ、およびバインディングが含まれます。具象インタフェースは含まれません。具象インタフェースは、サービスが配置されているトランスポートURLです。 |
動的ルーティングを使用すると、プロキシ・サービスの実行時に宛先を確定できます。これを行うには、XMLファイルのルーティング・テーブルを使用して、XQueryリソースを作成します。
|
注意: XQueryリソースを使用するかわりに、リソースの作成元のXMLファイルを直接使用することもできます。 |
XMLファイルまたはXQueryリソースは容易に保持できます。実行時に、プロキシ・サービスのルーティング先またはパブリッシュ先を決定するルーティング・テーブルにエントリを指定します。XMLファイルまたはXQueryリソースには、論理的な識別子(企業名など)を物理的な識別子(Oracle Service Busのサービスの完全修飾名)にマップするルーティング・テーブルが含まれています。メッセージから抽出された論理的な識別子は、呼び出すサービスの名前である物理的な識別子にマップされます。
|
注意: 動的ルート・アクションを使用するには、Oracle Service Busのサービスの完全修飾名が必要です。 |
パイプラインでは、論理的な修飾子はXPathを使用してメッセージに取得されます。XQueryリソースのXMLテーブルを変数に割り当てます。ルーティング・テーブルの変数に問合せを実装し、対応する論理的な修飾子に基づいて物理的な修飾子を抽出します。この変数を使用すると、必要なサービスを呼び出すことができます。以下の項では、動的ルーティングの実装方法を説明します。
以下のXMLファイルからXQueryリソースを作成できます。sampleXquery.xmlとしてこれを保存します。
サンプルXMLからXQueryリソースを作成するには:
アクティブ・セッションで、左側のナビゲーション・パネルから「プロジェクト・エクスプローラ」を選択します。「プロジェクト・ビュー」ページが表示されます。
XQueryリソースの追加先となるプロジェクトを選択します。
「プロジェクト・ビュー」ページで、「リソース・タイプの選択」リストから「XQueryリソース」を選択します。XQueryの作成ページが表示されます。
「リソース名」フィールドにリソースの名前を入力します。これは必須です。
「リソースの説明」フィールドにリソースの説明を入力します。これは省略可能です。
「XQuery」フィールドに、XQueryリソースとして使用するXMLへのパスを指定します。「参照」をクリックしてファイルを検索します。また、XMLをコピーして「XQuery」フィールドに貼り付けることもできます。これは必須です。
XQueryリソースを保存します。
セッションをアクティブ化します。
プロキシ・サービスを使用して動的ルーティングを実装するには:
アクティブ・セッションで、左側のナビゲーション・パネルから「プロジェクト・エクスプローラ」を選択します。「プロジェクト・ビュー」ページが表示されます。
プロキシ・サービスの追加先となるプロジェクトを選択します。
「プロジェクト・ビュー」ページで、「リソース・タイプの選択」リストから「プロキシ・サービス」リソースを選択します。「全般的な構成」ページが表示されます。
「全般的な構成」ページの「サービス名」フィールドに、プロキシ・サービスの名前を入力します。これは必須です。
「サービス・タイプ」で使用できる様々なサービスのタイプの横にあるボタンをクリックして、サービスのタイプを選択します。サービスのタイプの選択方法の詳細は、第22章「プロキシ・サービス: アクション」を参照してください。
「終了」をクリックします。「サマリー」ページで「保存」をクリックして、プロキシ・サービスを保存します。
「プロジェクト・ビュー」ページで、「リソース」表の新しく作成したプロキシ・サービスに対して「メッセージ・フローの編集」アイコンをクリックします。「メッセージ・フローの編集」ページが表示されます。
メッセージ・フローをクリックして、パイプライン・ペアをメッセージ・フローに追加します。
「リクエスト・パイプライン」アイコンをクリックし、メニューから「ステージの追加」を選択します。
「Stage1」アイコンをクリックし、メニューから「ステージの編集」を選択します。「ステージ構成の編集」ページが表示されます。
「アクションの追加」アイコンをクリックします。メニューから「アクションの追加」項目を選択します。
「メッセージ処理」から「割当て」アクションを選択します。
「式」をクリックします。XQuery式エディタが表示されます。
「XQueryリソース」をクリックします。ブラウザに、XQueryリソースをインポートできるページが表示されます。「参照」をクリックしてXQueryリソースを検索します。
「検証」をクリックしてインポートしたXQueryリソースを検証します。
検証が成功したら、インポートしたXQuery式を保存します。
「ステージ構成の編集」ページで、フィールドに変数の名前を入力します。
これにより、XQueryリソースがこの変数に割り当てられます。これで、この変数に外部化したルーティング・テーブルが格納されました。
別の「割当て」アクションを追加します。
以下のXQueryを入力します。
<ctx: route>
<ctx: service isProxy='false'> {$routingtable/row[logical/text()=$logicalidentifier]/physical/text()}
</ctx: service>
</ctx: route>
前述のコードで、$logicalidentifierを実際のXPathで置換して、メッセージ($bodyなど)から論理的な識別子を抽出します。
「検証」をクリックしてXQueryを検証します。
検証が成功したら、XQueryを保存します。
「ステージ構成の編集」ページで、フィールドに変数の名前(routeresultなど)を入力します。
これにより、動的ルート・アクションで使用するXMLがこの変数に抽出されます。
メッセージ・フローをクリックして、ルート・ノードをメッセージ・フローの最後に追加します。
「ルート・ノード」アイコンをクリックし、メニューから「編集」を選択します。
「アクションの追加」アイコンをクリックします。メニューから「アクションの追加」項目を選択します。
動的ルーティング・アクションを選択します。
「式」をクリックします。XQuery式エディタが表示されます。
変数($routeresultなど)を入力します。
Oracle Service Busでは、カスタムのEJBコードやJavaコードを記述したり、Oracle Data Service Integratorなどの別のデータベース製品を使用せずに、プロキシ・サービスからデータベースに対して読取りアクセスを行うことができます。execute-sql()関数を使用して、データベースに対して簡単なJDBC呼出しを行い、単純なデータベースの読取りを実行できます。指定した地域の税率を取得する単純な問合せや、複雑な結合を使用して、基になる複数のデータベース表から注文の現在の状態を取得する問合せなど、任意のSQL問合せが有効です。
データベース問合せを使用してデータを取得し、メッセージに情報を追加したり、ルーティング先を選択したり、プロキシ・サービスの動作をカスタマイズすることができます。Oracle Service Busプロキシ・サービスが「見積依頼」メッセージを受信する場合のシナリオを例として示します。プロキシ・サービスは、顧客の優先度に基づいて、見積りを提供する複数のビジネス・サービス(たとえば標準、ゴールド、プラチナ・レベルのサービス)のいずれかにリクエストをルーティングできます。その後で、プロキシ・サービスは、それらのサービスが返す結果をSQLベースで補強します。たとえば、選択した出荷方法と注文品の重量に基づいて送料を検索し、そのコストを見積依頼メッセージに追加することができます。
関数の構文とその使用例については、43.2.5項「fn-bea:execute-sql()」を参照してください。execute-sql()関数は型付きデータを返し、SQL/JDBCデータ・モデルとXQueryデータ・モデル間で値を自動的に変換します。
返された要素を、Oracle Service Busメッセージ・フローのユーザー定義の変数に格納できます。
execute-sql()関数でサポートされるデータベースおよびJDBCドライバは次のとおりです。
Oracle WebLogic Serverに含まれるサンプル・データベース。
IBM DB2/NT 8。XXXこれは、Windows NT 8.xまたは8.x以上の場合、場合によってはIBB DB2の可能性があります。
Microsoft SQL Server 2000、2005
Oracle8iリリース8.1.x
Oracle9i、Oracle Database 10g
Sybase 12.5.2および12.5.3。XXX製品について確認してください。Sybase Adaptive Serverの可能性があります。
WebLogic Type 4 JDBCドライバ。XXX Oracle WebLogic Server。
Oracle WebLogic Serverでサポートされるサード・パーティ製ドライバ
43.2.5項「fn-bea:execute-sql()」関数で使用するデータソースには、非XAドライバを使用してください。この関数は、データソースへの読取り専用アクセスをサポートしています。
|
注意: データベースへの接続に使用する非XA JDBCドライバ・クラスの指定に加え、グローバル・トランザクションと2フェーズ・コミットを必ず無効にする必要があります。(Oracle WebLogic Server管理コンソールで、グローバル・トランザクションはJDBCデータ・ソースに対してデフォルトでは有効です。)データ・ソースに対するこれらの指定は、Oracle WebLogic Server管理コンソールを介して行うことができます。Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソースの作成」を参照してください。 |
Oracle Service BusでサポートされているデータベースおよびJDBCドライバの詳細は、次のURLにあるOracle Fusion Middlewareのサポートされるシステム構成を参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
前述のリストに示したコア・セット以外のデータベースもサポートされています。ただし、前述のコア・データベースでは、非コア・データベースの場合よりも、XQueryエンジンが適切にデータ型を認識し、XQueryタイプにマップします。データを取得する際に、コア・データベースの独自のJDBC拡張が使用される場合もあります。非コア・データベースでは、XQueryエンジンは、JDBCドライバが提供する標準タイプのコード、および標準のJDBC結果セットのアクセス・メソッドに完全に依存します。
プロキシ・サービスを設計する際に、XQueryをリソースとして入力するのではなく、アクション定義の一部としてインラインで入力することができます。メッセージ・フローでIf...Then...アクションの条件にインラインXQueryを使用することもできます。インラインXQueryエディタの使用については、37.11.3項「変数の構造のマッピングの作成」を参照してください。
メッセージ・コンテキストは、Oracle Service Busを介してメッセージがルーティングされるときに、メッセージ・コンテキストとメッセージに関する情報を保持する一連の変数です。header、bodyおよびattachmentsの各変数(XQuery文では、$header、$bodyおよび$attachments)は、Oracle Service Busを介して流れるメッセージを表します。メッセージの標準書式はSOAPです。サービス・タイプがSOAPでなくても、メッセージはOracle Service Busのメッセージ・コンテキスト内でSOAPとして表示されます。
メッセージ・コンテキストでは、$headerにSOAP Header要素が格納され、$bodyにSOAP Body要素が格納されます。Header要素とBody要素は、プロキシ・サービスのサービス・タイプに応じてSOAP 1.1またはSOAP 1.2のネームスペースで修飾されます。また、メッセージ・コンテキストでは、$attachmentsにattachmentsと呼ばれるラッパー要素が含まれ、attachmentごとに1つのattachment子要素を持ちます。attachment要素には、body要素と実際の添付ファイルが含まれます。
プロキシ・サービスでメッセージを受信すると、メッセージのコンテンツを使用してheader変数、body変数およびattachments変数が初期化されます。SOAPサービスの場合、受信したSOAPメッセージのエンベロープからHeader要素およびBody要素が直接取得され、それぞれ$headerおよび$bodyに割り当てられます。非SOAPサービスの場合、通常はメッセージのコンテンツ全体がBody要素(SOAP 1.1ネームスペースで修飾)でラップされて$bodyに割り当てられ、空のHeader要素(SOAP 1.1ネームスペースで修飾)が$headerに割り当てられます。
バイナリ・メッセージとMFLメッセージは別の方法で初期化されます。MFLメッセージの場合、$bodyに割り当てられるBody要素には、MFLと同等のXMLドキュメントが挿入されます。バイナリ・メッセージの場合、メッセージ・データは内部的に格納され、$bodyに割り当てられるBody要素には参照XMLが挿入されます。参照XMLは<binary-content ref="..."/>のような形式になります。"..."には、プロキシ・サービスによって割り当てられる一意の識別子が入ります。
メッセージ・コンテキストは、XMLスキーマによって定義されます。プロキシ・サービスを定義するメッセージ・フローのコンテキスト変数を操作するには、XQuery式を使用する必要があります。
Oracle Service Busで事前定義されているコンテキスト変数は、以下のように分類されます。
メッセージ関連の変数
inbound変数およびoutbound変数
operation変数
fault変数
事前定義されたコンテキスト変数の詳細は、39.2項「事前定義されたコンテキスト変数」を参照してください。
$bodyには、メッセージのペイロード変数が含まれます。Oracle Service Busからメッセージをディスパッチするときに、送信メッセージに含める変数を決定できます。この決定は、ターゲット・エンドポイントがSOAPメッセージを受信するか非SOAPメッセージを受信するかによって異なります。
バイナリの場合、$bodyのBody要素に任意のテキストまたはXMLメッセージ・コンテンツが格納されて送信されます。
MFLメッセージの場合、$bodyのBody要素にMFLドキュメントと同等のXMLが格納されます。
テキスト・メッセージの場合、$bodyのBody要素にテキストが格納されます。テキスト添付では、$attachmentsのBody要素にテキストが格納されます。コンテンツがシンプル・テキストではなくXMLの場合、XMLはテキスト・メッセージとして送信されます。
XMLメッセージの場合、$bodyのBody要素にXMLが格納されます。XML添付では、$attachmentsのBody要素にXMLが格納されます。
SOAPメッセージは、<soap:Envelope>要素内のheader変数およびbody変数のコンテンツをラップすることで作成されます。SOAP 1.1ネームスペースはSOAP 1.1サービスに使用され、SOAP 1.2ネームスペースはSOAP 1.2サービスに使用されます。body変数に参照XMLが格納されている場合、この参照XMLが送信されます。つまり、参照されているコンテンツはメッセージに追加されません。
非SOAPサービスの場合、$bodyのBody要素にbinary-content要素が格納されると、ターゲット・サービスのタイプに関係なく、内部的に格納された参照先コンテンツがそのまま送信されます。
詳細は、第39章「メッセージ・コンテキスト」を参照してください。
メッセージ・コンテキスト変数の型は、メッセージ・コンテキスト・スキーマ(MessageContext.xsd)によって定義されます。Oracle XQuery Mapperでメッセージ・コンテキスト変数を操作する場合は、JARファイル(OSB_ORACLE_HOME/lib/sb-schemas.jar)に用意されたMessageContext.xsdと、次の場所にあるトランスポート固有のスキーマを参照する必要があります。
OSB_ORACLE_HOME/lib/transports/
メッセージ・コンテキスト・スキーマおよびトランスポート固有のスキーマの詳細は、39.10項「メッセージ・コンテキスト・スキーマ」を参照してください。
メッセージ・コンテキストを検査または変更するときには、以下のガイドラインを考慮してください。
XQuery式で変数の要素を参照する場合、その変数のルート要素はパスに含まれません。たとえば、次のXQuery式は、メッセージの最初の添付のContent-Descriptionを取得します。
$attachments/ctx:attachment[1]/ctx:content-Description
2番目の添付を取得するには、次のように記述します。
$attachments/ctx:attachment[2]/ctx:body/*
コンテキスト変数は空の場合もあれば、単一のXML要素または文字列値が格納されている場合もあります。ただし、多くの場合、XQuery式はシーケンスを返します。XQuery式を使用して値を変数に割り当てるとき、式によって返されるシーケンスの最初の要素のみが変数の値として格納されます。たとえば、SOAPヘッダーのWS-Addressing Message IDの値(ヘッダーに存在するものと仮定)をidvarという変数に割り当てる場合、割当てアクションを次のように指定します。
assign data($header/wsa:messageID to variable idvar
|
注意: 上記の例で2つのWS-Addressing MessageIDヘッダーが存在する場合、idvar変数には最初のMessageIDヘッダーの値が割り当てられます。 |
変数$header、$bodyおよび$attachmentsが空になることはありません。ただし、$headerには空のSOAP Header要素、$bodyには空のSOAP Body要素、$attachmentsには空のattachments要素がそれぞれ含まれる場合があります。
トランスフォーメーション・リソース(XSLTまたはXQuery)を使用する場合、トランスフォーメーション・リソースは、メッセージのSOAP本体のドキュメントを変換するように定義されます。このような場合、トランスフォーメーションの入力パラメータをXQuery式にすることで、トランスフォーメーションの簡易化および効率化を図ることができます。たとえば、次のXQuery式を使用して、トランスフォーメーションへの入力として、メッセージのBody要素($body)にビジネス・ドキュメントを渡すことができます。
$body/* [1]
トランスフォーメーションの結果は、置換アクションによって$bodyに戻すことができます。つまり、$bodyのコンテンツ(Body要素のコンテンツ)を置換します。詳細については、第11章「XQueryトランスフォーメーション」および第15章「XSLトランスフォーメーション」を参照してください。
挿入アクションまたは置換アクションを使用すると、単一の要素に対する挿入または置換だけでなく、選択した要素のシーケンスに対しても挿入または置換を行うことができます。要素のシーケンスを返すようXQuery式を構成できます。たとえば、挿入アクションおよび置換アクションを使用して、$inboundから$outboundに一連のトランスポート・ヘッダーをコピーすることができます。アクションを追加する方法については、22.1項「メッセージ・フローでのアクションの追加と編集」を参照してください。使用例については、37.10.3項「inboundからoutboundへのJMSプロパティのコピー」を参照してください。
プロキシ・サービスと呼び出されるビジネス・サービスのインタフェースが異なることが前提になっています。そのため、inbound変数からoutbound変数への情報(トランスポート・ヘッダーやJMSプロパティなど)の伝播は行われません。
プロキシ・サービスのリクエスト・メッセージとレスポンス・メッセージのトランスポート・ヘッダーは$inboundに含まれ、呼び出されるビジネス・サービスのリクエストとレスポンスのトランスポート・ヘッダーは$outboundに含まれます。
たとえば、一方向メッセージ(レスポンスのない呼出し)で、ユーザー定義のJMSプロパティをインバウンド・メッセージからアウトバウンド・メッセージにコピーする必要がある場合、次のXQuery式を使用できます。
トランスポート・ヘッダー・アクションを使用して、次を設定します
$inbound/ctx:transport/ctx:request/tp:headers/tp:user-header
次の最初の子として:
./ctx:transport/ctx:request/tp:headers
出力変数の中で。
トランスポート・ヘッダー・アクションの構成方法の詳細は、22.7項「トランスポート・ヘッダー・アクションの追加」を参照してください。
この項の内容は次のとおりです。
Oracle Service Busでは、Oracle XQuery Mapperなどの外部ツールで作成されたXQueryをインポートできます。これらのXQueryは、プロキシ・サービスのメッセージ・フローのどの場所でも使用できます。XQueryを使用するには、XQueryリソースの入力をインラインXQueryにバインドし、XQueryリソースの出力をアクションにバインドします。このアクションは、出力の結果を入力として使用する割り当て、置換、挿入などのアクションです。
ただし、XQueryをリソースとして入力するのではなく、アクションの定義の一部としてインラインで入力することができます。If...Then...アクションの条件にインラインXQueryを使用することもできます。
インラインXQuery式エディタは、以下で構成される簡単なXQueryを入力するときに使用します。
XQueryが埋め込まれたXMLフラグメント
child軸に沿った単純な変数パス
|
注意: より複雑なXQueryについては、XQueryに慣れていない場合は特に、XQuery Mapperを使用することをお薦めします。 |
インラインXQueriesは、次のような場合に使用すると効率的です。
インラインXQuery式エディタを使用して変数の構造を作成します。37.11.2項「変数の構造の使用」を参照してください。
$headerまたは$bodyに含まれるSOAPエンベロープの要素からビジネス・ドキュメントまたはRPCパラメータを抽出したり、アクセスします。
$attachmentsに含まれる添付ドキュメントを抽出したり、アクセスします。
サービス・コールアウト・アクションのパラメータをSOAPエンベロープから抽出して設定します。
サービス・コールアウト・アクションの結果パラメータをSOAPエンベロープに挿入します。
for loopを実行するためにSOAPエンベロープからシーケンスを抽出します。
更新アクションで、for loop内のシーケンスの項目を更新します。
Oracle Service Busでは、Oracle XQuery Mapperなどの外部ツールで作成されたXQueryをインポートできます。これらのXQueryは、プロキシ・サービスのメッセージ・フローのどの場所でも使用できます。XQueryを使用するには、XQueryリソースの入力をインラインXQueryにバインドし、XQueryリソースの出力をアクションにバインドします。このアクションは、出力の結果をアクション入力として使用する割当て、置換、挿入などのアクションです。ただし、XQueryをリソースとして入力するのではなく、アクションの定義の一部としてインラインで入力することができます。If...Then...アクションの条件にインラインXQueryを使用することもできます。
インラインXQueryエディタとインラインXPathエディタでは、変数の構造を型または要素にマップし、その構造のグラフィック表現からドラッグ・アンド・ドロップ操作によってパス式を作成することにより、変数の構造を宣言できます。また、パス式を手動で入力することもできます。
この機能は、すべてのユーザー定義変数と$inbound、$outboundおよび$faultに対して直接使用できます。ただし、この機能を使用して$attachmentsのXML添付ファイル、$headerのヘッダーまたは$bodyのドキュメントとRPCパラメータに直接アクセスすることはできません。例外として、WSDLプロキシ・サービスによって受信されたリクエスト・メッセージの$bodyのドキュメントとパラメータには直接アクセスできます。
変数の構造の作成方法の詳細は、37.11.3項「変数の構造のマッピングの作成」を参照してください。
XQueryエンジンのサポート、およびOracleの関数と演算子の関係の詳細は、第43章「XQueryの実装」を参照してください。
通常、インラインXQuery式エディタは、以下で構成される簡単なXQueryを入力するときに使用します。
XQueryが埋め込まれたXMLフラグメント
child軸に沿った単純な変数パス
|
注意: 複雑なXQueryには、ドラッグ・アンド・ドロップ機能を備えたOracle XQuery Mapperを使用することをお薦めします。『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のXQuery Mapperに関する項を参照してください。 |
インラインXQueryの適切な使用例は次のとおりです。
$headerまたは$bodyに含まれるSOAPエンベロープの要素からビジネス・ドキュメントまたはRPCパラメータを抽出したり、アクセスします。
$attachmentsに含まれる添付ドキュメントを抽出したり、アクセスします。
サービス・コールアウトのパラメータをSOAPエンベロープから抽出して設定します。
サービス・コールアウトの結果パラメータをSOAPエンベロープに挿入します。
for loopを実行するためにSOAPエンベロープからシーケンスを抽出します。
更新アクションで、for loop内のシーケンスの項目を更新します。
インラインXQuery式エディタを使用して、変数の構造を作成することもできます。詳細については、37.11.2項「変数の構造の使用」を参照してください。
インラインXQuery式エディタを使用すると、変数の構造を作成することができます。これにより、設計の目的で特定の変数の構造を定義できます。たとえば、XPath変数のXMLスキーマを表示するよりも、管理コンソールでXPath変数を参照する方が簡単です。
|
注意: ランタイムを作動させるために変数の構造を作成する必要はありません。変数の構造によって、変数の構造や変数パスが定義されますが、変数は作成されません。変数は実行時に、ステージ内にある割当てアクションの対象として作成されます。 |
一般的なプログラミング言語では、変数のスコープは静的です。変数の名前と型は明示的に宣言されます。静的なスコープ内の任意の場所から変数にアクセスできます。
Oracle Service Busにはいくつかの事前定義された変数が存在しますが、変数を動的に作成し、割当てアクションまたはforループ内のループ変数を使用して変数に値を割り当てることもできます。変数に値を割り当てると、プロキシ・サービスのメッセージ・フローの任意の場所から変数にアクセスできるようになります。変数の型は宣言されませんが、原則として、任意の時点で変数に格納されている基礎になる値の型が変数の型になります。
|
注意: forループの変数のスコープは制限されており、ステージ外からはアクセスできません。 |
インラインXQuery式エディタを使用すると、XQueryには0以上の入力と1つの出力が含まれます。式エディタ自体に入力と出力の構造を表示できるため、インラインXQueryを作成するときに、XMLスキーマまたはWSDLリソースを開いて構造を確認する必要はありません。構造が視覚的に表示されるため、作成中のXQueryに述部を指定せずに、child軸に沿って単純な変数パスをドラッグ・アンド・ドロップすることができます。
変数の構造のマッピングでは、各エントリはラベルを持ち、変数または変数パスを1つまたは複数の構造にマップします。これらのマッピングのスコープはステージまたはルート・ノードです。変数は静的に型指定されないので、1つの変数がステージまたはルート・ノードの様々な位置(または同じ位置)で複数の異なる構造を持つことができます。つまり、1つの変数または変数パスを複数の構造にマップし、それぞれに異なるラベルを使用することができます。構造を表示するには、リストで対応するラベルを選択します。
|
注意: インラインXPath式エディタでも変数の構造のマッピングを作成できます。ただし、変数または変数パスは構造にマップされますが、構造から選択したときに生成されるXPathは、変数を基準にした相対XPathです。./ctx:attachment/ctx:bodyは、相対XPathの一例です。 |
以下の項では、様々なタイプの変数の構造のマッピングを作成する方法について説明します。
このサンプルWSDLは、この項のほとんどの例で使用します。このWSDLをリソースとして構成に保存してください。詳細については、37.11.3.2項「例で必要なリソースの作成」を参照してください。
例37-17 サンプルWSDL
<definitions
name="samplewsdl"
targetNamespace="http://example.org"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:s0="http://www.oracle.com"
xmlns:s1="http://example.org"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<types>
<xs:schema
attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="http://www.oracle.com"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="PO" type="s0:POType"/>
<xs:complexType name="POType">
<xs:all>
<xs:element name="id" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
</xs:all>
</xs:complexType>
<xs:element name="Invoice" type="s0:InvoiceType"/>
<xs:complexType name="InvoiceType">
<xs:all>
<xs:element name="id" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
</xs:all>
</xs:complexType>
</xs:schema>
</types>
<message name="POTypeMsg">
<part name="PO" type="s0:POType"/>
</message>
<message name="InvoiceTypeMsg">
<part name="InvReturn" type="s0:InvoiceType"/>
</message>
<portType name="POPortType">
<operation name="GetInvoiceType">
<input message="s1:POTypeMsg"/>
<output message="s1:InvoiceTypeMsg"/>
</operation>
</portType>
<binding name="POBinding" type="s1:POPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetInvoiceType">
<soap:operation soapAction="http://example.com/GetInvoiceType"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
</definitions>
この後の例を利用するには、サンプルWSDLをリソースとして構成に保存し、サンプルWSDLを使用するサンプルのビジネス・サービスとプロキシ・サービスを作成します。
以下の手順に従って、Oracle Service Bus管理コンソールでタスクを実行します。
次のステップを実行します:
Oracle Service Bus管理コンソールの左側のナビゲーション・ペインで、「チェンジ・センター」の下にある「作成」をクリックして、現在の構成に変更を加えるための新しいセッションを作成します。
左側のナビゲーション・ペインで、「プロジェクト・エクスプローラ」をクリックします。
「プロジェクト・ビュー」ページで、WSDLの追加先となるプロジェクトをクリックします。
「プロジェクト・ビュー」ページの「リソースの作成」フィールドで、「インタフェース」の下にある「WSDL」を選択します。
「新しいWSDLリソースの作成。」ページの「リソース名」フィールドに「SampleWSDL」と入力します。このフィールドは必須です。
サンプルWSDLのテキストをコピーして「WSDL」フィールドに貼り付けます。
このフィールドは必須です。
「保存」をクリックします。新しいWSDL SampleWSDLがリソースのリストに追加され、現在のセッションで保存されます。次に、このWSDLを使用するプロキシ・サービスを作成する必要があります。37.11.3.2.2項「サンプルWSDLを使用するプロキシ・サービスの作成」を参照してください。
次のステップを実行します:
左側のナビゲーション・ペインで、「プロジェクト・エクスプローラ」をクリックします。
「プロジェクト・ビュー」ページで、プロキシ・サービスの追加先となるプロジェクトを選択します。
「プロジェクト・ビュー」ページの「リソースの作成」フィールドで、「サービス」の下にある「プロキシ・サービス」を選択します。
「プロキシ・サービスの編集 - 全般的な構成」ページの「サービス名」フィールドに、「ProxywithSampleWSDL」と入力します。このフィールドは必須です。
「サービス・タイプ」フィールドで、サービスで交換されるメッセージのタイプとパッケージ化を定義します。
「新しいサービスの作成」の下にある「WSDL Webサービス」を選択します。
「参照」をクリックします。WSDLブラウザが表示されます。
「SampleWSDL」を選択し、「WSDL定義の選択」ペインで「POBinding」を選択します。
「発行」をクリックします。
「全般的な構成」ページの他のすべてのフィールドをデフォルト値のままにし、「次へ」をクリックします。
「トランスポート構成」ページのすべてのフィールドをデフォルト値のままにし、「次へ」をクリックします。
「操作選択構成」ページで、「選択アルゴリズム」フィールドに「SOAP本体タイプ」が選択されていることを確認し、「次へ」をクリックします。
このプロキシ・サービスについてこれまでに入力した構成データを確認し、「保存」をクリックします。新しいプロキシ・サービスProxywithSampleWSDLがリソースのリストに追加され、現在のセッションで保存されます。このプロキシ・サービスのメッセージ・フローを構築するには、37.11.3.2.3項「サンプル・プロキシ・サービスのメッセージ・フローの構築」を参照してください。
次のステップを実行します:
「プロジェクト・ビュー」ページの「アクション」列で、ProxywithSampleWSDLプロキシ・サービスの「メッセージ・フローの編集」アイコンをクリックします。
「メッセージ・フローの編集」ページで、「ProxywithSampleWSDL」アイコンをクリックし、「パイプライン・ペアの追加」をクリックします。PipelinePairNode1が表示されます。ここには、リクエスト・パイプラインとレスポンス・パイプラインが含まれています。
「リクエスト・パイプライン」アイコンをクリックし、「ステージの追加」をクリックします。ステージ「Stage1」が表示されます。
「保存」をクリックします。ProxywithSampleWSDLプロキシ・サービスの基本的なメッセージ・フローが作成されます。
次のステップを実行します:
左側のナビゲーション・ペインで、「プロジェクト・エクスプローラ」をクリックします。「プロジェクト・ビュー」ページが表示されます。
ビジネス・サービスを追加するプロジェクトを選択します。
「プロジェクト・ビュー」ページの「リソースの作成」フィールドで、「サービス」の下にある「ビジネス・サービス」を選択します。「ビジネス・サービスの編集 - 全般的な構成」ページが表示されます。
「サービス名」フィールドに「BusinesswithSampleWSDL」と入力します。このフィールドは必須です。
「サービス・タイプ」フィールドでは、次のように、サービスで交換されるメッセージのタイプとパッケージ化を定義します。
「新しいサービスの作成」の下にある「WSDL Webサービス」を選択します。
「参照」をクリックします。WSDLブラウザが表示されます。
「SampleWSDL」を選択し、「WSDL定義の選択」ペインで「POBinding」を選択します。
「発行」をクリックします。
「全般的な構成」ページの他のすべてのフィールドをデフォルト値のままにし、「次へ」をクリックします。
「トランスポート構成」ページで、「エンドポイントURI」フィールドにエンドポイントURIを入力します。
「追加」をクリックし、「次へ」をクリックします。
「SOAPバインド構成」ページのすべてのフィールドにデフォルト値を使用します。
「次へ」をクリックします。
このビジネス・サービスについてこれまでに入力した構成データを確認し、「保存」をクリックします。新しいビジネス・サービスBusinesswithSampleWSDLがリソースのリストに追加され、現在のセッションで保存されます。
左側のナビゲーション・ペインで、「チェンジ・センター」の下にある「アクティブ化」をクリックします。セッションが終了し、構成がランタイムにデプロイされます。これで、例を使用する準備ができました。37.11.3.3項「例1: 事前定義された変数の構造の選択」に進みます。
この例では、プロキシ・サービスProxyWithSampleWSDLを使用して事前定義された変数の構造を選択します。このサービスのタイプは、SampleWSDLのバインディングPOBindingを使用するWSDL Webサービスです。
プロキシ・サービスのメッセージ・フローが、処理するメッセージの構造を認識している必要があります。このために、Oracle Service Busでは事前定義された構造が自動的に提供されます。この構造は、インタフェースのすべてのメッセージで、プロキシ・サービスのWSDLでの定義に従って、body変数をSOAP本体の構造にマップします。この事前定義された構造のマッピングのラベルはbodyです。
|
注意: この事前定義された構造は、型付きインタフェースを備えたメッセージング・サービスのためにもサポートされています。 |
事前定義された変数の構造を選択する手順:
XQuery式エディタ・ページの「変数の構造」パネルで、組込み構造のリストから「body」を選択します。
変数の構造bodyは、図37-4のように表示されます。
プロキシ・サービスProxyWithSampleWSDLが、ビジネス・サービスBusinessWithSampleWSDLへのサービス・コールアウトを呼び出すとします。このビジネス・サービスも、サービスのタイプはSampleWSDLのバインディングPOBindingを使用するWSDL Webサービスです。操作GetInvoiceTypeが呼び出されます。
この例では、メッセージ・フローが、処理するレスポンス・パラメータの構造を認識する必要があります。このためには、レスポンス・パラメータ変数を型InvoiceTypeにマップする新しい変数の構造を作成します。
変数を型にマップするには:
「変数の構造」パネルで「新しい構造の追加」をクリックします。追加フィールドが図37-5のように表示されます。
「XMLタイプ」を選択します。
「構造ラベル」フィールドに、作成する変数の構造の表示名として「InvoiceType」と入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。
「構造パス」フィールドに、実行時の変数の構造のパスとして「$InvoiceType」と入力します。
タイプ「InvoiceType」を選択するには、次のようにします。
「タイプ」フィールドで、該当するラジオ・ボタンを選択し、リストから「WSDLタイプ」を選択します。
「参照」をクリックします。WSDLブラウザが表示されます。
WSDLブラウザで「SampleWSDL」を選択してから、「WSDL定義の選択」ペインの「タイプ」で「InvoiceType」を選択します。
「発行」をクリックします。選択した「WSDLタイプ」の下に「InvoiceType」が表示されます。
「追加」をクリックします。新しい変数の構造「InvoiceType」が変数の構造のリストの「XMLタイプ」の下に追加されます。
変数の構造InvoiceTypeは、図37-6のように表示されます。
一時変数には、SampleWSDL WSDLで記述された要素Invoiceが含まれているとします。この例では、ProxyWithSampleWSDLメッセージ・フローは、この変数にアクセスする必要があります。このためには、変数を要素Invoiceにマップする新しい変数の構造を作成します。
変数を要素にマップする手順:
「変数の構造」パネルで「新しい構造の追加」をクリックします。
「XMLタイプ」を選択します。
「構造ラベル」フィールドに、作成する変数の構造の名前として、表示されたときに意味がわかるように「Invoice」と入力します。
「構造パス」フィールドに、実行時の変数の構造のパスとして「$Invoice」と入力します。
要素「Invoice」を選択するには、次のようにします。
「タイプ」フィールドで、該当するラジオ・ボタンを選択していることを確認します。「WSDL要素」を選択します。
「参照」をクリックします。
WSDLブラウザで「SampleWSDL」を選択してから、「WSDL定義の選択」ペインの「要素」で「Invoice」を選択します。
「発行」をクリックします。選択した「WSDL要素」の下に「Invoice」が表示されます。
「追加」をクリックします。新しい変数の構造「Invoice」が変数の構造のリストの「XMLタイプ」の下に追加されます。
変数の構造Invoiceは、図37-7のように表示されます。
プロキシ・サービスProxyWithSampleWSDLは、ドキュメント・スタイルがAny SOAPであるビジネス・サービスにルーティングします。このビジネス・サービスは、SOAP本体の発注書を返します。この例では、ProxyWithSampleWSDLプロキシ・サービスのメッセージ・フローが、そのレスポンスを処理する必要があります。このためには、body変数をPO要素にマップする新しい構造を作成し、PO要素を変数の子要素として指定します。body変数にはSOAP Body要素が格納され、PO要素はBody要素の子であるため、子要素として指定する必要があります。
変数を子要素にマップするには:
「変数の構造」パネルで「新しい構造の追加」をクリックします。
「XMLタイプ」を選択します。
「構造ラベル」フィールドに、作成する変数の構造の名前として、表示されたときに意味がわかるように「body to PO」と入力します。
「構造パス」フィールドに、実行時の変数の構造のパスとして「$body」と入力します。
PO要素を選択するには、次のようにします。
「タイプ」フィールドで、該当するラジオ・ボタンを選択していることを確認します。「WSDL要素」を選択します。
「参照」をクリックします。
WSDLブラウザで「SampleWSDL」を選択してから、「WSDL定義の選択」ペインの「要素」で「PO」を選択します。
「発行」をクリックします。
PO要素をbody to PO変数の構造の子として設定するために、「子として設定」チェックボックスを選択します。
「追加」をクリックします。新しい変数の構造「body to PO」が変数の構造のリストの「XMLタイプ」の下に追加されます。
変数の構造body to POは、図37-8のように表示されます。
プロキシ・サービスProxyWithSampleWSDLは、ビジネス・サービスBusinessWithSampleWSDLにメッセージをルーティングします。このビジネス・サービスも、サービスのタイプはSampleWSDLのバインディングPOBindingを使用するWSDL Webサービスです。この例では、メッセージ・フローがレスポンスを処理する必要があります。このためには、body変数をBusinessWithSampleWSDLビジネス・サービスにマップする新しい構造を定義します。これにより、サービスのWSDLインタフェースで、すべてのメッセージのSOAP本体にbody変数がマップされます。
|
注意: このマッピングは、型付きインタフェースを備えたメッセージング・サービスのためにもサポートされています。 |
変数をビジネス・サービスにマップする手順
「変数の構造」パネルで「新しい構造の追加」をクリックします。
「サービス・インタフェース」を選択します。
「構造ラベル」フィールドに、変数の構造の名前として、表示されたときに意味がわかるように「BusinessService」と入力します。
「構造パス」フィールドには、デフォルトとしてすでに$bodyが設定されています。これは、実行時の変数の構造のパスになります。
このビジネス・サービスを選択するには、以下の操作を実行します。
「サービス」フィールドで、「参照」をクリックします。サービス・ブラウザが表示されます。
サービス・ブラウザでBusinessWithSampleWSDLビジネス・サービスを選択し、「発行」をクリックします。ビジネス・サービスが「サービス」フィールドの下に表示されます。
「操作」フィールドで、「すべて」を選択します。
「追加」をクリックします。新しい変数の構造BusinessServiceが変数の構造のリストの「サービス・インタフェース」の下に追加されます。
変数の構造BusinessServiceは、図37-9のように表示されます。
ProxyWithSampleWSDLプロキシ・サービスが単一の添付ファイルを受信するように、SampleWSDLを変更します。添付ファイルは発注書です。この例では、プロキシ・サービスのメッセージ・フローが発注書を処理する必要があります。このためには、$attachmentsのbody要素を、子要素として指定されているPO要素にマップする新しい構造を定義します。body要素は、次の形式の変数パスとして指定されます。
$attachments/ctx:attachment/ctx:body
事前定義されたattachments構造のbody要素を選択してコピーし、新しいマッピング定義でマップされる変数パスとして貼り付けます。
子要素を別の子要素にマップするには:
「変数の構造」パネルで、組込み構造のリストから「attachments」を選択します。
変数の構造attachmentsは、図37-10のように表示されます。
attachments構造でbody子要素を選択します。ページの右側にあるプロパティ・インスペクタにbody要素の変数パスが表示されます。
$attachments/ctx:attachment/ctx:body
body要素の変数パスをコピーします。
「変数の構造」パネルで「新しい構造の追加」をクリックします。
「XMLタイプ」を選択します。
「構造ラベル」フィールドに、この変数の構造の名前として、表示されたときに意味がわかるように「PO attachment」と入力します。
「構造パス」フィールドに、body要素の変数パスを貼り付けます。
$attachments/ctx:attachment/ctx:body
これは、実行時の変数の構造のパスになります。
PO要素を選択するには、次のようにします。
「タイプ」フィールドで、該当するラジオ・ボタンを選択していることを確認し、「WSDL要素」を選択します。
「参照」をクリックします。
WSDLブラウザで「SampleWSDL」を選択してから、「WSDL定義の選択」ペインの「要素」で「PO」を選択します。
「発行」をクリックします。
body要素の子としてPO要素を設定するために、「子として設定」チェックボックスを選択します。
「追加」をクリックします。新しい変数の構造「PO attachment」が変数の構造のリストの「XMLタイプ」の下に追加されます。
複数の添付ファイルを使用する場合は、この構造化変数のフィールドをXQueryで使用するときに、索引を参照に追加します。たとえば、POフィールドをXQueryフィールドにドラッグしてPOを2番目の添付にする場合は、挿入した値を変更します。
$attachments/ctx:attachment/ctx:body/oracle:PO/oracle:id
これを次のように変更します。
$attachments/ctx:attachment[2]/ctx:body/oracle:PO/oracle:id
以下の項では、Oracle Service Busメッセージングのサービス品質機能について説明します。
Oracle Service Busでは、信頼性のあるメッセージングがサポートされます。メッセージがルート・ノードから別のサービスにルーティングされるとき、プロキシ・サービスがトランザクションに対応するよう構成されている場合、デフォルトのサービス品質(QoS)は「必ず1回」です。それ以外の場合、「ベスト・エフォート」QoSがサポートされます。
サービスの品質は、$outboundコンテキスト変数のqualityOfService要素で設定されます。
Oracle Service Busに用意されている配信の保証のタイプを表37-10に示します。
表37-10 配信の保証のタイプ
| 配信の信頼性 | 説明 |
|---|---|
|
必ず1回 |
「必ず1回」の信頼性では、アウトバウンド・メッセージの送信が開始されるまで終了エラーが発生しないことを前提として、メッセージがインバウンドからアウトバウンドに1回のみ配信されます。「必ず1回」は、信頼性が最適化されることを意味します。 「必ず1回」の配信の信頼性は提案であり、命令ではありません。「必ず1回」を指定すると、可能な場合に「必ず1回」の信頼性が提供されます。「必ず1回」が不可能な場合は、「少なくとも1回」の配信セマンティクスが試行され、これも不可能な場合は「ベスト・エフォート」の配信が実行されます。 トランザクションに対応するよう構成されているプロキシ・サービスのサービス品質は、「必ず1回」です。 次のインバウンド・トランスポートでも、ルート・ノード・アクションの
注意: |
|
少なくとも1回 |
「少なくとも1回」のセマンティクスは、アウトバウンド・メッセージの送信が開始されるまで終了エラーが発生しないことを前提として、メッセージがインバウンドからアウトバウンドに少なくとも1回は配信されることを意味します。ターゲット・サービスがトランスポートレベルのエラーとともにレスポンスを返した場合でも、配信は成功と見なされます。ただし、タイムアウト、接続エラー、または通信リンクの中断が発生した場合は成功とは見なされません。フェイルオーバーURLが指定されている場合は、少なくとも1つのURLについて「少なくとも1回」のセマンティクスが提供されます。 「必ず1回」が不可能であるが、 |
|
ベスト・エフォート |
「ベスト・エフォート」は、信頼性のあるメッセージングが存在せず、重複するメッセージが除去されないが、パフォーマンスは最適化されることを意味します。 次のインバウンド・トランスポートの場合、ルート・ノードの
次の場合、
注意: パブリッシュ・アクションで |
他のトランスポートのサービスの品質の詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のトランスポートに関する項を参照してください。
デフォルトの「必ず1回」サービスの品質属性をオーバーライドするには、アウトバウンド・メッセージのコンテキスト変数($outbound)でqualityOfServiceを設定する必要があります。詳細については、39.10項「メッセージ・コンテキスト・スキーマ」を参照してください。
次のメッセージ・フロー・アクションの場合、デフォルトのqualityOfService要素属性をオーバーライドできます。
パブリッシュ
動的にパブリッシュ
パブリッシュ表
サービス・コールアウト
ルーティング
動的ルーティング
ルーティング表
qualityOfService要素属性をオーバーライドするには、前述の任意のアクションにルーティング・オプション・アクションを追加し、QoSオプションを選択し、オーバーライド値を選択します。
メッセージ・コンテキスト変数の詳細は、39.10項「メッセージ・コンテキスト・スキーマ」を参照してください。
プロキシ・サービスがメッセージをパブリッシュするか、リクエストをビジネス・サービスにルーティングするときは、次の条件に応じて配信の保証がサポートされます。
qualityOfService要素の値
インバウンド・トランスポート(および該当する場合は接続ファクトリ)
アウトバウンド・トランスポート(および該当する場合は接続ファクトリ)
ただし、インバウンド・プロキシ・サービスがローカル・トランスポートで、呼出し元が別のプロキシ・サービスである場合、呼出し元のプロキシ・サービスのインバウンド・トランスポートが配信の保証を行います。呼び出されたプロキシ・サービスのトランスポートがローカル・トランスポートの場合、呼出し元のプロキシ・サービスが最適化されて、直接呼出しになるためです。転送プロトコルの詳細は、第20章「プロキシ・サービス: 作成と管理」および第19章「ビジネス・サービス: 作成と管理」を参照してください。
|
注意: プロキシ・サービスからのレスポンスには配信の保証はありません。 |
配信の保証に適用されるルールを表37-11に示します。
表37-11 配信の保証のルール
| 提供される配信の保証 | ルール |
|---|---|
|
必ず1回 |
プロキシ・サービスのインバウンド・トランスポートはトランザクションに対応し、アウトバウンド・トランスポートへの |
|
少なくとも1回 |
プロキシ・サービスのインバウンド・トランスポートはファイル、FTP、または電子メールで、 |
|
少なくとも1回 |
プロキシ・サービスのインバウンド・トランスポートはトランザクションに対応し、トランザクション非対応のアウトバウンド・トランスポートへの |
|
配信の保証なし |
その他の場合(すべてのレスポンス処理を含む)。 |
|
注意: JMSにより配信の保証として「少なくとも1回」および「必ず1回」をサポートするには、JMSトランザクションを利用し、サーバーがクラッシュした場合、または返信アクションや再開アクションのエラー・ハンドラで処理できないエラーが発生した場合にメッセージを再配信できるように、JMSキューの再試行回数と再試行間隔を構成する必要があります。ファイル、FTP、および電子メール・トランスポートでも、内部ではJMS/XAキューが使用されます。JMS/XAトランスポートを使用したプロキシ・サービスのデフォルトの再試行回数は1です。Oracle Service Busで作成されるデフォルトのJMSキューのリストについては、『Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド』を参照してください。 |
配信の保証のその他のルールは次のとおりです。
インバウンド・プロキシ・サービスのトランスポートでトランザクションが伝播または開始される場合、リクエスト処理は1つのトランザクションで実行されます。
qualityOfService要素がexactly-onceに設定されている場合、トランザクション対応の宛先へのリクエスト・フローで実行されるルート・ノード・アクションは、すべて同一トランザクションで実行されます。トランザクション・コンテキスト内のパブリッシュ・アクションとサービス・コールアウト・アクションは、デフォルトでは「ベスト・エフォート」であるため、トランザクション・コンテキスト外で実行されます。これらのアクションを「必ず1回」に設定すると、トランザクション・コンテキスト内で実行されます。
ルート・ノードの任意のアクションのqualityOfService要素がbest-effortに設定されている場合、サービス・コールアウト・アクションまたはパブリッシュ・アクションは、リクエスト・フロー・トランザクションの外部で実行されます。具体的には、JMS、Tuxedo、トランザクション対応のTuxedo、またはEJBの各トランスポートで、リクエスト・フロー・トランザクションが中断されます。トランザクション対応のTuxedoの処理はトランザクションなしで実行されるか、すぐにコミットされる別のトランザクションで実行されます。
リクエストの処理中にエラーが発生しても、(再開アクションまたは返信アクションを使用して)エラーを管理するユーザーのエラー・ハンドラで捕捉されると、メッセージは正常に処理されたと見なされ、トランザクションはコミットされます。トランザクションが中断されるのは、システム・エラー・ハンドラがエラーを受け取る場合、つまりエラーが処理されずにシステム・レベルに届く場合です。また、リクエスト・パイプラインの処理中にサーバー障害が発生した場合もトランザクションが中断されます。
ビジネス・サービスに対してJMS/XAトランスポートを使用するプロキシ・サービスがレスポンスを受信する(かつプロキシのインバウンドがトランザクション対応のTuxedoではない)場合、レスポンス処理は1つのトランザクションで実行されます。
qualityOfService要素が exactly-onceに設定されている場合、すべてのルート・アクション、サービス・コールアウト・アクション、およびパブリッシュ・アクションは同じトランザクションで実行されます。
qualityOfService要素がbest-effortに設定されている場合、すべてのパブリッシュ・アクションとサービス・コールアウト・アクションは、レスポンス・フロー・トランザクションの外部で実行されます。特に、JMS、EJB、またはトランザクション対応のTuxedoのタイプのトランスポートの場合、レスポンス・フロー・トランザクションは中断され、サービス呼出しの処理はトランザクションなしで、またはすぐにコミットされる別のトランザクションで実行されます。
JMS/XA宛先へのレスポンス・フローで実行されるプロキシ・サービスのレスポンスは、qualityOfService要素の設定に関係なく、常に同じトランザクションで実行されます。
プロキシ・サービスのインバウンド・トランスポートがトランザクション対応のTuxedoであるか、プロキシ・サービスの「レスポンスに同じトランザクション」オプションを設定している場合、リクエスト処理とレスポンス処理はともにこのトランザクションで実行されます。
|
注意: インバウンド・トランスポートがトランザクション対応のTuxedoで、アウトバウンドがJMS/XAなどの非同期トランスポートの場合、実行時エラーが発生します。 |
Oracle Service Busのスレッディング・モデルは次のように作動します。
プロキシ・サービスのリクエスト・フローとレスポンス・フローが別のスレッドで実行します。
サービス・コールアウトは常にブロックします。qualityOfService要素の値がbest-effortの場合、HTTPルート・アクションまたはパブリッシュ・アクションはブロックしません(リクエスト/レスポンスまたは一方向呼出しの場合)。
JMSルート・アクションまたはパブリッシュ・アクションは常にブロックしません。ただし、Oracle Service Busには永続メッセージ処理状態がないため、リクエストが送信された後でサーバーが再起動するとレスポンスが失われます。
|
注意: リクエスト・フローまたはレスポンス・フローのパブリッシュ・アクションでは、レスポンスは常に破棄されます。これは、パブリッシュ・アクションは本質的に一方向のメッセージ送信であるためです 。 |
以下の場合に、プロキシ・サービスの分割を検討してください。
HTTPがプロキシ・サービスのインバウンドおよびアウトバウンド・トランスポートであるとき、メッセージ・フローの途中に高信頼性を組み込みます。このようにして高信頼性を実現するには、プロキシ・サービスを、フロント・エンドHTTPプロキシ・サービスと、HTTPアウトバウンド・トランスポートを使用するバックエンドJMS (一方向またはリクエスト/レスポンス)プロキシ・サービスに分割します。エラー発生時には、メッセージの損失を回避できるように、最初のプロキシ・サービスがメッセージを2番目のプロキシ・サービスのキューにすぐに入れる必要があります。
プロキシ・サービス(たとえばloanGateway1)が別のプロキシ・サービス(たとえばloanGateway2)を呼び出すときに、JMS以外のトランスポートについて直接呼出しの最適化を無効にするには次のようになります。プロキシ・サービスloanGateway1からプロキシ・サービスloanGateway2にルーティングします(プロキシ・サービスloanGateway2がJMSトランスポートを使用する場合)。
HTTPプロキシ・サービスでJMSキューにパブリッシュするときに、リクエスト処理において後で例外が発生した場合にパブリッシュ・アクションをロールバックするには、プロキシ・サービスをフロント・エンドHTTPプロキシ・サービスとバックエンドJMSプロキシ・サービスに分けます。パブリッシュ・アクションでは、qualityOfService要素にexactly-onceを指定し、XA接続ファクトリを使用します。
JMSを使用してメッセージのインバウンドの再試行を構成するだけでなく、アウトバウンドの再試行およびロード・バランシングも構成できます。ロード・バランシング、フェイルオーバー、および再試行の組合せによって、パフォーマンスと高可用性を実現できます。各メッセージのフェイルオーバーURLとして指定したURLのリストは、ロード・バランシング・アルゴリズムに基づいて自動的に並べ替えられ、フェイルオーバーのシーケンスが形成されます。再試行回数がNの場合、シーケンス全体がN回再試行されてから終了します。システムは指定された再試行間隔の時間だけ待機してから、シーケンスの次のループを開始します。再試行回数が完了してもまだエラーがある場合、ルート・ノードのエラー・ハンドラ・パイプラインが呼び出されます。エラー・ハンドラ・パイプラインの詳細は、24.3項「パイプライン・エラー・ハンドラの追加」を参照してください。
|
注意: HTTPトランスポートの場合、Oracle Service Busでは200または202以外のHTTPステータスはエラーと見なされるため、再試行する必要があります。このアルゴリズムにより、Oracle Service Busでは、解決することのできない認証エラーなどのエラーを、そのURLで一定期間再試行することが可能です。これに対して、Oracle Service Busで任意のメッセージの送信を再試行するときに別のURLにフェイルオーバーする場合は、新しいURLではエラーにならない可能性があります。
|
Oracle WebLogic Serverは、アプリケーションとWebサービス環境のパフォーマンスを最適化し、ワーク・マネージャという機能を使用してサービス・レベル・アグリーメントを保持する際に役立ちます。ワーク・マネージャのリソースを作成し、作業実行ルールを定義することによって、作成したリソースを構成します。Oracle WebLogic Serverではワーク・マネージャのルールを使用して、作業の優先順位を付け、ワーク・マネージャが配置されているどのようなアプリケーションやコンポーネントにもスレッドを割り当てることができます。
ワーク・マネージャの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する説明を参照してください。
Oracle Service Busでは、プロキシ・サービスおよびビジネス・サービスのいくつかのトランスポートで、ワーク・マネージャとサービスを関連付けてサービス作業の優先順位を付けることができる、「ディスパッチ・ポリシー」という構成オプションが提供されます。この項では、プロキシ・サービスとビジネス・サービスでワーク・マネージャを使用する方法について説明します。
Oracle Service Busプロキシ・サービスのディスパッチ・ポリシーを構成することで、起動とリクエスト・パイプラインの実行はワーク・マネージャのルールによって制御されます。たとえば、最大制約が5のディスパッチ・ポリシーを使用したプロキシ・サービスの場合、そのプロキシ・サービスでは同時に5つのリクエスト・パイプライン・タスクしか実行できません。
リクエスト・パイプラインがプロキシ・サービスのディスパッチ・ポリシーによって制御されるのに対し、レスポンス・パイプラインはビジネス・サービスまたは分割-結合のディスパッチ・ポリシーによって制御されます。RouteToアクションでは、メッセージのルーティング先のビジネス・サービスまたは分割-結合を指定し、レスポンスには指定したビジネス・サービスまたは分割-結合のすべてのディスパッチ・ポリシーが適用されます。
RouteToアクションでローカル・プロキシ・サービスを指定した場合、元のプロキシのディスパッチ・ポリシーがローカル・プロキシのリクエスト・パイプラインで実行される作業に適用されます。ローカル・プロキシまたはローカル・プロキシのチェーンが、ビジネス・サービスまたは分割-結合を呼び出すRouteToアクションに達すると、ビジネス・サービス、分割-結合および後続のすべてのレスポンス・パイプラインが、呼び出されたビジネス・サービスまたは分割-結合のディスパッチ・ポリシーによって制御されます。
リクエストでエラーが発生すると、エラー・レスポンスは同じスレッド内でリクエスト・パイプラインとして処理されます。
アウトバウンド・メタデータで指定したサービス品質(QoS)は、リクエストをスレッド化する方法に影響を与える可能性があるため、ワーク・マネージャを監視する際の表示内容にも影響します。RouteToアクションでのQoSは、デフォルトではインバウンドQoSに設定されています。たとえば、JMS/XA、SB、Tuxedo、WS(WS-RM)などトランザクション対応の一部のインバウンド・トランスポートでは、QoSは「必ず1回」に設定されます。HTTPなどのその他のインバウンド・トランスポートでは、QoSはデフォルトで「ベスト・エフォート」に設定されます。RouteToアクションでのQoSは、RouteToアクションのユーザー設定でオーバーライドされない限り、インバウンドから継承されます。
「ベスト・エフォート」を使用すると、ルート・ノードはビジネス・サービスを非同期に呼び出します。「ベスト・エフォート」の場合は、ワーク・スレッドはプールに戻され、レスポンスを待機しないため、非同期に戻される予定の保留中の作業がある場合でも、ワーク・マネージャの制約に対してスレッドがカウントされることはありません。しかし、「必ず1回」を選択すると、リクエスト・スレッドによってリクエストが送信され、レスポンスの待機がブロックされて、ワーク・マネージャの制約に対してスレッドがカウントされます。「必ず1回」の場合は、待機中のスレッドはプロキシ・サービスに割り当てられたワーク・マネージャに適用されます。肯定レスポンスが届くと、新規スレッドにより、ビジネス・サービスまたは分割-結合に割り当てられたディスパッチ・ポリシーを使用して、そのレスポンス・パイプラインが処理されます。
「必ず1回」を指定することは、パフォーマンス、メモリーおよびスレッドの視点から費用がかかりますが、トランザクション対応のインバウンド・リソースおよびアウトバウンド・リソースにおける整合性を維持するためには必要です。
QoSの詳細は、37.12項「サービスの品質」を参照してください。
Oracle Service Busでは、異種のエンドポイント間での相互運用性を確保するため、コンテンツ・タイプ、JMSタイプ、およびエンコーディングをそれぞれ制御できます。
Oracle Service Busでは外部のクライアントまたはサービスに必要な情報が想定されませんが、サービス定義で構成済みの情報が使用されます。アウトバウンド・メッセージのコンテンツ・タイプは、サービス・タイプとインタフェースから派生します。コンテンツ・タイプは、電子メールおよびHTTPプロトコルの一部です。
サービス・タイプごとのコンテンツ・タイプを以下に示します。
XMLまたはSOAP (WSDLの有無を問わない)の場合、コンテンツ・タイプはtext/XML。
インタフェースがMFLまたはバイナリのメッセージングの場合、コンテンツ・タイプはbinary/octet-stream。
インタフェースがテキストのメッセージングの場合、コンテンツ・タイプはtext/plain。
インタフェースがXMLのメッセージングの場合、コンテンツ・タイプはtext/XML
インタフェースがJavaのメッセージングの場合、コンテンツ・タイプはJavaオブジェクト。
また、JMSタイプには、Java型以外のメッセージ用のバイトまたはテキストを指定できます。Oracle Service Bus管理コンソールまたはEclipse用Oracle Service Busプラグインでサービスを定義する際に使用する、JMSタイプを構成します。
サービスを呼び出すプロキシ・サービスのアウトバウンド・コンテキスト変数($outbound)のコンテンツ・タイプ、およびプロキシ・サービス・レスポンスのインバウンド・コンテキスト変数($inbound)のコンテンツ・タイプはオーバーライドできます。$outboundコンテキスト変数と$inboundコンテキスト変数の詳細は、39.4項「inbound変数とoutbound変数」を参照してください。
すべてのアウトバウンド・メッセージについて、サービス定義でエンコーディングも明示的に構成されます。サービス定義の詳細は、第20章「プロキシ・サービス: 作成と管理」および第19章「ビジネス・サービス: 作成と管理」を参照してください。
Oracle Service Busでは、ビジネス・サービスへのメッセージ・フローを制限できます。このビジネス・サービスへのメッセージ・フローを制限する技術は、スロットルと呼ばれます。詳細は、第50章「スロットル」を参照してください。
Oracle Service Busは、実行時環境でSOAP 1.1サービスへのWebサービス相互運用性(WS-I)準拠を提供します。WS-Iの基本プロファイルの目的を以下に示します。
WSDLとSOAPの仕様の曖昧な部分を明確にします。
相互運用性を拡張するために、メッセージの受信やWSDLのインポートに適用できる制約を定義します。メッセージを送信するときは、制約を満たすようにメッセージを構成します。
WS-I基本プロファイルは、http://www.ws-i.org/Profiles/BasicProfile-1.1.htmlにあります。
WSDLに基づいてプロキシ・サービスまたはビジネス・サービスを構成する場合、Oracle Service Bus管理コンソールまたはEclipse用Oracle Service Busプラグインを使用して、Oracle Service BusでそのサービスにWS-I準拠を適用するかどうかを指定できます。この方法については、20.2.17項「「操作選択構成」ページ」を参照してください。
プロキシ・サービスのWS-I準拠を構成すると、そのプロキシ・サービスが受信するインバウンド・リクエスト・メッセージでチェックが実行されます。呼び出されたサービスについてWS-I準拠を構成すると、その呼び出されたサービスからのレスポンス・メッセージを任意のプロキシが受信したときに、チェックが実行されます。デフォルトでは、プロキシ・サービスのSOAPクライアントはシステム・エラー・ハンドラ定義のエラーを受け取るため、このようなエラーに対応するエラー・ハンドラを作成することをお薦めします。エラー・ハンドラの作成方法の詳細は、以下を参照してください。
『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のメッセージ・フローへのエラー・ハンドラの追加と構成に関する項
プロキシ・サービスから送信されるメッセージについては、それがアウトバウンド・リクエストでもインバウンド・レスポンスでも、WS-I準拠のチェックは明示的には実行されません。これは、ほとんどのメッセージ・コンテンツの生成はパイプライン設計者によって行われるためです。ただし、メッセージのOracle Service Busによって生成される部分は、サポートされるWS-I準拠のすべてのチェックを満たします。以下のコンテンツが含まれます。
サービス呼出しリクエスト・メッセージ
プロキシ・サービスによって返されるシステム生成のエラー・メッセージ
プロキシ・サービスによって生成されるHTTPステータス・コード
「WS-I準拠の適用」チェックボックスは、図37-11のように表示されます。
|
注意: WS-I準拠チェックでは、サービスで呼び出される操作をシステムが認識する必要があります。つまり、プロキシ・サービスが受信するリクエスト・メッセージでは、コンテキスト変数$operationはnull以外の値であることが必要です。そのためには、操作選択アルゴリズムが適切に構成されていることが前提になります。呼び出されたサービスから受信するレスポンス・メッセージでは、ルート、パブリッシュ、およびサービス・コールアウトのアクション構成で操作が指定されている必要があります。 |
プロキシ・サービスまたはビジネス・サービスのWS-I準拠チェックを構成すると、Oracle Service Busで表37-12に示すチェックが実行されます。
表37-12 Oracle Service BusのWS-I準拠チェック
| チェック | WS-I基本プロファイルの詳細 | 説明 |
|---|---|---|
|
3.1.1 SOAPエンベロープ構造 |
R9980 エンベロープは、SOAP 1.1、第4項「SOAP Envelope」に指定された構造に準拠する必要があります(修正対象)。 |
このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。レスポンス・メッセージがチェックされ、メッセージに外部 |
|
3.1.2 SOAPエンベロープ・ネームスペース |
R1015 受信側は、ドキュメント要素が |
このチェックはリクエスト・メッセージとレスポンス・メッセージに適用されます。これは、3.1.1 SOAPエンベロープ構造に関連しています。リクエスト・メッセージのローカル名が |
|
3.1.3 SOAP Bodyのネームスペース修飾 |
R1014 エンベロープの |
このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。すべてのリクエスト・エラー・メッセージで |
|
3.1.4 許可されない構成 |
R1008 エンベロープは文書型宣言を含むことはできません。 |
このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。すべてのリクエスト・エラー・メッセージで |
|
3.1.5 SOAPトレーラ |
R1011 エンベロープでは、 |
このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。すべてのリクエスト・エラー・メッセージで |
|
3.1.9 SOAP 1.1要素のSOAP属性 |
R1032 エンベロープの |
このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。任意のリクエスト・エラー・メッセージで |
|
3.3.2 SOAP Faultの構造 |
R1000 エンベロープがFaultの場合、 |
このチェックは、レスポンス・メッセージのみに適用されます。 |
|
3.3.3 SOAP Faultのネームスペース修飾 |
R1001 エンベロープがFaultの場合、 |
このチェックは、レスポンス・メッセージのみに適用されます。 |
|
3.4.6 HTTPクライアント・エラー・ステータス・コード |
R1113 HTTPリクエスト・メッセージの形式に誤りがある場合、インスタンスは「 R1114 HTTPリクエスト・メッセージの形式に誤りがある場合、インスタンスは「 R1125 リクエストのフォーマットに問題があることを示すレスポンスについては、インスタンスは4xx HTTPステータス・コードを使用する必要があります。 |
リクエストのエラーで返されるステータス・コードを変更できない場合、プロキシ・サービスのレスポンスのみに適用されます。 |
|
3.4.7 HTTPサーバー・エラー・ステータス・コード |
R1126 レスポンス・エンベロープがFaultの場合、インスタンスは「 |
このチェックは、リクエスト・メッセージとレスポンス・メッセージに別の方法で適用されます。リクエスト・メッセージの場合、生成されたフォルトには「 |
|
4.7.19 レスポンス・ラッパー |
R2729 rpc-literalバインディングで記述されたエンベロープがレスポンスである場合、対応する |
このチェックは、レスポンス・メッセージのみに適用されます。Oracle Service Busでは、プロキシ・サービスからFault以外のレスポンスを生成することはありません。 |
|
4.7.20 パート・アクセッサ |
R2735 rpc-literalバインディングで記述されたエンベロープでは、ネームスペースにないパラメータと戻り値のパート・アクセッサ要素を配置する必要があります。 R2755 rpc-literalバインディングで記述されたメッセージのパート・アクセッサ要素は、対応する |
このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。任意のリクエスト・エラー・メッセージで |
|
4.7.22 必須ヘッダー |
R2738 エンベロープは、エンベロープを記述する |
このチェックは、リクエスト・メッセージとレスポンス・メッセージに適用されます。任意のリクエスト・エラー・メッセージで |
|
4.7.25 SOAPActionの記述 |
R2744 HTTPリクエスト・メッセージは、SOAPAction HTTPヘッダー・フィールドに、 R2745 HTTPリクエスト・メッセージは、 |
このチェックはリクエスト・メッセージに適用され、 |
Oracle Service Busは、SOAP 1.1とSOAP 1.2をサポートしています。SOAP 1.1プロキシ・サービスでSOAP 1.2ビジネス・サービスを呼び出すことも、その逆の呼出しを行うこともできます。しかし、SOAP 1.1と1.2に違いがあるため、Oracle Service Busは一部の状況で2つのSOAP間での自動変換を実行できません。SOAP 1.1と1.2の変換を適切に使用するには、以下のガイダンスを使用してください。
ビジネス・サービスを呼び出す前に、Oracle Service BusによりSOAPネームスペースは自動的に変更されます。ビジネス・サービスからフォルトが返された場合、プロキシ・サービスのSOAPバージョンに自動的に変更されます。ただし、この処理は2つのバージョン間のSOAPヘッダー関連のXML属性(MustUnderstandなど)をマップするパイプライン・アクションに依存します。また、エンコードされたエンベロープのSOAPエンコードされたネームスペースの変更も、パイプライン・アクションに依存します。
ペイロードがdoc/またはrpc/リテラル・エンコーディングを使用する場合のみ、SOAP 1.1からSOAP 1.2での自動変換が正常に機能します。
SOAP 1.1では、encodingStyle属性はエンベロープの任意の要素に許可されます。SOAP 1.2では、encodingStyle属性は本文の子要素のみ許可されます。SOAP 1.1のencodingStyle属性が本文の子要素、ヘッダー、およびフォルト詳細以外で存在する場合、SOAP 1.1からSOAP 1.2への自動的な変換によって、無効エンベロープが生じる場合があります。有効なエンベロープを確保するには、プロキシ・サービス・パイプラインでSOAP変換を実行する必要があります。
SOAP 1.1とSOAP 1.2サービスがrpc/encodedからdoc/literalなど、異なるエンコーディング・スタイルを使用している場合、プロキシ・サービス・パイプラインでSOAP変換を実行する必要があります。
