このトピック内の情報は、出力ノードとメッセージ処理ノードのどちらにも適用されます。 これら 2 つのノード・タイプは一緒に考慮することができます。 なぜなら、メッセージ処理ノードは一般に、メッセージを処理するために使用され、出力ノードはビット・ストリームの形式で出力を提供するために使用されますが、そのいずれかの機能を実行するために、どちらのノード・タイプでも使用できるからです。
ユーザー定義のメッセージ処理ノードは、ノードを含む LIL がオペレーティング・システムによってロードされ、初期化されるときにブローカーに登録されます。
ブローカーは bipGetMessageflowNodeFactory を呼び出して、LIL の機能、および LIL の呼び出し方を設定します。
次に bipGetMessageflowNodeFactory 関数は、cniCreateNodeFactory 関数を呼び出します。これは、LIL によってサポートされるすべてのノードに対して、ファクトリー名およびグループ名を戻します。
LIL は次にユーティリティー関数 cniDefineNodeClass を呼び出して、各ノードの名前と、インプリメンテーション関数の関数ポインターの仮想関数表の両方を渡します。
インスタンス化の段階で、ユーザー定義のメッセージ処理ノードのインスタンスが作成されます。 この段階が始まるのは、ブローカーがメッセージ・フローを作成して、そのメッセージ・フロー内のユーザー定義ノードの各インスタンス化ごとに cniCreateNodeContext 関数を呼び出すときです。 cniCreateNodeContext 関数は、そのノード・タイプの cniDefineNodeClass に渡される CNI_VFT 構造の iFpCreateNodeContext フィールドに指定される関数です。 この関数は、そのノードに必要なリソース (メモリーを含む) を割り振り、ユーザー定義ノードのインスタンス化にあたって構成済みの属性の値を保持できるようにします。
cniCreateContext 内でユーザー定義拡張機能は cniCreateInputTerminal および cniCreateOutputTerminal という 2 つの関数を呼び出して、メッセージ処理ノードが持つ入力ターミナルと出力ターミナルを設定します。
ユーザー定義のメッセージ処理ノードのライフ・サイクルの処理段階で、その入力メッセージの処理が行われると、メッセージは何らかの方法で変換されます。
ブローカーがキューからメッセージを取り出し、 そのメッセージがユーザー定義ノードの入力ターミナルに到着すると、 ブローカーはインプリメンテーション関数 cniEvaluate を呼び出します。 この関数は、メッセージの処理方法を決定するために使用されます。
ユーザー定義のメッセージ処理ノードで一連のノード・ユーティリティー関数を使用して、一連のメッセージ処理関数、例えば、メッセージ・データへのアクセス、ESQL へのアクセス、メッセージ・オブジェクトの変換、メッセージの伝搬などを実行することができます。 メッセージを処理するために使用しようとしているノード・ユーティリティー関数を、cniEvaluate 関数に組み込む必要があります。
このインターフェースでは、メッセージのプロパティー・サブツリーが自動的に生成されるわけではありません。 メッセージにプロパティー・サブツリーを含めることは要件ではありませんが、入力ノードに関係なく、 プロパティー・フォルダーを作成して一貫したメッセージ・ツリー構造を用意すると便利かもしれません。 メッセージにプロパティー・サブツリーを作成する場合で、 ユーザー定義の入力ノードを使用している場合、 この作業は自分で行う必要があります。
ユーザー定義のメッセージ処理ノードによるメッセージの処理が完了したら、 使用されていたシステム・リソースをリリースするため、 また、メッセージが構成されて処理されたときに獲得されたコンテキストなどの、 ノード・インスタンスに固有のデータ領域をリリースするために、 ノードを破棄する必要があります。
ブローカーが cniDeleteNodeContext 関数を呼び出すとき、 ユーザー定義のメッセージ処理ノードのインスタンスは破棄されます。