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.

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)

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.

I 100% agree with Eduard.

Even back when I had two mirrored instances sat running in the same physical location, we were saved many times by mirroring when there had been issues with either IRIS or the server/OS itself.

It's also very helpful for managing upgrades, and even server migrations (by adding in the new servers as async members, and then demoting a failover member on an old server and promoting a new server from async to failover).

Jumping off of the answer I have given here only earlier today and being in a country currently observing(?) BST, you'll want to use the following approach:

1. Use $ZDATETIMEH with the dformat of  3 and tformat of 7 (Note for the tformat that it's expecting the input as UTC, which is what you have with your source timestamp)
2. Use $ZDATETIME with the dformat of 8 and tformat of 1
3. Realise quickly that the tformat includes separators between the date and time, and within the time itself, so wrap it all in $ZSTRIP to remove all punctuation and whitespace...

Basically this:

WRITE $ZSTRIP($ZDATETIME($ZDATETIMEH("2023-09-28T20:35:41Z",3,7),8,1),"*P")

Gives you this:

And demonstrating this for a date that isn't affected by BST you'll note that the time stays the same as the input because BST isn't in effect in the winter, taking the timezone I'm in back to GMT:

I hope this helps!

If you replace $h with $NOW(), this should do as you need

However there is a caveat with regards to Timezones mentioned in the online documentation that you may want to review to ensure it works as you'd expect and need.

Have you tried to open the pdf in a text editor like notepad++ to see what it looks like? It might be that the stream is incomplete, or you're writing the base64 to the file output without decoding?

This feels like a timezone/locale issue - is the difference between your time zone and UTC also 5 hours apart?

Hi Joshua.

Is it possible that there is a group policy in place that is being applied to you and not your colleagues? Have you tried forcing an update of your group policies applied to your profile - from the windows terminal/command line:

gpupdate /force

Alternatively, do you have any extensions installed in Edge that you don't have installed for Chrome? Maybe an adblocker?

Finally, have you tried opening devtools on this page, refreshing, and then seeing if there are any meaningful errors appearing under the Console or Network tab?

The only way I can think of doing this would be to split out the Helper() ClassMethod into its own class, and then ensure the order of compilation is in such a way that the class containing the Helper class method is compiled. Depending on how you're achieving this, could you use the CompileAfter class keyword?

So something like:

Class 1:

Class Foo.Bar.1
{

ClassMethod Helper()
{
// do something
}

}

Class 2:

Class Foo.Bar.2 [ CompileAfter = (Foo.Bar.1) ]
{

ClassMethod Generated() [ CodeMode = objectgenerator ]
{
do ##Class(Foo.Bar.1).Helper()
// do something else
}

}

There's a good thread from a few years ago that goes into various ways of converting date formats which you can find here.

My approach in that thread was to suggest the use of the class method ##class(Ens.Util.Time).ConvertDateTime()

In your case using this option, you could do this for your main question:

Set Output = ##class(Ens.Util.Time).ConvertDateTime(input,"%Y-%m-%d %H:%M:%S.%N","%Y%m%d")

And then for your followup to include seconds:

Set Output = ##class(Ens.Util.Time).ConvertDateTime(input,"%Y-%m-%d %H:%M:%S.%N","%Y%m%d%H%M%S")

Hi Pascal.

The additional blank lines is something that has come up before here Edit and Resend HL7 Adds Blank Lines | InterSystems Developer Community |

And the response the poster got suggested that this is being addressed in 2024.1.1 and 2024.2.

I can't speak to the IIS issue, but this might be worth raising with WRC?

If I were to write this in an operation using the EnsLib.HTTP.OutboundAdapter, my approach would be something similar to:

	Set tSC = ..Adapter.SendFormData(.webresponse,"GET",webrequest)

	//begin backoff algorithm
	
	//Get start time in seconds
	Set startInSeconds = $ZDTH($H,-2)
	
	//Set initial params for algorithm
	Set wait = 1, maximumBackoff=64, deadline=300
	
	//Only run while Status Code is 504
	While (webresponse.StatusCode = "504"){
		
		//HANG for x.xx seconds
		HANG wait_"."_$RANDOM(9)_$RANDOM(9)
		
		//Call endpoint
		Set tSC = ..Adapter.SendFormData(.webresponse,"GET",webrequest)
		
		//Increment potential wait periods
		If wait < maximumBackoff Set wait = wait*2

		//Adjust wait if previous action takes us above the maximum backoff
		If wait > maximumBackoff Set wait = maximumBackoff
		
		//Check if deadline has been hit, exiting the While loop if we have
		Set currentTimeInSeconds = $ZDTH($H,-2)
		If (currentTimeInSeconds-startInSeconds>=deadline){Quit}
	}

This is untested however, so massive pinch of salt is required 😅

I'm not sure if it's related, but my colleagues and I all notice random performance issues with the management portal when accessing our non-production environment that's using IIS.

It was deployed to our non-production environment for similar experimentation reasons, but I never took it further due to these issues (and it dropped from my radar due to still being on 2022.1.2 with no immediate pressures to upgrade)
I need to upgrade the version of web gateway following a recent email from Intersystems, so I'm going to run that now and then reboot the machine and see if I see any changes.

Beyond that, I'm going to be following this discussion closely to see if our issues are related and if there is a solution.