Console オンラインヘルプ

プロキシサービス

この節の内容は以下のとおりです。

プロキシサービスの概要

この節の内容は以下のとおりです。

プロキシサービスとは、WebLogic Server 上にローカルに実装される Web サービスの AquaLogic Service Bus 定義です。プロキシサービスは、WSDL、パイプライン、ポリシーの観点で定義します。プロキシサービスでセキュリティ資格が必要な場合は、そのセキュリティ資格を管理するプロキシサービスプロバイダを AquaLogic Service Bus Console で作成できます。プロキシサービスプロバイダのコンフィグレーション方法については、「プロキシサービスプロバイダの追加」を参照してください。HTTP/S プロキシサービスのアクセス制御ポリシーをコンフィグレーションすることができます。詳細については、「アクセス制御ポリシーの表示と検索」を参照してください。

プロキシサービスは、メッセージフローをコンフィグレーションすることで実装します。メッセージフローには、パイプラインペア、および開始ノード、ルートノード、エコーノード、ブランチノードを入れることができます。詳細については、「メッセージフローの概要」および「メッセージフローの表示と変更」を参照してください。

以下の表は [プロジェクトエクスプローラ] モジュールと [リソースブラウザ] モジュールでアクセスできるページをまとめたものです。各ページに関連するタスクとヘルプトピックを確認できます。

表 14-1 [プロジェクトエクスプローラ] モジュールおよび [リソースブラウザ] モジュールからアクセスするページ

ページ	関連タスク	ヘルプトピック
プロキシサービスの概要	プロキシサービスのリストの表示。サービス名とアラートが表示される。	プロキシサービスの表示と検索
	リストのフィルタ	プロキシサービスの表示と検索
	プロキシサービスの削除	プロキシサービスの削除
プロキシサービスの編集	プロキシサービスの追加	プロキシサービスの追加
プロキシサービスの詳細	特定のプロキシサービスの詳細の表示と編集	プロキシサービスの表示と変更
メッセージフローの編集	メッセージフローの表示	メッセージフローの表示と変更
	メッセージフローの変更	メッセージフローの表示と変更
	パイプラインペアノードの追加	パイプラインペアノードの追加
	条件付きブランチノードの追加	条件付きブランチノードの追加
	オペレーションブランチノードの追加	オペレーションブランチノードの追加
	ルートノードの追加	ルートノードの追加
	ステージの追加	ステージの追加
ブランチノードの編集	ブランチの詳細の変更とブランチ定義の追加	条件付きブランチの詳細の表示と変更
ステージコンフィグレーションの編集	アクションの追加	アクションの追加
エラーハンドラの編集	プロキシサービスに関するエラーハンドラの追加	プロキシサービスへのエラー処理の追加
	パイプラインエラーハンドラの追加	パイプラインへのエラー処理の追加
	ステージエラーハンドラの追加	ステージへのエラー処理の追加
	ルートノードへのエラーハンドラの追加	ルートノードへのエラー処理の追加
XQuery 式の編集	XQuery 式の編集	XQuery 式の編集
XQuery 条件の編集	XQuery 条件の編集	XQuery 条件の編集
XPath 式の編集	XPath 式の編集	XPath 式の編集
新しいメッセージコンテキスト変数の定義	新しいコンテキスト変数の定義	新しいメッセージコンテキスト変数の定義

サービスの種類

サービスの種類は、それぞれ同じパターンに従って作成されます。サービスの種類のコンフィグレーションは、共通の部分とサービスの種類固有の部分で構成されます。

共通のコンフィグレーションは、以下のプロパティで構成されます。

表 14-2 サービスの種類のコンフィグレーション

プロパティ	説明
リソース定義	リソース定義は、以下のもので構成される。サービス名 (プロジェクト名、パス名、およびローカル名) サービスの説明 (省略可能) サービスの種類 (読み込み専用)
全般的なコンフィグレーション	このコンフィグレーションは、以下のもので構成される。プロキシサービスのサービスプロバイダ注意 : サービスプロバイダが必要になるのは、クライアント証明書認証を必要とする HTTPS サービスに対してプロキシサービスからメッセージをルーティングする場合、または一部のメッセージレベルのセキュリティシナリオに限られる。
転送コンフィグレーション	各プロキシサービスに以下のパラメータをコンフィグレーションできる。 [エンドポイント URI] - 文字列。 `/proxy1` または `jms://localhost:7001/QueueConnectionFactory/DestName` など (必須)。 JMS 送り先として複数のサーバを指定するには、次の URI 形式を使用する。 `jms://host1:port,host2:port/QueueConnectionFactory/DestName` [すべてのヘッダを取得] - ブール型の値で、デフォルト値は [はい]。ユーザ指定のヘッダ - ヘッダ名の文字列のリスト。[すべてのヘッダを取得] オプションで [いいえ] を選択した場合にのみ適用可能。選択する転送方式は、バインディング定義により必要とされる転送モード (要求/応答、一方向、または両方) をサポートする必要があり、それに従ってコンフィグレーションする。両方のモードでメッセージを交換するサービスでは、バインディングレイヤをコンフィグレーションし、場合に応じて転送モードを選択できるようにする必要がある (要求/応答を 2 つの非同期呼び出しとして実装する、JMS などのすべての転送用)。サービスが具象型である場合、この選択は、バインディング定義の記述に従って自動的に行われる。サービスが具象型でない場合、バインディングレイヤをコンフィグレーションするには、`$outbound` 変数でモードを設定する必要がある。転送方式と WSDL に基づいて、転送モードが自動的に選択されるが、`$inbound` や `$outbound` で上書きできる。

プロパティ

説明

リソース定義

リソース定義は、以下のもので構成される。

サービス名 (プロジェクト名、パス名、およびローカル名)

サービスの説明 (省略可能)

サービスの種類 (読み込み専用)

全般的なコンフィグレーション

このコンフィグレーションは、以下のもので構成される。

プロキシサービスのサービスプロバイダ

注意 : サービスプロバイダが必要になるのは、クライアント証明書認証を必要とする HTTPS サービスに対してプロキシサービスからメッセージをルーティングする場合、または一部のメッセージレベルのセキュリティシナリオに限られる。

転送コンフィグレーション

各プロキシサービスに以下のパラメータをコンフィグレーションできる。

[エンドポイント URI] - 文字列。
/proxy1
または
jms://localhost:7001/QueueConnectionFactory/DestName など (必須)。

JMS 送り先として複数のサーバを指定するには、次の URI 形式を使用する。
jms://host1:port,host2:port/QueueConnectionFactory/DestName

[すべてのヘッダを取得] - ブール型の値で、デフォルト値は [はい]。

ユーザ指定のヘッダ - ヘッダ名の文字列のリスト。[すべてのヘッダを取得] オプションで [いいえ] を選択した場合にのみ適用可能。

選択する転送方式は、バインディング定義により必要とされる転送モード (要求/応答、一方向、または両方) をサポートする必要があり、それに従ってコンフィグレーションする。

両方のモードでメッセージを交換するサービスでは、バインディングレイヤをコンフィグレーションし、場合に応じて転送モードを選択できるようにする必要がある (要求/応答を 2 つの非同期呼び出しとして実装する、JMS などのすべての転送用)。サービスが具象型である場合、この選択は、バインディング定義の記述に従って自動的に行われる。サービスが具象型でない場合、バインディングレイヤをコンフィグレーションするには、$outbound 変数でモードを設定する必要がある。

転送方式と WSDL に基づいて、転送モードが自動的に選択されるが、$inbound や $outbound で上書きできる。

各サービスの種類では、以下のコンフィグレーションを定義する必要があります。

バインディング定義
実行時コンフィグレーション
実行時変数 ($operation、$body、$header、$attachments)

表 14-3 サービスの種類のコンフィグレーション

プロパティ	説明
WSDL ポート	既存の WSDL リソースを基にして SOAP および XML サービスを構築できる。プロキシサービスとビジネスサービスの任意の転送に WSDL ドキュメントを使用できる。この WSDL は、最終的な WSDL ドキュメントのベースとして使用される。 WSDL では、WSDL ポートまたは WSDL バインディングのみが定義可能であるため、WSDL を基にしてビジネスサービスまたはプロキシサービスを作成するときには、これらのエンティティのいずれかのみを選択できる。WSDL ポートは、実際の転送アドレスを表す。WSDL ポートは、具象インタフェースに使用する。 WSDL ポートの定義については、http://www.w3.org/TR/wsdl#_ports を参照。 AquaLogic Service Bus では、WSDL バインディングに基づいてプロキシサービスを作成すると、そのプロキシサービス用に生成された WSDL に新しいサービスとポートの定義が設定される。WSDL ポートと WSDL バインディングのどちらに基づいてプロキシサービスを定義するかに関わらず、そのプロキシサービス用として生成された WSDL で定義されるポートは 1 つだけである。テンプレート WSDL でポート X からサービスが生成される場合、生成される WSDL でもポート X が定義される。テンプレート WSDL で定義された他のすべてのポートは、生成される WSDL には含まれない。さらに、WSDL ポートに基づいてプロキシサービスを作成する場合、生成される WSDL ではそのポート名が使用され、そのポートに関連付けられたすべての WS-Policy が保持される。バインディングはポートから決定され、ポートの種類はバインディングから決定される。サービスがテンプレート WSDL のバインディング Y から生成される場合、生成される WSDL によって新しいサービスとポートが定義される (<service-name>QSService および <port-name>QSPort)。テンプレート WSDL で定義されたどのポートも、生成される WSDL には含まれない。 WSDL バインディングテンプレートに基づいてサービスを作成する場合、その WSDL には、使用したバインディングに関連付けられた複数のポートが存在する場合がある。各ポートには異なる URL を使用でき、異なる WS-Policy を付加できる。したがって、生成される WSDL は、そのバインディングを使用するが、そのバインディング用に WS-Policy のない人為的なポートを生成する。すべての WSDL ベースサービスでは、サービス定義の転送セクションで転送の種類と転送 URL を上書きできる。注意 : サービスの URL に ?WSDL を追加したものをブラウザのアドレスフィールドに入力することで、HTTP(S) ベースのプロキシサービスの WSDL を取得できる。
WSDL バインディング	既存の WSDL リソースを基にして SOAP および XML サービスを構築できる。プロキシサービスとビジネスサービスの任意の転送に WSDL ドキュメントを使用できる。この WSDL は、最終的な WSDL ドキュメントのベースとして使用される。 WSDL では、WSDL ポートまたは WSDL バインディングのみが定義可能であるため、WSDL を基にしてビジネスサービスまたはプロキシサービスを作成するときには、これらのエンティティのいずれかのみを選択できる。WSDL バインディングは、インタフェースの構造とパッケージ化の方法を表す。WSDL バインディングは、転送アドレスのマップに使用する。 WSDL バインディングの定義については、http://www.w3.org/TR/wsdl#_bindings を参照。サービスの転送プロトコルを互換性のある別のプロトコルに変更できる。サービスによって参照される `<wsdl:binding>` の `<soap:binding>` 要素の転送属性に、選択された転送の値が反映される必要がある。 SOAP サービスの場合は、既存の `<wsdl:service>` 定義があればそれが削除され、単一の `<wsdl:port>` を持つ新しい定義が作成される。この `<wsdl:port>` は、サービスで参照される `<wsdl:binding>` に基づいてコンフィグレーションされ、SOAP アドレスにはサービスのアドレス (転送によって定義されたもの) が格納される。 XML サービスの場合、使用可能な標準の WSDL バインディング定義は、HTTP 用に定義されたものだけである。ただし、BEA は JMS 用に独自の標準定義を追加している。したがって、JMS 転送プロトコルの場合を除き、標準の HTTP バインディングが使用される。 SOAP の場合は、既存の `<wsdl:service>` がすべて削除され、サービスのアドレスを反映した新しいものが作成される。HTTP および JMS (一方向) のみが標準としてサポートされていることから、`<wsdl:service>` を他のコンフィグレーション用に生成することはない。
任意の SOAP サービス	バインディング定義 : このサービスの種類で定義する情報は、WSDL バインディング定義とは無関係に、サービスで SOAP メッセージを受信するか送信するかのみである。したがって、この種類のバインディングコンフィグレーションは空になる。また、バインディングコンフィグレーションが存在しないため、この種類ではメッセージのコンテンツタイプとの組み合わせで、メッセージに添付ファイルがあるかどうかを十分判別できる。定義上、どのサービス (SOAP または XML) も WSDL 定義を持たない。これらのサービスの WSDL ドキュメントを要求することはできない。実行時変数 : `$body` 変数および `$header` 変数に、受信 SOAP メッセージの `<soap:Body>` および `<soap:Header>` がそれぞれ格納される。 SOAP メッセージに添付ファイルがあれば、`$attachments` 変数に格納される。ポートの種類を定義しないため、`$operation` 変数はこのサービスの種類には使用されない。メッセージコンテキスト変数の詳細については、「メッセージ関連の変数」および「送信するメッセージの作成」を参照。
任意の XML サービス	バインディング定義 : このサービスの種類で定義する情報は、WSDL バインディング定義とは無関係に、サービスで XML メッセージを受信するか送信するかのみである。したがって、この種類のバインディングコンフィグレーションは空になる。また、バインディングコンフィグレーションが存在しないため、この種類ではメッセージのコンテンツタイプとの組み合わせで、メッセージに添付ファイルがあるかどうかを十分判別できる。定義上、どのサービス (SOAP または XML) も WSDL 定義を持たない。これらのサービスの WSDL ドキュメントを要求することはできない。実行時変数 : `$body` 変数内の `<soap:Body>` 要素内に受信 XML メッセージがラップされて格納される。メッセージに添付ファイルがあれば、`$attachments` 変数に格納される。 `$header` 変数はこのサービスの種類には使用されず、デフォルト値に設定される。ポートの種類を定義しないため、`$operation` 変数はこのサービスの種類には使用されない。メッセージコンテキスト変数の詳細については、「メッセージ関連の変数」および「送信するメッセージの作成」を参照。
メッセージングサービス	バインディング定義 : メッセージングサービス用のバインディング定義は、交換されるメッセージのコンテンツタイプのコンフィグレーションで構成される。応答のコンテンツタイプは、要求のコンテンツタイプと同じである必要はない。そのため、応答は個別にコンフィグレーションされる (たとえば、サービスで MFL メッセージを受信し、XML の受信確認を返すことも可能)。定義上、メッセージベースのサービスには WSDL 定義は存在しない。これらのサービスの WSDL ドキュメントを要求することはできない。要求 (および応答) のコンテンツタイプは、以下の 4 つから選択できる。バイナリテキスト XML MFL 実行時変数 : このサービスの種類はメッセージベースである。Web サービスには複数の「処理」という概念はない。したがって、`$operation` 変数は空のままになる。 `$body` 変数内の `<soap:Body>` 要素内に受信メッセージがラップされて格納される。 `$header` 変数はこのサービスの種類では使用されず、デフォルト値に設定される。メッセージに添付ファイルがあれば、`$attachments` 変数に格納される。メッセージコンテキスト変数の詳細については、「メッセージ関連の変数」および「送信するメッセージの作成」を参照。

サービスの種類と転送方式

AquaLogic Service Bus では、以下の種類のサービスの種類と転送方式をサポートしています。

表 14-4 AquaLogic Service Bus でサポートされるサービスの種類と転送方式

サービスの種類	転送プロトコル
SOAP または XML WSDL	JMS¹ HTTP(S)
SOAP (WSDL なし)	JMS HTTP(S)
XML (WSDL なし)²	HTTP(S) JMS 電子メールファイル FTP
メッセージの種類 (バイナリ、テキスト、MFL、XML)	HTTP(S) JMS 電子メールファイル FTP

1. WS-Security が有効になっている場合、JMS 要求と JMS 応答はサポートされません。
2. HTTP GET は、WSDL がない XML でのみサポートされます。

プロキシサービスの追加

[プロキシサービスの編集 - 全般的なコンフィグレーション] ページでは、プロキシサービスを追加できます。

プロキシサービスとは、WebLogic Server 上にローカルに実装される Web サービスの AquaLogic Service Bus 定義です。プロキシサービスは、WSDL、パイプライン、ポリシーの観点で定義します。詳細については、「プロキシサービスの概要」を参照してください。

プロキシサービスを追加するには、まずサービスの全般的な情報をコンフィグレーションしたうえで、そのサービスについて、一般の転送情報とプロトコルに依存する転送情報をコンフィグレーションし、さらに、サービスに処理が含まれる場合は、サービスの処理選択アルゴリズムをコンフィグレーションする必要があります。これがメッセージングサービスである場合は、メッセージの種類もコンフィグレーションする必要があります。コンフィグレーションはプロキシサービスを作成する前に確認できます。

この手順には以下のタスクが含まれます。

プロキシサービスを追加するには - 全般的なコンフィグレーション

まだセッションを作成していない場合は、左側のナビゲーションペインで、[Change Center] の下にある [作成] をクリックして、現在のコンフィグレーションに変更を加えるための新しいセッションを作成します。詳細については、「Change Center の使用」を参照してください。

左側のナビゲーションペインで、[プロジェクトエクスプローラ] を選択します。プロジェクトビュー ページが表示されます。

プロキシサービスの追加先となるプロジェクトを選択します。プロキシサービスは直接プロジェクトに追加することも、選択したフォルダに対して追加することもできます。

注意 : フォルダを選択するには、フォルダ名をクリックします。フォルダビュー ページが表示されます。

プロジェクトビュー ページまたはフォルダビュー ページの [リソースの作成] フィールドで、[プロキシサービス] を選択します。[プロキシサービスの編集 - 全般的なコンフィグレーション] ページが表示されます。

[サービス名] フィールドにユニークなプロキシサービス名を入力します。

[サービスの種類] フィールドで、以下のいずれか 1 つを実行します。

注意 : サービスの種類により、そのサービスで交換されるメッセージの種類とパッケージ化が決定されます。このフィールドは必須です。

表 14-5 [サービスの種類] フィールド

処理	手順
WSDL ポートからのサービスの作成	1. [新しいサービスの作成] の下にある [WSDL ポート] を選択する。 2. [参照] をクリックする。[WSDL ブラウザ] が表示される。 3. [WSDL ブラウザ] で、WSDL リソースを選択してから、[WSDL 定義] ペインでポートを選択する。 4. [送信] をクリックしてダイアログボックスを閉じ、全般的なコンフィグレーションページに戻る。注意 : WSDL では、WSDL ポートまたは WSDL バインディングのみが定義可能であるため、WSDL を基にしてビジネスサービスまたはプロキシサービスを作成するときには、これらのエンティティのいずれかのみを選択できる。WSDL ポートは、実際の転送アドレスを表す。WSDL ポートは、具象インタフェースに使用する。このサービスの種類の詳細については、「プロキシサービスの概要」の「サービスの種類」と「サービスの種類と転送方式」を参照。また、このトピックにある「プロキシサービスからの WSDL の生成」も参照。
WSDL バインディングからのサービスの作成	1. [新しいサービスの作成] の下にある [WSDL バインディング] を選択する。 2. [参照] をクリックする。[WSDL ブラウザ] が表示される。 3. [WSDL ブラウザ] で、WSDL リソースを選択してから、[WSDL 定義] ペインでバインディングを選択する。 4. [送信] をクリックしてダイアログボックスを閉じ、全般的なコンフィグレーションページに戻る。注意 : WSDL では、WSDL ポートまたは WSDL バインディングのみが定義可能であるため、WSDL を基にしてビジネスサービスまたはプロキシサービスを作成するときには、これらのエンティティのいずれかのみを選択できる。WSDL バインディングは、インタフェースの構造とパッケージ化の方法を表す。WSDL バインディングは、転送アドレスのマップに使用する。このサービスの種類の詳細については、「プロキシサービスの概要」の「サービスの種類」と「サービスの種類と転送方式」を参照。また、このトピックにある「プロキシサービスからの WSDL の生成」も参照。
メッセージングサービスの作成	あるデータ型のメッセージを受信し、別のデータ型のメッセージで応答できるサービスを作成するには、[メッセージングサービス] を選択する。このようなメッセージ交換は、要求/応答または一方向にすることができる。Web サービスとは異なり、要求と応答のコンテンツタイプは同じでなくてもかまわない。このサービスの種類の詳細については、「プロキシサービスの概要」の「サービスの種類」と「サービスの種類と転送方式」を参照。
明示的に定義された具象インタフェースを持たない SOAP サービスの作成	明示的に定義された具象インタフェースを持たない SOAP サービスを作成するには、[任意の SOAP サービス] を選択する。このサービスの種類の詳細については、「プロキシサービスの概要」の「サービスの種類」と「サービスの種類と転送方式」を参照。
明示的に定義された具象インタフェースを持たない XML サービスの作成	明示的に定義された具象インタフェースを持たない XML サービスを作成するには、[任意の XML サービス] を選択する。注意 : HTTP GET に対応しているサービスの種類は、[任意の XML サービス] のみ。このサービスの種類の詳細については、「プロキシサービスの概要」の「サービスの種類」と「サービスの種類と転送方式」を参照。
既存のビジネスサービスからのプロキシサービスの作成	1. [既存のサービスから作成] の下にある [ビジネスサービス] を選択する。 2. [参照] をクリックする。[サービスブラウザ] が表示される。 3. [サービスブラウザ] でビジネスサービスを選択する。 4. [送信] をクリックしてダイアログボックスを閉じ、全般的なコンフィグレーションページに戻る。これにより、選択したビジネスサービスにルーティングするルートノードを備えたプロキシサービスを作成できる。ビジネスサービスの詳細については、「ビジネスサービスの概要」を参照。
既存のプロキシサービスからのプロキシサービスの作成	1. [既存のサービスから作成] の下にある [プロキシサービス] を選択する。 2. [参照] をクリックする。[サービスブラウザ] が表示される。 3. [サービスブラウザ] でプロキシサービスを選択する。 4. [送信] をクリックしてダイアログボックスを閉じ、全般的なコンフィグレーションページに戻る。これにより、選択したプロキシサービスのクローンを新しいプロキシサービスとして作成できる。

[プロキシサービスプロバイダ] フィールドで、プロキシサービスプロバイダの名前を選択します。

[参照] をクリックします。[プロキシサービスプロバイダブラウザ] が表示されます。

[プロキシサービスプロバイダブラウザ] で、プロキシサービスプロバイダを選択します。

[送信] をクリックしてダイアログボックスを閉じ、全般的なコンフィグレーション ページに戻ります。

プロキシサービスプロバイダは特定の場合だけに必要とされます。たとえば、双方向発信 TLS/SSL でクライアント証明書認証を必要とする HTTPS サービスに対してプロキシサービスからメッセージをルーティングする場合や、一部の Web サービスセキュリティのシナリオ (プロキシサービスでメッセージの暗号化を必要とする場合など) に限定されます。プロキシサービスプロバイダの詳細については、「プロキシサービスプロバイダの概要」を参照してください。プロキシサービスプロバイダの作成方法については、「プロキシサービスプロバイダの追加」を参照してください。

注意 : Web サービスセキュリティ対応のプロキシサービスを追加するには、WS-Policy が付加された WSDL (ポートまたはバインディング) からプロキシサービスを作成する必要があります。

[次へ] をクリックします。

[サービスの種類] フィールドで [メッセージングサービス] を選択した場合は、[プロキシサービスの編集 - メッセージの種類のコンフィグレーション] ページが表示されます。「プロキシサービスを追加するには - メッセージの種類のコンフィグレーション」に進みます。
その他のサービスの種類を選択した場合は、[プロキシサービスの編集 - 転送コンフィグレーション] ページが表示されます。「プロキシサービスを追加するには - 転送コンフィグレーション」に進みます。

プロキシサービスを追加するには - メッセージの種類のコンフィグレーション

[サービスの種類] フィールドで [メッセージングサービス] を選択した場合は、[プロキシサービスの編集 - 全般的なコンフィグレーション] ページで [次へ] をクリックすると、[プロキシサービスの編集 - メッセージの種類のコンフィグレーション] ページが表示されます。

メッセージングサービス用のバインディング定義は、交換されるメッセージのコンテンツタイプのコンフィグレーションで構成されています。応答のコンテンツタイプは、要求のコンテンツタイプと同じである必要はありません。そのため、応答は個別にコンフィグレーションされます (たとえば、サービスで MFL メッセージを受信し、XML の受信確認を返すことも可能です)。

要求メッセージと応答メッセージのメッセージの種類を選択します。

[要求メッセージの種類] フィールドで、要求メッセージのメッセージの種類を選択します。

表 14-6 [要求メッセージの種類] フィールド

メッセージの種類	説明
バイナリ	メッセージのコンテンツタイプが不明か、重要でない場合は、[バイナリ] を選択する。
テキスト	メッセージをテキストに限定できる場合は、[テキスト] を選択する。
MFL	メッセージが MFL 定義に準拠したバイナリドキュメントの場合は、[MFL] を選択する。MFL ファイルは、1 つのみコンフィグレーションできる。注意 : MFL の場合は、[参照] をクリックし、[MFL ファイルブラウザ] で MFL を選択してから、[送信] をクリックすることができる。
XML	メッセージが XML ドキュメントの場合は、[XML] を選択する。一部の型情報を指定するために、交換される XML ドキュメントの XML スキーマ型を宣言できる。

