Hey Community!

We're happy to share a new video from our InterSystems Developers YouTube:

⏯  Smarter Table Statistics @ Ready 2025

This presentation introduces Collected Table Statistics, a new and more flexible way to manage table statistics in InterSystems IRIS 2025.2. Unlike traditional fixed statistics stored in class definitions, collected stats are stored with data, making them easier to update, version, export, and roll back.
A new automatic collection task keeps statistics current by identifying and updating only the tables that need tuning, with minimal system impact and full configurability. Users can control when and how stats are collected, and choose between fixed or collected stats during query processing.

The feature also works in interoperability environments, improving SQL performance on message and search tables by allowing the engine to prioritize the most effective query conditions.

Presenters:
🗣 Yuchen Liu, Principal Systems Developer, InterSystems
🗣 Minhao Li, Systems Developer, InterSystems

Enjoy watching, and subscribe for more videos! 👍

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?