In a Python Business Process, the expected entry point is on_request(self, request), not a custom method like ask(self, request). The Python API reference for BusinessProcess lists on_request, on_response, and on_complete as the key methods, and its example handles incoming messages in on_request. [1][2]

So if your Business Process currently contains something like:

class ChatProcess(BusinessProcess):
    def ask(self, request):
        ...

you should move that logic into:

class ChatProcess(BusinessProcess):
    def on_request(self, request):
        ...

The same issue applies to Python Business Operations: the documented handler is on_message(self, request). [1]

Your current pattern of sending from a service to a process synchronously is shown in the RAG example, but that example’s process code uses a custom ask() method, while the API reference for Python business processes defines on_request() as the method invoked for incoming requests. [3][1]

If you want to test Python business process logic more easily, the Python Gateway documentation also mentions a helper:

Note: isc.py.util.BPEmulator class is added to allow easy testing of Python Interoperability business processes. It can execute business process (python parts) in a current job. [4]

If after changing the method names you still have trouble, the available material here does not provide a more specific diagnosis of the exact error shown in your screenshot. [1][2]

Sources:

The returned material shows how to customize the HL7->SDA3 step and how SDA/FHIR mappings can be inspected, but it does not state that repeating elements preserve positional order across the standard HL7->SDA3->FHIR pipeline, nor does it document that an SDA list index such as source.Addresses() is guaranteed to match the original HL7 repetition index such as PID:11(n). [1][2][3][4][5][6]

What is documented is:

• If you use HS.Gateway.HL7.HL7ToSDA3, extending that class and adding custom handling is a supported customization approach. [1][2][3]
• Custom SDA data can be carried forward using CustomPairs, and when the target is FHIR, CustomPairs are mapped into a FHIR extension containing a Parameters resource. [4][5][6]
• The FHIR Annotations tool can be used to inspect mapping details, including field-to-field mappings, cardinality, whether a mapping appends to an existing target object, and whether it uses a subtransformation or class method. [4][5]

[!IMPORTANT]

Any persistent class such as HS.Registry.Patient must be recompiled after modifications are made to HS.Local.SDA3.PatientExtension. [1][2][3]

Because the available sources do not explicitly guarantee order preservation for repeating fields in the standard HL7->SDA3->FHIR transforms, it is not safe to conclude that tAddrIdx will always correspond to the same original PID.11 repetition based on these documents alone. [1][2][3][4][5][6]

If you need to verify the exact behavior for Patient address mappings, the documented way to investigate is to review the mapping details in FHIR Annotations, where you can inspect the specific SDA-to-FHIR mapping, cardinality, and technical mapping definition for the relevant fields. [4][5]

Sources:

The documents show that InterSystems creates a matching cached query only when two statements “differ only in their literal values,” with some additional exceptions. If a query does not match an existing cached query, a new cached query name is reserved and then assigned when prepare succeeds. [1][2][3]

They also show several cases where statements that look logically equivalent still generate separate cached queries, because cache matching is based on more than just the generated hash value you are looking at. In particular, the documentation explicitly says that some textual differences still produce separate cached queries, such as case-sensitive alias differences and other syntactic variations. [1][4][5][2][6][3]

So for your two statements, the reason two cached queries are created is that InterSystems is not treating them as the same cacheable statement just because the hash appears the same to you. The cache match rules are stricter than “same hash” and only guarantee reuse for queries that differ only by literal substitution, unless one of the separate-cache conditions applies. [1][2][3]

The documents do not explicitly state the rule for different casing of a column reference itself such as Name versus NamE, so they do not provide enough evidence to say exactly which internal comparison step causes your specific example to split into two cached queries. What can be said from the available material is that same hash value does not by itself mean the statements will share one cached query, and separate cached queries can still be generated for syntactic differences that do not change optimization. [1][2][3]

Sources:

For your first scenario, you can filter listing results by defining an additional filter on a measure. The documentation says that for a given measure, you can specify an extra filter that is added to the detail listing query, and records that do not meet that criterion are removed. This is configured in the measure definition as a Measure-Specific Listing Filter, where you set Operator and Value. For your case, if you want only students with marks greater than 82, you would use a measure based on the marks field and set the listing filter to > with value 82. [1][2]

The supported operators for this listing filter are <, <=, >, >=, <>, =, MAX, MIN. Also, the cube class supports this through the measure attributes listingFilterOperator and listingFilterValue. [1][2]

For filtering the pivot table itself by a measure value, the subject area must include a searchable measure. Then in the Analyzer you can use Filters → Advanced Options → Add Condition, select the measure from the end of the list, choose the operator, and enter the comparison value. The documentation gives the example of filtering all patients whose test score is 65 or higher. So for marks greater than 82, this approach applies if your marks measure is searchable. [3][2]

Note: The filter control is part of the Pivot Builder area, not part of the Pivot Preview area. This has two implications:

• When you save the pivot table, the Analyzer saves any selections in the filter control. When you next open the pivot table, the Analyzer redisplays the filter control as you saved it.

• The pivot table as seen in a dashboard is filtered as you saved it and does not include the filter control. (You use a separate mechanism to provide filters to users of your dashboards.) [3]

For your second scenario, the available documentation only states that if you drag a level such as Student Name into the Filters box or filter bar, the drop-down lets you select from the members of that level, with options such as All, selecting one or more members, excluding members, or choosing a range. It does not describe a way to make that level-based filter automatically show only the names currently visible in the listing table. [3]

The documentation does say that you can define a named filter, and that a named filter can be saved with the subject area and used in multiple pivot tables and in filter controls on dashboards. But the retrieved material does not provide a method for restricting a Student Name filter control so it only lists the five names currently shown in the table. [3]

So, based on the available material:

• To get only rows with marks greater than 82 in a listing, use a measure-specific listing filter on the marks measure, or use an advanced pivot filter on a searchable marks measure. [1][3][2]
• For a Student Name filter that only shows the currently displayed five names, the retrieved documentation does not provide a documented way to do that. [3]

Sources:

No. SUPPORT_DELIMITED_IDENTIFIERS can only be set system-wide, not for just the current session. The documentation states that this option “allows you to change support for delimited identifiers system-wide” and that “once set, this option takes effect system-wide for all processes.” [1]

You can change it with either:

• SET OPTION SUPPORT_DELIMITED_IDENTIFIERS = TRUE|FALSE
• $SYSTEM.SQL.Util.SetOption() using the DelimitedIdentifiers option [1][2][3]

You can check the current setting with:

• $SYSTEM.SQL.CurrentSettings() [1][2][3]

By contrast, the same SET OPTION page explicitly says that locale options apply “for the current process,” which highlights that SUPPORT_DELIMITED_IDENTIFIERS is not a session/process-level option. [1]

Note:

Delimited identifiers are required by other features of InterSystems IRIS, such as InterSystems IRIS Business Intelligence. As such, take care when disabling them to ensure that other parts of your configuration are not affected. [2]

Sources:

Yes, a license server can manage key files stored in a central location and distribute them to other InterSystems IRIS instances. In that model, each instance must be configured with the LicenseID of the key file so it can retrieve a copy of the key at startup. The key files can be loaded from a central directory using the KeyDirectory property of Config.LicenseServers; when this is set, the instance that starts the license server reads valid *.key files from that directory at startup and sends them to the license server. [1][2][3][4]

At the same time, each InterSystems IRIS instance must also have a local copy of the authorizing license key file installed. [1][2][3]

The license server can run on any computer where you run an InterSystems IRIS instance, and one license server can handle multiple instances. [1][2][3]

Important: InterSystems Terms and Conditions govern how you may use the licensed InterSystems IRIS software. Occasionally, the implementation may be more lenient. Verify that any license-related code you write conforms to these terms and conditions. [1]

Note: Loading a new key with the same LicenseID as an existing key in the license server key tables marks the existing key as replaced. Requests from instances for that LicenseID receive the most recently loaded key. You can use the existing $System.License.DumpKeys() method to view the current state of keys in the license server. [1]

Sources:

You can use built-in InterSystems pages for a basic dashboard, but the available information in the retrieved sources points to two different built-in views depending on what you want to show:

1. For listing and visualizing message routes/interfaces inside a production, use Interoperability > View > Interface Maps. It lists all the routes a message can take within a production in tabular form, and you can click a row to see a visual representation of that route. It also supports exporting results to .csv, .txt, .xml, or .html. The columns described are Service, Process, Rule, Transformation, and Operation. [1]

2. For operational status monitoring of production components, use the built-in production monitoring pages. The Production Configuration page shows the business hosts in the production with color-coded status indicators, and the production monitor includes status-oriented tables such as outgoing connections, queues, and event log summaries. For outgoing connections, the table includes:

   • business operation status
   • business operation connection status
   • business operation name
   • number of messages processed since the production started [2]

If your immediate goal is a simple internal dashboard, the built-in options from the retrieved sources are:

• Interface Maps for listing and visualizing interfaces/routes in a production [1]
• Production Configuration / Production Monitor for component status and monitoring-oriented information [2]

The retrieved sources do confirm built-in status information such as:

• status color/state for business operations: Active/OK, inactive, error, disabled, retry [2]
• connection status for TCP/HTTP/FTP/ODBC-style connections: connected, listening, disconnected, or not applicable [2]
• processed message counts since production start in the outgoing connections table [2]

The sources do not provide a built-in feature specifically described as a dashboard combining all of the fields you listed together in one place, such as:

• Interface Name
• Current Status
• Last message processed timestamp
• IP and Port
• Server / Instance / Production environment name

They also do not provide precompiled code from product documentation for such a combined custom dashboard. However, one retrieved community/Open Exchange result describes a custom Production Monitor package that can be installed with ZPM: zpm "install production-monitor" and presents it as a custom monitoring app for productions. [3]

[!NOTE]

The Jobs tab lists only the latest 100 jobs. [2]

So the most evidence-based suggestion from the retrieved material is:

• start with Interface Maps if you want route inventory and visualization [1]
• use Production Monitor / Production Configuration for current status monitoring [2]
• if you want a more customized dashboard, review the community package production-monitor as a starting point [3]

If you want, I can help you map your requested fields one by one against what these built-in pages already expose. [1][2][3]

Sources:

The material I found suggests the issue is likely with how the XML parameter is being bound when calling SQL Server from EnsLib.SQL.OutboundAdapter, rather than with the stored procedure itself. In a related Ensemble/SQL Server parameterized call, passing complex text worked when the SQL parameter type was treated as VARCHAR(8000), but failed for NVARCHAR(MAX) and NVARCHAR(8000). A suggested workaround was to call the procedure using the parameter-array form and explicitly set the parameter SQL type to VARCHAR, for example: Set tParams(1)=xmlContent and Set tParams(1,"SqlType")=$$$SqlVarchar, then use ExecuteProcedureParmArray(...). [1][2]

Your XML payload also appears malformed in the example you posted: the CDATA contains <TESTxmlns='http://tempuri.org/ICMPDSv3_1.xsd'>, which has no space between the element name and the xmlns attribute. That means the opening tag shown is not well-formed XML as written. [3]

The procedure definition you posted has 7 parameters total, with 5 input parameters and 2 output parameters (@LogComment and @Alert). Your request object shows numberofparams as 5 while the SQL call text is { call dbo.PopulateDataTable(?,?,?,?,?,?,?) }, so you should make sure the outbound call is supplying the parameters in a way that matches the procedure signature, especially if output parameters are involved. [3]

A practical adjustment based on the retrieved material is to:

1. Ensure the XML string itself is well-formed.
2. Pass the XML as a parameter array element rather than inline text.
3. Explicitly set that parameter’s SQL type to VARCHAR in the adapter call. [3][1][2]

Example pattern from the retrieved discussion:

set tQuery="{ CALL dbo.SavePatientDetails (?) }"
set tParams=1
set tParams(1)=xmlContent
set tParams(1,"SqlType")=$$$SqlVarchar  ; or 12 if macro does not resolve
set tSC = ..Adapter.ExecuteProcedureP...

[1][2]

If you continue using your current request wrapper, also verify that the parameter count and positions match the stored procedure definition exactly. [3]

Sources:

From the available material, the main point is this:

• TUNE TABLE always updates the SQL table definition.
• It also commonly updates the corresponding persistent class definition.
• The reason given is that this lets the query optimizer use the gathered statistics without requiring a class compilation.
• If the class is deployed, TUNE TABLE updates only the SQL table definition, and the optimizer uses the gathered statistics indirectly from the table definition. [1]

So, to your first concern: the documents do not describe this as a harmful inconsistency if one run updates the class and a later run does not. They only state that the SQL table definition is updated, and that class update is common but not always done; for deployed classes, only the SQL table definition is updated and the optimizer still uses the statistics. That indicates the optimizer can work from the SQL table definition even when the class is not updated. [1]

On recompiling the class, the documents only explicitly say:

• when TUNE TABLE changes values, it may flag the table’s class definition for recompile;
• updating the class definition allows the optimizer to use the statistics without requiring compilation;
• if the class is deployed, the optimizer can use the table definition instead. [1]

They do not explicitly say whether a later class compile will overwrite SQL table-definition statistics, or which side “wins” after recompilation. So I can’t confirm that part from the provided sources. [1]

About the purpose of “class update”, one relevant explanation from the retrieved material is that table statistics are stored as part of the class definition, based on the idea that they are often relatively static and belong with the application. One comment also notes that this means stats can be lost if a system library is overwritten during upgrade, which supports your understanding that class update is related to keeping/exporting those statistics with the class/application definition. [2]

Also relevant:

