An update in 2 parts:

1. Some of the code in our repo is non-canonical ObjectScript (eg it has examples of '//ABC' comments, with no space, in the files in the repo; these are canonicalised to '// ABC'). So when imported into Ensemble via the VS Code extensions, it is "canonicalised" and subsequently shows as changed in relation to what was in the repo. This is our problem, not a bug, but we've no idea why it occurred in the first place!
2. In the course of investigating it we stumbled on the ObjectScript Language Server error above, and I've subsequently been able to isolate it at least to the point of making it reproducible. There is further discussion on the GitHub discussion forum, including instructions for how to reproduce.

As result I'm going to mark this as answered, because further exploration will be done from stuff on the GitHub forum.

Thanks @Eduard Lebedyuk , that was helpful. As you describe, headers are not re-used from a previous call. On closer inspection, our confusion arose from the fact that if you provide a set of credentials as a setting on the operation which is implemented by EnsLib.HTTP.OutboundAdapter, even if you don't explicitly set the Basic Authentication headers yourself, they are created for you by the adapter using the provide credentials - we didn't realise this, and so when we removed our own explicit setting of the headers (for testing) we were confused by the headers still arriving in the downstream system!!

Update: this was answered by @Brett Saviano on the GitHub discussion forum for the VS Code extension: Should the extension change line feeds on compilation? · intersystems-community/vscode-objectscript · Discussion #1495
 

With help from WRC, looks like this is something of our own doing - we were using sub-transforms in ways that caused us problems. Our sub-transforms above were outputting whole new XML documents, when at the very least they should have been taking existing partially produced XML from the top-level transform and using that existing document to output. We "solved" the node ordering issue by moving everything into a single transform, so there was no mismatch between top level and sub-transforms.

For the sake of other people being able to find an answer, we took this up with WRC. Suspicion is this is a bug/aberrant behaviour in Ensemble (and they suspect recent versions of Iris). WRC were going to check in with development, and we are still waiting to hear back from them around that.

Never mind, our support people had updated the Java version, despite what the logs said! And because they hadn't restarted Ensemble/the server, it still had the old JAVA_HOME in its environment. We are currently banging their heads against the nearest wall for them! 🙄

Closing off an old question for completeness, we never did get Zen working. In the end we used Apache FOP directly:

• HL7 -> XML as described in the original question
• call Apache FOP using $ZF(-100,  $$$fopbat, "-xml", XMLfilename, "-xsl", StyleSheetFilename, "-pdf", PDFfilename)

This puts the output PDF onto the filesystem from where, in our solution, it is later picked up for onward transmission to a downstream system.

For the sake of closing off this old question, and to answer my own question, in light of more experience and some testing...

• side effects of the transformation could, in theory, change the behaviour - but it'd have to be a transformation that had side-effects (eg kept some kind of state across executions, whether in globals or on the filesystem or in some other way)
• performance could be affected, since transformation is called twice rather than once, but in most cases the difference is likely to be negligible.

Never mind, I'm an idiot. One of my colleagues found the issue - I thought I had, but I hadn't managed to add both:

• Property ReplyCodeActions As %String(MAXLEN = 1000);
• Parameter SETTINGS = "ReplyCodeActions:Additional,...."

I think I'd added one to TNHS.SOAPclassExtra, hadn't worked, tried the other, but somehow failed to check both together...🙄 Working now.

Follow-up/solution: we can do:

set message2 = message.%ConstructClone(1)

and then use message for the XML generation and message2 for calls to GetValueAt, and that works OK.

Still don't know why GetValueAt appears to change the content of the message...

For the sake of having an "accepted" answer on this post: we never got to the bottom of what was going on, and scrubbed and reinstalled Ensemble. Thanks for suggestions - some useful learning, even if we were never able to get to the bottom of what was going on.

For completeness / in case others come across this, turned out the XML export file was being corrupted during transfer between the two systems. It was a CR/LF corruption - in our specific case CR/LF was getting converted to CR/CR/LF !!

Highlighted that DTL's specifically appear sensitive to CR/LF changes - we've subsequently come across the same #6301 error loading DTL's get CR/LF modified in another way (we're still tracking that one down, though suspicion currently is with git...)