[応答メッセージの種類] フィールドで、応答メッセージのメッセージの種類を選択します。

表 14-7 [応答メッセージの種類] フィールド

メッセージの種類	説明
なし	メッセージにコンテンツタイプがない場合に選択する。
バイナリ	メッセージのコンテンツタイプが不明か、重要でない場合は、[バイナリ] を選択する。
テキスト	メッセージをテキストに限定できる場合は、[テキスト] を選択する。
MFL	メッセージが MFL 定義に準拠したバイナリドキュメントの場合は、[MFL] を選択する。MFL ファイルは、1 つのみコンフィグレーションできる。注意 : MFL の場合は、[参照] をクリックし、[MFL ファイルブラウザ] で MFL を選択してから、[送信] をクリックすることができる。
XML	メッセージが XML ドキュメントの場合は、[XML] を選択する。一部の型情報を指定するために、交換される XML ドキュメントの XML スキーマ型を宣言できる。

[次へ] をクリックします。

転送コンフィグレーション ページが表示されます。「プロキシサービスを追加するには - 転送コンフィグレーション」に進みます。

プロキシサービスを追加するには - 転送コンフィグレーション

[プロキシサービスの編集 - 全般的なコンフィグレーション] ページで [次へ] をクリックすると、転送コンフィグレーション ページが表示されます。メッセージングサービスの場合、[プロキシサービスの編集 - メッセージの種類のコンフィグレーション] ページで [次へ] をクリックすると、このページが表示されます。

このページでは、プロキシサービスの転送情報をコンフィグレーションできます。AquaLogic Service Bus でサポートしているサービスの種類と転送方式の種類については、「サービスの種類と転送方式」を参照してください。

注意 : 着信転送レベルのセキュリティは、クライアントアプリケーションと AquaLogic Service Bus プロキシサービスに適用されます。発信転送レベルのセキュリティは、AquaLogic Service Bus のプロキシサービスとビジネスサービスの間の接続に適用されます。転送レベルのセキュリティの詳細については、『BEA AquaLogic Service Bus ユーザーズガイド』の「着信メッセージおよび発信メッセージの保護」で「転送レベルのセキュリティ」を参照してください。

[プロトコル] フィールドで、以下の転送プロトコルを 1 つ選択します。

HTTP
JMS
HTTPS
FTP
Email
File

[エンドポイント URI] フィールドに、[プロトコル] フィールドで選択した転送プロトコルに基づく形式のエンドポイント URI を入力してから、[Add] をクリックします。

表 14-8 [エンドポイント URI] フィールド

転送プロトコル	形式
Email	`mailfrom:mail-server-hostname:mail-server-port`
File	`file:///drivename:/somename`
FTP	`ftp://hostname:port/directory`
HTTP	`/someName`
HTTPS	`/someName`
JMS	`jms://host:port/factoryJndiName/destJndiName` JMS 送り先として複数のサーバを指定するには、次の URI 形式を使用する。 `jms://host1:port,host2:port/QueueConnectionFactory/DestName`

注意 : 複数の URL をコンフィグレーションできます。[アクション] カラムで [削除] をクリックすると、いつでも URL を削除できます。実行時に、[ロードバランシングアルゴリズム] フィールドで選択したロードバランシングアルゴリズムに基づいて URL が選択されます。

[すべてのヘッダを取得] フィールドで、転送からすべてのヘッダを取り出す場合は [はい] を、定義に該当するヘッダを取り出す場合は [いいえ] を選択します。[いいえ] を選択した場合は、[ヘッダ] フィールドに一連のヘッダを入力してから、[Add] をクリックします。

[次へ] をクリックします。

新しい転送コンフィグレーション ページが表示されます。このページでは、プロキシサービスのプロトコルに依存する転送情報をコンフィグレーションできます。「プロキシサービスを追加するには - プロトコル依存の転送コンフィグレーション」に進みます。

プロキシサービスを追加するには - プロトコル依存の転送コンフィグレーション

[プロキシサービスの編集 - 転送コンフィグレーション] ページで [次へ] をクリックすると、プロトコル依存の転送コンフィグレーション ページが表示されます。このページでは、プロキシサービスについて、[プロトコル] フィールドで選択した転送プロトコルに基づき追加的な転送情報をコンフィグレーションできます。

[プロトコル] フィールドで選択した転送プロトコルに基づき、以下のいずれか 1 つを実行します。

表 14-9 [プロトコル] フィールド

転送プロトコル	手順
HTTP	1. [基本認証が必要] チェックボックスを選択して、このサービスにアクセスするための基本認証を必須とするか、このフィールドを空白のままにして基本認証を不要とする。基本認証では、WebLogic Server でユーザ名とパスワードを使用し、セキュリティレルム (Lightweight Directory Access Protocol (LDAP) ディレクトリサービスや Windows Active Directory など) でコンフィグレーションされた認証プロバイダに対してクライアントの認証が行われる。クライアントは、HTTP 要求ヘッダでユーザ名とパスワードを送信する必要がある。注意 : HTTP での基本認証は、パスワードがクリアテキストで送信されるため推奨されない。HTTPS では暗号化されたチャネルが提供されるため、パスワードは HTTPS で送信するのが安全。警告 : 基本認証を必要とする HTTP プロキシサービスのエンドポイントを作成する場合、転送認可ポリシーは着信エンドポイント URI に自動的には関連付けられない。基本認証を強制するには、エンドポイントの転送認証ポリシーを定義する必要がある。詳細については、『BEA AquaLogic Service Bus ユーザーズガイド』の「着信メッセージおよび発信メッセージの保護」を参照。 2. [ディスパッチポリシー] フィールドで、このエンドポイントのディスパッチポリシーを選択する。デフォルトのディスパッチポリシーを使用するには、[default] のままにする。ディスパッチポリシーは、サービスのエンドポイントに使用する WLS 9.0 ワークマネージャのインスタンスを参照する。たとえば、プロキシサービスが JMS 転送プロトコルに対応している場合、サービスのエンドポイントは、そのディスパッチポリシーに関連付けることのできる MDB (メッセージ駆動型 Bean) の JAR ファイルになる。 3. [要求エンコーディング] フィールドで、HTTP 転送における要求の文字セットエンコーディングとして、デフォルトの `iso-8859-1` を受け入れるか、別の文字セットエンコーディングを入力する。 4. [応答エンコーディング] フィールドで、HTTP 転送における応答の文字セットエンコーディングとして、デフォルトの `iso-8859-1` を受け入れるか、別の文字セットエンコーディングを入力する。
HTTPS	1. [クライアント認証] フィールドで、クライアント認証方式として [なし]、[基本]、または [クライアント証明書] を選択する。警告 : 基本認証を必要とする HTTPS プロキシサービスのエンドポイントを作成する場合、転送認可ポリシーは着信エンドポイント URI に自動的には関連付けられない。基本認証を強制するには、エンドポイントの転送認証ポリシーを定義する必要がある。詳細については、『BEA AquaLogic Service Bus ユーザーズガイド』の「着信メッセージおよび発信メッセージの保護」を参照。 2. [ディスパッチポリシー] フィールドで、このエンドポイントのディスパッチポリシーを選択する。デフォルトのディスパッチポリシーを使用するには、[default] のままにする。ディスパッチポリシーは、サービスのエンドポイントに使用する WLS 9.0 ワークマネージャのインスタンスを参照する。たとえば、プロキシサービスが JMS 転送プロトコルに対応している場合、サービスのエンドポイントは、そのディスパッチポリシーに関連付けることのできる MDB (メッセージ駆動型 Bean) の JAR ファイルになる。 3. [要求エンコーディング] フィールドで、HTTPS 転送における要求の文字セットエンコーディングとして、デフォルトの `iso-8859-1` を受け入れるか、別の文字セットエンコーディングを入力する。 4. [応答エンコーディング] フィールドで、HTTPS 転送における応答の文字セットエンコーディングとして、デフォルトの `iso-8859-1` を受け入れるか、別の文字セットエンコーディングを入力する。
JMS	1. [送り先の種類] フィールドで [キュー] または [トピック] を選択する。 2. 要求を TSL/SSL 接続で行う場合は、[SSL を使用] チェックボックスを選択する。それ以外の場合は、このフィールドを空白のままにする。TLS/SSL (セキュアソケットレイヤ) では、ネットワークで接続される 2 つのアプリケーションが互いの ID を認証し、アプリケーション間で交換されるデータを暗号化できるようにすることによって、安全な接続が可能になる。認証を使用すると、サーバ (および必要に応じてクライアント) はネットワーク接続の相手側アプリケーションの ID を検証できる。また、送り先の JNDI エントリに対してアクセス制御が設定されていることにより、管理者から個々の JMS 送り先 (キューまたはトピック) へのアクセスが制限されている場合、JNDI ツリー内でのルックアップ時に、ビジネスサービスでユーザ名とパスワードを使用して認証を行う必要がある。 3. [送り先の種類] フィールドで [キュー] を選択した場合は、[応答が必要] チェックボックスを選択する。それ以外の場合は、このフィールドを空白のままにする。このチェックボックスにより、メッセージの送信後に応答を受け取るか受け取らないかが決まる。このチェックボックスを選択した場合は、[応答 URI] フィールドへの入力が必要。 4. [応答 URI] フィールドに、`jms://host:port/MyFactory/MyQueue` という形式で URI を入力する。[応答が必要] を選択した場合は、このフィールドは必須。複数のサーバを送り先にするには、次の URI 形式を使用する。 `jms://host1:port,host2:port/QueueConnectionFactory/DestName` 5. [メッセージの種類] フィールドで、[バイト] または [テキスト] を選択する ([応答が必要] フィールドを選択した場合)。 6. [要求エンコーディング] フィールドで、JMS 転送における要求の文字セットエンコーディングとして、デフォルトの `utf-8` を受け入れるか、別の文字セットエンコーディングを入力する。 7. [応答エンコーディング] フィールドで、JMS 転送における応答の文字セットエンコーディングとして、デフォルトの `utf-8` を受け入れるか、別の文字セットエンコーディングを入力する。 8. [JMS サービスアカウント] フィールドで、JMS サーバ接続に使用するサービスアカウントを選択する。サービスアカウントは、ユーザ ID とそれに関連付けられたパスワードのエリアスリソースである。サービスアカウントの詳細については、「サービスアカウントの概要」を参照。 9. [ディスパッチポリシー] フィールドで、このエンドポイントのディスパッチポリシーを選択する。[default] は、デフォルトのディスパッチポリシーを示す。ディスパッチポリシーは、サービスのエンドポイントに使用する WLS 9.0 ワークマネージャのインスタンスを参照する。たとえば、プロキシサービスが JMS 転送プロトコルに対応している場合、サービスのエンドポイントは、そのディスパッチポリシーに関連付けることのできる MDB (メッセージ駆動型 Bean) の JAR ファイルになる。
Email	1. [サービスアカウント] フィールドにサービスアカウントを入力する。このフィールドは必須。 2. [ポーリング間隔] フィールドにポーリング間隔を秒数で入力する。このフィールドは必須。 3. [電子メールプロトコル] フィールドで、電子メールアカウントのサーバの種類として [pop3] または [IMAP] を選択する。このフィールドは必須。 4. [読み込み制限] フィールドに、ポーリングスイープあたりの読み込みメッセージ最大数を指定する。無制限にするには `0` と入力する。このフィールドは必須。 5. アーカイブディレクトリにファイルをステージングして、それをヘッダに参照として渡す場合は、[参照として渡す] フィールドを選択する。それ以外の場合は、このフィールドを空白のままにする。 6. [読み込み後のアクション] フィールドで、メッセージ読み込み後の動作を選択する。 [アーカイブ] - メッセージがアーカイブ化される。 [削除] - メッセージが削除される。 [移動] - メッセージが移動される。[移動] は、IMAP プロトコルでのみ使用可能。注意 : このフィールドは必須。 7. [添付ファイル] フィールドで添付ファイルの処理方法を選択する。 [アーカイブ] - 添付ファイルがアーカイブディレクトリに保存される。 [無視] - 添付ファイルが無視される。このフィールドは必須。 8. [読み込み後のアクション] フィールドで [移動] を選択した場合は、[IMAP 移動先フォルダ] フィールドにメッセージの移動先フォルダを入力する。 9. [ダウンロードディレクトリ] フィールドに、電子メールのダウンロード先となる一時保存先を入力する。このフィールドは必須。 10. [読み込み後のアクション] フィールドで [アーカイブ] を選択した場合は、[アーカイブディレクトリ] フィールドにアーカイブ保存先のパスを入力する。[アーカイブディレクトリ] フィールドは、[参照として渡す] フィールドを選択した場合も必須。 11. [エラーディレクトリ] フィールドに、問題が生じたときにメッセージと添付ファイルを書き込むファイルシステムディレクトリへのパスを入力する。このフィールドは必須。 12. [要求エンコーディング] フィールドで、電子メール転送における要求の文字セットエンコーディングとして、デフォルトの `iso-8859-1` を受け入れるか、別の文字セットエンコーディングを入力する。
File	1. [File Mask] フィールドに、選択するファイルの正規表現を入力する。デフォルト値は *.。このフィールドは必須。 2. [Polling Interval] フィールドにポーリング間隔を秒数で入力する。デフォルト値は 60。このフィールドは必須。 3. [Read Limit] フィールドに、ポーリングスイープあたりの読み込みメッセージ最大数を指定する。無制限にするには `0` と入力する。デフォルトは、10。このフィールドは必須。 4. イベントの配信を受信順にする場合は、[Sort By Arrival] チェックボックスを選択し、それ以外の場合は空白のままにする。 5. すべてのディレクトリを再帰的にスキャンする場合は、[Scan SubDirectories] チェックボックスを選択し、それ以外の場合はこのフィールドを空白のままにする。 6. アーカイブディレクトリにファイルをステージングして、それをヘッダに参照として渡す場合は、[Pass By Reference] チェックボックスを選択する。それ以外の場合は、このフィールドを空白のままにする。 7. [Post Read Action] フィールドで、メッセージ読み込み後の動作を選択する。 [archive] - メッセージがアーカイブ化される。 [delete] - メッセージが削除される。このフィールドは必須。 8. [Stage Directory] フィールドに、ファイルの処理中に一時的にファイルをステージングする中間ディレクトリを入力する。このフィールドは必須。 9. [Post Read Action] フィールドで [archive] を選択した場合は、[Archive Directory] フィールドにアーカイブ保存先のパスを入力する。[Archive Directory] フィールドは、[Pass By Reference] フィールドを選択した場合も必須。 10. [Error Directory] フィールドに、問題が生じたときにメッセージと添付ファイルをポストする場所を入力する。このフィールドは必須。 11. [Request encoding*] フィールドで、ファイル転送における要求の文字セットエンコーディングとして、デフォルトの `utf-8` を受け入れるか、別の文字セットエンコーディングを入力する。
FTP	1. FTP サーバのユーザが匿名の場合は、[ユーザ認証] フィールドで [匿名] を選択し、FTP サーバが外部的にコンフィグレーションされたアカウントの場合は [外部ユーザ] を選択する。 2. [メール ID] フィールドまたは [サービスアカウント] フィールドに、匿名ユーザのメール ID を入力するか ([ユーザ認証] フィールドで [匿名] を選択した場合)、またはサービスアカウントを入力する ([ユーザ認証] フィールドで [外部ユーザ] を選択した場合)。[外部ユーザ] を選択した場合、このフィールドへの入力は必須。 3. すべてのディレクトリを再帰的にスキャンする場合は、[サブディレクトリのスキャン] チェックボックスを選択し、それ以外の場合はこのフィールドを空白のままにする。 4. アーカイブディレクトリにファイルをステージングして、それをヘッダに参照として渡す場合は、[参照として渡す] チェックボックスを選択する。 5. イベントの配信を受信順にする場合は、[到着順にソート] チェックボックスを選択する。 6. 処理時にリモートサーバから FTP ファイルを直接ストリーミングする場合は、[リモートストリーミング] チェックボックスを選択する。それ以外の場合は、このフィールドを空白のままにする。 7. [タイムアウト] フィールドに、接続が切断されるまでのソケットタイムアウト間隔を秒数で入力する。0 と入力した場合、タイムアウトは発生しない。 8. [再試行回数] フィールドに FTP 接続失敗時の再試行回数を指定する。 9. [ファイルマスク] フィールドに、選択するファイルの正規表現を入力する。デフォルト値は *.。このフィールドは必須。 10. [ポーリング間隔] フィールドにポーリング間隔を秒数で入力する。デフォルト値は 60。このフィールドは必須。 11. [読み込み制限] フィールドに、ポーリングスイープあたりの読み込みメッセージ最大数を指定する。無制限にするには `0` と入力する。デフォルト値は 10。このフィールドは必須。 12. [読み込み後のアクション] フィールドで、メッセージ読み込み後の動作を選択する。このフィールドは必須。 [アーカイブ] - メッセージがアーカイブ化される。 [削除] - メッセージが削除される。 13. [転送モード] フィールドで転送モードとして [ascii] または [binary] を選択する。 14. [読み込み後のアクション] フィールドで [アーカイブ] を選択した場合は、[アーカイブディレクトリ] フィールドにアーカイブ保存先のパスを入力する。[アーカイブディレクトリ] フィールドは、[参照として渡す] フィールドを選択した場合も必須。 15. [ダウンロードディレクトリ] フィールドに、ファイル転送中にファイルをダウンロードするローカルのディレクトリを入力する。このフィールドは必須。 16. [エラーディレクトリ] フィールドに、問題が生じたときにメッセージと添付ファイルをポストする場所を入力する。このフィールドは必須。 17. [要求エンコーディング*] フィールドで、ファイル転送における要求の文字セットエンコーディングとして、デフォルトの `utf-8` を受け入れるか、別の文字セットエンコーディングを入力する。

[次へ] をクリックします。

このサービスに操作が含まれる場合は、[プロキシサービスの編集 - 操作選択コンフィグレーション] ページが表示されます。「プロキシサービスを追加するには - 操作選択コンフィグレーション」に進みます。
このサービスに操作が含まれない場合は、全般的なコンフィグレーションの確認ページが表示されます。「プロキシサービスを追加するには - 全般的なコンフィグレーションの確認」に進みます。

プロキシサービスを追加するには - 操作選択コンフィグレーション

このサービスに処理がある場合は、プロトコル依存の転送コンフィグレーション ページで [次へ] をクリックすると、操作選択コンフィグレーション ページが表示されます。このページでは、このプロキシサービスによって呼び出される処理の決定に使用される選択アルゴリズムを選択できます。このオプションは、WSDL に基づいて定義された SOAP サービスまたは XML サービスでのみ使用できます。

WSDL 仕様では、受信する SOAP メッセージの種類に基づいて呼び出す処理を計算するデフォルトのアルゴリズムが定義されています。ただし、その他の手段に基づいて処理を選択しなければならない場合もあります (パフォーマンスや、署名および暗号化に問題があったり、デフォルトのアルゴリズムが使用できない場合など)。

AquaLogic Service Bus には、アルゴリズムが追加で用意されています。これらはそれぞれ同じパターンに従っており、式の評価に基づいて値を取得し、その値を使用して静的なテーブルから対応する処理をルックアップします。

[選択アルゴリズム] フィールドで、以下のいずれか 1 つを選択します。

表 14-10 [選択アルゴリズム] フィールド

選択アルゴリズム	説明
転送ヘッダ	この選択アルゴリズムを選択すると、ルックアップ値を含む転送ヘッダを定義できる。
WS-Addressing	この選択アルゴリズムを選択すると、ルックアップ値は SOAP メッセージの SOAP ヘッダ内の WS-Addressing Action タグに入る。
SOAP ヘッダ	この選択アルゴリズムを選択すると、SOAP ヘッダに対して評価される XPath 式を定義して、ルックアップ値を取得できる。
SOAP 本体の種類	WSDL 仕様で定義されたデフォルトのアルゴリズム。受信する SOAP メッセージの種類に基づいて呼び出す処理が計算される。注意 : プロキシサービスをコンフィグレーションする Web サービスセキュリティのパススルーシナリオで本体が暗号化されている場合は、選択アルゴリズムとして [SOAP 本体の種類] を選択することはできない。SOAP ヘッダが暗号化されたパススルーシナリオについても同様。

注意 : WSDL ポートまたは WSDL バインディングに基づく XML サービスを作成する場合は、[転送ヘッダ] と [ペイロードの種類] という選択アルゴリズムがこのページに表示されます。

注意 : 選択した選択アルゴリズムに応じて、さらに別のフィールドが表示されます。

[選択アルゴリズム] フィールドで選択した選択アルゴリズムに基づき、以下のいずれか 1 つを実行します。

表 14-11 [選択アルゴリズム] フィールド

選択アルゴリズム	手順
転送ヘッダ	1. [ヘッダ名] フィールドに、呼び出される処理を選択するキーとして使用される値を抽出する転送ヘッダを入力する。 2. [操作のマッピング] フィールドの [値] フィールドに、各処理の値を指定する。この値が処理のキーとして使用される。このフィールドは必須。
WS-Addressing	[操作のマッピング] フィールドの [値] フィールドに、各処理の値を指定する。この値が処理のキーとして使用される。このフィールドは必須。
SOAP ヘッダ	1. [XPath 式] フィールドに、呼び出される処理を選択するキーとして使用される値を抽出する XPath 式を指定する。 2. [操作のマッピング] フィールドの [値] フィールドに、各処理の値を指定する。この値が処理のキーとして使用される。このフィールドは必須。
SOAP 本体の種類	この選択アルゴリズムを選択した場合は、追加のフィールドが表示されない。
ペイロードの種類	この選択アルゴリズムを選択した場合は、追加のフィールドが表示されない。

[次へ] をクリックします。

全般的なコンフィグレーションの確認ページが表示されます。「プロキシサービスを追加するには - 全般的なコンフィグレーションの確認」に進みます。

注意 : WS-Policy が付加された WSDL (ポートまたはバインディング) からプロキシサービスを作成する場合は、[次へ] をクリックすると、Web サービスセキュリティコンフィグレーション ページが表示されます。このページには、すべての処理について効果的な要求/応答の WS-Policy の読み込み専用ビューが表示されます。

以下のいずれか 1 つを実行します。

プロキシサービスをアクティブな仲介機能として使用し、復号化や署名の検証などの処理を実行する場合は、[WS-Security ヘッダの処理] を選択する。
プロキシサービスをパススルーとして使用し、メッセージの復号化やデジタル署名の検証を行わない場合は、[WS-Security ヘッダの処理] を空白にする。

詳細については、『BEA AquaLogic Service Bus ユーザーズガイド』の「着信メッセージおよび発信メッセージの保護」を参照してください。

プロキシサービスを追加するには - 全般的なコンフィグレーションの確認

操作選択コンフィグレーション ページで [次へ] をクリックすると、全般的なコンフィグレーションの確認ページが表示されます。このページでは、このプロキシサービスについてこれまでに入力したコンフィグレーションデータを確認できます。必要であれば、[編集] をクリックしコンフィグレーションを変更してから、プロキシサービスを保存できます。

以下のいずれか 1 つを実行します。

任意のコンフィグレーションページの [編集] をクリックして、変更を加える。
[戻る] をクリックして、前のページに戻る。
[保存] をクリックして、プロキシサービスを作成する。プロキシサービスが作成されます。

プロジェクトビュー ページまたはフォルダビュー ページが表示されます。新しいプロキシサービスがリソースリストに追加されます。

[取り消し] をクリックして、変更を取り消す。

注意 : プロキシサービス作成後の次の手順では、メッセージフローをコンフィグレーションします。メッセージフローは、プロキシサービスの実装を定義します。メッセージフローには、パイプラインペア、および開始ノード、ルートノード、エコーノード、ブランチノードを入れることができます。詳細については、「メッセージフローの概要」および「メッセージフローの表示と変更」を参照してください。

注意 : 新しいプロキシサービスは現在のセッションに保存されます。コンフィグレーションに対する変更が完了したら、左側のナビゲーションペインで、[Change Center] の下にある [アクティブ化] をクリックします。セッションが終了し、コアコンフィグレーションが更新されます。また、セッション中はいつでも [破棄] をクリックすることができ、現在のセッションでこれまでに加えた変更を取り消すことができます。

プロキシサービスからの WSDL の生成

