EnsLib.HL7.Service.* through BPL to EnsLib.HL7.MsgRouter.RoutingEngine
Very similar question posed here: https://community.intersystems.com/node/467496, but I am missing a piece of this:
How do I correctly call a EnsLib.HL7.MsgRouter.RoutingEngine class from the BPL?I can successfully call the BPL from the EnsLib.HL7.Service.TCPService, and I have the BPL created to delay then call the rule. And I set the context and the result location..png)
This rule is really basic just sending the HL7 content to a EnsLib.HL7.Operation.TCPOperation
.png)
.png)
The Visual Trace shows that the BPL is getting called, and the rule gets called after the delay, but the rule actions don't get called, at least not correctly?
.png)
How would I send the HL7 original message through the BPL to this rule as if the BPL was not there?
If there is another way to add a delay without the BPL, that would work as well. I have not found a way to add the delay within the rule itself.
Comments
To pass the original HL7 message through a BPL and then into an HL7 routing rule, the message reaching the router must still be an EnsLib.HL7.Message, because EnsLib.HL7.MsgRouter.RoutingEngine is the router class used to support routing of HL7 v2.x messages, which are instances of EnsLib.HL7.Message. The HL7 routing rules themselves evaluate the incoming HL7 message as Document, using properties such as Document.Name, Document.DocType, and HL7 virtual property paths. [1][2]
For the router configuration itself, the routing process should use the full rule name in BusinessRuleName, and the Router Class should be EnsLib.HL7.MsgRouter.RoutingEngine. The guidance for HL7 routing specifically says the default router class created by the wizard should not be changed. [2]
If the rule is being called but its actions are not firing, one likely issue is that the message no longer matches the rule constraints after going through the BPL. For HL7 message routing rules, the constraints should match these message fields:
- Source constraint →
SourceConfigName - docCategory constraint → the portion of
DocTypebefore the colon - docName constraint → the HL7 message
Nameproperty [3]
So if your BPL is invoking the router but not preserving the original HL7 message object as the request, the rule may execute but not match the constraints or conditions needed for the send action. The rule conditions for HL7 are evaluated against the HL7 message object exposed as Document. [3][2]
If you want the behavior to be “as if the BPL was not there,” the BPL needs to pass the original HL7 request message object into the router unchanged, so that the router receives the same EnsLib.HL7.Message with its original DocType, Name, and related HL7 content available for rule evaluation. [1][2]
For adding a delay, the available material does not describe a delay feature within an HL7 routing rule itself. It does show that a router is a business process and that pre- or post-processing behavior can be implemented by overriding business process lifecycle methods such as OnRequest(), OnResponse(), OnComplete(), and OnTimeout() in a custom router class derived from a built-in router class. [1]
[!NOTE]
For compatibility with past releases, the special variablesHL7andHL7.Parentare supported as alternatives toDocumentandDocument.Parent. [2]
So the practical points to verify are:
- Your target business process is configured with router class
EnsLib.HL7.MsgRouter.RoutingEngine. [2] - The BPL sends an
EnsLib.HL7.Messagerequest to that router, not some wrapper or different message type. [1][2] - The router rule constraints still match the incoming message’s
SourceConfigName,DocType, andName. [3] - The rule actions depend on conditions against the HL7
Document, so confirm those properties are still present and correct after the BPL step. [2]
If you want, I can help you check the exact BPL call setup against these HL7 router expectations.
Sources: