Did You Know? How to Setup Chained Messages in OmniServer

In a nutshell, OmniServer's purpose is to retrieve information from devices that use ‘non-standard’ protocols to communicate such as weight scales, barcode readers, and printers.

Sometimes with some protocols, simply sending one message to a device, or doing nothing but simply transferring data to a client isn't enough. There are some more complex protocols where you will need to send a series of messages to the instrument, or respond to an event coming in from the device or to handle a sequence of handshaking messages. This is where "chained messages" come into play in an OmniServer protocol.

In this second post of a follow-up to our "OmniServer Did You Know?" blog series, we will cover how to chain multiple OmniServer command/request messages together in a protocol to flexibly handle such complex protocols.

Why might you need to chain messages together for a protocol?

With certain device communication protocols, it's not uncommon for devices to require a series of handshaking or initialization procedures to be performed before any meaningful communications can be attempted.  An example of such a situation is with modem communications, which requires both an initialization string and a phone number input prior to dialing.

Also, sometimes, a device might require a sequence of commands to be sent in a specific order, with a response in between each command, such as a recipe that needs inputs from the control system in the proper sequence, for example.

Or, perhaps, a device has some number of defined error situations that result in an error message being sent to OmniServer that requires a specific response to proceed with normal communications.  Using the "Action" setting in an error message of an OmniServer protocol, combined with the "On Success" and "On Failure" chain settings of command/request messages, OmniServer can act upon that error from the device and take appropriate action (such as sending an acknowledgement or re-sending the original message).

If you missed our original blog series "OmniServer Did You Know?" or the first post in this revisit, get caught up here!

How Can I Do This?

Chained messages can be found in three different sections of an OmniServer protocol:

1. Chaining in Command/Request Messages

   You can chain host messages via the Chains and Triggers tab on any Command/Request (Host) message.
   
   The On Success setting tells OmniServer to process the specified message next if the Response part of the original Command/Request message was successfully completed.
   
   The On Failure setting, on the other hand, processes the selected Command/Request message when the Response part of the original Command/Request message does not complete or fails in its parsing of the data stream for some reason.
   
   
   
   In a sense, you can think of this mechanism as a type of simplified "If-Then" logic; if the message is successful, then process this message.  Or, if the message is not successful, then process this other message.

2. Chaining in Unsolicited Messages

   You can also chain to a particular Command/Request message when a Unsolicited message is activated. This occurs by setting the "Trigger Message" for the unsolicited message. Then, whenever the Unsolicited message is activated, the Trigger Message will be processed after any matching response to that Unsolicited message.
   
   

3. Chaining in Error Messages

   Finally, you can use an Error Message to control how OmniServer treats the success or failure of the Command/Request message being processed at the time the error message was activated/received. This behavior is defined using the "Action" setting.
   
   There are four possible values:
   
   
   
   1. Accept: Accept the message and turn control over to the On Success chain of the host message.
   2. Retry: Retry the message, using the normal retry procedures.
   3. Retry Forever: Retry the Command/Request message that was just sent indefinitely. Be careful with this option, since it can create an endless loop.
   4. Fail: Reject the Command/Request message that was just sent and turn control over to the On Failure chain of that Command/Request message.
      
      

Are there any limitations to chaining messages?

Not particularly, but it is important to realize that it's possible to create an endless loop if you configure an "On Failure" or "On Success" chain to the same Command/Request message, or to reiterate from early, set an Error Message action to "Retry Forever", when there is no chance that the message will ever succeed - such a loop would require a restart of the OmniServer poller to reset communications.

Where can I get more information?

Do you have a protocol that you’re not really sure how to implement?  As always, we're happy to help with a complimentary protocol review of your protocol documentation or to answer questions you may have.

Email us at support@softwaretoolbox.com with your questions and subscribe to our blog for more quick and easy OmniServer tutorials and tips.  Then, make sure to download the OmniServer trial to try it yourself for free.