ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Service Bus管理者ガイド
11gリリース1 (11.1.1.7)
B61436-07
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

39 メッセージ・コンテキスト

この章では、Oracle Service Bus(OSB)メッセージ・コンテキスト・モデルとメッセージ・フローで使用する事前定義されたコンテキスト変数について説明します。

この章の内容は次のとおりです。

39.1 メッセージ・コンテキスト・モデル

メッセージ・コンテキストは、Oracle Service Busでメッセージがルーティングされるときに、メッセージ・コンテキストとメッセージに関する情報を保持する一連のプロパティです。これらのプロパティは、コンテキスト変数と呼ばれます。たとえば、サービス・エンドポイントは、事前定義されたコンテキスト変数によって表されます。Oracle Service Busは、ユーザー定義のコンテキスト変数もサポートします。

メッセージ・コンテキストは、XMLスキーマによって定義されます。通常は、XQuery式を使用して、プロキシ・サービスを定義するメッセージ・フローのコンテキスト変数を操作します。

39.2 事前定義されたコンテキスト変数

表39-1に、事前定義されたコンテキスト変数を示します。事前定義されたコンテキスト変数のタイプは、メッセージ関連の変数、inboundおよびoutbound変数、operation変数、fault変数に分けられます。

メッセージ・コンテキスト変数の要素の型については、39.10項「メッセージ・コンテキスト・スキーマ」を参照してください。

表39-1 Oracle Service Busの事前定義されたコンテキスト変数

コンテキスト変数脚注 1  説明 関連項目

header

SOAPメッセージの場合、headerにはSOAPヘッダーが格納されます。(プロキシ・サービスがSOAP 1.2の場合、headerにはSOAP 1.2 Header要素が格納されます。)

メッセージのタイプがSOAP以外の場合、headerには空のSOAPヘッダー要素が格納されます。

39.3項「メッセージ関連の変数」

body

メッセージ・タイプによって異なります。

  • SOAPメッセージの場合、SOAPエンベロープから抽出した<SOAP:Body>部が格納されます。(プロキシ・サービスがSOAP 1.2の場合、body変数にはSOAP 1.2 Body要素が格納されます。)

  • バイナリ以外の非SOAPメッセージの場合、メッセージ・コンテンツ全体が<SOAP:Body>要素でラップされて格納されます。

  • バイナリ・メッセージの場合、バイナリ・メッセージのメモリー内コピーへの参照が<SOAP:Body>でラップされて格納されます。

  • Javaオブジェクトの場合、Javaオブジェクトのメモリー内コピーへの参照が<SOAP:Body>でラップされて格納されます。

39.3項「メッセージ関連の変数」

attachments

メッセージのMIME添付を格納します。

39.3項「メッセージ関連の変数」

inbound

次のものが含まれます。

  • メッセージを受信したプロキシ・サービスに関する情報。

  • インバウンド・トランスポート・ヘッダー。

39.4項「inbound変数とoutbound変数」

outbound

次のものが含まれます。

  • メッセージの送信先のターゲット・サービスに関する情報。

  • アウトバウンド・トランスポート・ヘッダー。

39.4項「inbound変数とoutbound変数」

operation

プロキシ・サービスで呼び出される操作を指定します。

39.5項「operation変数」

fault

メッセージの処理中に発生したエラーに関する情報を格納します。

39.6項「fault変数」

脚注 1 メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。

39.3 メッセージ関連の変数

メッセージ関連の変数であるheader、body、およびattachmentsは、Oracle Service Busのメッセージ・フローでのメッセージの標準書式を表します。これらの変数は、プロキシ・サービスが受信したメッセージ・コンテンツを使用して初期化され、他のサービスにルーティングまたはパブリッシュされる送信メッセージを作成するために使用されます。

メッセージの処理の一部としてメッセージを変更するには、これらの変数を変更する必要があります。

メッセージ・ペイロード(つまり、ヘッダーや添付を除くメッセージ・コンテンツ)は、body変数に格納されます。送信メッセージに含める変数のコンテンツはOracle Service Busからメッセージがディスパッチ(パブリッシュまたはルーティング)される時点で決定されます

この決定は、ターゲットのエンドポイントがSOAPメッセージを受信するか非SOAPメッセージを受信するかによって異なります。

39.3.1 header変数

header変数には、メッセージに関連付けられているSOAPヘッダーが格納されます。header変数は、下位要素にヘッダーを含む<SOAP:Header>要素を参照します。(プロキシ・サービスがSOAP 1.2の場合、header変数にはSOAP 1.2 Header要素が格納されます。)非SOAPメッセージまたはヘッダーがないSOAPメッセージの場合、<SOAP:Header>要素は空になり、下位要素を持ちません。

39.3.2 body変数

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コンテンツ」を参照してください。

39.3.3 attachments変数

