transsecs_message_matching

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision 		Previous revision
transsecs_message_matching [2020/05/12 14:17]
wikiadmin created 		transsecs_message_matching [2020/05/12 17:06] (current)
wikiadmin
Line 1: Line 1:
-[+TransSECS Message Matching+]+**TransSECS Message Matching**
  
-For a GEM Tool, incoming GEM-compliant Host messages will be automatically matched and handled.  +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.
-These messages should not be re-defined in the tool defintion unless you want to override the native behavior. +
-These GEM messages include:+
  
-(:table border=3 cellpadding=5 cellspacing=0:) +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.
-(:head:)Host Message +
-(:head:)Tool Response Message +
-(:cellnr:) S1F3 +
-(:cell:) S1F4 with SVID value(s) automatically inserted in reply +
-(:cellnr:) S1F11 +
-(:cell:) S1F12 with SVID list automatically inserted in reply +
-(:cellnr:) S1F13 +
-(:cell:) S1F14 with MDLN and SOFTREV automatically inserted in reply +
-(:cellnr:) S1F15 +
-(:cell:) S1F16 with OFLACK +
-(:cellnr:) S1F17 +
-(:cell:) S1F18 with ONLACK +
-(:cellnr:) S1F23 +
-(:cell:) S1F24 with CEID list automatically inserted in reply +
-(:cellnr:) S2F13 +
-(:cell:) S2F14 with ECID value(s) automatically inserted in reply +
-(:cellnr:) S2F15 +
-(:cell:) S2F16 with EAC automatically inserted in reply +
-(:cellnr:) S2F17 +
-(:cell:) S2F18 with date/time of tool automatically inserted in reply +
-(:cellnr:) S2F23 +
-(:cell:) S2F24 with TIAACK automatically inserted in reply and trace started if appropriate +
-(:cellnr:) S2F29 +
-(:cell:) S2F30 with ECID list automatically inserted in reply +
-(:cellnr:) S2F31 +
-(:cell:) S2F32 with TIACK and date/time of tool automatically reset +
-(:cellnr:) S2F33 +
-(:cell:) S2F34 with DRACK automatically inserted in reply and listed report(s) enabled/disabled (if not error) +
-(:cellnr:) S2F35 +
-(:cell:) S2F36 with LRACK automatically inserted in reply and listed report(s) linked/unlinked to events(s) (if not error) +
-(:cellnr:) S2F37 +
-(:cell:) S2F38 with ERACK automatically inserted in reply and listed event(s) enabled/disabled (if not error) +
-(:cellnr:) S5F3 +
-(:cell:) S5F4 with ACKC5 automatically inserted and alarm(s) enabled/disabled +
-(:cellnr:) S5F5 +
-(:cell:) S5F6 with alarm list automatically inserted +
-(:cellnr:) S5F7 +
-(:cell:) S5F8 with enabled alarm list automatically inserted +
-(:cellnr:) S6F15 +
-(:cell:) S6F16 with event report data automatically inserted +
-(:cellnr:) S6F19 +
-(:cell:) S6F20 with report data automatically inserted +
-(:tableend:)+
  
 +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**
  • transsecs_message_matching.1589311060.txt.gz
  • Last modified: 2020/05/12 14:17
  • by wikiadmin