You can implement this in a Health Connect Cloud interoperability production, but the returned material does not give enough detail to fully prescribe whether you should use a scheduled business service or Task Manager for your exact nightly file-generation logic. What is clearly supported is:

• You can create and manage an interoperability production in Health Connect Cloud through the Management Portal. [1]
• For writing HL7 content to files, EnsLib.HL7.Operation.FileOperation is specifically identified as the class whose purpose is to create a file in a directory and add HL7 messages to it. [1][2]
• In Health Connect Cloud, the documented cloud-oriented file workflow is to use productions with business services, business processes, and business operations, and use SFTP integration with folders in your tenant’s S3 bucket rather than relying on a traditional local server workflow. [3]
• If timing matters, the deployment time zone can be configured, and the default is UTC, so that is relevant for a nightly time such as 11:45 PM. [1]

For your scenario, the best-supported approach from the returned documents is:

1. Create a production in Health Connect Cloud. [1][3]
2. Use a business operation for file output; the returned material specifically points to EnsLib.HL7.Operation.FileOperation for creating a file and adding HL7 messages to it. [1][2]
3. If this needs to be cloud-based rather than written to a deployment-local directory, use the documented SFTP/S3 pattern for output files. [3]
4. Set the deployment time zone correctly so the nightly schedule aligns with your intended local time. [1]

If your design is closer to “create placeholder files first, then append live HL7 messages later,” the retrieved material does support the file-append concept through EnsLib.HL7.Operation.FileOperation, but it does not provide the exact implementation steps for generating 17 files with names like xxx__YYYYMMDD.txt, using the next day’s date, and writing "Dummy Word" before later appending live data. [1][2]

On scheduling:

• One returned source shows that productions have a Schedule feature for business services, and that this can be used to run within configured start/stop times. [4][5]
• Another returned source shows that custom scheduled tasks can be built by extending %SYS.Task.Definition and implementing OnTask(). [6]

However, the retrieved material does not explicitly say which of those two is the recommended pattern in Health Connect Cloud for your exact use case, nor does it provide the ObjectScript/VS Code implementation needed for your filename/date/content requirements. [1][4][6]

Note: Do not confuse the tenant-level Files page with deployment-level Files pages. The tenant-level Files page lets you set up the SFTP feature for all of the deployments on your tenant. The deployment-level Files pages let you upload files from your local computer to a deployment. [1][3]

Note: Some of the functionality described in this section may not be available to all users, depending on their role on the development team. For more information, see Tenants Page. [1]

So, from the available material, the safest answer is: use a Health Connect Cloud production and a file-writing business operation, and for cloud storage use the documented SFTP/S3-based workflow rather than assuming a writable local server area. The exact “scheduled nightly creation of 17 seed files with next-day names and hardcoded content” implementation is not described in the returned documents. [1][3][2]

Sources:

The retrieved material does not show a documented way for an Angular app to ask “am I already authenticated to Federated/Clinical Viewer?” or to directly obtain the Clinical Viewer username/session for reuse in Angular. It specifically describes that “clinical is in one csp session and angular is in another one,” and the working direction taken there was to stop trying to share CSP session context and instead secure the Angular app with an Angular route guard/interceptor plus bearer/JWT tokens for the REST API. [1]

For your scenario, the available guidance points to these conclusions:

• Do not rely on sharing the Clinical Viewer CSP session with your Angular app, because the retrieved discussion says Clinical Viewer and Angular can end up in different CSP sessions. [1]
• Do not rely on passing $username into Angular through index.csp as the main authentication model; the retrieved material does not document that as a supported solution for this use case. [1]
• Prefer token-based authentication for the IRIS REST API, using OAuth bearer/JWT tokens rather than Basic auth or CSP-session sharing. One example says they implemented a /login endpoint to obtain a bearer token, and that JWT must be enabled in the CSP application for the REST entry point. [1]

On the Clinical Viewer side, the retrieved material says that without a current Clinical Viewer web session, a new incoming connection must log in, and it also says there was not a “federation-wide universal authorization scheme” in that context. It also notes that Clinical Viewer later added Single Sign-On support, including “Single Sign-On operation with EHRs” and the statement “Clinical Viewer will support Single Sign On in the 2021.2 release.” However, the retrieved material still does not explain how a custom Angular app launched from Clinical Viewer navigation can consume that SSO state or extract the username. [2][3]

For Angular hosting/routing, the retrieved material only shows that Angular apps can be served from a CSP/IRIS web application path, for example a page on /seti displaying an Angular app from a CSP folder. It does not provide guidance that you must give up Angular routing or switch to index.csp?route=.... [4]

So the most supportable answer from the retrieved documents is:

1. Protect your Angular UI with Angular guards/interceptors. [1]
2. Authenticate your REST API with bearer/JWT tokens. [1]
3. Do not assume Clinical Viewer session sharing or $username injection is the right foundation for this architecture. [1]
4. The retrieved material does not document a supported method to inherit Clinical Viewer authentication/user identity directly into your Angular app. [3][1]

Sources:

I can’t determine the cause from the information available, because the actual error details are missing. The retrieved material only shows that you are getting an error while calling the InterSystems FHIR Server (FHIRaaS) API, but not the error text, code, or HTTP status. [1]

If your setup uses an interoperability production, one known cause is that FHIR requests are being routed through HS.FHIRServer.Interop.Service without that service being configured and running. In that case, configure HS.FHIRServer.Interop.Service in both the Production and the FHIR server configuration page. If you are using direct InterSystems FHIR server storage, that configuration is not needed. [1][2][3]

Note: The InterSystems FHIR server does not require an interoperability production; by default, FHIR requests received by an endpoint’s REST handler are sent directly to the FHIR server’s Service. FHIR servers that do not use an interoperability production can be significantly faster. [1]

If this started after an upgrade and you are now getting HTTP 500, one reported cause is missing access to the HSSYSLOCALTEMP database for the FHIR web applications. A reported fix is to add the %DB_HSSYSLOCALTEMP role to the web applications that handle FHIR requests, or run:

do ##class(HS.HealthConnect.FHIRServer.Upgrade.MethodsV6).AddLOCALTEMPRoleToCSP() [1][4][5]

If your error is 401 Unauthorized, one documented cause is how the OAuth token is sent. The FHIR Server supports the access token only in the HTTP Authorization header as Bearer <token>, not as a request URL parameter. Also, FHIRServer currently does not handle opaque tokens. [6][7]

Please share the exact error message, HTTP status, and whether you are using direct FHIR repository access or an interoperability production so the issue can be narrowed down. [1]

Sources:

The generated .disp class is expected to perform request checks based on the OpenAPI spec before it calls the implementation method, and the retrieved material explicitly shows integer validation being generated for path parameters. [1]

Important: Because the dispatch class is a generated class, you should never edit it. Instead, modify and recompile the specification class. [1]