attachments変数には、メッセージに関連付けられた添付が格納されます。attachments変数は、XMLスキーマで定義されます。これは、単一のルート・ノードである<ctx:attachments>と、各添付の<ctx:attachment>下位要素で構成されます。この下位要素には、添付に関する情報(MIMEヘッダーから派生)と添付コンテンツが含まれます。他のメッセージ関連の変数と同様に、attachmentsは常に設定されます。ただし、添付がない場合は、attachments変数は空の<ctx:attachments>要素で構成されます。

各添付要素には、表39-2に示す一連の下位要素が含まれます。

表39-2 attachments変数の下位要素

attachments変数の要素 説明脚注 1 

Content-ID

添付を識別するグローバルに一意の参照。型はstringです。

Content Type

添付のメディアのタイプとサブタイプを指定します。型はstringです。

Content-Transfer-Encoding

添付のエンコード方法を指定します。型はstringです。

Content-Description

コンテンツの説明。型はstringです。

Content-Location

添付を識別するローカルに一意のURIベースの参照。型はstringです。

Content-Disposition

受信者による添付の処理方法を指定します。型はstringです。

body

添付データを保持します。型はanyTypeです。

脚注 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ベースのサービスへの添付ファイルの送信はサポートしていません。

39.3.4 body変数とattachments変数内のバイナリ・コンテンツ

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により逆参照されず、送信メッセージにコンテンツが挿入されません。

39.3.4.1 ビジネス・プロセスへの添付付きSOAPの送信

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—

39.3.5 body変数内のJavaコンテンツ

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オブジェクトはパイプラインのキャッシュから削除されます。

39.3.6 bodyコンテンツのストリーミング

メッセージ・コンテンツを処理する際に、Oracle Service Busパイプラインによってコンテンツをメモリーにロードするのではなく、コンテンツをストリームするように指定できます。プロキシ・サービスのコンテンツ・ストリーミングを有効にするときは、メッセージ処理時の中間手順として、ストリーミングされたコンテンツをメモリーとディスク・ファイルのどちらにバッファリングするかを指定します。これらの一時ファイルの作成は、パフォーマンスに影響を及ぼすことがあります。一時ファイルの保護については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のbodyコンテンツをストリーミングする場合の一時ファイルの保護に関する項を参照してください。

ストリーミング・オプションを有効にした場合、コンテンツ・ストリーミングはbody変数のみに適用されます。

一般に、コンテンツ・ストリーミングを使用するのは次のような場合です。

  • サイズの大きいコンテンツのメッセージを処理する場合。39.3.6.1項「コンテンツ・ストリーミングを使用する際のベスト・プラクティス」のガイドラインを参照してください。

  • Oracle Service Busがペイロードにアクセスする回数が少ない場合。

  • トランスフォーメーションのないコンテンツ・ベースのルーティングの場合。コンテンツ・ストリーミングを使用すると、部分解析の利点が得られるため、パフォーマンスが向上します。

39.3.6.1 コンテンツ・ストリーミングを使用する際のベスト・プラクティス

次のガイドラインと推奨事項に従ってください。

  • サイズの大きいメッセージを処理するためにストリーミングを有効にした場合、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の設定に注意してください。

39.3.7 添付ファイルのストリーミング

メッセージの添付ファイルを処理する際に、添付ファイルをメモリーにバッファリングしてXMLとして解析するのではなく、MIME添付ファイルをディスクにページングしてからコンテンツをストリーミングするように指定できます。サイズの大きい添付ファイルを扱う場合は、この方法が特に効果的です。

この方法を使用すると、ヘッダーのみがバッファリングされ、残りのメッセージ・ペイロードは、小さい複数の部分を同時に読み込むことができるストリームとして公開されます。ストリーミングされた転送により、サイズの大きいメモリー・バッファが不要になるため、サービスのスケーラビリティが向上します。

Oracle Service Busでは、次のトランスポートを使用するプロキシ・サービスおよびビジネス・サービスについて、MIME添付ファイルのストリーミングがサポートされます。

  • HTTP/S

  • ローカル(添付ファイルのストリーミングが有効になっているHTTPプロキシを介して連鎖し、ページングされた添付ファイル設定を継承している場合)

注意: Oracle Service Busは、電子メール、SB、またはWSトランスポートの添付ファイルのストリーミングをサポートしません。

HTTPプロキシ・サービスに対して有効になっている場合、設定はインバウンド・リクエスト・メッセージの処理に適用されます。HTTPビジネス・サービスの場合、設定はアウトバウンド・レスポンス・メッセージの処理に適用されます。アウトバウンド・リクエスト・メッセージをディスパッチすることができる次のアクションは、添付ファイルのストリーミングをサポートします。

  • ルート、動的ルーティング、およびルート表

  • パブリッシュ、動的パブリッシュ、およびパブリッシュ表