AquaLogic Service Bus では、WSDL バインディングに基づいてプロキシサービスを作成すると、そのプロキシサービス用に生成された WSDL に新しいサービスとポートの定義が設定されます。WSDL ポートと WSDL バインディングのどちらに基づいてプロキシサービスを定義するかに関わらず、そのプロキシサービス用として生成された WSDL で定義されるポートは 1 つだけです。テンプレート WSDL でポート X からサービスが生成される場合、生成される WSDL でもポート X が定義されます。テンプレート WSDL で定義された他のすべてのポートは、生成される WSDL には含まれません。さらに、WSDL ポートに基づいてプロキシサービスを作成する場合、生成される WSDL ではそのポート名が使用され、そのポートに関連付けられたすべての WS-Policy が保持されます。バインディングはポートから決定され、ポートの種類はバインディングから決定されます。

サービスがテンプレート WSDL のバインディング Y から生成される場合、生成される WSDL によって新しいサービスとポートが定義されます (<service-name>QSService および <port-name>QSPort)。テンプレート WSDL で定義されたどのポートも、生成される WSDL には含まれません。

WSDL バインディングテンプレートに基づいてサービスを作成する場合、その WSDL には、該当のバインディングに関連付けられた複数のポートが存在する場合があります。各ポートには異なる URL を使用でき、異なる WS-Policy を付加できます。したがって、生成される WSDL は、そのバインディングを使用しますが、そのバインディング用に WS-Policy のない人為的なポートを生成します。すべての WSDL ベースサービスでは、サービス定義の転送セクションで転送の種類と転送 URL を上書きできます。

サービスの URL に ?WSDL を追加したものをブラウザのアドレスフィールドに入力することで、HTTP(S) ベースのプロキシサービスの WSDL を取得できます。

プロキシサービスの表示と検索

[プロキシサービスの概要] ページでは、プロキシサービスのリストを表示できます。プロキシサービスとは、WebLogic Server 上にローカルに実装される Web サービスの AquaLogic Service Bus 定義です。詳細については、「プロキシサービスの概要」を参照してください。

プロキシサービスを表示および検索するには

左側のナビゲーションペインで、[リソースブラウザ] の下にある [プロキシサービス] を選択します。[プロキシサービスの概要] ページが表示されます。プロキシサービスごとに、以下の情報が表示されます。各プロパティの詳細については、「プロキシサービスの表示と変更」を参照してください。

表 14-12 [プロキシサービスの概要] ページ

プロパティ	説明
名前	ユニークなプロキシサービス名。詳細の表示ページにリンクされている。詳細については、「プロキシサービスの表示と変更」を参照。
パス	プロジェクト名と、プロキシサービスが格納されているフォルダの名前。このリソースが格納されているプロジェクトまたはフォルダにリンクされている。詳細については、「プロジェクトの詳細の表示」または「フォルダの詳細の表示」を参照。
オプション	[オプション] カラムに以下のアイコンが表示される。 [モニタの管理] アイコン。特定のサービスに関するアラートを確認できるモニタの管理ページにリンクされている。詳細については、「アラートルールの表示と検索」を参照。 [メッセージフローの編集] アイコン。特定のサービスに関するパイプラインの編集用画面にリンクされている。「メッセージフローの表示と変更」を参照。 [削除] アイコン。特定のサービスを削除できる。詳細については、「プロキシサービスの削除」を参照。 AquaLogic Service Bus の他のリソースによって参照されているリソースは削除できない。このようなリソースの場合は、[削除] アイコンではなく、赤い X 印の付いた削除アイコンが表示される。

プロパティ

説明

名前

ユニークなプロキシサービス名。詳細の表示ページにリンクされている。詳細については、「プロキシサービスの表示と変更」を参照。

パス

プロジェクト名と、プロキシサービスが格納されているフォルダの名前。このリソースが格納されているプロジェクトまたはフォルダにリンクされている。詳細については、「プロジェクトの詳細の表示」または「フォルダの詳細の表示」を参照。

オプション

[オプション] カラムに以下のアイコンが表示される。

[モニタの管理] アイコン。特定のサービスに関するアラートを確認できるモニタの管理ページにリンクされている。詳細については、「アラートルールの表示と検索」を参照。

[メッセージフローの編集] アイコン。特定のサービスに関するパイプラインの編集用画面にリンクされている。「メッセージフローの表示と変更」を参照。

[削除] アイコン。特定のサービスを削除できる。詳細については、「プロキシサービスの削除」を参照。

AquaLogic Service Bus の他のリソースによって参照されているリソースは削除できない。このようなリソースの場合は、[削除] アイコンではなく、赤い X 印の付いた削除アイコンが表示される。

特定のプロキシサービスを検索するには、以下のいずれか 1 つを実行します。

プロキシサービス名でフィルタする。[名前] フィールドと [パス] フィールドに、検索対象の名前とパスを入力してから、[検索] をクリックします。このパスは、プロジェクト名、およびプロキシサービスが格納されるフォルダの名前であり、検索条件と一致するサービスが表示されます。
リストを再ソートする。ソート可能なカラムには昇順および降順の矢印ボタンが表示されます (この場合は [名前] カラムと [パス] カラム)。このボタンをクリックしてソート順を変更します。
ページをスクロールする。右下隅のコントロールを使用します。ページを移動するには、ページ番号を選択するか、次のページ、前のページ、最初のページ、または最後のページに移動する矢印ボタンを使用します。

注意 : [すべて表示] をクリックすると、すべてのプロキシサービスが表示されます。

プロキシサービスの表示と変更

[詳細の表示] ページでは、個々のプロキシサービスの詳細を表示および編集できます。詳細については、「プロキシサービスの概要」を参照してください。

プロキシサービスの詳細を表示および編集するには

対象のプロキシサービスを検索します。詳細については、「プロキシサービスの表示と検索」を参照してください。

プロキシサービス名をクリックします。

[詳細の表示] ページに以下の情報が表示されます。

表 14-13 [詳細の表示] ページ

プロパティ

説明

リソース名

このプロキシサービスの名前。

参照先

このプロキシサービスが参照するオブジェクトの数。該当する参照がある場合は、リンクをクリックするとオブジェクトのリストが表示される。詳細については、「参照の表示」を参照。

参照元

このプロキシサービスを参照するオブジェクトの数。該当する参照がある場合は、リンクをクリックするとオブジェクトのリストが表示される。詳細については、「参照の表示」を参照。

説明

このプロキシサービスの説明 (説明が存在する場合)。
詳細の表示ページに以下の全般的なコンフィグレーション情報が表示されます。

表 14-14 全般的なコンフィグレーション情報

プロパティ

説明

サービスの種類

サービスの種類。

プロキシサービスプロバイダ

このプロキシサービスプロバイダの名前。
このプロキシサービスのサービスの種類がメッセージングサービスの場合は、以下のメッセージの種類のコンフィグレーション情報が表示されます。

表 14-15 メッセージの種類のコンフィグレーション情報

プロパティ

説明

要求メッセージの種類

[バイナリ]、[テキスト]、[MFL]、または [XML] で示される要求メッセージのメッセージの種類。

応答メッセージの種類

[なし]、[バイナリ]、[テキスト]、[MFL]、または [XML] で示される応答メッセージのメッセージの種類。
このページには以下の転送コンフィグレーション情報が表示されます。

表 14-16 転送コンフィグレーション情報

プロパティ

説明

プロトコル

転送プロトコル。

エンドポイント URI

エンドポイントの URI。

すべてのヘッダを取得

転送からすべてのヘッダ、定義に該当するヘッダのどちらを取り出すか。
転送プロトコルが電子メールの場合は、以下の電子メール転送コンフィグレーション情報が表示されます。

表 14-17 電子メール転送コンフィグレーション情報

プロパティ

説明

電子メールプロトコル

この電子メールアカウントのサーバの種類。

[pop3]

[imap]

サービスアカウント

このメールサーバのサービスアカウント。

ポーリング間隔

秒数で示されたポーリング間隔。

読み込み制限

ポーリングスイープあたりの読み込みメッセージ最大数。無制限の場合は「0」を指定する。

参照として渡す

ファイルをアーカイブディレクトリにステージングして、ヘッダに参照として渡すかどうか。

読み込み後のアクション

メッセージの読み込み後に、アーカイブ化、削除、移動のどの動作を実行するか。

[アーカイブ] - メッセージがアーカイブ化される。

[削除] - メッセージが削除される。

[移動] - メッセージが移動される。

注意 : [移動] は、IMAP プロトコルでのみ使用可能。

添付ファイル

添付ファイルをアーカイブ化するか、無視するか。

[アーカイブ] - 添付ファイルがアーカイブディレクトリに保存される。

[無視] - 添付ファイルが無視される。

IMAP 移動先フォルダ

[読み込み後のアクション] フィールドで [移動] を選択した場合に使用されるメッセージの移動先フォルダ。

ダウンロードディレクトリ

電子メールのダウンロードに使用される一時的な保存先。

アーカイブディレクトリ

[読み込み後のアクション] フィールドで [アーカイブ] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[アーカイブディレクトリ] フィールドは、[参照として渡す] フィールドを選択した場合も必須。

エラーディレクトリ

問題が生じた場合にメッセージと添付ファイルが書き込まれるファイルシステムディレクトリへのパス。

要求エンコーディング

電子メール転送の要求用文字セットエンコーディングが表示される。デフォルト値は iso-8859-1。
転送プロトコルがファイルの場合は、以下のファイル転送コンフィグレーション情報が表示されます。

表 14-18 ファイル転送コンフィグレーション情報

プロパティ

説明

File Mask

選択されるファイルに適用される正規表現。

Polling Interval

秒数で示されたポーリング間隔。

Encoding

ファイルがテキストファイルの場合、ファイルのエンコーディング。

Read Limit

ポーリングスイープあたりの読み込みメッセージの最大数。無制限の場合は「0」を指定する。

Sort by Arrival

イベントの配信を受信の順序にするかどうか。

Scan Subdirectories

すべてのディレクトリを再帰的にスキャンするかどうか。

Pass By Reference

ファイルをアーカイブディレクトリにステージングして、ヘッダに参照として渡すかどうか。

Post Read Action

メッセージの読み込み後に、アーカイブ化または削除するかどうか。

[archive] - メッセージがアーカイブ化される。

[delete] - メッセージが削除される。

Stage Directory

ファイルの処理中に一時的にファイルをステージングする中間ディレクトリ。

Error Directory

問題が生じた場合にメッセージと添付ファイルが書き込まれるファイルシステムディレクトリへのパス。

Archive Directory

[Post Read Action] フィールドで [archive] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[Archive Directory] フィールドは、[Pass By Reference] フィールドを選択した場合も必須。

Request encoding

JMS 転送の要求用文字セットエンコーディングが表示される。デフォルト値は utf-8。
転送プロトコルが FTP の場合は、以下の FTP 転送コンフィグレーション情報が表示されます。

表 14-19 FTP 転送コンフィグレーション情報

プロパティ

説明

メール ID / サービスアカウント

匿名ユーザのメール ID または外部的にコンフィグレーションされたユーザのサービスアカウント。

タイムアウト

秒数で示されたソケットタイムアウト。

ファイルマスク

選択されるファイルに適用される正規表現。

ダウンロードディレクトリ

FTP ファイルのダウンロードに使用される一時的な保存場所。

サブディレクトリのスキャン

すべてのディレクトリを再帰的にスキャンするかどうか。

参照として渡す

ファイルをアーカイブディレクトリにステージングして、ヘッダに参照として渡すかどうか。

読み込み後のアクション

メッセージの読み込み後に、アーカイブ化または削除するかどうか。

[アーカイブ] - メッセージがアーカイブ化される。

[削除] - メッセージが削除される。

アーカイブディレクトリ

[読み込み後のアクション] フィールドで [アーカイブ] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[アーカイブディレクトリ] フィールドは、[参照として渡す] フィールドを選択した場合も必須。

エラーディレクトリ

問題が生じた場合にメッセージと添付ファイルが書き込まれるファイルシステムディレクトリへのパス。

再試行回数

FTP 接続に失敗したときに再試行する回数。

ポーリング間隔

秒数で示されたポーリング間隔。

読み込み制限

ポーリングスイープあたりの読み込みメッセージの最大数。無制限の場合は「0」を指定する。

到着順にソート

イベントの配信を受信の順序にするかどうか。

転送モード

転送モード : [Binary] または [ASCII]。

要求エンコーディング

JMS 転送の要求用文字セットエンコーディングが表示される。デフォルト値は utf-8。
転送プロトコルが HTTP の場合は、以下の HTTP 転送コンフィグレーション情報が表示されます。

表 14-20 HTTP 転送コンフィグレーション情報

プロパティ

説明

基本認証が必要

基本認証が必要かどうか (必要な場合は [有効] が表示される)。

要求エンコーディング

HTTP 転送の要求用文字セットエンコーディングが表示される。デフォルト値は iso-8859-1。

応答エンコーディング

HTTP 転送の応答用文字セットエンコーディングが表示される。デフォルト値は iso-8859-1。
転送プロトコルが HTTPS の場合は、以下の HTTPS 転送コンフィグレーション情報が表示されます。

表 14-21 HTTPS 転送コンフィグレーション情報

プロパティ

説明

クライアント認証

クライアント認証方式 : [なし]、[基本]、または [クライアント証明書]。

要求エンコーディング

HTTPS 転送の要求用文字セットエンコーディングが表示される。デフォルト値は iso-8859-1。

応答エンコーディング

HTTPS 転送の応答用文字セットエンコーディングが表示される。デフォルト値は iso-8859-1。
転送プロトコルが JMS の場合は、以下の JMS 転送コンフィグレーション情報が表示されます。

表 14-22 JMS 転送コンフィグレーション情報

プロパティ

説明

送り先の種類

送り先の種類 : [キュー] または [トピック]。

SSL を使用

要求を TSL/SSL 接続で行うかどうか。

応答が必要

メッセージの送信後に応答を受け取るかどうか。

要求エンコーディング

JMS 転送の要求用文字セットエンコーディングが表示される。デフォルト値は utf-8。

応答 URI

jms://host:port/factoryJndiName/destJndiName の形式で記載された応答 URI。

複数のサーバを送り先にするには、次の URI 形式を使用する。
jms://host1:port,host2:port/QueueConnectionFactory/DestName

JMS サービスアカウント

JMS サーバ接続に使用するサービスアカウント。
このページには以下の操作選択コンフィグレーション情報が表示されます。

表 14-23 操作選択コンフィグレーション情報

プロパティ

説明

選択アルゴリズム

このプロキシサービスに呼び出される操作を決定する選択アルゴリズム。

ヘッダ名

このプロキシサービスについて [選択アルゴリズム] フィールドで [転送ヘッダ] を選択している場合、このフィールドには、呼び出される操作を選択するキーとして使用される値を抽出する転送ヘッダが表示される。

XPath 式

このプロキシサービスについて [選択アルゴリズム] フィールドで [SOAP ヘッダ] を選択している場合、呼び出される操作を選択するキーとして使用される値を抽出する XPath 式がこのフィールドに表示される。

操作のマッピング

このプロキシサービスについて [選択アルゴリズム] フィールドで [転送ヘッダ]、[WS-Addressing]、または [SOAP ヘッダ] を選択している場合、各操作の値がこのフィールドに表示される。この値が操作のキーとして使用される。

プロパティ	説明
リソース名	このプロキシサービスの名前。
参照先	このプロキシサービスが参照するオブジェクトの数。該当する参照がある場合は、リンクをクリックするとオブジェクトのリストが表示される。詳細については、「参照の表示」を参照。
参照元	このプロキシサービスを参照するオブジェクトの数。該当する参照がある場合は、リンクをクリックするとオブジェクトのリストが表示される。詳細については、「参照の表示」を参照。
説明	このプロキシサービスの説明 (説明が存在する場合)。

プロパティ	説明
サービスの種類	サービスの種類。
プロキシサービスプロバイダ	このプロキシサービスプロバイダの名前。

プロパティ	説明
要求メッセージの種類	[バイナリ]、[テキスト]、[MFL]、または [XML] で示される要求メッセージのメッセージの種類。
応答メッセージの種類	[なし]、[バイナリ]、[テキスト]、[MFL]、または [XML] で示される応答メッセージのメッセージの種類。

プロパティ	説明
プロトコル	転送プロトコル。
エンドポイント URI	エンドポイントの URI。
すべてのヘッダを取得	転送からすべてのヘッダ、定義に該当するヘッダのどちらを取り出すか。

プロパティ	説明
電子メールプロトコル	この電子メールアカウントのサーバの種類。 [pop3] [imap]
サービスアカウント	このメールサーバのサービスアカウント。
ポーリング間隔	秒数で示されたポーリング間隔。
読み込み制限	ポーリングスイープあたりの読み込みメッセージ最大数。無制限の場合は「`0`」を指定する。
参照として渡す	ファイルをアーカイブディレクトリにステージングして、ヘッダに参照として渡すかどうか。
読み込み後のアクション	メッセージの読み込み後に、アーカイブ化、削除、移動のどの動作を実行するか。 [アーカイブ] - メッセージがアーカイブ化される。 [削除] - メッセージが削除される。 [移動] - メッセージが移動される。注意 : [移動] は、IMAP プロトコルでのみ使用可能。
添付ファイル	添付ファイルをアーカイブ化するか、無視するか。 [アーカイブ] - 添付ファイルがアーカイブディレクトリに保存される。 [無視] - 添付ファイルが無視される。
IMAP 移動先フォルダ	[読み込み後のアクション] フィールドで [移動] を選択した場合に使用されるメッセージの移動先フォルダ。
ダウンロードディレクトリ	電子メールのダウンロードに使用される一時的な保存先。
アーカイブディレクトリ	[読み込み後のアクション] フィールドで [アーカイブ] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[アーカイブディレクトリ] フィールドは、[参照として渡す] フィールドを選択した場合も必須。
エラーディレクトリ	問題が生じた場合にメッセージと添付ファイルが書き込まれるファイルシステムディレクトリへのパス。
要求エンコーディング	電子メール転送の要求用文字セットエンコーディングが表示される。デフォルト値は `iso-8859-1`。

プロパティ	説明
File Mask	選択されるファイルに適用される正規表現。
Polling Interval	秒数で示されたポーリング間隔。
Encoding	ファイルがテキストファイルの場合、ファイルのエンコーディング。
Read Limit	ポーリングスイープあたりの読み込みメッセージの最大数。無制限の場合は「`0`」を指定する。
Sort by Arrival	イベントの配信を受信の順序にするかどうか。
Scan Subdirectories	すべてのディレクトリを再帰的にスキャンするかどうか。
Pass By Reference	ファイルをアーカイブディレクトリにステージングして、ヘッダに参照として渡すかどうか。
Post Read Action	メッセージの読み込み後に、アーカイブ化または削除するかどうか。 [archive] - メッセージがアーカイブ化される。 [delete] - メッセージが削除される。
Stage Directory	ファイルの処理中に一時的にファイルをステージングする中間ディレクトリ。
Error Directory	問題が生じた場合にメッセージと添付ファイルが書き込まれるファイルシステムディレクトリへのパス。
Archive Directory	[Post Read Action] フィールドで [archive] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[Archive Directory] フィールドは、[Pass By Reference] フィールドを選択した場合も必須。
Request encoding	JMS 転送の要求用文字セットエンコーディングが表示される。デフォルト値は `utf-8`。

プロパティ	説明
メール ID / サービスアカウント	匿名ユーザのメール ID または外部的にコンフィグレーションされたユーザのサービスアカウント。
タイムアウト	秒数で示されたソケットタイムアウト。
ファイルマスク	選択されるファイルに適用される正規表現。
ダウンロードディレクトリ	FTP ファイルのダウンロードに使用される一時的な保存場所。
サブディレクトリのスキャン	すべてのディレクトリを再帰的にスキャンするかどうか。
参照として渡す	ファイルをアーカイブディレクトリにステージングして、ヘッダに参照として渡すかどうか。
読み込み後のアクション	メッセージの読み込み後に、アーカイブ化または削除するかどうか。 [アーカイブ] - メッセージがアーカイブ化される。 [削除] - メッセージが削除される。
アーカイブディレクトリ	[読み込み後のアクション] フィールドで [アーカイブ] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[アーカイブディレクトリ] フィールドは、[参照として渡す] フィールドを選択した場合も必須。
エラーディレクトリ	問題が生じた場合にメッセージと添付ファイルが書き込まれるファイルシステムディレクトリへのパス。
再試行回数	FTP 接続に失敗したときに再試行する回数。
ポーリング間隔	秒数で示されたポーリング間隔。
読み込み制限	ポーリングスイープあたりの読み込みメッセージの最大数。無制限の場合は「`0`」を指定する。
到着順にソート	イベントの配信を受信の順序にするかどうか。
転送モード	転送モード : [Binary] または [ASCII]。
要求エンコーディング	JMS 転送の要求用文字セットエンコーディングが表示される。デフォルト値は `utf-8`。

プロパティ	説明
基本認証が必要	基本認証が必要かどうか (必要な場合は [有効] が表示される)。
要求エンコーディング	HTTP 転送の要求用文字セットエンコーディングが表示される。デフォルト値は `iso-8859-1`。
応答エンコーディング	HTTP 転送の応答用文字セットエンコーディングが表示される。デフォルト値は `iso-8859-1`。

プロパティ	説明
クライアント認証	クライアント認証方式 : [なし]、[基本]、または [クライアント証明書]。
要求エンコーディング	HTTPS 転送の要求用文字セットエンコーディングが表示される。デフォルト値は `iso-8859-1`。
応答エンコーディング	HTTPS 転送の応答用文字セットエンコーディングが表示される。デフォルト値は `iso-8859-1`。

プロパティ	説明
送り先の種類	送り先の種類 : [キュー] または [トピック]。
SSL を使用	要求を TSL/SSL 接続で行うかどうか。
応答が必要	メッセージの送信後に応答を受け取るかどうか。
要求エンコーディング	JMS 転送の要求用文字セットエンコーディングが表示される。デフォルト値は `utf-8`。
応答 URI	`jms://host:port/factoryJndiName/destJndiName` の形式で記載された応答 URI。複数のサーバを送り先にするには、次の URI 形式を使用する。 `jms://host1:port,host2:port/QueueConnectionFactory/DestName`
JMS サービスアカウント	JMS サーバ接続に使用するサービスアカウント。

プロパティ	説明
選択アルゴリズム	このプロキシサービスに呼び出される操作を決定する選択アルゴリズム。
ヘッダ名	このプロキシサービスについて [選択アルゴリズム] フィールドで [転送ヘッダ] を選択している場合、このフィールドには、呼び出される操作を選択するキーとして使用される値を抽出する転送ヘッダが表示される。
XPath 式	このプロキシサービスについて [選択アルゴリズム] フィールドで [SOAP ヘッダ] を選択している場合、呼び出される操作を選択するキーとして使用される値を抽出する XPath 式がこのフィールドに表示される。
操作のマッピング	このプロキシサービスについて [選択アルゴリズム] フィールドで [転送ヘッダ]、[WS-Addressing]、または [SOAP ヘッダ] を選択している場合、各操作の値がこのフィールドに表示される。この値が操作のキーとして使用される。

セッションの作成または編集をまだ行っていない場合は、左側のナビゲーションペインで、[Change Center] の下にある [作成] をクリックして新しいセッションを作成するか、[編集] をクリックして既存のセッションに入り、現在のコンフィグレーションを変更します。詳細については、「Change Center の使用」を参照してください。

対象のページの [編集] をクリックして、各コンフィグレーションページのフィールドに変更を加えます。各ページとフィールドの詳細については、「プロキシサービスの追加」を参照してください。

注意 : [サービス名] および [サービスの種類] フィールドは変更できません。

以下のいずれか 1 つを実行します。

[戻る] をクリックして、前のページに戻る。
[完了] をクリックして、プロキシサービスを更新する。プロキシサービスが更新されます。

[プロキシサービスの概要] ページが表示されます。

[取り消し] をクリックして変更を取り消し、[プロキシサービスの概要] ページに戻る。

注意 : プロキシサービスは現在のセッション内で更新されます。コンフィグレーションに対する変更が完了したら、左側のナビゲーションペインで、[Change Center] の下にある [アクティブ化] をクリックします。セッションが終了し、コアコンフィグレーションが更新されます。また、セッション中はいつでも [破棄] をクリックすることができ、現在のセッションでこれまでに加えた変更を取り消すことができます。

メッセージフローの概要

メッセージフローは、プロキシサービスの実装を定義します。メッセージフローには、パイプラインペア、および開始ノード、ルートノード、エコーノード、ブランチノードを入れることができます。メッセージフローの実装方法については、「メッセージフローの表示と変更」を参照してください。

この節の内容は以下のとおりです。

パイプライン

パイプラインとは、分岐のない一方向の処理の流れを表す名前付きのステージシーケンスです。

パイプラインは以下の 3 種類です。

表 14-24 パイプラインのカテゴリ

パイプラインのカテゴリ	説明
要求	要求パイプラインは、メッセージフローの要求パスの処理に使用される。
応答	応答パイプラインは、メッセージフローの応答パスの処理に使用される。
エラー	エラーパイプラインはエラーハンドラとして使用される。

