Hi Alexander.

Sorry for being pedantic, but you're missing the ending quotation mark when setting the value of 'sql'

SET variable = 2000
SET sql = "SELECT Column FROM Table WHERE ID = ?"
DO ##class(%SQL.Statement).%ExecDirect(, sql, variable)

Yes, I believe so.

The general principle is that the message is evaluated to see if it is eligible for being sent before the transform begins.

Hey Enrico.

The value of KeepIntegrity is set to True. I don't believe we have ever run the purge without including message bodies, but it's a non-production environment so stranger things have happened.

However, I did also just try running ##class(EnsLib.HL7.Message).Purge() in our production environment with the settings matching the retention period there, and it ran for a period, freed up around 5gb and then failed over to the other mirror as running the method consumed all of the ram on the box 😅

This namespace has been around for a long time (started life at around caché/ensemble 2014) and has likely accumulated a lot of baggage. I had a similar problem when trying to run Ensemble Orphaned Messages Purge Routine 

Hey David.

Your solution has caught my attention. What led you to this?

I have just run this against a non-production namespace that had a 30 day retention period and was sat at around 6GB. Running this command with the "pDaysToKeep" parameter set to 30 days has managed to free up 5GB and deleted 92158 messages, where I would have expected to have not deleted anything given the retention period for the purge task and the running of this method were the same.

Hey Brad.

The adapter has two sets of options here which can lead to confusion. We first have the charset for the adapter for the File adapter elements, and then the Default Char Encoding for the HL7 adapter elements.

As a starting point, I would try changing the Charset setting to Binary, and then setting the DefCharEncoding to UNICODE to match what is in your header.

Please look here for the solution: https://community.intersystems.com/post/base-64-message-taking-consideri...

So to do what you're trying to do in your DTL, add in a code block and paste in the following:

  Set CHUNKSIZE = 2097144
  Set outputStream=##class(%Stream.TmpCharacter).%New()
  Do source.EncodedPdf.Rewind()
  While ('source.EncodedPdf.AtEnd) {
    Set tReadLen=CHUNKSIZE
    Set tChunk=source.EncodedPdf.Read(.tReadLen)
    Do outputStream.Write($SYSTEM.Encryption.Base64Encode(tChunk,1))
  }
  Do outputStream.Rewind()
  Set Status = target.StoreFieldStreamRaw(outputStream,"OBXgrp(1).OBX:5.5")
  )

Yours is almost doing the same thing but, as Enrico points out with your code sample, you have the "Set tSC = tStream.Write($C(10))" line adding in the line breaks whereas my example has this excluded.

Separately, as alluded to by Scott, when adding the base 64 encoded PDF stream to the HL7, you'll want to use the StoreFieldStreamRaw method for the HL7. Trying to do a traditional set with a .Read() risks the input being truncated.

Hey Smythe.

Your Base64 has line breaks, so is breaking onto a new line which is then being read as a new line in the HL7.

Depending on what method you are using to convert the PDF to Base 64, you should have a setting to not use line breaks.

It's a bodge, but can you create a new namespace with the same name, delete the task, and then delete the namespace again?

Hey Anthony.

Depending on your version of Iris, I would recommend swapping out your use of %GlobalCharacterStream with %Stream.GlobalCharacter as the former is depreciated. Additionally, I would recommend swapping them out for their temp couterparts so you're not inadvertently creating loads of orphaned global streams, especially where you're dealing with files of this size.

It's a wild shot in the dark, but looking here: https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=ESQL_adapter_methods_creating#ESQL_transactions

has a try/catch where the catch has the following:

catch err{
    if (err.%ClassName(1)="common.err.exception") && ($$$ISERR(err.status)) {
      set tSC = err.status
    }
    else {
      set tSC = $system.Status.Error(err.Code,err.Name,err.Location,err.InnerException)
  }

If you try to recreate this, does the code you're looking for appear in either err.Code,err.Name,err.Location, or err.InnerException?

I thought that this would be a case of the Tilde being a special character for your target document due to its common use in HL7 for repeating fields. However, I ran a test to see what I got when trying this.

I created a transform for a PV1 segment, and attempted to set the value of PV1:1 to the output of the replace function and the input string contained a few commas:

I then ran this, and got this result:

Not only did it successfully replace the commas with tildes, but the virtual document now see's it as a repeating segment (even though the field is not repeating in it's specification).

I know this doesn't directly help you, but wanted to share my results in case it helped lead you to finding a solution. (for ref, this is from version 2022.1 of Iris For Health)

Ahh, I see what you mean.

I have not had to work in this way with IRIS and OpenEHR, so unfortunately I wouldn't be able to provide much insight.

Hey Joost.

What do you mean when you say "handle"?

Our interactions with OpenEHR for reading and creating/updating compositions are generally via traditional HTTP based API's, which is relatively simple to set up with IRIS.