I used Single-Session batch and used a business process/router to send only the Interchange DocType to the operation. The Group and Transaction sets within are referenced from the Interchange and are automatically re-assembled by the operation.

Ubuntu is worse in that respect, at least in my experience ... I run Ubuntu on a bunch of systems in my home office. Seems like every update requires a reboot. At least with Redhat you have more granular control over what updates are installed.

I don't personally see the need, and I think InterSystems has better things to spend their time on 😁

To use STARTTLS, you need to do the following:

1. Create a client SSL/TLS configuration in System Administration | Security | SSL/TLS Configurations
2. Set these properties of your smtp object:
   • Set smtp.SSLConfiguration = <name of configuration>
   • Set smtp.UseSTARTTLS = 1

I did:

Class OrdRes.VendorMDM Extends Ens.DataTransformDTL [ DependsOn = EnsLib.HL7.Message ]
{

Parameter IGNOREMISSINGSOURCE = 1;
Parameter REPORTERRORS = 1;
Parameter TREATEMPTYREPEATINGFIELDASNULL = 0;
XData DTL [ XMLNamespace = "http://www.intersystems.com/dtl" ]
{
<transform sourceClass='EnsLib.HL7.Message' targetClass='EnsLib.HL7.Message' sourceDocType='2.3:ORU_R01' targetDocType='2.5:MDM_T02' create='new' language='objectscript' >
<assign value='source.{MSH}' property='target.{MSH}' action='set' />
<assign value='"MDM"' property='target.{MSH:MessageType.MessageCode}' action='set' />
<assign value='"T02"' property='target.{MSH:MessageType.TriggerEvent}' action='set' />
<assign value='"2.5"' property='target.{MSH:VersionID.VersionID}' action='set' />
<assign value='source.{MSH:DateTimeofMessage}' property='target.{EVN:2}' action='set' />
<assign value='source.{PIDgrpgrp(1).PIDgrp.PID}' property='target.{PID}' action='set' />
<assign value='source.{PIDgrpgrp(1).PIDgrp.PV1grp.PV1}' property='target.{PV1}' action='set' />
<assign value='source.{PIDgrpgrp(1).ORCgrp(1).ORC}' property='target.{ORCgrp(1).ORC}' action='set' />
<assign value='source.{PIDgrpgrp(1).ORCgrp(1).OBR}' property='target.{ORCgrp(1).OBR}' action='set' />
<assign value='source.{PIDgrpgrp(1).ORCgrp(1).NTE()}' property='target.{ORCgrp(1).NTE()}' action='set' />
<assign value='"Endoscopy Image"' property='target.{TXA:DocumentType}' action='set' />
<assign value='"AU"' property='target.{TXA:DocumentCompletionStatus}' action='set' />
<assign value='"AV"' property='target.{TXA:DocumentAvailabilityStatus}' action='set' />
<foreach property='source.{PIDgrpgrp(1).ORCgrp(1).OBXgrp()}' key='k1' >
<assign value='source.{PIDgrpgrp(1).ORCgrp(1).OBXgrp(k1).OBX:SetIDOBX}' property='target.{OBXgrp(k1).OBX:SetIDOBX}' action='set' />
<assign value='source.{PIDgrpgrp(1).ORCgrp(1).OBXgrp(k1).OBX:ValueType}' property='target.{OBXgrp(k1).OBX:ValueType}' action='set' />
<assign value='source.{PIDgrpgrp(1).ORCgrp(1).OBXgrp(k1).OBX:ObservationIdentifier}' property='target.{OBXgrp(k1).OBX:ObservationIdentifier}' action='set' />
<assign value='source.{PIDgrpgrp(1).ORCgrp(1).OBXgrp(k1).OBX:ObservationSubID}' property='target.{OBXgrp(k1).OBX:ObservationSubID}' action='set' />
<assign value='source.{PIDgrpgrp(1).ORCgrp(1).OBXgrp(k1).OBX:Units.identifier}' property='target.{OBXgrp(k1).OBX:5.3}' action='set' />
<assign value='source.{PIDgrpgrp(1).ORCgrp(1).OBXgrp(k1).OBX:Units.identifier}' property='target.{OBXgrp(k1).OBX:5.4}' action='set' />
<if condition='source.{PIDgrpgrp(1).ORCgrp(1).OBXgrp(k1).OBX:SetIDOBX}' >
<true>
<code>
<![CDATA[ do source.GetFieldStreamRaw(.tStream,"PIDgrpgrp(1).ORCgrp(1).OBXgrp("_k1_").OBX:5(1).1",.tRem)
 //
 set tRem = "|PDF|||||F|"
 //
 // Store the stream to the appropriate target field
 do target.StoreFieldStreamRaw(tStream,"OBXgrp("_k1_").OBX:5(1).5",tRem)]]></code>
</true>
<false>
<assign value='source.{PIDgrpgrp(1).ORCgrp(1).OBXgrp(k1).OBX}' property='target.{OBXgrp(k1).OBX}' action='set' />
</false>
</if>
</foreach>
<assign value='source.{PID:18}' property='target.{TXA:12.3}' action='set' />
</transform>
}

}