For spec-first development, your business logic should be in the .impl class, while .disp is regenerated from the specification and can overwrite changes. [1]

Based on the retrieved material, there is no documented option to disable or remove that autogenerated integer validation in .disp by default. [1]

Sources:

I couldn’t find any built-in option in the retrieved material to export a production class with the ProductionDefinition XData items sorted in a stable, consistent order. The material shows that SaveToClass() rebuilds the XData from Ens.Config.Item objects, but it does not mention any sorting control for the export order. [1][2]

If you want to normalize the exported XData yourself, an XSLT-based post-processing step looks viable. The retrieved material shows that XData can be accessed and updated programmatically through %Dictionary.XDataDefinition, and one example uses XSLT to format XML stored in XData before saving it back. [3][4]

A different way to avoid the diff problem is to stop comparing one large production class export. The retrieved material mentions Deltanji as a tool that manages production configuration items separately, including XML for the ProductionDefinition XData contents, so individual items can be versioned and compared independently instead of diffing one unordered monolithic XData block. [5]

So based on the retrieved material, your choices appear to be:

• no documented built-in sorted export option was found, [1][2]
• build your own post-processing tool using programmatic XData access, potentially with XSLT, [3][4]
• or use a tool such as Deltanji that breaks production items into separately managed components. [5]

Sources:

I couldn’t find retrieved material showing a supported way to embed an existing PDF file inside a ZEN report from a stream field the way <img> handles images.

What the retrieved material does show is:

• ZEN reports support inserting images into PDF output using the <img> element, including images stored and retrieved for the report. [1][2][3]
• For PDFs themselves, one discussion states that there is “no easy way” from within Caché to work with PDF content directly, because PDF is a complex binary format and there is no built-in library to access/edit it. [4]
• A possible workaround mentioned is to use a PDF as a background/template during rendering with FOP, but that is described as awkward and dependent on knowing the fixed layout of the incoming PDF. [4]

So, based on the retrieved documents, there is no documented equivalent to image embedding for including a PDF from a stream field directly inside a ZEN report. [4]

If your goal is to show the contents of a PDF inside another generated PDF/report, the retrieved material only points to workaround-style approaches rather than native support. [4]

Sources:

Yes, this behavior has been reported. A related case describes that after compiling with the InterSystems VS Code extension, a local file that previously had CRLF endings is then shown as changed with LF endings. [1][2]

There is also returned documentation stating that when the ObjectScript extension retrieves a document from the server to display it in VS Code or to export it into a client-side workspace, it always uses LF line endings. [3]

Note: The ObjectScript extension can import documents which encode line endings using either the LF or CRLF control character sequence. However, when the extension retrieves a document from the server to display it in VS Code or to export it into a client-side workspace, it always uses LF line endings. [3]

From the available retrieved material, I can confirm the issue has been encountered, but I cannot provide a documented fix or setting to stop it specifically for version 2.12.6. One retrieved item says the question was answered on the extension’s GitHub discussion forum, but the actual resolution is not included in the returned content. [1][2]

Sources:

I could not find retrieved documentation that confirms a supported notification or event mechanism for detecting early HTTP client disconnects for requests handled by EnsLib.SOAP.Service or EnsLib.REST.Service through the Web Gateway / csp_module_sa. The retrieved material only shows disconnect handling for principal I/O devices and for WebSocket connections, not for these SOAP/REST service classes. [1]

For principal I/O devices, there is a DisconnectErr setting that causes a process to receive a disconnect error during an ObjectScript Write or Read, but this applies only to TCP devices and certain terminal devices, and only to the principal device. The same material says the application itself must detect that error and exit gracefully. [1]

Important: This parameter has been retained for compatibility, but should not be used when building new applications. [1]

The retrieved material does show explicit disconnect detection for WebSockets: %CSP.WebSocket can detect $$$CSPWebSocketClosed from Read(), and browser-side WebSocket clients have onclose and onerror events. But that evidence is specific to WebSockets and does not establish equivalent behavior for EnsLib.SOAP.Service or EnsLib.REST.Service. [1]

Because of that, I cannot confirm from the retrieved sources that IRIS already provides an out-of-the-box callback, event, or built-in active-session threshold mechanism for prematurely closed HTTP client connections in EnsLib.SOAP.Service / EnsLib.REST.Service. [1]

Sources:

There does not appear to be a documented way to stop or release an individual non-polling PEX business service instance created with Director.CreateBusinessService() from Python. The retrieved material only documents CreateBusinessService() as a method that initiates the specified non-polling business service and returns the created business service instance; it does not describe any corresponding per-instance shutdown or release method in Director. [1][2]

What the retrieved material does show is that stop/kill controls are provided at the production level instead. Those include methods and commands such as stop_production(), restart_production(), shutdown_production(), and CLI commands like iop -S for stop and iop -k for force stop. [1][2][3][4]

Your observation that the job ends when you close the IRIS connection is also consistent with the retrieved Python connection API material: iris.createIRIS(conn) creates an IRIS object that uses the specified IRISConnection, so the Python-side objects depend on that connection. [1]

So, based on the available material, the best documented conclusion is:

• you can create the non-polling service instance with Director.CreateBusinessService(), but
• there is no documented Python API in Director to cleanly release or kill that individual service instance before closing the connection, and
• the documented shutdown mechanisms are for the production as a whole, not for a single created service instance. [1][2][3][4]

Sources:

The available material confirms that Inactive limit is measured by the time between successful logins. When the configured number of days is reached, the account is disabled. A value of 0 means there is no limit, and the setting does not apply to LDAP or Delegated users. This supports your observation that the check is tied to login activity rather than disabling accounts independently in the background. [1]

The retrieved material does not confirm the more specific point that the inactivity timer is only initialized after the very first successful login, so that detail cannot be verified from the available sources. [1]

There is also related documented login behavior for failed logins:

• For Terminal, the system imposes an escalating time delay on each attempt.
• For CSP, attempts within 2 seconds of the previous attempt are automatically rejected and IRIS returns 503 Service Unavailable; these rejections are not audited.
• For Web, the message User Unauthorized is displayed.
• If Disable account if login limit reached is enabled, reaching the invalid login limit disables the account. [1]

For the case of a manually disabled account that also has an expired password, followed by a password-change prompt and then a Gateway Error, the retrieved documents do not explain that login sequence or that specific error path, so I can’t clarify it from the available material. [1][2]

Note: Mirror Members automatically set the InactiveLimit parameter to 0 on startup. This prevents user accounts from becoming inactive on other mirror members. [1]

Caution: This setting affects all accounts for the InterSystems IRIS instance, including those used by InterSystems IRIS itself. Until passwords are updated for these accounts, it may be impossible for various operations to proceed and this may lead to unexpected results. [1]

Sources:

A few things in the retrieved material match what you describe:

• One reported cause of repeated Java Gateway timeout/hung behavior was a memory leak related to how the JDBC driver Class Path was configured. In that case, the Class Path had been defined within the SQL Gateway, and after moving the driver Class Path to the Java Gateway service itself, the issue stopped occurring. [1][2]
• Another recommendation for intermittent gateway connection failures is to avoid very long-lived TCP connections. If your adapter or business operation is using Stay Connected = -1, try setting it to a lower value such as 30. The retrieved material states: “Longrunning tcp connections might be an issue. I would definitely try setting it to something lower.” [3]
• For troubleshooting, enabling the JDBC SQL Gateway log is specifically recommended so you can monitor connection problems and debug what is being sent between InterSystems and the downstream database. The portal path given is System Administration > Configuration > Connectivity > JDBC Gateway Settings, where you can specify a full log file path. [4]
• It is also recommended to verify whether the gateway process is running. If it is not running, the likely causes mentioned are Java installation problems or an incorrect port; if it is running, the issue is more likely the connection parameters. You can also test connectivity directly with $SYSTEM.SQLGateway.TestConnection(). [4]
• Another retrieved discussion suggests checking whether some other process is using the configured Java Gateway port, and on Linux an example check given is netstat --listening --numeric-ports. There is also a note that shutdown does not always properly stop Java Gateways, so stale processes/ports may contribute. [5]

Note: Controlling SQL Gateway Logging and Other JDBC Settings To monitor problems when connected via JDBC, you can enable JDBC logging for the SQL Gateway connection (see "SQL Gateway Logging"). The same dialog also allows you to specify JAVAHOME and other JDBC settings. [4]

So based on the retrieved material, the most relevant things to check are:

1. Move or confirm the JDBC driver Class Path is configured on the Java Gateway service, not only in the SQL Gateway definition, if that applies to your setup. [1][2]
2. Reduce Stay Connected from an indefinite or very long setting to something bounded, such as 30. [3]
3. Enable the JDBC Gateway log and review it when the timeout happens. [4]
4. Confirm the gateway process and port are healthy, and check for another process holding the port. [4][5]
5. Use $SYSTEM.SQLGateway.TestConnection() to test the connection independently. [4]

Sources:

Your idea is the best match to the guidance I found: put custom resource processors in a separate reusable module and make consumer modules depend on that module. [1][2]

The retrieved guidance suggests using Resource Processor classes declared in module.xml, with those processor classes marked Preload="true" so they are available early enough during package-manager processing. These classes should extend %ZPM.PackageManager.Developer.Processor.Abstract and override the appropriate methods for the custom installation behavior. [2]

So the recommended pattern is:

1. Package the custom processor implementation separately from the module that consumes it. [1][2]
2. Add that processor package as a dependency of any module that uses the processor. [1]
3. Declare the processor in module.xml as a Resource Processor class, using Preload="true" so it is loaded before the resources that need it are processed. [2]

This is also presented as a cleaner approach because it keeps installation behavior visible in module.xml and avoids hiding side effects in installer logic, improving simplicity, transparency, and auditability. [2]

I could not find a more explicit official step-by-step packaging recipe for your exact ProcessorClass="OSEX.ipm.demo.IpmResourceProcessor" example, but the closest matching material supports exactly the separate library/dependency approach you proposed, together with preloaded resource processor classes. [1][2]

Sources:

fuse.glusterfs is in the unsupported category for a durable %SYS location. IRIS rejects mounted volumes whose filesystem type is cifs, NFS, or anything containing fuse, which matches the warning you are seeing for ISC_DATA_DIRECTORY. [1]

Important: InterSystems strongly recommends using bind mounts, as illustrated in the preceding example, when mounting external volumes for InterSystems IRIS containers on production systems. However, under some circumstances, such as testing and creating demos or anything that you want to be portable to platforms other than Linux, it is preferable to use named volumes, because they eliminate problems related to directory paths, permissions, and so on. For detailed information about each method, see Manage data in Docker in the Docker documentation. [1]

The supported persistence model for containers is durable %SYS via ISC_DATA_DIRECTORY, where one persistent instance uses one external storage location. If the durable directory already contains /mgr, the container uses that data; if it is empty, IRIS initializes it. [1]

What you should not do is point multiple running IRIS instances or containers at the same persistent database directory. A single ISC_DATA_DIRECTORY is intended for one persistent instance only, and two simultaneously running instances must never share the same mgr/IRIS.DAT. [1]

For your Swarm goal — one container that can restart on any node and pick up the same data path — the retrieved material only supports that when the external storage behind ISC_DATA_DIRECTORY is a supported volume type. Since GlusterFS appears as fuse.glusterfs, the documents do not support using it for this purpose. [1]

The alternative direction shown in the retrieved material for high availability is not “one shared database directory across nodes”, but a multi-instance HA topology such as mirroring, sharded clusters, or other multi-instance deployments managed through configuration merge or Kubernetes tooling. [1]

IRIS databases can be mirrored for redundancy across two servers, with a PRIMARY and BACKUP failover member, plus an arbiter for quorum. [2]

So, based on the retrieved material:

• do not use GlusterFS mounted as fuse.glusterfs for ISC_DATA_DIRECTORY; [1]
• use a supported external volume for one persistent IRIS instance; [1]
• do not share one persistent instance directory between multiple running containers; [1]
• if you need cross-node HA, the documented approach is a multi-instance design such as mirroring rather than a single container using one shared GlusterFS-backed data directory. [1][2]

Sources:

I could not find returned documents that provide official auto-start steps for a Caché 2018 instance itself on AIX. The returned material only includes AIX-related startup guidance for ISCAgent and AIX platform notes, not a verified procedure for enabling OS-boot auto-start for the Caché instance QA2018. [1]

What the returned material does provide is:

• For IBM AIX, the documented startup script path shown is for ISCAgent:

  • /etc/rc.d/init.d/ISCAgent
  • start as root: /etc/rc.d/init.d/ISCAgent start
  • stop as root: /etc/rc.d/init.d/ISCAgent stop [1]

• ISCAgent must be configured to start automatically when the system starts on each failover and DR async mirror member, and platform-specific control scripts can be added by a system administrator to the system initialization process. The detailed startup configuration procedure is stated to be OS-specific and should be taken from the operating system documentation. [1]

• For startup order and dependencies in clustered environments, the sequence described is:

  1. Remount the storage
  2. Relocate the cluster IP
  3. Run an application/script agent to restart ISCAgent
  4. Start Caché using the ISC VCS cluster agent
     
     The ISCAgent step should depend on storage being mounted first, and the Caché start should depend on the ISCAgent step. [1]

• For AIX filesystem considerations, the filesystem containing IRIS.WIJ should use a mount option that includes file system buffering, for example rw, to improve recovery speed after a hard shutdown or crash. [1]

Note: Non-InterSystems IRIS workloads that benefit from file system caching (for example, operating system-level backups and/or file copies) are slowed by the cio mount option. [1]

