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")

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.

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.

Increasing the pool value will have some effect on the RAM and CPU usage, but no different than having other jobs running through the production. If you move all the components over to using the actor pool (by setting the individual pool settings to 0) it should be easy enough to raise the value bit by bit while keeping an eye on the performance of the production and the cpu/ram usage of the machine to find a sweet spot.

If the API just needs a bit of extra resource when there's a small spike in the inbound requests, then this should not be of too much concern as it will just calm down once it's processed what has been requested.

If, however, there's a chance that it could be overloaded from inbound requests and the worry is that the server won't cope, then maybe look at using Intersystems API Manager to sit in front of the environment and make use of things like the rate limiting feature.

Or you could go even further and begin caching responses to return if the API is being queried for data that isn't changing much so that there's less processing being done for each request if it's going to get called for the same information by multiple requests in quick succession. You could make your own solution with caché/Iris, or look at something like redis.

I'm thinking to increase the pool parameter, but I'm not sure if it's a good idea.

If you are not concerned about the order of which you are processing the inbound requests, then upping the pool size to the number of parallel jobs you're looking to run with should do what you need 

However, you may need to then also apply this logic to related components that the Process interacts with, otherwise you will end up just moving the bottleneck to another component.

Alternatively, if it fits your use case, you could use the Actor Pool for your production components and then increase it to a point where you see the bottleneck drop off.

Paolo has provided the link to the documentation on Pools, which has some info on considerations for the use of the two different types of Pool.

Thanks Luis.

The issue I'd have is that the clock starts on the poll interval at the point the service is started, so a restart of the server/production would then shift the time of day it tries to run, which would not be ideal if I needed a single run at a specific time of day. I might try a combination of the large poll interval and defining a schedule (based on the other responses) and see if that has the desired effect, but I may need to just concede and continue using the task manager. 🙂