Product features have improved in the telemetry zone in WebSphere Message Broker and WebSphere MQ products. WebSphere Message Broker Version 6 provides a SCADA node but WebSphere Message Broker Version 7 doesn't. The new telemetry enhancement in the WebSphere MQ can now be used instead for telemetry features. The enhanced version of the MQTT 3.1 protocol is now published in the DeveloperWorks . The migration is explained in detail here in the information center.
In this blog post let's look some changes that would be needed on the WebSphere Message Broker and WebSphere MQ for this migration. A brief about the application I have: Let's say that the MQTT enabled devices or some endpoints are sending the temperature, humidity and luminosity readings to 3 different topics as MQTT messages. This data needs to be further processed in the WebSphere Message Broker.
In this example that I tried out, I used a JMSInput node, the other alternative is to use a MQInput node. Once you add the node to the flow, configure the connection factory and the JNDI properties. These can be created in the WebSphere MQ explorer under JMS Administered Objects -> JNDI Bindings -> Connection Factory. The connection factory can be created with a binding mode for improved performance.
Now setup the WebSphere MQ Telemetry channel and service using the steps provided in this document. After this is setup the devices can publish messages MQ's publish subscribe engine. Note that the WebSphere Message Broker's pub/sub engine that was getting used while using the SCADA node is not used now. For the message broker flows, only messages published on some topics might be required and not all messages that get published on different topics. So its good to subscribe to only those topics from the JMSInput Node of message broker. Let's say messages published to "zigbee/temp/+" from the devices are only required by the message broker flow. Then under the "JMS Administered objects" section in the WebSphere MQ Explorer, the destinations can be created with name "TEMP.TOPIC" and topic string "zigbee/temp/+". This implies that the JMSInput node of the WebSphere Message Broker only receives messages from this topic. This will simplify the message flow on the message broker to a large extent.
On the JMSInput node we need to provide a connection factory and a subscription topic from which the messages need to be received. The subscription topic in this case would be "TEMP.TOPIC" and the connection factory would be "cf".
Now let's look at the message format the message flow needs to handle. Previously, SCADA node used to provide a BLOB message. Now if the JMS input node is used, a JMS bytes messages will be received. If a compute node (ESQL) is used after the JMSInput node, the topic can be parsed using "InputRoot.JMSTransport.Transport_Folders.Header_Values.JMSDestination" and the message data can be parsed using "CAST(InputRoot.BLOB.BLOB AS CHAR CCSID 1208)" .
When the message flow is deployed the subscriptions will be automatically created and can be found in "Subscriptions" folder in the WebSphere MQ Explorer. A JMSOutput node can be used to publish the messages to the topics in MQ from WMB, so that an MQTT Clients can receive those messages subscribing to the topics.
Migrating from SCADA nodes of WMB to WebSphere MQ Telemetry makes the integration a lot simpler.
MQdev Blog - moving to Messaging on Developerworks!
Matching: scada X