How to determine why a message didn't get routed by a message router routing rule.

When testing a new routing rule, one frequently encountered problem is that messages that seem like they should be getting routed to a target component are not getting routed.  This article aims to describe how to determine why the message didn't get routed.

1. Check the Event Log for the router to make sure there wasn't an error evaluating the rule or running any transformations referenced by the rule.  If there was, debug that error first.

2. Verify the settings on the general tab in the rule editor.
2a. Make sure "Rule Type" is correct.  For HL7 messages, it should be "HL7 Message Routing Rule".  For other types, it should be "General Message Routing Rule".
2b. Make sure "Rule Assist Class" and "Context Class" are correct.  Setting "Rule Type" will automatically set both of these fields, so if either are correct, just reset the "Rule Type" field to the correct value.
For Rule Type "HL7 Message Routing Rule", Rule Assist Class should be EnsLib.HL7.MsgRouter.RuleAssist and Context Class should be EnsLib.HL7.MsgRouter.RoutingEngine.
For Rule Type "General Message Routing Rule", Rule Assist Class should be EnsLib.MsgRouter.RuleAssist and Context Class should be EnsLib.MsgRouter.RoutingEngine.
2c. "Production Name" does not affect a running production.  It only affects the lookups when editing a rule.  Set it to the name of the production in which the rule will be used.

Below is a screenshot of these settings on the general tab:

For the following steps, you will need to find a message in the message viewer which was sent to the router without being routed.  To find such a message, search for messages that have the router as a target, as in the example extended criteria in this screenshot:

This screenshot illustrates the difference between visual traces for a message that was routed correctly (left) and a message that got stuck at the router (right):

Once you find the message that wasn't routed, make note of the following message header fields on the 'Header' tab:
SourceConfigName
MessageBodyClassName
MessageBodyId

If this is an HL7 message, then also make note of the following fields on the Body tab:
DocType
Name

3. Verify the constraints.  Below is each possible constraint, and which field it should match.
3a. Source constraint should match SourceConfigName header property
3b. (General Message Routing Rule Only) Message Class constraint should match the MessageBodyClassName header property
3c. (HL7 Message Routing Rule Only) docCategory constraint should match the portion of DocType before the colon.  E.g. if DocType is 2.3.1:ADT_A01 then it will match docCategory 2.3.1
3d. (HL7 Message Routing Rule Only) docName constraint should match the Name body property

Below is a screenshot showing example constraints:

4. Verify the conditions.  This should be done in terminal.
4a. First, use the MessageBodyClassName and MessageBodyId from above to open the message body in terminal: set msg = ##class(<MessageBodyClassName>).%OpenId(<MessageBodyId>)
4b. Multiple conditions will be separated in the rule by an AND or an OR.  Test each condition individually in terminal.
4c. (HL7 Message Routing Rule Only) For conditions that reference specific HL7 fields, use the method GetValueAt on the message to extract the values of the fields.  Below is an example screenshot of a rule and an example terminal session showing how to test the conditions.

 

In the terminal session, I can see that the SendingApplication of the message doesn't match what my condition is looking for.  The message has REGADT but my condition is looking for ADMADT.