|
|
この章では、Oracle Service Bus メッセージ コンテキスト モデルとメッセージ フローで使用する事前定義されたコンテキスト変数について説明します。内容は以下のとおりです。
メッセージ コンテキストは、Oracle Service Bus でメッセージがルーティングされるときに、メッセージ コンテキストとメッセージに関する情報を保持する一連のプロパティです。これらのプロパティは、コンテキスト変数と呼ばれます。たとえば、サービス エンドポイントは、事前定義されたコンテキスト変数によって表されます。Oracle Service Bus は、ユーザ定義のコンテキスト変数もサポートします。
メッセージ コンテキストは、XML スキーマによって定義されます。通常は、XQuery 式を使用して、プロキシ サービスを定義するメッセージ フローのコンテキスト変数を操作します。
事前定義されたコンテキスト変数を表 5-1 に示します。事前定義されたコンテキスト変数の型は、メッセージ関連の変数、inbound および outbound 変数、operation 変数、fault 変数に分けられます。
メッセージ コンテキスト変数の要素の型については、「メッセージ コンテキスト スキーマ」を参照してください。
|
||
|
メッセージ関連の変数である header、body、および attachments は、Oracle Service Bus のメッセージ フローでのメッセージの標準書式を表します。これらの変数は、プロキシ サービスが受信したメッセージ コンテンツを使用して初期化され、他のサービスにルーティングまたはパブリッシュされる送信メッセージを作成するために使用されます。
メッセージの処理の一部としてメッセージを変更するには、これらの変数を変更する必要があります。
メッセージ ペイロード (つまり、ヘッダや添付を除くメッセージ コンテンツ) は、body 変数に格納されます。送信メッセージに含める変数のコンテンツは Oracle Service Bus からメッセージがディスパッチ (パブリッシュまたはルーティング) される時点で決定されます
この決定は、対象のエンドポイントが SOAP メッセージを受信するか非 SOAP メッセージを受信するかによって異なります。
header 変数には、メッセージに関連付けられている SOAP ヘッダが格納されます。header 変数は、下位要素にヘッダを含む <SOAP:Header> 要素を参照します。(プロキシ サービスが SOAP 1.2 の場合、header 変数には SOAP 1.2 Header 要素が格納されます)。非 SOAP メッセージまたはヘッダがない SOAP メッセージの場合、<SOAP:Header> 要素は空になり、下位要素を持ちません。
body 変数はコアのメッセージ ペイロードを表し、常に <SOAP:Body> 要素を参照します。(プロキシ サービスが SOAP 1.2 の場合、body には SOAP 1.2 Body 要素が格納されます)。SOAP メッセージでも非 SOAP メッセージでも、コアのペイロードは同じ変数とパッケージで使用できます。つまり、<SOAP:Body> 要素でラップされます。
body 変数に割り当てられる。 <SOAP:Body> 要素内にメッセージ コンテンツ全体が挿入される。body 変数に挿入されるのではなく、<binary-content/> 参照要素が作成され、<SOAP:Body> 要素に挿入される。バイナリ コンテンツの処理方法については、「body 変数と attachments 変数内のバイナリ コンテンツ」を参照してください。<java-content/> 参照要素が作成され、<SOAP:Body> 要素に挿入される。Java コンテンツの処理方法については、「body 変数内の Java コンテンツ」を参照してください。
attachments 変数には、メッセージに関連付けられた添付が格納されます。attachments 変数は、XML スキーマで定義されます。これは、単一のルート ノードである <ctx:attachments> と、各添付の <ctx:attachment> 下位要素で構成されます。この下位要素には、添付に関する情報 (MIME ヘッダから派生) と添付コンテンツが含まれます。他のメッセージ関連の変数と同様に、attachments は常に設定されます。ただし、添付がない場合は、attachments 変数は空の <ctx:attachments> 要素で構成されます。
各添付要素には、表 5-2 に示す一連の下位要素が含まれます。
|
型なしの body 要素以外のすべての要素には MIME での解釈と同じ方法で解釈された文字列値が含まれます。たとえば、Content-Type 要素の有効な値は、text/xml と text/xml; charset=utf-8 などです。
添付の解析は再帰的ではありません。添付の Content-Type が multipart/... の場合、body 要素には元の MIME コンテンツがパッケージ化されずにバイトのストリームとして保持され、添付の下位要素は含まれません。MIME ストリームにはバイナリ データが含まれることがあり、その場合このストリームは <binary-content> 参照要素で表します。
バイナリ コンテンツの処理方法については、「body 変数と attachments 変数内のバイナリ コンテンツ」を参照してください。
Content-Type が multipart/form-data であるメッセージは、実行時に以下のように作成されます。
multipart/form-data タイプのメッセージのすべての部分が $attachments 変数に割り当てられる。$body 変数は空のままになります。multipart/form-data タイプのメッセージのコンテンツが $attachments 変数のコンテンツから作成される。$header または $body は含まれません。| 注意 : | 着信メッセージが multipart/form-data 以外の multipart タイプ (multipart/related など) で、発信メッセージが multipart/form-data の場合、着信ルート パートのヘッダとコンテンツを明示的に保持する必要があります。そうしないと、パススルーされません。 |
HTTP、HTTPS、または電子メール転送の場合のみ、添付ファイルが着信要求および発信応答 (つまりプロキシ サービスが受信するメッセージ内) でサポートされます。添付ファイルは、発信要求および着信応答 (つまりプロキシ サービスが送信するメッセージ) に関するすべての転送タイプでサポートされます。
Oracle Service Bus では、EJB、Tuxedo、または DSP ベースのサービスへの添付ファイルの送信はサポートしていません。
body 変数と attachments 変数では、テキスト ベース、XML ベース、および MFL ベースのコンテンツが XML 要素内に直接挿入されます。バイナリ データの場合、XML で使用できないバイト値が含まれることがあるため、Oracle Service Bus ではバイナリ コンテンツは XML 要素内に挿入されません。したがって、バイナリ コンテンツは操作できませんが効率的に処理されます。
バイナリ コンテンツが受信されると、Oracle Service Bus ランタイムによってバイナリ コンテンツがメモリ内ハッシュ テーブルに格納され、そのコンテンツへの参照が XML (body または attachments) 要素に挿入されます。この参照は、以下の XML コードで表されます。
この ref 属性に、バイナリ コンテンツをユニークに識別する URI または URN を指定します。この XML は、Oracle Service Bus パイプライン、ブランチ、またはルート ノードで他のコンテンツと同様に操作できます。ただし、影響を受けるのは、元のバイナリ コンテンツではなく参照だけです。
メッセージが Oracle Service Bus から送信されると、参照 XML の URI を使用して、関連バイナリ コンテンツが送信メッセージ内に復元されます。発信メッセージの作成方法については、「送信するメッセージの作成」を参照してください。
クライアントと特定の転送 (特に、電子メール、ファイル、FTP) では、この同じ参照 XML を使用して参照渡しを実装できます。この場合、実行時のプロキシ サービスではなく転送またはクライアントによって、参照 XML が作成されます。また、ref 属性内の URI の値は、参照 XML を作成するユーザによって指定されます。参照 XML が実行時のプロキシ サービスによって作成されない場合 (特に、URI の参照先が、内部で管理されているバイナリ コンテンツであると認識されない場合)、URI は Oracle Service Bus により逆参照されず、送信メッセージにコンテンツが挿入されません。
Oracle Service Bus パイプラインでは、Java コールアウト アクションへの入力および出力として、Java オブジェクトをサポートしています。Java コールアウトから返された POJO はパイプラインにキャッシュされ、そのキーは <java-content ref="cid:kkkkeeeeyyyy"/> の形式の XML メッセージにラップされて返されます。ここで、cid:kkkkeeeeyyyy は、生成アクションによって自動的に生成されたキーであり、パイプラインのキャッシュにあるオブジェクトのインデックスを指定するために使用されます。後続するすべてのアクションに対して、この XML が変更されずに引数として渡されます。
コンフィグレーション時には POJO 変数のコンテンツは、パイプライン アクションからは直接アクセスできません。代わりに、コンテンツは以下の方法で操作できます。
$pojo/java-content/@ref のような XQuery) と同様に処理できます。これはロギングやデバッグに役立つことがありますが、オブジェクトのコンテンツに直接アクセスすることはできません。<java-content.../> がソース変数からターゲット変数にコピーされます。$pojo) として渡すことができます。オブジェクト自体にアクセスすることはできません。引数は、実際のオブジェクトに自動的に逆参照されます。
(<java-content.../> 内に) Java オブジェクトのキーを保持しているすべての変数を削除した場合、または <java-content.../> スニペットを指しているすべての XPath を削除した場合、Java オブジェクトはパイプラインのキャッシュから削除されます。
メッセージ コンテンツを処理する際に、Oracle Service Bus パイプラインによってコンテンツをメモリにロードするのではなく、コンテンツをストリームするように指定できます。プロキシ サービスのコンテンツ ストリーミングを有効にするときは、メッセージ処理時の中間手順として、ストリーミングされたコンテンツをメモリとディスク ファイルのどちらにバッファリングするかを指定します。これらの一時ファイルの作成は、パフォーマンスに影響を及ぼすことがあります。一時ファイルの保護については、『Oracle Service Bus のセキュリティ ガイド』を参照してください。
ストリーミング オプションを有効にした場合、コンテンツ ストリーミングは body 変数だけに適用されます。
一般に、コンテンツ ストリーミングを使用するのは次のような場合です。
body メッセージ コンテキスト変数について、挿入、置換、名前変更、for each、検証、および削除の各アクションを使用することはできません。これらのアクションでは、入力変数をメモリ内で完全に実体化する必要がありますが、完全な実体化はコンテンツ ストリーミング オプションと互換性がないためです。$body の XQuery トランスフォーメーションまたは XSL トランスフォーメーションの結果を使用できます。$body 以外) の値を更新する場合。ただし、式の結果が完全に実体化でき、メッセージ コンテキストに格納できる小さなサイズであることを確認する必要があります。$body を使用する場合は、メッセージング サービスをバイナリ メッセージ タイプのプロキシ サービスとして宣言します。メッセージング サービスをテキスト メッセージ タイプのプロキシ サービスとして宣言すると、トランスフォーメーションの入力ストリームを取得するために $body が完全に実体化されます。$body の XQuery トランスフォーメーションまたは XSL トランスフォーメーションの結果を報告する場合。
たとえば、入力ストリーム全体を使用する $body/*:DateTimeStruct を記述するのはなく、次のように記述します。
($body/*:DateTimeStruct)[1] または $body[1]/*:DateTimeStruct[1]
インデックスを使用することにより、1 つ目の DateTimeStruct 要素までのコンテンツだけが解析されます。
let $labdata1 := $body/*
return <HEADER>{ $labdata1/HEADER/@*, $labdata1/HEADER/node() }</HEADER>
この場合、$labdata1 はルート要素なしにドキュメント全体にバインドされるため、XQuery エンジンがこれを実体化しようとするとメモリ不足になります。
このクエリを変更して必要以上に実体化されないようにする 1 つの方法として、/HEADER パス式を let 句内に移動します。
let $labdata1 := $body/*/HEADER
...
この場合、XQuery エンジンは HEADER 要素だけを実体化します。
実体化を回避するもう 1 つの方法として、ストリーミング モードで要素の名前を変更できる fn-bea:rename() 関数を使用する方法があります。
fn-bea:rename($oldelements as element()*, $newname as element()) as element()*
fn-bea:rename($body/*/HEADER, <HEADER_NEW/>)
メッセージの添付ファイルを処理する際に、添付ファイルをメモリにバッファリングして XML として解析するのではなく、MIME 添付ファイルをディスクにページングしてからコンテンツをストリーミングするように指定できます。サイズの大きい添付ファイルを扱う場合は、この方法が特に効果的です。
この方法を使用すると、ヘッダのみがバッファリングされ、残りのメッセージ ペイロードは、小さい複数の部分を同時に読み込むことができるストリームとしてエクスポーズされます。ストリーミングされた転送により、サイズの大きいメモリ バッファが不要になるため、サービスのスケーラビリティが向上します。
Oracle Service Bus では、以下の転送を使用するプロキシ サービスおよびビジネス サービスについて、MIME 添付ファイルのストリーミングがサポートされます。
注意 : Oracle Service Bus は、電子メール、SB、または WS 転送の添付ファイルのストリーミングをサポートしません。
HTTP プロキシ サービスに対して有効になっている場合、設定は着信要求メッセージの処理に適用されます。HTTP ビジネス サービスの場合、設定は発信要求メッセージの処理に適用されます。発信要求メッセージをディスパッチすることができる以下のアクションは、添付ファイルのストリーミングをサポートします。
ストリーミングが有効になっている場合、バイナリ、テキスト、または XML のすべての添付ファイルは不透明なデータとして処理されます。つまり、添付ファイルのストリーミングが有効になっている場合、添付ファイルの XML コンテンツに基づいた XQuery/XPath 式を実行することはできません。
Oracle Service Bus が着信メッセージを受信したとき、添付ファイルのストリーミングがコンフィグレーションされている場合は、各 MIME 添付ファイルのコンテンツはディスク上の別々のファイルに保存されます。
各添付ファイルの標準 MIME ヘッダ (これには、Content-ID、Content-Type、Content-Transfer-Encoding、Content-Description、Content-Location、および Content-Disposition (指定されている場合) が含まれます) を attachment 要素の下に追加するように、$attachments 変数の値が設定されます。
body 子要素には、ソース リポジトリ内の対応するソースを参照する単一の binary-content 子要素が含まれます。
たとえば、$attachments 変数は次のようになります。
<con:attachments xmlns:con="http://www.oracle.com/wli/sb/context">
<con:attachment>
<con:Content-Type>image/jpeg</con:Content-Type>
<con:Content-ID>
<1.urn:uuid:BFB7D745CBAF21BA5B12023554608963@apache.org>
</con:Content-ID>
<con:Content-Transfer-Encoding>
binary
</con:Content-Transfer-Encoding>
<con:body>
<con:binary-content ref="cid:23976580:1183dd6aab9:-7fe0"/>
</con:body>
</con:attachment>
</con:attachments>
これは添付ファイルのコンテンツ タイプに関係なく実行されます。つまり、たとえば text/xml 添付ファイルは、image/jpeg 添付ファイルと同じように、バイナリ コンテンツ要素を含む不透明なバイナリ データとして扱われます。
このスタイルのメッセージ処理は、添付ファイルがストリーミングされない場合とは異なります。添付ファイルがストリーミングされない場合は、text/xml や text/plain などの特定のファイル タイプが認識されて、添付ファイルの XML body 要素 (XML コンテンツを格納するため) またはテキスト コンテンツの初期化に使用されます。
Oracle Service Bus が発信メッセージを処理するとき、添付ファイルをストリーミングするようにコンフィグレーションされている場合は、各 MIME 添付ファイルのコンテンツはディスク上の別々のファイルに保存されます。Oracle Service Bus は、着信要求の場合と同様に $attachments メッセージ コンテキスト変数を初期化します (「着信メッセージの処理」を参照してください)。
Oracle Service Bus では、MTOM/XOP 形式の着信メッセージをデコードして解析し、必要に応じて MTOM/XOP 形式を使用して応答を送信するように、プロキシ サービスをコンフィグレーションできます。また、発信メッセージを MTOM/XOP 形式でエンコードするようにビジネス サービスをコンフィグレーションできます。
Oracle Service Bus は、着信 MTOM/XOP ペイロードを受け入れてデコードするために、次のバインディング タイプを持つプロキシ サービスをサポートしています。
MTOM/XOP ペイロードを受信するその他のサービス バインディング タイプのプロキシ サービスは、MIME マルチパート要求と同じようにペイロードを処理し、MTOM 固有の処理は行いません。
また、次の Oracle Service Bus 転送は MTOM/XOP をサポートします。
Oracle Service Bus は、次の発信メッセージをディスパッチできるすべての既存アクションをサポートします。
ただし、MTOM および SOAP with Attachments (SwA) を組み合わせること、およびメッセージレベルのセキュリティで MTOM を使用することはできません。また、メイン ペイロードをストリーミングしながら MTOM を使用することはできません。
プロキシ サービスで MTOM/XOP 形式の着信メッセージをデコードして解析し、必要に応じて MTOM/XOP 形式を使用して応答を送信することができます。[XOP/MTOM サポート] が有効になっている場合は、$header および $body メッセージ コンテキスト変数のバイナリ データを処理する方法を次のオプションからさらに選択します。
バイナリ データに直接アクセスする必要がある場合 (Java コールアウトまたはメッセージ フォーマット言語 (MFL) 変換にデータを渡す場合など) は、[参照によるバイナリ データを含む] オプションを使用できます。
[値によるバイナリ データを含む] は次の場合に使用できます。
[XOP/MTOM サポート] がプロキシ サービスに対して有効になっている場合は、すべての着信メッセージが MTOM 形式である必要はありません。代わりに、この設定では、MTOM 形式のメッセージが到着したときに、プロキシ サービスでそれを適宜処理する必要があることを指定します。[XOP/MTOM サポート] が有効になっていないプロキシ サービスが MTOM 形式のメッセージを受信した場合、サービスはメッセージを拒否し、ランタイム エラーを発行することにも注意してください。
参照によるバイナリ オプションが選択されている場合は、Oracle Service Bus はメッセージのルートを解析して xop:Include タグの存在をチェックします。これらのタグが検出された場合、タグはバイナリ リポジトリ内の対応するソースへの参照を含む ctx:binary-content 要素に変換されます。結果としてのドキュメントは $body メッセージ コンテキスト変数によって表されます。対照的に、$attachments メッセージ コンテキスト変数は情報を含みません (null です)。
つまり、パイプライン アクションが $body メッセージ コンテキスト変数のコンテンツにアクセスした場合、アクションは xop:Include 要素を検出しない代わりに、ctx:binary-content 要素を使用して動作します。
プロキシ サービスがクライアントに応答を返信する必要がある場合、バインディング レイヤは ctx:binary-content 参照をメッセージのルートにある xop:Include タグに置換し、対応する各バイナリ コンテンツ参照に別々の MIME 部分を追加して、MTOM/XOP パッケージ応答を作成します。
値によるバイナリ オプションが選択されている場合は、Oracle Service Bus が着信 MIME メッセージのルートを解析して xop:Include タグの有無をチェックします。該当するタグが検出された場合、対応する MIME 部分の本体 (バイナリ データ) は Base64 でエンコードされ、結果としてのテキストが $body メッセージ コンテキスト変数の xop:Include タグを置換します。
対照的に、$attachments メッセージ コンテキスト変数は情報を含みません (null です)。
ビジネス サービスを有効にすると、発信メッセージを MTOM/XOP 形式でエンコードできます。[XOP/MTOM サポート] が有効になっている場合は、$header および $body メッセージ コンテキスト変数のバイナリ データを処理する方法を次のオプションからさらに選択します。
[XOP/MTOM サポート] がビジネス サービスに対して有効になっている場合は、すべての発信メッセージが MTOM 形式である必要はありません。代わりに、この設定はビジネス サービスが MTOM ペイロードを処理できることを指定します。
MTOM/XOP サポートが有効になっている場合、Oracle Service Bus は $body メッセージ コンテキスト変数のコンテンツを調べて ctx:binary-content 要素を検索します。要素がある場合、Oracle Service Bus は ctx:binary-content を xop:Include 要素およびペイロードの対応する MIME 部分に置換して、MTOM/XOP MIME パッケージを作成します。
MTOM/XOP が有効で本体にバイナリ コンテンツが含まれている場合、コンテンツのサイズに関係なく (たとえば、1KB より小さい場合でも) Oracle Service Bus は常に MTOM/XOP を使用します。
また、Oracle Service Bus は MTOM と SwA の組み合わせをサポートしません。そのため、ビジネス サービスへの発信要求をディスパッチする必要があり、次の条件に該当する場合、システムは実行時例外を送出します。
inbound コンテキスト変数と outbound コンテキスト変数には、着信エンドポイントと発信エンドポイントに関する情報が格納されます。inbound 変数には要求メッセージを受信したプロキシ サービスに関する情報が格納され、outbound 変数 にはメッセージの送信先である対象ビジネス サービスに関する情報が格納されます。
outbound 変数は、ルート ノードのルート アクションとパブリッシュ アクションで設定されます。$outbound を変更するには、ルート ノードで要求アクションと応答アクションをコンフィグレーションし、パブリッシュ アクションで要求アクションをコンフィグレーションします。
| 警告 : | inbound コンテキスト変数と outbound コンテキスト変数に対して行った変更の一部は、実行時には無視されます。つまり、特定のヘッダとメタデータの値は、Oracle Service Bus ランタイムで上書きされる場合や無視される場合があります。この制限は、転送ヘッダとサービス コールアウト アクションを使用して転送ヘッダとメタデータを設定する場合、およびテスト コンソールを使用してプロキシ サービスまたはビジネス サービスをテストする場合にも適用されます。制限のあるヘッダおよびメタデータについては、「ランタイムによって転送ヘッダの設定が使用されるしくみについて」を参照してください。メッセージ フローで、ルート ノードの要求アクションまたは応答アクションおよびパブリッシュ アクション以外で $outbound に加えた変更は無視されます。つまり、これらの変更は、ルート ノードとパブリッシュ アクションで $outbound が初期化されるときに上書きされます。 |
サービス コールアウト アクションで outbound 変数を変更することはできません。
inbound 変数と outbound 変数の特性は以下のとおりです。
inbound コンテキスト変数と outbound コンテキスト変数は、「メッセージ コンテキスト スキーマ」で説明されているように endpoint 要素のインスタンスです。name 属性を含む。name 属性は、inbound、outbound いずれの場合も読み込み専用として扱う必要があります。| 警告 : | この読み込み専用ルールは強制されません。読み込み専用の要素を変更すると予期できない動作が生じることがあります。 |
service、transport、security を含む。
HTTP、HTTPS、または電子メール転送の場合のみ、添付ファイルが着信要求および発信応答 (つまりプロキシ サービスが受信するメッセージ内) でサポートされます。
添付ファイルは、発信要求および着信応答 (つまりプロキシ サービスが送信するメッセージ) に関するすべての転送タイプでサポートされます。
Oracle Service Bus では、EJB、Tuxedo、または DSP ベースのサービスへの添付ファイルの送信はサポートしていません。
この節では、コンテキスト変数 inbound および outbound の下位要素について説明します。また、どの下位要素が実行時に初期化されるかについての情報も示します。コンテキスト変数が初期化される方法については、「コンテキスト変数の初期化」を参照してください。以下の下位要素があります。
service 要素は、inbound、outbound いずれの場合も読み込み専用です。下位要素としては providerName、operation があります。
|
|
transport 要素は inbound の場合は読み込み専用です。ただし例外として、response 要素ではこの要素を変更して応答転送ヘッダを設定できます。transport 要素の下位要素を表 5-4 に示します。
|
|
|||
RequestMetaData XML)。したがって、この要素の構造は使用される転送によって異なる。
|
|||
ResponseMetaData XML)。したがって、この要素の構造は使用される転送によって異なる。
|
|||
|
|||
|
security 要素の下位要素を表 5-5 に示します。
|
|||
|
|||
|
|
|
『Oracle Service Bus Console の使い方』の「プロキシ サービス : アクション」
『Oracle Service Bus Console の使い方』の「プロキシ サービス : メッセージ フロー」にある「ルート ノード アクションの追加」
標準 HTTP ヘッダの説明については、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html を参照。
標準 JMS ヘッダについては、
http://edocs.bea.com/wls/docs_92/jms/fund.html#jms_features を参照してください。
operation 変数は、読み込み専用の変数です。この変数には、プロキシ サービスで呼び出される操作を指定する文字列が格納されます。プロキシ サービスに対する処理が定義されていない場合は、operation 変数が設定されず、null と等価の値が返されます。
Oracle Service Bus では、パフォーマンスを最適化するために operation 変数が inbound 変数の下位要素ではなくスタンドアロン変数として提供されます。処理の計算は、inbound 変数がアクセスされたときではなく、operation 変数が明示的にアクセスされるまで延期されることがあります。
fault 変数は、メッセージ処理中に発生したすべてのエラーに関する情報を保持するために使用します。エラーが発生すると、この変数に情報が格納されてから、適切なエラー ハンドラが呼び出されます。
| 注意 : | この変数はエラー ハンドラ パイプラインでのみ定義され、要求パイプラインや応答パイプライン、ルート ノードやブランチ ノードでは設定されません。 |
fault 変数には、表 5-6 に示す errorCode、reason、details、および location の各下位要素が含まれます。
|
fault 変数のコンテンツは、SOAP ベースのプロキシ サービスからの返信時にエラーを生成しやすいよう、SOAP エラーに基づいてモデル化されています。Oracle Service Bus によって生成されるエラー コードの値はシステム エラー コードに対応し、エラー コードの先頭には BEA という文字列が付加されます。
エラーに関連付けられたエラー コードは、fault コンテキスト変数の要素内に表示されます。次の XQuery ステートメントを使用して値にアクセスできます。
Oracle Service Bus では、考えられる 3 つのクラスのエラーに対応する 3 つの汎用エラー コードが定義されています。汎用コードの形式は BEA-xxx000 です。ここで、xxx は汎用カテゴリを次のように表します。
Oracle Service Bus では、特定のエラーを示すユニークなコードが定義されています。次に例を示します。
BEA-382030 - メッセージ解析エラーを示します (SOAP プロキシ サービスが非 SOAP メッセージを受信したなど)。
BEA-382500 - サービス コールアウト アクションが SOAP エラー応答を受信した場合に備えて予約されています。
これらのエラー コードおよびその他の特定のエラー コードについては、『Oracle Service Bus Console の使い方』の「エラー コード」を参照してください。また、「メッセージ フローでのエラー処理」も参照してください。
メッセージ コンテキストとその変数は、メッセージ受信時およびメッセージ処理の開始前にバインディング レイヤで初期化されます。コンテキスト変数を初期化する方法を表 5-7 に示します。
$outbound を変更できる。詳細については、「inbound 変数と outbound 変数」を参照。
|
|
attachments コンテキスト変数は、メッセージに含まれるすべての MIME 添付ファイルで初期化されますが、メイン メッセージを表す部分は含まれません (SOAP、XML、MFL など形式を問わず)。各 <attachment> 要素は、MIME パッケージの各部分に伴う MIME ヘッダを使用して初期化されます。
<attachment> の <body> 要素のコンテンツは、添付の Content-Type に応じて以下のいずれかになります。
この節では、コンテキスト変数 header および body の初期化が行われる方法について説明します。これらの変数の初期化方法は、プロキシ サービスのタイプが SOAP サービス、XML サービス (非 SOAP)、メッセージング サービスのいずれであるかによって異なります。
SOAP ベースのサービスへのメッセージは、<soap:Envelope> 要素に含まれる XML を含む SOAP メッセージです。添付を含むメッセージの場合、着信メッセージのコンテンツは、SOAP エンベロープをその一部として (通常は最初の部分、または最上位の Content-Type ヘッダで指定される部分) 含む MIME パッケージです。コンテキスト変数は以下のように初期化されます。
XML ベースのサービスへのメッセージは XML ですが、プロキシ サービス コンフィグレーションで許可された型を使用できます。添付を含むメッセージの場合、着信メッセージのコンテンツは、プライマリ XML ペイロードをその一部として (通常は最初の部分、または最上位の Content-Type ヘッダで指定される部分) 含む MIME パッケージです。
メッセージング サービスは、あるデータ型のメッセージを受信し、応答として別のデータ型のメッセージを返すことができるサービスです。サポートされるデータ型は、XML、MFL、テキスト、または型なしバイナリです。コンテキスト変数は以下のように初期化されます。
header - 空の <soap:Header/> 要素で初期化されます。body - ペイロード全体をラップする <soap:Body> 要素で初期化されます。 <soap:Body> 要素内に直接挿入される。 <soap:Body> 要素内に挿入される (「body 変数と attachments 変数内のバイナリ コンテンツ」を参照)。バイナリ コンテンツに対してアクセスまたは変更を行うことはできませんが、参照 XML を検証および変更し、インライン コンテンツと置き換えることができます。
メッセージ コンテキストに対する対話および操作は、プロキシ サービスを定義するパイプライン、ブランチ、またはルート ノードでのアクションを通じて行います。ほとんどのアクションについては、それを実行するための XQuery 言語がエクスポーズされています。各コンテキスト変数は、同じ名前の XQuery 変数として表されます。たとえば、header 変数は、XQuery では $header としてアクセスでき、body 変数は $body としてアクセスできます。この節の例では、XQuery を使用してコンテキスト変数に対するチェックおよび操作を行っています。
$body 変数は <soap-env:Body>...</soap-env:Body> 要素を含みます。(プロキシ サービスが SOAP 1.2 の場合、body 変数には SOAP 1.2 Body 要素が格納されます)。
たとえば、割り当てアクションを使用して body コンテキスト変数にデータを割り当てた場合、<soap-env:Body> 要素でデータをラップする必要があります。つまり、コンテキスト変数内に <soap-env:Body> 要素を含めることによって SOAP パッケージを構築します。
Oracle Service Bus のこの動作には例外があります。サービス コールアウト アクションの要求ドキュメント変数を作成する場合です。この場合、サービス コールアウト アクションはコアのペイロード (RPC パラメータ、ドキュメントなど) を処理の対象とし、Oracle Service Bus はコアのペイロードに基づいて SOAP パッケージを構築します。つまり、サービス コールアウト アクションの要求ドキュメント変数をコンフィグレーションするときには、入力ドキュメントを <soap-env:Body>...</soap-env:Body> でラップしません。
サービス コールアウト アクションのコンフィグレーションの詳細については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
$header 変数は <soap-env:Header>...</soap-env:Header> 要素を含みます。(プロキシ サービスが SOAP 1.2 の場合、header 変数には SOAP 1.2 Header 要素が格納されます)。
たとえば、 割り当てアクションを使用して header コンテキスト変数にデータを割り当てた場合、<soap-env:Header> 要素でデータをラップする必要があります。つまり、コンテキスト変数内に <soap-env:Header> 要素を含めることによって SOAP パッケージを構築します。これは、サービス コールアウト要求の 1 つまたは複数の SOAP ヘッダを設定できる場合を含め、$header のすべての操作に該当します。サービス コールアウト アクションの SOAP ヘッダのコンフィグレーションの詳細については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
SOAP サービスへのサービス コールアウト内の要求パラメータに使用する body 入力変数を作成する場合、soap-env:Body ラッパを削除するために、body/* を使用してその変数のコンテンツを定義します ($body を使用すると、soap-env:Body ラッパが保持されます)。
XQuery エディタおよび XPath エディタを使用したコンテキスト変数の処理の詳細については、以下を参照してください。
Oracle Service Bus によってメッセージがパブリッシュまたはルーティングされるときに、メッセージ コンテキストの変数の値を使用してメッセージのコンテンツが作成されます。たとえば、転送ヘッダと転送固有のメタデータは、$outbound/transport/request から取得されます。コンテキストの初期化と同様に、発信メッセージのメッセージ コンテンツはターゲット サービスのタイプに応じて異なって処理されます。以下のトピックで説明されているように、発信メッセージ コンテンツの作成方法はターゲット サービスのタイプによって異なります。
送信 SOAP メッセージは、header 変数と body 変数のコンテンツを <soap:Envelope> 要素でラップして作成します。呼び出されたサービスが SOAP 1.2 サービスの場合、作成されるエンベロープは SOAP 1.2 エンベロープです。呼び出されたサービスが SOAP 1.1 サービスの場合、作成されるエンベロープは SOAP 1.1 エンベロープです。body 変数に参照 XML コードが格納されている場合、メッセージは現状のまま送信されます。つまり、参照されているコンテンツはメッセージに追加されません。
attachments 変数で添付が定義されている場合は、メイン メッセージと添付データから MIME パッケージが作成されます。各添付部分のコンテンツの処理方法は、メッセージング サービスのコンテンツの処理方法に類似しています。
Oracle Service Bus の XML ベースのサービスへのメッセージは、body 変数のコンテンツから作成されます。
body 変数が空の場合は、サイズがゼロのメッセージが送信される。 body 変数に複数の XML コードが含まれる場合は、最初のコードのみが発信メッセージで使用される。たとえば、<soap:Body> に <abc/><xyz/> が含まれる場合は、<abc/> のみが送信されます。 body 変数のコンテンツが XML ではなくテキストである場合は、エラーが発生する。 body 変数に参照 XML コードが格納されている場合、メッセージは現状のまま送信されます。つまり、参照されているコンテンツはメッセージに追加されません。 attachments 変数で添付が定義されている場合は、XML メッセージと添付データから MIME パッケージが作成される。XML メッセージが null の場合は、対応する MIME 本文部分は空になります。各添付部分のコンテンツの処理方法は、メッセージング サービスのコンテンツの処理方法に類似しています。
含まれているデータのタイプに関わらず、header 変数は発信メッセージにコンテンツを提供しません。
サービス コールアウト アクションのメッセージの作成方法を示す例については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
Oracle Service Bus のメッセージング サービスへのメッセージは、body 変数のコンテンツから作成されます。
body 変数が空の場合、サイズがゼロのメッセージが送信される。 
MFL 変換が実行できない場合はエラーが発生する)。body 変数のコンテンツがテキストとして解釈され送信される。このため、Oracle Service Bus では、対象サービスにテキストとして配信する必要がある着信 XML メッセージを処理できます。つまり、このようなメッセージを処理するためにメッセージ フローをコンフィグレーションする必要はありません。body 変数に参照 XML コードを格納する必要がある。参照 URI は、Oracle Service Bus のメモリ内ハッシュ テーブルに格納されたバイナリ データを参照します。参照先コンテンツは対象サービスに送信されます。
クライアント、転送、またはプロキシ サービスの設計者によって参照 URI が指定される場合、参照されるデータは Oracle Service Bus に格納されないため、発信メッセージに含めることはできません。したがって、参照 XML がメッセージで送信されます。
body 変数に参照 XML コードが含まれ、対象サービスでバイナリ以外のメッセージが要求される場合は、body 変数内の参照 XML はコンテンツとして処理されます。つまり、メッセージは XML として送信されるか、テキストに変換されるか、または MFL に変換されます。これは、参照 XML の URI に関係なく当てはまります。
含まれているデータのタイプに関わらず、header 変数は発信メッセージにコンテンツを提供しません。
サービス コールアウト アクションのメッセージの作成方法を示す例については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
バイナリ メッセージの場合、Oracle Service Bus では body 変数にメッセージ コンテンツは挿入されません。代わりに、<binary-content/> 参照要素が作成され <SOAP:Body> 要素に挿入されます (「メッセージ関連の変数」を参照)。ただし、電子メール規格では、バイナリ コンテンツ タイプをメッセージの主要な部分として送信することがサポートされていません。テキストまたは XML のドキュメントと任意の添付を受信するメッセージング サービスに、電子メールでバイナリ メッセージを送信する場合は、以下の手順に従います。
送信メッセージのタイプが MFL の場合は、$body のコンテンツが、MFL トランスフォーメーションに基づいて XML からテキストまたはバイナリに変換されます。
バイナリ コンテンツの処理方法の詳細については、「body 変数と attachments 変数内のバイナリ コンテンツ」を参照してください。
メッセージ コンテキスト変数の型を指定するメッセージ コンテキスト スキーマ (MessageContext.xsd) は、「Message Context.xsd」で示されます。
メッセージ コンテキスト変数を操作する場合、JAR ファイル (ORACLE_HOME/osb_10.3/lib/sb-schemas.jar) に用意された MessageContext.xsd と、次の場所にある転送固有のスキーマを参照する必要があります。
ORACLE_HOME/osb_10.3/lib/transports/
ここで、ORACLE_HOME は Oracle Service Bus をインストールしたディレクトリを表す。
<schema targetNamespace="http://www.bea.com/wli/sb/context"
xmlns:mc="http://www.bea.com/wli/sb/context"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!--============================================================== -->
<!-- コンテキスト変数 'fault' はこの要素のインスタンスです -->
<element name="fault" type="mc:FaultType"/>
<!-- コンテキスト変数 'inbound' と 'outbound' は、この要素のインスタンスです -->
<element name="endpoint" type="mc:EndpointType"/>
<!-- 'inbound' 変数と 'outbound' 変数内の 3 つの下位要素 -->
<element name="service" type="mc:ServiceType"/>
<element name="transport" type="mc:TransportType"/>
<element name="security" type="mc:SecurityType"/>
<!-- コンテキスト変数 'attachments' はこの要素のインスタンスです -->
<element name="attachments" type="mc:AttachmentsType"/>
<!-- 'attachments' 変数の各添付は、この要素のインスタンスによって表されます -->
<element name="attachment" type="mc:AttachmentType"/>
<!-- バイナリ ペイロードと参照渡しコンテンツを表すために使用する要素 -->
<element name="binary-content" type="mc:BinaryContentType"/>
<!-- =================================================================== -->
<!-- スキーマ タイプ -->
<complexType name="AttachmentsType">
<sequence>
<!-- 'attachments' 変数は、単なる一連の添付要素です -->
<element ref="mc:attachment" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="AttachmentType">
<all>
<!-- 添付に関連付けられた一連の MIME ヘッダ -->
<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"/>
<!-- 添付コンテンツ自体をインラインで指定するか、または <binary-content/> として指定します -->
<element name="body" type="anyType"/>
</all>
</complexType>
<complexType name="BinaryContentType">
<!-- バイナリまたは参照渡しペイロードへの URI 参照 -->
<attribute name="ref" type="anyURI" use="required"/>
</complexType>
<!-- =================================================================== -->
<complexType name="EndpointType">
<all>
<!-- エンドポイントのサービス、転送、およびセキュリティの詳細を保持する下位要素 -->
<element ref="mc:service" minOccurs="0" />
<element ref="mc:transport" minOccurs="0" />
<element ref="mc:security" minOccurs="0" />
</all>
<!-- このエンドポイントによって表されるサービスの完全限定名 -->
<attribute name="name" type="string" use="required"/>
</complexType>
<!-- =================================================================== -->
<complexType name="ServiceType">
<all>
<!-- サービス プロバイダの名前 -->
<element name="providerName" type="string" minOccurs="0"/>
<!-- 呼び出されるサービス処理 -->
<element name="operation" type="string" minOccurs="0"/>
</all>
</complexType>
<!-- =================================================================== -->
<complexType name="TransportType">
<all>
<!-- エンドポイントの URI -->
<element name="uri" type="anyURI" minOccurs="0" />
<!-- 要求および応答に関する転送固有のメタデータ (転送ヘッダを含む) -->
<element name="request" type="anyType" minOccurs="0"/>
<element name="response" type="anyType" minOccurs="0" />
<!-- 一方向 (要求のみ) または双方向 (要求/応答) の通信を指定します -->
<element name="mode" type="mc:ModeType" minOccurs="0" />
<!-- サービスの品質を指定します -->
<element name="qualityOfService" type="mc:QoSType" minOccurs="0" />
<!-- 再試行の値 (発信のみ) -->
<element name="retryInterval" type="integer" minOccurs="0" />
<element name="retryCount" type="integer" minOccurs="0" />
</all>
</complexType>
<simpleType name="ModeType">
<restriction base="string">
<enumeration value="request"/>
<enumeration value="request-response"/>
</restriction>
</simpleType>
<simpleType name="QoSType">
<restriction base="string">
<enumeration value="best-effort"/>
<enumeration value="exactly-once"/>
</restriction>
</simpleType>
<!-- =================================================================== -->
<complexType name="SecurityType">
<all>
<!-- 転送レベルのクライアント情報 (着信のみ) -->
<element name="transportClient" type="mc:SubjectType" minOccurs="0"/>
<!-- メッセージ レベルのクライアント情報 (着信のみ) -->
<element name="messageLevelClient" type="mc:SubjectType" minOccurs="0"/>
<!-- 発信 WSS 処理を無効にするために使用するブール型フラグ (発信のみ) -->
<element name="doOutboundWss" type="boolean" minOccurs="0"/>
</all>
</complexType>
<complexType name="SubjectType">
<sequence>
<!-- この転送レベルまたはメッセージ レベルのサブジェクトに関連付けられたユーザ名 -->
<element name="username" type="string"/>
<element name="principals" minOccurs="0">
<complexType>
<sequence>
<!-- 認証プロバイダによって決まる、このサブジェクトが属する
各グループの要素 -->
<element name="group" type="string"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="FaultType">
<all>
<!-- エラーを識別する短い文字列 (たとえば BEA38229) -->
<element name="errorCode" type="string"/>
<!-- エラーの理由を説明するテキスト -->
<element name="reason" type="string" minOccurs="0" />
<!-- エラーに関する追加情報 -->
<element name="details" type="anyType" minOccurs="0" />
<!-- プロキシでエラーが発生した場所に関する情報 -->
<element name="location" type="mc:LocationType" minOccurs="0" />
</all>
</complexType>
<complexType name="LocationType">
<all>
<!-- エラーが発生したパイプライン/ブランチ/ルート ノードの名前 -->
<element name="node" type="string" minOccurs="0" />
<!-- エラーが発生したパイプラインの名前 (該当する場合) -->
<element name="pipeline" type="string" minOccurs="0" />
<!-- エラーが発生したステージの名前 (該当する場合) -->
<element name="stage" type="string" minOccurs="0" />
<!-- エラー ハンドラ内でエラーが発生したかどうかを示す -->
<element name="error-handler" type="boolean" minOccurs="0" />
</all>
</complexType>
<!-- エラーの <details> に追加されるスタック トレースをカプセル化する -->
<element name="stack-trace" type="string"/>
</schema>
|