• %CLEAR_VALUES clears existing SELECTIVITY, EXTENTSIZE, and similar values from both the class and table definition. [1]
• Running TUNE TABLE recompiles existing cached queries for the specified table to use the new Tune Table values, unless no values changed. [1]

So the safest summary is:

1. Updating the class is useful because it makes the gathered stats available through the class metadata and avoids needing class compilation for optimizer use. [1]
2. Not updating the class does not mean the optimizer cannot use the stats, because the SQL table definition is still updated, and this is explicitly how deployed classes work. [1]
3. The sources do not explicitly answer whether recompiling the class later overwrites SQL-definition stats, so that specific overwrite behavior is not confirmed here. [1]
4. Yes, one documented use of class update is effectively to keep the statistics with the class/application metadata, which aligns with export/deployment scenarios. [2]

If you want, I can help restate this as a practical recommendation for when to use class update in dev, test, and production.

Sources:

What you are seeing is consistent with browser cookie policy rather than an IRIS header-access issue. InterSystems IRIS lets you control cookie behavior for the web application, including whether cookies are used for session management and the default SameSite handling, but the documentation explicitly states that when SameSite=None is used for cross-site requests, browsers may require HTTPS. [1][2][3][4]

For your IRIS web application, the relevant settings are under the application’s Session Settings:

• Use Cookie for Session controls whether session tracking uses cookies, with options Always, Never, or Autodetect. [1]
• Session Cookie Scope controls the default SameSite value for session, login, CSRF, and Group ID cookies. [1]
• User Cookie Scope controls the default SameSite value for user-defined cookies created with %CSP.Response.SetCookie. [1]

If your Angular/Ionic app running in the browser is making a cross-site request to the IRIS server, then using SameSite=None is the setting associated with allowing cookies on cross-site requests. But the documentation says browsers may require HTTPS for that case, so there is not a documented IRIS-side way to make browsers accept that cookie over non-HTTPS remote access. [1][2][3][4]

Your localhost behavior versus remote test server behavior also fits that distinction: the issue is not that JavaScript cannot read Set-Cookie, but that the browser may refuse to store/send the cookie under cross-site, non-HTTPS conditions. Postman working does not contradict this, because the cited IRIS documentation here is specifically about browser session/cookie behavior for web applications. [1][2][3][4]

Important: To use these settings, you must first set the UseSession parameter of the application’s dispatch class to a non-zero value; otherwise, changes in the value of any of these settings have no effect. For more information, see Creating a REST Service Manually. [1]

The one documented workaround within IRIS session configuration is to avoid cookies entirely for session tracking by setting Use Cookie for Session to Never, which switches session management to URL rewriting instead of cookies. Whether that is practical for your REST/browser flow is not described in the retrieved material, so I cannot say more than that. [1]

So the direct answer is: there is no documented way in the retrieved IRIS material to force a browser to accept a cross-site Set-Cookie on a non-HTTPS remote environment. The documented guidance indicates that for SameSite=None, browsers may require HTTPS, so enabling HTTPS is the supported path. [1][2][3][4]

Sources:

For a BPL business process, the documented practice is to use BPL’s own error-handling model: define <scope> blocks with <faulthandlers>, and use <catch> for specific named faults or <catchall> for anything not specifically matched. When a fault is thrown, control passes to the matching fault handler in that scope; if no specific <catch> matches and a <catchall> exists, the <catchall> is used. [1][2][3][4]

If you are deciding between “Try/Catch inside the BPL” and native BPL handling, the material here points to BPL fault handlers for BPL processes rather than ObjectScript TRY/CATCH as the mechanism described for BPL itself. It also states that error handling in a BPL business process happens automatically, without needing to test or set the status value in normal BPL source code. [5][6][7][8][9]

If your process needs to stop with an error in a controlled way, the documented way is to set status to a failure value. When status acquires a failure value, InterSystems IRIS immediately terminates the business process and writes the corresponding text message to the Event Log. The documentation explicitly says this is the best way to cause a BPL business process to exit immediately, but gracefully. Also, a <call> automatically places the returned %Status into status, so failures from downstream business hosts propagate automatically into the BPL. [6][7][8][9]

For unexpected errors, you should not rely only on automatic logging if you have defined <faulthandlers>. The documentation explains that when scopes include <faulthandlers>, InterSystems IRIS does not automatically output the system error to the Event Log the same way it does when there is no scope/fault handling. In that case, it is up to the BPL developer to emit <trace> messages for unexpected errors. [1][2][3][4]

So, from the sources available here, good practice is:

• structure error-prone sections inside <scope> blocks
• handle known business faults with specific <catch>
• include <catchall> for unexpected cases
• use status failure when you want the process to terminate gracefully
• add <trace> output in fault handlers so unexpected errors are visible in the Event Log [1][2][3][4][6][7][8][9]

Note: If a is provided, it must be the last statement in the block. All blocks must appear before . [1][2][3][4]

Note: Error handling for a BPL business process happens automatically without your ever needing to test or set the status value in the BPL source code. The status value is documented here in case you need to trigger a BPL business process to exit under certain special conditions. [6][7][8][9]

Caution: Like all other execution context variable names, status is a reserved word in BPL. Do not use it except as [6][7][8][9]

The retrieved documents do not provide guidance that the built-in Production retry mechanism should be the primary or recommended general strategy for handling errors inside a Business Process, and they do not describe returning an error response to the caller as the general best practice. The guidance present is centered on BPL fault handlers, automatic %Status propagation, graceful termination via status, and explicit tracing/logging in fault handlers. [1][2][3][4][6][7][8][9]

Sources:

You can get it from the rule execution context by using the effective end value passed into the generated rule evaluation code. One example of the generated routine shows these output variables being set during rule evaluation, including pEffectiveEnd, which represents the ruleset effective end value. [1]

If you need to use that value inside a when condition, the supported approach shown in the related rule discussions is to expose logic through a custom function class that extends Ens.Rule.FunctionSet, and call that function from the rule condition. [2][3][4]

A practical approach is therefore:

1. Create a custom function in a class extending Ens.Rule.FunctionSet. [2][3][4]
2. Pass in the rule context or otherwise access the execution state from that function. [3]
3. Use the effective end value associated with the executing ruleset there, rather than trying to reference the parent ruleset metadata directly inside the raw when expression. [1]

One related example also notes that rule definitions are stored as XML in the RuleDefinition XData and can be loaded programmatically with Ens.Rule.Model.ruleDefinition, so if your requirement is to inspect ruleset metadata structurally, that can be done outside normal rule-condition evaluation. [5]

Warning: This is not standard use or best practice, and I'm not recommending you do this - as it will effectively negate the rules sets with effective periods feature. which in the future, you may want to use. [6]

Sources:

If the TLS configuration is a client configuration and Server certificate verification is set to Require, the connection is supposed to continue only if certificate verification succeeds. If verification does not succeed, the connection should not continue. [1]

The trusted CA file you specify is the file used to verify the peer certificate: “The configuration uses the certificates of the trusted CA(s) to verify peer certificates.” So if that file is wrong, missing, or otherwise unusable, that directly affects peer-certificate verification. [1]

The material also states that an expired certificate prevents establishing a TLS connection: “Once a certificate expires, you will no longer be able to establish a TLS connection with it.” [2]

So from the available documentation, the expected behavior is that traffic should not continue when verification is required and the server certificate cannot be successfully verified. [1][2]

If your interface has still been working for years, the returned documents do not explain that specific discrepancy. The only closely related comment in the retrieved material says that for some setups, “Server certificate verification” is typically set to “None”, and if it is set to “Require” it can cause rejection/failure, but that is a community comment rather than formal product documentation. [3]

Note: If the private key is password-protected and you do not enter a value here, InterSystems IRIS cannot confirm that the private key and the certificate’s public key match each other; this can result in mismatched keys being saved as a key pair. [1]

Note: The required fields vary, depending on whether the configuration is to be a client or server and on the desired features. Not all fields are required for all TLS configurations. [1]

Note: The Test button may not be able to successfully connect with all TLS servers, even if the configuration has no errors. When testing, the connection attempt performs a TLS handshake followed by an HTTP request. Tests may fail when the target server does not expect to immediately make a TLS handshake connection. [1]

Sources:

The available documentation says that webgateway containers already include a web server preconfigured with a Web Gateway extension, and that in a containerized deployment you should automate web server configuration by amending the web server configuration programmatically within the image’s Dockerfile or by describing it in the container cluster YAML. It does not describe a supported mechanism for adding extra nginx modules to the webgateway-nginx container. [1]

The nginx build guidance for the Web Gateway shows that nginx module support depends on how nginx itself is built. The documented build examples include options such as --with-http_ssl_module, and note that the build process can be changed to include or exclude optional nginx capabilities by changing the configure arguments. That indicates module availability is determined at nginx build time rather than by a Web Gateway setting. [2]

The webgateway-nginx:latest-em example shows the image’s nginx was built with these configure arguments:

--prefix=/opt/nginx --with-pcre=/opt/pcre-src --with-zlib=/opt/zlib-src --with-openssl=/opt/openssl-src --with-http_gunzip_module --with-http_ssl_module --with-http_v2_module --add-module=/opt/nginx-src/csp

sub_filter is not listed there, which is consistent with nginx reporting unknown directive sub_filter. [3]