要求パスと応答パスを作成するには、要求パイプラインと応答パイプラインをペアにして、単一ルートのツリー構造に整理します。ブランチノードを使用すると、これらのパイプラインペアを条件付きで実行して、ブランチ末尾のルートノードで要求と応答のディスパッチを実行できます。ツリー構造になっているため、メッセージフローの動作概要が明瞭になり、ルートアクションとブランチ条件の両方を、パイプラインステージの奥深くに埋め込むのではなく、全体的な設計の明確な一部とすることができます。

メッセージフローツリーは、以下の 3 つの最上位コンポーネントインスタンスを連鎖させた構造になっています。

表 14-25 パイプラインのカテゴリ

パイプラインのカテゴリ	説明
パイプラインペアノード	パイプラインペアノードは、1 つの要求パイプラインと 1 つの応答パイプラインを 1 つの最上位要素に結び付けたものである。メッセージフローツリーでは、1 つのパイプラインペアノードに対して設定できる直接の子孫は 1 つだけである。要求処理中にパイプラインペアノードに達すると、要求パイプラインだけが実行される。応答処理のためにパスを逆に辿るときは、応答パイプラインだけが実行される。パイプラインペアノードの追加方法については、「パイプラインペアノードの追加」を参照。
ブランチノード	ブランチノードを使用すると、可能ないくつかのパスのうちの 1 つに限定して処理を進ませることができる。ブランチ処理は、単純でありながらユニークな文字列値のタグが付いたブランチをまとめた簡単なルックアップテーブルを基準に行われる。メッセージコンテキストの変数をそのノードのルックアップ変数として指定し、この値を使用してどのブランチに進むかが判断される。ルックアップ変数に一致するブランチがない場合は、常に存在するデフォルトのブランチに進む。ルックアップ変数の値は、ブランチノードに到達する前に設定する必要がある。このアプローチにより、そのブランチノード自体の中での例外の発生を防ぐことができる。ブランチノードでは、メッセージフローツリー内にいくつかの子孫を持つことができる (デフォルトのブランチを含め各ブランチに 1 つずつ)。ブランチノードの追加方法については、「条件付きブランチノードの追加」を参照。
ルートノード	ルートノードは他のサービスとの要求/応答通信に使用される。ルートノードはプロキシに関する要求処理と応答処理の境界を表す。ルートノードが要求メッセージをディスパッチすると、要求処理が終了したと見なされる。ルートノードが応答メッセージを受信したときに、応答処理が始まる。ルートノード自体が、条件付きルーティング、発信トランスフォーメーション、および応答トランスフォーメーションに対応している。条件は、ルートノード内に配置することも、メッセージフローツリーのブランチノードに配置することもできるため、メッセージフローツリー構造の一部として呼び出す必要があるほどその条件が重要かどうかに応じて配置先を決定できる。ルートノードは要求処理と応答処理の境界を表すので、メッセージフローツリー内に子孫を持つことはできない。ルートノードの追加方法については、「ルートノードの追加」を参照。
エコーノード	エコーノードとは、要求パイプラインの最後から要求パイプラインの先頭にメッセージをルーティング (エコー) するノードである。つまり、メッセージは、プロキシサービスから別のサービスへルーティングされずに、プロキシサービス内部に残る。

メッセージの実行

次の表はメッセージの流れをまとめたものです。

表 14-26 メッセージの流れ

ノード	メッセージに対する処理
要求処理	要求処理はメッセージフローツリーのルートで開始される。
パイプラインペア	要求パイプラインだけが実行される。
ブランチ	ルックアップテーブルを評価して関連するブランチに進む。
ルート	発信/応答トランスフォーメーションとルーティングが実行される。注意 : ルートノードでは、ルーティングが実行されたかどうかに関係なく、要求処理から応答処理に変更される。応答を受信すると、要求時に使用されていたパスを逆に辿る。ルートノードなしで要求パスが終了する場合にも同じ操作が行われる。つまり、応答を待たずに、応答処理が開始され、ツリーへと戻る。
応答処理	「ルート」を参照。
パイプラインペア	応答パイプラインが実行される。
ブランチ	ブランチの前の要素に進む。
ツリーのルート	クライアントに応答を送信して戻す。

メッセージフローツリーの構築

メッセージフローツリーのルートには、任意の要素を配置できます。最も単純なメッセージフロー設計の 1 つに、ツリー最上位にルートノードを置いて、ツリー全体を表す方法があります。任意の 2 つの要素を連鎖できます。たとえば、間にブランチノードを置かずに、2 つのパイプラインペアノードを連鎖させることもできます。ブランチの構成に関しては、各ブランチを別々の要素で開始することができます。たとえば、1 つのブランチが直ちにルートノードで終了し、もう 1 つのブランチにはパイプラインペアが続き、さらにもう 1 つのブランチには子孫が何もないようにできます。この最後の例のように子孫のないブランチは、選択されると、すぐに応答処理が開始されます。ただし、一般的には、メッセージフローツリーの多くは次の 2 つの形式で使用されます。まず、非オペレーションサービスの場合のツリーは、ルートに単一のパイプラインペアがあり、それにルートノードが続く形式が一般的です。また、オペレーションサービスの場合のツリーは、同じくルートに単一のパイプラインペアがあり、処理に基づくブランチノードがそれに続く形式で、さらに各ブランチにはパイプラインペアが 1 つあり、その後にルートノードが続くのが一般的です。

オペレーションブランチ

通常、メッセージフローは WSDL ベースのサービスで使用されるため、処理固有の処理が必要なことがよくあります。AquaLogic Service Bus では、処理に基づくブランチノードを手動でコンフィグレーションする必要はなく、操作に基づいて自動的にブランチ処理を行うコンフィグレーション不要のブランチノードが用意されています。ブランチは、サービスで定義された各処理について作成されます。ブランチ変数は $operation です。

オペレーションブランチノードの追加方法については、「オペレーションブランチノードの追加」を参照してください。

メッセージフローの表示と変更

[メッセージフローの編集] ページでは、特定のプロキシサービスに関するメッセージフローを表示したり変更したりできます。メッセージフローの詳細については、「メッセージフローの概要」を参照してください。プロキシサービスの詳細については、「プロキシサービスの概要」を参照してください。

メッセージフローを表示および変更するには

または、[プロジェクトエクスプローラ] の下でプロジェクトまたはフォルダを選択して、プロジェクトまたはフォルダのリソースリストを表示することもできます。

[プロキシサービスの概要] ページで、対象プロキシサービスの [メッセージフローの編集] アイコンをクリックします。

プロジェクトまたはフォルダを選択した場合は、リソースのリストで該当するプロキシサービスの [メッセージフローの編集] アイコンをクリックします。
[メッセージフローの編集] ページが表示されます。このページには以下の機能があります。

プロキシサービスの開始ノードを示すアイコン。このアイコンをクリックして、パイプラインペアノード、ルートノード、条件付きブランチ、オペレーションブランチ、およびサービスのエラー処理を追加できます。
プロキシサービスのエコーノード (終了ノード) を示すアイコン。このノードはルートノードに変換できます。
メッセージフロー内の各種オブジェクトに関連付けられたページにリンクされている、左側のナビゲーションペインのメッセージフローのマップ。オブジェクト名をクリックすると、そのオブジェクトに関連付けられたページが表示されます。オブジェクトを追加すると、左側のナビゲーションペインのメッセージフローマップに適切なリンクが追加されます。このプロキシサービスに関するメッセージフローをまだ作成していない場合は、メッセージフローに [メッセージフローの編集] ページへのリンクだけが表示されます。

以下のいずれか 1 つを実行します。

表 14-27 [メッセージフローの編集] ページ

処理	手順
パイプラインペアノードの追加	開始ノードアイコンをクリックし、[パイプラインペアの追加] をクリックする。詳細については、「パイプラインペアノードの追加」を参照。
ルートノードの追加	開始ノードアイコンをクリックし、[ルートノードの追加] をクリックする。詳細については、「ルートノードの追加」を参照。
条件付きブランチノードの追加	開始ノードアイコンをクリックし、[条件付きブランチノードの追加] をクリックする。詳細については、「条件付きブランチノードの追加」を参照。
オペレーションブランチノードの追加	開始ノードアイコンをクリックし、[オペレーションブランチノードの追加] をクリックする。詳細については、「オペレーションブランチノードの追加」を参照。
このプロキシサービスへのエラー処理の追加	開始ノードアイコンをクリックし、[サービスエラーハンドラの追加] をクリックする。詳細については、「プロキシサービスへのエラー処理の追加」を参照。
エコーノードからルートノードへの変換	[エコーノード] アイコンをクリックし、[ルートノードに変換] をクリックする。詳細については、「ルートノードの追加」を参照。
更新した内容を保存して [プロキシサービスの概要] ページに戻る	[保存] をクリックする。
変更を取り消して [プロキシサービスの概要] ページに戻る	[取り消し] をクリックする。
[メッセージフローの編集] ページを開いたまま変更をクリアする	[クリア] をクリックする。

注意 : [保存] をクリックすると、メッセージフローは現在のセッション内で更新されます。コンフィグレーションに対する変更が完了したら、左側のナビゲーションペインで、[Change Center] の下にある [アクティブ化] をクリックします。セッションが終了し、コアコンフィグレーションが更新されます。また、セッション中はいつでも [破棄] をクリックすることができ、現在のセッションでこれまでに加えた変更を取り消すことができます。

パイプラインペアノードの追加

[メッセージフローの編集] ページでは、パイプラインペアノードを追加できます。パイプラインペアノードは要求パイプラインと応答パイプラインから成ります。メッセージフローには、パイプラインペアノード (プロキシサービス、またはサービスの処理用の要求パイプラインと応答パイプライン) と、ステージ、パイプライン、およびプロキシサービスに対して定義できるエラーハンドラをゼロ個以上入れることができます。パイプラインには、1 つまたは複数のステージを入れることができ、ステージにはアクションを入れることができます。詳細については、「メッセージフローの概要」を参照してください。

パイプラインペアノードを追加するには

[プロキシサービスの概要] ページの [リソースブラウザ] で、対象プロキシサービスの [メッセージフローの編集] アイコンをクリックします。または、[プロジェクトエクスプローラ] モジュールを使用している場合は、選択したプロジェクトまたはフォルダのリソースのリストで該当するプロキシサービスの [メッセージフローの編集] アイコンをクリックします。
選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。このページには以下の機能があります。

プロキシサービスの開始ノードを示すアイコン。このアイコンをクリックして、パイプラインペアノード、ルートノード、条件付きブランチ、オペレーションブランチ、およびサービスのエラー処理を追加できます。
プロキシサービスのエコーノード (終了ノード) を示すアイコン。このノードはルートノードに変換できます。
メッセージフロー内の各種オブジェクトに関連付けられたページにリンクされている、左側のナビゲーションペインのメッセージフローのマップ。

開始ノード アイコンをクリックし、[パイプラインペアの追加] をクリックします。

パイプラインペアノード アイコン、[名前] フィールド、および [説明] フィールドが表示されます。

[名前] フィールドにパイプラインペアノード名を入力します。

[説明] フィールドにパイプラインペアノードの説明を入力します。

以下のいずれか 1 つを実行します。

[保存] をクリックして、パイプラインペアノードを保存する。

[メッセージフローの編集] ページに、パイプラインペアノード アイコンとそのパイプラインペアノードに割り当てられた名前が表示されます。

[取り消し] をクリックして変更を取り消し、[プロキシサービスの概要] ページに戻る。

パイプラインペアノードを保存したら、以下のいずれか 1 つを実行します。

表 14-28 パイプラインペアノード

処理	手順
パイプラインへのステージの追加	適切な要求パイプラインまたは応答パイプラインをクリックし、[ステージの追加] をクリックする。詳細については、「ステージの追加」を参照。
パイプラインへのアクションの追加	ステージをすでに作成している場合は、対象のパイプラインのステージアイコンをクリックし、[編集｜ステージ] をクリックする。詳細については、「アクションの追加」を参照。
別のパイプラインペアノードの追加	作成したパイプラインペアのパイプラインペアノードアイコンをクリックし、[追加｜パイプラインペアの追加] をクリックする。または、開始ノードアイコンをもう一度クリックして、[パイプラインペアの追加] をクリックする。
ルートノードの追加	作成したパイプラインペアのパイプラインペアノードアイコンをクリックし、[追加｜ルートノードの追加] をクリックする。詳細については、「ルートノードの追加」を参照。
条件付きブランチノードの追加	作成したパイプラインペアのパイプラインペアノードアイコンをクリックし、[追加｜条件付きブランチノードの追加] をクリックする。詳細については、「条件付きブランチノードの追加」を参照。
このプロキシサービスへのエラー処理の追加	開始ノードアイコンをクリックし、[サービスエラーハンドラの追加] をクリックする。詳細については、「プロキシサービスへのエラー処理の追加」を参照。
エコーノードからルートノードへの変換	[エコーノード] アイコンをクリックし、[ルートノードに変換] をクリックする。詳細については、「ルートノードの追加」を参照。
パイプラインペアノード名と説明の編集	作成したパイプラインペアのパイプラインペアノードアイコンをクリックし、[編集｜名前と説明] をクリックする。注意 : パイプライン名またはルートノード名を変更すると、パイプライン数がゼロにリセットされるため、[モニタ] モジュールのダッシュボードページに表示されるメッセージ数が他のコンポーネントのメッセージ数と相関しなくなる場合がある。これは、AquaLogic Service Bus では、いったん削除して再作成するアクションとして名前の変更を処理しているためである。サービスのモニタ間隔と同じ時間が経過すると、メッセージ数は再び相関するようになる。
パイプラインペアノードの削除	作成したパイプラインペアのパイプラインペアノードアイコンをクリックし、[削除] をクリックする。
更新した内容を保存して [プロキシサービスの概要] ページに戻る	[保存] をクリックする。
変更を取り消して [プロキシサービスの概要] ページに戻る	[取り消し] をクリックする。
[メッセージフローの編集] ページを開いたまま変更をクリアする	[クリア] をクリックする。

条件付きブランチノードの追加

[メッセージフローの編集] ページでは、条件付きブランチノードを追加できます。ブランチノードを使用すると、可能ないくつかのパスのうちの 1 つに限定して処理を進ませることができます。詳細については、「メッセージフローの概要」を参照してください。

条件付きブランチノードを追加するには

[プロキシサービスの概要] ページで、対象プロキシサービスの [メッセージフローの編集] アイコンをクリックします。または、[プロジェクトエクスプローラ] モジュールを使用している場合は、選択したプロジェクトまたはフォルダのリソースのリストで該当するプロキシサービスの [メッセージフローの編集] アイコンをクリックします。

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。このページには以下の機能があります。

プロキシサービスの開始ノードを示すアイコン。このアイコンをクリックして、パイプラインペアノード、ルートノード、条件付きブランチ、オペレーションブランチ、およびサービスのエラー処理を追加できます。
プロキシサービスのエコーノード (終了ノード) を示すアイコン。このノードはルートノードに変換できます。
メッセージフロー内の各種オブジェクトに関連付けられたページにリンクされている、左側のナビゲーションペインのメッセージフローのマップ。
パイプラインペアノードやサービスエラーハンドラのアイコン (追加している場合)。

開始ノード アイコンをクリックし、[条件付きブランチノードの追加] を選択します。または、既存のパイプラインペアのパイプラインペアノード アイコンをクリックし、[追加｜条件付きブランチノードの追加] をクリックします。

条件付きブランチノード アイコン、[名前] フィールド、および [説明] フィールドが表示されます。

[名前] フィールドにブランチノード名を入力します。

[説明] フィールドにブランチノードの説明を入力します。

以下のいずれか 1 つを実行します。

[保存] をクリックして、ブランチノードを保存する。

条件付きブランチノード アイコンとそのブランチノードに割り当てた名前が表示されます。

[取り消し] をクリックして、変更を取り消す。

ブランチの定義を追加するために、対象のブランチノードを選択し、[編集｜ブランチノード] をクリックします。[ブランチノードの編集] ページが表示されます。

[ブランチ定義] パネルで、以下を実行します。

[選択したパス] フィールドで [編集] をクリックして、XPath 式を追加します。詳細については、「XPath 式の編集」を参照してください。

[変数] フィールドにコンテキスト変数を入力します。

[演算子] フィールドで、[=]、[!=]、[<]、[>]、[<=]、[>=] のいずれかを選択します。

[値] フィールドにブランチの値を入力します。

[ラベル] フィールドにブランチのラベルを入力します。

以下のいずれか 1 つを実行します。

表 14-29 条件付きブランチノードの追加

処理	手順
別のブランチ定義の追加	[オプション] カラムのポップアップメニューにある [新しいブランチの追加] をクリックする。
ブランチ定義の削除	[オプション] カラムのポップアップメニューにある [このブランチを削除] をクリックする。
定義リスト下方向へのブランチの移動	[オプション] カラムのポップアップメニューにある [ブランチを下に移動] をクリックする。注意 : このオプションは、複数のブランチ定義が存在する場合にのみ表示される。
定義リスト上方向へのブランチの移動	[オプション] カラムのポップアップメニューにある [ブランチを上に移動] をクリックする。注意 : このオプションは、複数のブランチ定義が存在する場合にのみ表示される。

定義操作を完了したら、以下のいずれか 1 つを実行します。

[保存] をクリックして、ブランチを更新する。

[メッセージフローの編集] ページが表示されます。

[取り消し] をクリックして変更を取り消し、[メッセージフローの編集] ページに戻る。
[クリア] をクリックして、[ブランチノードの編集] ページを開いたままで、変更を取り消す。

ブランチノードを保存したら、以下のいずれか 1 つを実行します。

表 14-30 条件付きブランチノードの追加

処理	手順
パイプラインペアノードの追加	開始ノードアイコンをクリックし、[パイプラインペアの追加] をクリックする。詳細については、「パイプラインペアノードの追加」を参照。
既存のパイプラインへのステージの追加	対象の要求パイプラインまたは応答パイプラインをクリックして、[ステージの追加] をクリックする。詳細については、「ステージの追加」を参照。
既存のパイプラインへのアクションの追加	対象のパイプラインのステージアイコンをクリックし、[編集｜ステージ] をクリックする。詳細については、「アクションの追加」を参照。
このプロキシサービスへのエラー処理の追加	開始ノードアイコンをクリックし、[サービスエラーハンドラの追加] をクリックする。詳細については、「プロキシサービスへのエラー処理の追加」を参照。
ブランチノード名と説明の編集	条件付きブランチアイコンをクリックし、[編集｜名前と説明] をクリックする。
ブランチ定義の編集	条件付きブランチアイコンをクリックし、[編集｜ブランチノード] をクリックする。
ブランチノードの削除	条件付きブランチアイコンをクリックし、[ブランチノードの削除] をクリックする。
更新した内容を保存して [プロキシサービスの概要] ページに戻る	[保存] をクリックする。
変更を取り消して [プロキシサービスの概要] ページに戻る	[取り消し] をクリックする。
[メッセージフローの編集] ページを開いたまま変更をクリアする	[クリア] をクリックする。

オペレーションブランチノードの追加

[メッセージフローの編集] ページでは、オペレーションブランチノードを追加できます。

オペレーションブランチノードを追加するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。このページには以下の機能があります。

プロキシサービスの開始ノードを示すアイコン。このアイコンをクリックして、パイプラインペアノード、ルートノード、条件付きブランチ、オペレーションブランチ、およびサービスのエラー処理を追加できます。
プロキシサービスのエコーノード (終了ノード) を示すアイコン。このノードはルートノードに変換できます。
メッセージフロー内の各種オブジェクトに関連付けられたページにリンクされている、左側のナビゲーションペインのメッセージフローのマップ。
パイプラインペアノードやサービスエラーハンドラのアイコン (追加している場合)。

開始ノード アイコンをクリックし、[オペレーションブランチノードの追加] を選択します。オペレーションブランチ アイコン、[名前] フィールド、および [説明] フィールドが表示されます。

[名前] フィールドにブランチ名を入力します。

[説明] フィールドにブランチの説明を入力します。

以下のいずれか 1 つを実行します。

[保存] をクリックして、ブランチを保存する。

オペレーションブランチ アイコンとそのブランチに割り当てられた名前が表示されます。

[取り消し] をクリックして、変更を取り消す。

[オペレーションブランチ定義] パネルで、サービスの処理を選択します。

以下のいずれか 1 つを実行します。

表 14-31 オペレーションブランチノードの追加

処理	手順
別のブランチ定義の追加	[オプション] カラムのポップアップメニューにある [新しいブランチの追加] をクリックする。
ブランチ定義の削除	[オプション] カラムのポップアップメニューにある [このブランチを削除] をクリックする。
定義リスト下方向へのブランチの移動	[オプション] カラムのポップアップメニューにある [ブランチを下に移動] をクリックする。注意 : このオプションは、複数のブランチ定義が存在する場合にのみ表示される。
定義リスト上方向へのブランチの移動	[オプション] カラムのポップアップメニューにある [ブランチを上に移動] をクリックする。注意 : このオプションは、複数のブランチ定義が存在する場合にのみ表示される。

定義操作を完了したら、以下のいずれか 1 つを実行します。

[保存] をクリックして、ブランチを更新する。

[メッセージフローの編集] ページが表示されます。

[取り消し] をクリックして変更を取り消し、[メッセージフローの編集] ページに戻る。
[クリア] をクリックして、[ブランチノードの編集] ページを開いたままで、変更を取り消す。

ブランチノードを保存したら、以下のいずれか 1 つを実行します。

表 14-32 オペレーションブランチノードの追加

処理	手順
パイプラインペアノードの追加	開始ノードアイコンをクリックし、[パイプラインペアの追加] をクリックする。詳細については、「パイプラインペアノードの追加」を参照。
既存のパイプラインへのステージの追加	適切な要求パイプラインまたは応答パイプラインをクリックし、[ステージの追加] をクリックする。詳細については、「ステージの追加」を参照。
既存のパイプラインへのアクションの追加	対象のパイプラインのステージアイコンをクリックし、[編集｜ステージ] をクリックする。詳細については、「アクションの追加」を参照。
条件付きブランチノードの追加	開始ノードアイコンをクリックし、[条件付きブランチノードの追加] をクリックする。詳細については、「条件付きブランチノードの追加」を参照。
ルートノードの追加	開始ノードアイコンをクリックし、[ルートノードの追加] をクリックする。詳細については、「ルートノードの追加」を参照。
このプロキシサービスへのエラー処理の追加	開始ノードアイコンをクリックし、[サービスエラーハンドラの追加] をクリックする。詳細については、「プロキシサービスへのエラー処理の追加」を参照。
ブランチノード名と説明の編集	オペレーションブランチアイコンをクリックし、[編集｜名前と説明] をクリックする。
ブランチ定義の編集	オペレーションブランチアイコンをクリックし、[編集｜ブランチノード] をクリックする。
ブランチノードの削除	オペレーションブランチアイコンをクリックし、[ブランチノードの削除] をクリックする。
更新した内容を保存して [プロキシサービスの概要] ページに戻る	[保存] をクリックする。
変更を取り消して [プロキシサービスの概要] ページに戻る	[取り消し] をクリックする。
[メッセージフローの編集] ページを開いたまま変更をクリアする	[クリア] をクリックする。

ステージの追加

[メッセージフローの編集] ページでは、ステージを追加できます。ステージはアクションのコンテナです。詳細については、「メッセージフローの概要」を参照してください。

注意 : ステージを追加する前に、パイプラインペアノードを作成する必要があります。詳細については、「パイプラインペアノードの追加」を参照してください。

ステージを追加するには

[メッセージフローの編集] ページが表示されます。

既存のパイプラインペアノードを展開して、要求パイプラインと応答パイプラインから成るパイプラインペアを表示します。

ステージを追加するパイプラインをクリックして、[ステージの追加] をクリックします。

ステージ アイコン、[名前] フィールド、および [説明] フィールドが表示されます。

[名前] フィールドでステージのデフォルト名を受け入れるか、別の名前を入力します。

[説明] フィールドにステージの説明を入力します。

以下のいずれか 1 つを実行します。

[保存] をクリックして、ステージを保存する。

[メッセージフローの編集] ページに、ステージ アイコンとそのステージに割り当てた名前が表示されます。

[取り消し] をクリックして変更を取り消し、[メッセージフローの編集] ページに戻る。

ステージを保存したら、以下のいずれか 1 つを実行します。

表 14-33 ステージの追加

