This example message flow includes two SCADAInput nodes configured to listen on different TCP/IP ports. When a message is received without error, the input node propagates it to a Compute node that manipulates the input message content and generates a number of output messages. The Compute node propagates the output messages to a Publication node which publishes them to registered subscribers that use the WebSphere MQ protocol. Any errors in the flow are propagated to an MQOutput node, which records the error messages on a queue to be processed later.
The Telemetry clients generate events, for example to indicate a change of state, or to confirm that they are still active. The clients are programmed to batch up events and send them to the broker every 15 minutes. The message flow is designed to extract individual event messages from the batch message and publish these.
The Compute node has been configured with ESQL that splits the batched input message into individual event messages. A WHILE loop iterates over each message in the batch. The MQMD is copied from the input message to each output message. Relevant fields are copied from the input tree to the output tree. Each output message is a JMSText message which is built by setting the User properties in the usr folder within the MQRFH2 header. Each message is passed to the Publication node by a PROPAGATE statement.
Here is an example input batch message that contains two events:
<?xml version="1.0" encoding="UTF-8"?> <!-- edited by Mary Bright --> <events d_tstamp="20040417103118"> <StateChange topic="LCUnit/12345/StateChange" d_tstamp="20040417104439" i_state="1" i_old_state="0"> <![CDATA[Changing state from 'Starting' to 'Payload' because 'The startup routine is complete']]> </StateChange> <Heartbeat topic="LCUnit/12345/Heartbeat" d_tstamp="20040417105126" i_state="1"> <d_tstamp>20040417104948</d_tstamp> <i_state>1</i_state> </Heartbeat> </events>
The ESQL module that processes messages of this format is shown below:
CREATE COMPUTE MODULE messageflow_Compute CREATE FUNCTION Main() RETURNS BOOLEAN BEGIN DECLARE BatchTime CHAR; SET BatchTime = InputRoot.XML.events.d_tstamp; DECLARE Count INTEGER CARDINALITY(InputRoot.XML.events.*[]); DECLARE I INTEGER 2; WHILE I <= Count DO SET OutputRoot.Properties.MessageDomain = 'XML'; SET OutputRoot.XML = NULL; SET OutputRoot.MQMD = InputRoot.MQMD; SET OutputRoot.MQRFH2.CodedCharSetId = 1208; SET OutputRoot.MQRFH2.(MQRFH2.Field)Format = 'MQSTR '; SET OutputRoot.MQRFH2.(MQRFH2.Field)NameValueCCSID = 1208; SET OutputRoot.MQRFH2.psc.Topic = InputRoot.XML.events.*[I].topic; SET OutputRoot.MQRFH2.usr.*[] = InputRoot.XML.events.*[I].(XML.Attribute)*[]; SET OutputRoot.MQRFH2.usr.b_time = BatchTime; SET OutputRoot.XML.Body.Text = InputRoot.XML.events.*[I].(XML.CDataSection)*' SET I = I + 1; PROPAGATE; END WHILE; RETURN FALSE; END; END MODULE;
The message flow has two input nodes to increase the message handling capability. You can use any number of input nodes. You can also change the message flow property Additional Instances to increase the number of processes that service the message flow. If you have many hundreds of clients, you might find that you have to handle a high message load on two or more brokers. Use one or more of these techniques to find an acceptable level of message processing.
This example shows only one way in which Telemetry client messages can be handled. Change this message flow, or create a new one, to meet your own Telemetry requirements.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac23520_ |