Now, I used PDFs rather than BMPs, I'm a little OCD, so my output looks slightly different from yours. But it does work. Notice that I used the numeric syntax to reference OBX:5's components, though. There are no symbolic names for those components in HL7, but they're still recognized using the numeric syntax.

Also, I think one of the OBX:5 components should probably contain "Base64" since that's probably how OBX:5.5 is encoded.

Here's the output:

The "length" of the OBX segment is only relevant if you're attempting to treat it as a string. If you treat it as an object and use the GUI's copy rules (which leverage the EnsLib.HL7.Message and EnsLib.HL7.Segment classes' methods), those fields should be readily accessible.

As Linux user irisusr:

jeff@host:~$ sudo su - irisusr
irisusr@host:~$ /isc/iris/sys/bin/irisdb -s/isc/iris/sys/mgr

Node: host, Instance: IH

USER>!whoami
irisusr

USER>

That command does get me directly to an IRIS shell prompt when logged into Linux as a user with the same name as an IRIS user.

Yes, I can launch an IRIS Lite Terminal from VS Code.

@John Murray I don't get the cookie errors, but I still get this:

In my case, on Ubuntu, I get the same behavior but different errors in the console:

The network trace simply shows a continuous stream of GETs:

I ran into this problem as well, and I vaguely recalled that the passthrough file service has issues with multiple targets. So I went to the documentation and tried to find any reference to the need to ensure the operations were called synchronously and (initially) couldn't. So I went ahead and configured the services with Work and Archive directories and waited for something bad to happen.

And of course, something bad did happen.

I later found the file adapter documentation that provides a clear description of how the Work and Archive directories impact synchronous delivery. It seems to indicate that the Work directory is more likely to break sync than the Archive directory, and that you can have an Archive directory configured while still supporting sync as long as the Work directory is not configured.

I get a ModuleNotFoundError with

import Pygments

but not

import pygments

Everything else in the dependencies imports ok.

I normally have OS Auth enabled, but I also tried disabling it with the same result.

Oh yes, it finally settled down and worked normally, but it seemed to be spending a lot of time talking to the servers before displaying the package listing. The servers are on AWS and I'm connected via a VPN, but my connection is quite fast for a home office and I've never noticed that before.

I've also exited and relaunched VS Code since without any significant delay, so it must've been a one-off.

I upgraded to the new beta that uses the proposed apis (v2.12.9-beta.1), and when I reconnected to the server, it took quite some time (5-10 minutes) before I could get to work. Since then, performance has been normal. Is there some new feature that indexes classes/routines locally or something? I couldn't find anything in the usual logs that indicated what was going on.