WebSphere Message Brokers
File: ac23510_
Writer: Kate Hostler

Task topic

This build: July 31, 2007 21:19:32

Designing Telemetry applications

When you create a message flow to receive messages from Telemetry clients, you must include at least one SCADAInput node. Configure the node's properties to define the port on which it listens for new messages. If your message flow sends messages to Telemetry clients, you must include either a Publication node, or a SCADAOutput node (the Publication node includes an embedded SCADAOutput node).

You must deploy message flows that contain SCADAInput and SCADAOutput nodes to a single execution group within a broker. If you send messages to Telemetry clients through a Publication node, the message flow that contains that node must also be in the same execution group as a SCADAInput node, even if you do not have a message flow that receives messages from Telemetry clients. This is because the properties of the SCADAInput node identify the TCP/IP port that is used for communication with the clients, and the characteristics of how messages are handled.

Starting and stopping listeners

Start and stop a WebSphere MQ Telemetry Transport listener using a publish message with the topic $SYS/SCADA/MQIsdpListener/<port_number>. Set the Payload part of the message set to ON or OFF. Replace <port_number> with the single port that you want to start or stop, or with all to start or stop all ports on the system that are designated as SCADA ports.

Improving message handling

The number of messages that are handled by a message flow depends both on message throughput and on response times. Review the guidance in Optimizing message flow response times and Optimizing message flow throughput. In addition, you must consider the Quality of Service that you choose for messages received from, or published to, Telemetry clients. This is described in Choosing Quality of Service.

Choosing Quality of Service

Quality of Service determines the reliability of message delivery. Review the circumstances of the messages that are processed; in some situations, message loss might be acceptable. For other scenarios, message delivery might need to be guaranteed. The Quality of Service options, QoS0, QoS1, and QoS2, are described in WebSphere MQ Telemetry Transport Quality of Service levels and flows.

If you choose to guarantee message delivery, the broker must take additional actions to preserve the message until it is certain that it has been delivered. This affects broker and client performance, so you must balance the need for speed of message processing with the need to ensure message delivery.

If you choose QoS1 or QoS2, which indicates the message must be delivered at least, or only, once, the broker and client must provide a certain level of acknowledgment. The broker must store the message so that it can resend it if the appropriate acknowledgments are not received.

The broker stores messages in its database. This can affect message handling if the broker is unable to complete input to or output from the database when required; the broker might stop processing messages if this happens. If your broker database is DB2, turn off DB2 next key locking to avoid these deadlock problems. Issue the following command in a DB2 command window to make this change:

db2set DB2_RR_TO_RS=YES_OVERRIDE_RI

Restart the DB2 database manager for this change to take effect.

If you choose QoS0, message delivery is not guaranteed. The broker does not store the messages.

Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:19:32

ac23510_ This topic's URL is: