Concatenation of mediators

[delcroip]

We were wondering if there is a way to concatenate mediators or routes with openHIM functionality so that e.g. the success of the first mediator triggers the execution of the second one.

We have tried something now by having two mediators A and B where mediator A executes its expression and passes the result to mediator B with a POST request which finalizes the process by also executing its expression and sending back a response but this approach have a performance toll because it generate more traffic (8) isntead of (6)

Traffic using the workarround described

1. Ext system --> openHIM
2. openHIM --> A
3. (2nd Mediator)A --> openHIM
4. (2nd Mediator) openHIM --> B
5. (2nd Mediator) B --> openHIM
6. (2nd Mediator) openHIM -->A
7. A --> openHIM
8. openHIM --> Ext system

Traffic that should happen

1. Ext system --> openHIM
2. openHIM --> A
3. A --> openHIM
4. (2nd Mediator) openHIM --> B
5. (2nd Mediator) B --> openHIM
6. openHIM --> Ext system

Thanks in advance

[BMartinos]

Hi @delcroip

I think if I understand your question correctly this has to do with chaining mediators together to complete a flow of business logic to implement.

There are a few ways this can possibly be achieved and depends on your specific needs and constraints (server resources / http request duration's etc).

OpenHIM mediators at its fundamentals are just micro services that communicate back to OpenHIM in a specific defined format. A Mediator doesn't technically have to respond to the OpenHIM in the mediator format, but then we dont have visibility into the various orchestrations that took place.

The condition of your routing will however sit within the relevant Mediator itself and not in the OpenHIM (The OpenHIM does the routing, not the business logic to be applied).

To avoid round trips via the OpenHIM, the Mediators itself should handle this.
Below is an example of how your scenario could be approached:

1. Ext system --> openHIM
2. OpenHIM --> A
3. A --> B
4. B --> openHIM
5. openHIM --> Ext system

Example Diagram:
http://www.plantuml.com/plantuml/png/lLEzZY8n3ExdAQofc69qFSK9aEvqLw0xmPRRXCG3bZ8EcpYxyFORXc68iaXqsyR-VlpPMGHHNc9lg_hNIM1x3e9z3UrF-7T4_lDtFOSNhpWeBUGODlWMCKWr5g5DZJbm3ZFg6bX6EI0BQJMWVYkoQAexAe7MQ4Y9yx1Ce2soWQCwMwSCY8DxiSeReSrz3KfJjHiqm6CuEWvOrMDV_TNZ4sGXcNjTtRmgTcb2_z3p2bvvrjF-8B13CDHrw94bzKpj7ZNIEneWXcLJvGBG5kay7RGCQ9hyMo9QFOZeltSQGyZJmHFgA0Yx68WlDUlsf2z9hTKvnHHSZwb9qBEouAzdbXZGTyxtQ9fIimnfCtWhhWS-I0xPPgO91k5XHSJQHZCQKCRGvMALBOqcMeE2la-F8DcF2A8aXgOyckbCCsEtjwkhZf9CJZMP6pdXnot0_EFaQvh8YVU9_vwVjeGicSx8bArmWMnYRpy1

[delcroip]

thank you,

We will do it like that but we'll need to hardcode the chaining logic into the mediators meaning that we will have to duplicate the mediator if it needs to be used in different chains event if its other actions don't change

Br

[BMartinos]

Sure, but this all depends on your implementation and how flexible you need to make it.

Your mediator can be developed to accept configuration via Environment variables or other config to make it re-usable and flexible. You can also dockerize the mediator making it much easier to re-use with alternative config, and allow it to better scale horizontally if need be.

At Jembi we have also been working on a common Mediator written in NodeJS that could potentially handle this kind of logic if configured correctly. The mediator doesnt require any additional coding and is purely configured via JSON config files to define the endpoint to listen on and the various business logic to apply. We have been making use of this common mediator to define endpoints which contain business logic to call other endpoints and complete our relevant flows:
https://github.com/jembi/openhim-mediator-mapping (Docs needs some updating though)

[delcroip]

Thanks, I need to have a closer look at this one,

On our side we develop the same kind of generic mediator using openfn-core as engine
https://github.com/SwissTPH/openfn-openhim-mediator ; its configuration is done through openHIM mediator config but I am always looking to avoid duplicates because it can lead to discrepancies like changing the credential of one mediator but not on this other... In my ideal mediation world each system should have inbox and outbox mediators that manage the credentials and the business logic is done by "internal" mediator and the "route" are defining the path between one system outbox and the other system inbox.

br

[BMartinos]

Great thanks @delcroip

This looks interesting and will dive a bit deeper into this :)