Are you supplying a cache-control header in your response? 

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%'

I’m not sure why that nested structure exists. Is it standard for HL7 OML^O21? If it is, Intersystems should ideally provide a clearer error message to help us troubleshoot this more effectively.

It is part of the HL7 v2.4+ specification for the OML_O21 message structure. The nested segment group is for prior patient visit, order and observation data. 

When I run the message through Interoperability | Interoperate | HL7 v2.x | HL7 v2.x Message Viewer with the following options:

I get the following errors:

Segments required by the HL7 2.5 OML_O21 specification are not present and the message is failing to parse after the first ORC. You can create a custom Doc Category and DocType Structure to eliminate the required segment(s) and associate it with the OML_O21 message type (alternately, you can just assign the ORM_O01 Structure to the OML_O21 message type).

Then use that custom Doc Category as the Message Schema Category in the inbound service and Doc Category/Doc Type in your DTL.

Without seeing the source message, it will be difficult to provide a definitive answer. My guess would be that there are segments in the message that would normally appear in an OBRgrp (or sub-group) but no OBR segment is present.

Also ... your screenshot indicates that the target message type/trigger event is being set to OML^O21, not ORM^O01. This differs from the description.

06/06/2025 15:51:54.8081368 *********************
Input to Web client with SOAP action = http://xxxxxxx/msg/SendMessage

Shouldn't that be https?

And the Web Gateway doesn't have anything to do with outbound client requests.

There are (at least) two sets of credentials used in the web gateway: one to control access to the web gateway's configuration forms, and the other to authenticate the web gateway to an IRIS instance. Removing the Password entry from the [SYSTEM] section of CSP.ini will give you unauthenticated access to the web gateway's configuration, as long as you're either accessing it locally or are remote but have an IP address that matches the filter set for the System_Manager entry.

Once you have access to the management pages, you can then configure the gateway's credentials for connecting to IRIS in the Configuration | Server Access | [Select Server] | Edit Server page. The credentials entered in the Connection Security section must match the Web Gateway credentials in IRIS (usually user CSPSystem with whatever password was originally set at installation). If you don't have access to that password anymore, you can sign on via IRIS terminal, and in the %SYS namespace execute d ^SECURITY. Option 1, User Setup, allows you to change passwords for users, as long as your account has the necessary roles/permissions.

Back in the Web Gateway's configuration forms, you can add a password for access to its configuration in the Configuration | Default Parameters page.

docName is not the same as DocType Name. The former is the HL7 event (i.e. "ADT_A04") while the latter is the message structure associated with that event. Many events use the same structure, so there's not a 1-1 correspondence. For example, A01, A04, A05 and A08 messages all use the ADT_A01 DocType Name.

In your trace statements, you should use the "_" character for string concatenation, not the "&" character; that's the full-evaluation logical "AND" symbol. 

My guess at this point is that PV1:PatientClass is not equal to "E".

The paths you're using for trace and 2nd when condition don't look correct for the ISC-supplied 2.3 Document Category. I would expect to see HL7.{PV1:3.1} and HL7.{PV1:PatientClass} used with a 2.3 DocType Category and ADT_A01 DocType Name (used for A04s).

So I've created a custom message structure for stuffing PDFs extracted from HL7 messages into a COLD feed. I've been using %Stream.FileBinary as the object type for the stream property in the class. I hadn't given much thought to the fact that those streams might hang around after a message purge, so I went back and modified the class to use %Stream.TmpBinary. I mean, that seems to make sense, right?

Except that with %Stream.TmpBinary, the stream goes away as soon as the message leaves the business process, and no file gets written by the operation. Oops.

So I'm back to using %Stream.FileBinary ... I would hope that the Interoperability message purge task would "do the right thing" and delete the stream since the message object extends Ens.Request, but I suppose I should do some experimentin' 😉