AllAccepted answers
Vic Sun · May 12

Ivan,

What you're saying generally makes sense. Because the mirror was flipping over and because of your network issues, the ECP connections didn't know where to connect. Do you understand the behavior now or did you still have an outstanding question?

Vic Sun · Mar 9

It's not possible to answer that question without knowing exactly what you did and probably looking at the system. What constitutes a "data mismatch"?

You could reach out to the WRC (InterSystems support).

Vic Sun · Feb 28

Scott, the SSL error is fairly generic. Using REDEBUG as suggested in one of the comments might give you more info. Otherwise, a network trace would be the ultimate source of truth in terms of why the SSL handshake is failing.

Vic Sun · Feb 28

It's tough to say without knowing your config and what exactly was done. For the second error at least it seems reasonably clear what could be causing it, maybe that will help to resolve the first error as well? I'm not an Apache expert so take my personal advice with a grain of salt, I just know that many people have found Mark's article to be helpful.
 

https://stackoverflow.com/questions/24060620/error-starting-apache-httpd-configuration-error-more-than-one-mpm-loaded

Vic Sun · Feb 8

Hi Scott,

Did you look at Web Servers for UNIX, Linux, and macOS? That page explains how to configure Apache to serve CSP files.

I'm not sure what you mean by calls to the management portal. If you have the standalone Apache / gateway set up appropriately, you can serve the portal through (presumably default) port 80, ex. go to http://<hostname>:80/csp/sys/UtilHome.csp, rather than attempting to use your private web server port.

Really the independent Apache is the main piece, you can consider the standalone web gateway to be a module on that Apache web server.

Hope that helps.

Vic Sun · Jan 14

Connor,

I'm not sure I understand what you're describing. Are you familiar with InterSystems mirroring? In short, it is a method of keeping two separate instances' data in sync, and can be used for reporting purposes. Do you really need just the deltas, and if so in what way would you be using them?

Vic Sun · Jan 10

Hello Scott,

I think the following doc section "Deploying a Production" is relevant:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=EGDV_deploying#EGDV_exporting_production

"If a production uses XSD schemas for XML documents or uses an old format schema for X12 documents, the schemas are not included in the XML deployment file and have to be deployed through another mechanism. InterSystems IRIS can store X12 schemas in the current format, in an old format, or in both formats. When you create a deployment file, it can contain X12 schemas in the current format, but it does not contain any X12 schemas in the old format or any XSD schemas for XML documents. If your production uses an old format X12 schema or uses any XSD XML schema, you must deploy the schemas independently of deploying the production. For the schemas that are not included in the deployment file, they can be deployed to a target system by either of the following means:

If the XML or X12 schema was originally imported from an XSD or SEF file and that file is still available, import the schema on the target system by importing that file. XSD files can be used to import XML schemas and SEF files can be used to import X12 schemas.

Export the underlying InterSystems IRIS global that contains the schema and then import this on the target system. To export a global, select System Explorer > Globals, select the desired globals and then select Export. The X12 schemas are stored in the EnsEDI.Description, EnsEDI.Schema, EnsEDI.X12.Description, and EnsEDI.X12.Schema globals. The XML schemas are stored in the EnsEDI.XML.Schema global. See “Exporting Globals” in the Using Globals guide for details on exporting globals."