|
|
Oracle Service Bus におけるメッセージ フローは、プロキシ サービスの実装を定義します。Oracle Service Bus プロキシ サービスは、Oracle Service Bus Console または Workshop for WebLogic 用の Oracle Service Bus プラグインで作成およびコンフィグレーションできます。この節では、メッセージ フローについて説明し、メッセージ フローを設計する際のガイドラインを示します。
以下の節では、Oracle Service Bus のメッセージ フローについて説明します。
Oracle Service Bus Console でメッセージ フローを作成およびコンフィグレーションする手順については、以下を参照してください。
Workshop for WebLogic でメッセージ フローを作成およびコンフィグレーションする手順については、以下を参照してください。
メッセージ フローは、プロキシ サービスを介してメッセージが流れるときのメッセージのルーティングと操作のロジックを定義するコンポーネントで構成されます。各ノードは、メッセージ フローでメッセージをルーティングするようにコンフィグレーションされます。また、ステージとアクションには、メッセージの処理とトランスフォーメーションに関するルールが含まれます。
メッセージ フローのほとんどの処理ロジックは、パイプラインで処理されます。パイプラインとは、分岐のない一方向の処理の流れを表す名前付きのステージ シーケンスです。パイプラインは、以下のカテゴリに分類されます。
プロキシ サービスの処理ロジックを実装するには、要求パイプラインと応答パイプラインをペアにしてパイプライン ペア ノードを作成します。これらのパイプライン ペア ノードを他のノードと結合して単一ルートのツリー構造を作成することで、フロー全体を制御できます。
メッセージ フローを定義する際に使用できるコンポーネントを表 3-1 に示します。
|
|
|
|
|
|
図 3-1 は、メッセージ フロー定義のコンポーネントの概要を示しています。
メッセージ フローの必須コンポーネントは、開始ノードとルート ノードだけです。メッセージ フローで連鎖できる他のコンポーネントに制限はありません。ルート ノードを 1 つ作成し、フローのすべてのロジックを格納できます。また、間にブランチ ノードを配置せずに 2 つのパイプライン ペア ノードを接続することもできます。ブランチ ノードを使用する場合、各ブランチ ノードはそれぞれ異なる要素で開始できます。あるブランチはルート ノードで終了し、別のブランチではパイプライン ペアが後続し、さらに別のブランチでは子孫を持たないようにすることができます (実行時に、子孫を持たないブランチを実行すると、応答処理がすぐに開始されます)。
ただし、一般には、メッセージ フローは次の形式のいずれかで設計します。
一般的なメッセージ フローでメッセージが処理されるしくみを表 3-2 に簡単に示します。
メッセージ フローでは、2 種類の分岐がサポートされています。オペレーション ブランチ ノードでコンフィグレーションされるオペレーション ブランチと、条件付きブランチ ノードでコンフィグレーションされる条件付きブランチです。
メッセージ フローで WSDL ベースのプロキシ サービスを定義する場合、操作固有の処理が必要となります。メッセージ フローにオペレーション ブランチ ノードを作成すると、WSDL で定義された操作に基づいて分岐ロジックを作成できます。
プロキシ サービスが複数の操作を含む WSDL に基づいている場合は、オペレーション ブランチを使用する必要があります。この場合、オペレーション ブランチ ノードを使用して、操作ごとにメッセージを個別に処理することを検討できます。
メッセージのドキュメント タイプなど、指定した条件に基づいて分岐する場合は、条件付きブランチを使用します。
条件付きブランチでは、ルックアップ テーブルに基づいて分岐が行われます。ルックアップ テーブルに含まれる各ブランチは、QuantityEqualToOrLessThan150 や QuantityMoreThan150 のような単純でユニークな文字列値でタグ付けされています。
(たとえば、メッセージ フロー内の前のステージで宣言された) メッセージ コンテキスト内の変数の値に基づいて分岐するように条件付きブランチをコンフィグレーションできます。また、ブランチ自体で定義された XPath 式の結果に基づいて分岐するように条件をコンフィグレーションすることもできます。
実行時に、変数または式が評価され、その結果値を使用してどのブランチに進むかが判断されます。値と一致するブランチがない場合は、デフォルト ブランチに進みます。ブランチ ノードでは、メッセージ フローに複数の子孫を持つことができます。ブランチごとにデフォルト ブランチが 1 つ含まれます。デフォルト ブランチを必ず定義する必要があります。ブランチ ノードに到達する前にルックアップ変数の値が設定されるように、プロキシ サービスを設計します。
たとえば、ルックアップ変数を使用する次のケースについて考えてみます。プロキシ サービスのタイプが任意の SOAP または任意の XML であり、条件付きブランチを実行できるようにメッセージのタイプを特定する必要があるとします。この場合、メッセージ タイプを特定するステージ アクションを設計した後に、メッセージ タイプに基づいて処理を分ける条件付きブランチ ノードをフロー内に設計できます。
今度は、条件付きブランチ ノードで XPath 式を使用するケースを考えてみます。注文の数量に基づいて分岐させるとします。この数量は、$body 内の既知の場所から取得できる変数によって渡されます。
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 Console または Workshop for WebLogic 用の Oracle Service Bus プラグインで使用できるアクションは、コンテキストによって決まります。
通信アクションは、メッセージ フローを制御します。各通信アクションを表 3-3 に示します。
フロー制御アクションは、条件付きルーティング、条件付きループ、およびエラー処理を実装します。また、フロー制御アクションを使用して、呼び出し元に成功を通知したり、ステージの残りのアクションをスキップしたりすることもできます。各フロー制御アクションを表 3-4 に示します。
このカテゴリのアクションは、メッセージ フローを処理します。各メッセージ処理アクションを表 3-5 に示します。
このカテゴリのアクションを使用して、ステージ内のメッセージ フローでの必要に応じて、エラーのログ記録またはレポート、およびアラートの生成を行います。各レポート アクションを表 3-4 に示します。
転送ヘッダ アクションは、通信タイプのアクションです。このアクションは、パイプライン ステージとエラー ハンドラ ステージで使用できます。
転送ヘッダ アクションをコンフィグレーションするときに、以下のオプションを使用できます。
これらのオプションは、自分のシナリオに最適な方法で使用します。どちらのオプションを使用しても、ソース ヘッダ セットのヘッダがターゲット ヘッダ セットにコピーされ、ターゲット セットの既存の値はすべて上書きされます。[パイプラインを介してすべてのヘッダを渡す] オプションは、ヘッダ固有の「ヘッダをコピー」オプションの前に実行されます。つまり、特定の転送ヘッダ アクションのコンフィグレーションで、[パイプラインを介してすべてのヘッダを渡す] を選択した場合、特定のヘッダに対して「ヘッダをコピー」オプションを選択する必要はありません。
ただし、[パイプラインを介してすべてのヘッダを渡す] を選択してすべてのヘッダをコピーし、その後に特定のヘッダに対して [ヘッダを削除] を選択して、個々のヘッダを削除するようにアクションをコンフィグレーションできます。
| 警告 : | 転送ヘッダは転送タイプに固有であるため、パススルー (またはコピー) オプションは、同じ転送タイプのサービス間でヘッダをコピーする場合にのみ使用することをお勧めします。転送タイプが異なるサービス間でヘッダを渡す (またはコピーする) と、渡されるヘッダが対象の転送で受け入れられない場合にエラーが発生することがあります。同じ理由で、「ヘッダを設定」オプションを使用してヘッダ名を指定するときにも注意が必要です。 |
前述のように、転送ヘッダ アクションを使用して、発信要求 (ルート、パブリッシュ、またはサービス コールアウトの各アクションでプロキシ サービスが送信するメッセージ) と着信応答 (プロキシ サービスがクライアントに返信する応答メッセージ) の転送ヘッダの値をコンフィグレーションできます。通常、ヘッダ値に対して以下の操作を実行できます。
転送ヘッダ アクションを使用すると、$inbound または $outbound のヘッダを設定、削除、またはパススルーできます。これらのヘッダを設定または削除した後に、$inbound または $outbound をログに書き込むと、変更の影響を確認できます。ただし、メッセージが送信されるときに Oracle Service Bus バインディング レイヤによって $inbound または $outbound の一部のヘッダが変更または削除され、そのため基礎になる転送でこれらのヘッダの一部が無視されて、その転送固有の値が使用されることがあります。重要な違いは、バインディング レイヤによるヘッダの変更は $inbound および $outbound に対して直接行われますが、転送による変更はメッセージのワイヤ形式だけに影響するという点です。たとえば、発信の Content-Length ヘッダの値を指定することはできますが、メッセージの送信時に、この値はバインディング レイヤによって $outbound から削除されます。したがって、この変更は応答パスで確認できます (たとえば、$outbound をログに記録すると、変更された値を確認できます)。$outbound に User-Agent ヘッダを設定した場合、HTTP 転送ではこの設定が無視され、転送独自の値が使用されます。ただし、$outbound の値が変更されることはありません。
実行時に無視または上書きされる転送ヘッダと、特定の転送ヘッダに関するその他の制限を表 3-7 に示します。
|
| 注意 : | 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 への各マッピングを記述できます。
メッセージ フロー内にトランスフォーメーションを指定する位置は、以下の条件によって異なります。
パブリッシュ アクションで、メッセージのターゲット サービスを判別し、メッセージのパッケージおよびサービスへの送信方法をコンフィグレーションします。Oracle Service Bus には、パブリッシュ テーブル アクションも用意されています。パブリッシュ テーブル アクションは、切り替え式条件テーブルにラップされた一連のルートで構成されます。これは、単一の XQuery 式の結果に基づいて各種ルートを選択できる短縮形の構文です。
トランスフォーメーションをパブリッシュ アクション内に設計した場合、トランスフォーメーションは $outbound 変数およびメッセージ関連の変数 ($header、$body、および $attachments) のローカル コピーを保持します。パブリッシュ アクションで発信メッセージに行った変更は、パブリッシュされるメッセージにのみ反映されます。つまり、パブリッシュ アクションで行った変更は、メッセージ フローがその次のアクションに進む前にロールバックされます。
たとえば、メッセージ フローで大口の発注書を処理するときに、管理者宛てに発注書の要約を電子メールで送信する必要がある場合について考えます。このような場合、要求パイプラインにパブリッシュ アクションを含めると、着信メッセージの SOAP 本体に発注書の要約が作成されます。パブリッシュ アクションでは、発注書データが発注書の要約に変換されます。たとえば、発注書の要約には添付ファイルは必要ないため、$attachments のすべての添付ファイルを削除できます。
WS-Addressing ヘッダに基づく 2 つの送り先の一方にメッセージをルーティングする必要があるとします。この場合、コンテンツ ベースのルーティングです。また、もう一方の送り先では、SOAP 本体のドキュメントの新しいバージョンが必要であるとします。このような場合、条件に基づいて 2 つの送り先の一方にルーティングされるように、ルート ノードをコンフィグレーションできます。2 つ目の送り先のためにドキュメントを変換するように、ルート ノードでトランスフォーメーションをコンフィグレーションします。
発信コンテキスト変数 ($outbound) の制御要素を設定して、発信メッセージに関するシステムの動作を調整できます (たとえば、サービスの品質を設定できます)。
inbound 変数と outbound 変数の下位要素、およびメッセージ コンテキストの変数の値を使用してメッセージのコンテンツが作成されるしくみについては、「inbound 変数と outbound 変数」および「送信するメッセージの作成」を参照してください。
Oracle Service Bus がサービス コールアウト アクションを通じてサービスを呼び出す場合は、メッセージ コンテキストの変数の値を使用してメッセージのコンテンツが作成されます。発信メッセージのメッセージ コンテンツは、ターゲット サービスの種類に応じて異なって処理されます。
以下のトピックで説明するように、メッセージ コンテンツの作成方法は、対象サービスのタイプ、および SOAP 本体とペイロード (パラメータまたはドキュメント) のどちらをコンフィグレーションするかによって異なります。
次のような SOAP ドキュメント スタイルのサービス (EJB ドキュメントおよびドキュメントにラップされたサービスを含む) のメッセージを作成できます。
SOAP ドキュメント スタイルのサービスへのコールアウト時にメッセージが作成されるしくみを説明するために、次のようにコンフィグレーションされたサービス コールアウト アクションについて考えてみます。
また、実行時に要求ドキュメント変数 myreq が次の XML にバインドされていることを前提とします。
<sayHello xmlns="http://www.openuri.org/">
<intVal>100</intVal>
<string>Hello Oracle</string>
</sayHello>
実行時に、SOAP 要求ヘッダ変数 reqheader は、次の SOAP ヘッダにバインドされます。
<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>
このシナリオ例では、外部サービスに送信されるメッセージの本文全体はコード リスト 3-3 のようになります (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 変数に割り当てられます。外部サービスからの応答全体は、コード リスト 3-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 変数にコード リスト 3-5 に示す値が割り当てられます。
<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 RPC スタイルのサービスへのコールアウト時にメッセージが作成されるしくみを説明するために、次のようにコンフィグレーションされた例について考えてみます。
このシナリオでは、サービスへの発信メッセージの本文はコード リスト 3-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>
呼び出しが行われたサービスから返される応答は、コード リスト 3-7 のようになります。
<?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 には、コード リスト 3-8 に示す値が割り当てられます。
<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 サービスへのコールアウト時にメッセージが作成されるしくみを説明するために、次のようにコンフィグレーションされたサービス コールアウト アクションを例にとります。
また、実行時に要求ドキュメント変数 myreq が次の XML にバインドされることを前提とします。
<sayHello xmlns="http://www.openuri.org/">
<intVal>100</intVal>
<string>Hello Oracle</string>
</sayHello>
myreq 変数の値です。myresp に割り当てられた値は、コード リスト 3-10 のようになります。<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>
たとえば、要求メッセージのコンテキスト変数 myreq が <hello>there</hello> という形式の XML ドキュメントにバインドされる場合、発信メッセージには厳密にこのペイロードが格納されます。応答メッセージのコンテキスト変数 (myresp) は、次のような参照要素にバインドされます。
<binary-content ref=" cid:1850733759955566502-2ca29e5c.1079b180f61.-7fd8"/>
エラー処理は、メッセージ フロー、パイプライン、ルート ノード、およびステージ レベルでコンフィグレーションできます。サービス コールアウトの結果として外部サービスから受け取るエラーのタイプには、転送エラー、SOAP エラー、予期される応答に一致しない応答などがあります。
fault コンテキスト変数の設定は、返されるエラーのタイプごとに異なります。fault 変数のコンテンツに基づいて、ビジネス ロジックとエラー処理ロジックを構築できます。$fault の詳細については、「fault 変数」を参照してください。
外部サービスから転送エラーを受け取り、転送プロバイダから Oracle Service Bus にエラー応答ペイロードが返されない場合 (たとえば、HTTP 403 のエラー コードが返された場合)、サービス コールアウト アクションは例外をスローします。これにより、パイプラインでエラーが発生します。ユーザがコンフィグレーションしたエラー ハンドラの fault 変数は、コード リスト 3-11 に示すメッセージと同様にフォーマットされたメッセージにバインドされます。
<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 の場合、ErrorResponseDetail 要素には応答と共に返される HTTP エラー コードも含まれます。fault 内の ErrorResponseDetail 要素には、サービスから受信したエラー応答ペイロードが含まれます。ErrorResponseDetail 要素の例をコード リスト 3-12 に示します。
<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 スキーマについては、「サービス コールアウトで生成されるエラーの詳細の XML スキーマ」を参照してください。 |
外部サービスが SOAP エラーを返した場合、Oracle Service Bus ランタイムは、カスタム エラー コードとエラーの詳細を示す説明を含むコンテキスト変数 $fault を設定します。そのために、SOAP エラーの <SOAP-ENV:Fault> 要素の下にある 3 つの要素のコンテンツが抽出され、Oracle Service Bus の fault 要素の作成に使用されます。
<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> 要素にラップされます。コード リスト 3-15 の faultcode 要素には QName が含まれ、関連するすべてのネームスペース宣言が保持されます。転送が HTTP の場合、ReceivedFault 要素にはエラー応答と共に返される HTTP エラー コードも含まれます。
生成される <alsb:ReceivedFault> 要素、およびカスタム エラー コードとエラー文字列は、fault コンテキスト変数のコンテンツの作成に使用されます。この例では、コード リスト 3-14 と同様の形式になります。
<ctx:Fault xmlns:ctx="http://www.bea.com/wli/sb/context">hat’s an Error!
<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>T</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 エラー コードも含まれます。
サービス コールアウトで生成されるエラーの詳細の XML スキーマ定義をコード リスト 3-15 に示します。
<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>
次のパラグラフで説明するプロセスでは、エラー ハンドラ ステージのエラー処理パイプラインを構成します。また、エラー パイプラインは、パイプライン (要求または応答) またはプロキシ サービス全体に対して定義することができます。
ステージ レベルのエラー ハンドラがエラー処理に呼び出されます。ステージ レベルのエラー ハンドラが特定タイプのエラーを処理できない場合、パイプライン エラー ハンドラが呼び出されます。パイプライン レベルのエラー ハンドラもエラーを処理できない場合は、サービス レベルのエラー ハンドラが呼び出されます。サービス レベルのエラー ハンドラも処理できない場合、システムがエラーを処理します。メッセージ フローのさまざまなレベルにおけるエラー ハンドラのスコープの概要を次の表に示します。
| 注意 : | エラー ハンドラのスコープには例外があります。たとえば、ステージ レベルの非 XML トランスフォーメーションによって送出される例外を捕捉するのは、サービス レベルのエラー ハンドラのみです。プロキシ サービスの送信応答メッセージ用に XML から MFL に変換する場合、このトランスフォーメーションは常にバインディング レイヤで発生します。したがって、たとえば、非 XML 出力でステージ レベルの必須フィールドが欠落している場合、サービス レベルのエラー ハンドラだけがこのエラーを捕捉できます。 |
エラー メッセージとエラー処理の詳細については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : エラー ハンドラ」を参照してください。
アサーションが true であるかどうかを確認するテストをコンフィグレーションすることでエラーを処理できます。また、失敗にコンフィグレーションされている応答アクションを使用できます。このテストはさまざまなレベルで繰り返すことができます。下位レベルでエラー ハンドラのない状態でエラーが発生した場合、メッセージ フローの上位レベルのエラー ハンドラによって処理することもできます。
通常、メッセージ フローのステージ レベルで特定のエラーを処理し、下位レベルでは処理されないエラーのより一般的なデフォルト処理に上位レベルのエラー ハンドラを使用する方が簡単です。予期されるエラーをパイプラインで明示的に処理し、予期されないエラーをサービスレベルのハンドラで処理することをお勧めします。
| 注意 : | サービス レベルで処理できるのは、WS-Security 関連のエラーのみです。 |
メッセージ処理中に発生したエラーに関する情報はすべて、事前定義されたコンテキスト変数 (fault 変数) に保持されます。エラーが発生すると、この変数に情報が格納されてから、適切なエラー ハンドラが呼び出されます。この fault 変数はエラー ハンドラ パイプラインでのみ定義され、要求パイプラインや応答パイプライン、ルート ノードやブランチ ノードでは設定されません。$fault の詳細については、「事前定義されたコンテキスト変数」を参照してください。
要求/応答型の着信メッセージでのエラー発生時には、多くの場合、エラーが発生した理由を説明するメッセージを送信元に返送する必要があります。そのためには、送信する応答に対してメッセージ コンテキスト変数をコンフィグレーションした後、失敗時の返信アクションを使用します。たとえば、HTTP メッセージが失敗した場合は、失敗時の返信アクションで HTTP 500 ステータスが生成されます。JMS メッセージが失敗した場合は、失敗時の返信アクションで JMS_BEA_Error プロパティが true に設定されます。Oracle Service Bus のエラー アクションについては、『Oracle Service Bus Console の使い方』の「プロキシ サービス : エラー ハンドラ」を参照してください。
プロキシ サービスが呼び出したサービスが SOAP エラーまたは転送エラーを返すと、エラー処理パイプラインが呼び出されます。受信した SOAP エラーはすべて $body に格納されるため、$body を変更せずに失敗時の返信アクションを実行すると、サービスの呼び出し元のクライアントには元の SOAP エラーが返されます。返信アクションがコンフィグレーションされていない場合、システム エラー ハンドラによって新しい SOAP エラー メッセージが生成されます。プロキシ サービスでは、HTTP エラー ステータスが設定されたか、JMS プロパティ SERVER_Error が true に設定されているために SOAP エラーが返されたと認識されます。
用途によっては、エラー レポートが必要な場合があります。このような場合は、レポート アクションを使用します。たとえば、要求パイプラインで追跡用にメッセージをレポートするレポート アクションを実行した後、ルート ノードによって呼び出されたサービスが失敗するというシナリオを想定します。このような場合、メッセージはレポート システムによってログに記録されますが、メッセージが正常に処理されたという保証はありません。メッセージが正常に受信されたことを示すだけです。
Oracle Service Bus Console では、メッセージを追跡することによって、メッセージ フローの正確な流れを把握することができます。これにより、メッセージが処理のために送信されたことをレポートする元のメッセージだけでなく、メッセージが正常に処理されなかったことをレポートする以降のエラーも確認できます。レポート アクションをコンフィグレーションし、実行時にレポートされるデータを使用する方法については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
この例では、エラー ハンドラにレポート アクションと返信アクションをコンフィグレーションする方法を示します。図 3-2 に示すメッセージ フローには、validate loan application ステージのエラー ハンドラが含まれています。この例のエラー ハンドラは、1 つのステージがコンフィグレーションされた単純なメッセージ フローです。Oracle Service Bus Console には、図 3-2 のように表示されます。
図 3-3 に示すように、このステージはアクション (置換、レポート、および返信) でコンフィグレーションされています。
アクションによって、パイプライン エラー ハンドラのステージの動作が次のように制御されます。
fault コンテキスト変数のコンテンツで置換されます。body 変数の要素は XPath 式で指定します。コンテンツは、XQuery 式で返される値で置換されます。この例では $fault/ctx:reason/text() です。
エラーが発生すると、fault コンテキスト変数のコンテンツがレポートされます。キー名は errorCode です。キー値は ./ctx:errorCode という XPath 式を使用して fault 変数から抽出されます。キーと値のペアをキー識別子として使用して、実行時にダッシュボードでこれらのメッセージを識別します。
レポート アクションをコンフィグレーションし、実行時にレポートされるデータを使用するには、『Oracle Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
コンフィグレーション情報については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : エラー ハンドラ」を参照してください。
作成するプロキシ サービスから呼び出す必要があるサービスがわからない場合に、動的ルーティングを使用できます。
どのプロキシ サービスでも、以下のいずれかの方法を使用して、メッセージを動的にルーティングできます。
| 注意 : | 動的ルーティングはルート ノードで使用でき、動的パブリッシュは要求パイプラインまたは応答パイプラインのステージで使用できます。 |
この方法を使用すると、プロキシ サービスでは、エンドポイント ビジネス サービスのサービス アカウントを動的に使用して、ユーザ名とパスワードをその発信要求に送信します。たとえば、プロキシ サービスがビジネス サービス A に要求をルーティングする場合、プロキシ サービスではビジネス サービス A のサービス アカウントを使用して、ユーザ名とパスワードをその発信要求に送信します。「動的ルーティングの実装」を参照してください。
この方法を使用すると、要求の送信先の URI に関係なく、ユーザ名とパスワードをその発信要求に送信するために、プロキシ サービスは静的に定義されたビジネス サービスのサービス アカウントを使用します。
この方法の使用方法については、「動的ルーティングの実装」を参照してください。
| 注意 : | この方法は、インタフェースの概要が確定している場合に使用します。インタフェースの概要には、メッセージのタイプ、ポート タイプ、およびバインディングが含まれます。具象インタフェースは含まれません。具象インタフェースは、サービスが配置されている転送 URL です。 |
動的ルーティングを使用すると、プロキシ サービスの実行時に送り先を確定できます。これを行うには、XML ファイルのルーティング テーブルを使用して、XQuery リソースを作成します。
| 注意 : | XQuery リソースを使用する代わりに、リソースの作成元の XML ファイルを直接使用することもできます。 |
XML ファイルまたは XQuery リソースは容易に保持できます。実行時に、プロキシ サービスのルーティング先またはパブリッシュ先を決定するルーティング テーブルにエントリを指定します。XML ファイルまたは XQuery リソースには、論理的な識別子 (企業名など) を物理的な識別子 (Oracle Service Bus のサービスの完全修飾名) にマップするルーティング テーブルが含まれています。メッセージから抽出された論理的な識別子は、呼び出すサービスの名前である物理的な識別子にマップされます。
| 注意 : | 動的ルート アクションを使用するには、Oracle Service Bus のサービスの完全修飾名が必要です。 |
パイプラインでは、論理的な修飾子は XPath を使用してメッセージに取得されます。XQuery リソースの XML テーブルを変数に割り当てます。ルーティング テーブルの変数にクエリを実装し、対応する論理的な修飾子に基づいて物理的な修飾子を抽出します。この変数を使用すると、必要なサービスを呼び出すことができます。以下の節では、動的ルーティングの実装方法を説明します。
以下の XML ファイルから XQuery リソースを作成できます。sampleXquery.xml としてこれを保存します。
<routing>
<row>
<logical>Oracle</logical>
<physical>default/goldservice</physical>
</row>
<row>
<logical>ABC Corp</logical>
<physical>default/silverservice</physical>
</row>
</routing>
これにより、XQuery リソースがこの変数に割り当てられます。これで、この変数に外部化したルーティング テーブルが格納されました。
| 注意 : | これを行うには、手順 11 から手順 13 を繰り返します。 |
<ctx: route>
<ctx: service isProxy=’false’> {$routingtable/row[logical/text()=$logicalidentifier]/physical/text()}
</ctx: service>
</ctx: route>
上記のコードで、$logicalidentifier を実際の XPath で置換して、メッセージ ($body など) から論理的な識別子を抽出します。
これにより、動的ルート アクションで使用する XML がこの変数に抽出されます。
Oracle Service Bus では、カスタムの EJB コードや Java コードを記述したり、Oraclce Data Service Integrator などの別のデータベース製品を使用せずに、プロキシ サービスからデータベースに対して読み込みアクセスを行うことができます。execute-sql() 関数を使用して、データベースに対して簡単な JDBC 呼び出しを行い、単純なデータベースの読み込みを実行できます。指定した地域の税率を取得する単純なクエリや、複雑な結合を使用して、基になる複数のデータベース テーブルから注文の現在の状態を取得するクエリなど、任意の SQL クエリが有効です。
データベース クエリを使用してデータを取得し、メッセージに情報を追加したり、ルーティング先を選択したり、プロキシ サービスの動作をカスタマイズすることができます。Oracle Service Bus プロキシ サービスが「見積依頼」メッセージを受信する場合のシナリオを例として示します。プロキシ サービスは、顧客の優先度に基づいて、見積りを提供する複数のビジネス サービス (たとえば標準、ゴールド、プラチナ レベルのサービス) のいずれかに要求をルーティングできます。その後で、プロキシ サービスは、それらのサービスが返す結果を SQL ベースで補強します。たとえば、選択した出荷方法と注文品の重量に基づいて送料を検索し、そのコストを見積依頼メッセージに追加することができます。
関数の構文とその使用例については、「fn-bea:execute-sql()」を参照してください。execute-sql() 関数は型付きデータを返し、SQL/JDBC データ モデルと XQuery データ モデル間で値を自動的に変換します。
返された要素を、Oracle Service Bus メッセージ フローのユーザ定義の変数に格納できます。
execute-sql() 関数でサポートされるデータベースおよび JDBC ドライバは以下のとおりです。
fn-bea:execute-sql() 関数で使用するデータソースには、非 XA ドライバを使用してください。この関数は、データソースへの読み込み専用アクセスをサポートしています。
| 警告 : | データベースへの接続に非 XA JDBC ドライバ クラスを指定する以外に、グローバル トランザクションと 2 フェーズ コミットを無効にしている必要があります (WebLogic Server Console で JDBC データ ソースを使用する場合、デフォルトではグローバル トランザクションが有効になっています)。データ ソースへのこれらの指定は、WebLogic Server Administration Console で行うことができます。『WebLogic Server Administration Console オンライン ヘルプ』の「JDBC データ ソースの作成」を参照してください。 |
Oracle Service Bus でのデータベースと JDBC ドライバのサポートについては、Oracle Service Bus 10g R3 でサポート対象のコンフィグレーションの「サポート対象のデータベース コンフィグレーション」を参照してください。
前のコード リストに示したコア セット以外のデータベースもサポートされています。ただし、上記のコア データベースでは、非コア データベースの場合よりも、XQuery エンジンが適切にデータ型を認識し、XQuery タイプにマップします。データを取得する際に、コア データベースの独自の JDBC 拡張が使用される場合もあります。非コア データベースでは、XQuery エンジンは、JDBC ドライバが提供する標準タイプのコード、および標準の JDBC ResultSet のアクセス メソッドに完全に依存します。
プロキシ サービスを設計する際に、XQuery をリソースとして入力するのではなく、アクション定義の一部としてインラインで入力することができます。メッセージ フローで If...Then... アクションの条件にインライン XQuery を使用することもできます。インライン XQuery エディタの使用については、「変数の構造のマッピングの作成」を参照してください。
メッセージ コンテキストは、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 で事前定義されているコンテキスト変数は、以下のように分類されます。
事前定義されたコンテキスト変数の詳細については、「事前定義されたコンテキスト変数」を参照してください。
$body には、メッセージのペイロード変数が含まれます。Oracle Service Bus からメッセージをディスパッチするときに、送信メッセージに含める変数を決定できます。この決定は、対象のエンドポイントが SOAP メッセージを受信するか非 SOAP メッセージを受信するかによって異なります。
$body の Body 要素に任意のテキストまたは XML メッセージ コンテンツが格納されて送信される。$body の Body 要素に MFL ドキュメントと同等の XML が格納される。 $body の Body 要素にテキストが格納される。テキスト添付では、$attachments の Body 要素にテキストが格納される。コンテンツがシンプル テキストではなく XML の場合、XML はテキスト メッセージとして送信されます。$body の Body 要素に XML が格納される。XML 添付では、$attachments の Body 要素に XML が格納されます。<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 ファイル (ORACLE_HOME/osb_10.3/lib/sb-schemas.jar) に用意された MessageContext.xsd と、次の場所にある転送固有のスキーマを参照する必要があります。
ORACLE_HOME/osb_10.3/lib/transports/
ここで、ORACLE_HOME は Oracle Service Bus をインストールしたディレクトリを表す。
メッセージ コンテキスト スキーマおよび転送固有スキーマの詳細については、「メッセージ コンテキスト スキーマ」を参照してください。
メッセージ コンテキストを検査または変更するときには、以下のガイドラインを考慮してください。
Content-Description を取得します。 $attachments/ctx:attachment[1]/ctx:content-Description
$attachments/ctx:attachment[2]/ctx:body/*
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 要素がそれぞれ含まれる場合があります。$body) にビジネス ドキュメントを渡すことができます。
トランスフォーメーションの結果は、置換アクションによって $body に戻すことができます。つまり、$body のコンテンツ (Body 要素のコンテンツ) を置換します。詳細については、『Oracle Service Bus Console の使い方』の「XQuery トランスフォーメーション」および「XSL トランスフォーメーション」を参照してください。
$inbound から $outbound に一連の転送ヘッダをコピーすることができます。アクションを追加する方法については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : アクション」にある「アクションの追加」を参照してください。使用例については、「inbound から outbound への JMS プロパティのコピー」を参照してください。
AquaLogic 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
転送ヘッダ アクションをコンフィグレーションする方法については、以下を参照してください。
Oracle Service Bus では、Oracle XQuery Mapper などの外部ツールで作成された XQuery をインポートできます。これらの XQuery は、プロキシ サービスのメッセージ フローのどの場所でも使用できます。XQuery を使用するには、XQuery リソースの入力をインライン XQuery にバインドし、XQuery リソースの出力をアクションにバインドします。このアクションは、出力の結果を入力として使用する割り当て、置換、挿入などのアクションです。
ただし、XQuery をリソースとして入力するのではなく、アクションの定義の一部としてインラインで入力することができます。If...Then... アクションの条件にインライン XQuery を使用することもできます。
インライン XQuery 式エディタは、以下で構成される簡単な XQuery を入力するときに使用します。
| 注意 : | より複雑な XQuery については、XQuery に慣れていない場合は特に、XQuery Mapper を使用することをお勧めします。 |
インライン XQueries は、次のような場合に使用すると効率的です。
$header または $body に含まれる SOAP エンベロープの要素からビジネス ドキュメントまたは RPC パラメータを抽出する、またはアクセスする。$attachments に含まれる添付ドキュメントを抽出する、またはアクセスする。 for loop を実行するために SOAP エンベロープからシーケンスを抽出する。 for loop 内のシーケンスの項目を更新する。| 注意 : | インライン XQuery 式エディタを使用して、変数の構造を作成することもできます。詳細については、「変数の構造の使用」を参照してください。 |
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 のドキュメントとパラメータには直接アクセスできます。
変数の構造の作成方法の詳細については、「変数の構造のマッピングの作成」を参照してください。
XQuery エンジンのサポート、および Oracle Data Service Integrator 関数と演算子の関係の詳細については、「XQuery の実装」を参照してください。
通常、インライン XQuery 式エディタは、以下で構成される簡単な XQuery を入力するときに使用します。
| 注意 : | 複雑な XQuery には、ドラッグ アンド ドロップ機能を備えた Oracle XQuery Mapper を使用することをお勧めします。『XQuery Mapper を使用したデータの変換』の「XQuery Mapper を使用したデータの変換」を参照してください。 |
インライン XQuery 式エディタを使用して、変数の構造を作成することもできます。詳細については、「変数の構造の使用」を参照してください。
インライン 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 をリソースとしてコンフィグレーションに保存してください。詳細については、「例で必要なリソースの作成」を参照してください。
<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 Console でタスクを実行します。
SampleWSDL」と入力します。このフィールドは必須です。| 注意 : | このフィールドは必須です。 |
SampleWSDL がリソースのリストに追加され、現在のセッションで保存されます。次に、この WSDL を使用するプロキシ サービスを作成する必要があります。「サンプル WSDL を使用するプロキシ サービスの作成」を参照してください。ProxywithSampleWSDL」と入力します。このフィールドは必須です。ProxywithSampleWSDL がリソースのリストに追加され、現在のセッションで保存されます。このプロキシ サービスのメッセージ フローを構築するには、「サンプル プロキシ サービスのメッセージ フローの構築」を参照してください。ProxywithSampleWSDL プロキシ サービスの [メッセージ フローの編集] アイコンをクリックします。 ProxywithSampleWSDL] アイコンをクリックし、[パイプライン ペアの追加] をクリックします。PipelinePairNode1 が表示されます。ここには、要求パイプラインと応答パイプラインが含まれています。ProxywithSampleWSDL プロキシ サービスの基本的なメッセージ フローが作成されました。 BusinesswithSampleWSDL」と入力します。このフィールドは必須です。BusinesswithSampleWSDL がリソースのリストに追加され、現在のセッションで保存されます。
この例では、プロキシ サービス ProxyWithSampleWSDL を使用して事前定義された変数の構造を選択します。このサービスのタイプは、SampleWSDL のバインディング POBinding を使用する WSDL Web サービスです。
プロキシ サービスのメッセージ フローが、処理するメッセージの構造を認識している必要があります。このために、Oracle Service Bus では事前定義された構造が自動的に提供されます。この構造は、インタフェースのすべてのメッセージで、プロキシ サービスの WSDL での定義に従って、body 変数を SOAP 本体の構造にマップします。この事前定義された構造のマッピングのラベルは body です。
| 注意 : | この事前定義された構造は、型付きインタフェースを備えたメッセージング サービスのためにもサポートされています。 |
[XQuery 式エディタ] ページの [変数の構造] パネルで、組み込み構造のドロップダウン リストから [body] を選択します。
変数の構造 body は、図 3-4 のように表示されます。
プロキシ サービス ProxyWithSampleWSDL が、ビジネス サービス BusinessWithSampleWSDL へのサービス コールアウトを呼び出すとします。このビジネス サービスも、サービスのタイプは SampleWSDL のバインディング POBinding を使用する WSDL Web サービスです。操作 GetInvoiceType が呼び出されます。
この例では、メッセージ フローが、処理する応答パラメータの構造を認識する必要があります。このためには、応答パラメータ変数を型 InvoiceType にマップする新しい変数の構造を作成します。
InvoiceType」と入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。$InvoiceType」と入力します。
変数の構造 InvoiceType は、図 3-6 のように表示されます。
一時変数には、SampleWSDL WSDL で記述された要素 Invoice が含まれているとします。この例では、ProxyWithSampleWSDL メッセージ フローは、この変数にアクセスする必要があります。このためには、変数を要素 Invoice にマップする新しい変数の構造を作成します。
Invoice」と入力します。$Invoice」と入力します。
変数の構造 Invoice は、図 3-7 のように表示されます。
プロキシ サービス ProxyWithSampleWSDL は、ドキュメント スタイルが任意の SOAP であるビジネス サービスにルーティングします。このビジネス サービスは、SOAP 本体の発注書を返します。この例では、ProxyWithSampleWSDL プロキシ サービスのメッセージ フローが、その応答を処理する必要があります。このためには、body 変数を PO 要素にマップする新しい構造を作成し、PO 要素を変数の子要素として指定します。body 変数には SOAP Body 要素が格納され、PO 要素は Body 要素の子であるため、子要素として指定する必要があります。
body to PO$body」と入力します。PO 要素を選択するには、次の手順に従います。 PO 要素を body to PO 変数の構造の子として設定するために、[子として設定] チェックボックスを選択します。
変数の構造 body to PO は、図 3-8 のように表示されます。
プロキシ サービス ProxyWithSampleWSDL は、ビジネス サービス BusinessWithSampleWSDL にメッセージをルーティングします。このビジネス サービスも、サービスのタイプは SampleWSDL のバインディング POBinding を使用する WSDL Web サービスです。この例では、メッセージ フローが応答を処理する必要があります。このためには、body 変数を BusinessWithSampleWSDL ビジネス サービスにマップする新しい構造を定義します。これにより、サービスの WSDL インタフェースで、すべてのメッセージの SOAP 本体に body 変数がマップされます。
| 注意 : | このマッピングは、型付きインタフェースを備えたメッセージング サービスのためにもサポートされています。 |
BusinessService」と入力します。$body] が設定されています。これは、実行時の変数の構造のパスになります。BusinessService が変数の構造のドロップダウン リストの [サービス インタフェース] の下に追加されます。
変数の構造 BusinessService は、図 3-9 のように表示されます。
ProxyWithSampleWSDL プロキシ サービスが単一の添付ファイルを受信するように、SampleWSDL を変更します。添付ファイルは発注書です。この例では、プロキシ サービスのメッセージ フローが発注書を処理する必要があります。このためには、$attachments の body 要素を、子要素として指定されている PO 要素にマップする新しい構造を定義します。body 要素は、以下の形式の変数パスとして指定されます。
$attachments/ctx:attachment/ctx:body
事前定義された attachments 構造の body 要素を選択してコピーし、新しいマッピング定義でマップされる変数パスとして貼り付けます。
変数の構造 attachments は、図 3-10 のように表示されます。
body 子要素を選択します。ページの右側にある [プロパティ インスペクタ] に body 要素の変数パスが表示されます。 $attachments/ctx:attachment/ctx:bodybody 要素の変数パスをコピーします。PO attachment」と入力します。$attachments/ctx:attachment/ctx:bodyPO 要素を選択するには、次の手順に従います。 PO attachment が変数の構造のドロップダウン リストの [XML の種類] の下に追加されます。
$attachments/ctx:attachment/ctx:body/oracle:PO/oracle:id
以下の節では、Oracle Service Bus メッセージングのサービス品質機能について説明します。
Oracle Service Bus は、信頼性の高いメッセージ機能を備えています。メッセージがルート ノードから別のサービスにルーティングされるときに、デフォルトのサービスの品質 (QoS) は、プロキシ サービスの転送が JMS/XA として定義されている場合は「必ず 1 回」になり、それ以外の場合は「ベスト エフォート」QoS がサポートされます。
サービスの品質は、$outbound コンテキスト変数の qualityOfService 要素で設定されます。
Oracle Service Bus に用意されている配信の保証のタイプを表 3-9 に示します。
他の転送のサービスの品質の詳細については、「Oracle Service Bus の転送」にある転送に関するドキュメントを参照してください。
デフォルトの「必ず 1 回」サービスの品質属性をオーバーライドするには、発信メッセージのコンテキスト変数 ($outbound) で qualityOfService を設定する必要があります。詳細については、「メッセージ コンテキスト スキーマ」を参照してください。
次のアクションのデフォルトの qualityOfService 要素属性をオーバーライドできます。
qualityOfService 要素属性をオーバーライドするには、ルート オプション アクションを使用してルーティングまたはパブリッシュし、サービス コールアウト アクションのチェックボックスも選択する必要があります。「メッセージ コンテキスト スキーマ」を参照してください。
プロキシ サービスがメッセージをパブリッシュするか、要求をビジネス サービスにルーティングするときは、次の条件に応じて配信の保証がサポートされます。
ただし、着信プロキシ サービスがローカル転送で、呼び出し元が別のプロキシ サービスである場合、呼び出し元のプロキシ サービスの着信転送が配信の保証を行います。呼び出されたプロキシ サービスの転送がローカル転送の場合、呼び出し元のプロキシ サービスが最適化されて、直接呼び出しになるためです。転送プロトコルの詳細については、『Oracle Service Bus Console の使い方』の「プロキシ サービス」および「ビジネス サービス」を参照してください。
| 注意 : | プロキシ サービスからの応答には配信の保証はありません。 |
配信の保証に適用されるルールを表 3-10 に示します。
| 注意 : | JMS により配信の保証として「少なくとも 1 回」および「必ず 1 回」をサポートするには、JMS トランザクションを利用し、サーバがクラッシュした場合、または返信アクションや再開アクションのエラー ハンドラで処理できないエラーが発生した場合にメッセージを再配信できるように、JMS キューの再試行回数と再試行間隔をコンフィグレーションする必要があります。ファイル、FTP、および電子メール転送でも、内部では JMS/XA キューが使用されます。JMS/XA 転送を使用したプロキシ サービスのデフォルトの再試行回数は 1 です。Oracle Service Bus で作成されるデフォルトの JMS キューのリストについては、『Oracle Service Bus デプロイメント ガイド』を参照してください。 |
qualityOfService 要素が exactly-once に設定されている場合、トランザクション対応の送り先への要求フローで実行されるルート ノード アクションとパブリッシュ アクションは、同じトランザクションで実行される。qualityOfService 要素が best-effort に設定されている場合、サービス コールアウト アクションまたはパブリッシュ アクションは、要求フロー トランザクションの外部で実行される。具体的には、JMS、Tuxedo、トランザクション対応の Tuxedo、または EJB の各転送で、要求フロー トランザクションが中断されます。トランザクション対応の Tuxedo の処理はトランザクションなしで実行されるか、すぐにコミットされる別のトランザクションで実行されます。qualityOfService 要素が exactly-once に設定されている場合、すべてのルート アクション、サービス コールアウト アクション、およびパブリッシュ アクションは同じトランザクションで実行される。 qualityOfService 要素が best-effort に設定されている場合、すべてのパブリッシュ アクションとサービス コールアウト アクションは、応答フロー トランザクションの外部で実行される。特に、JMS、EJB、または転送のタイプがトランザクション対応の Tuxedo の場合、応答フロー トランザクションはサスペンドされ、サービス呼び出しの処理はトランザクションなしで、またはすぐにコミットされる別のトランザクションで実行されます。qualityOfService 要素の設定に関係なく、常に同じトランザクションで実行される。| 注意 : | 着信転送がトランザクション対応の Tuxedo で、発信が JMS/XA などの非同期転送の場合、実行時エラーが発生します。 |
Oracle Service Bus のスレッディング モデルは次のように作動します。
| 注意 : | 要求フローまたは応答フローのパブリッシュ アクションでは、応答は常に破棄されます。これは、パブリッシュ アクションは本質的に一方向のメッセージ送信であるためです。 |
loanGateway1) が別のプロキシ サービス (たとえば loanGateway2) を呼び出すときに、JMS 以外の転送について直接呼出しの最適化を無効にするには、プロキシ サービス loanGateway1 からプロキシ サービス loanGateway2 にルーティングします (プロキシ サービス loanGateway2 が JMS 転送を使用する場合)。qualityOfService 要素に exactly-once を指定し、XA 接続ファクトリを使用します。
JMS を使用してメッセージの着信の再試行をコンフィグレーションするだけでなく、発信の再試行およびロード バランシングもコンフィグレーションできます。ロード バランシング、フェイルオーバ、および再試行の組み合わせによって、パフォーマンスと高可用性を実現できます。各メッセージのフェイルオーバ URL として指定した URL のリストは、ロード バランシング アルゴリズムに基づいて自動的に並べ替えられ、フェイルオーバのシーケンスが形成されます。再試行回数が N の場合、シーケンス全体が N 回再試行されてから終了します。システムは指定された再試行間隔の時間だけ待機してから、シーケンスの次のループを開始します。再試行回数が完了してもまだエラーがある場合、ルート ノードのエラー処理パイプラインが呼び出されます。エラー ハンドラ パイプラインの詳細については、『Oracle Service Bus Console の使い方』の「プロキシ サービス」にある「パイプラインへのエラー処理の追加」を参照してください。
| 注意 : | HTTP 転送の場合、Oracle Service Bus では 200 または 202 以外の HTTP ステータスはエラーと見なされるため、再試行する必要があります。このアルゴリズムにより、Oracle Service Bus では、解決することのできない認証エラーなどのエラーを、その URL で一定期間再試行することが可能です。これに対して、Oracle Service Bus で任意のメッセージの送信を再試行するときに別の URL にフェイルオーバする場合は、新しい URL ではエラーにならない可能性があります。 |
| 注意 : | quality of serviceが exactly once の場合、フェイルオーバや再試行は行われません。 |
Oracle Service Bus では、異種のエンドポイント間での相互運用性を確保するため、コンテンツ タイプ、JMS タイプ、およびエンコーディングをそれぞれ制御できます。
Oracle Service Bus では外部のクライアントまたはサービスに必要な情報が想定されませんが、サービス定義でコンフィグレーション済みの情報が使用されます。発信メッセージのコンテンツ タイプは、サービス タイプとインタフェースから派生します。コンテンツ タイプは、電子メールおよび HTTP プロトコルの一部です。
また、JMS タイプにはバイトまたはテキストを指定できます。Oracle Service Bus Console または Workshop for WebLogic 用の Oracle Service Bus プラグインでサービスを定義するときに、使用する JMS タイプをコンフィグレーションします。
サービスを呼び出すプロキシ サービスの発信コンテキスト変数 ($outbound) のコンテンツ タイプ、およびプロキシ サービス応答の着信コンテキスト変数 ($inbound) のコンテンツ タイプはオーバーライドできます。$outbound コンテキスト変数と $inbound コンテキスト変数の詳細については、「inbound 変数と outbound 変数」を参照してください。
すべての発信メッセージのエンコーディングも、サービス定義で明示的にコンフィグレーションします。サービス定義の詳細については、『Oracle Service Bus Console の使い方』の「プロキシ サービス」および「ビジネス サービス」を参照してください。
Oracle Service Bus では、メッセージ フローをビジネス サービスに制限できます。このビジネス サービスへのメッセージ フローを制限する技術は、スロットルと呼ばれます。詳細については、『Oracle Service Bus オペレーション ガイド』の「Oracle Service Bus のスロットル」を参照してください。
Oracle Service Bus は、実行時環境で SOAP 1.1 サービスへの Web サービス相互運用性 (WS-I) 準拠を提供します。WS-I の基本プロファイルの目的を以下に示します。
WS-I 基本プロファイルは、次の URL で入手できます。
http://www.ws-i.org/Profiles/BasicProfile-1.1.html (英文)
プロキシ サービスまたはビジネス サービスを WSDL に基づいてコンフィグレーションするとき、Oracle Service Bus Console または Workshop for WebLogic 用の Oracle Service Bus プラグインを使用すると、Oracle Service Bus で WS-I 準拠をそれらのサービスに適用するかどうかを指定できます。この方法については、以下を参照してください。
プロキシ サービスの WS-I 準拠をコンフィグレーションすると、そのプロキシ サービスが受信する着信要求メッセージでチェックが実行されます。呼び出されたサービスについて WS-I 準拠をコンフィグレーションすると、その呼び出されたサービスからの応答メッセージを任意のプロキシが受信したときに、チェックが実行されます。デフォルトでは、プロキシ サービスの SOAP クライアントはシステム エラー ハンドラ定義のエラーを受け取るため、このようなエラーに対応するエラー ハンドラを作成することをお勧めします。エラー ハンドラの作成方法の詳細については、以下を参照してください。
プロキシ サービスから送信されるメッセージについては、それが発信要求でも着信応答でも、WS-I 準拠のチェックは明示的には実行されません。これは、ほとんどのメッセージ コンテンツの生成はパイプライン設計者によって行われるためです。ただし、メッセージの Oracle Service Bus によって生成される部分は、サポートされる WS-I 準拠のすべてのチェックを満たします。以下のコンテンツが含まれます。
[WS-I 準拠の適用] チェックボックスは、図 3-11 のように表示されます。
![[WS-I 準拠の適用] チェックボックス](wwimages/wsi_compliance.gif)
| 注意 : | WS-I 準拠チェックでは、サービスで呼び出される操作をシステムが認識する必要があります。つまり、プロキシ サービスが受信する要求メッセージでは、コンテキスト変数 $operation は null 以外の値であることが必要です。そのためには、操作選択アルゴリズムが適切にコンフィグレーションされていることが前提になります。呼び出されたサービスから受信する応答メッセージでは、ルート、パブリッシュ、およびサービス コールアウトのアクション コンフィグレーションで操作が指定されている必要があります。 |
プロキシ サービスまたはビジネス サービスの WS-I 準拠チェックをコンフィグレーションすると、表 3-11 に示すチェックが実行されます。
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 の変換を適切に使用するには、以下のガイダンスを使用してください。
MustUnderstand など) をマップするパイプライン アクションに依存します。また、暗号化されたエンベロープの SOAP の暗号化されたネームスペースの変更も、パイプライン アクションに依存します。
|