03. High level view

As defined in Domain model Section, each business process step is executed in a different service, which respects the choreography approach. Sapher provides a generic implementation of these steps, which are, from now on, entitled as “Sapher Steps”.

Therefore, each microservice belonging to a distributed transaction should install Sapher and define the sapher steps in which they are an active participant - as explained in the Getting started guide.

For this reason, a sapher step must have an input handler and can have multiple response handlers. In Sapher, an input handler is called “HandlesInput” and a response handler “HandlesResponse”.

The figure above illustrates this in an example scenario constituted by three microservices, A, B, and C. Service A contains two SapherSteps, one triggered by user action and another by an external system. Service B and C listen to the output of Service A triggering their own SapherSteps and publishing messages that service A can listen to as responses, using response handlers, and marking the business process step as successful. Finally, service C also listens to service B output to mark its own SapherStep as successful. Service C does not provide any output, as it is the final step of the business process. In each SapherStep, state management and persistence, idempotency, retries, and timeouts are managed by Sapher entirely.