If that is indeed the case I recommend this series of articles.

Sorry, meant:

Do ..Adapter.%Client.SetHttpHeader(name, value)

How about a slightly different architecture:

1. Create a table, visible in all namespaces called Requests - and from Data Source namespace add 1 row to it on every new message.
2. Create a table, visible in all namespaces called Ack which contains {RequestId, Namespace, State}
3. In each namespace create a Business Service which would:
   1. Poll Requests/Ack tables to get new unprocessed requests (no corresponding Ack record).
   2. If an unprocessed request is found create an Ack record and send a message in a local namespace for BP processing
   3. Maybe write a response after the message is processed (or do it in BP/ProxyBP/job)

Advantage of this architecture is that you decouple processing on a namespace level - so if a production in one namespace is in error state/down the rest can proceed. It also eliminates a single point of failure in namespace switching job.
 

tl;dr instead of pushing your event make consumers pull it whenever convenient.

Supply them in $horolog format. In a case of YYYY-MM-DD, try: $zdateh("YYYY-MM-DD", 3)

OnHandleCorsRequest is called automatically if a browser requests CORS.

To add to original answer a bit:

Do %response.SetHeader("Access-Control-Allow-Origin","*")

This is OK for development but for production use you need to replace * with a hostname of your web site.

pResponse.physicianFirstName

InterSystems provides a specialized Spark connector. Documentation. And, of course, you can use a JDBC driver.

As for Kafka here's some examples showing InterSystems IRIS<>Kafka interoperability:

• PEX Demo
• Kafka demo

Vadim Fedorov wrote you an email with details.

First of all I would recommend reading these two documents available on WRC (Software Distribution - Docs):

• InterSystems IRIS Adoption Guide
• InterSystems IRIS In Place Conversion Guide

First one explains the differences between Cache and InterSystems IRIS and the second one is about automated in-place conversion from Cache to InterSystems IRIS.

I would recommend the following steps:

• upgrade to 2016.2
  • This is the place to uplift your application - on the one hand it's still Cache so upgrade is simple, on the other the code, even with the new 2016.2 features would probably run fine on InterSystems IRIS
  • if you're using SQL - start using frozen plans
  • if you're using JSON - new JSON features become available here (dynamic objects)
• upgrade to 2018.1 (latest micro)
• perform in-place conversion to the latest InterSystems IRIS

On Windows execute:

<iris>\bin\irisdb -s <iris>\mgr

where <iris> is a root of an InterSystems IRIS installation.