ストリーミングが有効になっている場合、バイナリ、テキストまたはXMLのすべての添付ファイルは不透明なデータとして処理されます。つまり、添付ファイルのストリーミングが有効になっている場合、添付ファイルのXMLコンテンツに基づいたXQuery/XPath式を実行することはできません。

39.3.7.1 インバウンド・メッセージの処理

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>
            &lt;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コンテンツを格納するため)またはテキスト・コンテンツの初期化に使用されます。

39.3.7.2 アウトバウンド・メッセージの処理

Oracle Service Busがアウトバウンド・メッセージを処理するとき、添付ファイルをストリーミングするように構成されている場合は、各MIME添付ファイルのコンテンツはディスク上の別々のファイルに保存されます。Oracle Service Busは、インバウンド・リクエストの場合と同様に$attachmentsメッセージ・コンテキスト変数を初期化します(39.3.7.1項「インバウンド・メッセージの処理」を参照してください)。

39.3.8 XOP/MTOMサポートについて

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でサポートされていません。

39.3.8.1 プロキシ・サービスの構成

プロキシ・サービスでXOP/MTOM形式のインバウンド・メッセージをデコードして解析し、必要に応じてXOP/MTOM形式を使用してレスポンスを送信することができます。「XOP/MTOMサポート」が有効になっている場合は、$bodyメッセージ・コンテキスト変数のバイナリ・データを処理する方法を次のオプションからさらに選択します。

「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の保護」に関する項を参照してください。

39.3.8.1.1 参照によるバイナリ・オプションについて

バイナリ・データに直接アクセスする必要がある場合、たとえば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パッケージ・レスポンスを作成します。

39.3.8.1.2 値によるバイナリ・オプションについて

「値によるバイナリ・データを含む」は次の場合に使用します。

  • MTOMとMTOM以外のサービスの間にブリッジを作成する場合。たとえば、MTOM対応でないサービスにルーティングされるリクエストを受信するMTOM対応のプロキシ・サービスについて考えます。このオプションを使用して、XML内のバイナリ・データをBase64エンコード形式で送信するために既存の標準に準拠できます。

  • バイナリ・データの代わりにbase64binary要素の使用を必要とするXMLスキーマに照らしてメッセージのコンテンツを検証する場合。

値によるバイナリ・オプションが選択されている場合は、Oracle Service BusがインバウンドMIMEメッセージのルートを解析してxop:Includeタグの有無をチェックします。該当するタグが検出された場合、対応するMIME部分の本体(バイナリ・データ)はBase64でエンコードされ、結果としてのテキストが$bodyメッセージ・コンテキスト変数のxop:Includeタグを置換します。対照的に、 $attachments メッセージ・コンテキスト変数は情報を含みません(nullです)。

39.3.8.2 ビジネス・サービスの構成

ビジネス・サービスを有効にすると、アウトバウンド・メッセージを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の保護」に関する項を参照してください。

39.3.8.2.1 アウトバウンド・メッセージの処理

ビジネス・サービスで「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ではありません。

39.3.8.3 XOP/MTOM添付ファイルのストリーミング

サービスで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メッセージを生成します。


注意:

最適なパフォーマンスを得るためにはメモリー内の添付ファイルを参照する方法が推奨されるので、メモリー不足のエラーを発生させるようなサイズの大きい添付ファイルを送信する特別な必要性がある場合のみ「添付ファイルのディスクへのページング」オプションを使用します。

39.4 inbound変数とoutbound変数

$inboundコンテキスト変数と$outboundコンテキスト変数には、インバウンド・エンドポイントとアウトバウンド・エンドポイントに関する情報が格納されます。$inbound変数にはリクエスト・メッセージを受信したプロキシ・サービスに関する情報が格納され、$outbound変数にはメッセージの送信先であるターゲット・ビジネス・サービスに関する情報が格納されます。

$outbound変数は、ルート・ノードのルート・アクションとパブリッシュ・アクションで設定されます。$outboundを変更するには、ルート・ノードでリクエスト・アクションとレスポンス・アクションを構成し、パブリッシュ・アクションでリクエスト・アクションを構成します。


注意:

inboundコンテキスト変数およびoutboundコンテキスト変数に行う変更の一部は、実行時に保持されません。つまり、特定のヘッダーおよびメタデータは、Oracle Service Busランタイムによって上書きまたは無視されます。トランスポート・ヘッダーとサービス・コールアウト・アクションを使用してトランスポート・ヘッダーとメタデータを設定する場合、およびテスト・コンソールを使用してプロキシ・サービスとビジネス・サービスをテストする場合にもこの制限は当てはまります。

