Message Map サンプルについて

サンプル・マップは、さまざまなブローカリング・シナリオをインプリメントする設計パターンを例示します。 メッセージ・マップ・ツールの設計により、これらの設計パターンを複合パターンとして結合することができます。 これにより、単純なシナリオ用の設計パターンを組み合わせて、複雑なシナリオ用のメッセージ・マップを作成することができます。 サンプル・ファイルはデプロイ可能であることを意図されてはいません。

完全メッセージ・アセンブリーの処理

完全メッセージ・アセンブリーを処理するための サンプル・ファイルは、Message Map Sample Message Flows プロジェクトの message_assembly フォルダーにあります。

メッセージ・アセンブリーは、メッセージのすべてのヘッダーと本文またはペイロードの組み合わせです。 メッセージ・フロー内の Mapping、DataInsert、DataUpdate、DataDelete、および Extract ノードは常に、 完全メッセージ・アセンブリーを処理します。 これは、これらのノードのマッピングにより、メッセージ・アセンブリー・モデルが、常にマップのソースとターゲットとして 示されることを意味します。

WebSphere Message Broker には、単純化された Properties モデルと完全な「ヘッダー」モデルの 2 つの メッセージ・アセンブリー・モデルがあります。 どちらを選択するかは、どちらのモデルがシナリオ要件に一致するかによります。 左のピクチャーはメッセージ・アセンブリーの Properties モデルを示し、右は Headers メッセージ・アセンブリー・モデルを 示しています。

プロパティー・アセンブリー

プロパティー・アセンブリー

WebSphere Message Broker メッセージ・アセンブリーには以下の 4 つの項目が含まれており、それらはピクチャー内で 番号付けされています。

  1. LocalEnvironment フォルダー
  2. Properties フォルダー
  3. トランスポート・レイヤー「メッセージ・ヘッダー」グループ
  4. メッセージ・ペイロードまたは本文

メッセージ・フローを、1 つのマッピング・ノードの後で Route To Label ジャンプを実行する構成にすることができます。 これは、フロー内内容ベース経路指定シナリオで役立ちます。

このサンプルには、以下の 3 つの共通シナリオがインプリメントされています。

どの場合も、メッセージの本文またはペイロードがメッセージ・アセンブリー内の最後の項目になります。

先頭に戻ります。

マップを使用したメッセージ・フロー処理の制御

メッセージ・アセンブリー labelName エレメントを使用して、マッピング・ノードの後のメッセージの経路指定を 制御します。 これは、マップから処理を継続するために、次のメッセージ・フロー・ノードを選択するシナリオで役立ちます。

次の図は、Mapping ノード、Route To Label ノード、およびいくつかの宛先 Label ノードで構成された サンプル・メッセージ・フロー・ファイル RouteToLabelUsingMap.msgflow を示しています。 Label ノードのターゲット宛先ラベルは、その名前と同じ構成になります。

Route To Label メッセージ・フロー

出力メッセージを処理する Label ノードを選択するためには、マップが Label ノード Label Name プロパティーを指定する必要が あります。 サンプル・マップ・ファイル SetLabelNodeLabelName.msgmap は、以下のように if 行を 2 つの condition と 1 つの else と共に使用して、 これを処理します。

Route To Label メッセージ・マップ

このサンプルでは、以下のようになります。

先頭に戻ります。

すべてのヘッダーをコピー

マップは多くの場合、メッセージの本文のみをフォーカスします。 このシナリオでは、すべてのヘッダーがマップによって変更されないままコピーされます。

すべてのヘッダーを未変更でコピーするには、Properties モデルを使用します。 単純化された Properties メッセージ・アセンブリー・モデルを選択すると、Properties フォルダー以外のすべての メッセージ・ヘッダーが順番に未変更でコピーされます。

Properties メッセージ・マップを作成したら、$source/Properties 複合エレメントを $target/Properties 複合エレメントにマップします。 これにより、Properties フォルダーが他のすべての未変更ヘッダーと共に未変更でソースからターゲットにコピーされます。

下のイメージは、すべてのヘッダー (Properties を含む) を未変更でコピーするために構成されたサンプル・ファイル CopyAllHeaders.msgmap を示しています。

すべてのヘッダーをコピー

先頭に戻ります。

プロパティーのマッピング

Properties モデルを使用すると、複数のヘッダーをマップすることによる複雑さに対応する必要なしに、多くの ブローカー・シナリオを使用可能にすることができます。 Properties は、MQ Series および MRM パーサーの重要なヘッダー属性の多くを抽出して、単一のパッケージ内で提供します。 MQ Series がトランスポート・レイヤーであり、MRM がメッセージ本体パーサーである場合、「すべてのヘッダーをコピー」シナリオに 加えて、Properties モデルを使用してください。 これらの属性は、以下のように分類されます。

Properties モデル

  1. メッセージの物理フォーマット
  2. トランスポート・レイヤー「サービス品質」
  3. 応答パス情報
  4. パブリッシュ/サブスクライブ・トピック

Properties モデル内のすべてのフィールドを設定する必要があることに注意しなければなりません。 例えば、出力メッセージ・ワイヤー・フォーマットを選択するために MessageFormat などの単一フィールドを 設定する必要がある場合は、Properties フォルダー内の他の値も設定またはコピーしてください。 明示的に設定されていないフィールドは出力メッセージにコピーされません。

先頭に戻ります。

ヘッダーのマッピング

Headers モデルを使用すると、プロパティーに加えて、選択したヘッダーをマップすることができます。 Headers モデルは「すべてのヘッダーをコピー」機能をサポートしないことに注意してください。 つまり、明示的にマップされていないヘッダーはターゲットの一部として作成されません。

ヘッダーは MQMD、MQ、HTTP、および JMS ヘッダーとしてカテゴリー化されます。 Headers モデルは JMS、SOAP over JMS、および HTTP シナリオに使用してください。 Properties モデルが必要な制御を提供していないときは、MQ シナリオに Headers モデルを使用して ください。

  1. MQ グループには MQMD および MQRFH2 ヘッダーが含まれます。 これがヘッダー構造定義であることに注意してください。 つまり、ランタイムでは、マップが自動的にソース・パーサーを処理します。 MQRFH2 ターゲットの場合、マップはバージョン 5 のブローカーでは MQRFH2 パーサーを、バージョン 6 のブローカーではより 高性能な MQRFH2C パーサーを動的に選択します。
    「すべてのヘッダーをコピー」機能を使用したコピーとは対照的に、MQRFH2 ヘッダーをマップするメッセージ・マップの すべての ESQL ダウンストリームは、このヘッダーの正しいパーサー名を使用して構成する必要があります。
  2. HTTP グループには、すべての標準ヘッダーが含まれます。 その他の HTTP ヘッダーは無視されます。 カスタム HTTP ヘッダーを処理する必要がある場合は、に記述されているとおり、マップを呼び出すように ESQL Compute ノードを構成する必要があります。
  3. JMS グループには標準 JMS ヘッダーが含まれます。 カスタム・バージョンを処理するには、に記述されているとおり、カスタム JMS ヘッダーを メッセージ・セットで定義し、マップを呼び出すように ESQL Compute ノードを構成する必要があります。
Headers モデル

先頭に戻ります。

複数の出力メッセージの作成

複数出力メッセージ・シナリオの サンプル・ファイルは、Message Map Sample Message Flows プロジェクトの multiple_output フォルダーにあります。

複数の出力メッセージを作成するための基本ルールは、複数の $target 行を暗黙的または明示的に宣言する ことです。 複数の行を、for 行を使用して、暗黙的に宣言することができます。 for 行を使用すると、ゼロ個以上の出力メッセージが作成されます (for 行ソースとして 提供されるソース項目につき 1 つ)。 複数の出力メッセージは、「ソースおよびターゲットの追加」メニューを使用して複数の ターゲットを明示的に追加することによっても作成できます。 そのようなターゲットのそれぞれが、1 つの出力メッセージを作成します。 ソース内の項目がそれぞれ独自に複数の出力メッセージを作成する場合、for 行と複数ターゲットを 組み合わせることも可能です。

複数のメッセージを出力するようにメッセージ・マップを構成することが有益であるようなシナリオがいくつかあります。 そのようなシナリオのいくつかを以下に示します。

メッセージ・マップ・ツールを使用すると、複数の出力メッセージを簡単に生成できます。 必要なのは、複数のターゲット・メッセージ・アセンブリーを指定するか、1 つのターゲット・メッセージ・アセンブリーを for 行に入れることだけです。

先頭に戻ります。

繰り返しフィールド用の複数出力メッセージの作成

このシナリオ用のサンプル・ファイルは、Message Map Sample Message Flows プロジェクトの multiple_output フォルダーにあります。

繰り返しソース・フィールド用の複数出力メッセージを作成するために必要なのは、ターゲット・メッセージ・アセンブリーを、 繰り返しソースに作用する for 行に入れることだけです。

サンプル・メッセージ・マップ repeating_source.msgmap は、 ソース・メッセージ・アセンブリー内の繰り返しフィールドを、呼び出し側メッセージ・フロー内の メッセージ・アセンブリーのストリームに変換します。 repeating_source.msgmap は、$target 行を for 行内で折り返して、複数の出力メッセージ・アセンブリー (繰り返し入力につき 1 つ) を作成します。 それぞれのアセンブリーごとに Properties フォルダーがコピーされます。 これは、「すべてのヘッダーをコピー」 動作が使用されることを意味します。 次に、それぞれの出力メッセージ・アセンブリー内に、単一の rtl:body がコピーされます。

バッチ繰り返し

先頭に戻ります。

複数パーツ入力メッセージ用の複数出力メッセージの作成

このシナリオ用のサンプル・ファイルは、Message Map Sample Message Flows プロジェクトの multipart_messages フォルダーにあります。

繰り返しフィールドの場合、繰り返し複数パーツ・ソース・メッセージ用の複数出力メッセージを作成するために必要なのは、 ターゲット・メッセージ・アセンブリーを、繰り返し複数パーツ・メッセージ定義に作用する for 行に入れる ことだけです。

複数パーツ・メッセージと通常の繰り返しフィールドとの主な違いは、複数パーツ・メッセージがローカル内容グループによって open または open-defined 内容モデル (XML スキーマに対するブローカー拡張) を使用して定義されて いるのに対し、繰り返しフィールドはエレメントによって定義されていることにあります。

複数パーツ・メッセージ用の異なるメッセージ・マップ構成を導入する代わりに、内容グループは、その内容が XML スキーマ・ワイルドカードであるかのように扱われます。 XML スキーマ・ワイルドカード・エレメント用のマップの作成には、呼び出し先サブマップの使用が必要になります。

サンプルに示されているとおり、ワイルドカード・エレメントは、エレメント固有のサブマップを通じてマップされます。 実際、ワイルドカードまたは「不明」エレメントは、サブマップ呼び出しによって「既知の」エレメントに変換されます。

バッチ繰り返し

先頭に戻ります。

非繰り返し入力用の複数出力メッセージの作成

このシナリオ用のサンプル・ファイルは、プロジェクト Message Map Sample Message Flows の 下のフォルダー multiple_output にある nonrepeating_source.msgmap です。

複数メッセージを作成する技法は、ソースが繰り返されるかどうかにかかわらず同じです。 この場合、複数の $target 行がマップによって明示的に宣言されます。 宣言されたターゲット行のそれぞれが出力メッセージを作成します。 繰り返しシナリオでは、ターゲット・アセンブリーを含む for 行によって複数のアセンブリーが暗黙的に 宣言され、for 内の項目につき 1 つの出力アセンブリーが作成されました。

バッチ繰り返し

先頭に戻ります。

メッセージ内のフィールドのソート、グループ化、または照合

このシナリオ用のサンプル・ファイルは、Message Map Sample Message Flows プロジェクトの sorting フォルダーにあります。 このテーマには 2 つのバリエーションがあります。

既知のキーでソート

マップのオーサリング時に、ソート用のキー値が既知であるときのソートまたはグループ化が、ファイル sorting.msgmap によって示されています。 可能な 3 つのフィールド値は、非繰り返し入力用の複数出力メッセージの作成の設計パターンを 使用して 3 つの個別メッセージにソートされます。

単一メッセージが複数メッセージに変換された後で、合計値またはレコード・カウントの計算が必要になる場合がよくあります。 この計算は、ファイル total.msgmap 内の 2 番目のステップによって処理される必要があります。 メッセージ・フロー sort.msgflow は、この結果を得るための 2 つのマッピング・ノードの 接続方法を示しています。

データベースからのキーでソート

サンプル・ファイルは sorting_dynamic.msgmap です。 このサンプルは、既知のキーでソートと非常に似ています。 大きな違いは、マップが、有効なキーのリストを取得するためにデータベースに進む必要があることです。 マップにおけるステップは以下のとおりです。

前出の例と同様に、これだけでは正しい出力メッセージが作成されず、total.msgmap マップをもう一度呼び出して 出力メッセージごとの合計を計算する必要があります。

先頭に戻ります。

ESQL からのマップの呼び出し

サンプル・ファイルは、プロジェクト Message Map Sample Message Flows のフォルダー esql_calling_msgmap にあります。

サンプルには、ESQL からマップを呼び出す方法が示されています。 ユーザーがメイン・マップではなくサブマップを呼び出すことを 前提としています。 サブマップは、別のマップまたは ESQL から呼び出されることを意図されたメッセージ・マップです。 「新規メッセージ・マップ」ウィザード (「ファイル」>「新規」>「メッセージ・マップ」) でサブマップを作成する には、以下のように「このマップは別のマップから呼び出され...」 ラジオ・ボタンを選択します。

「新規メッセージ・マップ」ウィザードでサブマップを作成

サブマップを呼び出すために必要な ESQL シグニチャーを以下に示します。

	submapName(
		sourcePath1, [sourcePath2, [...]]
		[targetPath, ]
		InputLocalEnvironment [, OutputLocalEnvironment])
	

少なくとも 1 つの sourcePath パラメーターが常時存在します。 これは、メッセージ・フロー・ノードを駆動するメッセージング入力を表します。 sourcePath は、メッセージ・マップを呼び出す前にソース・ツリー・ノードを参照するために初期化される ESQL REFERENCE 変数です。

targetPath は、ターゲット・ルート・ツリー・ノードを参照するオプションの ESQL REFERENCE 変数です。 この変数は、メッセージ・マップを呼び出す前に初期化する必要があります。 targetPath はオプションであり、メッセージ・マップにターゲット・パラメーターがない場合、 マップはメッセージング出力を作成しません。 この変数は、リレーショナル・データベースへのメッセージのシナリオに使用されます。 ここでは、マップが ESQL Database ノードから呼び出されます。

InputLocalEnvironment および OutputLocalEnvironment は、関連する ESQL ノード相関名に初期化される ESQL REFERENCE 変数です。 メッセージ・マップは、スキーマ・スコープ・プロシージャーとしてインプリメントされるため、相関名に直接アクセスすることは できません。

サンプル・コードは必須パラメーターを初期化して、マップを呼び出します。

先頭に戻ります。

集約シナリオでのメッセージ・マップの使用

サンプル・ファイルは、プロジェクト Message Map Sample Message Flows のフォルダー esql_calling_msgmap にあります。

マップを呼び出す ESQL の基本パターンがインプリメントされました。 Properties および Headers フォルダーを初期化して、必要な参照を作成し、マップを呼び出すための ESQL MODULE コードが作成されました。

マップは、すべての Aggregate ノード・フォルダー (Request1Request2 など) から 単一出力メッセージを構成します。 プロパティーとヘッダーが ESQL MODULE によって処理されたため、残りの作業は LocalEnvironment.Aggregate.AgregateRequestFolderName の内容を出力メッセージにコピーすること だけです。

先頭に戻ります。

XML スキーマ・シナリオ

以下のサンプル・シナリオは、メッセージ・マップ内でワイルドカード、タイプ拡張および制限、置換グループ、 内容モデル・グループを使用する XML スキーマ・モデルを変換するための設計パターンを示しています。

先頭に戻ります。

ワイルドカード・エレメント

ワイルドカード・エレメントおよび属性を処理するためのサンプル・ファイルは、Message Map Sample Message Flows プロジェクトの multipart_messages フォルダーにあります。

ワイルドカード・エレメントは、サブマップの呼び出しによって処理されます。 サブマップ内に、エレメントの名前がハードコーディングされています。 同じワイルドカードから異なるエレメント名を処理するには、ifcondition、 および else 行を使用してください。

サンプルでは単純繰り返しフィールドのシナリオがインプリメントされていますが、繰り返しソースが ブローカーの複数パーツ・メッセージ として形作られている少し複雑な例になっています。 複数パーツ・メッセージは、マップ・ツールによってワイルドカード・エレメントとして処理されます。 ワイルドカードは、正しいエレメント名のためのサブマップの呼び出しによって処理されます。

最初のマップでは、ターゲット・メッセージ・アセンブリーが for 行に含まれています。 for 行は、単一ソース・メッセージに含まれる繰り返し複数パーツ・メッセージに作用します。 ターゲット・アセンブリーが for 行に含まれていることは、完全ターゲット・メッセージ・アセンブリーが、 ソース内の入力複数パーツ・メッセージごとに 1 つずつ出力されることを意味します。 最初のメッセージ・マップには、複数パーツ・メッセージをサポートするワイルドカード・メッセージのマッピングも 含まれています。 このマッピングはサブマップと呼ばれ、ワイルドカードが表すエレメントの完全定義を戻す必要があります。

複数パーツ・エンベロープ・メッセージ

2 番目のマップでは、ワイルドカード・メッセージ・エレメントが rtl:body エレメントとなる制約を受けている ことがわかります。 このサブマップでは、ソースとターゲットは同じであり、ソースはディープ・コピーされてターゲットを作成します。

複数パーツが含まれているメッセージ

先頭に戻ります。

タイプ継承

このシナリオのサンプル・ファイルは、Message Map Sample Message Flows プロジェクトの xmlschema フォルダーにある type_to_substitutiongroup.msgmap です。

メッセージ・マップ・エディターでは、有効なタイプの組み合わせを示すために、特殊なソースおよび ターゲット・ツリー・フォルダーが使用されています。 フォルダーの名前は specializations for base type です。 フォルダーの内部には、基本タイプからのすべての非抽象導出と結合されたエレメントが示されています。 これらの具体的なエレメント表現のそれぞれには、完全な内容 (すべての可能な属性の後にすべての有効なエレメントが続く) が 含まれています。 基本的に、ツリーは XML スキーマ・モデルが記述するさまざまな XML エレメントを示します。

サンプル・メッセージ・マップでは、extensionType1 および extensionType2 代案を許可する XML スキーマ・モデルを使用してソースが記述されています。 これらの代案のそれぞれを個別にターゲットにマップすることができます。

タイプ拡張階層を、選択モデル、置換グループなどに結合することができます。 ただし、サンプルではこの複雑さを避けています。

先頭に戻ります。

置換グループ

このシナリオのサンプル・ファイルは、Message Map Sample Message Flows プロジェクトの xmlschema フォルダーにある type_to_substitutiongroup.msgmap です。

メッセージ・マップ・エディター内では、置換グループの組み合わせを使用する有効なエレメントを示すために、特殊なソースおよび ターゲット・ツリー・フォルダーが使用されています。 フォルダーの名前は substitutions for head element です。 フォルダーの内部には、基本タイプへのすべての非抽象導出と結合されたさまざまなエレメント名が示されています。 これらの具体的なエレメント表現のそれぞれには、完全な内容 (すべての可能な属性の後にすべての有効なエレメントが続く) が 含まれています。 基本的に、ツリーは XML スキーマ・モデルが記述するさまざまな XML エレメントを示します。

サンプル・メッセージ・マップでは、抽象 HeadElement エレメントに対する Substitute1 および Substitute2 代案を許可する XML スキーマ・モデルを使用してターゲットが記述されています。 これらの代案のそれぞれを個別にソースにマップすることができます。

置換グループは、タイプ階層に結合することができます。 ただし、サンプルではこの複雑さを避けています。

先頭に戻ります。

繰り返しモデル・グループ

このシナリオ用のサンプル・ファイルは、Message Map Sample Message Flows プロジェクトの modelgroups フォルダーにあります。

先頭に戻ります。

メインページのアイコン   サンプルのホームに戻る