New post
Question
· Mar 22, 2022

Business Process setup - Orphaned Messages

#Business Process (BPL) #Business Rules #HL7 #Ensemble

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
Discussion (6)2
Log in or sign up to continue
Jeffrey Drumm · Mar 22, 2022

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.

1 0
Stefan Schick · Mar 25, 2022

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
 

Regards
Stefan

0 0
Scott Roth · Mar 25, 2022

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"

0 0
Stefan Schick · Mar 29, 2022

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.

Regards 
Stefan

0 0