制限のあるヘッダーとメタデータの詳細は、33.4項「テスト・コンソールでのランタイムによるトランスポート設定の使用方法」を参照してください。ルート・ノードのリクエスト・アクションまたはレスポンス・アクションおよびパブリッシュ・アクション以外でメッセージ・フローの$outboundに行う変更は無視されることにも注意してください。つまりルート・ノードおよびパブリッシュ・アクションで$outboundが初期化される際、、それらの変更は上書きされるということです。

サービス・コールアウト・アクションでoutbound変数を変更することはできません。

inbound変数とoutbound変数の特性は次のとおりです。

HTTP、HTTPSまたは電子メール・トランスポートの場合のみ、添付ファイルがインバウンド・リクエストおよびアウトバウンド・レスポンス(つまりプロキシ・サービスが受信するメッセージ内)でサポートされます。

添付ファイルは、アウトバウンド・リクエストおよびインバウンド・レスポンス(つまりプロキシ・サービスが送信するメッセージ)に関するすべてのトランスポート・タイプでサポートされます。

Oracle Service Busでは、EJB、Tuxedo、またはDSPベースのサービスへの添付ファイルの送信はサポートしていません。

39.4.1 inbound変数とoutbound変数の下位要素

この項では、コンテキスト変数inboundおよびoutboundの下位要素について説明します。また、どの下位要素が実行時に初期化されるかについての情報も示します。コンテキスト変数が初期化される方法については、39.7項「コンテキスト変数の初期化」を参照してください。次の下位要素があります。

39.4.1.1 service

service要素は、inbound、outboundいずれの場合も読取り専用です。下位要素としてはproviderName、operationがあります。

表39-3 service要素の下位要素

下位要素脚注 1  説明

providerName

サービス・キー・プロバイダの名前を指定します。

パブリッシュ・アクションおよびルーティング・アクションの構成に基づいて初期化されます。

operation

(outboundのみ)

outbound変数で使用され、ターゲット・ビジネス・サービスで呼び出される操作の名前を指定します。

inboundおよびoutboundに基づいて初期化されます。

注意: この要素はoutbound変数に対してのみ使用されます。inboundメッセージの場合は、プロキシ・サービスで呼び出される操作の名前がoperation変数によって指定されます。

脚注 1 メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。

39.4.1.2 transport

transport要素はinboundの場合は読取り専用です。ただし例外として、response要素ではこの要素を変更してレスポンス・トランスポート・ヘッダーを設定できます。transport要素の下位要素を表39-4に示します。

表39-4 transport要素の下位要素

下位要素脚注 1  説明

uri

次のようにエンドポイントのURIを指定します。

  • inbound変数で使用する場合、これは、メッセージを受信するURIです。

  • outbound変数で使用する場合、これは、メッセージの送信時に使用するURIです。この値は、サービス・ディレクトリに登録されているURI値をオーバーライドします。

初期化

URI要素は次のように初期化されます。

  • inbound変数の場合は常に初期化されます。

  • outbound変数の場合は初期化されません。outboundに対してURIを設定すると、サービス構成で指定されたURIのセットがオーバーライドされます。この要素を設定した場合、URIフェイルオーバーはサポートされません。

request

inbound変数では、この要素は読取り専用脚注 2 です。outbound変数の場合は変更可能です。

リクエストに関するトランスポート固有のメタデータ(トランスポート・ヘッダーを含む)を指定します。この要素の値は転送プロトコルによって定義されます(具体的には、トランスポートSDKによって定義されたRequestMetaData XML)。したがって、この要素の構造は使用されるトランスポートによって異なります。

この要素のトランスポート固有の型については、Oracle Service Busインストールの次のディレクトリに用意された該当するトランスポート・スキーマを参照してください。

OSB_ORACLE_HOME/lib/transports/

初期化

URI要素は次のように初期化されます。

  • inbound変数の場合は、Oracle Service Busで受信したリクエスト・メッセージの情報を使用して初期化されます。

  • outbound変数の場合は、適切な型のrequest要素が作成されます。使用される型はトランスポートに依存します。request要素は通常は空の要素として初期化されますが、一部の重要なトランスポート・ヘッダー(content-type、SOAPActionなど)については例外です。

ルート・ノードのリクエスト・アクションで$outboundを構成すると、ファイル・トランスポートプロトコルを使用して次のようにアウトバウンド・メッセージのファイル名を設定できます。

  • fileNameのみを指定した場合、その名前のファイルはターゲット・ビジネス・サービスのエンドポイントURIで指定される場所に格納されます。

  • isFilePathをtrueに設定している場合、fileNameの値はターゲット・ビジネス・サービスのエンドポイントURIに追加された相対パスとして使用されます。たとえば、エンドポイントURIがfile:////apollo/ob/dataで、fileNameヘッダーを./myPath/myFile.xmlに設定し、isFilePathをtrueに設定している場合、メッセージは/apollo/ob/data/myPath/myFile.xmlに格納されます。

    その名前のファイルがすでに存在する場合、path/filename_random-number.xmlの形式で新しい名前が生成されます。ここで、random-numberは0から999999の整数です。

