All
Accepted answers
Colin Brough · Mar 9 go to post

Thanks for those that took the time to reply. Summary of where we've got to:

  • "structural" support for what we are trying to do isn't there in Ensemble 2018; another piece of ammunition to use when kicking our management into upgrading to Iris 😁
  • we had a further think, and also had a conversation with someone from WRC where were able to go into a bit more detail about our application, which resulted in a (very promising looking) solution. We already have a table whose contents includes the MessageBodyId, so we when we come to process a message for a LabReportId we can see whether there is an entry in the table for that LabReportId, and if there is compare the MessageBodyId in the table with that from the current message to ensure they are processed correctly.
Colin Brough · Oct 7, 2025 go to post

Yeah, this is what we were doing (and wanting to avoid). So being able to do the queries in SQL, including the HL7 content, and exporting the output to CSV (which Excel can import) means we have the tools we need for future diagnostics/issue resolution.

Colin Brough · Oct 7, 2025 go to post

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.

Colin Brough · Oct 3, 2025 go to post

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:

Colin Brough · Sep 23, 2025 go to post

A basic pass-through can be achieved by:

  • HL7 TCP Service with Ack Mode set to Application
  • no message router/business process
  • HL7 TCP Operation, with Reply Code Actions set to
    :?R=C,:?E=C,:~=C,:?A=C,:*=C,:I?=W,:T?=C
  • this basically says that the pass-through interface will treat every message which receives an ACK (of any kind) from the downstream as Completed (C), and so pass the received ACK back to the upstream.
Colin Brough · Sep 22, 2025 go to post

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?
Colin Brough · Jul 10, 2025 go to post

Same command works fine for me, similar vintage of Ensemble. Must be something specific to your environment/machine, and what drives are available. You could try

set sc = $ZF(-100, "/SHELL","dir","C:\")

or some other drive you know to be present, and see whether that makes a difference.

Colin Brough · Jul 2, 2025 go to post

When I looked yesterday there was a "Learning Services, Dev Community and Partner Portal Overview" listed for 24th July. When I went to register for both the future of healthcare integration and the learning services, Dev Community etc one, the latter has disappeared. Any plans to reschedule?

Colin Brough · Jul 1, 2025 go to post

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.

Colin Brough · Jul 1, 2025 go to post

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

Colin Brough · May 6, 2025 go to post

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.

Colin Brough · May 1, 2025 go to post

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, 2025 go to post

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</Desc…;
<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&gt;
</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, 2025 go to post

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 · Apr 10, 2025 go to post

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.

Colin Brough · Apr 10, 2025 go to post

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.

Colin Brough · Mar 26, 2025 go to post

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

Colin Brough · Mar 25, 2025 go to post

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, 2025 go to post

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 · Feb 25, 2025 go to post

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.
  

Colin Brough · Jan 29, 2025 go to post

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 · Jan 29, 2025 go to post

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.

Colin Brough · Jan 10, 2025 go to post

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.