ユーザー定義のパーサーのライフ・サイクル

ユーザー定義のメッセージ・フロー・パーサーの存続期間には、さまざまな段階が存在します。

以下の段階があります。

このトピックでは、ユーザー定義パーサーの実行時に WebSphere® Message Broker コンポーネント間で発生する対話について説明します。各段階について、各段階の始まりとなるイベント、各段階の途中と後に発生するイベント、および呼び出される API を説明します。ここで説明されている概念を理解しておくと、パーサーの設計と開発をより効率的に行うのに役立ちます。

登録

ユーザー定義のパーサーのライフ・サイクル中の最初の段階は、登録段階です。 登録段階の目的は、ユーザー定義のパーサーをブローカーに登録することです。 この段階は、実行グループが開始したときに始まります。

インスタンス化

パーサーは、パーサーのライフ・サイクルのインスタンス化の段階で作成されます。 入力メッセージを受け取るか、またはComputeノードで出力メッセージが作成されると、 関係のあるパーサーが識別され、MQMD などのメッセージ・ヘッダーからパーサー要件が取られます。 ブローカーは開始し、ロード可能インプリメンテーション・ライブラリー (LIL)、およびパーサー・ファクトリーをロードします。cpiCreateContext 関数が呼び出される前に、ブローカーは、パーサー用の有効なルート・エレメントとして名前エレメントを作成します。 ただし、このエレメントには名前が付いていません。 パーサーは、このエレメントに cpiSetElementName 関数で名前を指定しなければなりません。 実行グループ・プロセスがパーサーのインスタンスを作成し、ブローカーは cpiCreateContext への呼び出しを行って、パーサー・オブジェクトがメッセージの適切なセクションを獲得できるようにします。

次いでブローカーは、cpiParseBuffer を呼び出します。 cpiParseBuffer は、必要な初期化を実行し、パーサーが所有権を得ているメッセージ内容の長さを戻します。パーサーは、解析するメッセージ・データの量を査定し、適切なバイト数を請求します。

ユーザー定義のパーサー・オブジェクトのインスタンスが作成されるときはいつでも、コンテキスト作成インプリメンテーション関数 cpiCreateContext もブローカーによって呼び出されます。 この呼び出しにより、パーサーは、パーサーに関連付けられたインスタンス・データを割り振ることができます。パーサー・オブジェクトのコンテキストを削除する cpiDeleteContext 関数も必要です。

処理

処理段階では、パーサーがメッセージ・オブジェクト内でエレメントの操作、変更、および参照を行います。メッセージ・フロー処理段階は、関係するメッセージのブローカーの内部モデル表現に存在しない メッセージ内でエレメントへのアクセスを必要とする、ナビゲーションなどのメッセージ処理 アクティビティー発生時に開始します。

メッセージ・フロー処理段階中、パーサーはメッセージ・ツリーへのナビゲートの試みに応答して 呼び出されます。パーサーは、cpiParseBuffer 呼び出し時に割り振られたバッファーを調査し、必要なメッセージ・エレメントがあれば作成します。

その後、パーサーは次のパーサー・インプリメンテーション関数のいずれか、またはすべてを使用して、 メッセージ・エレメント全体をナビゲートできます。
  • cpiParseFirstChild
  • cpiParseLastChild
  • cpiParsePreviousSibling
  • cpiParseNextSibling

これらの関数は、ユーザー定義パーサーでサポートされているメッセージ形式のデータを論理的に表す構文エレメント・ツリーの一部に対して (メッセージ・フィールドを指定するフィルター式などの) 何らかの形式のナビゲーションが実行される際に呼び出されます。このナビゲーションは、ブローカー内での操作で構文エレメント・ツリーを構築または拡張する必要がある場合に発生します。

最適な構文エレメント・ツリーのナビゲート方法を決定する際には、以下の点を考慮してください。
  • 構文エレメントには、親、兄弟、および最初と最後の子への 5 つのポインターがあるため、使用できるナビゲーションのセットは限定されています。
  • これらすべてのナビゲーションの実行に、同じ内部クラスが使用されます。
  • パーサーはナビゲーションを制御しません。 ナビゲートの方向、およびナビゲーション・パーサー・インプリメンテーション関数が呼び出される順序は、ESQL またはユーザー定義ノードで決定されます。ユーザー定義パーサーは、方向や順序を制御することはできず、選択されたナビゲーション・スキーム (例えば、右から左へ構文解析するか、左から右へ構文解析するか) に忠実に応じる必要があります。
  • ユーザー定義パーサーを作成する際には、parseNextItem 関数にパーサー・コードを置いてください。この関数は、構文エレメント・ツリーのエレメントを一度に 1 つずつ構築し、 名前、値、および完全なフラグを適切に設定することになっています。 この関数のインプリメント方法は、解析されるビット・ストリームの性質に依存します。提供されているサンプル・パーサーでは、この振る舞いを実際の例で見ることができます。

構文エレメント・ツリーの関連部分の解析を終えると、パーサーは cpiWriteBuffer を呼び出します。 この関数は、パーサー・オブジェクトに関連付けられているメッセージ・バッファーのビット・ストリームに自身の構文エレメント・ツリーの一部を付加して、出力メッセージを作成します。

破棄

破棄段階は、ユーザー定義のパーサーのライフ・サイクルの最終段階です。 パーサーが構文エレメント・ツリーの一部分をビット・ストリームに書き込み、出力メッセージを 作成すると、ブローカーがパーサーが使用するために作成したシステム・リソースをリリースする 必要があります。

破棄段階は、mqsistop コマンドを使用して実行プロセスが停止させられるときから始まります。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
最終更新 : 2009-02-20 12:44:32

as01413_