workflows.md

Architecture: Workflows

Successful Workflow

1. User sends an HTTP POST request with the expected payload to Saga Client to start a new transaction.

2. Saga Client generates a new transaction ID, starts a new instance of the orchestrator (assigning the transaction ID as the orchestrator instance ID) and provides the transaction ID as part of the HTTP POST response, allowing the requester to pool the saga status through the Saga Status Checker service.

3. Saga Orchestrator calls the Saga Orchestrator Activity to persist the initial Saga state as PENDING on Cosmos DB.

4. Saga Orchestrator calls the Command Producer Activity to produce a new command to Event Hubs to validate bank accounts. In the meantime, it waits for an external event that tells the result of the validation to move to the next step of the workflow.

5. Validator consumes the command generated by the orchestrator through Event Hubs, simulates a task that validates bank accounts, produces a new successful event to Saga Reply Event Hubs and persists the service data on Cosmos DB.

6. Saga Event Processor consumes the event generated by the Validator, persists the event data on Cosmos DB and raises an external event to Saga Orchestrator that contains the event name.

7. Saga Orchestrator receives the external event response and calls the Command Producer Activity to produce a new command to Event Hubs and starts the transfer process. In the meantime, it waits for an external event that tells the result of the transfer to move to the next step of the workflow.

8. Transfer consumes the command generated by the orchestrator through Event Hubs, simulates credit and debit operations on both bank accounts, produces a new successful event to Saga Reply Event Hubs and persists the service data on Cosmos DB.

9. Saga Event Processor consumes the event generated by the Transfer, persists the event data on Cosmos DB and raises an external event to Saga Orchestrator that contains the event name.

10. Saga Orchestrator receives the external event response and calls the Command Producer Activity to produce a new command to Event Hubs to create the transaction receipt. In the meantime, it waits for an external event that tells the result of the receipt generation process to finish the Saga.

11. Receipt consumes the command generated by the orchestrator through Event Hubs, generates a random receipt ID, produces a new successful event to Saga Reply Event Hub and persists the service data on Cosmos DB.

12. Saga Event Processor consumes the event generated by the Receipt, persists the event data on Cosmos DB and raises an external event to Saga Orchestrator that contains the event name.

13. Saga Orchestrator receives the external event response and calls the Saga Orchestrator Activity to update the Saga state to SUCCESS on Cosmos DB.

Note: The requester can check the saga status and the orchestrator runtime status anytime by the Saga Status Checker through an HTTP GET request.

Compensation Workflow

1. User sends an HTTP POST request with the expected payload to Saga Client to start a new transaction.

2. Saga Client generates a new transaction ID, starts a new instance of the orchestrator (assigning the transaction ID as the orchestrator instance ID) and provides the transaction ID as part of the HTTP POST response, allowing the user to query the status of the saga and the orchestrator runtime.

3. Saga Orchestrator calls the Saga Orchestrator Activity to persist the initial Saga state as PENDING on Cosmos DB.

4. Saga Orchestrator calls the Command Producer Activity to produce a new command to Event Hubs to validate bank accounts. In the meantime, it waits for an external event that tells the result of the validation to move to the next step of the workflow.

5. Validator consumes the command generated by the orchestrator through Event Hubs, simulates a task that validates bank accounts, produces a new successful event to Saga Reply Event Hubs and persists the service data on Cosmos DB.

6. Saga Event Processor consumes the event generated by the Validator, persists the event data on Cosmos DB and raises an external event to Saga Orchestrator with the event name.

7. Saga Orchestrator receives the external event response and calls the Command Producer Activity to produce a new command to Event Hubs and starts the transfer process. In the meantime, it waits for an external event that tells the result of the transfer to move to the next step of the workflow.

8. Transfer consumes the command generated by the orchestrator through Event Hubs, simulates credit and debit operations on both bank accounts, produces a new successful event to Saga Reply Event Hubs and persists the service data on Cosmos DB.

9. Saga Event Processor consumes the event generated by the Transfer, persists the event data on Cosmos DB and raises an external event to Saga Orchestrator with the event name.

10. Saga Orchestrator receives the external event response and calls the Command Producer Activity to produce a new command to Event Hubs to create the transaction receipt. In the meantime, it waits for an external event that tells the result of the receipt generation process to finish the Saga.

11. Receipt consumes the command generated by the orchestrator through Event Hubs, an error occurs on generating the receipt ID, the FAILED task result is persisted on Cosmos DB and a new failed event is produced to Saga Reply Event Hub.

12. Saga Event Processor consumes the event generated by the Receipt, persists the event data on Cosmos DB and raises an external event to Saga Orchestrator with the FAILED state.

13. Saga Orchestrator receives the external event response and calls the Command Producer Activity to produce a new compensation command to Event Hubs to compensate the transfer process. In the meantime, it waits for an external event that tells the result of the compensating transaction to finish the Saga.

14. Transfer consumes the compensation command generated by the orchestrator through Event Hubs, undo the credit and debit operations on both bank accounts, produces a new compensation event to Saga Reply Event Hubs and persists the service data on Cosmos DB.

15. Saga Event Processor consumes the compensation event generated by the Transfer, persists the event data on Cosmos DB and raises an external event to Saga Orchestrator with the event name.

16. Saga Orchestrator receives the external event response and calls the Saga Orchestrator Activity to update the Saga state to CANCELLED on Cosmos DB.