C ユーザー定義メッセージ処理ノードのライフ・サイクル

このトピックは、C プログラミング言語に関する、ユーザー定義のメッセージ処理ノードの存続期間におけるさまざまな段階を説明します。 作成および破棄されるオブジェクト、および以下の段階で呼び出されるインプリメンテーション関数やクラスについて説明します。

このトピック内の情報は、出力ノードとメッセージ処理ノードのどちらにも適用されます。 これら 2 つのノード・タイプは一緒に考慮することができます。 なぜなら、メッセージ処理ノードは一般に、メッセージを処理するために使用され、出力ノードはビット・ストリームの形式で出力を提供するために使用されますが、そのいずれかの機能を実行するために、どちらのノード・タイプでも使用できるからです。

登録

ユーザー定義のメッセージ処理ノードは、ノードを含む LIL がオペレーティング・システムによってロードされ、初期化されるときにブローカーに登録されます。

ブローカーは bipGetMessageflowNodeFactory を呼び出して、LIL の機能、および LIL の呼び出し方を設定します。

次に bipGetMessageflowNodeFactory 関数は、cniCreateNodeFactory 関数を呼び出します。これは、LIL によってサポートされるすべてのノードに対して、ファクトリー名およびグループ名を戻します。

LIL は次にユーティリティー関数 cniDefineNodeClass を呼び出して、各ノードの名前と、インプリメンテーション関数の関数ポインターの仮想関数表の両方を渡します。

インスタンス化

インスタンス化の段階で、ユーザー定義のメッセージ処理ノードのインスタンスが作成されます。 この段階が始まるのは、ブローカーがメッセージ・フローを作成して、そのメッセージ・フロー内のユーザー定義ノードの各インスタンス化ごとに cniCreateNodeContext 関数を呼び出すときです。 cniCreateNodeContext 関数は、そのノード・タイプの cniDefineNodeClass に渡される CNI_VFT 構造の iFpCreateNodeContext フィールドに指定される関数です。 この関数は、そのノードに必要なリソース (メモリーを含む) を割り振り、ユーザー定義ノードのインスタンス化にあたって構成済みの属性の値を保持できるようにします。

ブローカーは、以下の場合にノード・インスタンスを作成し、cniCreateNodeContext を呼び出します。
  • 以下の状況でメッセージ・フローが作成された場合。
    • ブローカーが開始するとき (ユーザーが mqsistart を実行)。ブローカーが開始すると、以前にデプロイされたあらゆるメッセージ・フローが再作成されます。
    • 実行グループが再ロードされるとき (ユーザーが mqsireload を実行)。実行グループが再ロードされると、以前にデプロイされたあらゆるメッセージ・フローが再作成されます。
    • 実行グループ内で重大エラーが発生した結果、実行グループが再始動するとき。
  • メッセージ・フローが再デプロイされた場合。 メッセージ・フローが変更を加えられて再デプロイされると、ブローカーは、フロー内のすべてのノードを削除した後、ノードを新しい構成で再作成することにより、再デプロイを処理します。
注: 実行グループを開始するとき、メッセージ・フローは作成されません。 実行グループを停止してもすべてのフローが停止するだけで、フローを削除したり、プロセスが停止したりすることはありません。 実行グループを再始動すると、メッセージ・フローが開始しますが、メッセージ・フローが再作成されることはありません。

cniCreateContext 内でユーザー定義拡張機能は cniCreateInputTerminal および cniCreateOutputTerminal という 2 つの関数を呼び出して、メッセージ処理ノードが持つ入力ターミナルと出力ターミナルを設定します。

処理

ユーザー定義のメッセージ処理ノードのライフ・サイクルの処理段階で、その入力メッセージの処理が行われると、メッセージは何らかの方法で変換されます。

ブローカーがキューからメッセージを取り出し、 そのメッセージがユーザー定義ノードの入力ターミナルに到着すると、 ブローカーはインプリメンテーション関数 cniEvaluate を呼び出します。 この関数は、メッセージの処理方法を決定するために使用されます。

ユーザー定義のメッセージ処理ノードで一連のノード・ユーティリティー関数を使用して、一連のメッセージ処理関数、例えば、メッセージ・データへのアクセス、ESQL へのアクセス、メッセージ・オブジェクトの変換、メッセージの伝搬などを実行することができます。 メッセージを処理するために使用しようとしているノード・ユーティリティー関数を、cniEvaluate 関数に組み込む必要があります。

このインターフェースでは、メッセージのプロパティー・サブツリーが自動的に生成されるわけではありません。 メッセージにプロパティー・サブツリーを含めることは要件ではありませんが、入力ノードに関係なく、 プロパティー・フォルダーを作成して一貫したメッセージ・ツリー構造を用意すると便利かもしれません。 メッセージにプロパティー・サブツリーを作成する場合で、 ユーザー定義の入力ノードを使用している場合、 この作業は自分で行う必要があります。

破棄

ユーザー定義のメッセージ処理ノードによるメッセージの処理が完了したら、 使用されていたシステム・リソースをリリースするため、 また、メッセージが構成されて処理されたときに獲得されたコンテキストなどの、 ノード・インスタンスに固有のデータ領域をリリースするために、 ノードを破棄する必要があります。

ブローカーが cniDeleteNodeContext 関数を呼び出すとき、 ユーザー定義のメッセージ処理ノードのインスタンスは破棄されます。

ノードのインスタンスが削除される際に、ブローカーは cniDeleteNodeContext を呼び出します。 以下のイベントが発生すると、ノードが削除される場合があります。
  • 以下の状況における、実行グループ・プロセスの制御された終了。
    • ブローカーが停止するとき (ユーザーが mqsistop を実行)。
    • 実行グループが再ロードされるとき (ユーザーが mqsireload を実行)。
    • 実行グループ内で重大エラーが発生した結果、実行グループが再始動するとき。
    注: これには、実行グループの停止は含まれません。実行グループを停止してもすべてのフローが停止するだけで、フローを削除したり、プロセスが停止したりすることはありません。
  • メッセージ・フローが削除された場合。 例えば、メッセージ・フローがツールのブローカー管理パースペクティブから削除された場合。
  • メッセージ・フローが再デプロイされた場合。 メッセージ・フローが変更を加えられて再デプロイされると、ブローカーは、フロー内のすべてのノードを削除した後、ノードを新しい構成で再作成することにより、再デプロイを処理します。
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
as01394_