This is an old revision of the document!
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.
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.
Messages marked as “Out Messages”
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:
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.
When an element of a message is a list, the length of the list is not checked by default. For example, the RequestedEventMessage:
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:
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:
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.