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.

Hi Mary.

If you did want to create your own method to do this, you could do something like this:

Class Demo.StopThings
{

/// Stops all services in the specified production
ClassMethod StopAllServices(ProductionName As %String) As %Status
{
    Set sc = $$$OK, currService=""
    Set rs = ##class(Ens.Config.Production).EnumerateConfigItemsFunc(ProductionName, 1)
    While rs.%Next() {
        Set currService = rs.Get("ConfigName")
        Write "Stopping the following service: "_currService_"..."
        Set tSC = ##class(Ens.Director).EnableConfigItem(currService, 0)
        If tSC = $$$OK{Write "Complete!",!}
        Else{Write "Failed",!}
        }
    Return sc
}

}

And then you could call it from terminal from relevant namespace by running:

Set Status = ##class(Demo.StopThings).StopAllServices("Insert.ProductionName.Here")

To use the same code for Operations, change the 1 to a 3 in the call to "EnumerateConfigItemsFunc" (and swap out the bits that say service for operation).

The above is some quick and dirty code to demonstrate the approach you could go for, but you may want to add in some error handling etc to make things more robust given your usecase.

Hey Scott.

I saw this post when you originally made it, and I was curious to know what direction you went with?

As a short term approach, you may want to look into using Stunnel in client mode to encrypt the traffic and then set something up similar to:

This would mean that the traffic between your 2016 instance and stunnel is unencrypted but all on the same machine, and then stunnel handles the encryption between your machine and the external site using TLS1.3.

However, even if you go this route, I would still recommend getting the process started for upgrading to a newer version.

Are you able to share the full error you're seeing?

I have just tested this, and I'm getting no such errors when compiling.

This may cause some regions to opt for FHIR as a response while others opt for other solutions such as OpenEHR.

There's no reason for these to be seen as competing standards. A model where the data storage is OpenEHR and the data transfer is FHIR is seen by some as the best of both worlds 🙂

I'm not sure there's a way to select it when creating a production export.

The data in stored within the Global "Ens.Config.BusinessPartnerD" which you could export separately and then import into your new environment?

If you were to use the Parenthesis () Syntax in your routing rule, you could simply make your rule something like:

The reason this works is that using the parenthesis syntax to access repeating values from a message will return all of the entries in the repeating segment as a *delimited string, and you can then check the string contains the - character using the contains function.

*Do make sure that the delimiter isn't the character you're looking for. Maybe throw in a trace when you first test this and check how it's returned.

Hey Michael.

A good use of a lookup table would be when working with an integration between two systems that use differing codes for the same values.

For example, you could have System A that records Sex as 1 for Male, 2 for Female, 0 for Not Known, and 9 for Not Specified, whereas System B uses M for Male, F for Female, and O for Other.

You could have a winding If/Else in a transform, or you could simply reference a lookup table in your DTL using the ..Lookup() function:

and then build up your lookup table to look like this:

As you can see, System A has more values than System B so the values for Not Known and Not Specified are being added as Other in my example.

Another example could be you needed to filter messages in a router based on a code within the HL7 message. You could add the codes to a lookup table as the key and a description as the value, and then use the Exists() function within your routing rule:

Which becomes:

Hey Jon.

One option could be to change the permissions for the source directory to be read only for the account running Ensemble/Healthshare? This way, the adapter will copy the file from the directory but will then be unable to delete it from the directory, while also keeping track of what files it has copied.

The log for the passthrough service will be a bit messy at first. but you'll end up with something like:

However, if the directory you're going to be checking for documents will be an ever growing list of a large number of documents, then your own suggestion of copying the files into a secondary working directory before being picked up by ensemble might actually be the best option as there's a bit of an overhead for the adapter when it's scanning a directory that contains a large number of files.

Depending on how soon after the files creation you need it for onward processing, you could create a scheduled task that copies all files from the previous day into your working directory and then sends an email if that fails for any reason?