処理	手順
アクションの追加	ステージアイコンをクリックし、[編集｜ステージ] をクリックする。詳細については、「アクションの追加」を参照。
このパイプラインへのエラー処理の追加	パイプラインをクリックし、[パイプラインエラーハンドラの追加] をクリックする。詳細については、「パイプラインへのエラー処理の追加」を参照。
別のパイプラインペアの追加	開始ノードアイコンをクリックし、[パイプラインペアの追加] をクリックする。または、既存のパイプラインペアノードアイコンをクリックし、[追加｜パイプラインペアの追加] をクリックする。詳細については、「パイプラインペアノードの追加」を参照。
ルートノードの追加	パイプラインペアノードアイコンをクリックし、[追加｜ルートノードの追加] をクリックする。詳細については、「ルートノードの追加」を参照。
条件付きブランチノードの追加	パイプラインペアノードアイコンをクリックし、[追加｜条件付きブランチノードの追加] をクリックする。詳細については、「条件付きブランチノードの追加」を参照。
このプロキシサービスへのエラー処理の追加	開始ノードアイコンをクリックし、[サービスエラーハンドラの追加] をクリックする。詳細については、「プロキシサービスへのエラー処理の追加」を参照。
エコーノードからルートノードへの変換	[エコーノード] アイコンをクリックし、[ルートノードに変換] をクリックする。詳細については、「ルートノードの追加」を参照。
ステージ名と説明を編集する	ステージアイコンをクリックし、[編集｜名前と説明] をクリックする。
ステージの削除	該当するステージアイコンをクリックし、[削除] をクリックする。
更新した内容を保存して [プロキシサービスの概要] ページに戻る	[保存] をクリックする。
変更を取り消して [プロキシサービスの概要] ページに戻る	[取り消し] をクリックする。
[メッセージフローの編集] ページを開いたまま保存前の変更をクリアする	[クリア] をクリックする。

アクションの追加

[ステージコンフィグレーションの編集] ページでは、アクションを追加できます。アクションとは、プロキシサービスを通過するメッセージの処理を定義するパイプラインステージの要素です。メッセージフローの詳細については、「メッセージフローの概要」を参照してください。

注意 : アクションを追加する前に、パイプラインペアノードを作成し、ステージを追加する必要があります。詳細については、「パイプラインペアノードの追加」および「ステージの追加」を参照してください。

アクションを追加するには

[メッセージフローの編集] ページが表示されます。

既存のパイプラインを展開して、要求パイプラインと応答パイプラインから成るパイプラインを表示します。

アクションを追加する既存のステージのステージ アイコンをクリックし、[編集｜ステージ] をクリックします。[ステージコンフィグレーションの編集] ページが表示されます。

[アクションの追加] をクリックし、アクションの種類を選択して、アクションを追加します。次の表は、アクションの種類とコンフィグレーションの手順をまとめたものです。

注意 : アクションの使用例、設計パターン、ベストプラクティスについては、『BEA AquaLogic Service Bus ユーザーズガイド』の「AquaLogic Service Bus でのメッセージフローの作成」を参照してください。

表 14-34 アクションの追加

