パーサー

パーサーとは、着信メッセージの物理ビット・ストリームを解釈し、そのメッセージの内部論理表現をツリー構造で作成するプログラムです。 パーサーは、内部メッセージ・ツリー表現からの発信メッセージ用のビット・ストリームも再生成します。

入力メッセージを表すビット・ストリームが、統合ノードが処理できる内部形式に変換されると、パーサーが呼び出されます。このようなパーサーの起動を解析と呼びます。 内部形式 (論理ツリー構造) については、 論理ツリー構造で説明しています。 これがツリーとして説明されているのは、メッセージが通常は、構造内の階層になっているからです。 この構造の良い例が XML です。 パーサーがビット・ストリームを解釈する方法はパーサーに固有のものであるため、ビット・ストリームから作成される論理メッセージ・ツリーはパーサーごとに異なります。

呼び出されるパーサーは、メッセージの構造によって異なります (メッセージの構造のことをメッセージ・テンプレート といいます)。 メッセージ・テンプレート情報は、メッセージのメッセージ・ドメイン、メッセージ・モデル、メッセージ・タイプ、および物理形式から成っています。 これらの値はあわせて、メッセージが含むデータの構造を示します。

出力メッセージを表す論理ツリーがビット・ストリームに変換されるときにも、パーサーが起動されます。 パーサーによるこのアクションを書き込み といいます。 通常は、メッセージ・フローの最後に、出力ノードによって出力メッセージが生成されます。 ただし、出力ノードにさらにノードを接続して、メッセージの処理を続けることができます。

メッセージ・ドメインは、メッセージ・インスタンスの解析および書き込みで使用するパーサーを識別します。 メッセージ・テンプレートの残りの部分 (メッセージ・モデル、メッセージ・タイプ、物理形式) はオプションであり、 MRM パーサーなどのモデル駆動型パーサーによって使用されます。

メッセージの論理構造は通常、メッセージの業務内容にマップします。 例えば、顧客名、アドレス、およびアカウント番号がそれに含まれます。 その物理的特性が重要になり、ビット・ストリームの構造に影響を与えるのは、接続を介してメッセージを送信するときだけです。

統合ノードは、入力メッセージと出力メッセージが属するすべてのメッセージ・ドメインについて、パーサーへのアクセスを必要とします。 さらに、統合ノードは、入力または出力メッセージに組み込まれる、すべての識別可能なメッセージ・ヘッダーに対して、パーサーを必要とします。 パーサーは、メッセージ・フローが必要とした時点で呼び出されます。

本体パーサー

IBM® Integration Bus は、メッセージ本体パーサーを提供することにより、以下のメッセージ・ドメイン内のメッセージに対する組み込みサポートを提供します。

どの本体パーサーを使用する必要がありますか? を参照 どのような状況でどのメッセージ本体パーサーを使用するかについて説明します。

メッセージに対してどのメッセージ・ドメインを使用するかは、解析または書き込みが開始されるメッセージ・フロー内の場所で指定します。
  • メッセージ・ビット・ストリームを解析するには、通常は、メッセージを受信する入力ノードの「メッセージ・ドメイン」プロパティーを設定します。 しかし、解析操作を ESQL で開始する場合は、CREATE ステートメントの DOMAIN 節を使用します。

    作成されるメッセージ・ツリーについては、 メッセージ・ツリー構造で説明します。 その正確な形は、ノードが何をしているかによって、メッセージ・フローを進行していくにつれて変化することがあります。

    メッセージ・ツリーのルート・エレメントの最後の子エレメントは、そのツリーを作成した本体パーサーの名前にちなんで命名されます。 例えば、「メッセージ・ドメイン」プロパティーを MRM に設定した場合、ルートの最後の子エレメントは MRM という名前になります。これは、そのメッセージ・ツリーが MRM パーサーによって所有されていることを示します。

  • メッセージを書き込むために、統合ノードは所有する本文パーサーを呼び出して、メッセージ・ツリーからメッセージ・ビット・ストリームを作成します。

本体パーサーの中には、モデル駆動型のものもあります。その意味するところは、解析および書き込みの際に、メッセージ・セットからの事前定義メッセージが使用されるということです。 MRM、SOAP、DataObject、IDOC、および (オプションとしての) XMLNSC パーサーは、モデル駆動型パーサーです。 これらのパーサーを使用するには、メッセージ・セット内でメッセージをモデル化し、 IBM Integration Toolkitから統合ノードにデプロイする必要があります。

それ以外の本体パーサーはプログラマチックです。つまり、解析して書き込むメッセージは、自己定義メッセージであり、メッセージ・セットは必要ないということです。 事前定義メッセージと自己定義メッセージを参照してください。

モデル駆動型パーサーを使用する場合、メッセージ・モデルと、判断しだいでメッセージ・タイプおよびメッセージ形式を指定する必要があります。その指定によって、パーサーは、メッセージの解析または書き込みのガイダンスとなるデプロイ済みメッセージ定義を見つけることができます。

メッセージ・ビット・ストリームを解析するために、通常は、メッセージを受信する入力ノードの「メッセージ・モデル」プロパティー、「メッセージ」プロパティー、および「物理形式」プロパティーを設定します。 また、ESQL で解析操作を開始する場合は、CREATE ステートメントの SETTYPE、および FORMAT 節を使用します。 この情報は、メッセージ・ツリーの「プロパティー」フォルダーにコピーされます。

メッセージを書き込むために、統合ノードは所有する本文パーサーを呼び出して、メッセージ・ツリーからメッセージ・ビット・ストリームを作成します。 パーサーがモデル駆動型パーサーである場合は、「プロパティー」フォルダー内の MessageSet、MessageType、および MessageFormat フィールドを使用します。

メッセージ・タイプまたはメッセージ形式が必要かどうかは、メッセージ・ドメインによって決まります。

本体パーサーがモデル駆動型でない場合でも、 IBM Integration Toolkitでメッセージ・セットを作成して使用することをお勧めします。メッセージ・セットが IBM Integration Bus ランタイム環境にデプロイされていなくても、メッセージ・フロー・アプリケーションの開発が単純化されるためです。 メッセージをモデル化する理由 を参照 メッセージ・セットを作成する利点について説明します。

ヘッダー・パーサー

IBM Integration Bus は、以下のメッセージ・ヘッダーのパーサーも提供します。これらのメッセージ・ヘッダーは、アプリケーションで入力メッセージまたは出力メッセージに組み込むことができます。

すべてのヘッダー・パーサーはプログラマチックであり、解析または書き込み時にメッセージ・セットを使用しません。

ユーザー定義のパーサー

提供されているパーサーが処理しないメッセージ本体データまたはヘッダーを構文解析または書き込みするために、 IBM Integration Bus ユーザー定義パーサー・プログラミング・インターフェースを使用するユーザー定義パーサーを作成できます。

ヒント: WMQ 形式では、メッセージまたはメッセージの一部に対してパーサーは提供されません。MQFMT_IMS_VAR_STRING。この形式のデータの前には、多くの場合、MQIIH ヘッダー (形式) が付きます。MQFMT_IMS)。 IBM Integration Bus は、そのようなデータを BLOB メッセージとして扱います。 メッセージ・フロー内の CodedCharSetId またはそのようなメッセージのエンコードを変更する場合は、MQFMT_IMS_VAR_STRINGデータは変換されず、メッセージ記述子または先行ヘッダーがメッセージのその部分を正しく記述していません。 そのようなメッセージのデータを変換する必要がある場合は、MRM ドメインを使用して、メッセージ・セットを作成してメッセージの内容をモデル化するか、またはユーザー定義のパーサーを用意しなければなりません。

ルート・パーサー

ルート・パーサーとは、統合ノードによって作成された論理ツリー構造内の最初のパーサーです。 ルート・パーサーは、メッセージ・フローで使用する入力ノードによって定義されます。例えば、SOAP 入力 ノードは、 MQ 入力 ノードとは異なるルート・パーサーを使用します。 各ルート・パーサーは、論理ツリー内のプロパティー・フォルダーを処理するためにさまざまなプロパティー・パーサーを作成します。これは、さまざまな入力ノードによって、トランスポートに固有の方法でこれらの値を取得してシリアライズする必要があるためです。 ルート・パーサーはさまざまなツリーに割り当てられるため、ツリー間でエレメントをコピーする際に異なる動作が発生する可能性があります。 WebSphere MQ ルート・パーサーは、ESQL で新規ツリーを作成するときに使用されます。

パーサー・コピー

あるパーサーと別のパーサーとの間でツリーをコピーする場合、例えば ESQL を使用したために、関係するパーサーのタイプによってその動作は異なります。

同種パーサー・コピー

例えば ESQL 内にある、2 つの同一のパーサー間でツリーをコピーする場合:
SET OutputRoot.XMLNSC.myTesData.Data = InputRoot.XMLNSC.myInputData.myDarta
「同種パーサー・コピー」が実行されます。 この場合、統合ノードでは、ターゲット・パーサーによってツリーを完全に表すことができるために、確実にすべてのパーサー情報がコピーされます。 ターゲット・パーサーには、ソース・パーサーから取得されたツリーの同一コピーがあります。 このエレメントの下にあるすべてのパーサー構造が保持され、メッセージ内のすべての属性が引き続きターゲット・ツリー内の属性として表されます。

異種パーサー・コピー

例えば ESQL 内で、2 つの異なるパーサー間でツリーをコピーする場合:
SET OutputRoot.DFDL.Data.Account = InputRoot.XMLNSC.Data.Account
この場合、統合ノードは、ターゲット・パーサーによってソース・ツリーを完全に表すことができるかどうかを判別できません。 これは、一部のパーサーでは同じタイプの構造とコンテンツ情報がサポートされないために発生する動作です。 この場合、ソース・ツリーのコピーを作成するのではなく、統合ノードは論理構造を下にナビゲートして、ターゲット・パーサーを使用してエレメントを作成する必要があります。 そのため、パーサー構造は保持されず、ソース内の属性だったエレメントは、ターゲット・ツリーの属性ではないことがあります。 異種パーサー・コピーの後のターゲット・ツリーは、ターゲット・パーサーの下にある名前と値のペアのみで構成され、その他のパーサー情報は含まれません。

コピーされるソース・ツリーのルート・エレメントの子だったパーサーはどれも、出力ツリーでは保持されないことに注意してください。 シリアライズ時には、異種パーサー・コピーから作成されたツリーが、本体パーサーが出力メッセージをシリアライズできるような方法で構成されるようにする必要があります。