New post
AllAccepted answers
Colin Brough · Apr 11

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.

Colin Brough · Mar 25

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

Colin Brough · Mar 17

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

Colin Brough · Jan 29

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.

Colin Brough · Nov 20, 2024

We've got the same issue, but with an incoming HL7 feed with embedded, encoded characters - would be nice to be able to detect what's coming in, but I take it from this discussion that's not (reliably) possible. Don't really want to scan the whole text of every incoming message to heuristically look for possible encodings. Upstream say/think they are sending UTF-8, but we seem to be getting Window-1252, for the characters we've seen in the (limited) testing. Who knows what will come through the feed once it goes live!