提供されている集約フローをさまざまな要件に合わせて変更する方法について説明します。 また、このサンプルは、この製品のバージョン 5 およびそれ以前のバージョンから既存の集約フローを移植する場合にも役立ちます。
AggregateControl ノードの Control ターミナルは、特定の集約操作の状況およびトラッキング情報の入った制御メッセージを伝搬するために使用します。 Control ターミナルの接続では、以下のオプションを使用できます。
いずれかのオプションを選ぶ際には、以下の要素を考慮する必要があります。
オプション 3 では、パフォーマンスや動作に影響しない場合もあり得ます。 たとえば、ファンアウトされた要求メッセージに対する処理が非常に高速に実行される一方で、Compute ノードの処理が原因で AggregateControl ノードの Control ターミナルからのメッセージの配信が遅れる場合などです。 このシナリオは AggregateReply ノードの処理の問題の原因となる可能性があります。
しかし、そうではあっても、AggregateReply ノードで「不明なメッセージ・タイムアウト」をゼロに設定しないでおけば、集約は正しく完了します。 この場合、不明の応答は保管されて、タイムアウト期間の後に再処理され、それらはこの時点で制御状態情報に統合されます。 「不明なメッセージ・タイムアウト」の満了が原因で生じた遅延の後であっても、集約操作は正しく完了します。
「不明なメッセージ・タイムアウト」をゼロに設定した場合、制御メッセージより先に着信する応答は、AggregateReply ノードの Unknown ターミナルに直接伝搬されます (残りの集約データとは統合されません)。
オプション 3 は、以下の省略図のようになります。
AddMqmd Compute ノードには以下の例のような ESQL が含まれ、制御メッセージをキューに書き込むことができます。
CREATE COMPUTE MODULE AggregationOut_AddMqmd
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET OutputRoot = InputRoot;
CREATE NEXTSIBLING OF OutputRoot.Properties DOMAIN 'MQMD';
SET OutputRoot.MQMD.Version = MQMD_CURRENT_VERSION;
RETURN TRUE;
END;
END MODULE;
制御情報が AggregateControl ノードに保管されるより前に、応答メッセージがファンイン・フローによって受け取られる可能性を回避するには、ファンアウト・フローの MQInput ノードの「トランザクション・モード」を「はい」に設定する必要があります。
ファンアウト・フローがトランザクション制御下で実行されていない場合、 MQOutput ノードが集約ファンアウト要求メッセージを書き出すたび、そのメッセージは呼び出されるアプリケーションによって即時に処理を受けることになります。 このアプリケーションの対応によっては、制御情報が保管されるより先に、AggregateReply ノードが応答を受け取ることになります。
AggregateControl ノードの Control ターミナルが Compute ノードと MQOutput ノードに接続されている場合、つまりファンイン・フローとファンアウト・フローが別々のメッセージ・フローに置かれている場合、同じ問題が発生する可能性があります。 ファンアウトがトランザクション下で実行されるとしても、トランザクションの及ぶ範囲は MQOutput ノードによるメッセージの書き込みまでなので、ファンイン・フローの Control 分岐の処理中に、応答は依然として不明のまま処理される可能性があります。このシナリオについては、上記のセクションのオプション 3 で説明しています。
どちらの場合も、AggregateReply ノードで「不明なメッセージ・タイムアウト」をゼロに設定しないでおけば、集約は正しく完了します。 不明の応答は保管されて、指定された秒数の後に再処理され、それらはこの時点で制御状態情報に統合されます。 「不明なメッセージ・タイムアウト」の満了が原因で生じた遅延の後であっても、集約操作は正しく完了します。 「不明なメッセージ・タイムアウト」をゼロに設定した場合、制御メッセージより先に着信する応答は、AggregateReply ノードの Unknown ターミナルに直接伝搬されます (残りの集約データとは統合されません)。
このセクションと前のセクションの両方を要約すると、Aggregation ファンアウト・フローの最も効率的な設計では必ず次のようになります。
最も効率的な設計オプションを採用すると、前述のようなタイプのタイムアウト問題は起きません。 ただし、これらのオプションを使用できない場合でも、AggregateReply ノード上で「不明なメッセージ・タイムアウト」パラメーターをゼロ以外の値に設定すれば、確実に集約操作を正常に完了させることができます。
AggregateReply ノードには、Out、Unknown、および Timeout の 3 つの非エラー出力ターミナルがあります。 トランザクションのコンテキストに特別な注意を払いつつ、これらの異なるターミナルからメッセージが送信される時および理由を理解することは重要です。 トランザクションのコンテキストは、MQInput ノードによって所有されるか (これは着信メッセージによって AggregateReply ノードからの出力がトリガーされる場合に生じます)、あるいは AggregateReply ノード自身によって所有される可能性があります。
トランザクション・コンテキストが AggregateReply ノードによって所有される場合、その意味体系は通常どおりですが、トランザクションの制御の中心となるのは AggregateReply ノードであって、MQInput ノードではありません。 これはつまり、メッセージ・フローの後の部分でエラーが生じると、MQInput ノードではなく AggregateReply ノードがロールバックし、このノードの Catch ターミナルにメッセージが伝搬されるということを意味します。 AggregateReply ノード自身のトランザクションのコンテキストの中で AggregateReply ノードから伝搬されるメッセージは、MQInput ノードから直接提供されるわけではありません。 AggregateReply ノードがそのフロー呼び出しの入力ノードとなります。
AggregateReply ノードのトランザクションの動作は、「トランザクション・モード」構成パラメーターによって制御されます。 この設定と MQInput ノードの設定は必ず同じものにして、AggregateReply ノードからの出力がすべて同じレベルのトランザクションの制御の下に置かれるようにする必要があります。
MQInput ノードのトランザクションの制御の下にあるのは、次の状態です。
AggregateReply ノードのトランザクションの制御の下にあるのは、次の状態です。
AggregateReply ノードには、In および Control の 2 つの入力ターミナルがあります。
Control ターミナルがオプショナルであることに留意してこれらのターミナルの両方を使用する場合、データを AggregateReply ノードに提供する最も効率的な方法は、ファンイン・フローのための単一の MQInput ノードを設け、その後に Filter ノードを続けることです。
Filter ノードは、必要に応じて、AggregateReply ノードの In または Control ターミナルに着信メッセージを経路指定するために使用します。
メッセージ・フロー内で 2 つの MQInput ノードを (1 つを In ターミナルに、1 つを Control ターミナルに) 使用する代わりに、この方法を使用してください。
ファンイン・フローは、以下の図のようでなければなりません。
Filter ノードは、以下の例のような ESQL モジュールを必要とします。
これにより、メッセージは AggregateReply ノードの適切なターミナルに確実に経路指定されます。
CREATE FILTER MODULE FanIn_Filter
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
IF Root.XMLNSC.ComIbmAggregateControlNode IS NULL THEN
RETURN TRUE; -- wired to In
ELSE
RETURN FALSE; -- wired to Control
END IF;
END;
END MODULE;
単一の MQInput ノードを使用すべき理由は、2 つの MQInput ノードの間でどのように追加のスレッド (追加のインスタンスを使用することにより使用可能になる) を分配すべきかを指定できないからです。AggregateReply ノードの In ターミナルの方がトラフィックがより大きくなる傾向があるので、 そちらの入力ノードで実行させるスレッドをより多くするのが効率的ですが、このシナリオは構成できません。 したがって、ノードがスレッド不足に陥って、応答メッセージが滞り、集約のメカニズムの速度が低下する恐れがあります。
この状態が当てはまるのは、AggregateControl ノードの Control ターミナルがキューへの出力に接続されている場合だけです。 Control ターミナルを接続しなければ、これらの問題は回避できます。
上記の解決方法を実施できない場合、制御メッセージを読み取る MQInput ノードを、単一スレッドで実行するように強制することができます。
ただし、この構成の結果として、最初の MQInput ノードのパフォーマンスは大幅に制限されます。