You should not try to generate your own key for this workflow. For iris-google-run-deploy-template, you need to request the service key from the InterSystems community team in Discord, specifically in the Open Exchange channel. One related announcement also says the key could be obtained in the Docker channel in Discord. [1][2]

After you receive it, add it to your GitHub repository secrets as SERVICE_ACCOUNT_KEY, and for this template you should put the JSON key there. [1]

If you are using the newer reusable demo deployment workflow instead, it also says to ask for the deployment key and store it as the SERVICE_ACCOUNT_KEY secret. [3]

Sources:

Replacing the character by converting the segment to a string, applying $Replace(), and then rebuilding the segment with EnsLib.HL7.Segment.ImportFromString() is a reasonable approach based on the returned examples. A returned example also shows ImportFromString() being used to create an HL7 segment from a string. [1]

The \r you are seeing at the end of the segment string is expected in HL7. The returned material states that carriage return (CR, ASCII 13) is the normal HL7 segment terminator, and another returned discussion confirms that seeing r as the segment terminator is normal HL7 behavior. [1][2]

For your specific question about removing that trailing \r, the returned documents do not provide a documented supported method for stripping it from the result of OutputToString() in this use case. They only establish that CR is the normal segment terminator and that ImportFromString() is used for segment-from-string reconstruction. [1]

A safer alternative shown in the returned material is to avoid rebuilding the full segment text where possible, and instead iterate through fields/components/subcomponents using GetValueAt() and SetValueAt(). That avoids working directly with the full serialized segment string, including its terminator. [1]

There is also a warning in the returned material that if your target is still an HL7 message, you should be careful not to blindly unescape or otherwise alter HL7 syntax in a way that makes the message invalid. [3]

If the goal is only to replace a literal non-ASCII data character such as © with (C), using $Replace() on the relevant data value is consistent with the returned examples. [1][3][4]

Sources:

Yes, this can be handled through the IrisCluster definition by using a podTemplate.spec.securityContext on your IRIS data/compute nodes, and for Web Gateway in locked-down environments the examples use the non-root Web Gateway image instead of the regular Apache/NGINX image. [1][2]

One example specifically calls out that the regular Apache/NGINX Web Gateway containers run as root, and that this causes problems when you need non-root execution. It recommends using the non-root image webgateway-lockeddown and explicitly setting: [1]

securityContext:
  runAsUser: 51773
  runAsGroup: 51773
  runAsNonRoot: true
  fsGroup: 51773

[1]

The same example shows this being set in the IrisCluster CRD under topology.data.podTemplate.spec.securityContext, together with a locked-down Web Gateway under topology.data.webgateway: [1]

topology:
  data:
    podTemplate:
      spec:
        securityContext:
          runAsUser: 51773
          runAsGroup: 51773
          runAsNonRoot: true
          fsGroup: 51773
    webgateway:
      image: containers.intersystems.com/intersystems/webgateway-lockeddown:2025.1
      type: apache-lockeddown

[1]

Another IrisCluster example shows the same pattern: non-root security context in podTemplate.spec.securityContext and a locked-down Web Gateway image/type in the cluster definition. [2]

So for your admission-policy error (runAsNonRoot / runAsUser != 0), the documented direction is to use the locked-down Web Gateway image and define the pod security context in the IrisCluster YAML. [1][2]

There is also an IKO setting useIrisFsGroup: true in the operator Helm values that is described as relevant when you need volumes mounted with the correct filesystem ownership for IRIS containers running as non-root. [1]

Based on the retrieved material, the practical next step is to update your IrisCluster to use:

• webgateway-lockeddown
• type: apache-lockeddown
• podTemplate.spec.securityContext with runAsUser, runAsGroup, runAsNonRoot, and fsGroup set to 51773 [1][2]

I cannot confirm from the retrieved documents whether every standalone topology.webgateway variant exposes its own separate podTemplate for a direct Web Gateway-only securityContext override, or whether you must rely on the node podTemplate plus the locked-down image pattern shown in the examples. [1][2][3]

