Cisco ACE XML Gateway ユーザ ガイド
JMS トラフィックに関する作業
JMS トラフィックに関する作業
発行日;2012/02/01 | 英語版ドキュメント(2009/11/20 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 8MB) | フィードバック

目次

JMS トラフィックに関する作業

でサポートされる JMS について

JMS の概要の設定

JMS メディエーションについて

クラスタおよびメッセージ バス

JMS メッセージング サーバの指定

JMS ハンドラおよびサービス記述子の設定

JMS ハンドラの作成

サービス記述子の作成

JMS メディエーションの設定

JMS トラフィックに関する作業

この章では、ネットワーク上のホスト間でメッセージをやり取りする Java ベースのテクノロジー Message Service(JMS)の形式のトラフィックで、ACE XML Gateway を使用する方法について説明します。内容は次のとおりです。

「ACE XML Gateway でサポートされる JMS について」

「JMS メッセージング サーバの指定」

「JMS ハンドラおよびサービス記述子の設定」

「JMS メディエーションの設定」

ACE XML Gateway でサポートされる JMS について

JMS 統合の機能は、オプションで別にインストールされた Gateway の拡張機能を介して ACE XML Gateway によって提供されます。拡張機能がインストールされている場合、ACE XML Gateway を使用して JMS トラフィックを管理、ルーティング、およびセキュリティ保護するために使用できます。


) JMS 拡張モジュールがシステムにインストールされている場合、ポリシー ハンドラの作成時にプロトコル メニューで JMS オプションを表示できます。このオプションが表示されない場合で、JMS ルーティングを使用する場合、使用している Cisco ACE XML ゲートウェイ のサポート担当者に問い合せてください。


JMS プロバイダーとやり取りするよう ACE XML Gateway を設定できる数多くの方法があります。Gateway では、特定のキューまたはトピックでリッスンすることによってメッセージを受信したり、JMS キューまたはトピックにメッセージを発行したりすることができます。1 つのキューからメッセージを受信し、それを検証し、別のものに発行することによって、メッセージ検証を実行できます。

図 16-1 Gateway から JMS へ

 

ACE XML Gateway では、次の図で示したように、別の JMS システム間で統合ポイントとしても動作できます。

図 16-2 Gateway から JMS へ

 

ACE XML Gateway では、JMS メッセージを SOAP または HTTP メッセージに、またはその逆に変換することによって、異なる形式間が取り次がれます。この場合、ACE XML Gateway は、別のネットワーク エンティティ間の位置に置かれます。

図 16-3 JMS メディエーション

 

JMS メッセージには、次の部分で構成されることがあります。

必須ヘッダーには、宛先、メッセージ ID、タイムスタンプなどの情報が、名前と値のペアとして含まれます。

オプションのプロパティは、アプリケーション固有の名前と値のペア(ヘッダーの名前と値のペアの補足)です。たとえば、プロパティが存在することを要求するか、または、プロパティ コンテンツまたはタイプをチェックすることによって、ACE XML Gateway では、メッセージのプロパティを検証できます。

オプションのペイロード(または本文)には、名前と値のペア、テキスト コンテンツ(XML など)、または未解釈バイトなど、さまざまなタイプのデータが含まれることがあります。ペイロードに XML テキストが含まれている場合、ACE XML Gateway により、メッセージの XML 署名の検証または適用、XML 暗号の暗号化または復号化、コンテンツの変換などを行うことができます。

ACE XML Gateway では、WebSphere MQ(MQSeries)および TIBCO Enterprise Message Service がサポートされます。さらに、I/O SDK では、JMS により、他に実装されている JMS とともに動作するように拡張できます。

JMS の概要の設定

JMS トラフィックに対して ACE XML Gateway を設定する一般的な手順は、次の手順のように、プロトコルの他のタイプの設定に類似しています。

1. ポリシーで(メッセージング サーバ オブジェクトとして)メッセージング サーバ接続情報を設定します。

2. JMS トピック サブスクライバまたはキュー リスナーとしてハンドラを作成します。

3. メッセージング サーバ オブジェクトを使用して、JMS の宛先を指定するサービス記述子を作成します。

4. ルートによって、ハンドラとサービス記述子を接続します。

この章では、JMS 固有の手順について説明します。ハンドラ、サービス記述子、ルートに関する一般情報については、 第 5 章「ハンドラ、ルート、およびサービス記述子の使用方法」 を参照してください。

