On Ubuntu, check your /etc/apache2/apache2.conf file and verify that the csp Directory stanza contains a CSPFileTypes line with all of the required file extensions needed:

<Directory "/opt/webgateway/csp">
        CSPFileTypes csp cls zen cxw png jpg css gif svg js
        AllowOverride None
        Options MultiViews FollowSymLinks ExecCGI
        Require all granted
        <FilesMatch "\.(log|ini|pid|exe)$">
                Require all denied
        </FilesMatch>
</Directory>

Getting this error with SQL tools when connecting to IRIS 2025.1.1 via https. The customer I'm working with has an internal CA and its root/chain is in my trusted root certificate store. The ObjectScript extension doesn't appear to complain about it when using https for my server configurations, with or without NODE_TLS_REJECT_UNAUTHORIZED = 0 set in the environment.

From the SQL Tools error log:

Error t [RequestError]: Error: unable to verify the first certificate
at new t (c:\Users\Jeff.vscode\extensions\intersystems-community.sqltools-intersystems-driver-0.1.7\dist\ls\plugin.js:2:405571)
at U.callback (c:\Users\Jeff.vscode\extensions\intersystems-community.sqltools-intersystems-driver-0.1.7\dist\ls\plugin.js:2:407384)
at e.callback.t.callback [as _callback] (c:\Users\Jeff.vscode\extensions\intersystems-community.sqltools-intersystems-driver-0.1.7\dist\ls\plugin.js:2:406830)
at t._callback.t.callback.t.callback (c:\Users\Jeff.vscode\extensions\intersystems-community.sqltools-intersystems-driver-0.1.7\dist\ls\plugin.js:2:430662)
at U.emit (node:events:518:28)
at U.onRequestError (c:\Users\Jeff.vscode\extensions\intersystems-community.sqltools-intersystems-driver-0.1.7\dist\ls\plugin.js:2:439522)
at ClientRequest.emit (node:events:518:28)
at emitErrorEvent (node:_http_client:104:11)
at TLSSocket.socketErrorListener (node:_http_client:518:5)
at TLSSocket.emit (node:events:518:28)
at emitErrorNT (node:internal/streams/destroy:170:8)
at emitErrorCloseNT (node:internal/streams/destroy:129:3)
at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
cause: Error: unable to verify the first certificate
at TLSSocket.onConnectSecure (node:_tls_wrap:1679:34)
at TLSSocket.emit (node:events:518:28)
at TLSSocket._finishInit (node:_tls_wrap:1078:8)
at ssl.onhandshakedone (node:_tls_wrap:864:12) {
code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE'

A similar issue has been reported on GitHub, and I added the relevant stuff from above as a comment; the issue has been open since May and he developer hasn't responded. Just wondering if anyone else has experienced this and found a solution.

The Matches() method in the DTL and Routing Rule function list does not use regex syntax; it uses COS "?" pattern matching. The pattern you'd need for your specific example is "1A2N" for 1 alpha character followed by 2 digits.

There's also a ..RegexMatch() method for the DTL and Routing Rule editors in most modern versions of IRIS. That accepts most pcre regex patterns.

It's been my experience that the contents of the ACK message are not evaluated by any of the ReplyCodeActions. If you need to specifically suspend messages that are NAK'ed with this value in MSA:3, you'll need to create a custom operation and associated adapter (likely extending EnsLib.HL7.Operation.TCPOperation and EnsLib.HL7.Adapter.TCPOutboundAdapter respectively) that implements the NAK/Suspend logic.

There were a couple of solutions mentioned in my reply.

If you need to work with field values in the message, either for routing or transformation, you will need to create a custom schema that includes the Z segment (which you'll also need to create) and assign that Message Schema Category in the inbound interface.

And if you want to transform the message using the DTL Editor, you'll need to specify the custom Message Schema Category for the Source (and possibly Target, if the downstream application needs it) message.

Include the setting in the SETTINGS string, but prefix it with a dash (-) character:

Parameter SETTINGS = "-Whatever,DSN:Basic:selector?context={Ens.ContextSearch/DSNs},..."

EDIT: Was apparently typing that while you were reading the documentation 😁

And for competeness' sake, the actual documentation:

Adding and Removing Settings

While I love this idea (and have voted for it!) I think it would be ideal to generalize it into the concept of themes. I've elaborated on my reasoning in a comment on the idea @Yone Moreno Jiménez  posted in the Ideas Portal.

I'm wondering if it should be its own Idea, though ... but I don't want to "split the vote" if it interferes with Yone getting his accessibility issue addressed.

Also, one might be tempted to simply kill the ^Ens.Queue global.

Don't.

^Ens.Queue is used for other housekeeping tasks, and while killing it will absolutely remove all messages from visibility in the queue viewer, it won't change the message headers for those items from queued status to something else (like aborted or discarded). And it will very likely break other things that you really don't want to break.

Here's a short method you can place in a utility class that does what you want:

ClassMethod AbortAll() As %Status
{
    Set tSC = $$$OK
    Set tQry = ##class(%SQL.Statement).%New()
    Set tSC = tQry.%PrepareClassQuery("Ens.Queue","Enumerate")
    If $$$ISOK(tSC)
    {
        Set tRS = tQry.%Execute()
        While tRS.%Next()
        {
            Set tQueue = tRS.%Get("Name")
            Write !, "Aborting Queue "_tQueue
            Do ##class(Ens.Queue).AbortQueue(tQueue)
        }
    }
    Return tSC
}

Are the Cerner custom schemas shown in your SearchTable based on InterSystems-supplied schemas? Is it possible that you need to specify "fully qualified" paths to the values you wish to index, for example:

Class XXXX.HL7.RAD.SearchTable Extends EnsLib.HL7.SearchTable
{

XData SearchSpec [ XMLNamespace = "http://www.intersystems.com/EnsSearchTable" ]
{
<Items>
    <Item DocType="InteleRAD_2.5.1:ORU_R01" PropName="AccessionNo" >{PIDgrpgrp(1).ORCgrp(1).OBR:PlacerOrderNumber.EntityIdentifier}</Item>
    <Item DocType="2.5.1:ORU_R01" PropName="AccessionNo" >{PIDgrpgrp(1).ORCgrp(1).OBR:PlacerOrderNumber.EntityIdentifier}</Item>
    <Item DocType="2.5.1:ORM_O01" PropName="AccessionNo" >{PIDgrpgrp(1).ORCgrp(1).OBR:PlacerOrderNumber.EntityIdentifier}</Item>
</Items>
}

In a routing rule, temporary variables must be declared in the rule's general tab:

And in the rule proper, they must be prefixed with an "@" symbol wherever they're referenced:

The foreach as you've designed it will only set the values for tSendAbnormal and tSendNormal based on the contents of the last OBX segment in the message, since it keeps looping until it either hits the last segment or you've triggered a return based on a condition.

What, exactly, are your criteria for sending a message to the "Normal" transformation vs. the "Abnormal?" In a result message, some observations (OBX segments) may have abnormal flags while others won't. Would such a message qualify for both transformations?

An error that would cause a suspended message should appear in the operation's error log. That would also have the session ID and a link to a trace of the message.

You could also query via SQL for a message header that starts with the string "Resent" in the Description field; that's the resent copy of the message but it will include the original message ID following the word "Resent." It will have the same session ID as the source message and both will show up in the trace.

A sample query:

SELECT ID, MessageBodyId, TargetConfigName, TimeCreated, Description
  FROM Ens.MessageHeader
  WHERE
    ID >= (SELECT TOP 1 ID FROM Ens.MessageHeader WHERE TimeCreated >='2025-06-25 10:45:00.000' ORDER BY TimeCreated ASC)
    AND 
        ID <= (SELECT TOP 1 ID FROM Ens.MessageHeader WHERE TimeCreated <='2025-06-26 00:00:00.000' ORDER BY TimeCreated DESC)
    AND 
        TargetConfigName = 'To_Downstream_System'
    AND 
        Description LIKE 'Resent%'