• For AIX I/O pacing, the notes say I/O pacing can hinder write daemons, and if write daemons are slowing or stalling, the high-water mark may need adjustment. [1]

Important: Beginning in AIX® 6.1, you should not have to make any high-water mark adjustments. [1]

• For AIX performance monitoring, if these vmstat -vs metrics increase, the related values should be increased:
  • pending disk I/Os blocked with no pbuf
  • paging space I/Os blocked with no psbuf
  • filesystem I/Os blocked with no fsbuf
  • client filesystem I/Os blocked with no fsbuf
  • external pager filesystem I/Os blocked with no fsbuf [1]

Because the returned documents do not include an official Caché 2018 on AIX auto-start procedure for the instance itself, I cannot provide verified steps beyond the items above. [1]

Sources:

The retrieved material supports that missing HS package mappings would be inconsistent with the expected FHIR namespace setup, and that the Interactions strategy is normally expected to be present in that flow, but it does not explicitly confirm whether 2022.3.0I4HFHIR (Build 4093U) Preview 4 has a known defect causing the behavior you saw. [1]

The expected installation flow shown in the retrieved material is:

1. Install the HealthShare foundation.
2. Install the FHIR namespace.
3. Install the FHIR instance.

One example shows:

• ZN "HSLIB"
• Do ##class(HS.HC.Util.Installer).InstallFoundation(pNamespace)
• Do ##class(HS.FHIRServer.Installer).InstallNamespace(pNamespace) or, after switching to the namespace, Do ##class(HS.FHIRServer.Installer).InstallNamespace()
• Do ##class(HS.FHIRServer.Installer).InstallInstance(...) [1]

Your provisioning approach using:

zn "FHIRDB"
Do ##class(HS.FHIRServer.Installer).InstallNamespace()

matches an example of the expected namespace-install step, but the retrieved material also indicates there is a prerequisite: before configuring the foundation namespace, all HealthShare (HS) packages, routines, and globals must already be correctly mapped to the target namespace. If those mappings are absent, configuration can fail unexpectedly. [1]

Note: before configuring the foundation namespace, “all HealthShare (HS) packages, routines, and globals* are correctly mapped to your target namespace,” otherwise configuration can fail unexpectedly. [1]

The retrieved material also includes an example of a successful foundation install log where mappings are added during installation, including:

Added Package mappings HS,HSMOD,SchemaMap

followed later by:

HS.FHIRServer.Installer:InstallNamespace ... [1]

That makes your observation about namespaces being created without mappings look inconsistent with the setup examples and prerequisites in the retrieved material. [1]

For the Interactions strategy point, one installation example explicitly uses HS.FHIRServer.Storage.Json.InteractionsStrategy as the strategy class when creating the FHIR instance, and then retrieves the strategy with ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint(...). That indicates the Interactions strategy is normally part of the expected setup shown in the retrieved material. [1]

So the strongest supported conclusion is:

• missing package mappings are not consistent with the documented prerequisites and sample successful install behavior, and
• the missing Interactions strategy may be related, because that strategy normally appears in the expected setup flow,
• but the retrieved documents do not confirm that Preview 4 specifically has a known bug for this. [1]

Sources:

The behavior you describe is consistent with the SOAP catalog/test pages not being enabled for your web application, and possibly with web application security settings also blocking access. The key point is that viewing and testing a SOAP service in a browser uses %SOAP.WebServiceInfo and %SOAP.WebServiceInvoke, and those are blocked by default in user applications unless explicitly allowed. [1][2]

For a web application, the ^SYS("Security","CSP","AllowClass",...) entries must use the web application name, not the class name. An example given is that for a web application such as /csp/test/, the required settings are:

set ^SYS("Security","CSP","AllowClass","/csp/test/","%SOAP.WebServiceInfo")=1
set ^SYS("Security","CSP","AllowClass","/csp/test/","%SOAP.WebServiceInvoke")=1

So if your application is /colintest1/, the correct form is with "/colintest1/" as the fourth subscript. [2]

Also, enabling %SOAP.WebServiceInfo and %SOAP.WebServiceInvoke only affects the browser-based SOAP catalog and test pages. It is independent from invoking the SOAP service through the SOAP protocol itself. For actual inbound SOAP requests through CSP Gateway, the web application should have Inbound Web Services enabled. [1]

If you want to control who can access the SOAP service, you can do that either at the CSP application level or at the SOAP service class level:

• In the web application definition, set a Resource Required value.
• Or in the service class, define:

Parameter SECURITYRESOURCE = 'my_soap_resource';

Only users with access to that resource will then be able to use the service; otherwise they get Illegal CSP Request. [3]

If you are testing anonymously through the browser, UnknownUser must be enabled appropriately for that application context, and application roles/matching roles may also be needed depending on what resources the service and namespace require. One discussion notes that for development/testing, Unknown User must be enabled, and another explains that matching roles can be used to grant needed privileges only within that CSP application. [3][4]

The message:

An error occurred with the CSP application and has been logged to system error log (^ERRORS)

means you should inspect the application error log for the namespace, or use ^%ERN, because the details of the actual failure are logged there. One suggested way to investigate is:

• Management Portal → System Operation → System Logs → Application Error Log → [Namespace]
• or run ^%ERN from the terminal. [1]

When the logged error is Illegal CSP Request, that usually means access to the class/page is prohibited, which again points back to the web application access settings and the %SOAP.WebServiceInfo / %SOAP.WebServiceInvoke allow-list entries for the application. [1]

A few practical conclusions follow from the retrieved material:

1. Use the web application path in ^SYS("Security","CSP","AllowClass",...), not the class name. [1][2]
2. Make sure the web application has Inbound Web Services enabled if you want actual SOAP requests to reach the service. [1]
3. If you need security, use a required resource on the application or Parameter SECURITYRESOURCE in the service class. [3]
4. Check the Application Error Log / ^%ERN to see the real underlying error instead of relying on the generic CSP page. [1]

Note:

“We strongly suggest that you use a SOAP Web Client to generate an HTTP SOAP request to call Caché SOAP Web Services rather than using the catalog pages.” [2]

Again, from the material retrieved, the most likely issue is not your service method code itself, but the CSP/web application configuration around SOAP catalog/test access and inbound web service handling. [1][2]

Sources:

Yes — you can change the Developer Portal URL/port that IAM uses by updating the Dev Portal configuration in your docker-compose.yml, specifically KONG_PORTAL_GUI_HOST. In the example configuration, it is set to 127.0.0.1:8003, which is why the portal generates URLs with port 8003. [1][2][3]

Port 8003 and port 8000 are intended for different purposes:

• 8000 is the HTTP proxy port that forwards incoming API traffic to upstream services. [1][2][3]
• 8003 is the HTTP port for the Developer Portal UI. [1][2][3]

So if your issue is that the Dev Portal is showing/generated with 8003, you can change the configured Developer Portal host/port by editing KONG_PORTAL_GUI_HOST before starting IAM, then restarting it. [1][2][3]

Note: The docker-compose.yml file defines the URLs that are used to access the IAM management portal and the developer portal. To avoid Cross-Origin Resource Sharing (CORS) errors when accessing the IAM management and developer portals, the URLs that you use must match the URLs defined in the docker-compose.yml file in the KONG_ADMIN_GUI_URL and KONG_PORTAL_GUI_HOST environment variables. The default values of these are http://localhost:8002 for the management portal and 127.0.0.1:8003 for the developer portal. If you will be using different URLs to access these portals, you must edit the docker-compose file before you start IAM. For details on how Kong Enterprise handles CORS and other DNS issues, see DNS Considerations for Kong Gateway. [1]

However, the available documents do not describe a supported way to make Dev Portal-generated API calls use port 8000 instead of 8003 simply by changing a single setting, nor do they provide Kong 3.2.1.0-specific guidance for that exact behavior. Based on the retrieved material, 8003 remains the Dev Portal port and 8000 remains the proxy/API traffic port. [1][2][3]

Sources:

InterSystems does provide an API for invoking ObjectScript functionality externally: the Native API for ObjectScript. It uses %Net.DB.DataSource to create a connection, %Net.DB.Connection to manage it, and %Net.DB.Iris to work with globals, transactions, and to invoke routines or class methods. A documented usage sequence is: create the connection with CreateConnection(...), call CreateIris() on that connection, then use the resulting %Net.DB.Iris instance. The retrieved material explicitly says this API can “invoke functions and methods implemented in routines or classes.” [1]

If your goal is to execute ObjectScript functionality from an external script, the retrieved documents show these supported options:

• Native API for ObjectScript for external access to IRIS features and method/routine invocation. [1]
• Python on Windows is shown in the retrieved documentation as having a Windows wheel for the Native SDK. [2]
• .NET connectivity is also shown as supported in the retrieved documentation via InterSystems.Data.IRISClient.dll. [2]

For the more specific case of running a free-form terminal-style ObjectScript command line such as you would from the console, one retrieved source says that the Native API is missing a direct option for that, and shows an add-on workaround that submits command text and returns a reply. It also states that the submitted command must end with a QUIT value, for example: SET ^MyGlobal="I was here" QUIT 1. [3]

Warning: This is a rather dirty hack if there is no other chance

That same source also says:

Native API for IRIS is missing an option to run a simple

Command in ObjectScript as you do from the console or a terminal.

This add-on allows to submit some command line and receive a reply.

The NativeAPI function always requires to have a reply value

So take care to terminate your line with any QUIT

to serve the underlying method. Even if it makes no sense.

e.g. SET ^MyGlobal=“I was here” QUIT 1 [3]

There is also a Windows example in the retrieved material for Embedded Python using iris.execute() to execute ObjectScript, including examples on IRIS for Windows (x86-64) such as:

• iris.execute('write "hello world", !')
• iris.execute('return $zversion') [4]

However, the retrieved documents do not provide a direct statement about which irisnative language binding works correctly with an 8-bit / non-Unicode IRIS server on Windows 10 specifically. They show general support for Native API, Python on Windows, .NET connectivity, and an ObjectScript-native API approach, but not a definitive compatibility statement for your exact 8-bit Windows scenario. [2][4][1]

So, based only on the retrieved material:

• Yes, InterSystems provides an external API: Native API for ObjectScript. [1]
• If you need to invoke class methods/routines, %Net.DB.Iris is the documented mechanism. [1]
• If you specifically need terminal-style free-form command execution, the retrieved source says that is not directly provided by Native API and points to an add-on workaround. [3]
• The retrieved sources do not confirm which irisnative language works correctly on Windows 10 with 8-bit IRIS specifically. [2]

Sources:

The error means the object reference being used during %dispatch is invalid when IRIS tries to invoke the imported proxy method. In your generated proxy, applyRules() calls ..%dispatch(,$this,"applyRules",..%gateway,args...), so both the proxy instance and its gateway association must be valid for the call to work. [1]

In the code sequence you posted, the important part is:

s sc = SCJavaDroolsObj.connection.%Import("com.lca.smc.drools.DroolsRules")
s SCJavaDroolsObj.drools = ##class(com.lca.smc.drools.DroolsRules).%New()
d SCJavaDroolsObj.drools.applyRules(patientjson)

The retrieved material says this is consistent with creating the proxy object via %New() without a valid gateway-backed remote object context for dispatch. The imported class method body shown does not itself create the Java-side object; it only dispatches through %gateway. [1]

So the practical checks are:

1. Make sure the gateway connection object is valid and assigned correctly before import and use. [1]
2. Make sure the proxy classes are imported/created through the gateway import step before trying to use the Java class or method. A similar Java/JAR example explicitly recommends using %ExpressImport() or %Import() before use. [1][2]
3. The failure is happening when DO SCJavaDroolsObj.drools.applyRules(patientjson) evaluates an invalid object reference in the proxy/dispatch path. [1]

There is also a possible typo called out in the retrieved material: one pasted version showed SCJavaDroolsObj.connection=connections instead of connection. If your real code uses connections, that would also leave you with an invalid object reference. [1]

The DO syntax itself is not the issue. Calling an instance method as DO oref.Method() is valid ObjectScript syntax, but it requires oref to be a valid object reference. If the object reference is invalid, IRIS raises an object-reference-related error while evaluating the method call. [1]

I do not see enough retrieved documentation to give you the exact corrected object-construction statement for a %Net.Remote.Base proxy after %Import(), so I cannot safely provide replacement code beyond these points. [1][2]

Sources:

A practical approach shown in the retrieved material is to handle this through routing/custom logic, not by writing a special shutdown callback for router B. One example uses a custom Ens.Rule.FunctionSet method to disable a production item programmatically with:

##class(Ens.Director).EnableConfigItem(serviceName,0,1)

and then calls that function from routing rules when the condition is detected. This shows that one router/rule can disable another production item directly. [1][2]

The retrieved material also shows that HL7 routers are business processes based on EnsLib.HL7.MsgRouter.RoutingEngine, and supported customization is done by subclassing the router and overriding lifecycle methods such as OnRequest(), OnResponse(), OnComplete(), OnTimeout(), and OnError(). So if you need custom behavior, the supported pattern is to extend the router class rather than create a separate custom process just for this purpose. [1]

I could not find anything in the retrieved material that documents a built-in dependency mechanism between two business processes, or that specifically recommends using an onShutdown callback on router B to disable router A. Based on the available sources, the clearest supported option is to implement logic that disables A with Ens.Director.EnableConfigItem(...) when your custom router/rule logic determines B is no longer available. [1][3][4]

Sources:

I could not find material about running InterSystems IRIS specifically on HashiCorp Nomad, translating Docker Compose to HCL, or using Packer for this purpose in the retrieved documents.

What I can confirm from the available material is that the documented IRIS container examples are centered on Docker Compose, where the configuration covers:

• how the image is built,
• which ports are exposed,
• how host storage is mapped into the container,
• and how startup scripts are executed after the container starts. [1]

The retrieved example shows these Docker Compose concepts for IRIS:

• build for image creation from a Dockerfile,
• ports for exposing 1972 and 52773,
• volumes for mapping a host directory such as ./dur to /dur in the container,
• restart: always,
• healthcheck,
• and command: --after ... to run an IRIS auto-configuration script at startup. [1]

It also states that the startup script runs every time the container starts.

NOTE: The commands in this script are executed every time the container starts. This means that if the container goes down for any reason and restarts (for example, due to restart: always), all the commands in this script will be executed again. If this behavior is not taken into account when writing the script, it can lead to unintended side effects such as reinstalling packages or resetting tables. [1]

Beyond those Docker Compose-based details, the retrieved documents do not provide guidance about Nomad behavior, HCL equivalents, or Packer workflows for IRIS. [1][2]

Sources:

Your error points to generated ObjectScript for the stored procedure referencing an undefined variable, specifically %ROWCOUNT, which matches the error text <<UNDEFINED>...*%ROWCOUNT>. The retrieved material shows that SQL-generated procedure/method wrapper code normally uses variables such as SQLCODE, %ROWID, and %ROWCOUNT. One documented example explicitly includes NEW SQLCODE,%ROWID,%ROWCOUNT, and the procedure context also uses %sqlcontext.%ROWCOUNT and %sqlcontext.%SQLCODE. [1]

This strongly suggests the runtime failure is in the generated wrapper code path, not simply in the SQL syntax of your INSERT. Your procedure compiles, but fails at runtime with <UNDEFINED> on %ROWCOUNT, and a similar reported case in the retrieved material concludes that generated SQL code can be defective and may require an InterSystems fix or a rewrite as a workaround. [1]

Your observation about “Function type” versus “query type” is also consistent with the retrieved documentation. A SQL query is generated differently and must consist of a single SELECT statement, while a SQL method/procedure is wrapped in generated ObjectScript code. Also, if a SQL method does not specify a RETURN clause, it returns an empty string. [1]

For debugging, inspect the generated implementation named in the error location, specifically Silk.procspInsertObject.1, at the label/offset shown in the error such as zspInsertObject+50. The retrieved material recommends examining generated SQL routines/classes at the exact failing offset to see what code is accessing the undefined variable. In another example, debugging was done by preserving generated SQL source, reproducing the error, and then opening the generated routine at the failing location. [1][2]

Practical next steps supported by the retrieved sources:

1. Inspect the generated routine/class named in the error, especially the offset where %ROWCOUNT is referenced. [1]
2. Treat this as likely generated-code behavior rather than a straightforward parameter-binding mistake in your SQL text. [1]
3. If possible, rewrite the procedure definition to avoid the specific generated code path that triggers the problem, since similar cases were worked around by rewriting the SQL. [1]
4. If the problem persists, contact the InterSystems WRC because comparable generated-code failures were identified as issues requiring an InterSystems fix. [1]

When debugging SQL execution paths, check SQLCODE immediately after execution; the retrieved material says this is the only reliable way to determine whether the operation succeeded. It also notes that when SQLCODE=100, %ROWCOUNT is 0. [3]

I cannot confirm from the retrieved material exactly which rewrite of your CREATE PROCEDURE will avoid this in Caché, but the available evidence supports that the failure is caused by generated procedure code accessing %ROWCOUNT while undefined, rather than by the fact that you passed parameters. [1][3]

Sources:

You can test a returned %DynamicObject in two ways shown in the retrieved material:

1. Use the standard %UnitTest.TestCase assertion macros like $$$AssertEquals and $$$AssertTrue. Your test class should extend %UnitTest.TestCase, and test methods should start with Test. Also, these assertions are macros, so call them with Do. [1][2][3]

Class MyPackage.MyTests Extends %UnitTest.TestCase
{
Method TestDynamicObject()
{
    Set tActual = ##class(MyPackage.MyClass).MyMethod()
    Set tExpected = {"value":"abc"}
    Do $$$AssertEquals(tActual, tExpected, "Returned object should match expected")
}
}

[4]

2. If you need better comparison for %DynamicObject contents, use the supplemental Assert-Objectscript library. It supports field-by-field comparison and gives clearer failure output for dynamic objects. It requires a %UnitTest.TestCase context. [5][6]

Method Assert() As utility.testing.AssertBuilder
{
    return ##class(utility.testing.AssertBuilder).AssertOnContext($THIS)
}

Method TestDynamicObject()
{
    Set tActual = ##class(MyPackage.MyClass).MyMethod()
    Set tExpected = {"value":"abc"}
    Do ..Assert().ThatActualObject(tActual).UsingFieldByFieldComparison().IsEqualTo(tExpected)
}

[4]

If you want to ignore a field such as id during comparison, you can do this: [5][6]

Do ..Assert().ThatActualObject(tActual).UsingFieldByFieldComparison().IgnoringField("id").IsEqualTo(tExpected)

[4]

For the exception case, the retrieved material does not provide a dedicated built-in assertion specifically for “assert this custom exception class was thrown”. The documented pattern available is to use Try/Catch in the test and then assert success or failure explicitly. [4][1]

Method TestCustomException()
{
    Try {
        Do ##class(MyPackage.MyClass).MyMethodThatThrows()
        Do $$$AssertFailure("Expected custom exception was not thrown")
    }
    Catch ex {
        Do $$$AssertSuccess("Custom exception was thrown")
    }
}

[4]

If your method returns a %Status instead of throwing directly, use the status assertions: $$$AssertStatusOK and $$$AssertStatusNotOK. [1][2][7]

Method TestStatusError()
{
    Set tSC = ##class(MyPackage.MyClass).MyMethod()
    Do $$$AssertStatusNotOK(tSC, "Method should return an error status")
}

[4]

Important: The assertions in %UnitTest.TestCase are macros, not methods. * CORRECT: Do $$$AssertEquals(1, 1, "test") * INCORRECT: Do ..AssertEquals(1, 1, "test") [4]

If your main need is comparing %DynamicObject values cleanly, Assert-Objectscript is the most directly relevant option in the retrieved material. For exception assertions, the retrieved material only supports the manual Try/Catch plus assertion pattern above. [4]

Sources:

I could only find information about InterSystems IRIS Community Edition, not a separate community edition or separate licensing model specifically for IRIS Report Designer. [1]

What is available is this:

