この章では、ルート、パブリッシュ、サービス・コールアウト、トランスポート・ヘッダー、条件付きアクション、エラー・アクション、メッセージ変換アクションなど、Oracle Service Busコンソールを使用したパイプラインへの異なるタイプのアクションの追加方法について説明します。
アクションとは、パイプラインを流れるメッセージの定義方法を決定するパイプライン・ステージ、エラー・ハンドラ・ステージ、ルート・ノードおよびブランチ・ノードの要素です。
この章の内容は次のとおりです。
アクションとは、プロキシ・サービスを流れるメッセージの定義方法を決定するパイプライン・ステージ、エラー・ハンドラ・ステージ、ルート・ノードおよびブランチ・ノードの要素です。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
また、パイプライン・ステージ、ルート・ノード、およびエラー・ハンドラ・ステージをすでに追加していることも前提としています。参照:
パイプラインにアクションを追加するには:
静的に指定された、メッセージのターゲット・サービスを指定し、メッセージのパッケージおよびサービスへの送信方法を構成するには、パブリッシュ・アクションを使用します。パブリッシュの動作の詳細は「パイプラインでのトランスフォーメーションの実行」を参照してください。
パブリッシュ・アクションを追加するには:
ゼロまたはそれ以上の静的に指定されたサービスにメッセージをパブリッシュするには、パブリッシュ表アクションを使用します。切替え式の条件ロジックを使用して、どのサービスをパブリッシュに使用するか実行時に決定します。
パブリッシュの動作の詳細は「パイプラインでのトランスフォーメーションの実行」を参照してください。
パブリッシュ表アクションを追加するには:
XQuery式によって指定されたサービスに対してメッセージをパブリッシュするには、動的パブリッシュ・アクションを使用します。パブリッシュの動作の詳細は「パイプラインでのトランスフォーメーションの実行」を参照してください。
動的パブリッシュ・アクションを追加するには:
$outbound
のアウトバウンド・リクエストのURI、サービスの品質、モードおよび再試行パラメータの一部またはすべてを変更するには、ルーティング・オプション・アクションを使用します。これらのプロパティは、$outbound
上の割当て、挿入、置換または削除アクションで変更できますが、ルーティング・オプションを使用すると、XPath、XQueryまたは$outbound
コンテキスト変数の構造を理解していなくてもこのタスクを実行できます。
ルーティング・オプションのアクションはコンテキスト変数$outbound
が有効な場合にのみ使用できます。次のアクションに追加できます。
パブリッシュ
動的にパブリッシュ
パブリッシュ表
サービス・コールアウト
ルーティング
動的ルーティング
ルーティング表
ルーティングの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。
ルーティング・オプションのアクションを構成するには
Service Busに登録済のプロキシ・サービスまたはビジネス・サービスの同期(ブロッキング)コールアウトを構成するには、サービス・コールアウト・アクションを使用します。サービス・コールアウト・アクションの詳細は「サービス・コールアウト・メッセージの作成」を参照してください。
サービス・コールアウト・アクションを追加するには:
メッセージのヘッダーの値を設定するには、トランスポート・ヘッダー・アクションを使用します。
トランスポート・ヘッダー・アクションを追加するには:
「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。
該当するアイコンをクリックして、「アクションの追加」→「通信」→「トランスポート・ヘッダー」を選択します。
「のトランスポート・ヘッダーを設定」リストから、次のいずれかを選択して、どのメッセージ・コンテキストの場所を変更するかをランタイムに対して指定します。
「アウトバウンド・リクエスト」 - アウトバウンド・リクエスト(ルート、パブリッシュまたはサービス・コールアウト・アクションでプロキシ・サービスによって送信されるメッセージ)のトランスポート・ヘッダーの値を設定するには、このオプションを選択します。これらのヘッダー要素は、メッセージ・コンテキストの次の場所にあります。
$outbound/ctx:transport/ctx:request/tp:headers
「インバウンド・レスポンス」 - インバウンド・レスポンス(プロキシ・サービスがクライアントに返信するレスポンス・メッセージ)のトランスポート・ヘッダーの値を設定するには、このオプションを選択します。これらのヘッダー要素は、メッセージ・コンテキストの次の場所にあります。
$inbound/ctx:transport/ctx:response/tp:headers
(オプション)すべてのヘッダーをインバウンド・メッセージとアウトバウンド・メッセージとの間でパススルーするには、「パイプラインを介してすべてのヘッダーを渡す」を選択します。ソース・ヘッダー・セットのすべてのヘッダーはターゲット・ヘッダー・セットにコピーされ、ターゲット・ヘッダー・セットの既存の値はすべて上書きされます。
ヘッダー固有のパス・スルー・オプションに関連してこのオプションを使用する方法の詳細は、「パイプラインでのトランスポート・ヘッダーの構成」を参照してください。
追加する各ヘッダーについて、次の手順を行います。
「トランスポート・ヘッダー」表で「ヘッダーの追加」をクリックして、ヘッダーを構成するためのフィールドを表示します。
次のいずれかを実行して、ヘッダーを指定します。
「名前」列のリストから、ヘッダー名を選択します。リストには、事前定義されたすべてのターゲット・トランスポートのヘッダー名が含まれています(たとえば、HTTPトランスポートの場合はContent-Type、JMSトランスポートの場合はJMSCorrelationIDなど)。
「その他」フィールドにヘッダー名を入力します。ヘッダー名がこのサービスのトランスポート用に事前定義されたいずれかのヘッダーでない場合、そのヘッダーはトランスポート仕様の定義のとおりユーザー・ヘッダーになります。
「アクション」列でいずれかのオプションを選択して、ヘッダーの値の設定方法を指定します。
ヘッダーを式に設定
このオプションを選択すると、XQuery式またはXSLT式を使用して、ヘッダーの値を設定できます。「text/xml」などの簡単な式にすることも、複雑なXQuery式またはXSLT式にすることもできます。
Service Busトランスポート・レイヤーでは、すべてのヘッダーのXML表現を文字列値として定義するため、式の結果は、ヘッダーの値が設定される前に文字列に変換されます。何も返さない式のヘッダーの値は、空の文字列に設定されます。式を使用してヘッダーを削除することはできません。
警告:
このアクションで指定できるヘッダー設定がすべて実行時に反映されるわけではありません。設定できる所定のトランスポートのヘッダーおよび実行時に反映されるそれらの設定の詳細は、「パイプラインでのトランスポート・ヘッダーの構成」を参照してください。
ヘッダーの削除
リクエストまたはレスポンスのメタデータからヘッダーが削除されるように指定します。
「インバウンド・リクエストからヘッダーをコピー」(アウトバウンド・リクエストのトランスポート・ヘッダーを設定している場合)
または
「アウトバウンド・レスポンスからヘッダーをコピー」(インバウンド・レスポンスのトランスポート・ヘッダーを設定している場合)
このヘッダーがインバウンド・メッセージの同じ名前を持つ対応するヘッダーからアウトバウンド・メッセージに、またその逆に直接コピーされるように指定します。たとえば、アウトバウンド・リクエストのSOAPActionヘッダーを設定する場合は、「インバウンド・リクエストからヘッダーをコピー」を選択すると、ランタイムが$inbound
のSOAPActionリクエスト・ヘッダーから値をコピーします。インバウンド・レスポンス・ヘッダーの場合、コピーするヘッダーのソースは、$outbound
のレスポンス・ヘッダーです。
ソースに存在しないヘッダーについて「ヘッダーのコピー」オプションが選択された場合、このオプションは無視され、このヘッダーのターゲットではアクションが実行されません。
グローバルな「パイプラインを介してすべてのヘッダーを渡す」オプションに関連してこのオプションを使用する方法の詳細は、「パイプラインでのトランスポート・ヘッダーの構成」を参照してください。
表にヘッダーを追加するには、「ヘッダー」アイコンをクリックし、「ヘッダーの追加」をクリックします。
この表を展開すると、別のトランスポート・ヘッダーの構成に使用できる新しい一連のオプションを含む追加の行が表示されます。この表には、必要な数のヘッダーを追加することができます。ランタイムでは、対応するXMLの生成時に、ネームスペースを宣言し、適切な順序でヘッダー要素を配置するため、表のヘッダーの順序を指定する必要はありません。
「保存」をクリックして、現在のセッションで更新をコミットします。
HTTPパイプラインでは、次の方法でトランスポート・ヘッダーにCookieを設定できます。
複雑なXML式を使用してCookieを設定する(Service Busのデフォルト・フォーマット)には、次の式の構文を使用して、アウトバウンド・リクエストのHTTP Cookieヘッダーの値を構成します。
<cookie-values xmlns="http://www.bea.com/wli/sb/transports/http"> <value>{fn:concat("cookie_name", "=", "cookie_value")}</value> </cookie-values>
XQueryリソースで使用できるルーティング情報に基づいて、メッセージ・ルートを割り当てます。これは終端アクションなので、このアクションの後に別のアクションを追加することはできません。ただし、このアクションには、リクエストとレスポンスのアクションを含めることができます。動的ルーティングの詳細は、「動的ルーティングの使用」を参照してください。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
ルート・ノードに動的ルーティングを追加するには:
そのメッセージのターゲット・サービスを指定し、サービスへのメッセージのルーティング方法を構成します。これは終端アクションなので、このアクションの後に別のアクションを追加することはできません。ただし、このアクションには、リクエストとレスポンスのアクションを含めることができます。ルーティングの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
ルート・ノードにルーティング・アクションを追加するには:
ルーティング表は、切替え式の条件表にラップされた一連のルートです。これは、単一のXQuery式の結果に基づいて各種ルートを選択できる短縮形の構文です。ステージ・エディタで複数のレベルをネストできます。メッセージのターゲット・サービスを指定し、ターゲット・サービスへのメッセージのルーティング方法を構成します。
これは終端アクションなので、このアクションの後に別のアクションを追加することはできません。ただし、このアクションには、リクエストとレスポンスのアクションを含めることができます。ルーティングの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
ルート・ノードにルーティング表を追加するには:
For-Eachアクションは、一連の値を反復処理してアクションのブロックを実行するために使用します。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
For-Eachアクションを追加するには:
XQuery式のブール結果に基づき、1つまたは複数のアクションを条件付きで実行するには、if-thenアクションを使用します。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
If-Thenアクションを追加するには:
指定したエラー・コード(文字列)と説明を使用して例外を発生させるには、エラーを発生させるアクションを使用します。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
エラー生成アクションを追加するには:
呼出し元に即時に返信されるように指定するには、返信アクションを使用します。返信アクションは、リクエスト・パイプライン、レスポンス・パイプライン、またはエラー・パイプラインで使用できます。成功時または失敗時に返信するように構成できます。HTTPインバウンド・トランスポートでの失敗時の返信の場合、返信アクションでは、呼出し元に即時に返信されるように指定します。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
返信アクションを追加するには:
エラー・ハンドラによってエラーが処理された後で、メッセージ・フローを再開するには、再開アクションを使用します。このアクションにパラメータはありません。このアクションはエラー・パイプラインでのみ使用できます。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
再開アクションを追加するには:
完了した後に:
このアクションの構成が完了したら、「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、引き続き他のアクションを構成するか、この構成を保存します。
実行時にこのステージの実行がスキップされて、処理がパイプラインの次のステージに進むように指定するには、スキップ・アクションを使用します。このアクションにはパラメータがなく、リクエスト・パイプライン、レスポンス・パイプライン、エラー・パイプラインで使用できます。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
スキップ・アクションを追加するには:
XQuery式の結果をコンテキスト変数に割り当てるには、割当てアクションを使用します。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
割当てアクションを追加するには:
削除アクションは、コンテキスト変数またはXPath式で指定したすべてのノードを削除するときに使用します。削除アクションは一連の更新アクションの1つです。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
削除アクションを追加するには:
XPath式で選択したノードを基準に、指定した位置にXQuery式を挿入するには、挿入アクションを使用します。挿入アクションは更新アクションの1つです。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
挿入アクションを追加するには:
パイプラインからJavaメソッドまたはEJBビジネス・サービスを呼び出すには、Javaコールアウト・アクションを使用します。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
Javaコールアウト・アクションを追加するには:
JavaScriptアクションを使用して、JavaScript式を使用するXMLまたはJSONペイロードのコンテンツを操作します。
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
MFL (Message Format Language)変換アクションを使用して、メッセージ・パイプライン内でメッセージ・コンテンツをXMLとXML以外の形式との間で変換します。MFLは、バイナリ・データのレイアウトを記述するために使用する特別なXMLドキュメントです。Oracle独自の言語を使用して、フォーマットされたバイナリ・データをXMLデータに、またはXMLデータをバイナリ・データに変換するルールを定義します。「Message Format Languageを使用したデータ構造の定義」を参照してください。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
MFL変換アクションを追加するには:
nXSD変換アクションを使用して、メッセージ・パイプライン内でメッセージ・コンテンツをXMLとネイティブ・フォーマット・データとの間で変換します。変換に使用するネイティブ・スキーマの作成の詳細は、テクノロジ・アダプタの理解のネイティブ・フォーマット・ビルダー・ウィザードに関する項を参照してください。
nXSD変換アクションを使用して、メッセージ・パイプライン内でメッセージ・コンテンツをXMLとネイティブ・フォーマット・データとの間で変換します。変換に使用するネイティブ・スキーマの作成の詳細は、テクノロジ・アダプタの理解のネイティブ・フォーマット・ビルダー・ウィザードに関する項を参照してください。
次の例に示すとおり、関連付けられているXSDリソースに関連する注釈がある場合、nXSD変換アクションでは、XMLからJSON、およびJSONからXMLの変換をサポートしています。
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://example.com/RestService_Operation1_request"
targetNamespace="http://example.com/RestService_Operation1_request" elementFormDefault="qualified"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:version="JSON" nxsd:encoding="US-ASCII">
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="country" type="xsd:string"/>
<xsd:element name="circuit" type="xsd:string"/>
<xsd:element name="date" type="xsd:date"/>
…
nXSD変換アクションはこのバージョンのService Busで拡張されており、JSONからXMLへの変換時にスキーマの順序が適用されます。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
nXSD変換アクションを追加するには:
XPath式で選択された要素のコンテンツを変更せずに要素名を変更するには、名前変更アクションを使用します。名前変更アクションは更新アクションの1つです。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
名前変更アクションを追加するには:
XPath式で指定されたノードまたはノードのコンテンツを置き換えるには、置換アクションを使用します。ノードまたはそのコンテンツは、XQuery式が返した値で置換されます。置換アクションでは、単純な値、要素、属性を置き換えることができます。XQuery式から何も返されない状態は、アクションがノード全体を置き換えるか、ノードコンテンツのみを置き換えるかにより、識別されたノードを削除すること、または空のノードを作成することと同じです。置換アクションは更新アクションのセットの内の1つです。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
置換アクションを追加するには:
XMLスキーマ要素またはWSDLリソースに対して、XPath式で選択した要素を検証するには、検証アクションを使用します。検証できるのは、グローバル要素のみです。Service Busはローカル要素に対する検証に対応していません。実行時にXQuery式の結果に基づいて、XMLスキーマ要素またはWSDLリソースを動的に選択することも選択できます。
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
検証アクションを追加するには:
「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。
該当するアイコンをクリックして、「アクションの追加」→「メッセージ処理」→「検証」を選択します。
「XPath」をクリックします。検証する要素を指定するXPath式を作成します。インラインXQueryおよびXPath式の作成と編集を参照してください。XPath式エディタで式を作成したら、「保存」をクリックして、「ステージ構成の編集」ページで式を挿入します。
変数フィールドに、検証する要素を保持する変数の名前を入力します。
次のいずれかのオプションを選択します。
リソースに対して: 「リソース」リンクをクリックし、「WSDL」または「スキーマ」を選択します。「WSDLブラウザ」または「XMLスキーマ・ブラウザ」から、次の手順を実行します。
WSDLファイルまたはXMLスキーマを選択します。
WSDLファイルまたはXMLスキーマのタイプまたは要素を選択します。
「発行」をクリックします。
式からのリソースに対して: 「式」リンクをクリックします。XQuery式エディタ・ページが表示されます。XQuery式エディタを使用して、WSDLファイルまたはスキーマ・リソースを動的に指定するXQuery式を作成または編集します。インラインXQueryおよびXPath式の作成と編集を参照してください。
次のものは、WSDLリソースの動的な指定の例です。
<validate xmlns="http://www.bea.com/wli/sb/context"> <wsdl>default/MyWSDL</wsdl> <schemaType> <namespaceURI>http://openuri.org</namespaceURI> <localname>MyType</localname> </schemaType> </validate>
次のものは、スキーマ・リソースの動的な指定の例です。
<validate xmlns="http://www.bea.com/wli/sb/context"> <schema>{dvm:lookup('SBProject/dvm/DVM_Validation', 'operation', $operationName, 'validationSchema','default')}</schema> <schemaElement> .........<namespaceURI>"http://www.server.com/date</namespace> <localname>{dvm:lookup('SBProject/dvm/DVM_Validation', 'operation', $operationName, 'validationElement','default')}</localname> </schemaElement> </validate>
選択したスキーマまたはWSDLが、OSBにインポートされているスキーマまたはWSDLリソースであるようにしてください。URLファイルやURLは直接指定できません。必要なXMLフラグメントは、XQuery式で作成され、XMLを作成するためにどのようなXQuery式でも入力できます。前述の例で、示されたXMLはXML定数であり、想定されるXMLを示しています。
たとえば、WSDLの名前は変数になる場合があるため、リソース名を見つけるには、その名前を抽出します。別の例は、1つまたは複数のキーを指定してXMLフラグメントのルックアップを実行できる関数があるXqueryモジュール・リソースが存在する場合です。この場合、検証式で必要なキーを評価し、そのXqueryモジュール関数を呼び出すことができます。これにより、1つのXqueryモジュールとルックアップ・アルゴリズムですべての動的エントリを外部化して管理できます。
この検証の結果(ブール結果)を保存する場合は、検証結果を変数に保存を選択し、結果を保存する変数の名前を入力します。
また、WSDLファイルやXMLスキーマ要素に対する要素の検証が失敗したときにエラーを発生させる場合は、検証の失敗で「エラーの生成」を選択します。
「保存」をクリックして、現在のセッションで更新をコミットします。
アラート宛先にアラートを送信するには、アラート・アクションを使用して、パイプラインのメッセージ・コンテキストに基づいてアラートを生成します。SLAアラートと異なり、アラート・アクションで生成された通知は、主にビジネスでの使用、またはエラーの報告を目的とし、システムの状態を監視するものではありません。このことを考慮して、アラートの宛先を構成および選択する必要があります。アラートの宛先の詳細は、「アラート宛先の操作」を参照してください。
サービスに対してパイプライン・アラートが有効になっていない場合や、ドメイン・レベルでパイプライン・アラートが有効になっていない場合は、メッセージの処理中に、構成したアラート・アクションがバイパスされます。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
アラート・アクションを追加するには:
ログに記録するメッセージを作成し、ログに使用する一連の属性を定義するには、ログ・アクションを使用します。
始める前に
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
注意:
ログ・ファイルまたは標準出力(サーバー・コンソール)にログ・データを表示するには、WebLogic Serverのロギングを次の重大度に設定する必要があります。
ログの最低の重大度: 情報
ログ・ファイル: 情報
標準出力: 情報
ログの重大度の設定の詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のログの重大度の使用に関する項を参照してください。
ログ・アクションを追加するには:
プロキシ・サービスのメッセージ・レポートを有効にするには、レポート・アクションを使用します。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
レポート・アクションを追加するには:
「コンソールでのパイプライン・アクションの追加と編集」の説明に従って、アクションを追加する場所に移動します。
該当するアイコンをクリックして、「アクションの追加」→「レポート」→「レポート」を選択します。
「式」をクリックします。XQuery式エディタ・ページが表示されます。インラインXQueryおよびXPath式の作成と編集を参照してください。XQuery式を使用して、Service Busダッシュボートにレポートされるデータを作成します。
XQuery式を編集したら、「キーの追加」をクリックします。「キー名」フィールドと「キー値」フィールド(XPath式編集用の画面に移動するための「XPath」リンクとコンテキスト変数を入力できる「変数」フィールドを持つ)の2つのフィールドが表示されます。
キー値のペアは、メッセージ・コンテキスト変数やメッセージ・ペイロードからキー識別子を抽出して、残りのメッセージを無視する場合に使用します。キーは、メッセージを識別する便利な手段となります。キーは、「レポート」モジュールでレポート・インデックスとして表示されます。『Oracle Service Busの管理』のメッセージ・レポートの操作に関する項を参照してください。
「キー名」フィールドにキーの名前を入力します。
「XPath」をクリックします。「XPath式の編集。」ページが表示されます。インラインXQueryおよびXPath式の作成と編集を参照してください。
「変数」フィールドにコンテキスト変数を入力します。
さらにキー値を追加するには、「キー」アイコンをクリックして「キーの追加」を選択します。キーを削除するには、「キー」アイコンをクリックして「このキーを削除」を選択します。
たとえば、ステージのエラー・ハンドラで構成されたレポート・アクションを考えてみます。このアクションは、エラーが発生した場合にfault
コンテキスト変数のコンテンツを報告します。レポート・アクションは次のように構成されます。
キー名= errorCode
キー値= ./ctx:errorCode
(変数fault
)
実行時にこのこのアクションが行われるたびに、データ・ストリームを通じてメッセージが報告されます。次の表は、レポート・アクションが2回実行された後の結果を示しています。
レポート・インデックス | DBタイムスタンプ | インバウンド・サービス | エラー・コード |
---|---|---|---|
errorCode=OSB-382505 |
04/26/07 9:45 AM |
MortgageBroker/ProxySvcs/loanGateway3 |
OSB-382505 |
errorCode=OSB-382505 |
04/26/07 9:45 AM |
OSB-382505 |
エラー処理は、メッセージ・フロー、パイプライン、ルート・ノード、およびステージ・レベルで構成できます。「エラー・ハンドラの編集」ページで、エラー・ハンドラを構成します。エラー・ハンドラの動作を指定するには、必ず、少なくとも1つのステージをページに追加する必要があります。
始める前に
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
また、この手順は、「パイプラインへのパイプライン・ペアの追加方法」の説明に従って、パイプライン・ペア・ノードを作成していることも前提としています。
パイプライン・エラー・ハンドラを追加するには:
始める前に
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。この手順は、「コンソールでのパイプラインへのステージの追加方法」の説明に従って、パイプラインにステージを追加していることも前提としています。
ステージ・エラー・ハンドラを追加するには:
始める前に
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
また、この手順は、「コンソールでのパイプラインへのルート・ノードの追加方法」の説明に従って、ルート・ノードを作成していることも前提としています。
ルート・ノード・エラー・ハンドラを追加するには:
始める前に
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
エラー・ハンドラを表示および変更するには:
次のいずれかを行います:
表14-8 エラー・ハンドラの表示と変更
内容 | この手順を完了するには... |
---|---|
パイプラインのエラー・ハンドラの表示および変更 |
「リクエスト・パイプライン」アイコンまたは「レスポンス・パイプライン」アイコンをクリックして、「パイプライン・エラー・ハンドラの編集」をクリックします。「エラー・ハンドラの編集」ページが表示されます。「コンソールでのパイプライン・エラー・ハンドラの追加」を参照してください。 |
ルート・ノードのエラー・ハンドラの表示および変更 |
適切な「ルート・ノード」アイコンをクリックしてから、「ルート・エラー・ハンドラの編集」をクリックします。「エラー・ハンドラの編集」ページが表示されます。「コンソールでのルート・ノード・エラー・ハンドラの追加」を参照してください。 |
ステージのエラー・ハンドラの表示および変更 |
適切な「ステージ」アイコンをクリックしてから、「ステージ・エラー・ハンドラの編集」をクリックします。「エラー・ハンドラの編集」ページが表示されます。「コンソールでのステージ・エラー・ハンドラの追加」を参照してください。 |
パイプライン内のアクションまたはステージを無効化することもできます。無効化されたアクションまたはステージは、パイプラインの実行でスキップされます。アクションまたはステージを無効化した場合、ネストされたアクション(存在する場合)はすべて自動的に無効化されます。無効化されたステージまたはアクションは設計時に検証されません。
注意:
無効化されたステージにエラー・ハンドラがある場合、そのエラー・ハンドラも無効化されます。
無効化されたアクションまたはステージの構成は編集できます。リファクタは、無効化されたアクションおよびステージに対しても実行されます。したがって、無効化されたアクションまたはステージ内のサービスに対するコールがあり、そのサービスの名前が変更されている場合、サービス・コールアウトは自動的に更新されます。
無効化されたステージまたはアクションはいつでも再有効化でき、それによってそのアクションまたはステージはパイプラインでスキップされなくなります。
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
パイプラインでアクションを無効化にするには:
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
パイプラインでアクションを再有効化にするには:
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
パイプラインでステージを無効化するには:
始める前に:
この手順は、「コンソールでのパイプラインの表示と編集」の説明に従って、すでに「メッセージ・フローの編集」ページでパイプラインを編集していることを前提としています。
パイプラインでステージを再有効化にするには: