Wow, thanks very much. I did try, and it seems to work flawlessly. It makes editing the markdown already more pleasant, even without the preview being colored. Thanks again!

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

The ToXML function is broken. This is a known bug (I've reported it mid-Januari).

It is possible to fix it, but it requires patching system code, class HS.FHIR.DTL.Util.XML.Adapter to be precise.

In that class, at (on my system, 2021.2) line 359 (in method ToXMLHelper), there is this statement:

set isprimitive = ($extract(propType)="%")

This basically assumes all properties are objects, except those that start with a %-sign. This is obviously wrong. The code will work if you replace that statement with this:

set isprimitive = ($extract(propType)="%") || (propType="") || ($$$classIsDataType(propType))

Here we additionally check for properties without a type (DomainResource has one: property id), and typed properties that are datatypes. With this change, the ToXML() method works for me.

HTH,
Gertjan.

Just a quick response to your "topic for a different discussion", as it is relevant in this one. A Scope inside the loop allows one to examine the exact error, and if it is not fatal, decide to handle/ignore it and continue with the next iteration. A Scope outside the loop makes this a lot harder.

What BPL structure shows the problem solution most clearly depends on the problem and sometimes, as you note, on personal preference. It is therefore important to specify exactly which conditions are not supported, rather than "certain conditions". This allows the programmer to choose the easiest and/or clearest solution path, and not have to worry about things breaking if iterations exceed a certain (unspecified) number.

To purposefully withhold that information, as you suggest the documentation does, is saddening.

Actually, on closer examination, it appears that in your example the problem is that the Continue is inside the Scope. If you move it outside the Scope, the problem doesn't occur (as you noted). The cause is that the fault handler that was pushed on the stack for the Scope is not removed, because the Scope is not exited "normally". Therefore, each iteration adds a fault handler to the stack that is never removed.

Having one or more scopes in a loop is a perfectly normal thing to do, if you want fine-grained error handling and/or recovery. I have just done some tests, and they work perfectly. If "best practice" dictates that this should not be done, "best practice" is wrong. A Continue inside a Scope, however, is never needed (even if perhaps convenient sometimes).

Unfortunately, I don't remember exactly what I did when I ran into my handler stack issue (it's been a while). Perhaps I also did a Continue inside a Scope. In that case, it was a bug on my part.

Perhaps this can be better documented? The description of the limitation you quoted above is rather vague. Even better would be if the compiler recognized this construct, and removed as many fault handlers from the stack as were pushed on it, when it encounters a Continue inside a Scope in a loop.

Thanks, this is useful information. I have encountered this bug in the past, but did not have the time to figure out exactly what triggered it, and restructured my code.

It would be nice if this bug was fixed, though.

Thanks, but a terminal command (requiring you to install the preview release) is not what I call documentation. But I did install it. To give an example of what the "Help()" gives me:

Help(method)
     Write out a list of the methods of this object to the console.
addToPath(path)
     <p>
createServer(serverDef)
     Create a new server.  This function requires the "%Admin_Manage" resource.

Interestingly, on the local installed preview, the class documentation does show the %SYSTEM.external class (with ever so slightly more information, btw.). I really hope that this lack of documentation is fixed before release, because as it is now, it is unusable.

Regard,
Gertjan.