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!!

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.

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.

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