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