Orchestrate Saga

This handler (com.rierino.handler.saga.SagaEventHandler) provides ability to coordinate end-to-end API calls, locally executing or distributing microservice steps across the platform.

Handler Parameters

Parameter	Definition	Example	Default
saga.state	Name of the state manager keeping saga definitions	customSaga	saga
response.stream	Name of the stream to post results when saga is completed or failed	response_product	response
saga.stream	Name of the stream to track results of saga steps	saga_product	saga
saga.system	Name of the system to track results of saga steps	kafka_default	-
event.system	Name of the default system to post requests to event runners	kafka_default	-
saga.timeout	Milliseconds of latency to allow before timing out any saga call	5000	10000
timer.pool	Number of threads to allow for scheduled sagas (if empty, handler does not allow scheduling)	10 ("default" for system default pool size)	-
roles.variable	Variable name to use for pulling user roles against allowed ones	userRoles	user.roles path in event payload

In case SagaEventHandler will have scheduling, it should follow one of the following configurations:

• Having a single replica of the runner only

• Deploying as StatefulSet and setting the timer.pool parameter for partition 0 only with "0.parameters.timer.pool" convention

Otherwise, the same saga would be executed by each replica with the same schedule.

773B

handler-saga-0001.json

Example Saga Handler Definition (Can be Imported on Element Screen)

Actions

StartSaga

Initiates execution of a new saga, using "sagaPath" parameter of the requesting event, or the request metadata path if not defined. The request is accepted only if there is an active saga matching this path.

Using sagaPath for initializing a new saga call allows nested saga flows for complex API scenarios.

StepSaga

Executes the next action after a saga step is completed by an event runner, using the saga id and step id in event saga metadata.

Unlike the other event handlers, SagaEventHandler is rarely called from within saga flows, as it acts as a coordinator rather than a simple task executor.