Telemetry クライアントからメッセージを受信するメッセージ・フローを作成する場合は、少なくとも 1 つの SCADAInput ノードを組み込む必要があります。このプロパティーを構成して、新しいメッセージを listen するポートを定義します。メッセージ・フローがメッセージを Telemetry クライアントに送信する場合は、Publication ノードまたは SCADAOutput ノード (Publication ノードには、組み込み SCADAOutputノードが含まれている) を組み込む必要があります。
SCADAInput および SCADAOutput ノードを含むメッセージ・フローを、ブローカー内の単一実行グループにデプロイする必要があります。Publication ノードを介してメッセージを Telemetry クライアントに送信する場合は、Telemetry クライアントからメッセージを受信するメッセージ・フローがない場合でも、このノードを含むメッセージ・フローも、SCADAInput ノードと同じ実行グループに存在している必要があります。 これは、SCADAInput ノードのプロパティーが、クライアントとの通信に使用される TCP/IP ポートを識別するためであり、メッセージの処理方法の特性も関係しています。
トピック $SYS/SCADA/MQIsdpListener/<port_number> でパブリッシュ・メッセージを使用して、WebSphere MQ Telemetry Transportリスナーを開始および停止します。 メッセージ・セットのペイロード部分を「オン」または「オフ」にします。<port_number> を、開始または停止する単一ポートで置き換えるか、all で置き換えて、SCADA ポートとして指定されているシステム上のすべてのポートを開始または停止します。
メッセージ・フローによって処理されるメッセージの数は、メッセージ・スループットおよび応答時間によって異なります。メッセージ・フロー応答時間の最適化およびメッセージ・フロー・スループットの最適化の指針を検討してください。 さらに、Telemetry クライアントから受信されるメッセージ、または Telemetry クライアントにパブリッシュされるメッセージに選択するサービス品質を考慮する必要があります。これについては、サービス品質の選択で説明しています。
サービス品質によって、メッセージ配信の信頼性が決まります。 処理されるメッセージの環境を検討してください。場合によっては、メッセージ損失が許容されることもあります。他のシナリオでは、メッセージの配信が保証されなければならない場合もあります。サービス品質のオプション (QoS0、QoS1、および QoS2) については、WebSphere MQ Telemetry Transport サービス品質レベルおよびフローで説明されています。
メッセージ配信を保証する場合は、ブローカーは追加アクションを実行して、メッセージが確実に配信されるまでメッセージを保持する必要があります。これはブローカーおよびクライアントのパフォーマンスに影響を与えるため、メッセージ処理の速度とメッセージを確実に配信する必要性との間で平衡を取る必要があります。
QoS1 または QoS2 を選択する場合 (メッセージが「最低 1 回」または「1 回のみ」配信されることを示す)、ブローカーおよびクライアントは、特定レベルの確認通知を提供する必要があります。 適切な確認通知が受信されなかった場合にメッセージを再送できるよう、ブローカーはメッセージを保管する必要があります。
ブローカーは、メッセージをデータベースに保管します。これは、ブローカーが、要求時にデータベースに対する入力または出力を完了できなかった場合に、メッセージ処理に影響を与える可能性があります。このことが生じると、ブローカーはメッセージの処理を停止することがあります。ブローカー・データベースが DB2 の場合、DB2 の次のキーロック機能をオフにして、このようなデッドロック問題を回避してください。これを変更するには、DB2 コマンド・ウィンドウで次のコマンドを発行します。
db2set DB2_RR_TO_RS=YES
DB2 データベース・マネージャーを再始動して、この変更を有効にします。
QoS0 を選択すると、メッセージの配信は保証されません。ブローカーは、メッセージを保管しません。