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.

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

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.

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.

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.

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.

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

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

Odd. I just ran your exact query on IRIS for Health 2023.3 and it executed successfully.

The error message suggests that a macro isn't defined, specifically $$$vaDataSegName, which is found in EnsHL7.inc (among others). Since you're working specifically with HL7 messages I suspect that include file is not available to the namespace in which you're running the query.