Thank you so much for the detailed response, Eduard.

Upon further reflection, though, I'm not sure this is exactly the solution I'm looking for. There may be multiple "sidelined" messages that are eligible for update from a single response; consider the situation where lab orders may be created in an external system for delivery to a Lab system, but the patient is registered in the Lab via a separate interface that is driven by a request made of the registration system by Ensemble. All orders for a given patient encounter would need to be held until the registration is received, but only one event will trigger the release (and enrichment) of all orders for that encounter.

Assuming tokens are unique across all deferred responses, I'll need to create a token management system that supports a one-to-many relationship between the "public" token sent to/received from the external system and the "private" tokens that identify deferred messages eligible for update from a given deferred response. If a single token can satisfy the response requirement for multiple messages, though, that may not be necessary. If that capability is mentioned in the documentation, I haven't come across it yet.

In Studio's Tools menu, select Options, Environment, Documentation and Proxy. Check "Templates and add-ins will use Proxy server for <hostname>." Enter the address (including 'https://' if you're using SSL/TLS) and port number for your standalone web server. Click Apply.

You may have to re-authenticate each time you select a template, but at least you'll be able to get to them (and I'm sure there's a way around that too).

Hmm. If " is is escaped as \", and the value consists of a single " (or ends with ") then it appears as \"" in the JSON output. A simple $REPLACE becomes a slightly less simple $REPLACE(json, ":""""", ":null""") , with fingers crossed that the output from %ToJSON isn't prettified in the future...

Certainly not the end of the world, but I'm a bit concerned that it's the start of a trip down the rabbit hole wink

Thank you, Eduard.

My need is relatively unsophisticated, at least in my mind :)

I'm modeling  a JSON request payload for a web service as a Persistent class  ("Patient") that will be used as the message body for an Ensemble Request (of type Ens.Request). The Patient object will be populated from HL7v2 or possibly other sources via a DTL, and the target HTTP operation will serialize the message body to JSON for submission to an external web service.

Your suggestions have given me 98% of what I need ... but I'd like to represent unpopulated values as null rather than "" and/or simply omit keys with null values from the resulting JSON. There are format options for some of the %ZEN.Auxiliary.altJSONProvider methods, but none seem to provide that sort of control (and I swear I saw one or both of my desires addressed in one of the DC threads on JSON serialization but can't find it again).

substituting null for "" is a relatively simple $REPLACE operation; scraping out un-valued keys is perhaps a bit more complicated.

Thanks for clarifying the current status of the new JSON methods. I'm hoping any current issues get resolved soon.

So, putting it all together ...

NOTE: This is NOT production-ready code. There's no error handling or input validation. You get to add that stuff yourself :)

Class User.HL7.Operation.Email extends Ens.BusinessOperation {

 

Parameter ADAPTER = "EnsLib.EMail.OutboundAdapter";

 

Property Adapter As EnsLib.EMail.OutboundAdapter;

 

Parameter INVOCATION = "Queue";

 

Method SimpleMessage(pInput As EnsLib.HL7.Message, Output pOutput As Ens.Response) As %Status

{

    Set email=##class(%Net.MailMessage).%New()

    Set addr = pInput.GetValueAt("PID:13.4")

    Do email.To.Insert(addr)

    Set email.Subject="The subject of your message"

    Do email.TextData.Write("This is the body of your message.")

    Set tSc=..Adapter.SendMail(email)

    //send an empty response message after message is sent

    Set pOutput=##class(Ens.Response).%New()

    Quit $$$OK

}

 

XData MessageMap {

<MapItems>

    <MapItem MessageType="EnsLib.HL7.Message">

        <Method>SimpleMessage</Method>

    </MapItem>

</MapItems>

}

 

}

Do you need to route the message based on criteria supplied in HL7 field values? Is any transformation required?

If the answer to both of those questions is "no," then you really don't need a router ... you can specify the operation(s) in the target config name field for the business service that receives the messages.

If you need to route, though, you'll want to disable BuildMap segment mapping error validation in the routing rule. That's enabled when using 1 as the validation selection. Try "d-m-z" instead, assuming you still want to validate that the messages have a DocType assigned.

Note that you won't be able to (easily) specify routing criteria based on fields in segments starting with the first segment that doesn't match the schema, or (again, easily) work with those segments in DTLs.

If flexibility and maintainability are a requirement, I'd recommend you go ahead and create a custom schema.

There's a pretty good description of what needs to be done in the overview here. It describes, and offers examples of,  methods for composing and sending an email in a Business Operation based on this adapter. The primary decisions you'll need to make are whether it will be a simple text-based email vs. a multi-part message, what type of message object will trigger it, and the method to call for delivery when that message type is received.