AllAccepted answers
Jeffrey Drumm · Aug 1, 2024

Or you could write a custom Business Process to do it. Here's an example with inadequate error processing (😉) that should give you some ideas:

/// Business Process to Modify the MSH:7 field
Class HICG.Sample.SetMSHDate Extends Ens.BusinessProcess [ ClassType = persistent ]
{
/// Downstream processes or operations to send messages to
Property TargetConfigNames As %String(MAXLEN = 1000);

Parameter SETTINGS = "TargetConfigNames:Basic:selector?multiSelect=1&context={Ens.ContextSearch/ProductionItems?targets=1&productionName=@productionId}";

/// Clone, modify and send the message downstream
Method OnRequest(pRequest As Ens.Request, Output pResponse As Ens.Response) As %Status
{
  Set tClone = pRequest.%ConstructClone()
  Set tCurDtTm = ##class(Ens.Rule.FunctionSet).CurrentDateTime("%Y%m%d%H%M%S")
  Do tClone.SetValueAt(tCurDtTm,"MSH:7")
  Do tClone.%Save()
  For i=1:1:$LENGTH(..TargetConfigNames,",") 
  {
    Set tSC = ..SendRequestAsync($PIECE(..TargetConfigNames,",",i),tClone,0)
    Return:$$$ISERR(tSC) tSC
  }
  Return $$$OK
}

/// Return an array of connections for drawing lines on the config diagram
ClassMethod OnGetConnections(Output pArray As %String, pItem As Ens.Config.Item)
{
    Do ##super(.pArray,pItem)
    If pItem.GetModifiedSetting("TargetConfigNames",.tValue) {
        For i=1:1:$LENGTH(tValue,",") { Set tOne=$ZSTRIP($P(tValue,",",i),"<>W")  Continue:""=tOne  Set pArray(tOne)="" }
    }
}
}

The reason you need to clone the inbound message is that Start-of-Session messages are immutable. You must clone them, modify the clone and send it.

Jeffrey Drumm · Jul 26, 2024

The code block action in a DTL is for writing arbitrary ObjectScript, not Javascript. It's commonly used for for data manipulation that can't be satisfied by the methods available in the FunctionSet; for example, extracting and decoding a base64-encoded PDF from an OBX:5.5 field and writing it to a file. It can also be used to interact with globals to maintain state between invocations of the DTL, or perform a database lookup, or even write values to the default device that will display in the Test tool. Very useful for debugging.

I would not recommend using it for operations that could potentially block. There's no built-in mechanism for setting a timeout so use a BPL for those cases.

Jeffrey Drumm · Jul 23, 2024

I came across this article when troubleshooting a connectivity issue with %Net.SSH.Session and needing to use a public/private key pair for authentication. For those that also end up here because they're unable to establish a session with an ssh-rsa key:

The SHA1 signing algorithm has been deprecated for a few years and is now disabled in the latest versions of many Linux flavors. That affects ssh-rsa, as it uses SHA1. You can enable SHA1 via /etc/crypto-policies/config on RHEL 9, but you probably shouldn't.

Fortunately, ed25519 is supported and can be used with %Net.SSH.Session. The default format for both the public and private keys works; no need to create the private key in PEM format (and you likely can't anyway since ssh-keygen ignores the -m directive with ed25519).

$ ssh-keygen -t ed25519

Jeffrey Drumm · Jul 23, 2024

The WRC recommended I try signing the key with ed25519, and that works without having to re-enable SHA1.

$ ssh-keygen -t ed25519

copy the id_ed25519.pub file from the .ssh directory to authorized_keys in the remote host's .ssh directory and make sure the permissions are set to 400 for ~/.ssh and the files within.

Jeffrey Drumm · Jul 23, 2024

So ... after trying a LOT of different options, I finally uncovered the issue. The version of %Net.SSH.Session() in the HealthConnect release I'm working with (2023.1.2) requires ssh-rsa to be enabled on the remote server. And ssh-rsa requires the deprecated SHA1 algorithm which is disabled on RHEL 9.

The workaround is to issue the following command as root:

[root ~]# update-crypto-policies --set DEFAULT:SHA1

I'm hoping there's an update that eliminates the need to do this; the WRC has been notified.

Jeffrey Drumm · Jul 22, 2024

Was there a resolution for this issue? I'm encountering the exact same error on RedHat Linux 9. I've verified that the public and private keys are in the correct formats and that the permissions are properly set for the files and directories. But AuthenticateWithKeyPair() generates the same error.

The same key pair work properly to initiate a ssh/scp/sftp session in the Linux shell. They're in the .ssh directory under the irisusr account, which is the account under which HealthConnect runs, $ZV IRIS for UNIX (Red Hat Enterprise Linux 9 for x86-64) 2023.1.2 (Build 450U) Mon Oct 16 2023 11:29:24 EDT.

Jeffrey Drumm · Jul 18, 2024

An option that can be performed without Studio, also nice! (You do need VS Code though)

And @Robert.Cemper1003's solution can be performed exclusively via the Management Console, which is also a great alternative.

I'm guessing that the WebSocket Terminal would also provide IRIS command shell access without an ssh session but I haven't played with that yet.

Jeffrey Drumm · Jul 16, 2024

I wrote a quick classmethod in my custom FunctionSet class to test your observation and found that I can use the full mnemonic property path name, for example:

ClassMethod GetControlID(pMsg As EnsLib.HL7.Message) As %String
{
    // Also works with "MSH:10"
    Return pMsg.GetValueAt("MSH:MessageControlID")
}

Example from a rule (I used Document, but HL7 also works):

And the resulting trace from the Visual Trace:

I'm thinking that your inbound messages might not have the DocCategory (ex. "2.3.1") and DocName (ex. "ADT_A01") properties set ... ?

Jeffrey Drumm · Jul 4, 2024

@Enrico.Parisi's observation is the most likely reason for the failure. You can obtain the credentials (assuming you've set them up in Interoperability | Configure | Credentials) with
 

Set tCreds = ##class(Ens.Config.Credentials).%OpenId(..Adapter.Credentials,,.tSC)
Return:$$$ISERR(tSC) tSC

The tCreds.Username and tCreds.Password properties are available on success.