· Sep 18, 2023

Inbound Requests as a part of InterSystems Interoperability production

Hi Interoperability experts!

Recently noticed an interesting conceptual discussion in our Interoperability Discord channel to which I want to give more exposure.

All we know that typical InterSystems Interoperability production consists of the following chain:

Inbound adapter->Business Service->Business Process->Business Operation->Outbound adapter.

And Business Process (BO) here is always considered as a passive "listener" either on port/folder/rest API for an incoming data.

But often the reason to initiate the production process can be a data that could be retrieved by an active request to some port/rest api/s3 bucket. 

And the documentation says if a developer wants to have an http request in a production it should be implemented via business operation and outbound adapter pair that will receive the data and send it to business service. So the diagram looks like that:

So it is kind of a reverse logic here. Which is not something we teach in learning.intersystems.com and documentation

Should we introduce an idea of Inbound Request adapter? How do you manage it in real-life productions? Any other thoughts?

Discussion (4)2
Log in or sign up to continue

No discussion: Business Operation and Outbound adapter is a combination you should not break 

But to trigger a second Business OP You just need a Business Service that you kick,
no need for a Busines Process in between. Old ENSDEMO shows such examples.
eg. DemoRecodMapper

Here the FileService is the driving part.
another example uses a service that triggers itself DemoDashboard

It just lives on his timeout setting
Here it has nothing to do then updating some properties
But it could be anything. eg Kicking another Business Operation

A bunch of services with their InboundAdapters, such as FTP, Email, SQL, Kafka, and so on, connects to external server using this InboundAdapter directly, collect data and use it in Service. 

And only for TCP, HTTP, SOAP, REST by some reason decided that InboundAdapter now should start our own server, so, external services should connect to us. It's useful for sure, but the why we can't use it the other way too, is it somehow completely different? The logic in the workflow is still the same, it's Input data, which have to start the workflow.