Thank you for your explanations. The procedure you described sounds somewhat complex, but (as ultimately proven by your report) feasible. Together we are 5 colleagues who deal with the development and administration of interfaces in addition to other topics. We would need external help from our systems department to set up a certificate-based access procedure. I can see the day coming when the certificate has expired or something else has happened and we have locked ourselves out with no way of quickly re-establishing this access on our own. But thanks again for the suggestion, I will definitely look into whether this could be an option for us.
Thank you very much for your feedback. After some back and forth and failed attempts, I have now decided on a different approach. The reasons for this are on the one hand that an export of all 133500 records would take something like 12h and in case of an error all preliminary work is gone.
Furthermore, even with 1000 records the transfer to a FHIR bundle again ran into a STORE error. All in all it is more reasonable to split the export into smaller packages. I got a handle on the problem by now initiating export at 500 objects and persistently storing the IDs of the handled records so they can be ignored on the next run.
The process is called on a timed basis every 5 minutes and works in chunks until all resources are exported. This runs since 1h now, and looks good so far.
Regards, Martin
Thanks for the hint. In the past it was the port of the packaged webserver, that is true. Meanwhile we're using the Apache server that comes with the distribution's package manager in combination with the Intersystems webgateway. We're just using the same port configuration. I hope this at least alleviates the problem described, but unfortunately does not change the problem that all web apps, including the management portal, are addressed via the same port.