go to post Jeffrey Drumm · Jul 24, 2024 You'll need to generate your own XML schema by importing either an xsd or wsdl. Once you've done that, you'll be able to use the schema in your DTL by selecting the Source or Target class as EnsLib.EDI.XML.Document, with the Document Type set to the name of your imported XML.
go to post 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
go to post 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.
go to post 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.
go to post 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.
go to post Jeffrey Drumm · Jul 18, 2024 The response from the Stored Procedure was not in the form of an object?
go to post Jeffrey Drumm · Jul 18, 2024 Also pointed out by others was not to have the Response object be anything other than Ens.Response. Any other type would cause an Orphaned message created even if you don't use it. Is this true even when the response object extends Ens.Response? That's a bit surprising ...
go to post 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.
go to post 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 ... ?
go to post Jeffrey Drumm · Jul 12, 2024 I'm pretty sure it's because a message header isn't created for an ACK, since (in most cases) it's not sent anywhere. They're tracked in Ens_Util.IOLogObj, and cleaned up from there if selected in the Message Purge task.
go to post Jeffrey Drumm · Jul 8, 2024 Yes, the process runs as the irisusr account, but does not have irisusr's environment, it has root's.
go to post Jeffrey Drumm · Jul 8, 2024 Great article, @Sylvain Guilbaud! One suggestion I would make is to configure the User value as irisusr (assuming that was the user specified at installation for stopping/starting IRIS). Otherwise IRIS obtains the root environment, which can have unexpected consequences.
go to post Jeffrey Drumm · Jul 4, 2024 Set From = "2024-07-04 13:21:16.477" Set To = $ZSTRIP($PIECE(From,".",1),"*P")
go to post 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.
go to post Jeffrey Drumm · Jul 4, 2024 The Connect() method returns a %Boolean, not an %Status. You should check the ReturnCode and ReturnMessage properties to determine why it's failing.
go to post Jeffrey Drumm · Jul 3, 2024 The new editor doesn't support that, at least yet. If you'd prefer to have the original rule editor launch when editing a rule, you can disable the new editor's web application /ui/interop/rule-editor through the Management Console via System Administration | Security | Applications | Web Applications.
go to post Jeffrey Drumm · Jun 12, 2024 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.
go to post Jeffrey Drumm · May 26, 2024 Looking through the HL7 2.5 OML_O21 structure as supplied by InterSystems, you'll find that there's a nested PIDgrpgrp() under ORCgrp().OBRgrp() that has a subordinate ORCgrp(). It looks like the parse is attempting to match on the required OBR segment in the nested PIDgrpgrp().ORCgrp(). You have a couple of options ... both of which require a custom schema to match your message. The first is to make the OBR segment in the PIDGrpgrp().ORCgrp() optional; the second is to remove the PIDgrpgrp() grouping entirely in the custom schema. EDIT: The first option doesn't work since the ORC matches on the optional ORC segment in the nested PIDgrpgrp.ORCgrp(), which makes it attempt to match on the required PIDgrpgrp.ORCgrp().OBXgrp().
