この章では、Oracle Service Bus(OSB)メッセージ・コンテキスト・モデルとメッセージ・フローで使用する事前定義されたコンテキスト変数について説明します。
この章の内容は次のとおりです。
メッセージ・コンテキストは、Oracle Service Busでメッセージがルーティングされるときに、メッセージ・コンテキストとメッセージに関する情報を保持する一連のプロパティです。これらのプロパティは、コンテキスト変数と呼ばれます。たとえば、サービス・エンドポイントは、事前定義されたコンテキスト変数によって表されます。Oracle Service Busは、ユーザー定義のコンテキスト変数もサポートします。
メッセージ・コンテキストは、XMLスキーマによって定義されます。通常は、XQuery式を使用して、プロキシ・サービスを定義するメッセージ・フローのコンテキスト変数を操作します。
表39-1に、事前定義されたコンテキスト変数を示します。事前定義されたコンテキスト変数のタイプは、メッセージ関連の変数、inboundおよびoutbound変数、operation変数、fault変数に分けられます。
メッセージ・コンテキスト変数の要素の型については、39.10項「メッセージ・コンテキスト・スキーマ」を参照してください。
表39-1 Oracle Service Busの事前定義されたコンテキスト変数
コンテキスト変数脚注 1 | 説明 | 関連項目 |
---|---|---|
header |
SOAPメッセージの場合、 メッセージのタイプがSOAP以外の場合、 |
|
body |
メッセージ・タイプによって異なります。
|
|
attachments |
メッセージのMIME添付を格納します。 |
|
inbound |
次のものが含まれます。
|
|
outbound |
次のものが含まれます。
|
|
operation |
プロキシ・サービスで呼び出される操作を指定します。 |
|
fault |
メッセージの処理中に発生したエラーに関する情報を格納します。 |
|
脚注 1 メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。
メッセージ関連の変数であるheader
、body
、およびattachments
は、Oracle Service Busのメッセージ・フローでのメッセージの標準書式を表します。これらの変数は、プロキシ・サービスが受信したメッセージ・コンテンツを使用して初期化され、他のサービスにルーティングまたはパブリッシュされる送信メッセージを作成するために使用されます。
メッセージの処理の一部としてメッセージを変更するには、これらの変数を変更する必要があります。
メッセージ・ペイロード(つまり、ヘッダーや添付を除くメッセージ・コンテンツ)は、body
変数に格納されます。送信メッセージに含める変数のコンテンツはOracle Service Busからメッセージがディスパッチ(パブリッシュまたはルーティング)される時点で決定されます
この決定は、ターゲットのエンドポイントがSOAPメッセージを受信するか非SOAPメッセージを受信するかによって異なります。
SOAPメッセージが要求される場合は、header
変数とbody
変数がSOAPエンベロープで結合され、メッセージが作成されます。
非SOAPメッセージが要求される場合は、body
変数のBody要素のコンテンツによってメッセージ全体が構成されます。
いずれの場合も、サービスが添付を受信するときは、生成されたメッセージとattachments
変数からMIMEパッケージが作成されます。
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>
要素でラップされます。
SOAPメッセージの場合は、SOAP本文がエンベロープから抽出され、body
変数に割り当てられます。
バイナリ以外の非SOAPメッセージの場合は、新しく作成された<SOAP:Body>
要素内にメッセージ・コンテンツ全体が挿入されます。
バイナリ・メッセージの場合は、メッセージ・コンテンツがbody
変数に挿入されるのではなく、<binary-content/>
参照要素が作成され、<SOAP:Body>
要素に挿入されます。バイナリ・コンテンツの処理方法については、39.3.4項「body変数とattachments変数内のバイナリ・コンテンツ」を参照してください。
Javaオブジェクトの場合は、<java-content/>
参照要素が作成され、<SOAP:Body>
要素に挿入されます。Javaコンテンツの処理方法については、39.3.5項「body変数内のJavaコンテンツ」を参照してください。
attachments
変数には、メッセージに関連付けられた添付が格納されます。attachments
変数は、XMLスキーマで定義されます。これは、単一のルート・ノードである<ctx:attachments>
と、各添付の<ctx:attachment>
下位要素で構成されます。この下位要素には、添付に関する情報(MIMEヘッダーから派生)と添付コンテンツが含まれます。他のメッセージ関連の変数と同様に、attachments
は常に設定されます。ただし、添付がない場合は、attachments
変数は空の<ctx:attachments>
要素で構成されます。
各添付要素には、表39-2に示す一連の下位要素が含まれます。
表39-2 attachments変数の下位要素
attachments変数の要素 | 説明脚注 1 |
---|---|
Content-ID |
添付を識別するグローバルに一意の参照。型は |
Content Type |
添付のメディアのタイプとサブタイプを指定します。型は |
Content-Transfer-Encoding |
添付のエンコード方法を指定します。型は |
Content-Description |
コンテンツの説明。型は |
Content-Location |
添付を識別するローカルに一意のURIベースの参照。型は |
Content-Disposition |
受信者による添付の処理方法を指定します。型は |
body |
添付データを保持します。型は |
脚注 1 メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。
型なしのbody
要素以外のすべての要素にはMIMEでの解釈と同じ方法で解釈された文字列値が含まれます。たとえば、Content-Type
要素の有効な値は、text/xml
とtext/xml; charset=utf-8
などです。
添付の解析は再帰的ではありません。添付のContent-Type
がmultipart/...
の場合、body
要素には元のアンパックのMIMEコンテンツがバイトのストリームとして保持され、添付の下位要素は含まれません。MIMEストリームにはバイナリ・データが含まれることがあり、その場合このストリームは<binary-content>
参照要素で表します。
バイナリ・コンテンツの処理方法については、39.3.4項「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スニペットで表されます。
<binary-content ref="..."/>
このref属性に、バイナリ・コンテンツをユニークに識別するURIまたはURNを指定します。このXMLは、Oracle Service Busパイプライン、ブランチまたはルート・ノードで他のコンテンツと同様に操作できます。ただし、影響を受けるのは、元のバイナリ・コンテンツではなく参照だけです。
例:
body
変数のバイナリ・コンテンツを添付にコピーするには、参照XMLを添付要素のbody
下位要素にコピーします。
2つの異なる添付のバイナリ・コンテンツを置き換えるには、参照XMLスニペットまたはref属性の値を置き換えます。
メッセージがOracle Service Busからディスパッチされると、参照XMLのURIを使用して、関連バイナリ・コンテンツが送信メッセージ内に復元されます。アウトバウンド・メッセージの作成方法については、39.9項「ディスパッチするメッセージの作成」を参照してください。
クライアントと特定の転送(特に、電子メール、ファイル、FTP)では、この同じ参照XMLを使用して参照渡しを実装できます。この場合、実行時のプロキシ・サービスではなく転送またはクライアントによって、参照XMLが作成されます。また、ref
属性内のURIの値は、参照XMLを作成するユーザーによって指定されます。参照XMLが実行時のプロキシ・サービスによって作成されない場合(特に、URIの参照先が、内部で管理されているバイナリ・コンテンツであると認識されない場合)、URIはOracle Service Busにより逆参照されず、送信メッセージにコンテンツが挿入されません。
Oracle Service BusからBPELビジネス・プロセスへ添付文書付きSOAP(SwA)を送信し、XPath関数ora:getAttachmentContent('inputVariable','bin','/bin')
を使用してBPEL内の複数の添付を取得するには、必ず次の手順を実行してください。
複数の添付にContent-ID
添付変数を設定します。
href
属性を使用して、プライマリSOAPエンベロープ内の添付を参照します。
場合によっては、cid:
情報がhref
属性にない場合があります。
次に、例を示します。
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<rootpart@example.com>" Content-Description: This is the optional message description. --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"> <m:SendClaim xmlns:m=”http://example.com/mimewsdl”> <ClaimDetail> <Name>...</Name> <!-- additional claim details --> </ClaimDetail> <ClaimPhoto href=”cid:4d7a5fa2-14af-451c-961b5c3abf786796@example.com”/> </m:SendClaim> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <4d7a5fa2-14af-451c-961b5c3abf786796@example.com> ...MIME attachment of binary photograph... --MIME_boundary—
Oracle Service Busパイプラインでは、Javaコールアウト・アクションへの入力および出力として、Javaオブジェクトをサポートしています。Javaコールアウトから返されたPOJOはパイプラインにキャッシュされ、そのキーは<java-content ref="
cid:kkkkeeeeyyyy
"/>
の形式のXMLメッセージにラップされて返されます。ここで、cid:kkkkeeeeyyyy
は、生成アクションによって自動的に生成されたキーであり、パイプラインのキャッシュにあるオブジェクトの索引を指定するために使用されます。後続するすべてのアクションに対して、このXMLが変更されずに引数として渡されます。
構成時にはPOJO変数のコンテンツは、パイプライン・アクションからは直接アクセスできません。かわりに、コンテンツは次の方法で操作できます。
コンテンツのメタデータ(コンテンツのキー)は、他のXML(たとえば、$pojo/java-content/@ref
のようなXQuery)と同様に処理できます。これはロギングやデバッグに役立つことがありますが、オブジェクトのコンテンツに直接アクセスすることはできません。
(パイプライン内で)自動的にPOJO型として指定される新しい変数にコンテンツを割り当てることができます。オブジェクト自体にアクセスすることはできません。XMLスニペット<java-content.../>
がソース変数からターゲット変数にコピーされます。
コンテンツは、別の適切なアクション(Javaコールアウトなど)に変数(たとえば、$pojo
)として渡すことができます。オブジェクト自体にアクセスすることはできません。引数は、実際のオブジェクトに自動的に逆参照されます。
(<java-content />
内に)Javaオブジェクトのキーを保持しているすべての変数を削除した場合、または<java-content />
スニペットを指しているすべてのXPathを削除した場合、Javaオブジェクトはパイプラインのキャッシュから削除されます。
メッセージ・コンテンツを処理する際に、Oracle Service Busパイプラインによってコンテンツをメモリーにロードするのではなく、コンテンツをストリームするように指定できます。プロキシ・サービスのコンテンツ・ストリーミングを有効にするときは、メッセージ処理時の中間手順として、ストリーミングされたコンテンツをメモリーとディスク・ファイルのどちらにバッファリングするかを指定します。これらの一時ファイルの作成は、パフォーマンスに影響を及ぼすことがあります。一時ファイルの保護については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のbodyコンテンツをストリーミングする場合の一時ファイルの保護に関する項を参照してください。
ストリーミング・オプションを有効にした場合、コンテンツ・ストリーミングはbody変数のみ
に適用されます。
一般に、コンテンツ・ストリーミングを使用するのは次のような場合です。
サイズの大きいコンテンツのメッセージを処理する場合。39.3.6.1項「コンテンツ・ストリーミングを使用する際のベスト・プラクティス」のガイドラインを参照してください。
Oracle Service Busがペイロードにアクセスする回数が少ない場合。
トランスフォーメーションのないコンテンツ・ベースのルーティングの場合。コンテンツ・ストリーミングを使用すると、部分解析の利点が得られるため、パフォーマンスが向上します。
次のガイドラインと推奨事項に従ってください。
サイズの大きいメッセージを処理するためにストリーミングを有効にした場合、body
メッセージ・コンテキスト変数について、挿入、置換、名前変更、for each、検証、および削除の各アクションを使用することはできません。これらのアクションでは、入力変数をメモリー内で完全に実体化する必要がありますが、完全な実体化はコンテンツ・ストリーミング・オプションと互換性がないためです。
次のパイプライン・アクションでは、サイズの大きい$body
のXQueryトランスフォーメーションまたはXSLトランスフォーメーションの結果を使用できます。
割当て、挿入、および置換の各アクション - 別のコンテキスト変数($body
以外)の値を更新する場合。ただし、式の結果が完全に実体化でき、メッセージ・コンテキストに格納できる小さなサイズであることを確認する必要があります。
Javaコールアウト - 入力引数を渡す場合。Javaコールアウトへのすべての入力は完全に実体化されます。したがって、入力として使用する式の結果は、完全に実体化できる小さなサイズであることが必要です。
MFLトランスフォーメーション - 入力をXML Beanとしてあらかじめ実体化せずに、サイズの大きいペイロードを変換する場合。MFLトランスフォーメーションへの入力としてサイズの大きい$body
を使用する場合は、メッセージング・サービスをバイナリ・メッセージ・タイプのプロキシ・サービスとして宣言します。メッセージング・サービスをテキスト・メッセージ・タイプのプロキシ・サービスとして宣言すると、トランスフォーメーションの入力ストリームを取得するために$body
が完全に実体化されます。
アラート、ログ、およびレポートの各アクション - サイズの大きい$body
のXQueryトランスフォーメーションまたはXSLトランスフォーメーションの結果を報告する場合。
サービス・コールアウト
XSLトランスフォーメーションでは、トランスフォーメーションを実行するためにすべての入力が完全に実体化されます。したがって、入力が完全に実体化でき、XSLTプロセッサが処理できる小さなサイズであることを確認する必要があります。
サイズの大きいMFL入力を使用する場合、MFLステージ・アクションではなく、MFLサービスを使用してMFLからXMLへのトランスフォーメーションを実行する必要があります。
コンテンツが完全に実体化されると、OOM例外が発生する可能性があり、コンテンツを表示することによって、テスト・コンソール・ウィンドウの処理速度が低下するので、テスト・コンソールを使用して、サイズの大きいコンテンツのメッセージでプロキシ・サービスをテストしないでください。
XQueryを作成するときは、適切な索引を使用して部分解析を実行できるようにします。
たとえば、入力ストリーム全体を使用する$body/*:DateTimeStruct
を記述するのではなく、次のように記述します。
($body/*:DateTimeStruct)[1] or $body[1]/*:DateTimeStruct[1]
索引を使用することにより、1つ目のDateTimeStruct
要素までのコンテンツのみが解析されます。
複数のコンシューマ(式)がアクセスする各変数が実体化されるため、XQueryを作成するときに、次のような文を記述しないようにしてください。
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/>)
実行時に、サイズの大きいメッセージの処理は、基になるトランスポートの制限と制約を受けます(メッセージ・サイズの処理の制限など)。サイズの大きいメッセージを受け入れるトランスポートの容量を制限するJVMおよびRMIの設定に注意してください。
メッセージの添付ファイルを処理する際に、添付ファイルをメモリーにバッファリングしてXMLとして解析するのではなく、MIME添付ファイルをディスクにページングしてからコンテンツをストリーミングするように指定できます。サイズの大きい添付ファイルを扱う場合は、この方法が特に効果的です。
この方法を使用すると、ヘッダーのみがバッファリングされ、残りのメッセージ・ペイロードは、小さい複数の部分を同時に読み込むことができるストリームとして公開されます。ストリーミングされた転送により、サイズの大きいメモリー・バッファが不要になるため、サービスのスケーラビリティが向上します。
Oracle Service Busでは、次のトランスポートを使用するプロキシ・サービスおよびビジネス・サービスについて、MIME添付ファイルのストリーミングがサポートされます。
HTTP/S
ローカル(添付ファイルのストリーミングが有効になっているHTTPプロキシを介して連鎖し、ページングされた添付ファイル設定を継承している場合)
注意: 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
メッセージ・コンテキスト変数を初期化します(39.3.7.1項「インバウンド・メッセージの処理」を参照してください)。
Oracle Service Busでは、XOP/MTOM形式のインバウンド・メッセージをデコードして解析し、必要に応じてXOP/MTOM形式を使用してレスポンスを送信するように、プロキシ・サービスを構成できます。また、Service Busではアウトバウンド・メッセージをXOP/MTOM形式でエンコードするようにビジネス・サービスを構成できます。
Oracle Service Busは、着信XOP/MTOMペイロードを受け入れてデコードするために、次のバインディング・タイプを持つプロキシ・サービスをサポートしています。
任意のXML
メッセージング(XML)
任意のSOAP
WSDLベース
XOP/MTOMペイロードを受信するその他のサービス・バインディング・タイプのプロキシ・サービスは、MIMEマルチ・パート・リクエストと同じようにペイロードを処理し、MTOM固有の処理は行いません。
また、次のOracle Service BusトランスポートはXOP/MTOMをサポートします。
HTTP/S
ローカル
SB (連鎖しているOracle Service Busドメインなど、適用可能な場合)
Oracle Service Busは、次のアウトバウンド・メッセージをディスパッチできるすべての既存アクションをサポートします。
ルート、動的ルーティング、およびルート表
パブリッシュ、動的パブリッシュ、およびパブリッシュ表
サービス・コールアウト
Oracle Service Busでは、XOP/MTOMを有効にしたSOAPサービスで、Oracle WSMメッセージ保護ポリシーおよび非メッセージ保護ポリシーがサポートされています。ただし、署名暗号を有効化するOracle WSMメッセージ保護ポリシーまたは添付付きSOAP(SwA)の両方とも、MTOMエンコード・メッセージと互換性がないため、これらのポリシーはXOP/MTOMでサポートされていません。
プロキシ・サービスでXOP/MTOM形式のインバウンド・メッセージをデコードして解析し、必要に応じてXOP/MTOM形式を使用してレスポンスを送信することができます。「XOP/MTOMサポート」が有効になっている場合は、$bodyメッセージ・コンテキスト変数のバイナリ・データを処理する方法を次のオプションからさらに選択します。
「参照によるバイナリ・データを含む」(デフォルト) 39.3.8.1.1項「参照によるバイナリ・オプションについて」を参照
「値によるバイナリ・データを含む」 39.3.8.1.2項「値によるバイナリ・オプションについて」を参照
「XOP/MTOMサポート」がプロキシ・サービスに対して有効になっている場合は、すべてのインバウンド・メッセージがMTOM形式である必要はありません。かわりに、この設定では、MTOM形式のメッセージが到着したときに、プロキシ・サービスでそれを適宜処理する必要があることを指定します。XOP/MTOMサポートが有効になっていないプロキシ・サービスがMTOM形式のメッセージを受信した場合、サービスはメッセージを拒否し、ランタイム・エラーを発行することにも注意してください。
次の各項では、バイナリ・データ・オプションを使用するときのプロキシ・サービスの動作を説明します。プロキシ・サービスのXOP/MTOMが有効になっており、Oracle WSMインバウンド・リクエスト実行ポリシーを使用している場合にこの動作がどう変化するかの詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の
第50章の「Oracle Web Services ManagerによるOracle Service Busの保護」に関する項を参照してください。
バイナリ・データに直接アクセスする必要がある場合、たとえばJavaコールアウトまたはMessage Format Language (MFL)トランスフォームにデータを渡す場合は、「参照によるバイナリ・データを含む」オプションを使用します。
参照によるバイナリ・オプションが選択されている場合は、Oracle Service Busはインバウンド・メッセージのルートを解析してxop:Include
タグの存在をチェックします。これらのタグが検出された場合、タグはバイナリ・リポジトリ内の対応するソースへの参照を含むctx:binary-content
要素に変換されます。結果としてのドキュメントは$body
メッセージ・コンテキスト変数によって表されます。対照的に、$attachments
メッセージ・コンテキスト変数は情報を含みません(nullです)。
つまり、パイプライン・アクションが$body
メッセージ・コンテキスト変数のコンテンツにアクセスした場合、アクションはxop:Include
要素を検出しないかわりに、ctx:binary-content
要素を使用して動作します。
プロキシ・サービスがクライアントにレスポンスを返信する必要がある場合、バインディング・レイヤーはctx:binary-content
参照をメッセージのルートにあるxop:Include
タグに置換し、対応する各バイナリ・コンテンツ参照に別々のMIME部分を追加して、XOP/MTOMパッケージ・レスポンスを作成します。
「値によるバイナリ・データを含む」は次の場合に使用します。
MTOMとMTOM以外のサービスの間にブリッジを作成する場合。たとえば、MTOM対応でないサービスにルーティングされるリクエストを受信するMTOM対応のプロキシ・サービスについて考えます。このオプションを使用して、XML内のバイナリ・データをBase64エンコード形式で送信するために既存の標準に準拠できます。
バイナリ・データの代わりにbase64binary要素の使用を必要とするXMLスキーマに照らしてメッセージのコンテンツを検証する場合。
値によるバイナリ・オプションが選択されている場合は、Oracle Service BusがインバウンドMIMEメッセージのルートを解析してxop:Include
タグの有無をチェックします。該当するタグが検出された場合、対応するMIME部分の本体(バイナリ・データ)はBase64でエンコードされ、結果としてのテキストが$body
メッセージ・コンテキスト変数のxop:Include
タグを置換します。対照的に、 $attachments メッセージ・コンテキスト変数は情報を含みません(nullです)。
ビジネス・サービスを有効にすると、アウトバウンド・メッセージをXOP/MTOM形式でエンコードできます。[XOP/MTOMサポート]が有効になっている場合は、 $header および $body メッセージ・コンテキスト変数のバイナリ・データを処理する方法を次のオプションからさらに選択します。
参照によるバイナリ・データを含む: (デフォルト)アウトバウンド・レスポンス・メッセージでの$bodyメッセージ・コンテキスト変数の設定時に、xop:Include
要素をctx:binary-content
要素に置換します。
値によるバイナリ・データを含む: アウトバウンド・レスポンス・メッセージで、$bodyメッセージ・コンテキスト変数の設定時にxop:Include
要素を対応するバイナリ・データのBase64エンコード・テキスト・バージョンで置換します。
「XOP/MTOMサポート」がビジネス・サービスに対して有効になっている場合は、すべてのアウトバウンド・メッセージがMTOM形式である必要はありません。かわりに、この設定はビジネス・サービスがMTOMペイロードを処理できることを指定します。
次の各項では、バイナリ・データ・オプションを使用するときのビジネス・サービスの動作を説明します。ビジネス・サービスのXOP/MTOMが有効になっており、Oracle WSMポリシーを使用している場合にこの動作がどう変化するかの詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の
第50章の「Oracle Web Services ManagerによるOracle Service Busの保護」に関する項を参照してください。
ビジネス・サービスで「XOP/MTOMサポート」が有効になっている場合、Oracle Service Busは$bodyメッセージ・コンテキスト変数のコンテンツを調べてctx:binary-content
要素を検索します。要素がある場合、Oracle Service Busはctx:binary-content
をxop:Include
要素およびペイロードの対応するMIME部分に置換して、XOP/MTOM MIMEパッケージを作成します。
XOP/MTOMが有効で本体にバイナリ・コンテンツが含まれている場合、コンテンツのサイズに関係なく(たとえば、1KBより小さい場合でも)Oracle Service Busは常にXOP/MTOMを使用します。
また、Oracle Service BusはMTOMとSwAの組合せをサポートしません。そのため、ビジネス・サービスへのアウトバウンド・リクエストをディスパッチする必要があり、次の条件に該当する場合、システムは実行時例外をスローします。
ビジネス・サービスのXOP/MTOMが有効になっています。
$attachmentsメッセージ・コンテキスト変数がnullではありません。
サービスでXOP/MTOMが有効になっている場合、前の説明に示すように、Oracle Service Busはメッセージの$headerと$body内の要素を自動的に変更します。XOP/MTOMメッセージを変更する必要があるため、Oracle Service Busはメッセージ$headerとメッセージ$bodyのストリーミングをサポートしません。
ただし、添付ファイルが大きいためにメモリー不足のエラーを発生させるような場合、XOP/MTOMメッセージのバイナリ添付ファイルを、Oracle Service Busヒープ(デフォルト)ではなく、ディスクに直接ストリーミングする必要があります。
注意: XOP/MTOM添付ファイルは、メッセージの$attachments変数では送信されません。前述のとおり、それらはメッセージ$body内に含まれるかまたは$bodyメッセージから参照されます。 |
XOP/MTOMメッセージの添付ファイルを直接ディスクにストリーミングするには、サービス構成で次の設定を使用します。
XOP/MTOMの「参照によるバイナリ・データを含む」オプションを使用します。(「値によるバイナリ・データを含む」オプションでは、$body内にバイナリ・データが直接含まれ、XOP/MTOMのサポートにはストリーミングできません。)
「参照によるバイナリ・データを含む」が選択されている場合は、「添付ファイルのディスクへのページング」オプション(HTTPトランスポートのみ)も選択できます。「添付ファイルのディスクへのページング」が選択されている場合は、Oracle Service Busはメモリーではなくディスク上のバイナリ添付ファイルを参照するXOP/MTOMメッセージを生成します。
注意: 最適なパフォーマンスを得るためにはメモリー内の添付ファイルを参照する方法が推奨されるので、メモリー不足のエラーを発生させるようなサイズの大きい添付ファイルを送信する特別な必要性がある場合のみ「添付ファイルのディスクへのページング」オプションを使用します。 |
$inbound
コンテキスト変数と$outbound
コンテキスト変数には、インバウンド・エンドポイントとアウトバウンド・エンドポイントに関する情報が格納されます。$inbound
変数にはリクエスト・メッセージを受信したプロキシ・サービスに関する情報が格納され、$outbound
変数にはメッセージの送信先であるターゲット・ビジネス・サービスに関する情報が格納されます。
$outbound
変数は、ルート・ノードのルート・アクションとパブリッシュ・アクションで設定されます。$outbound
を変更するには、ルート・ノードでリクエスト・アクションとレスポンス・アクションを構成し、パブリッシュ・アクションでリクエスト・アクションを構成します。
注意: inbound コンテキスト変数およびoutbound コンテキスト変数に行う変更の一部は、実行時に保持されません。つまり、特定のヘッダーおよびメタデータは、Oracle Service Busランタイムによって上書きまたは無視されます。トランスポート・ヘッダーとサービス・コールアウト・アクションを使用してトランスポート・ヘッダーとメタデータを設定する場合、およびテスト・コンソールを使用してプロキシ・サービスとビジネス・サービスをテストする場合にもこの制限は当てはまります。
制限のあるヘッダーとメタデータの詳細は、33.4項「テスト・コンソールでのランタイムによるトランスポート設定の使用方法」を参照してください。ルート・ノードのリクエスト・アクションまたはレスポンス・アクションおよびパブリッシュ・アクション |
サービス・コールアウト・アクションでoutbound
変数を変更することはできません。
inbound
変数とoutbound
変数の特性は次のとおりです。
同じXMLスキーマを持ちます。inbound
コンテキスト変数とoutbound
コンテキスト変数は、39.10項「メッセージ・コンテキスト・スキーマ」
で説明されているようにendpoint要素のインスタンスです。
サービス・ディレクトリに登録されているエンドポイントの名前を指定する単一のname
属性を含みます。name
属性は、inbound
、outbound
いずれの場合も読取り専用として扱う必要があります。
注意: この読取り専用ルールは強制されません。読取り専用の要素を変更すると予期できない動作が生じることがあります。 |
次の項で説明する下位要素service
、transport
、security
を含みます。
HTTP、HTTPSまたは電子メール・トランスポートの場合のみ、添付ファイルがインバウンド・リクエストおよびアウトバウンド・レスポンス(つまりプロキシ・サービスが受信するメッセージ内)でサポートされます。
添付ファイルは、アウトバウンド・リクエストおよびインバウンド・レスポンス(つまりプロキシ・サービスが送信するメッセージ)に関するすべてのトランスポート・タイプでサポートされます。
Oracle Service Busでは、EJB、Tuxedo、またはDSPベースのサービスへの添付ファイルの送信はサポートしていません。
この項では、コンテキスト変数inbound
およびoutbound
の下位要素について説明します。また、どの下位要素が実行時に初期化されるかについての情報も示します。コンテキスト変数が初期化される方法については、39.7項「コンテキスト変数の初期化」を参照してください。次の下位要素があります。
service
要素は、inbound
、outbound
いずれの場合も読取り専用です。下位要素としてはproviderName
、operation
があります。
表39-3 service要素の下位要素
下位要素脚注 1 | 説明 |
---|---|
providerName |
サービス・キー・プロバイダの名前を指定します。 パブリッシュ・アクションおよびルーティング・アクションの構成に基づいて初期化されます。 |
operation ( |
inboundおよびoutboundに基づいて初期化されます。 注意: この要素は |
脚注 1 メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。
transport
要素はinbound
の場合は読取り専用です。ただし例外として、response
要素ではこの要素を変更してレスポンス・トランスポート・ヘッダーを設定できます。transport
要素の下位要素を表39-4に示します。
表39-4 transport要素の下位要素
下位要素脚注 1 | 説明 |
---|---|
uri |
次のようにエンドポイントのURIを指定します。
初期化 URI要素は次のように初期化されます。
|
request inbound変数では、この要素は読取り専用脚注 2 |
リクエストに関するトランスポート固有のメタデータ(トランスポート・ヘッダーを含む)を指定します。この要素の値は転送プロトコルによって定義されます(具体的には、トランスポートSDKによって定義された この要素のトランスポート固有の型については、Oracle Service Busインストールの次のディレクトリに用意された該当するトランスポート・スキーマを参照してください。
初期化 URI要素は次のように初期化されます。
ルート・ノードのリクエスト・アクションで
|
response この要素は、 |
レスポンスに関するトランスポート固有のメタデータ(トランスポート・ヘッダーを含む)を指定します。この要素の値は転送プロトコルによって定義されます(具体的には、トランスポートSDKによって定義された この要素のトランスポート固有の型については、Oracle Service Busインストールの次のディレクトリに用意された該当するトランスポート・スキーマを参照してください。
初期化
標準HTTPヘッダーの説明については、 標準JMSヘッダーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』のJMSパブリックAPIの付加価値拡張機能に関する項を参照してください。 注意: MQヘッダー |
mode |
通信スタイルが 初期化
|
qualityOfService この要素は、
|
メッセージ送信時または受信時に使用するサービスの品質を指定します。有効な値は
初期化
|
retryCount ( |
Oracle Service Busからメッセージを送信するときの再試行回数を指定します。
|
脚注 1 メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。
脚注 2 この読取り専用ルールは強制されません。読取り専用の要素を変更すると予期できない動作が生じることがあります。
security
要素の下位要素を表39-5に示します。
表39-5 security要素の下位要素
下位要素脚注 1 | 説明 |
---|---|
transportClient ( |
認証されたトランスポート・レベル・ユーザー情報を指定します。ユーザー情報にはユーザー名とオプションのprincipalsが含まれます。principalsには0個以上のgroupを含めて、subjectが属するgroupごとに1つの要素を含めることができます。 注意: subjectが匿名の場合、usernameは" Oracle Service Busによって初期化されます。inboundの |
messageLevelClient ( |
認証されたメッセージ・レベル・ユーザー情報を指定します。ユーザー情報にはユーザー名とオプションのprincipalsが含まれます。principalsには0個以上のgroupを含めて、subjectが属するgroupごとに1つの要素を含めることができます。 注意: subjectが匿名の場合、usernameは" Oracle Service Busによって初期化されます。inboundの |
doOutboundWss
|
Oracle Service Busは、ルーティング時またはパブリッシュ時にこの要素の値を設定します。 使用頻度の低いデザイン・パターンには、この値を 詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の「Webサービスのメッセージ・レベルでのセキュリティの構成」、アウトバウンドWS-Securityの無効化に関する項を参照してください。 注意: あるプロキシ・サービスがOracle Web Services Managerサービス・ポリシーを含む別のプロキシ・サービス(ローカル・プロキシなど)を呼び出す場合はアウトバウンドWS-Security処理は行われません。OSBはその操作を自動的に処理し、doOutboundWssプロパティを使用しません。詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のローカル・プロキシでのOracle WSMセキュリティの使用に関する説明を参照してください。 |
脚注 1 メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。
脚注 2 この読取り専用ルールは強制されません。読取り専用の要素を変更すると予期できない動作が生じることがあります。
標準HTTPヘッダーの説明については、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
を参照してください。
標準JMSヘッダーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』のWebLogic JMSに関する項を参照してください。
operation
変数は、読取り専用の変数です。この変数には、プロキシ・サービスで呼び出される操作を指定する文字列が格納されます。プロキシ・サービスに対する操作が定義されていない場合は、operation
変数が設定されず、nullと等価の値が返されます。
Oracle Service Busでは、パフォーマンスを最適化するためにoperation
変数がinbound
変数の下位要素ではなくスタンドアロン変数として提供されます。処理の計算は、inbound
変数がアクセスされたときではなく、operation
変数が明示的にアクセスされるまで延期されることがあります。
fault
変数は、メッセージ処理中に発生したすべてのエラーに関する情報を保持するために使用します。エラーが発生すると、この変数に情報が格納されてから、適切なエラー・ハンドラが呼び出されます。
注意: この変数はエラー・ハンドラ・パイプラインでのみ定義され、リクエスト・パイプラインやレスポンス・パイプライン、ルート・ノードやブランチ・ノードでは設定されません。 |
fault
変数には、表39-6
に示すerrorCode
、reason
、details
およびlocationの各下位要素が含まれます。
表39-6 fault変数の下位要素
fault変数の要素 | 説明脚注 1 ... |
---|---|
errorCode |
エラー・コードを文字列値で指定します。 |
reason |
エラーの説明を格納します。 |
details |
エラーに関連するユーザー定義XMLコンテンツを格納します。 |
location |
エラーが発生したノード、パイプライン、およびステージを指定します。また、エラーがエラー・ハンドラ内で発生したかどうかも指定します。次の下位要素があります。
|
脚注 1 メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。
fault
変数のコンテンツは、SOAPベースのプロキシ・サービスからの返信時にフォルトを生成しやすいよう、SOAPフォルトに基づいてモデル化されています。Oracle Service Busによって生成されるエラー・コードの値はシステム・エラー・コードに対応し、エラー・コードにはBEA文字列の接頭辞が付加されます。
エラーに関連付けられたエラー・コードは、fault
コンテキスト変数の要素内に表示されます。次のXQuery文を使用して値にアクセスできます。
$fault/ctx:errorCode/text()
Oracle Service Busでは、考えられる3つのクラスのエラーに対応する3つの汎用エラー・コードが定義されています。汎用コードの形式はBEA-xxx000
です。ここで、xxx
は汎用カテゴリを次のように表します。
380: トランスポート
382: プロキシ
386: セキュリティ
394: UDDI
これにより、次のように汎用コードが生成されます。
BEA-380000からBEA-380999
トランスポート・エラーを示します(メッセージのディスパッチの失敗など)。
BEA-382000からBEA-382499
プロキシ・サービスのランタイム・エラーを示します(ステージの例外など)。
BEA-382500からBEA-382999
プロキシ・サービス・アクション内のエラーを示します。
BEA-386000からBEA-386999
WS-Securityエラーを示します(認可エラーなど)。
BEA-394500からBEA-394999
UDDIサブシステム内のエラーを示します。
Oracle Service Busでは、特定のエラーを示すユニークなコードが定義されています。例:
BEA-382030 - メッセージ解析エラーを示します(SOAPプロキシ・サービスが非SOAPメッセージを受信したなど)。
BEA-382500 - サービス・コールアウト・アクションがSOAPフォルト・レスポンスを受信した場合に備えて予約されています。
これらのエラー・コードおよびその他の特定のエラー・コードについては、付録A「エラー・コード」を参照してください。また、37.7項「メッセージ・フローでのエラー処理」も参照してください。
メッセージ・コンテキストとその変数は、メッセージ受信時およびメッセージ処理の開始前にバインディング・レイヤーで初期化されます。コンテキスト変数を初期化する方法を表39-7に示します。
表39-7 コンテキスト変数の初期化
コンテキスト変数 | 初期化方法 |
---|---|
fault |
ルーティングが行われていないか、エラーが発生していないため、nullに初期化されます。 |
outbound |
ルート・ノードのルート・アクションとパブリッシュ・アクションで初期化されます。ルーティング・ノードのリクエスト・アクションとパブリッシュ・アクションで(さらに、ルーティング・ノードのレスポンス・アクションでも)
|
inbound |
登録されたプロキシ・サービスに関するService Busメタデータと、特定の受信リクエストに関するトランスポート・レベル・メタデータ(トランスポート・ヘッダー、認証されたユーザー情報など)から取得したサービス、トランスポート、およびセキュリティの情報で初期化されます。
|
header body attachments operation |
インバウンド・メッセージのコンテンツを使用して初期化されます。初期化の実行方法は、この項の以降のトピックで説明するようにプロキシ・サービスのタイプによって異なります。
|
attachments
コンテキスト変数は、メッセージに含まれるすべてのMIME添付ファイルで初期化されますが、メイン・メッセージを表す部分は含まれません(SOAP、XML、MFLなど形式を問わず)。各<attachment>
要素は、MIMEパッケージの各部分に伴うMIMEヘッダーを使用して初期化されます。
<attachment>
の<body>
要素のコンテンツは、添付のContent-Type
に応じて次のいずれかになります。
XML
テキスト
添付コンテンツを参照する参照XMLスニペット(39.3.4項「body変数とattachments変数内のバイナリ・コンテンツ」を参照)
この項では、コンテキスト変数header
およびbody
の初期化方法について説明しますが、これらの変数の初期化方法は、プロキシ・サービスのタイプが39.9.1項「SOAPサービス」、39.9.2項「XMLサービス(非SOAP)」、39.9.3項「メッセージング・サービス」のいずれであるかによって異なります。
SOAPベースのサービスへのメッセージは、<soap:Envelope>
要素に含まれるXMLを含むSOAPメッセージです。添付を含むメッセージの場合、インバウンド・メッセージのコンテンツは、SOAPエンベロープをその一部として(通常は最初の部分、または最上位のContent-Type
ヘッダーで指定される部分)含むMIMEパッケージです。コンテキスト変数は次のように初期化されます。
header
- SOAPメッセージの<soap:Header>
要素で初期化されます。
body
- SOAPメッセージの<soap:Body>
要素で初期化されます。
XMLベースのサービスへのメッセージはXMLですが、プロキシ・サービス構成で許可された型を使用できます。添付を含むメッセージの場合、インバウンド・メッセージのコンテンツは、プライマリXMLペイロードをその一部として(通常は最初の部分、または最上位のContent-Type
ヘッダーで指定される部分)含むMIMEパッケージです。
コンテキスト変数は次のように初期化されます。
header
- 空の<soap:Header/>
要素で初期化されます。
body
- XMLペイロード全体をラップする<soap:Body>
要素で初期化されます。
メッセージング・サービスは、あるデータ型のメッセージを受信し、応答として別のデータ型のメッセージを返すことができるサービスです。サポートされるデータ型は、XML、MFL、テキスト、または型なしバイナリです。コンテキスト変数は次のように初期化されます。
header
- 空の<soap:Header/>
要素で初期化されます。
body
- ペイロード全体をラップする<soap:Body>
要素で初期化されます。
XML、MFL、およびテキスト・コンテンツの場合は、<soap:Body>
要素内に直接挿入されます。
バイナリ・コンテンツの場合は、参照XMLコードが作成され<soap:Body>
要素内に挿入されます(39.3.4項「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>
でラップしません。
サービス・コールアウト・アクションの構成については、21.6項「サービス・コールアウト・アクションの追加」を参照してください。
$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ヘッダーの構成の詳細については21.6項「サービス・コールアウト・アクションの追加」を参照してください。
WS-Addressingヘッダー(From)の抽出: $header/wsa:From
非SOAPメッセージからのペイロードの抽出: $body/*
アウトバウンド・レスポンス・メッセージからのuser-headerの抽出: $outbound/ctx:transport/ctx:response/tp:user-header[@name='myheader']/@value
SOAPサービスへのサービス・コールアウト内のリクエスト・パラメータに使用するbody
入力変数を作成する場合、soap-env:Body
ラッパーを削除するために、body/*
を使用してその変数のコンテンツを定義します($body
を使用すると、soap-env:Body
ラッパーが保持されます)。
サービス コールアウト内のリクエスト・パラメータの変数コンテンツの割当て: $body/*
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
変数はアウトバウンド・メッセージにコンテンツを提供しません。
サービス・コールアウト・アクションに対するメッセージの作成の例については、第21章「プロキシ・サービス: アクション」を参照してください。
Oracle Service Busのメッセージング・サービスへのメッセージは、body
変数のコンテンツから作成されます。
送信メッセージのタイプに関係なく、body
変数が空の場合、サイズがゼロのメッセージが送信されます。
送信メッセージのタイプがXMLの場合、メッセージは39.9.2項「XMLサービス(非SOAP)」で示されているのと同じ方法で作成されます。
送信メッセージのタイプがMFLの場合は、抽出されたXMLがMFLに変換される点を除きXMLメッセージの場合と同様に処理されます。(XMLから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
変数はアウトバウンド・メッセージにコンテンツを提供しません。
サービス・コールアウト・アクションに対するメッセージの作成の例については、第21章「プロキシ・サービス: アクション」を参照してください。
バイナリ・メッセージの場合、Oracle Service Busではbody
変数にメッセージ・コンテンツは挿入されません。かわりに、<binary-content/>
参照要素が作成され<SOAP:Body>
要素に挿入されます(39.3項「メッセージ関連の変数」を参照)。ただし、電子メール規格では、バイナリ・コンテンツ・タイプをメッセージの主要な部分として送信することがサポートされていません。テキストまたはXMLのドキュメントと任意の添付を受信するメッセージング・サービスに、電子メールでバイナリ・メッセージを送信する場合は、次の手順に従います。
バイナリ・コンテンツ参照XMLを$body
から$attachments
に変更します。
$body
のコンテンツを<SOAP:Body>
要素でラップされたテキストまたはXMLに置き換えます。
送信メッセージのタイプがMFLの場合は、$body
のコンテンツが、MFLトランスフォーメーションに基づいてXMLからテキストまたはバイナリに変換されます。
ターゲット・サービスでテキスト・メッセージを受信する場合は、$outbound
でcontent-type
(MFLメッセージ・タイプのデフォルトはバイナリ)をtext/plain
として設定できます。
ターゲット・サービスでバイナリ・メッセージを受信する場合は、電子メール・トランスポートでMFLコンテンツを送信することはできません。
バイナリ・コンテンツの処理方法については、39.3.4項「body変数とattachments変数内のバイナリ・コンテンツ」を参照してください。
メッセージ・コンテキスト変数の型を指定するメッセージ・コンテキスト・スキーマ(MessageContext.xsd
)は、39.10項「Message Context.xsd」で示されます。
メッセージ・コンテキスト変数を操作する場合、JARファイル(OSB_ORACLE_HOME
/lib/sb-schemas.jar)に用意されたMessageContext.xsd
と、OSB_ORACLE_HOME
/lib/transports/にあるトランスポート固有のスキーマを参照する必要があります。
例39-1 Message Context.xsd
<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"> <!--============================================================== --> <!-- The context variable 'fault' is an instance of this element --> <element name="fault" type="mc:FaultType"/> <!-- The context variables 'inbound' and 'outbound' are instances of this element --> <element name="endpoint" type="mc:EndpointType"/> <!-- The three sub-elements within the 'inbound' and 'outbound' variables --> <element name="service" type="mc:ServiceType"/> <element name="transport" type="mc:TransportType"/> <element name="security" type="mc:SecurityType"/> <!-- The context variable 'attachments' is an instance of this element --> <element name="attachments" type="mc:AttachmentsType"/> <!-- Each attachment in the 'attachments' variable is represented by an instance of this element --> <element name="attachment" type="mc:AttachmentType"/> <!-- Element used to represent binary payloads and pass-by reference content --> <element name="binary-content" type="mc:BinaryContentType"/> <!-- =================================================================== --> <!-- 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> <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> <complexType name="BinaryContentType"> <!-- URI reference to the binary or pass-by-reference payload --> <attribute name="ref" type="anyURI" use="required"/> </complexType> <!-- =================================================================== --> <complexType name="EndpointType"> <all> <!-- Sub-elements holding service, transport, and security details for the endpoint --> <element ref="mc:service" minOccurs="0" /> <element ref="mc:transport" minOccurs="0" /> <element ref="mc:security" minOccurs="0" /> </all> <!-- Fully-qualified name of the service represented by this endpoint --> <attribute name="name" type="string" use="required"/> </complexType> <!-- =================================================================== --> <complexType name="ServiceType"> <all> <!-- name of service provider --> <element name="providerName" type="string" minOccurs="0"/> <!-- the service operation being invoked --> <element name="operation" type="string" minOccurs="0"/> </all> </complexType> <!-- =================================================================== --> <complexType name="TransportType"> <all> <!-- URI of endpoint --> <element name="uri" type="anyURI" minOccurs="0" /> <!-- Transport-specific metadata for request and response (includes transport headers) --> <element name="request" type="anyType" minOccurs="0"/> <element name="response" type="anyType" minOccurs="0" /> <!-- Indicates one-way (request only) or bi-directional (request/response) communication --> <element name="mode" type="mc:ModeType" minOccurs="0" /> <!-- Specifies the quality of service --> <element name="qualityOfService" type="mc:QoSType" minOccurs="0" /> <!-- Retry values (outbound only) --> <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> <!-- Transport-level client information (inbound only) --> <element name="transportClient" type="mc:SubjectType" minOccurs="0"/> <!-- Message-level client information (inbound only) --> <element name="messageLevelClient" type="mc:SubjectType" minOccurs="0"/> <!-- Boolean flag used to disable outbound WSS processing (outbound only) --> <element name="doOutboundWss" type="boolean" minOccurs="0"/> </all> </complexType> <complexType name="SubjectType"> <sequence> <!-- User name associated with this tranport- or message-level subject --> <element name="username" type="string"/> <element name="principals" minOccurs="0"> <complexType> <sequence> <!-- There is an element for each group this subject belongs to, as determined by the authentication providers --> <element name="group" type="string" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> <!-- =================================================================== --> <complexType name="FaultType"> <all> <!-- A short string identifying the error (e.g. BEA38229) --> <element name="errorCode" type="string"/> <!-- Descriptive text explaining the reason for the error --> <element name="reason" type="string" minOccurs="0" /> <!-- Any additional details about the error --> <element name="details" type="anyType" minOccurs="0" /> <!-- Information about where the error occured in the proxy --> <element name="location" type="mc:LocationType" minOccurs="0" /> </all> </complexType> <complexType name="LocationType"> <all> <!-- Name of the Pipeline/Branch/Route node where error occured --> <element name="node" type="string" minOccurs="0" /> <!-- Name of the Pipeline where error occured (if applicable) --> <element name="pipeline" type="string" minOccurs="0" /> <!-- Name of the Stage where error occured (if applicable) --> <element name="stage" type="string" minOccurs="0" /> <!-- Indicates if error occured from inside an error handler --> <element name="error-handler" type="boolean" minOccurs="0" /> </all> </complexType> <!-- Encapsulates any stack-traces that may be added to a fault <details> --> <element name="stack-trace" type="string"/> </schema>