So, based on the returned material, the practical conclusion is that you would need a custom-built nginx image if you require additional nginx modules such as sub_filter, and container customization should be done in the image Dockerfile or deployment YAML. The provided documents do not give a supported step-by-step process for rebuilding the InterSystems webgateway-nginx container with extra nginx modules. [1][2][3]

Important: Use of the Universal Modules with Nginx has been deprecated due to stability issues. Deployments of the Web Gateway which connect to Nginx using the NSD fully support all features, including WebSockets. [2]

If you are currently using the Universal Modules with Nginx, InterSystems recommends upgrading to the most recent version of the Web Gateway and rebuilding your Nginx server to work with the NSD. Be sure to remove the CSPModulePath directive from your server configuration when you edit the server configuration file. [2]

This means if you decide to build your own nginx-based solution, the documented recommendation is to use the NSD-based Web Gateway approach rather than the deprecated Universal Modules approach. [2]

Sources:

IRIS does not automatically “activate” a Python virtual environment for Embedded Python. The material found describes two supported patterns instead:

1. install packages into the IRIS mgr/python folder with pip --target, or
2. use a virtual environment and explicitly add that venv’s site-packages directory to sys.path before importing modules. [1]

For a virtual environment, the documented example is to append the venv site-packages path in ObjectScript, then import the package, for example: [1]

set sys = ##class(%SYS.Python).Import("sys")
do sys.path.append("/where/you/want/your/venv/lib/pythonX.X/site-packages")
set requests = ##class(%SYS.Python).Import("requests")

So, setting IRIS_PYTHON_PATH=/usr/irissys/.venv/bin/ in docker-compose.yml is not described in the retrieved material as the way to make Embedded Python find packages from a virtual environment. The retrieved material specifically points to adding the site-packages directory to sys.path, not the venv bin directory. [1]

If you want the packages to be available without managing a venv path, the retrieved material suggests installing them directly into the IRIS Python module location with pip --target=/path/to/your/iris/mgr/python .... [1]

The dev template material also states that it is “embedded python compatible” and that “all modules in requirements.txt will be installed during docker build,” but it does not provide additional details here about using IRIS_PYTHON_PATH to activate a venv for all IRIS execution. [2]

Sources:

The portal can display message body details only when the message body is a standard production message body object. If the message body is “any other type,” the Body tab has no additional fields. [1]

The Contents tab can display formatted contents of the message body, for example XML for standard production messages or segment-based output for virtual documents. It also supports View Full Contents and View Raw Contents for those message types. [1]

For stream-based messages, the retrieved material does not describe a portal feature that directly renders arbitrary %Stream properties or %Status values in the Message Viewer. One returned example specifically describes a request/response message class containing only a %GlobalCharacterStream property where the Ensemble Message Viewer shows the stream content as blank. [2]

For %Status, the returned material only states that methods such as SendRequestSync(), SendRequestAsync(), and SendDeferredResponse() return a status value of type %Status, and that code can check or display that status programmatically. [3][4][5][6]

To read stream content programmatically, the documents show using stream methods such as Read(), ReadLine(), Rewind(), Write(), WriteLine(), MoveToEnd(), and Clear(). For HTTP responses, the response body is in %Net.HttpResponse.Data, which is a %GlobalBinaryStream. [7][8][9][10]

So based on the retrieved documents, there is no documented way here to read STREAM or STATUS messages directly in the portal in the same way as standard message contents. The available guidance is to access those values in code rather than through the portal viewer. [2][7][1]

Sources:

If the remote system sends back an HL7 reply that is not a “simple OK ACK message,” then IndexNotOKs is consistent with the documented purpose of the setting: it saves replies that are not simple OK ACKs and indexes them. That includes things like error NACKs and query responses. IndexNotOKs is also the documented default behavior for HL7 business services unless deprecated parameters were overridden. [1]

For the specific behavior you are seeing with malformed replies, there is relevant guidance from the retrieved material: if an ACK received from an external system does not match a schema, it can be stored but not create a Message Header or entry in the IOLog, which is one of the cited causes of orphaned HL7 messages. That matches your observation of orphan ACK/NCK traffic when the vendor sends back something like A08 instead of ACK. [2]

The same retrieved material states that for this schema-mismatch case, the solution is to correct the schema for the ACK. [2]

So based on the documents, the answer is:

• Yes, IndexNotOKs makes sense if your goal is to retain and index replies that are not simple OK ACKs, including problematic replies you may want to investigate. [1]
• No document retrieved says that IndexNotOKs itself fixes malformed vendor ACKs or prevents orphaning. The orphaning behavior described is tied to replies that do not match schema. [2]
• The documented remediation for malformed ACKs that do not match schema is to correct the schema for those ACKs. [2]