response

この要素は、outbound変数の場合は読取り専用です。inbound変数の場合は変更可能です。

レスポンスに関するトランスポート固有のメタデータ(トランスポート・ヘッダーを含む)を指定します。この要素の値は転送プロトコルによって定義されます(具体的には、トランスポートSDKによって定義されたResponseMetaData XML)。したがって、この要素の構造は使用されるトランスポートによって異なります。

この要素のトランスポート固有の型については、Oracle Service Busインストールの次のディレクトリに用意された該当するトランスポート・スキーマを参照してください。

OSB_ORACLE_HOME/lib/transports/

初期化

URI要素は次のように初期化されます。

  • outbound変数の場合は、Oracle Service Busで受信したレスポンス・メッセージの情報を使用して初期化されます。

  • inbound変数の場合は、適切な型のresponse要素が作成されます。使用される型はトランスポートに依存します。response要素は通常は空の要素として初期化されますが、一部の重要なトランスポート・ヘッダー(content-type、SOAPActionなど)については例外です。

標準HTTPヘッダーの説明については、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlを参照してください。

標準JMSヘッダーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』のJMSパブリックAPIの付加価値拡張機能に関する項を参照してください。

注意: MQヘッダーApplOriginData、ApplIdentityData、Accounting TokenにはOracle JMSと同等のものがありません。

mode

通信スタイルがrequest(一方向)であるか、request-response(双方向)であるかを指定します。

初期化

inbound変数、outbound変数のいずれの場合も、サービスおよびそのサービスの操作(該当する場合)の情報を使用して初期化されます。たとえば、リクエストのみの操作が呼び出されるとき、mode要素はrequest-responseではなくrequestに設定されます。

qualityOfService

この要素は、inbound変数の場合は読取り専用です。

outbound(パブリッシュ・アクションまたはルーティング・アクションのアウトバウンド・リクエスト・アクション)の場合は変更可能です。

メッセージ送信時または受信時に使用するサービスの品質を指定します。有効な値はbest-effortとexactly-onceです。

  • best-effortでは、各ディスパッチでそのトランザクション・コンテキストが定義されます(トランスポートがトランザクション対応の場合)。

    ベスト・エフォートでは、信頼性のあるメッセージングも、重複するメッセージの除去もありません。ただし、パフォーマンスは最適化されます。

    パブリッシュ・アクションの結果としてメッセージがディスパッチされるシナリオでは、ディスパッチ・エラーは表示されません。

    ルーティング・ノードからメッセージがディスパッチされるシナリオでは、ディスパッチ・エラー表示されます。

  • exactly-onceでは、ディスパッチはインバウンド・トランザクション・コンテキストの一部として含められます(コンテキストが存在し、アウトバウンド・トランスポートがトランザクション対応の場合)。エラーが発生すると、処理が中止され、関連付けられているエラー・ハンドラがトリガーされます(ルーティング、パブリッシュのいずれの場合も)。

    「必ず1回」の信頼性では、アウトバウンド・メッセージの送信が開始されるまで終了エラーが発生しないことを前提として、メッセージがインバウンドからアウトバウンドに1回のみ配信されます。

初期化

qualityOfService要素は、inbound変数およびoutbound変数で次のように初期化されます。

  • inbound変数の場合、サービス品質(QoS)はトランスポートによって決定されます。たとえば、JMS/XAトランスポートではQoSは「必ず1回」で、HTTPトランスポートでは「ベスト・エフォート」です。

  • outboundの場合、QoSはパブリッシュとルーティングで異なり、次のように設定されます。

    ルーティング - メッセージがルート・ノードから別のサービスにルーティングされる場合、QoSは、インバウンド・コンテキスト変数の値を使用して常に初期化されます。つまり、アウトバウンドのQoSは、インバウンドのQoSが「必ず1回」の場合(のみ)「必ず1回」に設定されます。それ以外の場合、アウトバウンドのQoSは「ベスト・エフォート」に設定されます。

    パブリッシュ - メッセージが、パブリッシュ・アクションの結果として別のサービスにパブリッシュされる場合、サービスの品質(QoS)は、インバウンドの設定に関係なく、「ベスト・エフォート」に常に初期化されます。

retryCount

(outboundのみ)

Oracle Service Busからメッセージを送信するときの再試行回数を指定します。

retryCountが設定されている場合は、ターゲット・サービスの構成に含まれるすべての再試行回数の値がこの設定によりオーバーライドされます。

脚注 1 メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。

脚注 2 この読取り専用ルールは強制されません。読取り専用の要素を変更すると予期できない動作が生じることがあります。

39.4.1.3 security

security要素の下位要素を表39-5に示します。

表39-5 security要素の下位要素

下位要素脚注 1  説明

transportClient

(inboundのみ、読取り専用脚注 2 )

認証されたトランスポート・レベル・ユーザー情報を指定します。ユーザー情報にはユーザー名とオプションのprincipalsが含まれます。principalsには0個以上のgroupを含めて、subjectが属するgroupごとに1つの要素を含めることができます。

注意: subjectが匿名の場合、usernameは"anonymous"で、group要素はありません。

Oracle Service Busによって初期化されます。inboundのtransportClient要素は読取り専用です。

messageLevelClient

(inboundのみ、読取り専用2)

認証されたメッセージ・レベル・ユーザー情報を指定します。ユーザー情報にはユーザー名とオプションのprincipalsが含まれます。principalsには0個以上のgroupを含めて、subjectが属するgroupごとに1つの要素を含めることができます。

注意: subjectが匿名の場合、usernameは"anonymous"で、group要素はありません。

Oracle Service Busによって初期化されます。inboundのmessageLevelClient要素は読取り専用です。

doOutboundWss

outboundのみ)

Oracle Service Busは、ルーティング時またはパブリッシュ時にこの要素の値を設定します。

使用頻度の低いデザイン・パターンには、この値をfalseに設定して、プロキシ・サービスがアウトバウンドWS-Security SOAPエンベロープを自動的に生成しないようにするものもあります。

詳細は、『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 この読取り専用ルールは強制されません。読取り専用の要素を変更すると予期できない動作が生じることがあります。

39.4.2 関連項目

第21章「プロキシ・サービス: アクション」

22.8項「メッセージ・フローへのルート・ノードの追加」

標準HTTPヘッダーの説明については、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlを参照してください。

標準JMSヘッダーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』のWebLogic JMSに関する項を参照してください。

39.5 operation変数

operation変数は、読取り専用の変数です。この変数には、プロキシ・サービスで呼び出される操作を指定する文字列が格納されます。プロキシ・サービスに対する操作が定義されていない場合は、operation変数が設定されず、nullと等価の値が返されます。

Oracle Service Busでは、パフォーマンスを最適化するためにoperation変数がinbound変数の下位要素ではなくスタンドアロン変数として提供されます。処理の計算は、inbound変数がアクセスされたときではなく、operation変数が明示的にアクセスされるまで延期されることがあります。

39.6 fault変数

fault変数は、メッセージ処理中に発生したすべてのエラーに関する情報を保持するために使用します。エラーが発生すると、この変数に情報が格納されてから、適切なエラー・ハンドラが呼び出されます。


注意:

この変数はエラー・ハンドラ・パイプラインでのみ定義され、リクエスト・パイプラインやレスポンス・パイプライン、ルート・ノードやブランチ・ノードでは設定されません。

fault変数には、表39-6に示すerrorCode、reason、detailsおよびlocationの各下位要素が含まれます。

表39-6 fault変数の下位要素

fault変数の要素 説明脚注 1 ...

errorCode

エラー・コードを文字列値で指定します。

reason

エラーの説明を格納します。

details

エラーに関連するユーザー定義XMLコンテンツを格納します。

location

エラーが発生したノード、パイプライン、およびステージを指定します。また、エラーがエラー・ハンドラ内で発生したかどうかも指定します。次の下位要素があります。

  • node - エラーが発生したパイプライン、ブランチ、またはルート・ノードの名前を示す文字列。

  • pipeline - 該当する場合、エラーが発生したパイプラインの名前を示す文字列。

  • stage - 該当する場合、エラーが発生したステージの名前を示す文字列。

  • error-handler - エラー・ハンドラ内でエラーが発生したことを示すブール値。

脚注 1 メッセージ・コンテキスト・スキーマは、メッセージ・コンテキスト変数の要素の型を指定します。

fault変数のコンテンツは、SOAPベースのプロキシ・サービスからの返信時にフォルトを生成しやすいよう、SOAPフォルトに基づいてモデル化されています。Oracle Service Busによって生成されるエラー・コードの値はシステム・エラー・コードに対応し、エラー・コードにはBEA文字列の接頭辞が付加されます。

エラーに関連付けられたエラー・コードは、faultコンテキスト変数の要素内に表示されます。次のXQuery文を使用して値にアクセスできます。

$fault/ctx:errorCode/text()

Oracle Service Busでは、考えられる3つのクラスのエラーに対応する3つの汎用エラー・コードが定義されています。汎用コードの形式はBEA-xxx000です。ここで、xxxは汎用カテゴリを次のように表します。

これにより、次のように汎用コードが生成されます。

Oracle Service Busでは、特定のエラーを示すユニークなコードが定義されています。例:

BEA-382030 - メッセージ解析エラーを示します(SOAPプロキシ・サービスが非SOAPメッセージを受信したなど)。

BEA-382500 - サービス・コールアウト・アクションがSOAPフォルト・レスポンスを受信した場合に備えて予約されています。

