New post
Question
· Jul 16

Orphan Message Cleanup Approaches

#Databases #HL7 #Namespace #Caché #Ensemble

Hi all.

Recently, I have noticed Scott Roth's mission to resolve issues with Orphaned messages with a lot of focus on prevention, and I envy that level of dedication.

Not wanting to be left out, this has sparked an interest in checking my environments for orphaned messages. Amongst a few different posts on the subject, I came across this post from Suriya Murugan in 2016 that included an interesting class in a Github Gist that seems to be built to do a deep dive into the identification and cleanup of Orphaned Messages.

My question is - is this still considered an appropriate way of cleaning up a namespace's amassed orphaned messages? Other approaches seem to focus heavily on HL7 2.x messages, but a lot of the orphans in my environments are most likely from custom classes that contained the odd steam object without an appropriate %OnDelete classmethod included.

Discussion (10)3
Log in or sign up to continue
Julian Matthews · Jul 18

Thanks Scott.

I'm also not rushing to delete based on counts, but it's still interesting to review.

I ran the "Complete Ensemble Message Body Report" from Suriya's post's Gist against a namespace and it ran for about 8 hours, which now has me nervous to run the Delete option. Although, to be fair, this is a namespace that has been in operation for about 10 years, so I might start smaller and work my way up.

0 0
Scott Roth · Jul 18

In my adventures, I broke down our BPL's to see where the Custom Message Classes were leaving the Orphaned messages.

Within BPL's make sure if you use Context Variables none of them are sent to "Instantiate", if you end up not using that context variable it will leave a blank (orphaned) message.

Also pointed out by others was not to have the Response object be anything other than Ens.Response. Any other type would cause an Orphaned message created even if you don't use it.

I also took it upon myself to make sure any context variable (message class) that I defined, I set to "" after using it.

0 0
Scott Roth · Jul 18

I had a context variable set to Ens.Response, then when I would make my calls to the BO to execute the Stored Procedure on MS SQL, I would set the Response even though I did not expect thing to Ens.Response and my context variable to callresponse.

Then return Ens.Response at the end of the BP. I figured since it was blank it was not needed and would be creating additional Ens.Response objects.

So I removed the callresponse from those calls that I did not expect anything back from like inserts, etc... because if there was a SQL error the status and error would of be sent back to the BO anyway.

0 0
Mark OReilly · Aug 5

Hi:

The reason for counts rather than days was a more granular approach to deleting data with no day information about it i.e. Stream data which would not have a date assigned to it.

Also a lot of custom data ends up in the same table if you don't define a new location for the message data. This would cause an inability to run proper sql against it to clear out the data so a count based approach of where the last message id was required 

1 0