• InterSystems IRIS Community Edition exists and includes a free license intended for evaluation and testing, with some limitations. [1][2]
• You can get it from the InterSystems Evaluation Service at evaluation.intersystems.com by signing in with an InterSystems SSO account and downloading the Community Edition kit. [3][4][5]
• It is also available as a container from Docker Hub or the InterSystems Container Registry. [1][5]
• There is also an option for a full-powered evaluation license that lasts 35 days, while Community Edition is a smaller-capacity option with a longer lifetime. [3]

So, if your question is about a license for InterSystems IRIS itself, you can get the Community Edition or request an evaluation license through the Evaluation Service. But for IRIS Report Designer specifically, the retrieved material does not provide a separate community-edition download or separate license source. [1]

Sources:

The best-supported approach is to use the Web Gateway instance-prefix mechanism, not ad hoc Apache rewriting. InterSystems IRIS web application URLs can include an instancePrefix, which is the instance’s CSPConfigName. By default, CSPConfigName is the instance name in lowercase, but you can change it. The IRIS application server strips that prefix before matching the rest of the path to the web application, so your application path handling does not need to change. [1]

If your goal is to keep old-style URLs or avoid exposing the actual instance name, the documented solution is to set a custom CSPConfigName instead of using the default instance name. Example: [1]

d $System.CSP.SetConfig("CSPConfigName","walter")

Then configure the Web Gateway application access profile for the corresponding prefixed path, such as /walter, /walter/csp, or /walter/csp/sys, and point it to the correct IRIS server access profile. The same pattern applies to any prefix you choose. [1]

If you need a transition period where several old prefixes must still work, CSPConfigName can be a comma-delimited list, so multiple prefixes are accepted for the same instance. Example: [1]

d $System.CSP.SetConfig("CSPConfigName","perry,perry1,perry2,perry3")

So the documented options are:

1. Keep using the default instance-name prefix and configure the Web Gateway/web server to route that prefixed path to the instance. [1]
2. Replace the instance name in the URL with your own stable custom prefix by changing CSPConfigName. [1]
3. Accept multiple prefixes temporarily by setting a comma-delimited CSPConfigName list. [1]

For routing to work, the web server must invoke the Web Gateway for the chosen prefixed paths, and the Web Gateway must have an application access profile for those paths with the proper Default Server. [1]

So for your customer, the closest match to “revert to the previous URL path” is not Apache mod_rewrite, but assigning a custom CSPConfigName that matches the old path expectation, then configuring the Web Gateway to serve that prefix. If multiple legacy paths exist, use a comma-delimited CSPConfigName during migration. [1]

Note: Each time you allow the installer to automatically configure your web server to serve the web applications for a new or upgraded instance, the installer overwrites the existing /csp and / (root) application access profiles so that they route requests to your most recently installed or upgraded instance. To avoid inconvenience, when you manually configure an application within the /csp path (such as /csp/foo/bar), define an application access profile for a path subordinate to /csp (such as /csp/foo or /csp/foo/bar). [1]

Important: The instancePrefix identifier is not available when an InterSystems IRIS instance is running within a container. To access to the Management Portal and other built-in web applications for a specific instance in a multi-instance cluster, you must deploy a dedicated Web Gateway container for each InterSystems IRIS container. The specific procedure depends on the manner of deployment. For more information on this topic, see Web Access Using the Web Gateway Container. [1]

I did not find documentation here recommending Apache mod_rewrite or a reverse proxy as the preferred solution for this case; the documented approach is Web Gateway path routing together with CSPConfigName customization. [1]

Sources:

For a standard mirror VIP setup, you should not manually add the VIP address to the host NIC first. A common setup mistake is to add the IP intended for the Virtual IP directly to the machine before creating the mirror, but that IP address needs to be free and unassigned so that mirroring itself can assign the IP to the interface. [1][2]

So I would not confirm ip addr add *.*.*.*/2 dev nic as the correct general step for setting up a mirror VIP. The retrieved material indicates the VIP should be left unassigned rather than pre-added manually. [1][2]

To configure the mirror VIP, the VIP address must be configured in InterSystems IRIS, and the network interface is specified with VirtualAddressInterface in the mirror configuration. An example configuration uses:

• VirtualAddress : "${IRIS_VIRTUAL_IP}/24"
• VirtualAddressInterface : "eth0" [3]

After configuring the mirror VIP, failover testing is recommended by gracefully shutting down the current primary and verifying that clients can still connect regardless of which failover member is primary. [1]

Important: Before configuring a mirror VIP on a Linux platform, ensure that the arping command is available by installing the appropriate package (for example, the Debian iputils-arping package). [1]

If one or more mirror members is a nonroot InterSystems IRIS instance on UNIX or Linux, a mirror VIP cannot be used. [1]

Note: See Promoting a DR Async Member to Failover Member for important information about promoting a DR async to primary when a VIP is in use. [1]

If you see an error such as AddVirtualAddress failed, cannot become primary, that indicates the instance is unable to take over the VIP, and one thing to check is whether the VIP is already assigned somewhere else. [1][2]

If you want, the next step would be to share your OS, subnet mask, and whether IRIS is running as root or nonroot, so the exact VirtualAddress format from your environment can be checked against the mirror configuration examples. [1][3]

Sources:

I could find support for using SFTP from IRIS, including the FTP inbound/outbound adapters and the usual SFTP settings such as server, port 22, authentication method, public/private key files, and credentials. However, I did not find any retrieved document that describes native support for sending an SFTP connection through a proxy in InterSystems IRIS or Ensemble. [1][2][3]

The retrieved material confirms that IRIS can act as an SFTP client in productions:

• use EnsLib.FTP.InboundAdapter / related business services for GET/polling from an SFTP server
• use EnsLib.FTP.OutboundAdapter / related business operations for PUT to an SFTP server [1][3]

It also shows that SFTP configuration in IRIS is based on standard connection parameters and SSH key material, for example SFTPPublicKeyFile, SFTPPrivateKeyFile, and credentials for passphrases if needed. [2]

Because none of the retrieved documents provides a documented native or supported SFTP-over-proxy method, I can’t confirm a built-in InterSystems-supported approach for SFTP + proxy from the available sources. [1]

Note: The `` portion of the domain name is fixed and cannot be changed, for example, to mycompany.com. [1]

Sources:

From the retrieved material, the published Smart Factory Starter Pack installation steps are still:

1. create a namespace named OEESP
2. install the InterSystems Python Gateway
3. install the InterSystems classes using iris-export-builder
4. install the Python code and run pip install -r requirements.txt
5. create the web applications manually in the Management Portal [1]

On your Python Gateway question: the PythonGateway package page says that starting with InterSystems IRIS 2020.3, IRIS provides an out-of-the-box Python Gateway implementation. At the same time, the Smart Factory Starter Pack README still explicitly tells you to “Install the InterSystems Python Gateway.” [2][1]

Important notice This project is a community supported bridge between InterSystems IRIS and Python. Starting with 2020.3 InterSystems IRIS provides out-of-the-box Python Gateway implementation, officially supported by InterSystems. Documentation is available here. [2]