これらのエラー・コードおよびその他の特定のエラー・コードについては、付録A「エラー・コード」を参照してください。また、37.7項「メッセージ・フローでのエラー処理」も参照してください。

39.7 コンテキスト変数の初期化

メッセージ・コンテキストとその変数は、メッセージ受信時およびメッセージ処理の開始前にバインディング・レイヤーで初期化されます。コンテキスト変数を初期化する方法を表39-7に示します。

表39-7 コンテキスト変数の初期化

コンテキスト変数 初期化方法

fault

ルーティングが行われていないか、エラーが発生していないため、nullに初期化されます。

outbound

ルート・ノードのルート・アクションとパブリッシュ・アクションで初期化されます。ルーティング・ノードのリクエスト・アクションとパブリッシュ・アクションで(さらに、ルーティング・ノードのレスポンス・アクションでも)$outboundを変更できます。詳細は、39.4項「inbound変数とoutbound変数」を参照してください。

outboundの下位要素の初期化については、39.4.1項「inbound変数とoutbound変数の下位要素」を参照してください。

inbound

登録されたプロキシ・サービスに関するService Busメタデータと、特定の受信リクエストに関するトランスポート・レベル・メタデータ(トランスポート・ヘッダー、認証されたユーザー情報など)から取得したサービス、トランスポート、およびセキュリティの情報で初期化されます。

inboundの下位要素の初期化については、39.4.1項「inbound変数とoutbound変数の下位要素」を参照してください。

header

body

attachments

operation

インバウンド・メッセージのコンテンツを使用して初期化されます。初期化の実行方法は、この項の以降のトピックで説明するようにプロキシ・サービスのタイプによって異なります。

header、body、attachmentsの3つの変数は、ルーティングの後に、受信したレスポンスのコンテンツを使用して再初期化されます。ルーティングが実行されない場合や、通信モードがリクエストのみの場合、これらの変数は再初期化されません。つまり、これらの変数のコンテンツはクリアされません。

39.7.1 attachmentsコンテキスト変数の初期化

attachmentsコンテキスト変数は、メッセージに含まれるすべてのMIME添付ファイルで初期化されますが、メイン・メッセージを表す部分は含まれません(SOAP、XML、MFLなど形式を問わず)。各<attachment>要素は、MIMEパッケージの各部分に伴うMIMEヘッダーを使用して初期化されます。

<attachment>の<body>要素のコンテンツは、添付のContent-Typeに応じて次のいずれかになります。

39.7.2 header、bodyコンテキスト変数の初期化

この項では、コンテキスト変数headerおよびbodyの初期化方法について説明しますが、これらの変数の初期化方法は、プロキシ・サービスのタイプが39.9.1項「SOAPサービス」、39.9.2項「XMLサービス(非SOAP)」、39.9.3項「メッセージング・サービス」のいずれであるかによって異なります。

39.7.2.1 SOAPサービス

SOAPベースのサービスへのメッセージは、<soap:Envelope>要素に含まれるXMLを含むSOAPメッセージです。添付を含むメッセージの場合、インバウンド・メッセージのコンテンツは、SOAPエンベロープをその一部として(通常は最初の部分、または最上位のContent-Typeヘッダーで指定される部分)含むMIMEパッケージです。コンテキスト変数は次のように初期化されます。

  • header - SOAPメッセージの<soap:Header>要素で初期化されます。

  • body - SOAPメッセージの<soap:Body>要素で初期化されます。

39.7.2.2 XMLサービス(非SOAP)

XMLベースのサービスへのメッセージはXMLですが、プロキシ・サービス構成で許可された型を使用できます。添付を含むメッセージの場合、インバウンド・メッセージのコンテンツは、プライマリXMLペイロードをその一部として(通常は最初の部分、または最上位のContent-Typeヘッダーで指定される部分)含むMIMEパッケージです。

コンテキスト変数は次のように初期化されます。

  • header - 空の<soap:Header/>要素で初期化されます。

  • body - XMLペイロード全体をラップする<soap:Body>要素で初期化されます。

39.7.2.3 メッセージング・サービス

メッセージング・サービスは、あるデータ型のメッセージを受信し、応答として別のデータ型のメッセージを返すことができるサービスです。サポートされるデータ型は、XML、MFL、テキスト、または型なしバイナリです。コンテキスト変数は次のように初期化されます。

  • header - 空の<soap:Header/>要素で初期化されます。

  • body - ペイロード全体をラップする<soap:Body>要素で初期化されます。

    • XML、MFL、およびテキスト・コンテンツの場合は、<soap:Body>要素内に直接挿入されます。

    • バイナリ・コンテンツの場合は、参照XMLコードが作成され<soap:Body>要素内に挿入されます(39.3.4項「body変数とattachments変数内のバイナリ・コンテンツ」を参照)。バイナリ・コンテンツに対してアクセスまたは変更を行うことはできませんが、参照XMLを検証および変更し、インライン・コンテンツと置き換えることができます。

