In our case, it adds 2.3s to a build that takes way longer than that. (Our build creates Foundation namespaces, and loading the FHIR resources takes insanely long.) I expect this to be Python startup time, plus some time proportional to the amount of data to copy (roughly 300MB in my test).

Thanks, this is very useful. I've just tested this on an image with various build steps, and this saves us quite a bit of image space. The copy step now adds a little under 300MB to the base image, instead of almost 5GB (!). Squashing an image has the same effect, but prevents layer caching, so each push to a docker repository would upload the entire image. Your way, after the first time, presumably just the 300MB. Nice!

Interestingly, we've had already contacted our sales engineers about the massive amount of image disk space used after our build steps. I couldn't find what it's used for; the actual Linux filesystem is way smaller. The build steps also don't visibly use significant disk space, that I could find. I'm hoping InterSystems manages to do something about this in the future. In the meantime, we've got a nice workaround. Thanks again!

I would file this with WRC. The settings documentation suggest that you can specify the in- and output encoding with the Charset (Tekenset) setting. That implies that you should set that to utf-8, but that doesn't actually work. From looking at the source code, it appears that the business service (EnsLib.REST.Service) hardcodes a %GlobalBinaryStream response stream, which will output the bytes as they are.

As a workaround you could convert (encode) the stream to UTF-8 yourself before sending it.

I like to second Dmitry's concerns. I can somewhat see the reasoning behind removing as much as possible from the docker images. Especially if convenient docker or docker-compose recipes are made available, this could perhaps be of limited inconvenience. But for the Windows installers, I really don't see the point. Especially on a developer system, if/when the internal server is not accessible from the outside world, security is not an issue at all. If it is, an option not to install the built-in apache could be added. Giving us choices, instead of taking them away. I consider removing the built-in SMP server a major inconvenience.

Just to be clear: in future IRIS installations, the System Management Portal will be unavailable, unless you have a web server installed and configured?

Separate question: the EAP program page mentioned above requires a login, and then offers to download an evaluation version of IRIS. I just want to look at that FAQ, which I couldn't find. Could that be made available more easily?

I'm not sure about the meaning of the Distributed column, but this does indeed look suspicious. If you have that option, I'd stop and start IRIS (which should clear existing licenses), and try the web terminal again. If it now works, you have at least found the cause.

As to a more permanent solution, I don't know. I don't use web terminal all that often, but I would hope that, when you log in, it adds a connection to a license that login may already have. Perhaps the web socket connection plays a part in this. Like I said, I haven't really investigated this; I just mentioned it so you'd have something to check.

You can check whether you still have licenses available in the management portal: System Operation -> License Usage. If Current License Units Used equals License Units Authorized, web terminal can't allocate a new license, which it does seem to need. If not, yours is a different problem.

I've seen this happen on a CE docker instance; in this case the cause was that licenses ran out. I did not investigate further, but it appeared each start of a web terminal caused a new license to be consumed. Perhaps this could be your problem?

Method %JSONImport returns a %Status, which tells you what the problem is (using $System.Status.DisplayError()):

ERROR #9406: Unexpected format for value of field, appointmentid, using AthenaAppointment mapping

That value is a number in JSON, but you defined it as a %String in the class. The JSON import code disapproves. There are more fields like that, and additionally field reasonid is not defined in the mapping. If you fix these problems, the data will import.

(I'd also remove the %DynamicAbstractObject superclass, it is unneeded and gives errors on object destruction.)