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
}
I've found that a production whose components don't all fit in the current window can't be scrolled to see the items at the bottom unless you first click on the production name in the left column. Seems like a pointless extra step. At first I thought it was a Firefox issue but was able to replicate it in Chrome.
Alternately, a "Draft" mode that saves (but does not activate) work in progress when it times out.
Hi David, also think this is a great start to weaning oneself from Zen ... thanks!
Question: I see references to both zervice and zservice. Is that a typo?
Some Prefer Python
ObjectScript Saves My Bacon
Yes, I am $$$OK
And those message schema categories are configured in the services and operations that use that SearchTable? And, just as importantly, have always been there? It's not going to index messages that don't have those assigned in the message object's properties.
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>
}
What account is IRIS running under? Check Windows Task Manager | Details | User name column for the irisdb.exe task. It's that account's permissions that you're likely having issues with.
Great! I was a bit off on my comment regarding how the expressions in the foreach would be evaluated. Your rule should work as expected.
I will mention that having the "= 1" as part of the when evaluation is superfluous. 1 is true in the rule editor so these work just fine:
.png)
.png)
In a routing rule, temporary variables must be declared in the rule's general tab:
.png){kind=small}
And in the rule proper, they must be prefixed with an "@" symbol wherever they're referenced:
.png)
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?
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 assuming you mean one target field, since a segment in HL7 starts with a segment identifier like PID or PV1 and contains a string of fields separated by field delimiters (normally the "|" character).
If, for example, you want to copy the Patient First Name and Last Name separated by a space character into a single field, you could do this:
.png){kind=small}
The underscore character is the concatenation operator in IRIS, so the example is taking:
source.{PIDgrpgrp(1).PIDgrp.PID:PatientName(1).GivenName}, Concatenating it with a space character followed by source.{PIDgrpgrp(1).PIDgrp.PID:PatientName(1).FamilyName}, then storing it in target.{PIDgrpgrp(1).PIDgrp.PID:PatientName(1)}. This effectively replaces the entire field with just the patient's first and last name.
My example uses the HL7 2.5.1 schema; your field paths may be different based on the version of HL7 you're using.
OK, I'm pretty sure I found the problem.
Studio's default compiler flags are "cbk" and VS Code's were set to "cuk." I changed VS Code to match and it appears the issue is resolved.
EDIT: Weirdly, the tooltip text is not updated ...
EDIT 2: If the first line of the comment in the source contains HTML tags, the tooltip reverts to some earlier iteration of the comment (no idea where it's finding that). However, the popup is correct. Removing the tag(s) from the first line causes the tooltip to display the specified comment.
So ... if you want your tooltip to match the first comment line, make sure it has no HTML tags!
In VS Code, if I make a change to a comment in the class, compile, then look at the INT code via View Other, the change is not reflected in the INT code. It doesn't matter whether the text is added to the same comment line or a new line.
Source:
.png)
INT:
.png)
Interestingly, I can force the comment to update the popup if I remove the property from the class SETTINGS parameter, compile, re-add it, and compile again.
I continue to have issues with this functionality. While I did get my comments to show up as popup help text, I cannot edit them in the source and have those changes reflected in the popups.
I'll mention that I've been using VS Code for the development of this custom operation ...
Digging a bit deeper, I used IRIS Studio to open the class and look at the generated INT code. Interestingly, even though the code was compiled before opening it in Studio, the INT code did not reflect the change to the comment. When I recompiled in IRIS Studio, the INT code's popup text was updated as it should have been.
This appears to be a VS Code issue ... ?
OK, so ... mysteriously, it's now working.
A few of my comments were on multiple "///" prefixed lines, and I edited them to put them on a single comment line. Recompiled, and now the popup is popupulated ...
.png)
This comment had been previously marked as Correct, but it's not the solution to the issue.
Odd ... I'm doing the same. This is with Health Connect 2023.1 on Windows.
.png){kind=small}
.png)
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:
.png)
I get the following errors:
.png)
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.
@Robert Cemper pointed you in the right direction. However the USER namespace is not normally enabled for Interoperability. You can create your own database(s)/namespace(s) in the Management Console and they would default to being interoperability-enabled, or you can enable USER for Interoperability with the following command:
Do ##class(%EnsembleMgr).EnableNamespace("USER",1)The credentials entered at the Web Gateway login page are not related to any credentials stored in IRIS. They're controlled solely by the Username and Password entries in the [SYSTEM] section of CSP.ini. If those entries are deleted from CSP.ini, you should bypass the login page completely.
Note that if you're using a standalone web server on an IRIS installation that's been upgraded from an earlier version, there may be multiple CSP.ini files. For example, I work with an IRIS installation that has been upgraded many times and is now using a standalone web server; the original CSP.ini for the previously-included "private" web server is in the <install-dir>/sys/csp/bin/ folder, but the active CSP.ini is in /opt/webgateway/conf/.
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.
^Ens.AppData is the target of the $$$EnsStaticAppData macro, which is referenced in these classes:
Ens.Adapter.cls
Ens.Util.File.cls
EnsLib.EDI.EDIFACT.Operation.BatchStandard.cls
EnsLib.EDI.X12.Document.cls
EnsLib.EDI.X12.Operation.BatchStandard.cls
EnsLib.EDI.X12.Operation.FileOperation.cls
EnsLib.File.InboundAdapter.cls
EnsLib.FTP.InboundAdapter.cls
EnsLib.HL7.Operation.BatchStandard.cls
EnsLib.RecordMap.Operation.FileOperation.cls
EnsLib.SQL.InboundAdapter.cls
EnsLib.SQL.InboundProcAdapter.cls
EnsLib.SQL.Operation.GenericOperation.cls
EnsLib.SQL.Snapshot.cls
You can't specify a DocType Name in a routing rule, at least directly. By specifying the docName, you're both selecting the message by Message Type/Trigger Event and identifying the structure (DocType Name) that will be used to parse the message in the rule. If you look at the HL7 v2.3 DocType Category via the Management Console in Interoperability | Interoperate | HL7 v2.x | HL7 v2.x Message Structures | 2.3, then select the ADT_A04 Message Type, you'll see this:
.png)
This means that an A04 event will be evaluated/parsed using the structure defined for an A01; the DocType Name (Message Structure) is ADT_A01.
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).