39.8 コンテキスト変数に対する操作の実行

メッセージ・コンテキストに対する対話および操作は、プロキシ・サービスを定義するパイプライン、ブランチ、またはルート・ノードでのアクションを通じて行います。ほとんどのアクションについては、それを実行するためのXQuery言語が公開されています。各コンテキスト変数は、同じ名前のXQuery変数として表されます。たとえば、header変数は、XQueryでは$headerとしてアクセスでき、body変数は$bodyとしてアクセスできます。この項の例では、XQueryを使用してコンテキスト変数に対するチェックおよび操作を行っています。

39.8.1 $body

$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項「サービス・コールアウト・アクションの追加」を参照してください。

39.8.2 $header

$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/*

39.8.3 関連項目

XQueryエディタおよびXPathエディタを使用したコンテキスト変数の処理の詳細は、次を参照してください。

39.9 ディスパッチするメッセージの作成

Oracle Service Busによってメッセージがパブリッシュまたはルーティングされるときに、メッセージ・コンテキストの変数の値を使用してメッセージのコンテンツが作成されます。たとえば、トランスポート・ヘッダーとトランスポート固有のメタデータは、$outbound/transport/requestから取得されます。コンテキストの初期化と同様に、アウトバウンド・メッセージのメッセージ・コンテンツはターゲット・サービスのタイプに応じて異なって処理されます。次のトピックで説明されているように、アウトバウンド・メッセージ・コンテンツの作成方法はターゲット・サービスのタイプによって異なります。

39.9.1 SOAPサービス

送信SOAPメッセージは、header変数とbody変数のコンテンツを<soap:Envelope>要素でラップして作成します。呼び出されたサービスがSOAP 1.2サービスの場合、作成されるエンベロープはSOAP 1.2エンベロープです。呼び出されたサービスがSOAP 1.1サービスの場合、作成されるエンベロープはSOAP 1.1エンベロープです。body変数に参照XMLコードが格納されている場合、メッセージは現状のまま送信されます。つまり、参照されているコンテンツはメッセージに追加されません。

attachments変数で添付が定義されている場合は、メイン・メッセージと添付データからMIMEパッケージが作成されます。各添付部分のコンテンツの処理方法は、メッセージング・サービスのコンテンツの処理方法に類似しています。

39.9.2 XMLサービス(非SOAP)

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章「プロキシ・サービス: アクション」を参照してください。

39.9.3 メッセージング・サービス

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章「プロキシ・サービス: アクション」を参照してください。

39.9.3.1 電子メール・メッセージでのバイナリ・コンテンツの送信について

バイナリ・メッセージの場合、Oracle Service Busではbody変数にメッセージ・コンテンツは挿入されません。かわりに、<binary-content/>参照要素が作成され<SOAP:Body>要素に挿入されます(39.3項「メッセージ関連の変数」を参照)。ただし、電子メール規格では、バイナリ・コンテンツ・タイプをメッセージの主要な部分として送信することがサポートされていません。テキストまたはXMLのドキュメントと任意の添付を受信するメッセージング・サービスに、電子メールでバイナリ・メッセージを送信する場合は、次の手順に従います。

  1. バイナリ・コンテンツ参照XMLを$bodyから$attachmentsに変更します。

  2. $bodyのコンテンツを<SOAP:Body>要素でラップされたテキストまたはXMLに置き換えます。

送信メッセージのタイプがMFLの場合は、$bodyのコンテンツが、MFLトランスフォーメーションに基づいてXMLからテキストまたはバイナリに変換されます。

  • ターゲット・サービスでテキスト・メッセージを受信する場合は、$outboundでcontent-type(MFLメッセージ・タイプのデフォルトはバイナリ)をtext/plainとして設定できます。

  • ターゲット・サービスでバイナリ・メッセージを受信する場合は、電子メール・トランスポートでMFLコンテンツを送信することはできません。

バイナリ・コンテンツの処理方法については、39.3.4項「body変数とattachments変数内のバイナリ・コンテンツ」を参照してください。

39.9.4 関連項目

39.10項「メッセージ・コンテキスト・スキーマ」

21.6項「サービス・コールアウト・アクションの追加」

21.7項「トランスポート・ヘッダー・アクションの追加」

22.8項「メッセージ・フローへのルート・ノードの追加」

39.10 メッセージ・コンテキスト・スキーマ

メッセージ・コンテキスト変数の型を指定するメッセージ・コンテキスト・スキーマ(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>

39.10.1 関連項目

39.4項「inbound変数とoutbound変数」

39.8項「コンテキスト変数に対する操作の実行」

39.9項「ディスパッチするメッセージの作成」

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次