Hi Evgeny,

The current GitHub version will only serialise and deserialise to and from class based objects.

I do however have several other solutions in the unofficial version which will efficiently serialise and deserialise to and from globals. I also have a pollyfill solution for DynamicObject and DynamicArray that uses a type mixer class that would allow older versions of Cache to work with these classes now.

However, I've not used these in production, only unit tested. I am happy to release them if there is a need / someone is willing to collaborate on production level testing and debugging.

Hi David,

In general +1 for the generic boiler plate approach.

In terms of a generic JSON solution is could do with some additional type checks to make sure they are output correctly, e.g. booleans as true / false / null, empty numbers being returned as null and not empty string etc.

So just for booleans as an untested example you might replace...

set $PROPERTY(tRow,tColumnName) = $PROPERTY(rSet,tColumnName)

with this..

do tRow.%Set(tColumnName,$PROPERTY(rSet,tColumnName),$Select(tColumn.clientType=16:"boolean",1:""))

The alternative, if just going from SQL to a serialised JSON string could be to just use SQL and JSON_ARRAYAGG as per the examples here...


Hi David,

It's a little unclear if you are trying to conditionally serve static files, conditionally generate static files or something else. Do you have a more specific use case to help answer the question?

Yes, the semantics of my description are not perfect.

I should probably have used the term "resolved canonical form" in this particular instance.

You can access the rule name with aux.RuleReason in the transform which provides a way to pass in a delimited value.

Another option is to chain transformations together within the same send action. So you could have a second transformation for each target that does nothing but assign a hard coded value such as MGH and MGP to your facility codes.

To chain the transformations just select a second transformation from the data transform selector, or just add the name of the transformation in a comma delimited list, e.g.



It's worth mentioning that this will only work for the same target operation.

There are some downstream systems that require ADT and ORM messages to be sent on different ports. In this instance the messages end up on different queues and can be sent out of sequence.

I think the problem is that the RemoveItem() method does not action a %Save() on the production, so the item gets deleted, but remains referenced in the production XML.

If you look at the DeleteConfigItem() in the EnsPortal.ProductionConfig class you will see it calls the RemoveItem() method, but then does a %Save() afterwards to commit it.

I think I must have been doing something similar. I also seem to remember programmatically stopping the production first and then restarting it to remove any memory problems, although I think this was only causing problems on an early version of Ensemble.

Interesting, I'm sure I've had this working in the past. I will have a hack around with it. What version are you using?

I can't presume to know all decoders will unescape the solidus correctly.

Escaping the solidus is not a strict rule in the specification and there may be implementations that do not unescape it.

I think it is safer to say "most" than "all" and not place any false confidence on the next developer to read this post. I would rather they execute due diligence and be 100% sure that the third party libraries they are using will handle the 2016.1 output.

I wouldn't recommend this solution, it will cause problems.

It gets a bit confusing talking about strings, so lets refer to a serialised object as a stringy, and a property of a JSON object of type string as a string.

The $ZCONVERT function should be used to decode JSON strings (properties of a JSON object). It should not be used to decode a stringy (a serialised JSON object).

It works in your use case because it sees the stringy as a string and since there are only unwanted reverse solidus's to remove it looks like its working the way you want it to.

Let's say at a later date someone adds a description property, and one of those descriptions has the value 

A "special" file

In the JSON it would be escaped like so... 

{"FileStatus":"P","Path":"\/somepath\/test\/test123\/filename.txt","InterchangeOID":"100458","Desc":"A \"special\" file"}

This gets passed into $ZCONVERT and you end up with...

{"FileStatus":"P","Path":"/somepath/test/test123/filename.txt","InterchangeOID":"100458","Desc":"A "special" file"}

The path looks good, but now the description is invalid.

Is there a technical reason for wanting to remove the reverse solidus from the path?