For the Python 3.6.7 requirement, the retrieved documents tie that requirement to the standalone community PythonGateway package. They state that Python 3.6.7 64-bit is required and that other Python versions will not work due to ABI incompatibility. [2]

For installing the classes, the Starter Pack documentation only says: “Install the InterSystems classes. This can be easily done by using this tool https://github.com/gertjanklein/iris-export-builder”. I did not find any retrieved document that explains the specific iris-export-builder error you saw or gives an exact fix for it. [2][1]

For the web applications you need after installation, the README says to create them manually in the Management Portal under System Administration → Security → Applications → Web Applications, including these examples:

• /api/v1/datamodel with dispatch class opc.ua.rest.datamodel.disp
• /api/v1/equipment with dispatch class opc.ua.rest.equipment.disp
• /api/v1/masterdata with dispatch class opc.ua.rest.masterdata.disp [1]

NOTE: ⚠️ This application is licensed as open source under the MIT License and is not officially supported by InterSystems Corporation. Use it at your own risk. [1]

So the safest confirmation from the available documents is:

• yes, IRIS 2020.3+ includes an out-of-the-box Python Gateway [2]
• however, the Smart Factory Starter Pack instructions still say to install PythonGateway separately [1]
• the Python 3.6.7 requirement belongs to that older standalone PythonGateway package [2]
• I could not verify from the retrieved documents whether the Starter Pack works unchanged with the built-in IRIS Python Gateway instead of the older standalone package, and I could not identify the fix for your iris-export-builder error from the retrieved material [2][1]

Sources:

A workable pattern is to use:

• a business service to ingest the files,
• a business process to coordinate them,
• and a business operation to send the outbound files to the destination. The available material states that a business service can watch an input folder for incoming files and pass them to a business process for transformation or other processing, and that a business process can then pass outgoing files to a business operation, which deposits them in an output location. [1]

For the outbound transfer side, if your MoveIT endpoint is reached through file-transfer settings, the documented setup is:

1. Create authorization credentials in the Management Portal.
2. Configure the production component.
3. On the service or operation, use the Settings tab to define Basic Settings and SFTP Settings.
4. For the operation, specify File Path, FTP Server, and FTP Port as part of the configuration. [1]

For routing from one process to multiple destinations, the retrieved material shows two supported approaches:

• configure multiple targets directly in the business process configuration screen via response target configuration names, and/or
• use the Rule Editor with multiple Send directives to route to different operations, optionally with different DTLs per target. [1]

For your requirement where one of the 6 files contains data that must drive the processing/configuration for the other 5 files, the returned material does not describe a built-in documented workflow that waits for 6 related files and processes them as one session. The closest guidance is that this kind of requirement needs custom processing, such as:

• a custom adapter,
• a custom service derived from a file service,
• stream/file preprocessing logic,
• and/or a DTL to apply extracted values into downstream messages. [1]

The same material also notes that file-derived values can be accessed and then applied in transformation logic; for example, the full filename is available in the message object's Source property and can be used in a DTL after preprocessing or extraction. [1]

So the nearest documented workflow is:

1. Use a file-based business service to pick up the incoming files.
2. Send each file into a custom business process.
3. In that process, implement custom logic to identify the set of 6 related files and extract the needed values from the one “property/config” file.
4. Apply those extracted values during preprocessing or transformation for the remaining files, for example through DTL or custom code.
5. Send the resulting outbound files to the configured business operation for MoveIT transfer. [1]

This gives you the production building blocks, but the exact orchestration of “collect 6 related files, use one as the controller/property file, then process all 6 together in one session” would need custom implementation; that exact workflow is not described in the returned material. [1]

Sources:

A currently implemented option for Kibana is the Open Exchange package Intersystems-Monitoring. It is an add-on for InterSystems IRIS and HealthConnect that installs a monitoring production, collects data, and sends it to Logstash so you can view it in Kibana Discover. The transmitted data includes Prometheus Metrics from SYS.Monitor.SAM.Sensors. Its basic structure is a production with business services collecting data periodically and a business operation sending the collected data to Logstash. It is not a standalone solution; you must provide your own Elastic/Logstash instance. [1]

For the /api/monitor/metrics endpoint itself, the returned material describes it as exposing metrics in Prometheus format, intended to be consumed by Prometheus or SAM. You can retrieve the metrics directly with HTTP tools such as curl, Postman, browser, or similar. The format is plain-text Prometheus exposition format, where each line contains a metric name, optional labels, and a numeric value. Example metrics shown include forms like iris_jrn_free_space{id="WIJ",dir="/fast/wij/"} 401562.83. [2]

If you want the most supported approach, keep the metrics in their native Prometheus format and have them scraped by Prometheus/SAM at intervals, then visualize from that time-series store. A direct connection from a visualization tool to the raw IRIS endpoint was described as limiting functionality; the preferred flow is to ingest via Prometheus first so you keep Prometheus query capabilities and visualization features. [2]

If your requirement is specifically Kibana, the implemented path shown by the returned material is not “post JSON directly to Kibana,” but rather use an ingestion pipeline based on Elastic/Logstash. In that context, the documented ready-made solution is Intersystems-Monitoring, which already sends monitoring information, including Prometheus metrics, to Logstash for Elastic/Kibana use. [1]

For custom HealthShare metrics, you can extend the /api/monitor/metrics output by creating a class that extends %SYS.Monitor.SAM.Abstract, implementing GetSensors(), and publishing values with SetSensor(). After compiling the class, you register it with SYS.Monitor.SAM.Config.AddApplicationClass(...) so it is included in the /metrics output. The example shown for HealthShare creates a class in HS.Local, gathers values with SQL, and publishes them with SetSensor(name,value,identifier). [3]

Note: This example was done in InterSystems HealthShare 2023.1. [3]

For the custom HealthShare metrics example, the /api/monitor web application must also be given access to the code and data. The roles shown are %DB_HSCUSTOM to read the class and %DB_HSREGISTRY to read the data. [3]

Based on the returned material, a practical recommendation is:

1. Retrieve metrics from /api/monitor/metrics as-is in Prometheus format. [2]
2. If needed, add your own HealthShare application metrics through %SYS.Monitor.SAM.Abstract and SetSensor(). [3]
3. For Kibana, use an Elastic pipeline such as Intersystems-Monitoring with Logstash rather than trying to send ad hoc JSON directly to Kibana. [1]
4. Prefer Prometheus/SAM-style scraping and storage over converting the endpoint output to custom JSON for dashboarding. [2]

The returned material does not provide a documented JSON schema for transforming /api/monitor/metrics into JSON, and it does not describe a recommended implementation specifically inside a HealthShare Service, Business Process, or Operation for JSON transformation and direct Kibana API submission. The documented implemented solution for Kibana in the retrieved material is the Logstash-based monitoring package. [1]

Sources: