Couple of things I'm not sure of:

  • what is pCompletionKey  used for? Can that be used as a unique reference for that invocation of SendRequestAsync?
  • Is there such a thing as a sleep "Status" to use as Quit for OnRequest? Or do I need to loop until done? Will HANG in this case release the resources used by the process?
  • if the target operation responds with an error is that handled by OnResponse or only OnError?

The CompletionKey is a 'tag' which you can attach to each async call. So you can distinguish them in the OnResponse by that tag.

Just 'Quit' the OnRequest, Ensemble will call the OnResponse when needed.

At the end (all Requests have responded or an optional time-out has occurred) the OnComplete will be called.

If the target operation has responded with a error-message in the Response message it will be in the OnResponse.

(I think) the OnError will be called if the target operation exits with a status code of not $$$OK

The obvious answer would be 'it depends' ;-)

But essentially that is true, if you want out-of-the box Ensemble supported functionality (HL7, DICOM, etc) then it would be hard to match that within a reasonable time-frame and budget. Also if you want an all-purpose routing engine Ensemble would be hard to beat.

But if you have a specific problem in mind, a custom solution could be a better option.

IMHO Ensemble's queuing mechanism is pretty dumb, a custom queue could be more intelligent and dynamic, with dynamic actor pools and auto-start/stop queues.

Also stuff such as itinerary based routing, true publish and subscribe and complex event processing could then be an option (if needed).

And, also important, standard Caché is much cheaper then Ensemble (let alone HealthShare).

I assume your interfaces are all part of a bigger application, AFAIK there is no way to span an Ensemble Production across namespaces and from a EIA/ESB point-of-view having separate (connected) productions running on a single Ensemble instance doesn't make much sense.

Your idea to have individual builds and deployments makes sense though, but that would be more stuff that a dedicated build/deployment tool should be able to do

Considering myself among the 'the older and more established users of InterSystems technologies' ;-) we've always used the setup where each developer has his/hers own development machine. How the 'sandbox' namespace is called is not relevant. We use Git to tie the stuff together (more and more automated). It is allowed, or even encouraged, to use different versions of Caché or (in our case) Ensemble, which sometimes results in code that is not compatible with the current Production version, but we detect that in our QA phase and that might trigger discussions wether to upgrade Production if a used incompatible feature is of great value.

Having a separate development sandbox leaves room for experimenting which you wouldn't have if every developer is working in the same namespace, where in my opninion 'not to step on each others toes' would be much too constraining.

It will probable the same when Atelier takes off, some of us will be using that while others will stick to Studio or even brew their own in MS Code.