Scott Roth · Mar 22

Business Process setup - Orphaned Messages

I am still trying to track down orphaned messages and have noticed that when we have Business Rules that send to a Business Process that some times there is an orphaned message that is generated as result of that send. 

  • So my question is, is there an issue with the way that we have setup our Business Processes as they are setup with a request class of Ens.Request, and a response class of Ens.Response when the message is truly an HL7 message?
  • Shouldn't the request class and response class be EnsLib.HL7.Message?
  • Why would an orphaned message be created from the send from a Business Rule to a Business Process?

Product version: Caché 2018.1
$ZV: Cache for UNIX (IBM AIX for System Power System-64) 2018.1.3 (Build 414U) Mon Oct 28 2019 11:24:02 EDT
0 245
Discussion (6)2
Log in or sign up to continue

No, I don't think that's the issue.

My suspicion is that somewhere in your BPL you're cloning a message body and then not sending it anywhere, meaning that it never gets "attached" to a message header record. The records in Ens.MessageHeader are queried for the message body IDs to delete in the purge process, so if there's no header record with that message's ID as its MessageBodyID, it's by definition an orphaned message and does not get purged.

The source message is of course referenced by a header record, but a cloned message body doesn't get a header until you pass it to another process or operation.

In reviewing everything within the Business Process, I finally found that in my CALL requests that the response actions were not always filled in. So I am working through those now.

However I am seeing something weird with when a Router sends to the Business Process. Do I need to do something in the Business Process to send a response back to the Router?

Hi Scott,

we had a similar problem with orphaned response messages. They were shown in the visual message trace as type "NULL" instead of request or respose and the MessageBodyClassName in Ens.MessageHeader was empty.

We found two reasons for that:

1. business processes or operations where the pResponse parameter of the OnMessage() method was never used, e.g.

Method OnMessage(pRequest As Ens.Request, Output pResponse As Ens.Response) As %Status

The fix was to add a line of code to instanciate the object:

Set pResponse = ##class(Ens.Response).%New()

2. Routing rules that are called synchronous respond with a "NULL" message when the Response From parameter is empty.

The fix was to set the Response From parameter e.g. to "*" - the first response received will be the one returned


Thanks that helped a  lot. However I am seeing when I make a call to send the HL7 message to an operation, the callresponse is coming back NULL. Is there a way to send the message but make the process think we don't need a response back?

Can you show me a screen shot of what you mean by

"Routing rules that are called synchronous respond with a "NULL" message when the Response From parameter is empty.

The fix was to set the Response From parameter e.g. to "*" - the first response received will be the one returned"

Hi Scott,

when you send a message in synchronous mode (= wait for the response) to a routing engine,

either by not specifing Asynchronous In the call element of a graphic business process:

or programmatically: 
Set tSc = ..SendRequestSync(tTarget, tMsg)

There are several possibilities how/what the routing engine can respond (see help for Response From):

* means: return the first response the router has received to the sender

If you leave this field empty a "NULL" message will be returned.

Hope this will clarify it a bit.


If a Business Router is sending to a file based HL7 operation, I am seeing NULL values being returned. How can I tell the system that if we are sending a message to a File Based HL7 Business Operation that I don't expect a Return and avoid receiving the NULL value back?