Question
· 6 hr ago

Yet Another Quest To Prevent Orphaned Messages

#HL7 #Interoperability #Ensemble #InterSystems IRIS for Health

Hey everyone.

As part of an ongoing mission to track down orphaned HL7 Messages in our integration engine, I have been digging into our environment to track down the causes.

Having looked at various posts here (including one of my own) there are a few scenarios that can create orphaned messages resulting in excessive disk space usage. These scenarios are generally:

  1. Purging an environment with the option "Bodies Too" deselected
  2. Code creating/saving a Message but then not sending it
  3. BPL errors similar to 2, or a scenario where the response to a Call component is not set.

These are certainly big contributors, however there are other situations that can occur based on what I have been finding.

Quick History

A message is considered orphaned if the message exists but is missing from Ens.MessageHeader or if it is an ACK and is not referenced within Ens_Util.IOLogObj. The standard purge jobs will delete message bodies based on the Header for standard messages as well as the ACKs when clearing the IOLog.

Therefore, we can list these fairly easily with the following query:

SELECT HL7.ID,HL7.DocType,HL7.Envelope,HL7.Identifier,HL7.MessageTypeCategory,HL7.Name,HL7.OriginalDocId,HL7.ParentId, HL7.TimeCreated
FROM EnsLib_HL7.Message HL7
LEFT JOIN Ens.MessageHeader hdr
ON HL7.Id=hdr.MessageBodyId
LEFT JOIN Ens_Util.IOLogObj ack
ON HL7.Id = ack.InObjectId
WHERE hdr.MessageBodyId IS NULL AND ack.InObjectId IS NULL

Now, having run the above today, I began seeing results for messages created today, which tells me that orphaned messages are being actively generated. Not good!

Taking a look at a few examples, there are additional scenarios to those listed above that are creating these orphaned messages (specifically ACKs).

  1. If an Operation receives an Negative ACK but the Operations Reply Action Codes are configured to process as Completed, this stores the ACK but does not create a Message Header or entry in the IOLog.
  2. If the ACK received from an external system does not match to a schema, then this stores the ACK but does not create a Message Header or entry in the IOLog

The solution to 2 is to correct the schema for the ACK, however the solution to 1 does not seem so straight forward.

Has anyone else come across the scenario of 1 that could offer some insight?

Discussion (1)2
Log in or sign up to continue
DC AI Bot · 6 hr ago

The scenarios mentioned for orphaned HL7 messages such as purging without selecting "Bodies Too," code creating or saving a message and not sending it, and BPL errors, are significant contributors. However, additional causes include:

  1. Negative ACKs in Operations with specific Reply Action Codes: If an operation receives a negative acknowledgment (ACK) and its Reply Action Codes are configured to process as "Completed," the ACK is stored but does not create a Message Header or entry in the IOLog. This can cause orphaned messages without a clear straightforward solution, as Reply Action Codes in the Business Operation might be creating these orphans intentionally under the "Completed" status for specific operations [1].

  2. Mismatch with Schema: When external systems send an ACK that does not match the expected schema, the ACK is stored but fails to create a Message Header or IOLog entry. Correcting the schema for the ACK resolves this [1].

For identifying orphaned messages, use SQL queries such as the following:

SELECT HL7.ID,HL7.DocType,HL7.Envelope,HL7.Identifier,HL7.MessageTypeCategory,HL7.Name,HL7.OriginalDocId,HL7.ParentId, HL7.TimeCreated
FROM EnsLib_HL7.Message HL7
LEFT JOIN Ens.MessageHeader hdr
ON HL7.Id=hdr.MessageBodyId
LEFT JOIN Ens_Util.IOLogObj ack
ON HL7.Id = ack.InObjectId
WHERE hdr.MessageBodyId IS NULL AND ack.InObjectId IS NULL

This lists messages missing from Ens.MessageHeader or unreferenced in Ens_Util.IOLogObj [2].

To avoid orphans:
- Always forward created message bodies and use APIs like SendRequestSync or SendRequestAsync which save the message automatically before sending.
- For purging orphan messages programmatically, tools like CleanupSet in the ENSDEMO database can help perform a deep purge [2].

For issue 1 specifically, revisiting the operations' Reply Action Codes settings or coding practices to ensure headers and IOLog entries are created correctly may offer insights into resolution. This approach requires careful testing to match the required configurations and handle exceptions without creating orphans [1][2].

Sources:

0 0