Interesting, will maybe pursue at a later date - Jeffrey's suggestion above works for us, and we've also got organisational constraints on what browser extensions we are allowed to install, which makes trying this non-trivial.

This is fantastic - exactly what we were looking for. Thanks!

Yeah, should have said we've used that - but we've not figured out how to use VDoc specifications or their equivalent to output specific fields from the HL7 message as you can in the message viewer. In the SQL text shown by "Show Query" you get something like:

null As FieldName

where the column specified in the message viewer via a VDoc display specification would be.

Query in Message Viewer includes display item: 

This produces SQL query below:

Thanks @Eduard Lebedyuk for replying - we've already got ACK Mode set to Application.

Further investigation has revealed that:

• an "AA" (successful) ACK is passed back from the downstream to the pass-through interface and from the pass-through to the upstream when the business service (HL7 TCP) is connected directly to the business operation (HL7 TCP). This is (successful message) behaviour we want.
• an "AE" (unsuccessful) ACK from the downstream causes the business operation in the pass-through to suspend the message under default Reply Code Actions, and no ACK is send back from pass-through to the upstream. We want the AE ACK to be passed back through the pass-through to the upstream. 
• When a Message Router business process sits between the business service and the business process in the pass-through interface then (with current settings) then an ACK is generated by the Message Router and sent back to the upstream before any ACK (AA or AE) is received back from the downstream.

So our questions:

1. What Reply Code Actions applied to the business operation in the pass-through will not suspend messages which result in an AE (error) ACK, but pass that ACK back to the upstream? (We are continuing to experiment/read to see if we can do this.)
2. Is it possible to force an HL7 Message Router to be synchronous and wait for the ACK from the business operation, rather than defaulting to be asynchronous?

Perfect, thanks!

Thanks, that's really helpful - we'll have a play and see whether we can configure that to tell us what we are interested in.

We are using a source control solution - for the code we develop - the problem is that the other groups (an external contractor doing development, and a platform management team making config changes, mostly in the Production class) don't use our source control. So we are having to manually merge changes made by others back into active development branches - and organisationally / given the historical situation with multiple interacting interfaces built in a single namespace, there's not a lot we can do to change that context. So an audit of who changed what when is probably the best we can get for now...

Thanks Brett, that's very helpful. Have tried out the various combinations of VS Code import and export of code and also $SYSTEM.OBJ.Load() / .Export() / .ExportUDL() and what we are seeing matches your description. I suspect we'll never know how the affected classed got into our codebase in the first place, but now that we know what's going on we can make some attempt to manage the situation.

Thanks for replying:

1. Not really what @Brett Saviano, one of the ISC maintainers of the VS Code extension, said in previous discussion on the extension's github page.
2. Yup
3. But how? Try and edit, using either Studio or VS Code, to produce a '//XXX' comment (no space) outside a method definition. You can't do it - the space is generated by the editors without your intervention. Hence my question - how did that space get into Ensemble in the first place?
4. Yup
5. In principle its not just commented out Property's, it seems to be any '//' comment with no space after the '//' when that comment is not within a method (or classmethod) definition. And finding the couple of hundred classes with such comments across a 4000 class file production is a non-trivial exercise!

I'm also seeing the Language Server output disappearing from the drop-down now! @Brett Saviano is responding more fully on the GitHub forum linked above.

Thanks for looking. Realised that I gave the version number for the ObjectScript extension (3.0.1), but not for the Language Server (2.7.2). And as you've highlighted its the language server which is giving me the error.

Thanks, @Enrico Parisi, that looks a good starter for the kind of thing we are exploring.  

Thanks for the link, but as we are stuck on Ensemble (not Iris), we can't make use of this.

Thanks, that's helpful. Our end goal was the perennial XML to JSON conversion conundrum, or HL7 to JSON, and as we're currently stuck on Ensemble 2018, we've not got access to %JSON.Adapter, so we're... limited.

Our immediate goal was, given a particular message/document, visit all nodes holding data within the document (traverse the tree), and do some processing for each node - eg output a JSON representation of the data held at that node so that a JSON serialisation of the whole document can be produced; but the general case, not just the JSON case, is of interest.

Current application is taking an HL7 feed and sending (a subset of) the data in the HL7 and sending to be consumed by a downstream system via a REST web-service. The downstream in this case is being developed by another team within our organisation, and they can take XML - we've built a transformation to extract the relevant data into an EnsLib.EDI.XML.Document, and we've developed an XML schema for the data so we can validate it before sending on. But it would have been easier for them to consume JSON, so we were exploring how to do that - and are conscious that future requirements might include sending JSON rather than XML...

I was going to respond and say something like, "I'm sure that does answer the question, but I'm not sure I understand the answer!" So thanks for the executive summary! And thanks @Robert Cemper 
 for the background information.
  

Its a virtual document: EnsLib.EDI.XML.Document, with the XML schema applied having been loaded into Ensemble via Ensemble -> InterOperate -> XML -> XML Schema Structures.