The available documentation does not provide guidance on “what others have done” as a best-practice recommendation beyond those points. It does, however, identify two ACK-related orphan scenarios:

1. Negative ACKs processed as Completed by Reply Action Codes can be stored without creating a Message Header or IOLog entry. [2]
2. ACKs that do not match schema can also be stored without creating a Message Header or IOLog entry. [2]

If you want, I can help you turn this into a concrete configuration review checklist focused only on the settings mentioned in the retrieved material, such as Save Replies, Ack Mode, Get Reply, and Reply Code Actions.

Sources:

Using OAuth 2.0 is the supported direction here. InterSystems provides OAuth 2.0 client capabilities, and an OAuth client application can be configured with authorization server metadata such as authorization_endpoint, token_endpoint, jwks_uri, supported response types, and TLS/SSL configuration, which is the kind of setup you would need when integrating with an external identity provider such as Microsoft/Azure Entra ID. [1][2]

InterSystems also documents how an OAuth 2.0 client can use a custom login flow by subclassing %OAuth2.Login, defining the application name, scopes, response mode, and additional request properties for the token request. That is the documented framework for building an OAuth-based client flow on the InterSystems side. [3]

For Microsoft specifically, there is a community example discussing OAuth2 with Microsoft. It confirms that people are using InterSystems OAuth client configuration together with Azure registration, including registering the redirect URI in Azure and enabling the /csp/sys/oauth2 web application. It also recommends enabling relevant logging to troubleshoot issues in the flow. [4]

For mail specifically, a community discussion shows that InterSystems mail-related classes can use an OAuth access token once you have acquired one. In that discussion, %Net.POP3.Connect() is noted to have an AccessToken parameter, and a custom adapter example shows obtaining a token externally, storing it, and then passing it into ConnectPort(...,AccessToken). The same discussion states that “The lack on intersystems is to aquire an access token,” while %Net.POP3 already implements the protocol side expected by Microsoft once the token is available. [5][6]

A sample approach shared there uses embedded Python based on mutt_oauth2.py to:

• generate an authorization URL,
• obtain an authorization code from Microsoft,
• exchange that for the first access token,
• store token details in a global,
• and then reuse/refresh the token for mail access. [5][6]

The sample methods shown are:

• askAuthorization(...) to generate the browser URL for authentication,
• doAuthorization(...) to exchange the authorization code,
• getAccessToken(...) to retrieve a saved token,
• and then passing that token to ConnectPort(...). [5][6]

So, based on the retrieved material, the best documented approach is:

1. Move from Basic Authentication to OAuth 2.0. [1][2]
2. Register your application in Azure Entra ID and configure the InterSystems OAuth client/redirect handling. [4]
3. Acquire and manage the Microsoft access token outside the mail adapter if needed, for example with custom code or embedded Python. [5][6]
4. Pass the access token into the mail connection method rather than relying on Basic Authentication. [5][6]

I did not find a complete official sample specifically for “triggering an email alert from Caché using Azure Entra ID SMTP,” but I did find a community sample pattern for Microsoft mail OAuth token acquisition and use with InterSystems mail connectivity. [5][6]

Sources:

Commonly recommended strategies in InterSystems IRIS are to use built-in auditing for key security and system events, add application-level audit events for business actions, and avoid trying to audit every low-level database operation because of volume and performance impact. InterSystems IRIS supports both system audit events and user-defined audit events, and specifically notes that database inserts, updates, and deletes are not automatically audited because that can generate excessive entries; instead, it is more efficient for the application to create a single meaningful audit entry for events such as patient-record access. This is especially relevant in enterprise and healthcare environments where you want traceable user activity without overwhelming the system. [1]

For tracking user activity and maintaining compliance, the built-in audit facility is the main tool. It can capture events occurring inside InterSystems IRIS and in applications, and documented examples of built-in events include startup, shutdown, logins, security-setting changes, audit-setting changes, and interoperability-related configuration or schema changes. A separate security article also states that auditing can be used to track login attempts, permission changes, and sensitive data access, and that audit events are stored in the dedicated IRISAUDIT database and can be viewed in the Management Portal under System Administration > Security > Auditing > View Audit Database. [1][2]

For troubleshooting issues and monitoring integrations, interoperability-related events can be audited, including changes to a production configuration or schema. In addition, one source recommends using production trace for Web Services, and says API activity can be monitored through the IRIS API Admin Portal, while Web Services and Database activity can be monitored through the Management Portal. [1][3]

For enterprise monitoring and external integrations, InterSystems IRIS supports structured logging as an alternative output for the same audit messages, writing them to a machine-readable file that can be ingested by a monitoring tool. It also supports transmitting audit database events as OTLP/HTTP signals when using a monitoring tool compatible with OpenTelemetry. This makes built-in auditing suitable for integration with external observability platforms. [1]

Built-in monitoring tools specifically mentioned are Diagnostic Report, Log Monitor, and System Monitor. One source also recommends SAM (System Alerting and Monitoring) as an additional tool for alerts and cluster-wide monitoring, and describes it as being based on Grafana, AlertManager, and Prometheus. [3]

If you want to manage audit events programmatically rather than only through the Management Portal, the documented class to use is Security.Events. [1]

Practical recommendations explicitly called out include enabling and reviewing the audit events you need, monitoring LoginFailure events to detect unauthorized access attempts, reviewing audit logs regularly, and setting automated alerts for suspicious activity. [2]

Note: This document describes how to manage audit events with the Management Portal. To manage audit events programmatically, use the Security.Events class. [1]

Sources:

For improving interoperability performance in InterSystems IRIS, the returned material recommends focusing on production configuration, monitoring, purging, and tuning of system resources used by message processing. [1][2][3][4]

For productions and message throughput, the recommendations explicitly include adjusting pool sizes and buffer settings based on production volume, and monitoring for queue build-ups and interface outages. It also recommends configuring Ens.Alert to notify on those conditions and setting up automated message purging to control database growth. These points are directly tied to go-live and ongoing production performance management. [1]

For business services and operations, the material highlights correct adapter and component configuration: configure business services such as TCP, HTTP, and File services with the correct port or path, and configure adapters such as TCPInboundAdapter or HTTPInboundAdapter with appropriate framing such as MLLP. It also recommends using the built-in HL7 Testing Tool for sending sample messages, Visual Trace to inspect message flow including transformations and ACKs, and the Event Log to monitor adapter errors, timeout issues, and DTL exceptions. [1]

For monitoring and troubleshooting in production environments, the returned sources name these tools and approaches:

• Visual Trace for inspecting each step of a message flow and validating transformations and acknowledgments. [1]
• Event Log for adapter errors, timeout issues, and DTL exceptions. [1]
• ^PROFILE and ^TRACE to identify performance bottlenecks. [3]
• %SYS.MONLBL, ^PROFILE, and ^TRACE as available development and performance-analysis tools. [4]

For handling high volumes and backend performance factors, the material recommends:

• Separating file systems for installation files, database files, the primary journal directory, and the alternate journal directory to improve performance and recoverability. [2]
• Using direct or concurrent I/O for journal files to bypass the operating system cache, and direct I/O for database files because InterSystems IRIS uses its own database cache. [2]
• Monitoring journal growth and profiling journal files to determine which globals are driving growth. [2]
• Keeping average journal sync write response time at or below 0.5 ms, with a maximum of 1 ms, especially for scalability-sensitive deployments. [2]

For broader application-level optimization that can also benefit interoperability-related processing logic, the returned material recommends:

• Verifying SQL performance with the SQL Query Optimizer and query plan. [3]
• Using efficient global access patterns such as $ORDER and $DATA. [3]
• Preferring bulk operations over single-row processing when working with large datasets. [3]
• Ensuring persistent classes have appropriate indices for query requirements. [3]
• Identifying opportunities for asynchronous processing to improve responsiveness. [3]

For architecture and scaling considerations, the documents suggest evaluating whether Mirroring, Sharding, or ECP are needed based on scale requirements, and they also mention high-availability configuration for critical hospital interfaces. [3][1]

If your workload includes ObjectScript-level copying of large structures, the documentation notes a specific performance characteristic of MERGE (synonym: m): it can take longer than most other ObjectScript commands, is not atomic, and is more prone to interruption, which may matter in concurrent or high-volume processing scenarios. [5]

Important: MERGE is not an atomic operation. [5]

A practical production checklist from the returned material would be:

1. Configure services and adapters correctly for the transport and framing in use, such as MLLP for HL7. [1]
2. Monitor Visual Trace, Event Log, and queue build-ups continuously. [1]
3. Configure Ens.Alert for outages and backlog conditions. [1]
4. Tune pool sizes and buffer settings to actual production volume. [1]
5. Enable automated purging to limit database growth. [1]
6. Use ^PROFILE, ^TRACE, and %SYS.MONLBL to find bottlenecks. [3][4]
7. Optimize journaling storage and I/O layout, and monitor journal growth and sync latency. [2]
8. Review SQL plans, indexing, global access patterns, and use bulk processing where possible. [3]

Sources: