New post
AllAccepted answers
Colin Brough · May 1

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!
Colin Brough · Apr 30

Hmm, attachment isn't showing. Tried again, didn't work, so have pasted the text of the export file below:

<?xml version="1.0" encoding="UTF-8"?>
<Export generator="Cache" version="25" zv="Cache for Windows (x86-64) 2018.1 (Build 184U)" ts="2025-04-30 08:23:56">
<Class name="SCI81.s1.PatientNotification">
<Description>
Created from: http://fv-testscistore/storews/store81/scistoreservices.asmx?WSDL</Descr...
<ProcedureBlock>1</ProcedureBlock>
<Super>%SerialObject,%XML.Adaptor</Super>
<TimeChanged>63768,58466.681212</TimeChanged>
<TimeCreated>63767,58804.718434</TimeCreated>

<Parameter name="ELEMENTQUALIFIED">
<Default>1</Default>
</Parameter>

<Parameter name="NAMESPACE">
<Default>http://www.show.scot.nhs.uk/isd/SCIStore</Default>
</Parameter>

<Parameter name="XMLNAME">
<Default>PatientNotification</Default>
</Parameter>

<Parameter name="XMLSEQUENCE">
<Default>1</Default>
</Parameter>

<Property name="PatientID">
<Type>%String</Type>
<Parameter name="MAXLEN"/>
<Parameter name="XMLNAME" value="PatientID"/>
</Property>

<Property name="MergeID">
<Type>%String</Type>
<Parameter name="MAXLEN"/>
<Parameter name="XMLNAME" value="MergeID"/>
</Property>

<Property name="EventType">
<Type>%String</Type>
<Parameter name="MAXLEN"/>
<Parameter name="XMLNAME" value="EventType"/>
</Property>

<Property name="Consent">
<Type>%String</Type>
<Parameter name="MAXLEN"/>
<Parameter name="XMLNAME" value="Consent"/>
</Property>

<Property name="TransactionType">
<Type>%String</Type>
<Parameter name="MAXLEN"/>
<Parameter name="XMLNAME" value="TransactionType"/>
</Property>

<Property name="CHI">
<Type>%String</Type>
<Parameter name="MAXLEN"/>
<Parameter name="XMLNAME" value="CHI"/>
</Property>

<Property name="RecordType">
<Type>%String</Type>
<Parameter name="MAXLEN"/>
<Parameter name="XMLNAME" value="RecordType"/>
</Property>

<Property name="RecordKey">
<Type>%String</Type>
<Parameter name="MAXLEN"/>
<Parameter name="XMLNAME" value="RecordKey"/>
</Property>

<Property name="ProcessEvents">
<Type>%String</Type>
<Parameter name="MAXLEN"/>
<Parameter name="XMLNAME" value="ProcessEvents"/>
</Property>

<UDLText name="T">
<Content><![CDATA[
//Property any As list Of %XML.String(XMLNAME = "any", XMLPROJECTION = "ANY") [ SqlFieldName = _any ];

]]></Content>
</UDLText>

<Storage name="Default">
<Type>%Library.CacheSerialState</Type>
<State>PatientNotificationState</State>
<StreamLocation>^SCI81.s1.PatientNotificationS</StreamLocation>
<Data name="PatientNotificationState">
<Structure>listnode</Structure>
<Subscript/>
<Value name="1">
<Value>PatientID</Value>
</Value>
<Value name="2">
<Value>MergeID</Value>
</Value>
<Value name="3">
<Value>EventType</Value>
</Value>
<Value name="4">
<Value>Consent</Value>
</Value>
<Value name="5">
<Value>TransactionType</Value>
</Value>
<Value name="6">
<Value>CHI</Value>
</Value>
<Value name="7">
<Value>RecordType</Value>
</Value>
<Value name="8">
<Value>RecordKey</Value>
</Value>
<Value name="9">
<Value>ProcessEvents</Value>
</Value>
<Value name="10">
<Value>any</Value>
</Value>
</Data>
</Storage>
</Class>
</Export>

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.