If your environment still rejects the generated Web Gateway pod after applying the documented locked-down/non-root pattern, the retrieved documents do not provide further troubleshooting steps. [1][2]

Sources:

The information I found matches your symptom pattern but does not provide a confirmed fix for the exact "Failed to load cconnect executable" error.

What does appear relevant is that the problem can differ between command-line execution and web execution because the web application may be running under a different environment and/or a different DSN scope than the CLI process. One report states that terminal access and PHP shell script worked, while the PHP web application failed, and that “USER DATA SOURCES is not working but SYSTEM DSN is working.” [1]

Another closely related Linux ODBC + SSL case mentions that cconnect depends on OpenSSL, and the user concluded: “Problem is openSSL... I poked around cconnect.so and found out, it does!” That same post also raises environment-related items such as LD_LIBRARY_PATH for cconnect and SSL configuration file placement, which suggests checking whether the web server process has the same library path and SSL-related environment as the CLI user. [2]

There is also evidence from a web-server-side case that SELinux can block web server behavior even when command-line tests succeed. In that case, enabling the proper SELinux permissions resolved the issue for the web server process. [3]

Based on the retrieved material, the most supportable pointers are:

• Verify that the WordPress/PHP web process is using a SYSTEM DSN, not a user DSN, since CLI and web can behave differently in that respect. [1]
• Compare the environment of the web server user versus the CLI user, especially library-related settings and SSL-related configuration visibility. The retrieved material specifically points to LD_LIBRARY_PATH and OpenSSL dependency for cconnect. [2]
• Check whether SELinux is preventing the Apache/PHP process from accessing required files or making outbound network connections. One reported fix used:
  • setsebool -P httpd_can_network_connect on
  • and, in another case, setsebool -P httpd_unified 1 [3]

I do not have a document in the retrieved results that definitively explains or resolves the exact "Failed to load cconnect executable" message itself, so I cannot go beyond these pointers from the available sources. [4][1][2][3]

Sources:

The problem is that your mapped class definition is being included in TestBase.metadata.create_all, so SQLAlchemy tries to issue CREATE TABLE "User_BastideRecord.Record". That fails because the projected name contains a dot, as shown by your error: Delimited identifier expected, delimited identifier containing invalid character '.' found ^ CREATE TABLE "User_BastideRecord.Record" [1]

