このトピックは、ユーザー定義のパーサー実行時に、WebSphere Message Broker コンポーネント間で発生する 対話を理解するのに役立ちます。ここでは、各段階中、およびその後に発生するイベント、 および呼び出される API に関して各段階を説明します。 このトピックの概念を理解すると、パーサーの設計および開発をより効率的に行うことができます。
ユーザー定義のパーサーのライフ・サイクル中の最初の段階は、登録段階です。 登録段階の目的は、ユーザー定義のパーサーをブローカーに登録することです。 この段階は、実行グループ・プロセスの開始段階を初期化することによってトリガーされます。
パーサーは、パーサーのライフ・サイクルのインスタンス化の段階で作成されます。 入力メッセージを受け取るか、または計算ノードで出力メッセージが作成されると、 関係のあるパーサーが識別され、MQMD などのメッセージ・ヘッダーからパーサー要件が取られます。 ブローカーは開始し、ロード可能インプリメンテーション・ライブラリー (LIL)、およびパーサー・ファクトリーをロードします。 実行グループ・プロセスがパーサーのインスタンスを作成し、ブローカーは cpiCreateContext への呼び出しを行って、パーサー・オブジェクトがメッセージの適切な セクションを獲得できるようにします。
この関数が呼び出される前に、 ブローカーは、パーサー用の有効なルート・エレメントとして名前エレメントを作成しています。 ただし、このエレメントには名前が付いていません。 パーサーは、このエレメントに cpiSetElementName 関数で名前を指定しなければなりません。
次いでブローカーは、cpiParseBuffer を呼び出します。 この段階での cpiParseBuffer の目的は、必要な初期化を実行すること、およびパーサーが取る 所有権を持つメッセージ内容の長さを戻すことです。 パーサーは、解析するメッセージ・データの量を査定し、適切なバイト数を請求します。
ユーザー定義のパーサー・オブジェクトのインスタンスが作成されるときはいつでも、 コンテキスト作成インプリメンテーション関数 cpiCreateContext も メッセージ・ブローカーによって呼び出されます。 これによって、パーサーは、属性用のデータ域など、 パーサーと関連付けられたインスタンス・データを割り振ることができます。 パーサー・オブジェクトのコンテキストを削除する、cpiDeleteContext 関数も必要です。
処理段階の目的は、パーサーが解釈中のメッセージ・オブジェクト内のエレメントを操作、 変更、および参照することです。 メッセージ・フロー処理段階は、関係するメッセージのブローカーの内部モデル表現に存在しない メッセージ内でエレメントへのアクセスを必要とする、ナビゲーションなどのメッセージ処理 アクティビティー発生時に開始します。
メッセージ・フロー処理段階中、パーサーはメッセージ・ツリーへのナビゲートの試みに応答して 呼び出されます。パーサーは、cpiParseBuffer 呼び出し時に割り振られたバッファーを調査し、 必要なメッセージ・エレメントがあれば作成します。
これらの関数は、メッセージ・フィールドを指定するフィルター表現など、何らかの形式の ナビゲーションが実行された場合に、ユーザー定義のパーサーがサポートするメッセージ形式用の データを論理的に表す構文エレメント・ツリーの一部分に呼び出されます。 これは、ブローカー内の操作が構文エレメント・ツリーの構築または拡張を必要とする場合に発生します。
構文エレメント・ツリーの関連部分の解析を終えると、パーサーは cpiWriteBuffer を呼び出します。 この関数は、パーサー・オブジェクトに関連付けられているメッセージ・バッファーにある ビット・ストリームに構文エレメント・ツリーの一部分を追加します。 これによって出力メッセージが作成されます。