各メッセージ定義ファイルは、メッセージの論理構造と、 伝送中のメッセージ・ビット・ストリームの厳密な形状を表す物理フォーマットとの両方を記述します。 MRM ドメインを使用する場合、 メッセージ・ビット・ストリームを正確に解析する方法をパーサーに通知するときは、 物理フォーマット情報を提供する必要があります。
メッセージをデータのパケットと見なして、ある場所から別の場所に送信することができます。 メッセージの送信側と受信側は、 メッセージの構造とそのメッセージ内の各フィールドの意味について一致します。 これは、プラットフォームとプロトコルとが独立した論理構造です。
送信側と受信側は、 メッセージの物理表現 (つまり、 回線上でデータが物理的にどのように配置されるか) に関しても一致します。 例えば、個々の銀行口座のデビット機能についての情報を運ぶメッセージを定義する場合、 別の物理フォーマット (XML や、COBOL コピーブックのような固定構造など) で表すことができます。 どちらの場合でも、意味とデータは同じです。 物理レイアウトだけが変更されています。
MRM ドメインを使用している場合、 指定された物理フォーマットを使用してさまざまな物理表現をモデル化できます。
以下の例では、 非常に単純な論理メッセージにさまざまな物理表現を含める方法を示します。
論理モデルでは、 メッセージの構造および順序を定義します。 以下の例では、 3 つのフィールドが単純な整数で、 C の前に B、その前に A となっています。
int A; int B; int C;
<Msg><A>xxxxxxxx</A><B>xxxxxxxx</B><C>xxxxxxxx</C></Msg>この xxxxxxxx は、 ストリングとして表現されている整数の値です (XML はストリングした扱えません)。 以下は、別の表現です。
<Msg A="xxxxxxxx" B="xxxxxxxx" C="xxxxxxxx"/>ここでは、 整数の値が XML エレメントではなく XML 属性として保管されています。 メッセージ内の各フィールドの正確な XML レンダリングを、 XML プロパティーとして提供します。
{A_tag:xxxxxxxx;B_tag:xxxxxxxx;C_tag:xxxxxxxx}別方法は、 以下のような、 終了を示す区切り文字を指定するだけで済むような順序で並べられているデータによって行います。
[xxxxxxxx;xxxxxxxx;xxxxxxxx]TDS プロパティーとして正確な識別制度を提供します。
この例から、論理モデルは変更されないということが分かります。 モデル化を行うために選択した物理表現に関係なく、 これは MRM ドメインによって提供されている物理フォーマット・サポートを使用しており、一定です。 MRM パーサーでは、 定義したワイヤー形式層に基づいて、 入力の物理表現から任意の数の出力の物理表現にメッセージを変換できます。
メッセージ・セットの作成が済んでいれば、 物理フォーマットを作成できます。 これは、 メッセージ・セット・エディターを使用して行います。 次に the messageSet.mset ファイルを保管したときに、 そのメッセージ・セット内のすべてのメッセージ定義ファイル内のすべてのオブジェクトに、 新しい物理フォーマットがすべて追加されます。
次にメッセージ定義ファイル内のオブジェクトを編集したときに、 「プロパティー」タブ内のプロパティー階層ペインに物理フォーマットが表示されます。 オブジェクトの物理フォーマットをクリックすると、 そのオブジェクトのその物理フォーマットに関する情報を入力できる、 プロパティー・シートが表示されます。
すべてのオブジェクトに、すべての物理フォーマットのプロパティーがあるわけではないことに注意してください。 以下に例を示します。
これは、 それぞれの物理フォーマットのさまざまな性質によるものであり、 それらの違いについては、 それぞれの物理フォーマットのセクションで詳しく説明します。
特定のメッセージ・セット内に作成できる物理フォーマットの数に制限はありません。 ただし、 同じメッセージ・セット内で異なる種類の物理フォーマットを混合させる場合、 適用される推奨事項がいくつかあります。
物理フォーマットは、 必要なくなれば削除できます。