User bio
404 bio not found
Member since Nov 11, 2020
Posts:
Replies:
Based on this, is it fair to assume that the following alteration to the SQL query in Scott's above post would give a truer reflection of orphaned messages?
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
If you're looking to simply convert timezone codes to the UTC offset, I'd setup a simple utility that returns the desired string based on a case statement.
Something like:
ClassMethod DisplayTimezoneToUTCOffset(pInput as %String) As %String{
Quit $CASE($ZCONVERT(pInput,"U"),
"CEST":"+02:00",
"CET":"+01:00",
"BST":"+01:00",
:"")
}
If you then want to build the entire string, you could do similar to above for the months, and then have the following:
Class Demo.Utils.ExampleUtils.TimeConvert
{
ClassMethod DisplayDateTimeToLiteral(pInput as %String) As %String{
// Deconstruct the input string into it's logical parts.
// Variables starting d are "display" values that will be converted later.
Set DayOfWeek = $P(pInput," ",1) //Not used
Set dMonth = $P(pInput," ",2)
Set Day = $P(pInput," ",3)
Set Time = $P(pInput," ",4)
Set dTimeZone = $P(pInput," ",5)
Set Year = $P(pInput," ",6)
//Return final timestamp
Quit Year_"-"_..DisplayMonthToLiteral(dMonth)_"-"_Day_" "_Time_..DisplayTimezoneToUTCOffset(dTimeZone)
}
ClassMethod DisplayTimezoneToUTCOffset(pInput as %String) As %String{
Quit $CASE($ZCONVERT(pInput,"U"),
"CEST":"+02:00",
"CET":"+01:00",
"BST":"+01:00",
:"")
}
ClassMethod DisplayMonthToLiteral(pInput as %String) As %String{
Quit $CASE($ZCONVERT(pInput,"U"),
"JAN":"01",
"FEB":"02",
"MAR":"03",
//etc. etc.
"JUL":"07",
:"")
}
}
Which then gives the following:
.png)
Certifications & Credly badges:
Julian has no Certifications & Credly badges yet.
Global Masters badges:







Followers:
Following:
Thanks Jeffrey - it's certainly highlighted some hidden pockets of orphaned messages for me. I'm going to track this in a separate thread, but basically it seems there's a few edge cases where ACKs are being saved and don't end up in the IO log and don't get an entry in the Message Header table.