JMS メディエーションについて

Gateway では、たとえば、JMS メッセージを HTTP メッセージに変換することによって、および、その逆を行うことによって、別のプロトコル間のエンドポイント間でメッセージが仲介されます。ACE XML Gateway でプロトコルのメディエーションを実装するには、それぞれのプロトコルのハンドラおよびサービス記述子を設定し、それらの間のルートを作成し、必要に応じて、それぞれの側の間でプロパティおよびフィールドをマッピングします。

プロトコルは、同期(要求ごとに応答が想定される)の場合と、非同期(応答が想定されない)の場合があることに、注意してください。プロトコル メディエーションは、一般的に、同じモードのプロトコルのオブジェクト間でだけ、サポートされます。つまり、非同期オブジェクトは別の非同期オブジェクトだけを経由してルーティングでき、同期オブジェクトは別の同期オブジェクトだけを経由してルーティングできます。たとえば、非同期 JMS メッセージは、ネイティブ Tibco/Rendezvous または非同期 HTTP POST ebXML だけを経由してルーティングされますが、要求ベースおよび応答ベースの SOAP ドキュメントの宛先にはルーティングされません。

この要件は、サービス記述子へのルートを設定するときに、同期 JMS ハンドラがでは、有効なルーティング オプションが使用可能になるよう、Web コンソールで実行されます。

JMS メッセージと別の形式のメッセージとの間のマッピングは、必要に応じて、簡素化したり、複雑にしたり、することができます。簡単なメディエーション シナリオでは、単に、JMS メッセージ ハンドラに HTTP POST 本文サービス記述子をルーティングし、本文のパススルーを指定できます。この場合、ACE XML Gateway で JMS メッセージを受信するときに、サービス記述子で指定された宛先に送信する前に、対応する HTTP POST メッセージが作成され、HTTP メッセージの本文に元のメッセージの本文のコンテンツが置かれます。

より複雑なシナリオでは、着信 JMS 要求のプロパティを指定し、発信メッセージのプロパティにマッピングし、XML 本文のコンテンツを変換し、ターゲット メッセージのプロパティに出力をマッピングするか、または、(XPath によって示された)XML 本文の一部をプロパティにマッピングすることができます。

JMS メッセージ プロパティをターゲット メッセージに送信するには、ハンドラと対応するサービス記述子のメッセージ仕様設定で、(引数として)プロパティを指定する必要があります。

予想可能なように、サービス記述子の発信要求仕様にマッピングされる引数に、ハンドラの着信要求仕様の引数を設定する必要があり、また、サービス記述子の着信応答仕様で、ハンドラの発信応答にコンテンツをマッピングする必要があります。

クラスタおよびメッセージ バス

一般的に、ACE XML Gateway は、Gateway のクラスタの一部の場合でも、単独で動作している場合でも、同様に実行されます。ただし、1 つの重要な違いは、ACE XML Gateway クラスタでは、非クラスタ Gateway とは異なる方法で、メッセージ バス サーバに対するトラフィックが処理されます。

メッセージ バス サーバによって使用されるルーティング モデルは、いくつかの形式を取ります。JMS の用語では、モジュールは次のように認識されています。

キュー ベースのメッセージング。(複数のクライアントがキュー上でリッスンしている場合でも)メッセージは、1 つかつ唯一のクライアントによって使用されます。

トピック ベースのメッセージング。複数のクライアントによってメッセージが使用され、その数の分だけトピックにサブスクライブされます。

トピック ベースの配信では、メッセージ バスで、多くの異なる発信元および宛先で多くのメッセージが同時に送受信されるため、送信中の各メッセージの多くのコピーが同時に存在する可能性があります。

1 つの Gateway アプライアンスでは、メッセージの送受信を行うことができますが、クラスタ内の他の Gateway アプライアンスにそのメッセージを無視するように伝達することはできません。メッセージ バス サーバにより、メッセージの多くのコピーが送信される場合があるため、クラスタ内の各 Gateway アプライアンスでメッセージのコピーが参照される可能性が大きくなり、したがって、クラスタのメンバごとに一度、多くの回数処理されることになります。

アプリケーションのロジックで、メッセージを複数回処理することが認められる場合、ACE XML Gateway クラスタでメッセージが複数回代行受信され、処理されることは、問題ではありません。他方で、アプリケーションで各メッセージが一度に限定されて処理されることに依存している場合、トピック ベース メッセージ トラフィックを処理するよう、Gateway クラスタを設定することは、適切ではないことがあります。

解決策の 1 つとしては、単一の非クラスタ Gateway を設定し、トピック ベースのメッセージ トラフィックを処理することが考えられます。Gateway アプライアンスが 1 つだけ存在することにより、各メッセージが一度だけ処理されることが保証されます。他方で、キュー ベースのメッセージ トラフィックは、クラスタまたは非クラスタの Gateway のいずれかによって処理できることに注意してください。

メッセージ バスと使用するために Cisco ACE XML ゲートウェイ を設定する詳細については、使用しているシステムのサポート担当者まで問い合せてください。

JMS メッセージング サーバの指定

JMS トラフィックの ACE XML Gateway の設定の最初の手順は、ポリシーでメッセージ サーバ オブジェクトを作成して、JMS デーモンをホストするサーバを指定します。サーバは、ACE XML Gateway がメッセージまたはメッセージのソースのいずれかを配信する宛先として動作します。

ACE XML Gateway ポリシーには、MQSeries および TIBCO Rendezvous を含む、さまざまなタイプのメッセージング サーバを設定できます。特に JMS に対してセキュリティまたはメディエーションを実装しようとする場合、JMS が実装されている TIBCO Enterprise Message Service または MQSeries の場合でも、新しいサーバを JMS サーバとして設定するようにしてください。

JMS メッセージング サーバの表記をポリシーに追加するには、次の操作を実行します。


ステップ 1 Web コンソールの操作メニューで、[Policy] エリアにある [Messaging Servers] リンクをクリックします。

[Messaging Servers] ページが表示されます。このページはサーバ タイプによって整理されており、ページの上部に TIBCO Rendezvous(TIB/RV)サーバ、中間部に MQSeries サーバ、下部に JMS サーバが表示されます。

ステップ 2 [JMS Servers] セクションの上部で [Add a New JMS Server] ボタンをクリックします。

ボタンが使用可能な場合、JMS 統合の拡張機能は、システムにはインストールされていません。詳細については、サポート担当者に問い合せてください。

ステップ 3 [New Server] ページで、ポリシー内の JVM サーバで固有なサーバの名前を入力します。

ステップ 4 [Provider] フィールドで、example-jms.eng:7222 などの host : port の形式で JMS サービス プロバイダーの接続情報を入力します。

ホストの値は、JMS デーモンが実行中のノードの完全修飾ホスト名または IP アドレスである必要があります。ポートの値は、デーモンがメッセージを送信する宛先となるポートの番号です。

ステップ 5 [JMS Vendor] メニューで、サービス プロバイダー ベンダーの名前を選択します。ベンダーを指定すると、ACE XML Gateway により、JMS に実装されているベンダー固有の多様性がイネーブルにされます。

ステップ 6 [Save Changes] をクリックし、変更内容を現在アクティブなサブポリシーにコミットします。


 

これで、次のセクションで説明されているように、サーバをサービス記述子に適用できるようになっています。

JMS ハンドラおよびサービス記述子の設定

次に、JMS メッセージにサービス ハンドラおよび記述子を設定する手順について説明します。

JMS ハンドラにより、ACE XML Gateway での JMS メッセージの受信がイネーブルになります。メッセージを受信する ACE XML Gateway で JMS キューまたはトピックが指定されます。他方、サービス記述子により、ACE XML Gateway によってメッセージが配信される JMS の宛先が指定されます。

Gateway により、JMS と他のメッセージの形式との間が仲介されます。この場合、ハンドラとサービス記述子のペアの一方の側だけが、JMS プロトコル オブジェクトになります。

JMS ハンドラの作成

JMS ハンドラを作成するには、次の操作を実行します。


ステップ 1 操作メニューの [Policy] エリアで、[Virtual Services] リンクをクリックします。

ステップ 2 [Virtual Services] ブラウザ ページで、[Create a New] メニューにある [Handler] を選択し、[Create] ボタンをクリックします。

[Step 1 of 5: Handler Protocol] ページが表示されます。

ステップ 3 プロトコル メニューで、次のいずれかを選択します。

[JMS Request-Reply]:同期方式でのメッセージのやり取り用。このオプションは、応答の作成が想定されている JMS メッセージ用です。このオプションを使用すると、受信メッセージの要件だけではなく、JMS プロバイダーに返す応答の要件も指定できます。

[JMS Fire-and-Forget]:メッセージに対する応答が指定されない、非同期方式での JMS メッセージのやり取り用。

ステップ 4 [Continue] をクリックします。

ステップ 5 [Step 2 of 5: General Information] ページで、[Name] フィールドにハンドラの記述子名を入力し、[Handler Group] リストからハンドラを作成する必要があるハンドラ グループを選択します。必要に応じ、他の必要な設定を行います。

ハンドラに対する一般的な設定の詳細については、「ハンドラの作成」を参照してください。

ステップ 6 [Continue] をクリックします。

[Step 3 of 5: General Information] ページが表示されます。

ステップ 7 [JMS Server] メニューで、「JMS メッセージング サーバの指定」で作成したサーバを選択します。このサーバは、ACE XML Gateway で送受信するメッセージが生成されるデーモンのホストである必要があります。


) サーバがリストに表示されない場合、[Add New Server] ボタンをクリックし、サーバをポリシーに追加できます。


ステップ 8 [Subscribe to] メニューで、次のオプションから JMS メッセージ配信メカニズムを選択します。これらは、JMS によって定義された 1 つの標準デリバリ モデルに対応することに注意してください。

[Topic]。このデリバリ モードでは、メッセージは、指定されたトピックにサブスクライブされているクライアントと同じ数のクライアントに配信されます。

[Queue]。このデリバリ モードでは、メッセージは、1 つのキュー リスナーによって受信されるキューに配信されます。


) 詳細は、http://java.sun.com/products/jms/index.jsp で JMS ドキュメントを参照してください。


ステップ 9 サブスクリプション メニューの横にあるテキスト フィールドで、キューの識別情報を入力し、[Continue] ボタンをクリックします。

ステップ 10 [Step 4 of 5: Request Message Specification] ページで、受信メッセージの引数設定を指定します。

メッセージ仕様で、受信メッセージで想定される引数を設定できます。この方法での引数の指定は、次の 2 つの目的で用意されています。1 つ目の目的では、着信メッセージを検証できます(つまり、宛先で想定されているプロパティがメッセージ含まれていることを確認できます)。2 つ目の目的では、ハンドラとサービス記述子との間のルートでマッピング機能をイネーブルにできます。

他の形式でのフィールドへの(本文以外の)JMS プロパティのマッピングを含むメディエーションを実行する場合、 Request Message Specification ページで引数を指定する必要があります。

着信要求メッセージで [Arguments] を設定するには、次の操作を実行します。

a. [Add a New Row] ボタンをクリックします。

引数の要件を設定するフィールドが表示されます。

b. 次のフィールドを設定することによって、引数の検証を指定します。

[Name] は、メッセージに表示されるプロパティの名前です。これは、ポリシーに設定するすべての引数の必須フィールドです。

[Req] は、プロパティが必須か任意かを示します。このオプションを選択し、メッセージにプロパティがない場合、メッセージはブロックされます。

[Type] メニューで、プロパティのデータ タイプを選択します。ACE XML Gateway により、指定された引数が、[String]、[XML]、[Integer]、[Float]、[Boolean]、[Time]、または [Binary] のタイプから選択したタイプになります。

選択したタイプにより、検証メカニズム(つまり、XML 引数の XML スキーマ)または引数のコンテンツを追加で指定できます。たとえば、整数の場合、引数が 1000 未満である必要があると指定できます。

ステップ 11 ページの [Body Content Specification] エリアで、ACE XML Gateway がメッセージのペイロードを検証する必要がある方法について、次のオプションから指定します。

[Treat the body content as raw bytes (opaque data) with no validation]:検証する必要がある raw バイトがペイロードに含まれている場合、このオプションを選択します。

[Treat the body content as XML with no validation]:コンテンツが XML の場合に、ACE XML Gateway でメッセージ コンテンツの検証を抑制する場合に、このオプションを選択します。このオプションを選択すると、変換などの他の XML オプションが、Web コンソールのサービスで使用できるようになります。

[Validate that the body is well-formed XML only, with no content validation]:ACE XML Gateway は本文が適正な形式の XML になっていることは保証しますが、XML スキーマに対する本文の検証は行いません。

[Validate the body as XML according to]:ACE XML Gateway がメッセージ本文コンテンツを検証する XML スキーマを指定できます。ユーザは、XML スキーマを指定でき、そのスキーマ内から、メッセージが準拠する必要がある特定の名前空間および要素を選択できます。

ステップ 12 [Continue] ボタンをクリックします。

[Step 5 of 5: Response Message Specification] ページが表示されます。Fire-and-Forget JMS メッセージ ハンドラでは、応答が想定されていないため、メッセージは空です。ただし、Request-Reply JMS メッセージ ハンドラでは、ページは、要求メッセージ仕様ページと同じです。

ステップ 13 Request-Reply JMS メッセージ ハンドラでは、コントロールを使用して、発信応答メッセージの要件を定義します。

要件は、元の要求を作成したサーバに戻される前に、メッセージに適用されます。

ステップ 14 [Continue] をクリックします。

ハンドラのルートを追加するかどうかを確認するプロンプトが表示されます。

ステップ 15 宛先サービス記述子がポリシーにすでに存在する場合、ここでルートを追加できます。これ以外の場合、[Finish Without Adding a Route] をクリックし、ハンドラの初期設定を完了します。


 

ハンドラの初期設定が完了しました。プロパティ ページを使用すると、XML 署名の検証または生成、XML の暗号化または復号化など、追加オプションを設定できます。

サービス記述子の作成

JMS サービス記述子の作成は、JMS ハンドラの作成に類似していますが、JMS のユーザではなく JMS の作成者のために設定を定義することになります。つまり、サービス記述子インターフェイスで、JMS サブスクリプション プロファイルではなく JMS の宛先を定義します。

JMS サービス記述子を作成するには、次の操作を実行します。


ステップ 1 操作メニューの [Policy] エリアで、[Virtual Services] リンクをクリックします。

ステップ 2 [Virtual Services] ブラウザ ページで、[Create a New] メニューにある [Service Descriptor] を選択し、[Create] ボタンをクリックします。

ステップ 3 プロトコル選択メニューで、次のいずれかを選択します。

[JMS Request-Reply]:同期方式でのメッセージのやり取り用。このオプションが選択されている場合、ACE XML Gateway では、メッセージに対する応答が想定されます。

[JMS Fire-and-Forget]:応答が想定されない、非同期方式での JMS メッセージのやり取り用。

ステップ 4 [Continue] ボタンをクリックします。

[General Information] ページが表示されます。

ステップ 5 [Name] フィールドのサービス記述子に、わかりやすい名前を入力します。

ステップ 6 [Server] メニューで、メッセージの送信先となるプロバイダーをホストする JMS サーバを選択します。

サーバがメニューに表示されない場合、[Add a New Server] ボタンをクリックし、「JMS メッセージング サーバの指定」で説明されているように、サーバを作成します。

ステップ 7 [Continue] をクリックします。

ステップ 8 [Destination] メニューで、次のオプションから JMS メッセージの宛先のタイプを選択します(これらは、JMS によって定義された 1 つの標準メッセージ デリバリ モデルに対応することに注意してください)。

[Topic]。このデリバリ モードでは、メッセージは、指定されたトピックにサブスクライブされているクライアントと同じ数のクライアントに配信されます。

[Queue]。このデリバリ モードでは、メッセージは、1 つのキュー リスナーによって受信されるキューに配信されます。

ステップ 9 宛先メニューの横にあるテキスト フィールドで、キューまたはトピックの識別情報を入力します。

ステップ 10 JMS の要求と返信のサービス記述子で、必要に応じ、次の設定パラメータを指定します。

[Timeout]。このフィールドに指定した時間内で接続を確立できなかった場合、ACE XML Gateway によってイベントが記録され、接続試行が放棄されます。

[Service Time Threshold]。このフィールドに指定したミリ秒内で接続を確立できなかった場合、ACE XML Gateway によってイベントが記録されますが、サーバへの接続試行は継続されます。

ステップ 11 [Continue] ボタンをクリックします。

ステップ 12 [Step 4 of 5: Request Message Specification] ページで発信要求の要件を設定し、[Step 5 of 5: Response Message Specification] ページで着信応答の要件を設定します。

応答は想定されていないため、Fire-and-Forget では、応答に対する設定は用意されていないことに注意してください。

ハンドラについては、発信 JMS 要求で、別の形式からプロパティにフィールドがマッピングされるプロトコル メディエーションを実装する場合、サービス記述子の引数を指定する必要はありません。

メッセージ仕様コントロールの使用に関する詳細は、「JMS ハンドラの作成」の該当する説明を参照してください。

ステップ 13 [Continue] ボタンをクリックし、サービス記述子の初期設定を完了します。サービス記述子のプロパティ ページが表示されます。

これで、サービス記述子の初期設定が完了します。続いて、プロパティ ページを使用すると、XML の署名検証または生成、XML の暗号化または復号化など、別の設定を追加できます。

ステップ 14 終了時に、[Virtual Services] ページにあるハンドラからこのサービス記述子へのルートを設定します。異なるプロトコルのハンドラとサービス記述子との間でのルートの設定に関する詳細は、「JMS メディエーションの設定」を参照してください。


 

サービス記述子の初期設定が完了しました。プロパティ ページを使用すると、XML 署名の検証または生成、XML の暗号化または復号化など、追加オプションを設定できます。

JMS メディエーションの設定

ここでは、簡素なメディエーションの設定手順の概要について説明します。手順では簡素な実装が反映されていますが、ポリシー内でメディエーションが実装される方法について理解する一助となり、ユーザの実装で使用を開始できるようになります。


ステップ 1 まだ実装されていない場合、ソース メッセージとターゲット メッセージのハンドラとサービス記述子を作成します。

アソシエーションされるハンドラとサービス記述子は、異なるプロトコル タイプであることが可能ですが、非同期プロトコルのハンドラは、非同期のプロトコルのサービス記述子にだけルーティングされます。同様に、同期プロトコルは同期プロトコルにだけルーティングできます。

ステップ 2 ハンドラとサービス記述子にマッピングを作成する引数を定義します。

ステップ 3 ハンドラからサービス記述子へのルートを作成します。ハンドラのプロパティ ページの下部にある [Add New Route] ボタンをクリックすると、ルートを作成できます。


) ルートの作成に関する詳細は、「ルートの使用方法」を参照してください。


図 16-4 に示されているように、ルートの作成後、ハンドラのプロパティ ページでルート使用が表示されます。

図 16-4 ルートの仕様

 

基本メディエーションは、自動的に発生します。つまり、ACE XML Gateway により、デフォルトで、異なるプロトコルのサービス記述子とハンドラとの間の経路にルーティングされるメッセージの本文に、パススルーが実装されます。ただし、次の手順でカスタム マッピングを設定できます。

ステップ 4 デフォルトのメッセージ マッピング動作を変更するには、ハンドラのルート エリアで、次のオプションの [edit] リンクをクリックします。

[Req.Processing] では、ハンドラからサービス記述子に渡される要求メッセージ(つまり、バックエンド サービスに宛てられるメッセージ)のプロパティがマッピングされます。

[Resp.Processing] では、ACE XML Gateway によってサービス記述子からハンドラに渡されるときに、応答メッセージ(つまり、ユーザに宛てられるメッセージ)のプロパティがマッピングされます。

ステップ 5 [Edit Route Request Processing] ページまたは [Edit Route Response Processing] ページのコントロールは、サービス記述子またはハンドラのプロトコルによって、さまざまです。たとえば、HTTP GET の本文コンテンツ処理を設定するオプションはありません。ただし、一般的に、[Map body to body and arguments] または [Map body and arguments to body and arguments] のように、引数から本文処理メニューに対して実行されるマッピングのタイプを選択することによって、必要なマッピングが達成されます。終了すると、ページにマッピング フィールドが表示されます。

ステップ 6 マッピング フィールドを使用して、各マッピングのソース フィールドおよびターゲット フィールドを設定します。メッセージ仕様形式で設定されたすべてのプロパティが、マッピング メニュー コントロールで使用可能です。

対応するターゲット フィールド マッピングを指定しないソース フィールドが存在する場合、ソース フィールドはメッセージから分離され、そのコンテンツは失われます。

XML プロパティまたは本文コンテンツでは、次の指定を行うことができます。

ターゲット フィールドに送信される前にコンテンツに適用される XSLT

ターゲット フィールドに送信される XML プロパティまたは本文の一部を指定する XPath

たとえば、図 16-5 のマッピングにより、出力メッセージの本文に送信される XML 本文の一部、および、出力メッセージのプロパティを構成するハード コードされた値が、指定されます。

図 16-5 プロパティおよび本文のマッピングの形式

 

ステップ 7 完了したら、[Save Changes] をクリックし、ポリシーを導入して ACE XML Gateway への変更を有効にします。