処理	手順
割り当て	コンテキスト変数に XQuery 式の結果を割り当てる。 1. [アクションの追加] をクリックし、[割り当てる] を選択する。割り当てアクションが表示される。このアクションには以下の機能がある。 [割り当てる] アイコン XQuery 式編集用の画面に移動するための [式] リンクコンテキスト変数を入力するための [変数] フィールド 2. [式] をクリックする。[XQuery 式の編集] ページが表示される。詳細については、「XQuery 式の編集」を参照。 3. 式を編集したら、[変数] フィールドにコンテキスト変数を入力する。コンテキスト変数の詳細については、「メッセージコンテキスト」を参照。 4. 次の手順に進む。
削除	コンテキスト変数または XPath 式で指定されたすべてのノードを削除する。 1. [アクションの追加] をクリックし、[削除する] を選択する。削除アクションが表示される。このアクションには以下の機能がある。 [削除する] アイコン [変数] フィールドと、それに対応したラジオボタン XPath 式編集用の画面に移動するための [XPath] リンク (およびそれに対応したラジオボタン) と、XPath 式を実行するコンテキスト変数を指定する [変数] フィールド 2. コンテキスト変数を削除するには、このオプションに関連付けられたラジオボタンを選択し、[変数] フィールドにコンテキスト変数を入力する。コンテキスト変数の詳細については、「メッセージコンテキスト」を参照。また、XPath 式で選択されたすべてのノードを削除するには、このオプションに関連付けられたラジオボタンを選択し、[XPath] をクリックする。[XPath 式の編集] ページが表示される。詳細については、「XPath 式の編集」を参照。式を保存したら、[変数] フィールドにコンテキスト変数を入力する。コンテキスト変数の詳細については、「メッセージコンテキスト」を参照。 3. 次の手順に進む。注意 : 削除アクションは更新アクションの 1 つ。詳細については、「更新アクション」を参照。
If... Then...	XQuery 式のブール結果に基づいて if then else アクションを実行する。注意 : 条件アクションはネスト可能。ただし、ステージエディタでは、ネストは 4 累積レベルまでに制限されている。5 番目のレベルを追加しようとしても、そのネストアクションは表示されない。累積レベルには、すべてのブランチアクション (If...Then... 条件、パブリッシュテーブル、ルートテーブル) が含まれる。たとえば、2 レベルの条件と、ルートテーブルを含むパブリッシュテーブルを使用して、合計 4 レベルにすることができる。ただし、別の条件を追加 (最後のパブリッシュテーブルに対して) すると、その条件は表示されない。 1. [アクションの追加] をクリックし、[If...Then...] を選択する。 If... Then... アクションが表示される。このアクションには以下の機能がある。 [If...Then...] アイコン If... (<条件>) then... (条件の編集画面に移動するリンク) [アクションの追加] オプション 2. [条件] をクリックする。[XQuery 条件の編集] ページが表示される。詳細については、「XQuery 条件の編集」を参照。 3. XQuery 条件を編集したら、[アクションの追加] をクリックしてから、その条件に関連付けるアクションを選択する。追加するアクションの種類の詳細については、この表で該当する手順を参照。 4. 必要に応じて [If...Then...] アイコンをクリックして、else-if 条件または else 条件を追加し、[アクションの追加] をクリックして、これらの条件にアクションを関連付ける。 5. 次の手順に進む。
挿入	XPath 式で選択したノードを基準に指定した位置に XQuery 式を挿入する。 1. [アクションの追加] をクリックし、[挿入する] を選択する。挿入アクションが表示される。このアクションには以下の機能がある。 [挿入する] アイコン XQuery 式編集用の画面に移動するための [式] リンク相対的な位置を選択するためのドロップダウンリスト XPath 式編集用の画面に移動するための [XPath] リンクコンテキスト変数を入力するための [変数] フィールド 2. [式] をクリックする。[XQuery 式の編集] ページが表示される。詳細については、「XQuery 式の編集」を参照。 3. 式を編集したら、ドロップダウンリストで相対的な位置を選択する。相対的な位置は、XPath 式の結果を基準として挿入位置を決める場合に使用する。 [の前に] - XPath 式で選択される各要素や属性の兄とする。 [の後ろに] - XPath 式で選択される各要素や属性の弟とする。 [の最初の子として] - XPath 式で指定される各要素の第 1 の子とする (XPath が属性を指定している場合はエラー)。 [の最後の子として] - XPath 式で指定される各要素の最後の子とする (XPath が属性を指定している場合はエラー)。 4. [XPath] をクリックする。[XPath 式の編集] ページが表示される。詳細については、「XPath 式の編集」を参照。 5. XPath 式を編集したら、[変数] フィールドにコンテキスト変数を入力する。コンテキスト変数の詳細については、「メッセージコンテキスト」を参照。 6. 次の手順に進む。注意 : XQuery 式と XPath 式は両方とも要素を返す必要がある。ただし、XPath 式が要素を返さない場合、XQuery 式は属性を返す必要がある。注意 : 挿入アクションは更新アクションの 1 つ。詳細については、「更新アクション」を参照。
ログ	メッセージのログに使用する一連の属性を定義する。 1. [アクションの追加] をクリックし、[ログ] をクリックする。ログアクションが表示される。このアクションには以下の機能がある。 [ログ] アイコン XQuery 式編集用の画面に移動するための [式] リンクこのログアクションのメモを入力するための [アノテーション] フィールド。このメモは、事前に定義された式の結果と一緒にログに記録される。ロギングレベルを選択するための [アノテーションの重大度] ドロップダウンリスト 2. [式] をクリックする。[XQuery 式の編集] ページが表示される。コンテキスト変数の XQuery 式を通じてログに記録するメッセージコンテキストを指定する。詳細については、「XQuery 式の編集」を参照。 3. [アノテーション] フィールドに、このログアクションのメモを入力する。 4. [アノテーションの重大度] ドロップダウンリストで、以下のいずれかのレベルを選択する。 [情報] [警告] [エラー] [デバッグ] 5. 次の手順に進む。
パブリッシュ	メッセージの対象サービスを指定し、メッセージのパッケージ化の方法とサービスへの送信方法をコンフィグレーションする。 1. [アクションの追加] をクリックし、[パブリッシュ] を選択する。パブリッシュアクションが表示される。このアクションには以下の機能がある。 [パブリッシュ] アイコンサービス選択用の画面に移動するための [サービス] リンク要求アクションを追加するためのフィールド 2. [サービス] をクリックする。[サービスブラウザ] が表示される。 3. リストからサービスを選択してから、[送信] をクリックする。そのサービスがデフォルトのリンクの代わりに表示される。これがメッセージの対象サービスとなる。 4. メッセージのパッケージ化の方法とサービスへの送信方法をコンフィグレーションするために、[要求アクション] フィールドの [アクションの追加] をクリックし、サービスに関連付けるアクションを選択する。複数のアクションを追加することも可能。追加するアクションの種類の詳細については、この表で該当する手順を参照。 5. 必要に応じてアクションの追加を続行する。要求アクションを追加したら、次の手順に進む。注意 : パブリッシュアクションまたはパブリッシュテーブルアクションの結果としてメッセージが別のサービスにパブリッシュされるときのデフォルトのサービス品質 (QoS) は、プロキシサービス着信転送と発信パブリッシュアクションで JMS/XA 転送を使用している場合は「best effort」になる。「best effort」では、メッセージ処理の信頼性が低く、メッセージの重複が防止されないが、パフォーマンスは最適化される。デフォルトの「best effort」サービス品質属性をオーバーライドするには、発信メッセージのコンテキスト変数 (`$outbound`) に `qualityOfService` を設定する必要がある。詳細については、「メッセージコンテキストスキーマ」を参照。「exactly once」の信頼性については、「ルートノードの追加」を参照。サービス品質の詳細については、『BEA AquaLogic Service Bus ユーザーズガイド』の「AquaLogic Service Bus でのメッセージフローの作成」を参照。注意 : 各パブリッシュ要求トランスフォーメーションでは、メッセージコンテキストのローカルコピーが独自に保持される。詳細については、「送信するメッセージの作成」の「シナリオ例」を参照。
パブリッシュテーブル	パブリッシュテーブルとは、切り替え式の条件テーブルに含まれる一連のルートであり、単一の XQuery 式の結果に基づいて各種ルートを選択できる簡単な構文である。注意 : ステージエディタでは、ネストは 4 累積レベルまでに制限されている。5 番目のレベルを追加しようとしても、そのネストアクションは表示されない。累積レベルには、すべてのブランチアクション (If...Then... 条件、パブリッシュテーブル、ルートテーブル) が含まれる。たとえば、2 レベルの条件と、ルートテーブルを含むパブリッシュテーブルを使用して、合計 4 レベルにすることができる。ただし、別の条件を追加 (最後のパブリッシュテーブルに対して) すると、その条件は表示されない。メッセージの対象サービスを指定し、メッセージのパッケージ化の方法とサービスへの送信方法をコンフィグレーションする。 1. [アクションの追加] をクリックし、[パブリッシュテーブル] を選択する。パブリッシュテーブルアクションが表示される。このアクションには以下の機能がある。 [パブリッシュテーブル] アイコン、XQuery 式編集用の画面に移動するための [式] リンク、新しいケースを挿入するためのひし形アイコン、比較演算子を入力するためのフィールド、値を入力するためのフィールド、サービス選択用の画面に移動するための [サービス] リンク、要求アクションを追加するためのフィールド。 2. [式] をクリックする。[XQuery 式の編集] ページが表示される。詳細については、「XQuery 式の編集」を参照。 3. いずれかの比較演算子を選択する ([=]、[!=]、[<]、または [>])。 4. 所定のフィールドに値を入力する。 5. [サービス] をクリックする。[サービスブラウザ] が表示される。 6. リストからサービスを選択してから、[送信] をクリックする。そのサービスがデフォルトのリンクの代わりに表示される。これがメッセージの対象サービスとなる。 7. メッセージのパッケージ化の方法とサービスへの送信方法をコンフィグレーションするために、[要求アクション] フィールドの [アクションの追加] をクリックし、サービスに関連付けるアクションを選択する。複数のアクションを追加することも可能。追加するアクションの種類の詳細については、この表で該当する手順を参照。 8. 必要に応じてアクションの追加を続行する。アクションを追加したら、次の手順に進む。 9. 新しいケースを挿入する場合は、ひし形アイコンをクリックし、[新しいケースの挿入] を選択する。 10. 新しいケースについて、手順 3 ～ 8 を繰り返す。注意 : 最後に定義したケースのひし形アイコンをクリックして、[デフォルトケースの挿入] を選択すると、それ以前のすべてのケースが満たされなかった場合に選択されるルートとしてデフォルトのケースを最後に追加できる。 11. ケースを追加したら、次の手順に進む。
エラーを発生させる	指定したエラーコード (文字列) と説明を使用して例外を発生させる。 1. [アクションの追加] をクリックし、[エラーを発生させる] を選択する。エラー発生アクションが表示される。このアクションには以下の機能がある。 [エラーを発生させる] アイコンエラーコードを入力するための [エラーコード] フィールド (必須) エラーの説明を入力するための [エラーメッセージ] フィールド 2. [エラーコード] フィールドに、発生させるエラーコードを入力する。 3. [使用するエラーメッセージ] の下のフィールドに、エラーコードの説明を入力する。 4. 次の手順に進む。注意 : エラー処理アクションの詳細については、「エラーメッセージと処理」を参照。
名前変更	コンテンツを変更せずに、XPath で選択した要素の名前を変更する。 1. [アクションの追加] をクリックし、[名前変更する] を選択する。名前変更アクションが表示される。このアクションには以下の機能がある。 [名前変更する] アイコン XPath 式編集用の画面に移動するための [XPath] リンク [変数] フィールド [ローカル名]、[ネームスペース]、[ローカル名およびネームスペース] のラジオボタンとフィールド 2. [XPath] をクリックする。[XPath 式の編集] ページが表示される。詳細については、「XPath 式の編集」を参照。 3. [変数] フィールドにコンテキスト変数を入力する。コンテキスト変数の詳細については、「メッセージコンテキスト」を参照。 4. 以下のいずれか 1 つを実行する。ローカル名を使用して選択した要素名を変更する場合は、このオプションに関連付けられたラジオボタンを選択して、[ローカル名] フィールドにローカル名を入力する。ネームスペースを使用して選択した要素名を変更する場合は、このオプションに関連付けられたラジオボタンを選択して、[ネームスペース] フィールドにネームスペースを入力する。ローカル名とネームスペースを使用して選択した要素名を変更する場合は、このオプションに関連付けられたラジオボタンを選択して、[ローカル名] フィールドにローカル名を入力し、[ネームスペース] フィールドにネームスペースを入力する。 XPath 式は、属性ではなく、要素を選択する必要がある。 5. 次の手順に進む。注意 : 名前変更アクションは更新アクションの 1 つ。詳細については、「更新アクション」を参照。
置換	XPath 式で指定されたノードを XQuery 式の結果で置換する。 1. [アクションの追加] をクリックし、[置換する] を選択する。置換アクションが表示される。このアクションには以下の機能がある。 [置換する] アイコン XPath 式編集用の画面に移動するための [XPath] リンク XQuery 式編集用の画面に移動するための [式] リンクコンテキスト変数を入力するための [変数] フィールドノードの置換方法を指定する 2 つのラジオボタン 2. [XPath] をクリックする。[XPath 式の編集] ページが表示される。詳細については、「XPath 式の編集」を参照。 3. XPath 式を編集したら、[変数] フィールドにコンテキスト変数を入力する。コンテキスト変数の詳細については、「メッセージコンテキスト」を参照。 4. [式] をクリックする。[XQuery 式の編集] ページが表示される。詳細については、「XQuery 式の編集」を参照。 5. XQuery 式を編集したら、[ノード全体を置換] ラジオボタンを選択して、XPath 式で選択されるノードとそのすべてのコンテンツを置き換えるか、[ノードのコンテンツを置換] ラジオボタンを選択し、ノードはそのままにしてそのコンテンツのみを置き換える。 6. 次の手順に進む。注意 : 置換アクションでは、単純な値や要素を置き換えることができる (XQuery 式では属性を返すことができない)。XPath で属性が指定される場合は、XQuery 式で単純な値に評価する必要がある。XQuery 式から何も返されない場合、指定されたノードが空になるか、指定された属性が削除される。注意 : [ノード全体を置換] オプションを選択して XPath を ./* に設定するよりも、[ノードのコンテンツを置換] オプションを選択して [XPath] フィールドを空白にする方が効率的である。注意 : 置換アクションは更新アクションの 1 つ。詳細については、「更新アクション」を参照。
返信	返信アクションは、要求パイプライン、応答パイプライン、またはエラーパイプラインで使用できる。成功時または失敗時の応答を選択できる。失敗の場合、SOAP では、HTTP 500 エラーが返される。呼び出し元に即時に応答する。 1. [アクションの追加] をクリックし、[返信する] を選択する。返信アクションが表示される。このアクションには以下の機能がある。 [返信する] アイコン [成功時] ラジオボタンと [失敗時] ラジオボタン 2. [成功時] ラジオボタンを選択すると、メッセージが成功した場合に応答する。[失敗時] ラジオボタンを選択すると、メッセージが失敗した場合に応答する。 3. 次の手順に進む。注意 : エラー処理アクションの詳細については、「エラーメッセージと処理」を参照。
レポート	プロキシサービスのメッセージレポートを有効にする。 1. [アクションの追加] をクリックし、[レポート] を選択する。レポートアクションが表示される。このアクションには以下の機能がある。 [レポート] アイコン XQuery 式編集用の画面に移動するための [式] リンクキー名とキー値を追加するためのフィールド 2. [式] をクリックする。[XQuery 式の編集] ページが表示される。詳細については、「XQuery 式の編集」を参照。 3. XQuery 式を編集したら、[キーの追加] をクリックする。[キー名] フィールドと [キー値] フィールドが追加で表示される。[キー値] フィールドには、XPath 式編集用の画面に移動するための [XPath] リンクと [変数] フィールドがある。キーと値の組み合わせは、メッセージコンテキスト変数やメッセージペイロードからキー識別子を抽出して、残りのメッセージを無視する場合に使用する。キーは、メッセージを識別する便利な手段となる。キーは、[レポート] モジュールでレポートインデックスとして表示される。詳細については、「メッセージの表示と検索」および「メッセージの詳細の表示」を参照。 4. [キー名] フィールドに、キーの名前を入力する。 5. [XPath] をクリックする。[XPath 式の編集] ページが表示される。詳細については、「XPath 式の編集」を参照。 6. [変数] フィールドにコンテキスト変数を入力する。詳細については、「メッセージコンテキスト」を参照。 7. さらにキー値を追加するには、キーアイコンをクリックして [キーの追加] を選択する。キーを削除するには、キーアイコンをクリックして [このキーを削除] を選択する。 8. キー値を追加したら、次の手順に進む。
スキップ	ステージの実行をスキップして次のステージに進む。注意 : このアクションにはパラメータがなく、要求パイプライン、応答パイプライン、エラーパイプラインで使用できる。 1. [アクションの追加] をクリックし、[スキップする] を選択する。 [スキップする] アイコンが表示される。 2. 次の手順に進む。
検証	XPath 式により選択される要素を、最上位 XML スキーマ要素または WSDL リソースに対して検証する。 1. [アクションの追加] をクリックし、[検証する] を選択する。検証アクションが表示される。このアクションには以下の機能がある。 [検証する] アイコン XPath 式編集用の画面に移動するための [XPath] リンク要素を入力するための [変数] フィールド XML スキーマや WSDL の型や要素を選択する画面に移動できる [リソース] リンク 2. [XPath] をクリックする。[XPath 式の編集] ページが表示される。詳細については、「XPath 式の編集」を参照。 3. XPath 式を編集したら、[変数] フィールドに要素を入力する。 4. [リソース] をクリックし、[WSDL] または [スキーマ] を選択する。選択に応じて、[WSDL ブラウザ] または [XML スキーマブラウザ] が表示される。 5. WSDL または XML スキーマを選択し、WSDL または XML スキーマの型または要素を選択してから、[送信] をクリックする。 6. この検証結果のブール値を保存する場合は、このオプションに関連付けられたラジオボタンを選択して、[検証結果を変数に保存する] フィールドに変数を入力する。また、WSDL 要素や XML スキーマ要素に対する検証が失敗したときにエラーを発生させる場合は、[検証の失敗時にエラーを発生させる] ラジオボタンを選択する。 7. 次の手順に進む。注意 : 検証アクションではグローバル要素しか検証できない。AquaLogic Service Bus はローカル要素に対する検証には非対応。
Web サービスコールアウト	サービスと処理を指定してコンテキストを入力し、呼び出しの入力パラメータと出力パメータにバインドするコンテキスト変数を入力する。 1. [アクションの追加] をクリックし、[Web サービスコールアウト] を選択する。 Web サービスコールアウトアクションが表示される。このアクションには以下の機能がある。 [Web サービスコールアウト] アイコンサービス選択用の画面に移動するための [サービス] リンク [要求パラメータ] フィールドと [応答パラメータ] フィールド 2. [サービス] をクリックする。[サービスブラウザ] が表示される。 3. リストからサービスを選択してから、[送信] をクリックする。そのサービスがデフォルトのリンクの代わりに表示される。注意 : このサービスには、添付のない SOAP バインディングまたは添付のない XML over HTTP/HTTPS バインディングを含む WSDL が必要。 4. [要求ドキュメント] 変数フィールドに要求ドキュメント変数を入力する。 5. [応答ドキュメント] 変数フィールドに応答ドキュメント変数を入力する。 6. 次の手順に進む。

別のアクションを追加するには、前のアクションのアイコンをクリックして [アクションの追加] をポイントし、アクションを選択します。必要に応じてアクションの追加を続行します。追加するアクションの種類の詳細については、手順 5 の表で該当する手順を参照してください。アクションは任意の組み合わせで連鎖できます。

アクションを追加したら、次の手順に進みます。

以下のいずれか 1 つを実行します。

表 14-35 アクションの追加

処理	手順
アクションを削除する	該当するアイコンをクリックし、[このアクションを削除] をクリックする。アクションが削除される。
アクションを下に移動する	該当するアイコンをクリックし、[アクションを下に移動] をクリックする。アクションがこのステージに含まれる次のアクションの下に移動する。注意 : このオプションは、ステージに複数のアクションが含まれる場合にのみ表示される。
アクションを上に移動する	該当するアイコンをクリックし、[アクションを上に移動] をクリックする。アクションがこのステージに含まれる前のアクションの上に移動する。注意 : このオプションは、ステージに複数のアクションが含まれる場合にのみ表示される。
更新した内容を保存して [メッセージフローの編集] ページに戻る	[保存] をクリックする。
変更を取り消して [メッセージフローの編集] ページに戻る	[取り消し] をクリックする。
[ステージコンフィグレーションの編集] ページを開いたまま保存前の変更をクリアする	[クリア] をクリックする。

アクションを保存したら、以下のいずれか 1 つを実行します。

表 14-36 アクションの追加

処理	手順
既存のパイプラインへのステージの追加	適切な要求パイプラインまたは応答パイプラインをクリックし、[ステージの追加] をクリックする。詳細については、「ステージの追加」を参照。
パイプラインペアノードの追加	開始ノードアイコンをクリックし、[パイプラインペアの追加] をクリックする。または、既存のパイプラインペアノードアイコンをクリックし、[追加｜パイプラインペアの追加] をクリックする。詳細については、「パイプラインペアノードの追加」を参照。
ルートノードの追加	パイプラインペアノードアイコンをクリックし、[追加｜ルートノードの追加] をクリックする。詳細については、「ルートノードの追加」を参照。
条件付きブランチノードの追加	パイプラインペアノードアイコンをクリックし、[追加｜条件付きブランチノードの追加] をクリックする。詳細については、「条件付きブランチノードの追加」を参照。
このプロキシサービスへのエラー処理の追加	開始ノードアイコンをクリックし、[サービスエラーハンドラの追加] をクリックする。詳細については、「プロキシサービスへのエラー処理の追加」を参照。
エコーノードからルートノードへの変換	[エコーノード] アイコンをクリックし、[ルートノードに変換] をクリックする。詳細については、「ルートノードの追加」を参照。
ステージ名と説明の編集	該当するステージアイコンをクリックし、[編集｜名前と説明] をクリックする。
ステージの削除	該当するステージアイコンをクリックし、[削除] をクリックする。
更新した内容を保存して [プロキシサービスの概要] ページに戻る	[保存] をクリックする。
変更を取り消して [プロキシサービスの概要] ページに戻る	[取り消し] をクリックする。
[メッセージフローの編集] ページを開いたまま変更をクリアする	[クリア] をクリックする。

更新アクション

更新アクションには、削除、名前変更、挿入、置換などのアクションがあります。これらのアクションは、次のように評価され、実行されます。

任意の更新アクション用にコンフィグレーションした XPath 式が評価されて、処理の対象となるメッセージのノードが選択される。
挿入アクションと置換アクションの場合は XQuery 式をコンフィグレーションする。この式が評価され、挿入または置換するデータが決定される。
XPath 式の評価によって指定される各ノードに対して適切なアクションが実行される。つまり、次のように実行されます。

XPath 式で指定された変数または変数のノードを削除する。
XPath 式で指定されたノードの名前を変更する。
XPath 式で指定されたノード (またはノードのコンテンツ) を、XQuery 式で返された値に置き換える。
XQuery 式で返された値を、XPath 式で指定されたノードの兄弟 (前または後ろ) または子として挿入する。

ルートノードの追加

[メッセージフローの編集] ページでは、ルートノードを追加できます。ルートノードは、ファイル転送や電子メール転送など、一方向通信を行う場合に使用します。ルートノードはプロキシサービスの要求処理と応答処理の境界を表します。ルートノードが要求メッセージをディスパッチすると、要求処理が終了したと見なされます。ルートノードが応答メッセージを受信したときに、応答処理が始まります。メッセージフローの詳細については、「メッセージフローの概要」を参照してください。

AquaLogic Service Bus は、信頼性の高いメッセージ機能を備えています。メッセージがルートノードから別のサービスにルーティングされるときのデフォルトのサービス品質 (QoS) は、プロキシサービス転送が JMS/XA として定義されている場合は exactly once になり、それ以外の場合は best effort の QoS がサポートされます。exactly once では、発信メッセージの送信が開始されるまでは終了エラーが発生しないことを前提として、メッセージが着信から発信に 1 回だけ配信されます。exactly once の配信の信頼性は提案に過ぎず、必ず実現されるわけではありません。exactly once を指定すると、可能であれば exactly once の信頼性が提供されます。exactly once が不可能な場合は、at least once の配信セマンティクスが試行され、それでも不可能な場合は best effort の配信が実行されます。

at least once では、発信メッセージの送信が開始されるまでは終了エラーが発生しないことを前提として、メッセージが着信から発信に少なくとも 1 回配信されます。対象サービスが転送レベルのエラーを伴う応答を返す場合でも、配信は成功したと見なされます。ただし、タイムアウト、接続エラー、通信リンクの中断があった場合は成功にはなりません。フェイルオーバ URL が指定されている場合は、少なくとも 1 つの URL に対して at least once のセマンティクスが提供されます。

best effort では、メッセージ処理の信頼性が低く、メッセージの重複が防止されませんが、パフォーマンスは最適化されます。

デフォルトの exactly once サービス品質属性をオーバーライドするには、発信メッセージのコンテキスト変数 ($outbound) に qualityOfService を設定する必要があります。詳細については、「メッセージコンテキストスキーマ」を参照してください。

ルートノードを追加するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。このページには以下の機能があります。

プロキシサービスの開始ノードを示すアイコン。このアイコンをクリックして、パイプラインペアノード、ルートノード、条件付きブランチ、オペレーションブランチ、およびサービスのエラー処理を追加できます。
プロキシサービスのエコーノード (終了ノード) を示すアイコン。このノードはルートノードに変換できます。
メッセージフロー内の各種オブジェクトに関連付けられたページにリンクされている、左側のナビゲーションペインのメッセージフローのマップ。
パイプラインペアノードやサービスエラーハンドラのアイコン (追加している場合)。

ルートノードを追加するには、以下のいずれか 1 つを実行します。

開始ノード アイコンをクリックし、[ルートノードの追加] を選択する。
既存のパイプラインペアのパイプラインペアノード アイコンをクリックし、[追加｜ルートノードの追加] をクリックする。

ルートノード アイコン、[名前] フィールド、および [説明] フィールドが表示されます。

[エコーノード] アイコンをクリックし、[ルートノードに変換] を選択する。

ルートノード アイコン、[名前] フィールド、および [説明] フィールドが表示されます。

[名前] フィールドにルートノード名を入力します。

[説明] フィールドにルートノードの説明を入力します。

以下のいずれか 1 つを実行します。

[保存] をクリックして、ルートノードを保存する。

[メッセージフローの編集] ページに、ルートノード アイコンとそのルートノードに割り当てられた名前が表示されます。

[取り消し] をクリックして変更を取り消し、メッセージフローに戻る。

ルートノードをクリックし、[編集｜ルートノード] をクリックします。[ステージコンフィグレーションの編集] ページが表示されます。「ルートノードアクションの追加」に進みます。

ルートノードにアクションを追加し、ルートノードを保存したら、以下のいずれか 1 つを実行します。

表 14-37 ルートノードの追加

処理	手順
パイプラインペアノードの追加	開始ノードアイコンをクリックし、[パイプラインペアの追加] をクリックする。詳細については、「パイプラインペアノードの追加」を参照。
このプロキシサービスへのエラー処理の追加	開始ノードアイコンをクリックし、[サービスエラーハンドラの追加] をクリックする。詳細については、「プロキシサービスへのエラー処理の追加」を参照。
既存のパイプラインへのステージの追加	適切な要求パイプラインまたは応答パイプラインをクリックし、[ステージの追加] をクリックする。詳細については、「ステージの追加」を参照。
既存のパイプラインへのアクションの追加	対象のパイプラインのステージアイコンをクリックし、[編集｜ステージ] をクリックする。詳細については、「アクションの追加」を参照。
ルートノード名と説明の編集	ルートノードアイコンをクリックし、[編集｜名前と説明] をクリックする。注意 : パイプライン名またはルートノード名を変更すると、パイプライン数がゼロにリセットされるため、[モニタ] モジュールのダッシュボードページに表示されるメッセージ数が他のコンポーネントのメッセージ数と相関しなくなる場合がある。これは、AquaLogic Service Bus では、いったん削除して再作成するアクションとして名前の変更を処理しているためである。サービスのモニタ間隔と同じ時間が経過すると、メッセージ数は再び相関するようになる。
ルートノードアクションの編集	ルートノードアイコンをクリックし、[編集｜ルートノード] をクリックする。
ルートノードからエコーノードへの変換	ルートノードアイコンをクリックし、[エコーノードに変換] をクリックする。
ルートノードへのエラーハンドラの追加	ルートノードアイコンをクリックし、[エラーハンドラの追加] をクリックする。詳細については、「ルートノードへのエラー処理の追加」を参照。
更新した内容を保存して [プロキシサービスの概要] ページに戻る	[保存] をクリックする。
変更を取り消して [プロキシサービスの概要] ページに戻る	[取り消し] をクリックする。
[メッセージフローの編集] ページを開いたまま変更をクリアする	[クリア] をクリックする。

ルートノードアクションの追加

[メッセージフローの編集] ページで [編集｜ルートノード] をクリックすると、[ステージコンフィグレーションの編集] ページでルートノードアクションを追加できます。プロキシサービスのルートノードを通過するメッセージの処理は、ルートノードアクションにより定義されます。メッセージフローの詳細については、「メッセージフローの概要」を参照してください。

ルートノードアクションを追加するには

[メッセージフローの編集] ページが表示されます。

ルートノード アイコンをクリックし、[編集｜ルートノード] をクリックします。[ステージコンフィグレーションの編集] ページが表示されます。

[アクションの追加] をクリックし、アクションの種類を選択して、ルートノードアクションを追加します。次の表は、アクションの種類とコンフィグレーションの手順をまとめたものです。

表 14-38 ルートノードアクションの追加

処理	手順
If... Then...	XQuery 式のブール結果に基づいて if then else アクションを割り当てる。注意 : 条件アクションはネスト可能。ただし、ステージエディタでは、ネストは 4 累積レベルまでに制限されている。5 番目のレベルを追加しようとしても、そのネストアクションは表示されない。累積レベルには、すべてのブランチアクション (If...Then... 条件、パブリッシュテーブル、ルートテーブル) が含まれる。たとえば、2 レベルの条件と、ルートテーブルを含むパブリッシュテーブルを使用して、合計 4 レベルにすることができる。ただし、別の条件を追加 (最後のパブリッシュテーブルに対して) すると、その条件は表示されない。 1. [アクションの追加] をクリックし、[If...Then...] を選択する。 If... Then... アクションが表示される。このアクションには以下の機能がある。 [If...Then...] アイコン If... 条件 Then... (条件の編集画面に移動するリンク) 要求アクションと応答アクションを追加するためのフィールド 2. [条件] をクリックする。[XQuery 条件の編集] ページが表示される。詳細については、「XQuery 条件の編集」を参照。 3. XQuery 条件を編集したら、[アクションの追加] をクリックしてから、その条件に関連付けるアクションを選択する。注意 : ルートノードでは、[ルーティング] または [ルーティングテーブル] アクションのみを選択できる。これらのアクションの詳細については、この表の該当する手順を参照。ただし、これらのアクションには、要求と応答のアクションを入れることができる。詳細については、「アクションの追加」のアクションの表を参照。 4. 必要に応じて [If...Then...] アイコンをクリックして、else-if 条件または else 条件を追加し、[アクションの追加] をクリックして、これらの条件にアクションを関連付ける。 5. 次の手順に進む。
ルーティング	注意 : これは終端アクションなので、このアクションの後に別のアクションを追加することはできない。ただし、このアクションには、要求と応答のアクションを入れることができる。メッセージの対象サービスを指定し、対象サービスへのメッセージのルーティング方法をコンフィグレーションする。 1. [アクションの追加] をクリックし、[ルーティング] を選択する。ルーティングアクションが表示される。このアクションには以下の機能がある。 [ルーティング] アイコンサービス選択用の画面に移動するための [サービス] リンク要求アクションと応答アクションを追加するためのフィールド 2. [サービス] をクリックする。[サービスブラウザ] が表示される。 3. リストからサービスを選択してから、[送信] をクリックする。そのサービスがデフォルトのリンクの代わりに表示される。 4. アクションを追加するために、[要求アクション] フィールドの [アクションの追加] をクリックし、サービスに関連付けるアクションを選択する。複数のアクションを追加することも可能。追加するアクションの種類の詳細については、「アクションの追加」のアクションの表を参照。 5. アクションを追加するために、[応答アクション] フィールドの [アクションの追加] をクリックし、サービスに関連付けるアクションを選択する。複数のアクションを追加することも可能。追加するアクションの種類の詳細については、「アクションの追加」のアクションの表を参照。 6. アクションを追加したら、次の手順に進む。
ルーティングテーブル	注意 : これは終端アクションなので、このアクションの後に別のアクションを追加することはできない。ただし、このアクションには、要求と応答のアクションを入れることができる。ルーティングテーブルとは、切り替え式の条件テーブルに含まれる一連のルートであり、単一の XQuery 式の結果に基づいて各種ルートを選択できる簡単な構文である。ステージエディタでは、ネストは 4 累積レベルまでに制限されている。5 番目のレベルを追加しようとしても、そのネストアクションは表示されない。累積レベルには、すべてのブランチアクション (If...Then... 条件、パブリッシュテーブル、ルートテーブル) が含まれる。たとえば、2 レベルの条件と、ルートテーブルを含むパブリッシュテーブルを使用して、合計 4 レベルにすることができる。ただし、別の条件を追加 (最後のパブリッシュテーブルに対して) すると、その条件は表示されない。メッセージの対象サービスを指定し、サービスへのメッセージのルーティング方法をコンフィグレーションする。 1. [アクションの追加] をクリックし、[ルーティングテーブル] を選択する。ルーティングテーブルアクションが表示される。このアクションには以下の機能がある。 [ルーティングテーブル] アイコン、XQuery 式編集用の画面に移動するための [式] リンク、新しいケースを挿入するためのひし形アイコン、比較演算子を入力するためのフィールド、値を入力するためのフィールド、サービス選択用の画面に移動するための [サービス] リンク、要求アクションと応答アクションを追加するためのフィールド。 2. [=]、[!=]、[<]、[>]、[<=]、[>=] のいずれかの比較演算子を選択して、所定のフィールドに値式を入力する。 3. [サービス] をクリックする。[サービスブラウザ] が表示される。 4. リストからサービスを選択してから、[送信] をクリックする。サービスが表示される。 5. アクションを追加するために、[要求アクション] フィールドの [アクションの追加] をクリックし、サービスに関連付けるアクションを選択する。複数のアクションを追加することも可能。 6. アクションを追加するために、[応答アクション] フィールドの [アクションの追加] をクリックし、サービスに関連付けるアクションを選択する。複数のアクションを追加することも可能。注意 : 追加する要求アクションと応答アクションの種類の詳細については、「アクションの追加」のアクションの表を参照。 7. アクションを追加したら、次の手順に進む。 8. 新しいケースを挿入する場合は、ひし形アイコンをクリックし、[新しいケースの挿入] を選択する。 9. 新しいケースについて、手順 2 ～ 7 を繰り返す。ひし形アイコンをクリックして、[デフォルトケースの挿入] を選択すると、それ以前のすべてのケースが満たされなかった場合に選択されるルートとしてデフォルトのケースを追加できる。 10. ケースを追加したら、次の手順に進む。

処理

手順

If... Then...

XQuery 式のブール結果に基づいて if then else アクションを割り当てる。

注意 : 条件アクションはネスト可能。ただし、ステージエディタでは、ネストは 4 累積レベルまでに制限されている。5 番目のレベルを追加しようとしても、そのネストアクションは表示されない。累積レベルには、すべてのブランチアクション (If...Then... 条件、パブリッシュテーブル、ルートテーブル) が含まれる。たとえば、2 レベルの条件と、ルートテーブルを含むパブリッシュテーブルを使用して、合計 4 レベルにすることができる。ただし、別の条件を追加 (最後のパブリッシュテーブルに対して) すると、その条件は表示されない。

1. [アクションの追加] をクリックし、[If...Then...] を選択する。

If... Then... アクションが表示される。このアクションには以下の機能がある。
[If...Then...] アイコン
If... 条件 Then... (条件の編集画面に移動するリンク)
要求アクションと応答アクションを追加するためのフィールド

2. [条件] をクリックする。[XQuery 条件の編集] ページが表示される。詳細については、「XQuery 条件の編集」を参照。

3. XQuery 条件を編集したら、[アクションの追加] をクリックしてから、その条件に関連付けるアクションを選択する。

注意 : ルートノードでは、[ルーティング] または [ルーティングテーブル] アクションのみを選択できる。これらのアクションの詳細については、この表の該当する手順を参照。ただし、これらのアクションには、要求と応答のアクションを入れることができる。詳細については、「アクションの追加」のアクションの表を参照。

4. 必要に応じて [If...Then...] アイコンをクリックして、else-if 条件または else 条件を追加し、[アクションの追加] をクリックして、これらの条件にアクションを関連付ける。

5. 次の手順に進む。

ルーティング

注意 : これは終端アクションなので、このアクションの後に別のアクションを追加することはできない。ただし、このアクションには、要求と応答のアクションを入れることができる。

メッセージの対象サービスを指定し、対象サービスへのメッセージのルーティング方法をコンフィグレーションする。

1. [アクションの追加] をクリックし、[ルーティング] を選択する。

ルーティングアクションが表示される。このアクションには以下の機能がある。
[ルーティング] アイコン
サービス選択用の画面に移動するための [サービス] リンク
要求アクションと応答アクションを追加するためのフィールド

2. [サービス] をクリックする。[サービスブラウザ] が表示される。

3. リストからサービスを選択してから、[送信] をクリックする。そのサービスがデフォルトのリンクの代わりに表示される。

4. アクションを追加するために、[要求アクション] フィールドの [アクションの追加] をクリックし、サービスに関連付けるアクションを選択する。複数のアクションを追加することも可能。追加するアクションの種類の詳細については、「アクションの追加」のアクションの表を参照。

5. アクションを追加するために、[応答アクション] フィールドの [アクションの追加] をクリックし、サービスに関連付けるアクションを選択する。複数のアクションを追加することも可能。追加するアクションの種類の詳細については、「アクションの追加」のアクションの表を参照。

6. アクションを追加したら、次の手順に進む。

ルーティングテーブル

ルーティングテーブルとは、切り替え式の条件テーブルに含まれる一連のルートであり、単一の XQuery 式の結果に基づいて各種ルートを選択できる簡単な構文である。

ステージエディタでは、ネストは 4 累積レベルまでに制限されている。5 番目のレベルを追加しようとしても、そのネストアクションは表示されない。累積レベルには、すべてのブランチアクション (If...Then... 条件、パブリッシュテーブル、ルートテーブル) が含まれる。たとえば、2 レベルの条件と、ルートテーブルを含むパブリッシュテーブルを使用して、合計 4 レベルにすることができる。ただし、別の条件を追加 (最後のパブリッシュテーブルに対して) すると、その条件は表示されない。

メッセージの対象サービスを指定し、サービスへのメッセージのルーティング方法をコンフィグレーションする。

1. [アクションの追加] をクリックし、[ルーティングテーブル] を選択する。ルーティングテーブルアクションが表示される。このアクションには以下の機能がある。

[ルーティングテーブル] アイコン、XQuery 式編集用の画面に移動するための [式] リンク、新しいケースを挿入するためのひし形アイコン、比較演算子を入力するためのフィールド、値を入力するためのフィールド、サービス選択用の画面に移動するための [サービス] リンク、要求アクションと応答アクションを追加するためのフィールド。

2. [=]、[!=]、[<]、[>]、[<=]、[>=] のいずれかの比較演算子を選択して、所定のフィールドに値式を入力する。

3. [サービス] をクリックする。[サービスブラウザ] が表示される。

4. リストからサービスを選択してから、[送信] をクリックする。サービスが表示される。

5. アクションを追加するために、[要求アクション] フィールドの [アクションの追加] をクリックし、サービスに関連付けるアクションを選択する。複数のアクションを追加することも可能。

6. アクションを追加するために、[応答アクション] フィールドの [アクションの追加] をクリックし、サービスに関連付けるアクションを選択する。複数のアクションを追加することも可能。

注意 : 追加する要求アクションと応答アクションの種類の詳細については、「アクションの追加」のアクションの表を参照。

7. アクションを追加したら、次の手順に進む。

8. 新しいケースを挿入する場合は、ひし形アイコンをクリックし、[新しいケースの挿入] を選択する。

9. 新しいケースについて、手順 2 ～ 7 を繰り返す。ひし形アイコンをクリックして、[デフォルトケースの挿入] を選択すると、それ以前のすべてのケースが満たされなかった場合に選択されるルートとしてデフォルトのケースを追加できる。

10. ケースを追加したら、次の手順に進む。

ルートノードアクションを追加したら、以下のいずれか 1 つを実行します。

表 14-39 ルートノードアクションの追加

処理	手順
アクションを削除する	該当するアイコンをクリックし、[このアクションを削除] をクリックする。アクションが削除される。
アクションを下に移動する	該当するアイコンをクリックし、[アクションを下に移動] をクリックする。アクションがこのステージに含まれる次のアクションの下に移動する。注意 : このオプションは、ステージに複数のアクションが含まれる場合にのみ表示される。
アクションを上に移動する	該当するアイコンをクリックし、[アクションを上に移動] をクリックする。アクションがこのステージに含まれる前のアクションの上に移動する。注意 : このオプションは、ステージに複数のアクションが含まれる場合にのみ表示される。
更新した内容を保存して [メッセージフローの編集] ページに戻る	[保存] をクリックする。
変更を取り消して [メッセージフローの編集] ページに戻る	[取り消し] をクリックする。
[ステージコンフィグレーションの編集] ページを開いたまま保存前の変更をクリアする	[クリア] をクリックする。

アクションを保存したら、以下のいずれか 1 つを実行します。

表 14-40 ルートノードアクションの追加

処理	手順
ルートノード名と説明の編集	ルートノードアイコンをクリックし、[編集｜名前と説明] をクリックする。
ルートノードからエコーノードへの変換	ルートノードアイコンをクリックし、[エコーノードに変換] をクリックする。
ルートノードへのエラーハンドラの追加	ルートノードアイコンをクリックし、[エラーハンドラの追加] をクリックする。詳細については、「ルートノードへのエラー処理の追加」を参照。
更新した内容を保存して [プロキシサービスの概要] ページに戻る	[保存] をクリックする。
変更を取り消して [プロキシサービスの概要] ページに戻る	[取り消し] をクリックする。
[メッセージフローの編集] ページを開いたまま変更をクリアする	[クリア] をクリックする。

条件付きブランチの詳細の表示と変更

[ブランチノードの編集] ページでは条件付きブランチの詳細を表示および変更できます。ブランチノードの詳細については、「条件付きブランチノードの追加」および「メッセージフローの概要」を参照してください。

注意 : オペレーションブランチを編集する場合は、「オペレーションブランチの詳細の表示と変更」を参照してください。

条件付きブランチの詳細を表示および変更するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。このページには以下の機能があります。

プロキシサービスアイコン
プロキシサービス名
パイプラインペアノードをすでに追加している場合は、パイプラインペアノードアイコンおよびパイプラインペアノード名
条件付きブランチノードアイコンおよびブランチノード名
すでにルートノードを追加している場合は、[エコーノード] アイコンまたはルートノードアイコン
メッセージフロー内の各種オブジェクトに関連付けられたページにリンクされている、左側のナビゲーションペインのメッセージフローのマップ

条件付きブランチノード アイコンをクリックし、[編集｜ブランチノード] をクリックします。または、左側のナビゲーションペインで、メッセージフローのマップからブランチノードを選択することもできます。

ブランチコンフィグレーションの各フィールドおよびブランチ定義が表示されます。

以下のいずれか 1 つを実行します。

表 14-41 ブランチコンフィグレーションのフィールドとブランチ定義

処理	手順
[選択したパス] フィールドの XPath 式の編集	[編集] をクリックする。詳細については、「XPath 式の編集」を参照。
別のブランチ定義の追加	[オプション] カラムのポップアップメニューにある [新しいブランチの追加] をクリックする。
ブランチ定義の削除	[オプション] カラムのポップアップメニューにある [このブランチを削除] をクリックする。
定義リスト下方向へのブランチの移動	[オプション] カラムのポップアップメニューにある [ブランチを下に移動] をクリックする。注意 : このオプションは、複数のブランチ定義が存在する場合にのみ表示される。
定義リスト上方向へのブランチの移動	[オプション] カラムのポップアップメニューにある [ブランチを上に移動] をクリックする。注意 : このオプションは、複数のブランチ定義が存在する場合にのみ表示される。

ブランチを更新したら、以下のいずれか 1 つを実行します。

[保存] をクリックして、ブランチノードを更新する。[メッセージフローの編集] ページが表示されます。
[取り消し] をクリックして変更を取り消し、[メッセージフローの編集] ページに戻る。
[クリア] をクリックして、[ブランチノードの編集] ページを開いたままブランチの定義を取り消す。

オペレーションブランチの詳細の表示と変更

[ブランチノードの編集] ページではオペレーションブランチの詳細を表示および変更できます。オペレーションブランチの詳細については、「オペレーションブランチノードの追加」および「メッセージフローの概要」を参照してください。

オペレーションブランチの詳細を表示および変更するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。このページには以下の機能があります。

プロキシサービスアイコン
プロキシサービス名
パイプラインペアノードをすでに追加している場合は、パイプラインペアノードアイコンおよびパイプラインペアノード名
オペレーションブランチノードアイコンおよびブランチノード名
すでにルートノードを追加している場合は、[エコーノード] アイコンまたはルートノードアイコン
メッセージフロー内の各種オブジェクトに関連付けられたページにリンクされている、左側のナビゲーションペインのメッセージフローのマップ

オペレーションブランチノード アイコンをクリックし、[編集｜ブランチノード] をクリックします。または、左側のナビゲーションペインで、メッセージフローのマップからブランチを選択することもできます。

ブランチコンフィグレーションの各フィールドおよびブランチ定義が表示されます。

以下のいずれか 1 つを実行します。

表 14-42 ブランチコンフィグレーションのフィールドとブランチ定義

処理	手順
別のブランチ定義の追加	[オプション] カラムのポップアップメニューにある [新しいブランチの追加] をクリックする。
ブランチ定義の削除	[オプション] カラムのポップアップメニューにある [このブランチを削除] をクリックする。
定義リスト下方向へのブランチの移動	[オプション] カラムのポップアップメニューにある [ブランチを下に移動] をクリックする。注意 : このオプションは、複数のブランチ定義が存在する場合にのみ表示される。
定義リスト上方向へのブランチの移動	[オプション] カラムのポップアップメニューにある [ブランチを上に移動] をクリックする。注意 : このオプションは、複数のブランチ定義が存在する場合にのみ表示される。

ブランチを更新したら、以下のいずれか 1 つを実行します。

[保存] をクリックして、ブランチノードを更新する。[メッセージフローの編集] ページが表示されます。
[取り消し] をクリックして変更を取り消し、[メッセージフローの編集] ページに戻る。
[クリア] をクリックして、[ブランチノードの編集] ページを開いたままブランチの定義を取り消す。

ステージコンフィグレーションの詳細の表示と変更

[ステージコンフィグレーションの編集] ページでは、ステージを編集できます。ステージの詳細については、「ステージの追加」、「アクションの追加」、および「メッセージフローの概要」を参照してください。

ステージコンフィグレーションの詳細を表示および変更するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。このページには以下の属性が表示されます。

プロキシサービスアイコン
プロキシサービス名
パイプラインペアノードをすでに追加している場合は、パイプラインペアノードアイコンおよびパイプラインペアノード名
すでにルートノードを追加している場合は、[エコーノード] アイコンまたはルートノードアイコン
メッセージフロー内の各種オブジェクトに関連付けられたページにリンクされている、左側のナビゲーションペインのメッセージフローのマップ

編集するステージを選択します。

既存のパイプラインを展開してパイプラインペアを表示します。

要求パイプラインまたは応答パイプラインのステージ アイコンをクリックし、[編集｜ステージ] をクリックします。

[ステージコンフィグレーションの編集] ページが表示されます。

注意 : 左側のナビゲーションペインで、メッセージフローのマップからステージを選択することもできます。

以下のいずれか 1 つを実行します。

表 14-43 [ステージコンフィグレーションの編集] ページ

処理	手順
アクションの追加	[アクションの追加] をクリックしてから、適切なアクションを選択する。詳細については、「アクションの追加」を参照。
アクションの削除	アクションを選択してから、[このアクションを削除] をクリックする。
変数フィールドの編集	該当するフィールドを編集する。
XQuery 式の編集	編集する式をクリックする。詳細については、「XQuery 式の編集」を参照。
XPath 式の編集	編集する式をクリックする。詳細については、「XPath 式の編集」を参照。
XQuery 条件の編集	編集する条件をクリックする。詳細については、「XQuery 条件の編集」を参照。

変更を終えたら、以下のいずれか 1 つを実行します。

[保存] をクリックして、ステージを更新する。[メッセージフローの編集] ページが表示されます。
[取り消し] をクリックして変更を取り消し、[メッセージフローの編集] ページに戻る。
[クリア] をクリックして、[ステージコンフィグレーションの編集] ページを開いたまま保存前の編集内容を取り消す。

XQuery 条件の編集

[XQuery 条件の編集] ページでは、XQuery 条件を追加したり編集したりできます。このページは、プロキシサービスのメッセージフローから表示できます。メッセージフローの詳細については、「メッセージフローの概要」を参照してください。

XQuery 条件を編集するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。

既存のパイプラインを展開してパイプラインペアを表示します。

編集するステージのステージ アイコンを選択し、[編集｜ステージ] をクリックします。[ステージコンフィグレーションの編集] ページが表示されます。それまでに追加したアクションがある場合は、このページにそれらのアクションが表示されます。

編集する XQuery 条件が含まれているアクションを検索して、編集対象の条件を選択します。

アクション内に含まれている条件をクリックして、条件エディタを開きます。

[XQuery 条件の編集] ページが表示されます。このページには以下の機能があります。

[テキスト] ペインと [条件ビルダ] ペイン
[メッセージコンテキスト変数] パネル
[ネームスペース定義] パネル
[XQuery 関数] パレット

以下のいずれか 1 つを実行します。

表 14-44 [XQuery 条件の編集] ページ

処理	手順
メッセージコンテキスト変数の XPath の生成	1. [メッセージコンテキスト変数] パネルのドロップダウンリストで、コンテキスト変数 [`attachments`]、[`header`]、[`outbound`]、[`body`]、[`inbound`] から 1 つを選択する。メッセージコンテキスト変数の詳細については、「メッセージコンテキスト」を参照。 2. 表示された名前をクリックして、[メッセージコンテキスト変数] パネルの [XPath] フィールドに変数を表示する。注意 : 表示される名前は、ツリービュー形式で表示されるので、順に選択して展開することで下位要素を表示できる。 3. テキストを選択し、[XPath] フィールドからコンテキスト変数をドラッグして [式の編集] フィールドにドロップすることで、式を作成する。
メッセージコンテキスト変数の定義	詳細については、「新しいメッセージコンテキスト変数の定義」を参照。
ユーザのネームスペースの定義	1. [ネームスペース定義] パネルで、[ユーザのネームスペース] の [+] をクリックする。[新しいネームスペース宣言] ダイアログボックスが表示される。 2. [Prefix] フィールドにプレフィックスを入力する。 3. [Namespace] フィールドにネームスペースを入力する。 4. [OK] をクリックする。注意 : XML ネームスペースを使用すると、グローバルレベルでユニークな要素名と属性名にすることができる。ローカル名である要素名および属性名を、ネームスペースプレフィックスで修飾することにより、ユニークさが確保される。
ユーザのネームスペースの削除	[ネームスペース定義] パネルで、削除するユーザのネームスペースに対応する [-] (マイナス記号) をクリックする。
[テキスト] オプションを使用した XQuery 条件の作成	1. [テキスト] オプションが選択されていることを確認する。 2. [XQuery 条件の編集] フィールドにテキストを入力するか、貼り付ける。注意 : [XQuery 関数] パレットにある XQuery 関数または [メッセージコンテキスト変数] パネルにあるメッセージコンテキスト変数を [XQuery 条件の編集] フィールドにドラッグアンドドロップして条件を作成できる。また、あらかじめ定義されているデフォルトのネームスペース、変数ネームスペース、およびユーザ定義のネームスペースも追加できる。これらは [ネームスペース定義] パネルにある。ドラッグアンドドロップ機能は、Internet Explorer ブラウザでのみサポートされている。他のブラウザでは、ドラッグされたテキストを設定する JavaScript がサポートされていない。XML スキーマツリーを使用する場合は、ドラッグアンドドロップするのではなく、目的のノードをクリックする必要がある。これにより、パレットの下部にあるテキスト領域にそのノードの XPath が表示される。その後、このテキスト領域の内容をコピーして、[式の編集] フィールドに貼り付ける必要がある。 3. 以下のいずれか 1 つを実行する。 [送信] をクリックして、条件を保存する。[ステージコンフィグレーションの編集] ページが表示される。入力したテキストが条件として入力される。詳細については、「ステージコンフィグレーションの詳細の表示と変更」を参照。 [検証] をクリックして、条件を検証する。 [取り消し] をクリックして、変更を取り消す。
[条件ビルダ] オプションを使用した比較式の入力	1. [条件ビルダ] オプションを選択する。 2. [比較式] オプションが選択されていることを確認する。 3. 左側のペインに、コンテキスト変数、ネームスペース定義、または XQuery 関数を入力する。注意 : [XQuery 関数] パレットにある XQuery 関数を [XQuery 条件の編集] フィールドにドラッグアンドドロップして式を作成できる。また、あらかじめ定義されているデフォルトのネームスペース、変数ネームスペース、およびユーザ定義のネームスペースも追加できる。これらは [ネームスペース定義] パネルにある。 4. 中央のペインで、[=]、[!=]、[>]、[<]、[>=]、または [<=] を選択する。 5. 右側のペインにテキストまたはコンテキスト変数を入力する。注意 : テキストは引用符で囲む必要がある。たとえば、true ではなく、"true" と入力する。 6. [Add] をクリックする。入力したテキストが下のペインに表示される。 7. さらに条件を作成する場合は、手順 2 ～ 6 を繰り返す。各条件は、条件リストの最後に追加される。注意 : 追加の式を作成する場合は、必ず [and] または [or] オプションを選択する。注意 : 条件を削除するには、対象の条件を選択して [Remove] をクリックする。条件を条件リストの上に移動するには、[Up] を、下に移動するには [Down] をクリックする。更新するには、[Update] をクリックする。 8. 以下のいずれか 1 つを実行する。 [送信] をクリックして、条件を保存する。[ステージコンフィグレーションの編集] ページが表示される。入力したテキストが条件として入力される。詳細については、「ステージコンフィグレーションの詳細の表示と変更」または「アクションの追加」を参照。 [検証] をクリックして、式を検証する。 [取り消し] をクリックして、変更を取り消す。
[条件ビルダ] オプションを使用した単項式の入力	1. [条件ビルダ] オプションを選択する。 2. [単項式] オプションを選択する。 3. コンテキスト変数、ネームスペースの定義、または XQuery 関数を入力する。注意 : [XQuery 関数] パレットにある XQuery 関数を [XQuery 条件の編集] フィールドにドラッグアンドドロップして式を作成できる。また、あらかじめ定義されているデフォルトのネームスペース、変数ネームスペース、およびユーザ定義のネームスペースも追加できる。これらは [ネームスペース定義] パネルにある。 4. [Add] をクリックする。入力したテキストが下のペインに表示される。 5. さらに条件を作成する場合は、手順 2 ～ 6 を繰り返す。各条件は、条件リストの最後に追加される。注意 : 追加の式を作成する場合は、必ず [and] または [or] オプションを選択する。注意 : 条件を削除するには、対象の条件を選択して [Remove] をクリックする。条件を条件リストの上に移動するには、[Up] を、下に移動するには [Down] をクリックする。更新するには、[Update] をクリックする。注意 : 条件の全体定義では、単項式と比較式を混ぜることもできる。 6. 以下のいずれか 1 つを実行する。 [送信] をクリックして、条件を保存する。[ステージコンフィグレーションの編集] ページが表示される。入力したテキストが条件として入力される。詳細については、「ステージコンフィグレーションの詳細の表示と変更」または「アクションの追加」を参照。 [検証] をクリックして、式を検証する。 [取り消し] をクリックして、変更を取り消す。

注意 : [送信] をクリックすると、メッセージフローは現在のセッション内で更新されます。コンフィグレーションに対する変更が完了したら、左側のナビゲーションペインで、[Change Center] の下にある [アクティブ化] をクリックします。セッションが終了し、コアコンフィグレーションが更新されます。また、セッション中はいつでも [破棄] をクリックすることができ、現在のセッションでこれまでに加えた変更を取り消すことができます。

XQuery 式の編集

[XQuery 式の編集] ページでは、XQuery 式を追加したり変更したりできます。このページは、プロキシサービスのメッセージフローから表示できます。メッセージフローの詳細については、「メッセージフローの概要」を参照してください。

注意 : XQuery エディタと XPath エディタでは、変数の構造を型または要素にマッピングし、その構造のグラフィック表現からドラッグアンドドロップ操作でパス式を作成することにより、変数の構造を宣言することができます。これは簡単に使用できる機能です。代わりにパス式を手動で入力することもできます。

この機能は、すべてのユーザ定義変数と $inbound、$outbound、および $fault に対して直接使用できます。ただし、この機能を使用して $attachments の XML 添付ファイル、$header のヘッダ、または $body のドキュメントと RPC パラメータに直接アクセスすることはできません。例外として、WSDL プロキシサービスによって受信された要求メッセージの $body のドキュメントとパラメータには直接アクセスできます。

XQuery 式を編集するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。

既存のパイプラインを展開してパイプラインペアを表示します。

編集するステージのステージ アイコンをクリックし、[編集｜ステージ] をクリックします。[ステージコンフィグレーションの編集] ページが表示されます。それまでに追加したアクションがある場合は、このページにそれらのアクションが表示されます。

編集する XQuery 式が含まれているアクションを検索して、編集対象の式を選択します。

アクション内に含まれている XQuery 式のリンクをクリックして、式エディタを開きます。

[XQuery 式の編集] ページが表示されます。このページには以下の機能があります。

[テキスト] ペイン、[XQ トランスフォーメーション] ペイン、および [XSL トランスフォーメーション] ペイン
[メッセージコンテキスト変数] パネル
[ネームスペース定義] パネル
[XQuery 関数] パレット

以下のいずれか 1 つを実行します。

表 14-45 [XQuery 式の編集] ページ

処理	手順
メッセージコンテキスト変数の XPath の生成	1. [メッセージコンテキスト変数] パネルのドロップダウンリストで、コンテキスト変数 [`attachments`]、[`header`]、[`outbound`]、[`body`]、[`inbound`] から 1 つを選択する。メッセージコンテキスト変数の詳細については、「メッセージコンテキスト」を参照。 2. 表示された名前をクリックして、[メッセージコンテキスト変数] パネルの [XPath] フィールドに変数を表示する。注意 : 表示される名前は、ツリービュー形式で表示されるので、順に選択して展開することで下位要素を表示できる。 3. テキストを選択し、[XPath] フィールドからコンテキスト変数をドラッグして [式の編集] フィールドにドロップすることで、式を作成する。
メッセージコンテキスト変数の定義	詳細については、「新しいメッセージコンテキスト変数の定義」を参照。
ユーザのネームスペースの定義	1. [ネームスペース定義] パネルで、[ユーザのネームスペース] の [+] をクリックする。[新しいネームスペース宣言] ダイアログボックスが表示される。 2. [Prefix] フィールドにプレフィックスを入力する。 3. [Namespace] フィールドにネームスペースを入力する。 4. [OK] をクリックする。注意 : XML ネームスペースを使用すると、グローバルレベルでユニークな要素名と属性名にすることができる。ローカル名である要素名および属性名を、ネームスペースプレフィックスで修飾することにより、ユニークさが確保される。
ユーザのネームスペースの削除	[ネームスペース定義] パネルで、削除するユーザのネームスペースに対応する [-] (マイナス記号) をクリックする。
XQuery 式の手動での作成	1. [テキスト] オプションが選択されていることを確認する。 2. [式の編集] フィールドにテキストを入力するか、貼り付ける。注意 : [XQuery 関数] パレットにある XQuery 関数を [式の編集] フィールドにドラッグアンドドロップして式を作成できる。また、あらかじめ定義されているデフォルトのネームスペース、変数ネームスペース、およびユーザ定義のネームスペースも追加できる。これは、[ネームスペース定義] パネルにある。ドラッグアンドドロップ機能は、Internet Explorer ブラウザでのみサポートされている。他のブラウザでは、ドラッグされたテキストを設定するために必要な JavaScript がサポートされていない。XML スキーマツリーを使用する場合は、ドラッグアンドドロップするのではなく、目的のノードをクリックする必要がある。これにより、パレットの下部にあるテキスト領域にそのノードの XPath が表示される。その後、このテキスト領域の内容をコピーして、[式の編集] フィールドに貼り付ける必要がある。 3. 以下のいずれか 1 つを実行する。 [送信] をクリックして、式を保存する。[ステージコンフィグレーションの編集] ページが表示される。入力したテキストが式として入力される。詳細については、「ステージコンフィグレーションの詳細の表示と変更」を参照。 [検証] をクリックして、式を検証する。 [取り消し] をクリックして、変更を取り消す。
実行用 XQuery トランスフォーメーションの選択	1. [XQ トランスフォーメーション] オプションを選択する。 2. [実行するトランスフォーメーションを選択] フィールドで、実行する XQuery トランスフォーメーションを選択してから、[Select] をクリックする。 3. [変数マッピング] フィールドの下に、ラベルとそれに対応するテキストボックスが表示され、スクロールすることでトランスフォーメーションの各入力パラメータを表示できる。各ラベルはパラメータ名に相当し、各テキストボックスはそのパラメータにマッピングされる XQuery 式を定義するためのものである。マッピングはパラメータごとに定義する必要がある。たとえば、XQuery トランスフォーメーションに one および two という 2 つの入力パラメータがある場合、[変数マッピング] フィールドには、「one」および「two」という 2 つのラベルが表示される。XQuery 式が入力されるテキストボックスは、各ラベルに関連付けられている。次の XQuery 式は、このフィールドの有効な入力例である。 `$body/[1]` `$body/po:PurchaseOrder` 注意 :* 次の変数名はこのフィールドでは無効な入力となり、例外が発生する。 `body` 4. 以下のいずれか 1 つを実行する。 [送信] をクリックして、式を保存する。[ステージコンフィグレーションの編集] ページが表示される。選択したトランスフォーメーションが式として入力される。詳細については、「ステージコンフィグレーションの詳細の表示と変更」または「アクションの追加」を参照。 [検証] をクリックして、式を検証する。 [取り消し] をクリックして、変更を取り消す。
実行用 XSL トランスフォーメーションの選択	1. [XSL トランスフォーメーション] オプションを選択する。 2. [実行する XSL トランスフォーメーションを選択] フィールドで、実行する XSL トランスフォーメーションを選択してから、[Select] をクリックする。 3. [変数マッピング] フィールドの下に、ラベルとそれに対応するテキストボックスがトランスフォーメーションの入力パラメータごとに表示される。各ラベルはパラメータ名に相当し、各テキストボックスはそのパラメータにマッピングされる XQuery 式を定義するためのものである。マッピングはパラメータごとに定義する必要がある。たとえば、XSL トランスフォーメーションに one および two という 2 つの入力パラメータがある場合、[変数マッピング] フィールドには、「one」および「two」という 2 つのラベルと、ラベルごとに XQuery 式を入力するテキストボックスが表示されます。入力変数のマッピングの他に、トランスフォーメーションの入力ドキュメントの XQuery 式を指定する必要もある。このマッピングは、[入力ドキュメント] というラベルが付いたテキストボックスで指定する。次の XQuery 式は、このフィールドの有効な入力例である。 `$body/[1]` `$body/po:PurchaseOrder` 注意 :* 次の変数名はこのフィールドでは無効な入力となり、例外が発生する。 `body` 4. 以下のいずれか 1 つを実行する。 [送信] をクリックして、式を保存する。[ステージコンフィグレーションの編集] ページが表示される。選択したトランスフォーメーションが式として入力される。詳細については、「ステージコンフィグレーションの詳細の表示と変更」または「アクションの追加」を参照。 [検証] をクリックして、式を検証する。 [取り消し] をクリックして、変更を取り消す。

XPath 式の編集

[XPath 式の編集] ページでは、XPath 式を編集できます。このページは、プロキシサービスのメッセージフローから表示できます。メッセージフローの詳細については、「メッセージフローの概要」を参照してください。

XPath 式を編集するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。

既存のパイプラインを展開してパイプラインペアを表示します。

編集する XPath 式が含まれているアクションを検索して、編集対象の式を選択します。

アクション内に含まれている XPath 式のリンクをクリックして、式エディタを開きます。

[XPath 式の編集] ページが表示されます。このページには以下の機能があります。

XPath 式編集用のフィールド
[メッセージコンテキスト変数] パネル
[ネームスペース定義] パネル

以下のいずれか 1 つを実行します。

表 14-46 [XPath 式の編集] ページ

処理	手順
メッセージコンテキスト変数の XPath の生成	1. [メッセージコンテキスト変数] パネルのドロップダウンリストで、コンテキスト変数 [attachments]、[header]、[outbound]、[body]、[inbound] から 1 つを選択する。メッセージコンテキスト変数の詳細については、「メッセージコンテキスト」を参照。 2. 表示された名前をクリックして、[メッセージコンテキスト変数] パネルの [XPath] フィールドに変数を表示する。注意 : 表示される名前は、ツリービュー形式で表示されるので、順に選択して展開することで下位要素を表示できる。 3. テキストを選択し、[XPath] フィールドからコンテキスト変数をドラッグして [式の編集] フィールドにドロップすることで、式を作成する。
メッセージコンテキスト変数の定義	詳細については、「新しいメッセージコンテキスト変数の定義」を参照。
ユーザのネームスペースの定義	1. [ネームスペース定義] パネルで、[ユーザのネームスペース] の [+] をクリックする。[新しいネームスペース宣言] ダイアログボックスが表示される。 2. [Prefix] フィールドにプレフィックスを入力する。 3. [Namespace] フィールドにネームスペースを入力する。 4. [OK] をクリックする。注意 : XML ネームスペースを使用すると、グローバルレベルでユニークな要素名と属性名にすることができる。ローカル名である要素名および属性名を、ネームスペースプレフィックスで修飾することにより、ユニークさが確保される。
ユーザのネームスペースの削除	[ネームスペース定義] パネルで、削除するユーザのネームスペースに対応する [-] (マイナス記号) をクリックする。
XPath 式の手動での作成	1. [XPath 式の編集] フィールドにテキストを入力するか、貼り付ける。注意 : [メッセージコンテキスト変数] パネルにあるコンテキスト変数を [式の編集] フィールドにドラッグアンドドロップして式を作成できる。また、あらかじめ定義されているデフォルトのネームスペース、変数ネームスペース、およびユーザ定義のネームスペースも追加できる。これらは [ネームスペース定義] パネルにある。ドラッグアンドドロップ機能は、Internet Explorer ブラウザでのみサポートされている。他のブラウザでは、ドラッグされたテキストを設定する JavaScript がサポートされていない。XML スキーマツリーを使用する場合は、ドラッグアンドドロップするのではなく、目的のノードをクリックする必要がある。これにより、パレットの下部にあるテキスト領域にそのノードの XPath が表示される。その後、このテキスト領域の内容をコピーして、[式の編集] フィールドに貼り付ける必要がある。 2. 以下のいずれか 1 つを実行する。 [送信] をクリックして、式を保存する。[ステージコンフィグレーションの編集] ページが表示される。入力したテキストが式として入力される。詳細については、「ステージコンフィグレーションの詳細の表示と変更」または「アクションの追加」を参照。 [取り消し] をクリックして、変更を取り消す。

新しいメッセージコンテキスト変数の定義

[新しいメッセージコンテキスト変数の定義] ページでは、新しいメッセージコンテキスト変数型を定義できます。このページには、[XQuery 式の編集]、[XPath 式の編集]、[XQuery 条件の編集] の各ページからアクセスできます。詳細については、「XQuery 式の編集」、「XPath 式の編集」、「XQuery 条件の編集」を参照してください。

新しいメッセージコンテキスト変数を定義するには

[XQuery 式の編集] ページ、[XPath 式の編集] ページ、または [XQuery 条件の編集] ページの [メッセージコンテキスト変数] パネルで、[+] アイコンをクリックします。

[新しいメッセージコンテキスト変数の定義] ページが表示されます。

[変数名] フィールドに定義対象の変数名を入力します。

[このメッセージコンテキスト変数の型を選択] フィールドで、[文字列]、[型なし XML]、[XML スキーマ]、[WSDL]、[MFL] のいずれかの変数型を選択します。

注意 : [参照] をクリックし、該当するブラウザを使用して、XML スキーマ、WSDL、または MFL を選択してから、[送信] をクリックすることもできます。

以下のいずれか 1 つを実行します。

[送信] をクリックして新しい変数を保存し、前のページに戻る。
[取り消し] をクリックして変更を取り消し、前のページに戻る。

エラーメッセージと処理

この節の内容は以下のとおりです。

エラーハンドラ

BEA AquaLogic Service Bus では、エラーメッセージをフォーマットして返すようにシステムをコンフィグレーションできます。

メッセージフローの処理中には、さまざまな原因でエラーが発生します。たとえば、ユーザ名が正しく確認または認証されない場合は、セキュリティエラーが発生します。また、AquaLogic Service Bus がメッセージを正常に変換または検証できない場合は、トランスフォーメーションエラーが発生します。ルーティングサービスが使用できないために、ルーティングエラーが発生する場合などもあります。たいていのメッセージフローロジックは特定のステージ、ルートノード、またはプロキシサービスで実行されるため、一般的に、これらのエラーは特定のステージ、ルートノード、またはプロキシサービスに起因しています。

AquaLogic Service Bus には、エラーハンドラを定義してこれらのエラーを処理するための機能が用意されています。エラーハンドラは、ロギング、トランスフォーメーション、およびパブリッシュなどの各種アクションを実行し、適切にエラーを処理するためのパイプラインです。

ステージ内でエラーが発生すると、一連の手順が実行されます。この一連の手順がそのステージのエラーパイプラインを構成しています。

ネストエラーハンドラ

エラーハンドラは、メッセージフロー全体に対してコンフィグレーションすることも、メッセージフロー内の各パイプラインや各ステージに対してコンフィグレーションすることもできます。エラーハンドラはルートノードに対してコンフィグレーションすることもできます。ただし、ブランチノードに対してコンフィグレーションすることはできません。

エラーが生じると、そのエラーを取り囲む最も内側のエラーハンドラにより処理されます。たとえば、ステージ内で割り当てアクションを実行中にトランスフォーメーションエラーが生じた場合は、そのステージのエラーハンドラにより処理されます。そのステージにエラーハンドラがコンフィグレーションされていない場合は、次のレベルのエラーハンドラ、つまりトランスフォーメーションステージを含むパイプラインのエラーハンドラにより処理されます。このエラーハンドラもない場合は、メッセージフローレベルのエラーハンドラにより処理されます。これにも失敗すると、エラーは、デフォルトのシステムレベルエラーハンドラにより処理されます。

ルートノードで生じたエラーを捕捉できなかった場合、次のレベルのエラーハンドラはメッセージフローレベルのハンドラになります。つまり、ステージエラーは 3 つのレベルのユーザコンフィグレーションハンドラで処理できるのに対し、メッセージフローエラーは最大でも 2 つのレベルのユーザコンフィグレーションハンドラでしか捕捉できません。

すべてのコンポーネント、つまりステージ、パイプライン、またはメッセージフローが持つことのできるエラーハンドラは最大で 1 つです。そのため、要求または応答の処理中にエラーが発生し、これが下位の (パイプラインまたはステージの) エラーハンドラで処理されない場合は、1 つのメッセージフローレベルのエラーハンドラで処理することになります。着信バインディングレイヤは特定のステージやパイプラインと関連付けることができないため、バインディングレイヤで生じたエラーは常にメッセージフローレベルのエラーハンドラにより処理されます。発信バインディングレイヤのエラーは、通信を実行しているエンティティに応じて、いくつかの場所で生じる可能性があります。たとえば、ルーティング中に生じたバインディングレイヤのエラーは、ルートノードのエラーハンドラで捕捉できます。同様に、パブリッシュステージでのパブリッシュ処理中に生じたバインディングレイヤのエラーはステージレベルのエラーハンドラで捕捉できます。

空のエラーハンドラ

空のエラーハンドラ、つまりコンフィグレーションされていないエラーハンドラは、エラーハンドラがない状態と同じです。たとえば、ステージレベルのエラーハンドラを作成しても、コンフィグレーションを行うまでの間はエラーが「捕捉されず」、次のレベルのハンドラに処理が委ねられます。

エラーハンドラアクション

エラーハンドラによるエラー処理のしめくくりとして、以下のいずれかのアクションを選択できます。

表 14-47 エラーハンドラのアクション

エラーアクション	説明
返信	このアクションを割り当てると、プロキシサービスクライアントに対して即座にエラー応答が作成される。それ以降のすべてのメッセージフローの処理は停止され、メッセージに関係するコンテキスト変数に基づいて応答メッセージが送信される。この場合には、エラーハンドラをコンフィグレーションして、プロキシサービスに単純な応答を送信することも、エラーが発生したことを示すより詳細な応答を送信することも可能。成功時の HTTP 応答と失敗時の HTTP 応答の違いは以下のとおり。成功時の応答では、ステータスコード 200 と $body が送信される。失敗時の応答では、ステータスコード 500 と $body が送信される。
再開	このアクションを割り当てると、エラーが発生していないかのようにメッセージフローの処理が継続される。処理は、エラーが正常に解消された位置から継続される。残りのメッセージフローで予期されていない状態に陥ることになる可能性があるため、エラーハンドラにコンテキスト変数への対応をコンフィグレーションすることが必要な場合がある。エラーハンドラによりエラーが解消されると、そのエラーハンドラが正常に実行を完了したかのように処理が再開される。処理の再開点は、エラー発生点とは異なる。

エラーアクション

説明

返信

このアクションを割り当てると、プロキシサービスクライアントに対して即座にエラー応答が作成される。それ以降のすべてのメッセージフローの処理は停止され、メッセージに関係するコンテキスト変数に基づいて応答メッセージが送信される。この場合には、エラーハンドラをコンフィグレーションして、プロキシサービスに単純な応答を送信することも、エラーが発生したことを示すより詳細な応答を送信することも可能。

成功時の HTTP 応答と失敗時の HTTP 応答の違いは以下のとおり。

成功時の応答では、ステータスコード 200 と $body が送信される。

失敗時の応答では、ステータスコード 500 と $body が送信される。

再開

このアクションを割り当てると、エラーが発生していないかのようにメッセージフローの処理が継続される。処理は、エラーが正常に解消された位置から継続される。残りのメッセージフローで予期されていない状態に陥ることになる可能性があるため、エラーハンドラにコンテキスト変数への対応をコンフィグレーションすることが必要な場合がある。エラーハンドラによりエラーが解消されると、そのエラーハンドラが正常に実行を完了したかのように処理が再開される。処理の再開点は、エラー発生点とは異なる。

返信アクションも再開アクションも呼び出されない場合は、エラーが再送出されます。この場合、エラーは次のレベルのエラーハンドラに送られて処理されます。他に指定がない限り、再送出アクションはエラーハンドラのデフォルトのアクションです。

メッセージフローによるアクションの選択については、「エラーハンドラコンフィグレーション」を参照してください。

エラーハンドラコンフィグレーション

エラーハンドラはパイプラインの 1 つであるため、他のパイプラインと同じようにコンフィグレーションします。たとえば、パブリッシュアクションを使用して他のサービスにエラー通知を送信したり、割り当てアクションを使用してコンテキスト変数を変更したりできます。ただし、エラーハンドラでは、一部のアクションを使用できません。

エラーハンドラでは、標準のコンテキスト変数に加え、$fault 変数を使用できます。$fault 変数には、メッセージフロー処理中に発生したすべてのエラーに関する情報が格納されます。エラーが発生すると、エラーハンドラが呼び出される前にこの変数にエラーの情報が格納されます。$fault 変数は、エラーハンドラの中だけで定義されます。この変数は、単純な要求パイプラインおよび応答パイプラインの中では定義されません。これが、エラーパイプラインと他のすべてのパイプラインの重要な違いです。

$fault 変数内には、4 つのコア要素があります。

表 14-48 エラーハンドラコンフィグレーション

要素	説明
errorCode	エラーコードを文字列値として保持する
Reason	エラーの簡単な説明テキストを格納する
Details	エラーについての任意の XML コンテンツを格納する
Location	エラーが発生したパイプラインとステージを示す

$fault 変数は変更可能ですが、変更が関係するのはエラーハンドラ内だけです。

プロキシサービスへのエラー処理の追加

[メッセージフローの編集] ページでは、プロキシサービスにエラー処理を追加できます。エラー処理は、メッセージフロー、パイプライン、ルートノード、およびステージレベルでコンフィグレーションできます。詳細については、「エラーメッセージと処理」を参照してください。

プロキシサービスにエラー処理を追加するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。このページには以下の機能があります。

プロキシサービスアイコン
プロキシサービス名
パイプラインペアノードをすでに追加している場合は、パイプラインペアノードアイコンおよびパイプラインペアノード名
[エコーノード] アイコン
メッセージフロー内の各種オブジェクトに関連付けられたページにリンクされている、左側のナビゲーションペインのメッセージフローのマップ

開始ノード アイコンをクリックし、[サービスエラーハンドラの追加] をクリックします。[エラーハンドラ] アイコンがある [エラーハンドラの編集] ページが表示されます。

[エラーハンドラ] アイコンをクリックし、[ステージの追加] をクリックします。ステージ アイコン、[名前] フィールド、および [説明] フィールドが表示されます。

[名前] フィールドにステージ名を入力します。

[説明] フィールドにステージの説明を入力します。

[保存] をクリックして、ステージ名と説明を保存します。

ステージ アイコンをクリックし、[編集｜ステージ] をクリックします。[ステージコンフィグレーションの編集] ページが表示されます。

[アクションの追加] をクリックし、追加するアクションを選択して、アクションを追加します。

エラーハンドラはパイプラインの 1 つであるため、他のパイプラインと同じようにコンフィグレーションします。たとえば、パブリッシュ アクションを使用して他のサービスにエラー通知を送信したり、割り当てアクションを使用してコンテキスト変数を変更したりできます。追加するアクションの種類の詳細については、「アクションの追加」の該当する手順を参照してください。アクションは任意の組み合わせで連鎖できます。
また、これ以外にも、エラー発生、返信、および再開の 3 つのエラーアクションがよく使用されます。これらのアクションの詳細については、「エラーメッセージと処理」の「エラーハンドラアクション」を参照してください。
アクションを追加したら、次の手順に進みます。

以下のいずれか 1 つを実行します。

[保存] をクリックして、アクションを保存する。[エラーハンドラの編集] ページが表示されます。
[取り消し] をクリックして変更を取り消し、[エラーハンドラの編集] ページに戻る。
[クリア] をクリックして、[ステージコンフィグレーションの編集] ページを開いたまま保存前の編集内容を取り消す。

アクションを保存したら、以下のいずれか 1 つを実行します。

表 14-49 プロキシサービスへのエラー処理の追加

処理	手順
アクションの追加を続行してエラーハンドラをコンフィグレーションする	ステージアイコンをクリックし、[編集｜ステージ] をクリックする。
ステージ名と説明を編集する	ステージアイコンをクリックし、[編集｜名前と説明] をクリックする。
別のステージを追加する	[エラーハンドラ] アイコンまたはステージアイコンを選択し、[ステージの追加] をクリックする。
更新した内容を保存して [メッセージフローの編集] ページに戻る	[保存] をクリックする。
変更を取り消して [メッセージフローの編集] ページに戻る	[取り消し] をクリックする。
[エラーハンドラの編集] ページを開いたまま変更をクリアする	[クリア] をクリックする。

パイプラインへのエラー処理の追加

[メッセージフローの編集] ページでは、パイプラインにエラー処理を追加できます。エラー処理は、メッセージフロー、パイプライン、ルートノード、およびステージレベルでコンフィグレーションできます。詳細については、「エラーメッセージと処理」を参照してください。

注意 : パイプラインにエラーハンドラを追加する前に、パイプラインペアノードを作成する必要があります。詳細については、「パイプラインペアノードの追加」を参照してください。

パイプラインにエラー処理を追加するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。

既存のパイプラインペアノードを展開して、要求パイプラインと応答パイプラインから成るパイプラインペアを表示します。

エラー処理を追加するパイプラインをクリックし、[パイプラインエラーハンドラの追加] をクリックします。[エラーハンドラの編集] ページが表示されます。

[名前] フィールドにステージ名を入力します。

[説明] フィールドにステージの説明を入力します。

[保存] をクリックして、ステージ名と説明を保存します。

ステージ アイコンをクリックし、[編集｜ステージ] をクリックします。[ステージコンフィグレーションの編集] ページが表示されます。

[アクションの追加] をクリックし、追加するアクションを選択して、アクションを追加します。

エラーハンドラはパイプラインの 1 つであるため、他のパイプラインと同じようにコンフィグレーションします。たとえば、パブリッシュ アクションを使用して他のサービスにエラー通知を送信したり、割り当てアクションを使用してコンテキスト変数を変更したりできます。追加するアクションの種類の詳細については、「アクションの追加」の該当する手順を参照してください。アクションは任意の組み合わせで連鎖できます。
また、これ以外にも、エラー発生、返信、および再開の 3 つのエラーアクションがよく使用されます。これらのアクションの詳細については、「エラーメッセージと処理」の「エラーハンドラアクション」を参照してください。
アクションを追加したら、次の手順に進みます。

以下のいずれか 1 つを実行します。

[保存] をクリックして、アクションを保存する。[エラーハンドラの編集] ページが表示されます。
[取り消し] をクリックして変更を取り消し、[エラーハンドラの編集] ページに戻る。
[クリア] をクリックして、[ステージコンフィグレーションの編集] ページを開いたまま保存前の編集内容を取り消す。

アクションを保存したら、以下のいずれか 1 つを実行します。

表 14-50 パイプラインへのエラー処理の追加

処理	手順
アクションの追加を続行してエラーハンドラをコンフィグレーションする	ステージアイコンをクリックし、[編集｜ステージ] をクリックする。
ステージ名と説明を編集する	ステージアイコンをクリックし、[編集｜名前と説明] をクリックする。
別のステージを追加する	[エラーハンドラ] アイコンまたはステージアイコンを選択し、[ステージの追加] をクリックする。
更新した内容を保存して [メッセージフローの編集] ページに戻る	[保存] をクリックする。
変更を取り消して [メッセージフローの編集] ページに戻る	[取り消し] をクリックする。
[エラーハンドラの編集] ページを開いたまま変更をクリアする	[クリア] をクリックする。

ステージへのエラー処理の追加

[メッセージフローの編集] ページでは、ステージにエラー処理を追加できます。エラー処理は、メッセージフロー、パイプライン、ルートノード、およびステージレベルでコンフィグレーションできます。詳細については、「エラーメッセージと処理」を参照してください。

注意 : ステージにエラーハンドラを追加する前に、ステージを作成する必要があります。詳細については、「ステージの追加」を参照してください。

ステージにエラー処理を追加するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。

既存のパイプラインペアノードを展開して、要求パイプラインと応答パイプラインから成るパイプラインペアを表示します。それまでに追加したステージがある場合は、ステージ アイコンも表示されます。

編集するステージのステージ アイコンをクリックし、[追加｜ステージエラーハンドラ] をクリックします。[エラーハンドラの編集] ページが表示されます。

[名前] フィールドにステージ名を入力します。

[説明] フィールドにステージの説明を入力します。

[保存] をクリックして、ステージ名と説明を保存します。

ステージ アイコンをクリックし、[編集｜ステージ] をクリックします。[ステージコンフィグレーションの編集] ページが表示されます。

[アクションの追加] をクリックし、追加するアクションを選択して、アクションを追加します。

エラーハンドラはパイプラインの 1 つであるため、他のパイプラインと同じようにコンフィグレーションします。たとえば、パブリッシュ アクションを使用して他のサービスにエラー通知を送信したり、割り当てアクションを使用してコンテキスト変数を変更したりできます。追加するアクションの種類の詳細については、「アクションの追加」の該当する手順を参照してください。アクションは任意の組み合わせで連鎖できます。
また、これ以外にも、エラー発生、返信、および再開の 3 つのエラーアクションがよく使用されます。これらのアクションの詳細については、「エラーメッセージと処理」の「エラーハンドラアクション」を参照してください。
アクションを追加したら、次の手順に進みます。

以下のいずれか 1 つを実行します。

[保存] をクリックして、アクションを保存する。[エラーハンドラの編集] ページが表示されます。
[取り消し] をクリックして変更を取り消し、[エラーハンドラの編集] ページに戻る。
[クリア] をクリックして、[ステージコンフィグレーションの編集] ページを開いたまま保存前の編集内容を取り消す。

アクションを保存したら、以下のいずれか 1 つを実行します。

表 14-51 ステージへのエラー処理の追加

処理	手順
アクションの追加を続行してエラーハンドラをコンフィグレーションする	ステージアイコンをクリックし、[編集｜ステージ] をクリックする。
ステージ名と説明を編集する	ステージアイコンをクリックし、[編集｜名前と説明] をクリックする。
別のステージを追加する	[エラーハンドラ] アイコンまたはステージアイコンを選択し、[ステージの追加] をクリックする。
更新した内容を保存して [メッセージフローの編集] ページに戻る	[保存] をクリックする。
変更を取り消して [メッセージフローの編集] ページに戻る	[取り消し] をクリックする。
[エラーハンドラの編集] ページを開いたまま変更をクリアする	[クリア] をクリックする。

ルートノードへのエラー処理の追加

[メッセージフローの編集] ページでは、ルートノードにエラー処理を追加できます。エラー処理は、メッセージフロー、パイプライン、ルートノード、およびステージレベルでコンフィグレーションできます。詳細については、「エラーメッセージと処理」を参照してください。

注意 : ルートノードにエラーハンドラを追加する前に、ルートノードを作成する必要があります。詳細については、「ルートノードの追加」を参照してください。

ルートノードにエラー処理を追加するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。

ルートノード アイコンをクリックし、[エラーハンドラの追加] をクリックします。[エラーハンドラの編集] ページが表示されます。

[名前] フィールドにステージ名を入力します。

[説明] フィールドにステージの説明を入力します。

[保存] をクリックして、ステージ名と説明を保存します。

ステージ アイコンをクリックし、[編集｜ステージ] をクリックします。[ステージコンフィグレーションの編集] ページが表示されます。

[アクションの追加] をクリックし、追加するアクションを選択して、アクションを追加します。

エラーハンドラはパイプラインの 1 つであるため、他のパイプラインと同じようにコンフィグレーションします。たとえば、パブリッシュ アクションを使用して他のサービスにエラー通知を送信したり、割り当てアクションを使用してコンテキスト変数を変更したりできます。追加するアクションの種類の詳細については、「アクションの追加」の該当する手順を参照してください。アクションは任意の組み合わせで連鎖できます。
また、これ以外にも、エラー発生、返信、および再開の 3 つのエラーアクションがよく使用されます。これらのアクションの詳細については、「エラーメッセージと処理」の「エラーハンドラアクション」を参照してください。
アクションを追加したら、次の手順に進みます。

以下のいずれか 1 つを実行します。

[保存] をクリックして、アクションを保存する。[エラーハンドラの編集] ページが表示されます。
[取り消し] をクリックして変更を取り消し、[エラーハンドラの編集] ページに戻る。
[クリア] をクリックして、[ステージコンフィグレーションの編集] ページを開いたまま保存前の編集内容を取り消す。

アクションを保存したら、以下のいずれか 1 つを実行します。

表 14-52 ルートノードへのエラー処理の追加

処理	手順
アクションの追加を続行してエラーハンドラをコンフィグレーションする	ステージアイコンをクリックし、[編集｜ステージ] をクリックする。
ステージ名と説明を編集する	ステージアイコンをクリックし、[編集｜名前と説明] をクリックする。
別のステージを追加する	[エラーハンドラ] アイコンまたはステージアイコンを選択し、[ステージの追加] をクリックする。
更新した内容を保存して [メッセージフローの編集] ページに戻る	[保存] をクリックする。
変更を取り消して [メッセージフローの編集] ページに戻る	[取り消し] をクリックする。
[エラーハンドラの編集] ページを開いたまま変更をクリアする	[クリア] をクリックする。

エラーハンドラの表示と変更

[メッセージフローの編集] ページでは、エラーハンドラを表示し、変更できます。エラー処理は、メッセージフロー、パイプライン、ルートノード、およびステージレベルでコンフィグレーションできます。詳細については、「エラーメッセージと処理」を参照してください。

エラーハンドラを表示および変更するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。

以下のいずれか 1 つを実行します。

表 14-53 エラーハンドラの表示と変更

処理	手順
プロキシサービスのエラーハンドラの表示および変更	開始ノードアイコンをクリックし、[サービスエラーハンドラの編集] をクリックする。[エラーハンドラの編集] ページが表示される。詳細については、「プロキシサービスへのエラー処理の追加」を参照。
パイプラインのエラーハンドラの表示および変更	該当するパイプラインペアアイコンをクリックし、[パイプラインエラーハンドラの編集] をクリックする。[エラーハンドラの編集] ページが表示される。詳細については、「パイプラインへのエラー処理の追加」を参照。
ルートノードのエラーハンドラの表示および変更	ルートノードアイコンをクリックし、[編集｜エラーハンドラ] をクリックする。[エラーハンドラの編集] ページが表示される。詳細については、「ルートノードへのエラー処理の追加」を参照。
ステージのエラーハンドラの表示および変更	該当するステージアイコンをクリックし、[編集｜ステージエラーハンドラ] をクリックする。[エラーハンドラの編集] ページが表示される。詳細については、「ステージへのエラー処理の追加」を参照。

エラーハンドラの削除

[メッセージフローの編集] ページでは、既存のエラーハンドラを削除できます。エラー処理は、メッセージフロー、パイプライン、ルートノード、およびステージレベルでコンフィグレーションできます。詳細については、「エラーメッセージと処理」を参照してください。

エラーハンドラを削除するには

選択したプロキシサービスの [メッセージフローの編集] ページが表示されます。

以下のいずれか 1 つを実行します。

表 14-54 エラーハンドラの削除

処理	手順
プロキシサービスのエラーハンドラの削除	開始ノードアイコンをクリックし、[サービスエラーハンドラの削除] をクリックする。サービスのエラーハンドラが削除される。
パイプラインのエラーハンドラの削除	該当するパイプラインペアアイコンをクリックし、[パイプラインエラーハンドラの削除] をクリックする。パイプラインのエラーハンドラが削除される。
ルートノードのエラーハンドラの削除	ルートノードアイコンをクリックし、[エラーハンドラの削除] をクリックする。ルートノードのエラーハンドラが削除される。
ステージのエラーハンドラの削除	該当するステージアイコンをクリックし、[削除｜ステージエラーハンドラ] をクリックする。ステージのエラーハンドラが削除される。

注意 : [削除] をクリックすると、メッセージフローは現在のセッション内で更新されます。コンフィグレーションに対する変更が完了したら、左側のナビゲーションペインで、[Change Center] の下にある [アクティブ化] をクリックします。セッションが終了し、コアコンフィグレーションが更新されます。また、セッション中はいつでも [破棄] をクリックすることができ、現在のセッションでこれまでに加えた変更を取り消すことができます。

プロキシ サービス

プロキシ サービスの概要

サービスの種類

サービスの種類と転送方式

関連トピック

プロキシ サービスの追加

プロキシ サービスを追加するには - 全般的なコンフィグレーション

プロキシ サービスを追加するには - メッセージの種類のコンフィグレーション

プロキシ サービスを追加するには - 転送コンフィグレーション

プロキシ サービスを追加するには - プロトコル依存の転送コンフィグレーション

プロキシ サービスを追加するには - 操作選択コンフィグレーション

プロキシ サービスを追加するには - 全般的なコンフィグレーションの確認

プロキシ サービスからの WSDL の生成

関連トピック

プロキシ サービスの表示と検索

プロキシ サービスを表示および検索するには

関連トピック

プロキシ サービスの表示と変更

プロキシ サービスの詳細を表示および編集するには

関連トピック

プロキシ サービスの削除

プロキシ サービスを削除するには

関連トピック

メッセージ フローの概要

パイプライン

メッセージの実行

メッセージ フロー ツリーの構築

オペレーション ブランチ

関連トピック

メッセージ フローの表示と変更

メッセージ フローを表示および変更するには

関連トピック

パイプライン ペア ノードの追加

パイプライン ペア ノードを追加するには

関連トピック

条件付きブランチ ノードの追加

条件付きブランチ ノードを追加するには

関連トピック

オペレーション ブランチ ノードの追加

オペレーション ブランチ ノードを追加するには

関連トピック

ステージの追加

ステージを追加するには

関連トピック

アクションの追加

アクションを追加するには

更新アクション

関連トピック

ルート ノードの追加

ルート ノードを追加するには

関連トピック

ルート ノード アクションの追加

ルート ノード アクションを追加するには

関連トピック

条件付きブランチの詳細の表示と変更

条件付きブランチの詳細を表示および変更するには

関連トピック

オペレーション ブランチの詳細の表示と変更

オペレーション ブランチの詳細を表示および変更するには

関連トピック

ステージ コンフィグレーションの詳細の表示と変更

ステージ コンフィグレーションの詳細を表示および変更するには

関連トピック

XQuery 条件の編集

XQuery 条件を編集するには

関連トピック

XQuery 式の編集

XQuery 式を編集するには

関連トピック

XPath 式の編集

XPath 式を編集するには

関連トピック

新しいメッセージ コンテキスト変数の定義

新しいメッセージ コンテキスト変数を定義するには

関連トピック

エラー メッセージと処理

エラー ハンドラ

ネスト エラー ハンドラ

空のエラー ハンドラ

エラー ハンドラ アクション

プロキシサービス

プロキシサービスの概要

プロキシサービスの追加

プロキシサービスを追加するには - 全般的なコンフィグレーション

プロキシサービスを追加するには - メッセージの種類のコンフィグレーション

プロキシサービスを追加するには - 転送コンフィグレーション

プロキシサービスを追加するには - プロトコル依存の転送コンフィグレーション

プロキシサービスを追加するには - 操作選択コンフィグレーション

プロキシサービスを追加するには - 全般的なコンフィグレーションの確認

プロキシサービスからの WSDL の生成

プロキシサービスの表示と検索

プロキシサービスを表示および検索するには

プロキシサービスの表示と変更

プロキシサービスの詳細を表示および編集するには

プロキシサービスの削除

プロキシサービスを削除するには

メッセージフローの概要

メッセージフローツリーの構築

オペレーションブランチ

メッセージフローの表示と変更

メッセージフローを表示および変更するには

パイプラインペアノードの追加

パイプラインペアノードを追加するには

条件付きブランチノードの追加

条件付きブランチノードを追加するには

オペレーションブランチノードの追加

オペレーションブランチノードを追加するには

ルートノードの追加

ルートノードを追加するには

ルートノードアクションの追加

ルートノードアクションを追加するには

オペレーションブランチの詳細の表示と変更

オペレーションブランチの詳細を表示および変更するには

ステージコンフィグレーションの詳細の表示と変更

ステージコンフィグレーションの詳細を表示および変更するには

新しいメッセージコンテキスト変数の定義

新しいメッセージコンテキスト変数を定義するには

エラーメッセージと処理

エラーハンドラ

ネストエラーハンドラ

空のエラーハンドラ

エラーハンドラアクション

エラーハンドラコンフィグレーション

プロキシサービスへのエラー処理の追加

プロキシサービスにエラー処理を追加するには

ルートノードへのエラー処理の追加

ルートノードにエラー処理を追加するには

エラーハンドラの表示と変更

エラーハンドラを表示および変更するには

エラーハンドラの削除

エラーハンドラを削除するには