transsecs_message_matching [ErgoTech Systems, Inc. TechWiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
**TransSECS Message Matching**

TransSECS will attempt to match all incoming messages against known messages.  As soon as a match is found, not further matching is performed and the data is published and any notifications associated with the message are executed.

If no match is found, if a message of the given stream exists in TransSECS then an S9F5 message will be generated.  If the stream is unknown, an S9F3 message will be generated.

Whenever TransSECS receives a message is will first check to see if any of the messages match a known GEM standard message. This matching is described in the links below for tools and hosts.

[[GEM Host messages]]

[[GEM Tool messages]]


If the message does not match any of the GEM message TransSECS will attempt to match the incoming message against the messages your defined in the project tree.


{{:pasted:20200512-154510.png}}

Messages marked as "Out Messages"

{{:pasted:20200512-152608.png}}

will not be checked for an incoming match.

The search occurs in the order you defined the messages.  Here the first message checked will be the S1F4 message (the S1F3 message is marked as an "Out Message") and the last the S6F20 message.

The first check is to match the stream and function of the incoming message against the defined message.  An incoming message with a different stream and function will not match the TransSECS message.

If the stream and functions match, TransSECS will examine the structure of the message.  The structure must match exactly.  For example, the OnlineAck message:

{{:pasted:20200512-152351.png}}

must have exactly one element that is a binary type.  If the exact type is unknown, the "ANY" type may be used.  I this case the element must exist, but the type of the element is not checked.  The SVIDResponse message uses an "ANY" type.

{{:pasted:20200512-152439.png}}

When an element of a message is a list, the length of the list is not checked by default. For example, the RequestedEventMessage:

{{:pasted:20200512-152810.png}}

Starts with a list.  That list must contain two U4's and a List.  However, additional elements of that list will not prevent the message matching.  The same is true of the final zero-length list <L [0]> . When received, this list is likely to be non-zero length with variable parameters that can be parsed programmatically or in scripts.  Even though those parameter are not listed in TransSECS, and the incoming message has a list that is not zero-length, the message will be matched.  

**More precise message matching** 

There are, infrequently, cases where messages with similar structures should be identified differently. 

The most commonly used feature in this case is the "Key" field.

When the "Key" property is checked, the element at that location in the incoming message must exactly match the element defined in the "Default Value" field of TransSECS.  In this case:

{{:pasted:20200512-153652.png}}

the CEID in the incoming "RequestedEventMessage" must be 7502.  Any CEID value other than 7502 will prevent TransSECS from matching this message and matching will again be attempted at the next message in the tree.

Similar to a "Key", the default list-length matching behavior can be changed by selecting the "Match Exact List Length" option on the list editor node:

{{:pasted:20200512-153519.png}}

If selected, TransSECS will not match the list unless the incoming list exactly matches the list defined in the TransSECS message.

Somewhat common is to rely on the order of the message matching in TransSECS to match a "default" message after all more-precise messages have been matched.  Messages are ordered either by stream/function/alphabetical or alphabetically.  In this case, create a message that starts with a Z_ and it will be moved to the last element of the matched list and so matched last.

**Remote Command Messages**

For a tool interface, there is the option for special handling of S2F41 and S2F49 - remote or host command messages.

{{:pasted:20200512-163941.png}}


To enable this special handling, check the "Remote Command" checkbox. The "Command" field should be marked as a key in almost all cases.

When enabled, the message will be matched regardless of the order of the parameters.  In the example, if the PPID CPName is first and the LOTID second, the message will match.  The published data will match the CPName and not the location in the message.  All the CPNames must exist for the message to be matched.  There must not be unknown CPNames.  

If the "Send Err Msg" box is checked, if the "Key" field matches, or there is no "Key" field but the rest of the match fails, TransSECS will automatically return an S2F42 with an error description.  If there is only one message with a given "Key" the "Send Err Msg" button should be checked on that message.  If there are multiple messages with the same Key, the last message in the tree should have the "Send Err Msg" checked.  It's also possible to add "Default" S2F41 messages that do not have a key to force particular errors.  Make sure that they are the last S2F41 message and that the "Send Err Msg" box is checked.

**Advanced Message Matching**