| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.1.3) E53004-06 |
|
 前 |
 次 |
この章では、Oracle Service Busコンソールを使用したパイプラインまたはメッセージ・フローの作成および構成に関する概要と概念について説明します。内容には、パイプラインのコンポーネント、メッセージ変換、ルーティングとサービス・コールアウト、エラー処理、メッセージ・コンテキストおよびサービス品質(QoS)が含まれます。
Service Busにおけるメッセージ・フローは、パイプラインの実装を定義します。パイプラインは、Oracle Service BusコンソールまたはOracle JDeveloperで作成して構成できます。分割-結合でメッセージ・フローを定義することもできます。詳細は、「分割-結合によるサービスのパフォーマンスの向上」を参照してください。
次の各項では、Service Busのパイプラインについて説明します。
Oracle Service Busコンソールでパイプラインを作成および構成する手順については、次の章を参照してください。
Oracle JDeveloperでパイプラインを作成および構成する手順については、次の章を参照してください。
パイプラインは、パイプラインを介してメッセージが流れるときのメッセージのルーティングと操作のロジックを定義するコンポーネントで構成されます。ノードは、メッセージ・フローを介してメッセージをルーティングするように構成されます。ステージおよびアクションには、メッセージを処理および変換するためのルールが含まれます。
表12-1に、パイプラインを定義する際に使用できるコンポーネントを示します。
表12-1 パイプライン・コンポーネント
| コンポーネント・タイプ | サマリー |
|---|---|
開始ノード |
すべてのパイプラインは開始ノードで始まります。すべてのメッセージは、開始ノードを介してパイプラインに入ります。また、すべてのレスポンス・メッセージが開始ノードを介してクライアントに返されます。開始ノードで構成するものはありません。 |
パイプライン・ペア・ノード |
パイプライン・ペア・ノードは、1つのリクエスト・パイプラインと1つのレスポンス・パイプラインを1つの最上位要素に統合したものです。パイプラインでは、パイプライン・ペア・ノードが持つことができる直接の子孫は1つのみです。リクエスト処理中にService Busがパイプライン・ペア・ノードを処理すると、リクエスト・パイプラインのみが実行されます。Service Busがレスポンス・パイプラインを処理すると、実行パスが反転されます。 |
ステージ |
リクエスト・パイプライン、レスポンス・パイプライン、およびエラー・ハンドラには、ステージを含めることができます。ステージでは、パイプラインを通過するメッセージを処理するアクションを構成します。 「ステージおよびルート・ノードでのアクションの構成」も参照してください。 |
エラー・ハンドラ |
ノードまたはステージで発生する可能性のあるエラーを処理するために、ノードまたはステージにエラー・ハンドラを追加できます。 「パイプラインでのエラー処理」も参照してください。 |
ブランチ・ノード |
ブランチ・ノードを使用すると、可能ないくつかのパスのうちの1つに限定して処理を進めることができます。WSDLベースのサービスでは、操作ブランチがサポートされます。操作ブランチでは、分岐はWSDLファイルで定義された操作に基づいています。XPathベースの切替え表で定義された条件では、条件付きブランチがサポートされます。 「パイプラインの分岐」も参照してください。 |
ルート・ノード |
ルート・ノードでは、別のサービスやコンポーネントとのリクエスト/レスポンス通信が実行されます。これは、パイプラインに関するリクエスト処理とレスポンス処理の境界を表します。ルート・ノードがリクエスト・メッセージをディスパッチすると、リクエスト処理が終了したと見なされます。ルート・ノードがレスポンス・メッセージを受信したときに、レスポンス処理が始まります。ルート・ノードは、リクエスト・トランスフォーメーション、レスポンス・トランスフォーメーション、および条件付きルーティングに対応します。 ルート・ノードはリクエスト処理とレスポンス処理の境界を表すので、パイプライン内に子孫を持つことはできません。 「ステージおよびルート・ノードでのアクションの構成」も参照してください。 |
一般には、メッセージ・フローは次の形式のいずれかで設計します。
非オペレーション・サービス(操作を含むWSDLファイルに基づいていないサービス)のフローでは、ルートにパイプライン・ペアが1つあり、その後にルート・ノードを配置します。
オペレーション・サービスのフローでは、ルートにパイプライン・ペアが1つあり、その後にオペレーションに基づくブランチ・ノードを配置します。さらに、各ブランチにはパイプライン・ペアが1つあり、その後にルート・ノードを配置します。
表12-2 メッセージ・フローでのリクエスト・メッセージのパス
| パイプライン・ノード | メッセージ処理の内容 |
|---|---|
リクエスト処理 |
リクエスト処理コンテナ。 |
開始ノード |
開始ノードでリクエスト処理が開始されます。 |
パイプライン・ペア・ノード |
リクエスト・パイプラインだけが実行されます。 |
ブランチ・ノード |
ブランチ表を評価し、関連するブランチに進みます。 |
ルート・ノード |
リクエスト・トランスフォーメーションと共にルーティングが実行されます。 パイプラインでは、ルーティングが実行されるかどうかに関係なく、ルート・ノードはリクエストの処理からレスポンスの処理への移行を表します。ルート・ノードでは、メッセージ・フローの方向は逆方向になります。リクエスト・パスにルート・ノードが含まれていない場合、レスポンスを待機せずに、レスポンス処理は逆方向で開始されます。 |
表12-3 メッセージ・フローでのレスポンス・メッセージのパス
| パイプライン・ノード | メッセージ処理の内容 |
|---|---|
レスポンス処理 |
ブランチ・ノードをスキップして、ブランチの前にあるノードに進みます。 |
ルート・ノード |
レスポンス・トランスフォーメーションが実行されます。 |
ブランチ・ノード |
ブランチ・ノードをスキップして、ブランチの前にあるノードに進みます。 |
パイプライン・ペア・ノード |
レスポンス・パイプラインが実行されます。 |
開始ノード |
クライアントにレスポンスを返します。 |
パイプラインでは、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を呼び出す状況について考えてみます。ルート・ノードのルーティング表に条件付きブランチを構成できます。ただし、フローの最上位だけを調べる場合、この方法では分岐がやや困難になります。かわりに、条件付きブランチ・ノードを使用して、パイプライン自体にこのブランチを公開し、各ブランチのサブフローとして単純なルート・ノードを使用できます。
メッセージ・フロー、ステージまたはルート・ノードのどの場所にブランチを構成するかを決定する前に、ビジネス・シナリオを検討してください。パイプラインにブランチを構成する場合、ブランチ・ノードから多数のブランチが分岐すると、設計インタフェースが煩雑になる可能性があることに注意してください。
アクションは、パイプライン・ステージ、エラー・ハンドラ・ステージ、およびルート・ノードでメッセージを処理する手順を提供します。次の項で説明するように、コンテキストによって、使用可能なアクションが決まります。
関連項目
通信アクションは、メッセージ・フローを制御します。各通信アクションを表12-4に示します。
表12-4 通信アクション
| アクション | 用途 | 使用できる場所 |
|---|---|---|
動的にパブリッシュ |
Xquery式で指定されたサービスにメッセージをパブリッシュします。 |
|
パブリッシュ |
メッセージの静的に指定されたターゲット・サービスを特定し、メッセージをパッケージ化してそのサービスに送信する方法を構成します。 |
|
パブリッシュ表 |
ゼロまたはそれ以上の静的に指定されたサービスにメッセージをパブリッシュします。切替え式の条件ロジックを使用して、どのサービスをパブリッシュに使用するか実行時に決定します。 |
|
ルーティング・オプション |
アウトバウンド・リクエストのURI、サービスの品質、モード、再試行パラメータ、メッセージ優先度の各プロパティの一部またはすべてを変更します。 |
|
サービス・コールアウト |
Service Busに登録済のプロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合の同期(ブロッキング)コールアウトを構成します。「サービス・コールアウト・メッセージの作成」を参照してください。 |
|
トランスポート・ヘッダー |
メッセージのヘッダー値を設定します。「パイプラインでのトランスポート・ヘッダーの構成」を参照してください。 |
|
動的ルーティング |
XQueryリソースで使用できるルーティング情報に基づいて、メッセージ・ルートを割り当てます。 |
|
ルーティング |
そのメッセージのターゲット・サービスを指定し、サービスへのメッセージのルーティング方法を構成します。 |
|
ルーティング表 |
単一のXQuery式の結果に基づいて、異なるルートを選択します。 |
|
フロー制御アクションは、条件付きルーティング、条件付きループおよびエラー処理を実装します。また、フロー制御アクションを使用して、呼出し元に成功を通知したり、ステージの残りのアクションをスキップしたりすることもできます。各フロー制御アクションを表12-5に示します。
表12-5 フロー制御アクション
| アクション | 用途 | 使用できる場所 |
|---|---|---|
For Each |
値のシーケンスを反復処理し、アクションのブロックを実行します。 |
|
If... then... |
XQuery式のブール結果に基づいて、1つのアクションまたは一連のアクションを条件付きで実行します。 |
|
エラーの生成 |
指定されたエラー・コード(文字列)と記述を含む例外を発生させます。 |
|
返信 |
呼出し元に即時返信を送信します。 返信アクションは、リクエスト・パイプライン、レスポンス・パイプライン、またはエラー・パイプラインで使用できます。成功時または失敗時に返信するように構成できます。HTTPインバウンド・トランスポートでの失敗時の返信の場合、返信アクションでは、呼出し元に即時に返信されるように指定します。 |
|
再開 |
エラー・ハンドラによってエラーが処理された後、メッセージ・フローを再開します。このアクションにパラメータはありません。このアクションは、エラー・ハンドラでのみ使用できます。 |
|
スキップ |
実行時に現在のステージの実行がスキップされ、パイプラインの次のステージに処理を進めます。このアクションにはパラメータがなく、リクエスト・パイプライン、レスポンス・パイプライン、エラー・パイプラインで使用できます。 |
|
このカテゴリのアクションは、メッセージ・フローを処理します。各メッセージ処理アクションを表12-6に示します。
表12-6 メッセージ処理アクション
| アクション | 用途 | 使用できる場所 |
|---|---|---|
割当て |
コンテキスト変数にXQuery式またはXSLT式の結果を割り当てます。 |
|
削除 |
XPath式で指定されたコンテキスト変数または一連のノードを削除します。 |
|
挿入 |
XPath式で選択したノードを基準として特定された場所にXQuery式またはXSLT式の結果を挿入します。 |
|
Javaコールアウト |
パイプラインからJavaメソッドを呼び出します。 |
|
MFL変換 |
メッセージ・パイプラインで、XMLから非XMLまたは非XMLからXMLにメッセージ・コンテンツを変換します。MFLは、バイナリ・データのレイアウトを記述するために使用する特別なXMLドキュメントです。Oracle独自の言語を使用して、フォーマットされたバイナリ・データをXMLデータに、またはXMLデータをバイナリ・データに変換するルールを定義します。 |
|
nXSD変換 |
メッセージ・パイプラインで、XMLからネイティブ・フォーマット・データ、またはネイティブ・フォーマット・データからXMLに、メッセージ・コンテンツを変換します。 |
|
名前変更 |
要素のコンテンツを変更せずに、XPath式で選択した要素の名前を変更します。 |
|
置換 |
XPath式で指定されたノードまたはノードのコンテンツを置き換えます。ノードまたはそのコンテンツは、XQuery式が返した値で置換されます。 置換アクションでは、単純な値、要素、属性を置き換えることができます。XQuery式から何も返されない状態は、アクションがノード全体を置き換えるか、ノードコンテンツのみを置き換えるかにより、識別されたノードを削除すること、または空のノードを作成することと同じです。 置換アクションは更新アクションのセットの内の1つです。 |
|
検証 |
XMLスキーマ要素またはWSDLリソースに対して、XPath式で選択した要素を検証します。検証できるのは、グローバル要素のみです。Service Busはローカル要素に対する検証に対応していません。 |
|
このカテゴリのアクションを使用して、ステージ内のメッセージ・フローでの必要に応じて、エラーのログ記録またはレポート、およびアラートの生成を行います。各レポート・アクションを表12-7に示します。
表12-7 レポート・アクション
| アクション | 用途 | 使用できる場所 |
|---|---|---|
アラート |
パイプラインのメッセージ・コンテキストに基づいてアラートを生成し、アラート宛先に送信します。SLAアラートと異なり、アラート・アクションで生成された通知は、主にビジネスでの使用、またはエラーの報告を目的とし、システムの状態を監視するものではありません。アラート宛先の構成と選択は、この点を考慮して行う必要があります。 パイプライン・アラートがサービスで有効になっていない場合や、ドメイン・レベルで有効になっている場合は、メッセージを処理するときに構成済のアラート・アクションが省略されます。 |
|
ログ |
ログに記録するメッセージを作成し、メッセージをログに記録するときに使用する一連の属性を定義します。 |
|
レポート |
パイプラインのメッセージ・レポートを有効にします。XQuery/XSLT式は、Service Busダッシュボードにレポートされるデータの作成に使用されます。キー値のペアは、メッセージ・コンテキスト変数やメッセージ・ペイロードからキー識別子を抽出して、残りのメッセージを無視する場合に使用します。 |
|
トランスポート・ヘッダー・アクションは、通信タイプのアクションです。このアクションは、パイプライン・ステージとエラー・ハンドラ・ステージで使用できます。
トランスポート・ヘッダー・アクションを構成するときに、次のオプションを使用できます。
「パイプラインを介してすべてのヘッダーを渡す」オプションは、実行時にトランスポート・ヘッダー・アクションによって、インバウンド・メッセージからアウトバウンド・メッセージまたはアウトバウンド・メッセージからインバウンド・メッセージにすべてのヘッダーをパススルーすることを示します。ソース・ヘッダー・セットのすべてのヘッダーはターゲット・ヘッダー・セットにコピーされ、ターゲット・ヘッダー・セットの既存の値はすべて上書きされます。
「インバウンド・リクエストからヘッダーをコピー」オプションと「アウトバウンド・レスポンスからヘッダーをコピー」オプションは、実行時にトランスポート・ヘッダー・アクションによって、このオプションが関連付けられている特定のヘッダーをインバウンド・メッセージからアウトバウンド・メッセージまたはアウトバウンド・メッセージからインバウンド・メッセージにコピーすることを示します。
これらのオプションは、シナリオに合せて使用します。どちらのオプションを使用しても、ソース・ヘッダー・セットのヘッダーがターゲット・ヘッダー・セットにコピーされ、ターゲット・セットの既存の値はすべて上書きされます。「パイプラインを介してすべてのヘッダーを渡す」オプションは、ヘッダー固有のヘッダーをコピー・オプションの前に実行されます。つまり、特定のトランスポート・ヘッダー・アクションの構成で、「パイプラインを介してすべてのヘッダーを渡す」を選択した場合、特定のヘッダーに対してヘッダーをコピー・オプションを選択する必要はありません。
ただし、「パイプラインを介してすべてのヘッダーを渡す」を選択してすべてのヘッダーをコピーし、その後特定のヘッダーに対して「ヘッダーの削除」を選択して、個々のヘッダーを削除するようにアクションを構成できます。
警告:
トランスポート・ヘッダーはトランスポート・タイプに固有であるため、パススルー(またはコピー)オプションは、同じトランスポート・タイプのサービス間でヘッダーをコピーする場合にのみ使用することをお薦めします。トランスポート・タイプが異なるサービス間でヘッダーを渡す(またはコピーする)と、渡されるヘッダーがターゲットのトランスポートで受け入れられない場合にエラーが発生することがあります。同じ理由で、「ヘッダーを設定」オプションを使用してヘッダー名を指定するときにも注意が必要です。
トランスポート・ヘッダー・アクションを使用して、アウトバウンド・リクエスト(ルート、パブリッシュ、またはサービス・コールアウトの各アクションでプロキシ・サービスが送信するメッセージ)とインバウンド・レスポンス(プロキシ・サービスがクライアントに返信するレスポンス・メッセージ)のトランスポート・ヘッダーの値を構成できます。通常、ヘッダー値に対して次の操作を実行できます。
XQuery式を使用して指定します。
ソースからターゲット・サービスにパススルーします。
ソースからターゲット・サービスへの移動時に削除します。
トランスポート・ヘッダー・アクションを使用すると、$inboundまたは$outboundのヘッダーを設定、削除、またはパススルーできます。これらのヘッダーを設定または削除した後に、$inboundまたは$outboundをログに書き込むと、変更の影響を確認できます。ただし、メッセージが送信されるときにService Busバインディング・レイヤーによって$inboundまたは$outboundの一部のヘッダーが変更または削除され、そのため基礎になるトランスポートでこれらのヘッダーの一部が無視されて、固有の値が使用されることがあります。重要な違いは、バインディング・レイヤーによるヘッダーの変更は$inboundおよび$outboundに対して直接行われますが、トランスポートによる変更はメッセージのワイヤ形式だけに影響するという点です。たとえば、アウトバウンドのContent-Lengthヘッダーの値を指定することはできますが、メッセージの送信時に、この値はバインディング・レイヤーによって$outboundから削除されます。したがって、この変更はレスポンス・パスで確認できます(たとえば、$outboundをログに記録すると、変更された値を確認できます)。$outboundにUser-Agentヘッダーを設定した場合、HTTPトランスポートではこの設定が無視され、トランスポート独自の値が使用されます。ただし、$outboundの値が変更されることはありません。
「トランスポート・ヘッダー・アクションで指定するトランスポート・ヘッダーの値の制限」では、実行時に無視または上書きされるトランスポート・ヘッダーと、特定のトランスポート・ヘッダーに関するその他の制限を示します。
表12-8に、実行時に無視または上書きされるトランスポート・ヘッダーと、特定のトランスポート・ヘッダーに関するその他の制限を示します。
表12-8 トランスポート・ヘッダー・アクションで指定するトランスポート・ヘッダーの値の制限
| トランスポート | 制限の説明 | アウトバウンド・リクエスト・ヘッダー | インバウンド・レスポンス・ヘッダー |
|---|---|---|---|
HTTP |
Service Busランタイムは、メッセージのディスパッチ準備中にバインディング・レイヤーでこれらのヘッダーを上書きする場合があります。これらのヘッダーが変更された場合、それに応じて |
Content-Type |
Content-Type |
HTTP |
メッセージの送信時に、基になるトランスポートでこれらのヘッダーが無視され、別の値が使用される場合があります。トランスポートによって行われた変更は、 |
|
|
JMS |
リクエストが一方向のサービスまたは
|
JMSCorrelationID |
JMSCorrelationID |
JMS |
Service Busランタイムはこれらのヘッダーを設定します。つまり、設計時にこれらのヘッダーに対して行った指定内容は実行時に上書きされます。 注意: |
|
|
JMS |
IBM MQではクライアント・アプリケーションで一部のプロパティを設定できないため、IBM MQ宛先に関連するこれらのヘッダーを設定すると、実行時例外が発生します。 |
|
|
JMS |
「パイプラインを介してすべてのヘッダーを渡す」オプションも指定されている場合、これらのヘッダーを削除することはできません。 |
|
|
FTPおよびファイル |
制限はありません。つまり、ユーザーはファイル・トランスポートおよびFTPトランスポートのヘッダーを設定または削除でき、ユーザーによる指定はService Busランタイムで優先されます。 注意: FTPプロキシとファイル・プロキシには、 |
N/A |
N/A |
電子メール |
Service Busランタイムはこれらのヘッダーを設定します。つまり、設計時にこれらのヘッダーに対して行った指定内容は実行時に上書きされます。 |
Content-Type |
Content-Type |
電子メール |
Service Busはアウトバウンド・リクエストでこれらのヘッダーを使用しません。これらを動的に設定すると(つまり、これらを これらのヘッダーは |
|
N/A |
注意:
inboundコンテキスト変数とoutboundコンテキスト変数を設定する場合や、Service Bus Test Consoleを使用してプロキシ・サービスまたはビジネス・サービスをテストする場合は、トランスポート・ヘッダーとメタデータの設定のときと同じ制限が適用されます。
トランスフォーメーション・マップは、2つのデータ型の間のマッピングを記述したものです。Service Busは、XQueryおよびeXtensible Stylesheet Language Transformation (XSLT)標準を使用したデータ・マッピングに対応しています。XSLTマップでは、XMLからXMLへのマッピングを記述します。XQueryマップでは、XMLからXML、XMLから非XML、および非XMLからXMLへの各マッピングを記述できます。
パイプライン内にトランスフォーメーションを指定する位置は、次の条件によって異なります。
メッセージ・フォーマットがターゲット・サービスに依存する場合。つまり、メッセージ・フォーマットが、ルートの宛先で受け入れられるフォーマットであることが必要な場合です。これに該当するのは、トランスフォーメーションがルート・ノードまたはパブリッシュ・アクションの1つで実行されるときです。
パブリッシュ・アクションで、メッセージのターゲット・サービスを判別し、メッセージのパッケージおよびサービスへの送信方法を構成します。Service Busには、パブリッシュ表アクションも用意されています。パブリッシュ表アクションは、切替え式条件表にラップされた一連のルートで構成されます。これは、単一のXQuery式の結果に基づいて各種ルートを選択できる短縮形の構文です。
ルートの宛先に関係なく、リクエストまたはレスポンス・メッセージに対してトランスフォーメーションを実行するかどうか。この場合、リクエストまたはレスポンス・パイプライン・ステージでトランスフォーメーションを構成できます。
トランスフォーメーションをパブリッシュ・アクション内に設計した場合、トランスフォーメーションは$outbound変数およびメッセージ関連の変数($header、$bodyおよび$attachments)のローカル・コピーを保持します。パブリッシュ・アクションでアウトバウンド・メッセージに行った変更は、パブリッシュされるメッセージにのみ反映されます。つまり、パブリッシュ・アクションで行った変更は、メッセージ・フローがパイプラインのその次のアクションに進む前にロールバックされます。
たとえば、メッセージ・フローで大口の発注書を処理するときに、管理者宛てに発注書の要約を電子メールで送信する必要がある場合について考えます。このような場合、リクエスト・パイプラインにパブリッシュ・アクションを含めると、着信メッセージのSOAP本体に発注書の要約が作成されます。パブリッシュ・アクションでは、発注書データが発注書の要約に変換されます。たとえば、発注書の要約には添付ファイルは必要ないため、$attachmentsのすべての添付ファイルを削除できます。パブリッシュ・アクションの後は、次の項で説明するように、パブリッシュ・アクションより前の状態のメッセージがそのメッセージ・フローを通じて維持されます。
この項では、様々なサービス品質(QoS)設定におけるパブリッシュ・アクションの動作を説明します。
必ず1回 - QoSが必ず1回の場合、パブリッシュ・アクションはターゲット・サービスからのレスポンスがあるまで待機します(ブロッキング・コール)。ターゲットがビジネス・サービスの場合、パブリッシュ・アクションはビジネス・サービス・レスポンスがあるまで待機します。ターゲットがプロキシ・サービスの場合、パブリッシュ・アクションはプロキシ・サービスのレスポンス・パイプラインが完了するまで待機します。
ベスト・エフォート - QoSがベスト・エフォートで、ターゲット・サービスが一方向プロキシ・サービスまたは一方向ビジネス・サービスの場合で再試行回数が1回以上に設定されていると、パブリッシュ・アクションはターゲット・サービスが返されるまで待機します。一方向のターゲット・サービスではレスポンスがありませんが、プブリッシュ・アクションはリクエストが配信されるまで待機します。
ターゲット・プロキシまたはビジネス・サービスがリクエスト-レスポンスまたは一方向ビジネス・サービスの場合で、再試行回数が0に設定されていると、パブリッシュ・アクションはレスポンスを待機しません(ノンブロッキング・コール)。
WS-Addressingヘッダーに基づく2つの宛先の一方にメッセージをルーティングする必要があるとします。この場合、コンテンツ・ベースのルーティングです。また、もう一方の宛先では、SOAP本体のドキュメントの新しいバージョンが必要であるとします。このような場合、条件に基づいて2つの宛先の一方にルーティングされるように、ルート・ノードを構成できます。2つ目の宛先のためにドキュメントを変換するように、ルート・ノードでトランスフォーメーションを構成します。
アウトバウンド・コンテキスト変数($outbound)の制御要素を設定して、アウトバウンド・メッセージに関するシステムの動作を調整することもできます(たとえば、サービスの品質を設定できます)。
inbound変数とoutbound変数の下位要素、およびメッセージ・コンテキストの変数の値を使用してメッセージのコンテンツが作成される仕組みについては、「inbound変数とoutbound変数」および「ディスパッチするメッセージの作成」を参照してください。
関連項目
Service Busがサービス・コールアウト・アクションを通じてサービスをコールする場合は、メッセージ・コンテキストの変数の値を使用してメッセージのコンテンツが作成されます。アウトバウンド・メッセージのメッセージ・コンテンツは、ターゲット・サービスの種類に応じて異なって処理されます。
次のトピックで説明するように、メッセージ・コンテンツの作成方法は、ターゲット・サービスのタイプ、およびSOAP本体とペイロード(パラメータまたはドキュメント)のどちらを構成するかによって異なります。
次のようなSOAPドキュメント・スタイルのサービス(EJBドキュメントおよびドキュメントにラップされたサービスを含む)のメッセージを作成できます。
リクエスト・ドキュメントが割り当てられた変数にはSOAP本文が含まれます。
SOAPリクエスト・ヘッダーに割り当てられた変数にはSOAPヘッダーが含まれます。
レスポンスは単一のXMLドキュメント(SOAP本体のコンテンツとSOAPヘッダー(指定されている場合))である必要があります。
SOAPドキュメント・スタイルのサービスへのコールアウト時にメッセージが作成されるしくみを説明するために、次のように構成されたサービス・コールアウト・アクションについて考えてみます。
リクエスト・ドキュメント変数: myreq
レスポンス・ドキュメント変数: myresp
SOAPリクエスト・ヘッダー: reqheader
SOAPレスポンス・ヘッダー: respheader
また、実行時にリクエスト・ドキュメント変数myreqが次のXMLにバインドされていることを前提とします。
例 - リクエスト変数(myreq)のコンテンツ
<sayHello xmlns="http://www.openuri.org/">
<intVal>100</intVal>
<string>Hello Oracle</string>
</sayHello>
実行時に、SOAPリクエスト・ヘッダー変数reqheaderは、次のSOAPヘッダーにバインドされます。
例 - 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>
このシナリオ例では、外部サービスに送信されるメッセージの本文全体は次の例のようになります(myreq変数とreqheader変数のコンテンツは太字で示しています)。
例 - サービス・コールアウト・アクションの結果としてサービスに送信されるメッセージ
<?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変数に割り当てられます。外部サービスからのレスポンス全体が次の例で示されています。
例 - サービス・コールアウト・アクションの結果としてサービスから送信されるレスポンス・メッセージ
<?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変数に次の例に示す値が割り当てられます。
例 - サービス・コールアウト・アクションの結果であるレスポンス変数(myresp)のコンテンツ
<m:sayHelloResponse xmlns:m="http://www.openuri.org/">
<result ns0:type="xsd:string" xmlns:ns0="http://www.w3.org/2001/XMLSchema-instance">
This message brought to you by Hello Oracle and the number 100
</result>
</m:sayHelloResponse>
次のような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
このシナリオでは、サービスへのアウトバウンド・メッセージの本文は次の例のようになります。
例 - アウトバウンド・メッセージのコンテンツ
<?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>
次の例では、コールが作成されたサービスによって返されるレスポンスを示します。
例 - 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には、次の例に示す値が割り当てられます。
例 - 出力変数(output1)のコンテンツ
<message ns0:type="xsd:string" xmlns:ns0="http://www.w3.org/2001/XMLSchema-intance"> This message brought to you by Hello Oracle and the number 100</message>
次のようなXMLサービスのメッセージを作成できます。
リクエスト・メッセージは、リクエスト・ドキュメントが割り当てられた変数のコンテンツです。
リクエスト変数のコンテンツは、単一のXMLドキュメントである必要があります。
出力ドキュメントは、レスポンス・メッセージです。
XMLサービスへのコールアウト時にメッセージが作成されるしくみを説明するために、次のように構成されたサービス・コールアウト・アクションを例にとります。
リクエスト・ドキュメント変数: myreq
レスポンス・ドキュメント変数: myresp
また、実行時にリクエスト・ドキュメント変数myreqが次のXMLにバインドされていることを前提とします。
例 - myreq変数のコンテンツ
<sayHello xmlns="http://www.openuri.org/">
<intVal>100</intVal>
<string>Hello Oracle</string>
</sayHello>
このシナリオでは、次のようになります。
前述の例に示すように、アウトバウンド・メッセージ・ペイロードはmyreq変数の値です。
レスポンスおよびメッセージ・コンテキスト変数myrespに割り当てられる値は、次の例のようになります。
例 - myresp変数のコンテンツ
<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>
メッセージング・サービスの場合の特徴は次のとおりです。
リクエスト・メッセージはリクエスト変数のコンテンツです。コンテンツには単純なテキスト、XML、または<binary-content ref=.../>参照XMLのインスタンスによって表されるバイナリ・データを使用できます。
レスポンス・メッセージはバイナリとして扱われるため、実際にどのようなコンテンツを受信したかにかかわらず、レスポンス変数には<binary-content ref= ... />参照XMLのインスタンスが格納されます。
たとえば、リクエスト・メッセージのコンテキスト変数myreqが<hello>there</hello>という形式のXMLドキュメントにバインドされる場合、アウトバウンド・メッセージには厳密にこのペイロードが格納されます。レスポンス・メッセージのコンテキスト変数(myresp)は、次のような参照要素にバインドされます。
<binary-content ref=" cid:1850733759955566502-2ca29e5c.1079b180f61.-7fd8"/>
アウトバウンド・リクエストの添付ファイルを保持するオプションの変数と、アウトバウンド・レスポンスからの添付ファイルを保持する別の変数を指定できます。リクエスト添付ファイル変数とレスポンス添付ファイル変数を使用して、リクエスト添付ファイルとレスポンス添付ファイルをそれぞれ指定します。
リクエスト・メッセージ、レスポンス・メッセージあるいはその両方の添付ファイルを指定できます。次のコードは、リクエスト添付ファイル変数とレスポンス添付ファイル変数のスキーマ・タイプを示しています。
<!-- The schema type for -->
<complexType name="AttachmentsType">
<sequence>
<!-- the 'attachments' variable is just a series of attachment elements -->
<element ref="mc:attachment" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<!-- Each attachment in the 'attachments' variable is represented by an instance of this element -->
<element name="attachment" type="mc:AttachmentType"/>
<complexType name="AttachmentType">
<all>
<!-- Set of MIME headers associated with attachment -->
<element name="Content-ID" type="string" minOccurs="0"/>
<element name="Content-Type" type="string" minOccurs="0"/>
<element name="Content-Transfer-Encoding" type="string" minOccurs="0"/>
<element name="Content-Description" type="string" minOccurs="0"/>
<element name="Content-Location" type="string" minOccurs="0"/>
<element name="Content-Disposition" type="string" minOccurs="0"/>
<!-- Contains the attachment content itself, either in-lined or as <binary-content/> -->
<element name="body" type="anyType"/>
</all>
</complexType>
リクエスト添付ファイル変数とレスポンス添付ファイル変数は、ターゲット・サービスのバインディング・タイプやトランスポート・タイプに関係なく使用できます。
次の例では、SOAPドキュメント・スタイルJWSを使用したWLS Webサービスの例を示します。Webサービスには、入力引数をその戻り値として返す単一メソッドがあります。入力引数と戻り値は、添付ファイルとして送受信されます。
例 - サンプルSOAPドキュメント・スタイルJWS
import javax.activation.DataHandler;
@WebService(name="AttachmentsService", targetNamespace="http://example.org")
@Binding(Binding.Type.SOAP12)
@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
use=SOAPBinding.Use.LITERAL,
parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)
@WLHttpTransport(contextPath="testAttachments", serviceUri="AttachmentsService")
public class AttachmentsServiceImpl
{
@WebMethod(action="echoAttachmentAction")
public DataHandler echoAttachment(DataHandler dh)
{
return dh;
}
}
次の例では、前述のSOAPドキュメント・スタイルJWSの例のWebサービスに対応するWSDLドキュメントを示します。
例 - Webサービスに対応するWSDLドキュメント
<wsdl:definitions name="AttachmentsServiceImplServiceDefinitions"
targetNamespace="http://example.org"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:exam="http://example.org"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
<wsdl:types>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
targetNamespace="http://example.org" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://www.bea.com/servers/wls90/wsee/attachment"/>
<xs:element name="echoAttachment">
<xs:complexType>
<xs:sequence>
<xs:element name="dh" type="att:datahandler"
xmlns:att="http://www.bea.com/servers/wls90/wsee/attachment"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="echoAttachmentResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="return" type="att:datahandler"
xmlns:att="http://www.bea.com/servers/wls90/wsee/attachment"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:schema targetNamespace="http://www.bea.com/servers/wls90/wsee/attachment"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="datahandler">
<xs:annotation>
<xs:documentation>Internal type created by WebLogic - Do not
edit!</xs:documentation>
</xs:annotation>
</xs:complexType>
</xs:schema>
</wsdl:types>
<wsdl:message name="echoAttachment">
<wsdl:part element="exam:echoAttachment" name="parameters"/>
</wsdl:message>
<wsdl:message name="echoAttachmentResponse">
<wsdl:part element="exam:echoAttachmentResponse" name="parameters"/>
</wsdl:message>
<wsdl:portType name="AttachmentsService">
<wsdl:operation name="echoAttachment" parameterOrder="parameters">
<wsdl:input message="exam:echoAttachment"/>
<wsdl:output message="exam:echoAttachmentResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="AttachmentsServiceImplServiceSoapBinding"
type="exam:AttachmentsService">
<soap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="echoAttachment">
<soap12:operation soapAction="echoAttachmentAction" style="document"/>
<wsdl:input>
<soap12:body parts="parameters" use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body parts="parameters" use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="AttachmentsServiceImplService">
<wsdl:port binding="exam:AttachmentsServiceImplServiceSoapBinding"
name="AttachmentsServiceSoapPort">
<soap12:address
location="http://adc4110062:7001/testAttachments/AttachmentsService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
次に、前述のWSDLファイルがService Busに登録され、ビジネス・サービスがこのWSDL SOAPポートに登録されます。サービス・コールアウト・アクションは次のように構成されます。
リクエスト・ドキュメント変数: reqDoc
レスポンス・ドキュメント変数: respDoc
リクエスト添付ファイル変数: reqatt
レスポンス添付ファイル変数: respatt
サービス・コールアウト・アクションの追加と構成の詳細は、「コンソールでのサービス・コールアウト・アクションの追加」を参照してください。
次の例では、サービス・コールアウト処理が起動された際のリクエスト・ドキュメントの値およびリクエスト添付コンテキスト変数を示します。
例 - サービス・コールアウト呼出し時のリクエスト・ドキュメント変数(reqDoc)の値
<m:echoAttachment xmlns:m="http://example.org">
<m:dh href="cid:dh"/>
</m:echoAttachment>
例 - サービス・コールアウト呼出し時のリクエスト添付ファイル変数(reqatt)の値
<con:attachments xmlns:con="http://www.bea.com/wli/sb/context">
<con:attachment>
<con:Content-Type>image/jpeg</con:Content-Type>
<con:Content-ID><dh></con:Content-ID>
<con:body>
<con:binary-content ref="cid:-6175a307:131072c66ef:-7f56"/>
</con:body>
</con:attachment>
</con:attachments>
前述の例では、添付ファイルの本文は、ソース・リポジトリに格納されるソースを指し示すバイナリ・コンテンツ参照を使用します。これは、JavaコールアウトやMFL変換などの結果になります。
注意:
SOAPエンベロープのhref値が、添付ファイル・パートのContent-IDヘッダーに一致することを確認します。これにより、メッセージの本文と対応する添付ファイルがリンクされます。値が一致しない場合、JWS呼出しからSOAPフォルトを受信する場合があります。
次の例は、サービス・コールアウト・アクションのサンプル・アウトバウンド・ペイロードを示しています。
例 - サービス・コールアウトのアウトバウンド・ペイロード
POST http://localhost:7001/default/test1
Content-Type: multipart/related;boundary="----=_Part_0
_39288954.1310192119320";type="text/xml";start="<soapPart>"
------=_Part_0_39288954.1310192119320
Content-Type: application/soap+xml; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-ID: <soapPart>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header/>
<env:Body>
<m:echoAttachment xmlns:m="http://example.org">
<m:dh href="cid:dh"/>
</m:echoAttachment>
</env:Body>
</env:Envelope>
------=_Part_0_39288954.1310192119320
Content-Type: image/jpeg
Content-ID: <dh>
... binary content of some JPG file ….
------=_Part_0_39288954.1310192119320--
次の例では、サービス呼出しに対するJWSレスポンスを示します。
例 - Java Webサービス(JWS)のレスポンス
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: multipart/related;boundary="----=_Part_13
_1460020940.1310334461289";type="text/xml";start="<soapPart>"
------=_Part_13_1460020940.1310334461289
Content-Type: application/soap+xml; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-ID: <soapPart>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<m:echoAttachmentResponse xmlns:m="http://example.org">
<return xmlns="http://example.org" href="cid:return"/>
</m:echoAttachmentResponse>
</env:Body>
</env:Envelope>
------=_Part_13_1460020940.1310334461289
Content-Type: image/jpeg
Content-ID: <return>
…. binary content of some JPG file …
------=_Part_13_1460020940.1310334461289--
次の例では、サービス・コールアウト・レスポンスのコンテキスト変数の値を示します。
例 - レスポンス・ドキュメント変数(respDoc)の値
<m:echoAttachmentResponse xmlns:m="http://example.org">
<return xmlns="http://example.org" href="cid:return"/>
</m:echoAttachmentResponse>
例 - レスポンス添付ファイル変数(respatt)の値
<con:attachments xmlns:con="http://www.bea.com/wli/sb/context">
<con:attachment>
<con:Content-Type>image/jpeg</con:Content-Type>
<con:Content-ID><return></con:Content-ID>
<con:body>
<con:binary-content ref="cid:-6175a307:131072c66ef:-7f57"/>
</con:body>
</con:attachment>
</con:attachments>
次に、SOAP RPCスタイルWSDLファイルの例を示します。WSDLファイルは、ビジネス・サービスとしてService Busに登録されます。サービス・コールアウト・アクションを使用して、このビジネス・サービスを呼び出します。
例 - ビジネス・サービスのWSDLドキュメント
<?xml version="1.0"?>
<wsdl:definitions xmlns:types="http://example.com/mimetypes"
xmlns:ref="http://ws-i.org/profiles/basic/1.1/xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://example.com/mimewsdl"
xmlns:tns="http://example.com/mimewsdl">
<wsdl:types>
<xsd:schema targetNamespace="http://example.com/mimetypes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="http://ws-i.org/profiles/basic/1.1/xsd" />
<xsd:complexType name="ClaimDetailType">
<xsd:sequence>
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="ClaimForm" type="ref:swaRef"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</wsdl:types>
<wsdl:message name="ClaimIn">
<wsdl:part name="ClaimDetail" type="types:ClaimDetailType"/>
<wsdl:part name="ClaimPhoto" type="xsd:base64Binary"/>
</wsdl:message>
<wsdl:message name="ClaimOut">
<wsdl:part name="ClaimRefNo" type="xsd:string"/>
</wsdl:message>
<wsdl:portType name="ClaimPortType">
<wsdl:operation name="SendClaim">
<wsdl:input message="tns:ClaimIn"/>
<wsdl:output message="tns:ClaimOut"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ClaimBinding" type="tns:ClaimPortType">
<soapbind:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="SendClaim">
<soapbind:operation soapAction="http://example.com/soapaction"/>
<wsdl:input>
<mime:multipartRelated>
<mime:part>
<soapbind:body use="literal"
parts="ClaimDetail"
namespace="http://example.com/mimetypes"/>
</mime:part>
<mime:part>
<mime:content part="ClaimPhoto"
type="image/jpeg"/>
</mime:part>
</mime:multipartRelated>
</wsdl:input>
<wsdl:output>
<soapbind:body use="literal"
namespace="http://example.com/mimetypes"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>
サービス・コールアウト・アクションは次のように構成されます。
リクエスト・パラメータ: claimDetail
レスポンス・パラメータ: claimRefNo
リクエスト添付ファイル変数: reqatt
レスポンス添付ファイル変数: respatt
サービス・コールアウト・アクションの追加と構成の詳細は、「コンソールでのサービス・コールアウト・アクションの追加」および「JDeveloperでのサービス・コールアウト・アクションの追加」を参照してください。
次の例では、サービス・コールアウトが呼び出されたときのメッセージ・コンテキスト変数の値を示します。
例 - リクエスト・パラメータ(claimDetail)の値
<ClaimDetail xmlns=" http://example.com/mimetypes">
<Name>...</Name>
<ClaimForm>cid:claimform@example.com</ClaimForm>
</ClaimDetail>
例 - リクエスト添付ファイル変数(reqatt)の値
<con:attachments xmlns:con="http://www.bea.com/wli/sb/context">
<con:attachment>
<con:Content-Type>text/xml</con:Content-Type>
<con:Content-ID><claimform@example.com></con:Content-ID>
<con:body>
<form>...XML contents of claim form referenced by the swaRef... </form>
</con:body>
</con:attachment>
<con:attachment>
<con:Content-Type>image/jpeg</con:Content-Type>
<con:Content-ID><ClaimPhoto=4d7a5fa2-14af-451c-961b-5c3abf786796@example.com></con:Content-ID>
<con:body>
<con:binary-content ref="cid:-6175a307:131072c66ef:-7f58"/>
</con:body>
</con:attachment>
</con:attachments>
次に、アウトバウンド・リクエストの例を示します。
例 - サンプル・アウトバウンド・リクエスト
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start="<rootpart@example.com>"
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <rootpart@example.com>
<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body xmlns:types="http://example.com/mimetypes">
<types:SendClaim>
<ClaimDetail>
<Name>...</Name>
<ClaimForm>cid:claimform@example.com</ClaimForm>
</ClaimDetail>
</types:SendClaim>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
--MIME_boundary
Content-Type: text/xml
Content-Transfer-Encoding: 8bit
Content-ID: <claimform@example.com>
...claim form referenced by the swaRef...
--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <ClaimPhoto=4d7a5fa2-14af-451c-961b-5c3abf786796@example.com>
...MIME attachment of binary photograph...
--MIME_boundary--
次に、レスポンスの例を示します。
例 - サンプル・レスポンス
Content-Type: text/xml; charset=UTF-8
<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body xmlns:types="http://example.com/mimetypes">
<types:SendClaimResponse>
<ClaimRefNo>.............................</ClaimRefNo>
</types:SendClaimResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
レスポンスに対応するメッセージ・コンテキスト変数(claimRefNoおよびrespatt)が設定されます。次の例はrespatt変数の値を示しています。
例 - レスポンス添付ファイル変数(respatt)の値
<con:attachments xmlns:con=http://www.bea.com/wli/sb/context />
サービス・コールアウトでSOAP Message Transmission Optimization Mechanism (MTOM)を使用できます。MTOMは、XML-binary Optimized Packaging (XOP)を使用してバイナリ・データを転送します。
ただし、MTOMと添付ファイルを混ぜ合せることはできません。ターゲット・サービスがMTOMに対応し、アウトバウンド・リクエストに添付ファイルがある場合、次のエラーが発生します。
XOP/MTOMと添付ファイルの混在は許可されません。
ターゲット・サービスでMTOMが有効な場合、添付ファイル変数は構成しないでください。
エラー処理は、メッセージ・フロー、パイプライン、ルート・ノード、およびステージ・レベルで構成できます。サービス・コールアウトの結果として外部サービスから受け取るエラーのタイプには、トランスポート・エラー、SOAPフォルト、予期されるレスポンスに一致しないレスポンスなどがあります。
faultコンテキスト変数の設定は、返されるエラーのタイプごとに異なります。fault変数のコンテンツに基づいて、ビジネス・ロジックとエラー処理ロジックを構築できます。$faultの詳細は、「fault変数」を参照してください。
外部サービスからトランスポート・エラーを受け取り、トランスポート・プロバイダからService Busにエラー・レスポンス・ペイロードが返されない場合(たとえば、HTTPビジネス・サービスがXMLまたはSOAP以外のレスポンス・タイプを受け入れたためにHTTPレスポンス・コードを受け取れない場合)、サービス・コールアウト・アクションは例外をスローするので、パイプラインでエラーが発生します。ユーザーが構成したエラー・ハンドラのfault変数は、次の例に示すメッセージと同様にフォーマットされたメッセージにバインドされます。
例 - 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)レスポンス・コードは300以上のコードである必要があります。
(JMS)レスポンスにエラー・レスポンスであることを示すプロパティが設定されている必要があります(トランスポート・メタデータのステータス・コードが1に設定されている場合はエラーを示します)。
コンテンツ・タイプは、text/xml、application/any_string+xmlまたはmultipart/relatedである必要があります。
サービスがAnySoapまたはWSDLベースのSOAPである場合、サービスにSOAPエンベロープが必要です。SOAPエンベロープ内の本体はXML形式でなければなりません(テキストは不可)。
サービスのタイプがAnyXMLである、またはタイプがテキストであるメッセージング・サービスでXMLコンテンツが不成功レスポンス・コード(200または202以外の任意のコード)と共に返されます。
トランスポートがHTTPの場合、ErrorResponseDetail要素にはレスポンスとともに返されるHTTPエラー・コードも含まれます。fault内のErrorResponseDetail要素には、サービスから受信したエラー・レスポンス・ペイロードが含まれます。次の例では、ErrorResponseDetail要素の例を示します。
例 - 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>
注意:
サービス・コールアウト生成フォルトのXMLスキーマが「予期しないレスポンス」に示されています。
外部サービスがSOAPフォルトを返した場合、Service Busランタイムは、カスタム・エラー・コードとフォルトの詳細を示す説明を含むコンテキスト変数$faultを設定します。そのために、SOAPフォルトの<SOAP-ENV:Fault>要素の下にある3つの要素のコンテンツが抽出され、Service Busのfault要素の作成に使用されます。
サービスが次のエラーを返すシナリオを例にとります。
例 - サービス・コールアウトから返される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>要素にラップされます。「予期しないレスポンス」の例のfaultcode要素にはQNameが含まれ、関連するすべてのネームスペース宣言が保持されます。トランスポートがHTTPの場合、ReceivedFault要素にはフォルト・レスポンスとともに返されるHTTPエラー・コードも含まれます。
生成される<alsb:ReceivedFault>要素、およびカスタム・エラー・コードとエラー文字列は、faultコンテキスト変数のコンテンツの作成に使用されます。この例では、前述の例と同様の形式になります。
例 - Service Busのfault変数のコンテンツ - SOAPフォルト
<ctx:Fault xmlns:ctx="http://www.bea.com/wli/sb/context">
<ctx:errorCode>OSB-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:Client
</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>
注意:
一意のエラー・コードOSB-382500は、サービス・コールアウト・アクションがSOAPフォルト・レスポンスを受け取ったときに備えて予約されています。
ローカル・プロキシ・サービスをチェーンする場合、$fault変数ではSOAPフォルトの詳細はあるパイプラインから次へは伝搬されません。『Oracle Service Busでのサービスの開発』のプロキシ・サービス間でのSOAPフォルトの伝播に関する項で説明しているように、プロキシ・サービス間でSOAPフォルトを伝播するには、失敗時の返信アクションを指定したエラー・ハンドラを使用します。
プロキシ・サービスのランタイムが予期していないレスポンス・メッセージがサービスから返された場合、メッセージ・コンテキスト・フォルトが生成され、カスタム・エラー・コードOSB-382501で初期化されます。フォルトの詳細にはレスポンスのSOAP-Body要素のコンテンツが含まれます。トランスポートがHTTPの場合、ReceivedFault要素にはフォルト・レスポンスとともに返されるHTTPエラー・コードも含まれます。
次の例では、サービス・コールアウトで生成されるフォルトの詳細のXMLスキーマ定義を示します。
例 - サービス・コールアウトで生成されるフォルトの詳細の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>
次のパラグラフで説明するプロセスでは、エラー・ハンドラ・ステージのエラー処理パイプラインを構成します。また、エラー・パイプラインは、パイプライン・ペアのリクエストまたはレスポンス、またはパイプライン全体に対して定義できます。
ステージ・レベルのエラー・ハンドラがエラー処理に呼び出されます。ステージ・レベルのエラー・ハンドラが特定タイプのエラーを処理できない場合、パイプライン・エラー・ハンドラが呼び出されます。パイプライン・レベルのエラー・ハンドラもエラーを処理できない場合は、サービス・レベルのエラー・ハンドラが呼び出されます。サービス・レベルのエラー・ハンドラも処理できない場合、システムがエラーを処理します。表12-9に、パイプラインの様々なレベルにおけるエラー・ハンドラのスコープの概要を示します。
表12-9 エラー・ハンドラのスコープ
| レベル | スコープ |
|---|---|
ステージ |
ステージ内のすべてのエラーを処理します。 |
パイプライン |
パイプラインのステージの未処理のエラーと共に、パイプラインのすべてのエラーを処理します。 |
サービス |
サービスのパイプライン・ペアのリクエストまたはレスポンスの未処理のエラーとともに、パイプラインのすべてのエラーを処理します。 注意: WS-Securityエラーはすべてこのレベルで処理されます。 |
システム |
パイプラインのどの場所でも処理されないすべてのエラーを処理します。 |
注意:
エラー・ハンドラのスコープには例外があります。たとえば、ステージ・レベルの非XMLトランスフォーメーションによってスローされる例外を捕捉するのは、サービス・レベルのエラー・ハンドラのみです。プロキシ・サービスの送信レスポンス・メッセージ用にXMLからMFLに変換する場合、このトランスフォーメーションは常にバインディング・レイヤーで発生します。したがって、たとえば、非XML出力でステージ・レベルの必須フィールドが欠落している場合、サービス・レベルのエラー・ハンドラだけがこのエラーを捕捉できます。
アサーションがtrueであるかどうかを確認するテストを構成することでエラーを処理できます。このテストは様々なレベルで繰り返すことができます。下位レベルでエラー・ハンドラのない状態でエラーが発生した場合、パイプラインの上位レベルのエラー・ハンドラによって処理することもできます。
通常、パイプラインのステージ・レベルで特定のエラーを処理し、下位レベルでは処理されないエラーのより一般的なデフォルト処理に上位レベルのエラー・ハンドラを使用する方が簡単です。予期されるエラーをパイプラインで明示的に処理し、予期されないエラーをサービス・レベルのハンドラで処理することをお薦めします。
メッセージ処理中に発生したエラーに関する情報はすべて、事前定義されたコンテキスト変数(fault変数)に保持されます。エラーが発生すると、この変数に情報が格納されてから、適切なエラー・ハンドラが呼び出されます。このfault変数はエラー・ハンドラ・パイプラインでのみ定義され、リクエスト・パイプラインやレスポンス・パイプライン、ルート・ノードやブランチ・ノードでは設定されません。$faultの詳細は、「事前定義されたコンテキスト変数」を参照してください。
リクエスト/レスポンス型のインバウンド・メッセージでのエラー発生時には、多くの場合、エラーが発生した理由を説明するメッセージを送信元に返送する必要があります。そのためには、送信するレスポンスに対してメッセージ・コンテキスト変数を構成した後、失敗時の返信アクションを使用します。たとえば、HTTPメッセージが失敗した場合は、失敗時の返信でHTTP 500ステータスが生成されます。JMSメッセージが失敗した場合は、失敗時の返信でJMS_BEA_Errorプロパティがtrueに設定されます。
プロキシ・サービスが呼び出したサービスがSOAPフォルトまたはトランスポート・エラーを返すと、エラー処理パイプラインが呼び出されます。受信したSOAPフォルトはすべて$bodyに格納されるため、$bodyを変更せずに失敗時の返信を実行すると、サービスの呼出し元のクライアントには元のSOAPフォルトが返されます。返信アクションが構成されていない場合、システム・エラー・ハンドラによって新しいSOAPフォルト・メッセージが生成されます。プロキシ・サービスでは、HTTPエラー・ステータスが設定されたか、JMSプロパティSERVER_Errorがtrueに設定されているためにSOAPフォルトが返されたと認識されます。
用途によっては、エラー・レポートが必要な場合があります。このような場合は、レポート・アクションを使用します。たとえば、リクエスト・パイプラインで追跡用にメッセージをレポートするレポート・アクションを実行した後、ルート・ノードによって呼び出されたサービスが失敗するというシナリオを想定します。このような場合、メッセージはレポート・システムによってログに記録されますが、メッセージが正常に処理されたという保証はありません。メッセージが正常に受信されたことを示すだけです。
Oracle Service Busコンソールでは、メッセージを追跡することによって、メッセージ・フローの正確な流れを把握することができます。これにより、メッセージが処理のために送信されたことをレポートする元のメッセージだけでなく、メッセージが正常に処理されなかったことをレポートする以降のエラーも確認できます。レポート・アクションの構成方法と実行時にレポートされるデータの使用方法については、「Oracle Service Busコンソールでのパイプライン・アクションの操作」を参照してください。
Service Bus 12cは、メッセージ・フローのセキュリティ・フォルトをService Bus 11gとは別の方法で処理します。
Service Bus 11gでは、失敗したOWSMポリシーまたはインバウンド・リクエストのカスタム・トークン・メッセージ・レベル認証は、パイプライン・メッセージ・フローでユーザー構成サービス・エラー・ハンドラにより処理できます。たとえば、ユーザー名トークン認証ポリシーのサービスで、認証の失敗はサービスレベル・エラー・ハンドラをトリガーします(構成されている場合)。
Service Bus 12cでは、インバウンド・リクエストのセキュリティ処理によって発生するセキュリティ・エラーはパイプライン・サービスレベルのエラー・ハンドラでは処理されず、このSOAPフォルトの結果はデフォルト・インバウンドのシステム・エラー・ハンドラによって自動的に生成されます。これらのフォルトはカスタマイズできません。失敗したリクエストを次のコンポーネント(たとえば、パイプラインまたはビジネス・サービス)にルーティングすることはできません。
この例では、エラー・ハンドラにレポート・アクションと返信アクションを構成する方法を示します。図12-1に示すパイプラインには、validate loan applicationステージのエラー・ハンドラが含まれています。この例のエラー・ハンドラは、1つのステージが構成された単純なメッセージ・フローです。Oracle Service Busコンソールには、図12-1のように表示されます。
図12-2に示すように、このステージはアクション(置換、レポートおよび返信)で構成されています。
アクションによって、パイプライン・エラー・ハンドラのステージの動作が次のように制御されます。
置換: body変数の指定した要素のコンテンツが、faultコンテキスト変数のコンテンツで置換されます。body変数の要素はXPath式で指定します。コンテンツは、XQuery式で返される値で置換されます。この例では$fault/ctx:reason/text()です。
レポート: このアクションで構成されたエラー・ハンドラが呼び出されると、レポート・アクションのメッセージがService Busレポート・データ・ストリームに書き込まれます。JMSレポート・プロバイダによって、メッセージがFusion Middleware ControlのService Busダッシュボードでレポートされます。Service Busには、メッセージ・データを1つ以上のレポート・プロバイダに配信する機能があります。メッセージ・データは、メッセージの本文、およびメッセージに関連付けられた他の任意の変数(ヘッダーやinbound変数など)から取り込むことができます。レポート・プロバイダに配信されたメッセージは、メッセージのトラッキングや規制の監査などの機能に使用できます。
エラーが発生すると、faultコンテキスト変数のコンテンツがレポートされます。キー名はerrorCodeです。キー値は./ctx:errorCodeというXPath式を使用してfault変数から抽出されます。キーと値のペアをキー識別子として使用して、実行時にダッシュボードでこれらのメッセージを識別します。
レポート・アクションを構成し、実行時にレポートされるデータを使用するには、「Oracle Service Busコンソールでのパイプライン・アクションの操作」を参照してください。
返信: 実行時に、loanGateway3プロキシ・サービスの呼出し元に即時返信が送信され、メッセージにフォルトが含まれていたことが示されます(図12-2を参照)。この返信は「失敗時」です。
作成するパイプラインから呼び出す必要があるサービスがわからない場合に、動的ルーティングを使用できます。どのパイプラインでも、次のいずれかの方法を使用して、メッセージを動的にルーティングできます。
Service Busの完全修飾サービス名を動的に設定し、動的ルート・アクションまたは動的パブリッシュ・アクションを使用するように、メッセージ・フロー・パイプラインでXQuery式を設計します。
注意:
動的ルーティングはルート・ノードで使用でき、動的パブリッシュはリクエスト・パイプラインまたはレスポンス・パイプラインのステージで使用できます。
この方法を使用すると、パイプラインでは、エンドポイント・ビジネス・サービスのサービス・アカウントを動的に使用して、ユーザー名とパスワードをそのアウトバウンド・リクエストに送信します。たとえば、パイプラインがビジネス・サービスAにリクエストをルーティングする場合、呼出し元プロキシ・サービスではビジネス・サービスAのサービス・アカウントを使用して、ユーザー名とパスワードをそのアウトバウンド・リクエストに送信します。「動的ルーティングの実装」を参照してください。
ビジネス・サービスにメッセージをルーティングまたはパブリッシュするように、パイプラインを構成します。次に、ルート・アクションまたはパブリッシュ・アクションのリクエスト・アクション・セクションで、サービスのURIを動的に指定するルーティング・オプション・アクションを追加します。
この方法を使用すると、リクエストの送信先のURIに関係なく、ユーザー名とパスワードをそのアウトバウンド・リクエストに送信するために、プロキシ・サービスは静的に定義されたビジネス・サービスのサービス・アカウントを使用します。
この方法の使用方法については、「動的ルーティングの実装」を参照してください。
注意:
この方法は、インタフェースの概要が確定している場合に使用します。インタフェースの概要には、メッセージのタイプ、ポート・タイプ、およびバインディングが含まれます。具象インタフェースは含まれません。具象インタフェースは、サービスが配置されているトランスポートURLです。
動的サービスの呼出しの操作例については、http://www.oracle.com/technetwork/middleware/service-bus/learnmore/index.htmlでService Busのサンプルを参照してください。
動的ルーティングを使用すると、パイプラインの実行時に宛先を確定できます。これを行うには、XMLファイルのルーティング表を使用して、XQueryリソースを作成します。
注意:
XQueryリソースを使用するかわりに、リソースの作成元のXMLファイルを直接使用することもできます。
XMLファイルまたはXQueryリソースは容易に保持できます。実行時に、パイプラインのルーティング先またはパブリッシュ先を決定するルーティング・テーブルにエントリを指定します。XMLファイルまたはXQueryリソースには、論理的な識別子(企業名など)を物理的な識別子(Service Busのサービスの完全修飾名)にマップするルーティング・テーブルが含まれています。メッセージから抽出された論理的な識別子は、呼び出すサービスの名前である物理的な識別子にマップされます。
注意:
動的ルート・アクションを使用するには、Service Busのサービスの完全修飾名が必要です。
パイプラインでは、論理的な修飾子はXPathを使用してメッセージに取得されます。XQueryリソースのXML表を変数に割り当てます。ルーティング表の変数に問合せを実装し、対応する論理的な修飾子に基づいて物理的な修飾子を抽出します。この変数を使用すると、必要なサービスを呼び出すことができます。次の項では、動的ルーティングの実装方法を説明します。
次のXMLファイルからXQueryリソースを作成できます。sampleXquery.xmlとしてこれを保存します。
例 - サンプルXMLファイル
<routing>
<row>
<logical>Oracle</logical>
<physical>default/goldservice</physical>
</row>
<row>
<logical>ABC Corp</logical>
<physical>default/silverservice</physical>
</row>
</routing>
Oracle Service BusコンソールでサンプルXMLからXQueryリソースを作成するには:
認証済ユーザーのIDをベースにしたメッセージの動的ルーティングを行う場合、Service Busはユーザー名、グループ・メンバーシップ(/principals/group)、サブジェクト名(/subject-properties/property/name)などの情報を次のインバウンド・コンテキスト変数に格納します。
$inbound/ctx:security/ctx:transportClient/*
$inbound/ctx:security/ctx:messageLevelClient/*
これらのコンテキスト変数の詳細は、表A-6を参照してください。
「動的ルーティングの使用」で説明されているガイダンスに従って、目的のマッピング方法としてXQueryまたは簡単なXMLを使用して、認証済ユーザーのID特性を異なるエンドポイントにマップします。
次の事前定義されたService Bus XQuery関数も、IDベースのルーティングのセキュリティ・チェックの実行に使用できます。
動的サービスの呼出しの操作例については、http://www.oracle.com/technetwork/middleware/service-bus/learnmore/index.htmlでService Busのサンプルを参照してください。
Service Busでは、カスタムのEJBコードやJavaコードを記述したり、Oracle Data Service Integratorなどの別のデータベース製品を使用せずに、パイプラインからデータベースに対して読取りアクセスを行うことができます。execute-sql()関数を使用して、データベースに対して簡単なJDBC呼出しを行い、単純なデータベースの読取りを実行できます。指定した地域の税率を取得する単純な問合せや、複雑な結合を使用して、基になる複数のデータベース表から注文の現在のステータスを取得する問合せなど、任意のSQL問合せが有効です。
データベース問合せを使用してデータを取得し、メッセージに情報を追加したり、ルーティング先を選択したり、パイプラインの動作をカスタマイズできます。Service Busパイプラインが「見積依頼」メッセージを受信する場合のシナリオを例として示します。パイプラインは、顧客の優先度に基づいて、見積りを提供する複数のビジネス・サービス(たとえば標準、ゴールド、プラチナ・レベルのサービス)のいずれかにリクエストをルーティングできます。その後で、パイプラインは、それらのサービスが返す結果をSQLベースで補強します。たとえば、選択した出荷方法と注文品の重量に基づいて送料を検索し、そのコストを見積依頼メッセージに追加できます。
関数の構文とその使用例については、「fn-bea:execute-sql()」を参照してください。execute-sql()関数は型付きデータを返し、SQL/JDBCデータ・モデルとXQueryデータ・モデル間で値を自動的に変換します。
返された要素を、Service Busパイプラインのユーザー定義の変数に格納できます。
execute-sql()関数でサポートされるデータベースおよびJDBCドライバは次のとおりです。
WebLogic Serverに含まれるサンプル・データベース。
IBM DB2/NT 8
Microsoft SQL Server 2000、SQL Server 2005
Oracle9i、Oracle Database 10g、Oracle Database 11g、Oracle Database 12c
Sybase 12.5.2および12.5.3
WebLogic Type 4 JDBCドライバ
WebLogic Serverでサポートされるサード・パーティ製ドライバ
「fn-bea:execute-sql()」関数で使用するデータソースには、非XAドライバを使用してください。この関数は、データソースへの読取り専用アクセスをサポートしています。
警告:
データベースへの接続に使用する非XA JDBCドライバ・クラスの指定に加え、グローバル・トランザクションと2フェーズ・コミットを必ず無効にする必要があります。(Oracle WebLogic Server管理コンソールで、グローバル・トランザクションはJDBCデータ・ソースに対してデフォルトでは有効です。)データ・ソースに対するこれらの指定は、Oracle WebLogic Server管理コンソールを介して行うことができます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの作成に関する項を参照してください。
Service BusでサポートされているデータベースおよびJDBCドライバの詳細は、次の場所にあるOracle Fusion Middlewareのサポートされるシステム構成を参照してください。
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
前述のリストに示したコア・セット以外のデータベースもサポートされています。ただし、前述のコア・データベースでは、非コア・データベースの場合よりも、XQueryエンジンが適切にデータ型を認識し、XQueryタイプにマップします。データを取得する際に、コア・データベースの独自のJDBC拡張が使用される場合もあります。非コア・データベースでは、XQueryエンジンは、JDBCドライバが提供する標準タイプのコード、および標準のJDBC結果セットのアクセス・メソッドに完全に依存します。
パイプラインを設計する際に、XQueryはリソースとして入力するのではなく、アクション定義の一部としてインラインで入力できます。パイプラインでIf Thenアクションの条件にインラインXQueryを使用することもできます。インラインXQueryエディタの使用については、「変数の構造のマッピングの作成」を参照してください。
メッセージ・コンテキストは、Service Busを介してメッセージがルーティングされるときに、メッセージ・コンテキストとメッセージに関する情報を保持する一連の変数です。header、bodyおよびattachmentsの各変数(XQuery文では、$header、$bodyおよび$attachments)は、Service Busを介して流れるメッセージを表します。メッセージの標準書式はSOAPです。サービス・タイプがSOAPでなくても、メッセージはService Busのメッセージ・コンテキスト内でSOAPとして表示されます。
表12-10に、Service Busメッセージ・コンテキスト変数を示します。
表12-10 Service Busの事前定義されたコンテキスト変数
| コンテキスト変数 | 説明 | 関連項目 |
|---|---|---|
header |
SOAPメッセージの場合、 メッセージのタイプがSOAP以外の場合、 |
|
body |
この変数は、次に説明するようにメッセージ・タイプに応じて異なります。
|
|
attachments |
メッセージのMIME添付。 |
|
inbound |
インバウンド・トランスポート・ヘッダーとメッセージを受信したプロキシ・サービスについての情報。 |
|
outbound |
アウトバウンド・トランスポート・ヘッダーとメッセージが送信されるターゲット・サービスについての情報。 |
|
operation |
パイプラインで呼び出される操作 |
|
fault |
メッセージの処理中に発生したエラーに関する情報。 |
|
messageId |
トランスポート・プロバイダ固有のメッセージIDです。このIDは、Service Busランタイムを通過するその他のメッセージからメッセージを一意に識別できることが必要です。ただし、この値は一意である必要はありません。 |
メッセージ・コンテキストでは、$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式を使用する必要があります。Service Busで事前定義されているコンテキスト変数は、次のように分類されます。
メッセージ関連の変数
inbound変数およびoutbound変数
operation変数
fault変数
事前定義されたコンテキスト変数の詳細は、「事前定義されたコンテキスト変数」を参照してください。
$bodyには、メッセージのペイロード変数が含まれます。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要素が格納されると、ターゲット・サービスのタイプに関係なく、内部的に格納された参照先コンテンツがそのまま送信されます。
詳細は、「メッセージ・コンテキスト」を参照してください。
メッセージ・コンテキスト変数の型は、メッセージ・コンテキスト・スキーマ(MessageContext.xsd)によって定義されます。Oracle XQuery Mapperでメッセージ・コンテキスト変数を操作する場合は、JARファイル(OSB_ORACLE_HOME/lib/sb-schemas.jar)に用意されたMessageContext.xsdと、次の場所にあるトランスポート固有のスキーマを参照する必要があります。
OSB_ORACLE_HOME/lib/transports/
メッセージ・コンテキスト・スキーマおよびトランスポート固有のスキーマの詳細は、「メッセージ・コンテキスト・スキーマ」を参照してください。
メッセージ・コンテキストを検査または変更するときには、次のガイドラインを考慮してください。
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要素のコンテンツ)を置換します。詳細は、「XQueryでのデータの変換」および「XSLTでのデータの変換」を参照してください。
挿入アクションまたは置換アクションを使用すると、単一の要素に対する挿入または置換だけでなく、選択した要素のシーケンスに対しても挿入または置換を行うことができます。要素のシーケンスを返すようXQuery式を構成できます。たとえば、挿入アクションおよび置換アクションを使用して、$inboundから$outboundに一連のトランスポート・ヘッダーをコピーすることができます。アクションの追加の詳細は、「コンソールでのパイプライン・アクションの追加と編集」を参照してください。使用例については、「inboundからoutboundへのJMSプロパティのコピー」を参照してください。
プロキシ・サービスと呼び出されるビジネス・サービスのインタフェースが異なることが前提になっています。そのため、Service Busでは、inbound変数からoutbound変数への情報(トランスポート・ヘッダーやJMSプロパティなど)を伝播しません。
プロキシ・サービスのリクエスト・メッセージとレスポンス・メッセージのトランスポート・ヘッダーは$inboundに含まれ、呼び出されるビジネス・サービスのリクエストとレスポンスのトランスポート・ヘッダーは$outboundに含まれます。
たとえば、一方向メッセージ(レスポンスのない呼出し)で、ユーザー定義のJMSプロパティをインバウンド・メッセージからアウトバウンド・メッセージにコピーする必要がある場合、次のXQuery式を使用できます。
トランスポート・ヘッダー・アクションを使用して、次を設定します
$inbound/ctx:transport/ctx:request/tp:headers/tp:user-header
次の最初の子として:
./ctx:transport/ctx:request/tp:headers
出力変数の中で。
トランスポート・ヘッダー・アクションの構成方法の詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。
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式エディタを使用して変数の構造を作成します。「変数の構造の使用」を参照してください。
$headerまたは$bodyに含まれるSOAPエンベロープの要素からビジネス・ドキュメントまたはRPCパラメータを抽出したり、アクセスします。
$attachmentsに含まれる添付ドキュメントを抽出したり、アクセスします。
サービス・コールアウト・アクションのパラメータをSOAPエンベロープから抽出して設定します。
サービス・コールアウト・アクションの結果パラメータをSOAPエンベロープに挿入します。
for loopを実行するためにSOAPエンベロープからシーケンスを抽出します。
更新アクションで、for loop内のシーケンスの項目を更新します。
注意:
インラインXQuery式エディタを使用して、変数の構造を作成することもできます。詳細は、「変数の構造の使用」を参照してください。
インラインXQueryエディタとインラインXPathエディタでは、変数の構造を型または要素にマップし、その構造のグラフィック表現からドラッグ・アンド・ドロップ操作によってパス式を作成することにより、変数の構造を宣言できます。また、パス式を手動で入力することもできます。
この機能は、すべてのユーザー定義変数と$inbound、$outboundおよび$faultに対して直接使用できます。ただし、この機能を使用して$attachmentsのXML添付ファイル、$headerのヘッダーまたは$bodyのドキュメントとRPCパラメータに直接アクセスすることはできません。例外として、WSDLベースのプロキシ・サービスによって受信されたリクエスト・メッセージの$bodyのドキュメントとパラメータには直接アクセスできます。
変数の構造の作成方法の詳細は、「変数の構造のマッピングの作成」を参照してください。
XQueryエンジンのサポート、およびOracleの関数と演算子の関係の詳細は、「Service Bus XQuery関数」を参照してください。
通常、インラインXQuery式エディタは、次のもので構成される簡単なXQueryを入力するときに使用します。
XQueryが埋め込まれたXMLフラグメント
child軸に沿った単純な変数パス
注意:
複雑なXQueryには、ドラッグ・アンド・ドロップ機能を備えたOracle XQuery Mapperを使用することをお薦めします。『Oracle SOA SuiteでのSOAアプリケーションの開発』のXQueryマッパーでの変換の作成に関する項を参照してください。
インラインXQueryの適切な使用例は次のとおりです。
$headerまたは$bodyに含まれるSOAPエンベロープの要素からビジネス・ドキュメントまたはRPCパラメータを抽出したり、アクセスします。
$attachmentsに含まれる添付ドキュメントを抽出したり、アクセスします。
サービス・コールアウトのパラメータをSOAPエンベロープから抽出して設定します。
サービス・コールアウトの結果パラメータをSOAPエンベロープに挿入します。
for loopを実行するためにSOAPエンベロープからシーケンスを抽出します。
更新アクションで、for loop内のシーケンスの項目を更新します。
インラインXQuery式エディタを使用して、変数の構造を作成することもできます。詳細は、「変数の構造の使用」を参照してください。
インラインXQuery式エディタを使用すると、変数の構造を作成することができます。これにより、設計の目的で特定の変数の構造を定義できます。たとえば、XPath変数のXMLスキーマを表示するよりも、管理コンソールでXPath変数を参照する方が簡単です。Oracle Service Busコンソールでの変数の構造の使用例は、「変数の構造のマッピングの作成」を参照してください。
注意:
ランタイムを作動させるために変数の構造を作成する必要はありません。変数の構造によって、変数の構造や変数パスが定義されますが、変数は作成されません。変数は、ステージでの割当てアクションの対象として実行時に作成されます。
一般的なプログラミング言語では、変数のスコープは静的です。変数の名前と型は明示的に宣言されます。静的なスコープ内の任意の場所から変数にアクセスできます。
Service Busにはいくつかの事前定義された変数が存在しますが、変数を動的に作成し、割当てアクションまたはforループ内のループ変数を使用して変数に値を割り当てることもできます。変数に値を割り当てると、パイプラインの任意の場所から変数にアクセスできるようになります。変数の型は宣言されませんが、原則として、任意の時点で変数に格納されている基礎になる値の型が変数の型になります。
注意:
forループの変数のスコープは制限されており、ステージ外からはアクセスできません。
インラインXQuery式エディタを使用すると、XQueryには0以上の入力と1つの出力が含まれます。式エディタ自体に入力と出力の構造を表示できるため、インラインXQueryを作成するときに、XMLスキーマまたはWSDLリソースを開いて構造を確認する必要はありません。構造が視覚的に表示されるため、作成中のXQueryに述部を指定せずに、child軸に沿って単純な変数パスをドラッグ・アンド・ドロップすることができます。
変数の構造のマッピングでは、各エントリはラベルを持ち、変数または変数パスを1つまたは複数の構造にマップします。これらのマッピングのスコープはステージまたはルート・ノードです。変数は静的に型指定されないので、1つの変数がステージまたはルート・ノードの様々な位置(または同じ位置)で複数の異なる構造を持つことができます。つまり、1つの変数または変数パスを複数の構造にマップし、それぞれに異なるラベルを使用することができます。構造を表示するには、リストで対応するラベルを選択します。
注意:
インラインXPath式エディタでも変数の構造のマッピングを作成できます。ただし、変数または変数パスは構造にマップされますが、構造から選択したときに生成されるXPathは、変数を基準にした相対XPathです。./ctx:attachment/ctx:bodyは、相対XPathの一例です。
次の項では、Service Busメッセージングのサービス品質機能について説明します。
Service Busでは、信頼性のあるメッセージングがサポートされます。メッセージがルート・ノードから別のサービスにルーティングされるとき、プロキシ・サービスがトランザクションに対応するよう構成されている場合、デフォルトのサービス品質(QoS)は「必ず1回」で、それ以外の場合、「ベスト・エフォート」のQoSがサポートされます。
サービスの品質は、$outboundコンテキスト変数のqualityOfService要素で設定されます。
Service Busに用意されている配信の保証のタイプを表12-11に示します。
表12-11 配信の保証のタイプ
| 配信の信頼性 | 説明 |
|---|---|
必ず1回 |
「必ず1回」の信頼性では、アウトバウンド・メッセージの送信が開始されるまで終了エラーが発生しないことを前提として、メッセージがインバウンドからアウトバウンドに1回のみ配信されます。「必ず1回」は、信頼性が最適化されることを意味します。 「必ず1回」の配信の信頼性は提案であり、命令ではありません。「必ず1回」を指定すると、可能な場合に「必ず1回」の信頼性が提供されます。「必ず1回」が不可能な場合は、「1回以上」の配信セマンティクスが試行され、これも不可能な場合は「ベスト・エフォート」の配信が実行されます。 トランザクションに対応するよう構成されているプロキシ・サービスのサービス品質は、「必ず1回」です。 次のインバウンド・トランスポートでも、ルート・ノード・アクションの
注意: |
1回以上 |
「1回以上」のセマンティクスは、アウトバウンド・メッセージの送信が開始されるまで終了エラーが発生しないことを前提として、メッセージがインバウンドからアウトバウンドに少なくとも1回は配信されることを意味します。ターゲット・サービスがトランスポートレベルのエラーとともに応答した場合でも、配信は成功と見なされます。ただし、タイムアウト、接続エラー、または通信リンクの中断が発生した場合は成功とは見なされません。フェイルオーバーURLが指定されている場合は、少なくとも1つのURLについて「1回以上」のセマンティクスが提供されます。 「必ず1回」が不可能であるが、 |
ベスト・エフォート |
「ベスト・エフォート」は、信頼性のあるメッセージングが存在せず、重複するメッセージが除去されないが、パフォーマンスは最適化されることを意味します。 次のインバウンド・トランスポートの場合、ルート・ノードの
次の場合、
注意: パブリッシュ・アクションで |
他のトランスポートのサービス品質の詳細は、『Oracle Service Busでのサービスの開発』のトランスポートに関する項を参照してください。
デフォルトの「必ず1回」のサービス品質属性をオーバーライドするには、アウトバウンド・メッセージのコンテキスト変数($outbound)でqualityOfServiceを設定する必要があります。詳細は、「メッセージ・コンテキスト・スキーマ」を参照してください。
次のパイプライン・アクションの場合、デフォルトのqualityOfService要素属性をオーバーライドできます。
パブリッシュ
動的にパブリッシュ
パブリッシュ表
サービス・コールアウト
ルーティング
動的ルーティング
ルーティング表
qualityOfService要素属性をオーバーライドするには、前述の任意のアクションにルーティング・オプション・アクションを追加し、QoSオプションを選択し、オーバーライド値を選択します。
パイプラインがメッセージをパブリッシュするか、リクエストをビジネス・サービスにルーティングするときは、次の条件に応じて配信の保証がサポートされます。
qualityOfService要素の値
インバウンド・トランスポート(および該当する場合は接続ファクトリ)
アウトバウンド・トランスポート(および該当する場合は接続ファクトリ)
ただし、インバウンド・プロキシ・サービスがローカル・トランスポートで、呼出し元が別のプロキシ・サービスである場合、呼出し元のプロキシ・サービスのインバウンド・トランスポートが配信の保証を行います。呼び出されたプロキシ・サービスのトランスポートがローカル・トランスポートの場合、呼出し元のプロキシ・サービスが最適化されて、直接呼出しになるためです。トランスポート・プロトコルの詳細は、「プロキシ・サービスの作成と構成」および「ビジネス・サービスの作成と構成」を参照してください。
注意:
プロキシ・サービスからのレスポンスには配信の保証はありません。
配信の保証に適用されるルールを表12-12に示します。
表12-12 配信の保証のルール
| 提供される配信の保証 | ルール |
|---|---|
必ず1回 |
プロキシ・サービスのインバウンド・トランスポートはトランザクションに対応し、アウトバウンド・トランスポートへの |
1回以上 |
プロキシ・サービスのインバウンド・トランスポートはファイル、FTPまたは電子メールで、 |
1回以上 |
プロキシ・サービスのインバウンド・トランスポートはトランザクションに対応し、トランザクション非対応のアウトバウンド・トランスポートへの |
配信の保証なし |
その他の場合(すべてのレスポンス処理を含む)。 |
注意:
JMSにより配信の保証として「1回以上」および「必ず1回」をサポートするには、JMSトランザクションを利用し、サーバーがクラッシュした場合、または返信アクションや再開アクションのエラー・ハンドラで処理できないエラーが発生した場合にメッセージを再配信できるように、JMSキューの再試行回数と再試行間隔を構成する必要があります。ファイル、FTP、および電子メール・トランスポートでも、内部ではJMS/XAキューが使用されます。JMS/XAトランスポートを使用したプロキシ・サービスのデフォルトの再試行回数は1です。
配信の保証のその他のルールは次のとおりです。
インバウンド・プロキシ・サービスのトランスポートでトランザクションが伝播または開始される場合、リクエスト処理は1つのトランザクションで実行されます。
qualityOfService要素がexactly-onceに設定されている場合、トランザクション対応の宛先へのリクエスト・フローで実行されるルート・ノード・アクションは、すべて同一トランザクションで実行されます。トランザクション・コンテキスト内のパブリッシュ・アクションとサービス・コールアウト・アクションは、デフォルトではbest-effortであるため、トランザクション・コンテキスト外で実行されます。これらのアクションを「必ず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などの非同期トランスポートの場合、ランタイム・エラーが発生します。
Service Busのスレッド・モデルは次のように作動します。
プロキシ・サービスのリクエストおよびレスポンスのパイプラインは、常に個別のスレッドで実行されます。
外部サービスを呼び出すと、スレッドはパイプライン・アクションに応じてサービス品質オプションおよび使用するトランスポートをブロックする場合があります。
サービス・コールアウトは常にブロックします。qualityOfService要素の値がbest-effortの場合、HTTPルート・アクションまたはパブリッシュ・アクションはブロックしません(リクエスト/レスポンスまたは一方向呼出しの場合)。
JMSルート・アクションまたはパブリッシュ・アクションは常にブロックしません。ただし、Service Busには永続メッセージ処理状態がないため、リクエストが送信された後でサーバーが再起動するとレスポンスが失われます。
注意:
リクエスト・フローまたはレスポンス・フローのパブリッシュ・アクションでは、レスポンスは常に破棄されます。これは、パブリッシュ・アクションは本質的に一方向のメッセージ送信であるためです 。
ブロッキング・コールを使用する場合、サーバー・デッドロックを回避するため、最小スレッド数制約のあるワーク・マネージャをレスポンスに関連付ける必要があります。最小スレッド数制約により、処理する最小スレッド数が保証されます。
ワーク・マネージャの一般情報は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。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回再試行されてから終了します。システムは指定された再試行間隔の時間だけ待機してから、シーケンスの次のループを開始します。再試行回数が完了してもまだエラーがある場合、ルート・ノードのエラー・ハンドラ・パイプラインが呼び出されます。
注意:
HTTPトランスポートの場合、Service Busでは200または202以外のHTTPステータスはエラーと見なされるため、再試行する必要があります。このアルゴリズムにより、Service Busでは、解決することのできない認証エラーなどのエラーを、そのURLで一定期間再試行することが可能です。これに対して、Service Busで任意のメッセージの送信を再試行するときに別のURLにフェイルオーバーする場合は、新しいURLではエラーにならない可能性があります。
quality of serviceがexactly-onceの場合、フェイルオーバーや再試行は行われません。
WebLogic Serverは、アプリケーションとWebサービス環境のパフォーマンスを最適化し、ワーク・マネージャという機能を使用してサービス・レベル合意を保持する際に役立ちます。ワーク・マネージャのリソースを作成し、作業実行ルールを定義することによって、作成したリソースを構成します。WebLogic Serverではワーク・マネージャのルールを使用して、作業の優先順位を付け、ワーク・マネージャが配置されているどのようなアプリケーションやコンポーネントにもスレッドを割り当てることができます。
ワーク・マネージャの一般情報は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。Service Busのワーク・マネージャおよびスレッディングの詳細は、「ワーク・マネージャとスレッド」を参照してください。
Service Busでは、プロキシ・サービスおよびビジネス・サービスのいくつかのトランスポートで、ワーク・マネージャとサービスを関連付けてサービス作業の優先順位を付けることができる、「ディスパッチ・ポリシー」という構成オプションが提供されます。この項では、プロキシ・サービスとビジネス・サービスでワーク・マネージャを使用する方法について説明します。
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の詳細は、「サービスの品質」を参照してください。
Service Busでは、異種のエンドポイント間での相互運用性を確保するため、使用するコンテンツ・タイプ、JMSタイプおよびエンコーディングをそれぞれ制御できます。
Service Busでは外部のクライアントまたはサービスに必要な情報が想定されませんが、サービス定義で構成済の情報が使用されます。アウトバウンド・メッセージのコンテンツ・タイプは、サービス・タイプとインタフェースから派生します。コンテンツ・タイプは、電子メールおよびHTTPプロトコルの一部です。
サービス・タイプごとのコンテンツ・タイプを次に示します。
XMLまたはSOAP (WSDLファイルの有無を問わない)の場合、コンテンツ・タイプはtext/XML。
インタフェースがMFLまたはバイナリのメッセージングの場合、コンテンツ・タイプはbinary/octet-stream。
インタフェースがテキストのメッセージングの場合、コンテンツ・タイプはtext/plain。
インタフェースがXMLのメッセージングの場合、コンテンツ・タイプはtext/XML
インタフェースがJavaのメッセージングの場合、コンテンツ・タイプはJavaオブジェクト。
また、JMSタイプには、Java型以外のメッセージ用のバイトまたはテキストを指定できます。Oracle Service BusコンソールまたはOracle JDeveloperでサービスを定義するときに使用するJMSタイプを構成します。
サービスを呼び出すプロキシ・サービスのアウトバウンド・コンテキスト変数($outbound)のコンテンツ・タイプ、およびプロキシ・サービス・レスポンスのインバウンド・コンテキスト変数($inbound)のコンテンツ・タイプはオーバーライドできます。$outboundコンテキスト変数と$inboundコンテキスト変数の詳細は、「inbound変数とoutbound変数」を参照してください。
すべてのアウトバウンド・メッセージのエンコーディングも、サービス定義で明示的に構成します。サービス定義の詳細は、「プロキシ・サービスの作成と構成」および「ビジネス・サービスの作成と構成」を参照してください。
Service Busでは、ビジネス・サービスへのメッセージ・フローを制限できます。このビジネス・サービスへのメッセージ・フローを制限する技術は、スロットルと呼ばれます。詳細は、『Oracle Service Busの管理』のメッセージ抑制に関するビジネス・サービスの構成に関する項を参照してください。
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コンソールまたはOracle JDeveloperを使用すると、Service Busでそのサービスに対してWS-I準拠を適用するかどうかを指定できます。詳細は、「ビジネス・サービスのセキュリティおよびセキュリティ・ポリシー」を参照してください。
プロキシ・サービスのWS-I準拠を構成すると、そのプロキシ・サービスが受信するインバウンド・リクエスト・メッセージでチェックが実行されます。呼び出されたサービスについてWS-I準拠を構成すると、その呼び出されたサービスからのレスポンス・メッセージを任意のプロキシが受信したときに、チェックが実行されます。デフォルトでは、プロキシ・サービスのSOAPクライアントはシステム・エラー・ハンドラ定義のエラーを受け取るため、このようなエラーに対応するエラー・ハンドラを作成することをお薦めします。
プロキシ・サービスから送信されるメッセージについては、それがアウトバウンド・リクエストでもインバウンド・レスポンスでも、WS-I準拠のチェックは明示的には実行されません。これは、ほとんどのメッセージ・コンテンツの生成はパイプライン設計者によって行われるためです。ただし、メッセージのService Busによって生成されるパートは、サポートされるWS-I準拠のすべてのチェックを満たします。次のコンテンツが含まれます。
サービス呼出しリクエスト・メッセージ
プロキシ・サービスによって返されるシステム生成のエラー・メッセージ
プロキシ・サービスによって生成されるHTTPステータス・コード
「WS-I準拠の適用」チェック・ボックスは、図12-3のように表示されます。
注意:
WS-I準拠チェックでは、サービスで呼び出される操作をシステムが認識する必要があります。つまり、プロキシ・サービスが受信するリクエスト・メッセージでは、コンテキスト変数$operationはnull以外の値であることが必要です。そのためには、操作選択アルゴリズムが適切に構成されていることが前提になります。呼び出されたサービスから受信するレスポンス・メッセージでは、ルート、パブリッシュ、およびサービス・コールアウトのアクション構成で操作が指定されている必要があります。
プロキシ・サービスまたはビジネス・サービスのWS-I準拠チェックを構成すると、Service Busで表12-13に示すチェックが実行されます。
表12-13 Service BusのWS-I準拠チェック
| チェック | WS-I基本プロファイルの詳細 | Service Busの説明 |
|---|---|---|
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バインディングで記述されたエンベロープがレスポンスである場合、対応する |
このチェックは、レスポンス・メッセージのみに適用されます。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リクエスト・メッセージは、 |
このチェックはリクエスト・メッセージに適用され、 |
Service Busは、SOAP 1.1とSOAP 1.2をサポートしています。SOAP 1.1プロキシ・サービスでSOAP 1.2ビジネス・サービスを呼び出すことも、その逆の呼出しを行うこともできます。しかし、SOAP 1.1と1.2に違いがあるため、Service Busは一部の状況で2つのSOAP間での自動変換を実行できません。SOAP 1.1と1.2の変換を適切に使用するには、次のガイダンスを使用してください。
ビジネス・サービスを呼び出す前に、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変換を実行する必要があります。