Your reflected MetaData() is separate from the declarative metadata used by TestBase. In your code, metadata.reflect(https://community.intersystems.com/post/engine) only reflects into the local metadata object, but bases[namespace](https://community.intersystems.com/post/engine) calls TestBase.metadata.create_all, which still uses the ORM class definitions and attempts to create any mapped tables it knows about, including BastideRecord [1]

A practical fix is to avoid calling create_all() for classes that correspond to already existing objects such as your RecordMap projection, and use the existing table/class only for querying or updating instead of trying to create it [1]

You also noted that reflection shows all tables except the RecordMap table. Based on the retrieved material, there is no documented solution here showing how to make SQLAlchemy reflection discover a RecordMap table automatically, nor a confirmed method in these sources for accessing RecordMap data through SQLAlchemy reflection [1]

So from the available information, the supported conclusion is:

• do not let TestBase.metadata.create_all include the RecordMap-mapped class if that RecordMap already exists
• keep reflected/existing objects separate from ORM classes meant to be created
• the source provided does not confirm a way for SQLAlchemy reflection to expose the RecordMap table automatically [1]

If you need, you can restructure so only your normal application tables are attached to the metadata passed to create_all, while the RecordMap entity is declared for use against an already existing projection and excluded from table creation [1]

Sources:

A good fit is to keep shared behavior out of the Business Operation class itself and move it into small, explicit support classes, because the documented/project conventions prefer “small, explicit classes,” “business logic in service layer,” and avoiding mixing responsibilities in one class. [1]

For Business Operations specifically, the material only states that they should extend Ens.BusinessOperation, use the correct OnMessage(...) signature, and define the proper adapter when needed. It does not recommend a community-wide pattern of “always use a common superclass” for shared logic across multiple operations. [2][3][4]

Where the available guidance is more specific is architectural separation: common logic should be factored into separate classes rather than packed into endpoint or integration classes. One source gives the same kind of recommendation for REST implementations: delegate processing to other classes, and another example explicitly suggests a Commons class for logic shared across multiple operation-specific classes. That supports using a dedicated common/helper/service class for things like header construction or response parsing. [5]

So, based on the available material, the safest recommendation is:

• keep each Business Operation focused on interoperability concerns such as message handling, adapter use, and request/response flow [2][3][4]
• move reusable business or protocol logic into separate support/service/helper classes [1][5]
• use a shared superclass only when there is true common operational behavior that belongs in the class hierarchy, not just because several operations happen to call the same helper logic; the retrieved documents do not establish inheritance as the preferred default pattern [2][3][4]

If your shared code is things like building HTTP headers or parsing a common response format, that aligns well with a separate common class used by multiple Business Operations, while the BOs remain thin wrappers around message handling and adapter invocation. [1][5]

Sources:

A related issue shown in the retrieved material is an SMTP/TLS connection failure caused by SSL/TLS configuration problems, with the specific errors:

“ERROR #6085: Unable to write to socket with SSL/TLS configuration 'HTTPSCert', error reported 'SSL/TLS error in SSL_connect(), SSL_ERROR_SSL: protocol error, error:1408F10B:SSL routines:ssl3_get_record:wrong version number' + ERROR #6034: SMTP server connection failed during init command: <READ>GetResponse+5^%Net.SMTP.1.” [1]

One concrete point called out there is to verify that the SMTP operation is actually using the intended TLS configuration name, because the reported error referenced one configuration name while the screenshot showed a different one. In that example, the advice was to check whether the operation was using the configured TLS entry correctly. [1]

There is also evidence that using SMTP with TLS and an SSLConfiguration is a known topic in the InterSystems Developer Community, specifically “How to use SMTP protocol with TLS and SSLConfiguration.” [2]

If you are considering alternatives to email notifications, the retrieved material also shows examples of other notification channels:

• Telegram and email in the appmsw-telealerts solution [3][4]
• A Teams-style alternative is not documented in the returned material, but a workflow alert example explicitly says the target could be “a Telegram Operation or anything else really.” [5]
• AWS external messaging support is shown for SQS through the external messaging API, which indicates AWS messaging integration is available in retrieved examples, though SNS is not specifically documented in the returned material. [6]

Based on the retrieved material alone, the strongest guidance is:

1. Expect SMTP/TLS issues to happen in practice. [1]
2. First verify that the correct TLS/SSL configuration name is being used by your SMTP operation. [1]
3. If email remains problematic, alternative notification mechanisms such as Telegram/email hybrids or AWS messaging-related integrations are represented in the retrieved material. [6][3][4][5]

Sources:

A few additional things stand out from the retrieved material that may help make a fresh start easier to live with over the next decade:

• Keep using namespaces and databases with clear administrative separation, not just for globals vs routines, but as a broader design principle for maintainability. [1]
• Adopt a meaningful naming convention for environments and database roles, for example distinguishing DEV, QC, UAT, and PRD, and also whether a database is for data or code. [2]
• Consider separating stream data into its own database with global mapping if you store large %Stream properties that are rarely accessed. [2]
• Prefer persistent classes for application data instead of hardcoding direct global access, because that gives you schema, indices, SQL access, and safer long-term maintenance. [3][4]
• Design your global structures clearly up front and avoid ad-hoc key layouts if you do use globals directly. [4]
• Ensure persistent classes have appropriate indexes to support query requirements, and use indexes as part of the initial model design rather than adding them reactively later. [1]
• Make automated tests part of the foundation from day one, using %UnitTest. [1]
• Build in performance verification habits early: use the SQL query optimizer/query plan for SQL, and use tools such as ^PROFILE and ^TRACE to identify bottlenecks. [1]
• Review security at the architecture stage, including resources, roles, and application security, rather than treating it as a later hardening step. [1]
• Keep documentation and code comments maintainable from the start, using UDL or Studio-style comments so future developers can work effectively. [1]
• If you expect scale or distributed growth, evaluate early whether Mirroring, Sharding, or ECP are needed as part of the design. [1]

On your existing list specifically:

• Separating globals and routines is described as still recommended. One reason given is that the global store is a fast-changing database tied to mirroring, journaling, ECP, and sharding concerns, while the routine database should change rarely and be under special control. [2]
• Consistent class naming aligns with the convention that classes use capitalized word starts, for example CountryOrigin. [5]
• Search tables fit with the broader recommendation to ensure persistent classes have appropriate indices and to think about query needs up front. [1]

If I had to condense the strongest additions into a “second time around” checklist, it would be: define naming/environment conventions early, model data with persistent classes and indexes first, separate rarely used stream content if relevant, put testing/performance/security in place from the beginning, and design for operational separation and future scale. [1][2][3][4]

Sources:

You can install Embedded Git on your PROD servers as software, and you can also make it available instance-wide via %ALL using:

do ##class(SourceControl.Git.API).MapEverywhere()

This creates mappings so all namespaces on the instance can use the version installed in the current namespace, but each namespace still has to be configured independently. [1]

For installation, the package can be installed with:

zpm "install git-source-control"

or from a downloaded release archive with:

zpm "load /path/to/archive/git-source-control-release.tar.gz"

and setup is then done with:

do ##class(SourceControl.Git.API).Configure()

That configuration step is what initializes settings and can also initialize or clone a git repository. [1]

On your baseline-export question specifically, the available material shows that Embedded Git includes “a command-line utility to do a baseline export of items in a namespace,” and newer releases add that baseline export includes decomposed production items when production decomposition is enabled. [2][1]

For your question about doing this on PROD without enabling source control or without requiring it to be used, the material here does not describe a documented mode where Embedded Git is installed solely for baseline export or change tracking while source control remains disabled. What it does say is that namespaces must be configured independently, and Embedded Git’s purpose is to intercept edits so changes are reflected in the filesystem and git repository. [1]

If you want PROD or another non-development namespace to participate in a Git-based flow later, one documented approach is to configure Embedded Git there as well and “do a git pull there to load the incremental diff from a branch corresponding to the environment.” Changes deployed through Git are also logged in SourceControl_Git.DeploymentLog. [3][4]

Important : if using source control for interoperability, check the “Permit Enabling Automatic Refresh of Management Portal Pages” box in the management portal, at the page: Interoperability > Manage > Configuration > Interoperability Settings. This mitigates a potential for lost work. [1]

For your proposed phased rollout, the documentation also shows there is a “basic” mode intended to simplify working with Git in more prescriptive workflows, including a sync operation and branch-handling simplifications. [2]

Sources:

You can give the row ID a different SQL-visible name, but that does not replace the underlying object row ID used by the storage map. If your goal is mainly to avoid the default ID name colliding in SQL, use the class keyword SqlRowIdName to rename the SQL rowid column to something meaningful for your application. [1]

If you want a named IDKEY, there are two supported patterns: [1]

1. Property SomeId As %Integer [ Identity ];
   
   This behaves like the default IDKEY: it is automatically generated and not settable. [1]

2. Property SomeId As %Integer; with Index ... On SomeId [ IdKey ];
   
   This makes that property the object identity value, but you must set it yourself. Also, once saved, properties participating in an IdKey cannot be modified. [1]

In your example, xMDA [ Identity ] only defines an SQL identity column; it does not make xMDA the storage/object identity unless it is also the IdKey. Your current IdKey is PMKey On (Subscript1, Subscript2), so the object identity is based on those properties, not on xMDA. [1]

If you need to reference the actual row ID inside SqlComputeCode, use {%%ID}. That is the documented way to access the identity/row ID value in SQL compute code. [2]

So for your calculated property, instead of referencing {ID}, use {%%ID} in the compute expression. [2]

Your current design also means that ID is the system/internal row address, while a PrimaryKey is primarily for SQL/schema purposes. In Caché/IRIS, the %ID/IDKEY is what the system uses internally to identify and locate the row, while the primary key is what the application/schema exposes as the table key. These can be different. [3]

A practical way around your collision, therefore, is: [1][2][3]

• keep the internal row identity as %ID
• access it in computed SQL code using {%%ID}
• if needed, rename the SQL-visible rowid column with SqlRowIdName so your query can use another name instead of ID [1][2]

If the intention is to make xMDA itself be the true row/object identity, then it must participate as the IdKey; merely marking it [Identity] is not enough. [1]

Sources:

You can refresh the credentials by signing out the affected InterSystems Server Credentials account from VS Code, then signing in again so Server Manager prompts for the new password. The Server Manager extension exposes this through the Accounts menu in the VS Code activity bar, where the signed-in accounts can be managed and the account can be signed out. [1][2]

When you choose Sign Out, Server Manager lets you sign out the account after confirmation. If the password had previously been saved, you are also offered the option to delete the stored password, unless you changed the intersystemsServerManager.credentialsProvider.deletePasswordOnSignout setting. [1][2]

The stored password is not meant to live in settings.json unless you explicitly put it there yourself. Server Manager version 3 uses VS Code’s Authentication Provider API, and when you save the password it is stored securely in your workstation operating system’s keychain / native keystore. If you only press Enter instead of using the key button, the password is kept only until VS Code is restarted. [1][2][3]

Note: The best way to install and use this extension is by installing the InterSystems ObjectScript Extension Pack and following the documentation here. [1]

So the practical way to force a credential refresh is:

1. Open the Accounts menu in the VS Code activity bar. [1]
2. Find the relevant InterSystems Server Credentials signed-in account. [1][2]
3. Choose Sign Out. [1][2]
4. If offered, choose to delete the saved password as well. [1][2]
5. Reconnect to the server so VS Code / Server Manager prompts for the password again. [1][2]

There is also support for managing which extensions are trusted to use that account via Manage Trusted Extensions, but that is separate from changing the password itself. [1][2]

Sources:

The difference comes from the query dataset you send. In the examples retrieved, the C-FIND request built in ObjectScript includes not only PatientID and QueryRetrieveLevel, but also additional empty attributes such as AccessionNumber, StudyDescription, ModalitiesInStudy, ImageType, and StudyDate. Those are part of the request document and are used as requested return keys, so the response can include those fields when the remote system supports them. [1]

By contrast, the findscu example shown for command-line testing sends only PatientID with -m PatientID="102030". The trace you included also shows only these dataset elements in the request: QueryRetrieveLevel (STUDY) and PatientID. In the returned material, no extra return keys are added to that command-line request. As a result, the response shown contains only a small set of attributes: QueryRetrieveLevel, RetrieveAETitle, and PatientID. [2][1]

The retrieved material therefore supports this practical conclusion: if you want fields such as StudyDate, StudyDescription, PatientName, or StudyInstanceUID to appear in the C-FIND response, they need to be included in the query dataset as attributes you request back, just as the ObjectScript-built EnsLib.DICOM.Document example does with its extra DataSet.* entries. [1]

For debugging, the retrieved examples give you two useful ways to compare behavior:

• Use do ##class(DICOM.BS.QueryService).TestFind() to run the InterSystems sample query flow and inspect the resulting messages in the Message Viewer. [3]
• Use findscu for TCP-level simulation; the workshop example shows this approach for WorkList C-FIND testing from the command line. [3]

A concrete code example from the retrieved material for building a richer C-FIND request is: [1]

set findDicom = ##class(EnsLib.DICOM.Document).%New()
set tSC = findDicom.SetValueAt("1.2.840.10008.5.1.4.1.2.2.1", "CommandSet.AffectedSOPClassUID")
set tSC = findDicom.SetValueAt("32", "CommandSet.CommandField")
set tSC = findDicom.SetValueAt("1", "CommandSet.MessageID")
set tSC = findDicom.SetValueAt("0", "CommandSet.Priority")
set tSC = findDicom.SetValueAt("65278", "CommandSet.CommandDataSetType")

set tSC = findDicom.SetValueAt("STUDY", "DataSet.QueryRetrieveLevel")
set tSC = findDicom.SetValueAt("988333", "DataSet.PatientID")

set tSC = findDicom.SetValueAt("", "DataSet.AccessionNumber")
set tSC = findDicom.SetValueAt("", "DataSet.StudyDescription")
set tSC = findDicom.SetValueAt("", "DataSet.ModalitiesInStudy")
set tSC = findDicom.SetValueAt("", "DataSet.ImageType")
set tSC = findDicom.SetValueAt("", "DataSet.StudyDate")

The command-line tools and test flow shown in the retrieved workshop material for reproducing and tracing a query/retrieve scenario are: [3]

./dcmdir -c /shared/DICOMDIR --fs-id SAMPLEDICOMS --fs-desc /shared/dicom/descriptor /shared/dicom
./dcmqrscp --ae-config /shared/ae.properties -b DCM_QRY_SCP:3010 --dicomdir /shared/DICOMDIR

and then in IRIS:

do ##class(DICOM.BS.QueryService).TestFind()

If your goal is to test the published DICOM TCP service as an origin system from outside IRIS, the retrieved material confirms findscu as the command-line tool used for DICOM C-FIND simulation, and it also mentions DVTk RIS Emulator as a possible visual testing tool for FIND scenarios. [2][3]

So the most likely reason for the “short” response in your second circuit is that the command-line C-FIND request is much smaller and does not request the extra return attributes that the first circuit requests. [2][1]

Sources:

Your AGGREGATE(%TIMERANGE(...), Measures.Measure) pattern is the right general approach for a cumulative value over a time dimension, and it has been shown to work for running totals such as:

AGGREGATE(%TIMERANGE(YourTimeDimension.hierarchy.level,YourTimeDimension.hierarchy.level.CurrentMember),Measures.YourMeasure) [1]

A similar working example for cumulative totals is:

AGGREGATE(%TIMERANGE(DateOfSale.[Actual].[MonthSold].&,DateOfSale.CurrentMember), MEASURES.[Amount Sold])

used to return revenue from a starting month up to the current member on the rows axis. [3]

For your case, the likely issue is not the AGGREGATE syntax itself, because the sources show that AGGREGATE with %TIMERANGE works with ordinary measures like %COUNT and other standard measures. [1][3][4]

Your distinct-count measure is based on:

COUNT([dimension].[H1].[dimension].Members, EXCLUDEEMPTY)

and there is evidence that COUNT-based distinct member measures are a slower/special case, with InterSystems recommending the Distinct plug-in via %KPI() instead of using MDX COUNT for distinct member count. One reported solution says the provided Distinct plug-in is intended specifically to address the inefficiency of MDX COUNT distinct-member calculations. [5]

If you are counting distinct members, the documented alternative is to use the Distinct plug-in with %KPI() syntax rather than COUNT(...). The example syntax shown is:

%KPI("Custom DC Distinct","DISTINCT",1,"%level","<level spec>","%CONTEXT") [6]

and another source states that the built-in Distinct plug-in is the recommended approach for distinct member count instead of MDX COUNT. [5]

To troubleshoot the specific ERROR #5001: No member provider object found for member function: MEMBER(5) in your environment, the available guidance is to run the generated MDX in the DeepSee Shell and inspect the query/plan/trace there. The shell supports retrieving the last Analyzer query with #, showing the query plan with plan, and enabling trace with trace on. [7][8]

I do not see a source here that explains that exact #5001 error or proves exactly why your calculated measure fails inside AGGREGATE while %COUNT works. Based on the retrieved material, the safest guidance is:

1. Keep the cumulative pattern based on AGGREGATE(%TIMERANGE(...), measure) for running totals. [1][3]
2. Replace the distinct-count COUNT(...Members, EXCLUDEEMPTY) measure with a Distinct %KPI()-based measure if your goal is distinct member counting. [6][5]
3. Test the generated MDX in DeepSee Shell and inspect plan / trace to isolate whether the failure is in Analyzer-calculated-member evaluation. [7][8]

I do not have a source here that gives a direct fix for combining your exact COUNT(..., EXCLUDEEMPTY) calculated measure with AGGREGATE without error. [1][7][8][6][3][5]

Sources: