サンプル・マップは、さまざまなブローカリング・シナリオをインプリメントする設計パターンを例示します。 メッセージ・マップ・ツールの設計により、これらの設計パターンを複合パターンとして結合することができます。 これにより、単純なシナリオ用の設計パターンを組み合わせて、複雑なシナリオ用のメッセージ・マップを作成することができます。 サンプル・ファイルはデプロイ可能であることを意図されてはいません。
完全メッセージ・アセンブリーを処理するための サンプル・ファイルは、Message Map Sample Message Flows プロジェクトの message_assembly フォルダーにあります。
メッセージ・アセンブリーは、メッセージのすべてのヘッダーと本文またはペイロードの組み合わせです。 メッセージ・フロー内の Mapping、DataInsert、DataUpdate、DataDelete、および Extract ノードは常に、 完全メッセージ・アセンブリーを処理します。 これは、これらのノードのマッピングにより、メッセージ・アセンブリー・モデルが、常にマップのソースとターゲットとして 示されることを意味します。
WebSphere Message Broker には、単純化された Properties モデルと完全な「ヘッダー」モデルの 2 つの メッセージ・アセンブリー・モデルがあります。 どちらを選択するかは、どちらのモデルがシナリオ要件に一致するかによります。 左のピクチャーはメッセージ・アセンブリーの Properties モデルを示し、右は Headers メッセージ・アセンブリー・モデルを 示しています。
WebSphere Message Broker メッセージ・アセンブリーには以下の 4 つの項目が含まれており、それらはピクチャー内で 番号付けされています。
メッセージ・フローを、1 つのマッピング・ノードの後で Route To Label ジャンプを実行する構成にすることができます。 これは、フロー内内容ベース経路指定シナリオで役立ちます。
このサンプルには、以下の 3 つの共通シナリオがインプリメントされています。
どの場合も、メッセージの本文またはペイロードがメッセージ・アセンブリー内の最後の項目になります。
メッセージ・アセンブリー labelName
エレメントを使用して、マッピング・ノードの後のメッセージの経路指定を
制御します。
これは、マップから処理を継続するために、次のメッセージ・フロー・ノードを選択するシナリオで役立ちます。
次の図は、Mapping ノード、Route To Label ノード、およびいくつかの宛先 Label ノードで構成された
サンプル・メッセージ・フロー・ファイル RouteToLabelUsingMap.msgflow を示しています。
Label
ノードのターゲット宛先ラベルは、その名前と同じ構成になります。
出力メッセージを処理する Label ノードを選択するためには、マップが Label ノード Label Name プロパティーを指定する必要が
あります。
サンプル・マップ・ファイル SetLabelNodeLabelName.msgmap は、以下のように
if
行を 2 つの condition
と 1 つの else
と共に使用して、
これを処理します。
このサンプルでは、以下のようになります。
$source/rtl:body/content
がゼロであるメッセージはすべて、Label ノード Target1 からダウンストリームの
フロー・ノードによって処理されます。
$source/rtl:body/content
がゼロよりも大きいメッセージはすべて、Label ノード Target2 から
ダウンストリームのフロー・ノードによって処理されます。
マップは多くの場合、メッセージの本文のみをフォーカスします。 このシナリオでは、すべてのヘッダーがマップによって変更されないままコピーされます。
すべてのヘッダーを未変更でコピーするには、Properties モデルを使用します。 単純化された Properties メッセージ・アセンブリー・モデルを選択すると、Properties フォルダー以外のすべての メッセージ・ヘッダーが順番に未変更でコピーされます。
Properties メッセージ・マップを作成したら、$source/Properties
複合エレメントを
$target/Properties
複合エレメントにマップします。
これにより、Properties フォルダーが他のすべての未変更ヘッダーと共に未変更でソースからターゲットにコピーされます。
下のイメージは、すべてのヘッダー (Properties を含む) を未変更でコピーするために構成されたサンプル・ファイル CopyAllHeaders.msgmap を示しています。
Properties モデルを使用すると、複数のヘッダーをマップすることによる複雑さに対応する必要なしに、多くの ブローカー・シナリオを使用可能にすることができます。 Properties は、MQ Series および MRM パーサーの重要なヘッダー属性の多くを抽出して、単一のパッケージ内で提供します。 MQ Series がトランスポート・レイヤーであり、MRM がメッセージ本体パーサーである場合、「すべてのヘッダーをコピー」シナリオに 加えて、Properties モデルを使用してください。 これらの属性は、以下のように分類されます。
Properties
モデル内のすべてのフィールドを設定する必要があることに注意しなければなりません。
例えば、出力メッセージ・ワイヤー・フォーマットを選択するために MessageFormat
などの単一フィールドを
設定する必要がある場合は、Properties
フォルダー内の他の値も設定またはコピーしてください。
明示的に設定されていないフィールドは出力メッセージにコピーされません。
Headers
モデルを使用すると、プロパティーに加えて、選択したヘッダーをマップすることができます。
Headers
モデルは「すべてのヘッダーをコピー」機能をサポートしないことに注意してください。
つまり、明示的にマップされていないヘッダーはターゲットの一部として作成されません。
ヘッダーは MQMD、MQ、HTTP、および JMS ヘッダーとしてカテゴリー化されます。
Headers
モデルは JMS、SOAP over JMS、および HTTP シナリオに使用してください。
Properties
モデルが必要な制御を提供していないときは、MQ シナリオに Headers
モデルを使用して
ください。
Compute
ノードを構成する必要があります。
Compute
ノードを構成する必要があります。
複数出力メッセージ・シナリオの サンプル・ファイルは、Message Map Sample Message Flows プロジェクトの multiple_output フォルダーにあります。
複数の出力メッセージを作成するための基本ルールは、複数の $target
行を暗黙的または明示的に宣言する
ことです。
複数の行を、for
行を使用して、暗黙的に宣言することができます。
for
行を使用すると、ゼロ個以上の出力メッセージが作成されます (for
行ソースとして
提供されるソース項目につき 1 つ)。
複数の出力メッセージは、「ソースおよびターゲットの追加」メニューを使用して複数の
ターゲットを明示的に追加することによっても作成できます。
そのようなターゲットのそれぞれが、1 つの出力メッセージを作成します。
ソース内の項目がそれぞれ独自に複数の出力メッセージを作成する場合、for
行と複数ターゲットを
組み合わせることも可能です。
複数のメッセージを出力するようにメッセージ・マップを構成することが有益であるようなシナリオがいくつかあります。 そのようなシナリオのいくつかを以下に示します。
このシナリオでは、単一メッセージが、さまざまな企業情報システムをターゲットとするさまざまなメッセージに変換されるか、 または単一メッセージが、個々に処理することが適している複数の繰り返しフィールドを含んでいます。
複数パーツ・メッセージは、ブローカーの複数パーツ・メッセージ 機能を使用してモデル化されたメッセージです。 これを使用すると、さまざまなワイヤー・フォーマットのメッセージや、さまざまなディクショナリーをも、単一の バッチ・メッセージに結合することができます。
ソース・メッセージには、複数の EIS システム用の個別のメッセージへの変換を必要とするデータが含まれます。 複数の出力メッセージを作成するために、個々の非繰り返しフィールドを結合する必要があります。
ソース・メッセージには、フィールド内の値 (取引先 ID など) に基づいて複数の出力メッセージに変換する必要のある 繰り返しフィールド (送り状など) が含まれます。
メッセージ・マップ・ツールを使用すると、複数の出力メッセージを簡単に生成できます。
必要なのは、複数のターゲット・メッセージ・アセンブリーを指定するか、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 です。 このサンプルは、既知のキーでソートと非常に似ています。 大きな違いは、マップが、有効なキーのリストを取得するためにデータベースに進む必要があることです。 マップにおけるステップは以下のとおりです。
$db:select
行を使用して、データベースからキーのリストを取得します。
for
行が、$db:select
からの各項目を順番に処理します。
for
行は別の for
行で、ここではソース内の各レコードを
順番に選択します。
if
行と condition
行が 2 つの for
行をフィルターに
掛けるため、キーが一致する行のみが出力メッセージを作成します。
$target
行が、データベースとソース・メッセージの両方にある固有キー値ごとに 1 つの
出力メッセージを作成します。
前出の例と同様に、これだけでは正しい出力メッセージが作成されず、total.msgmap マップをもう一度呼び出して 出力メッセージごとの合計を計算する必要があります。
サンプル・ファイルは、プロジェクト 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
ノード・フォルダー (Request1、Request2 など) から
単一出力メッセージを構成します。
プロパティーとヘッダーが ESQL MODULE
によって処理されたため、残りの作業は
LocalEnvironment.Aggregate.AgregateRequestFolderName
の内容を出力メッセージにコピーすること
だけです。
以下のサンプル・シナリオは、メッセージ・マップ内でワイルドカード、タイプ拡張および制限、置換グループ、 内容モデル・グループを使用する XML スキーマ・モデルを変換するための設計パターンを示しています。
ワイルドカード・エレメントおよび属性を処理するためのサンプル・ファイルは、Message Map Sample Message Flows プロジェクトの multipart_messages フォルダーにあります。
ワイルドカード・エレメントは、サブマップの呼び出しによって処理されます。
サブマップ内に、エレメントの名前がハードコーディングされています。
同じワイルドカードから異なるエレメント名を処理するには、if
、condition
、
および 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 フォルダーにあります。