We have come pretty far in our Saga Pattern Implementation in our last post. We have completed all the services that form a part of our Order Management Saga. Also, we have managed to start up an instance of the Axon Server and connect all our services to it.
Now is the time to see our Saga implementation in action.
To recap, below is our high-level plan for this series about Saga Pattern Implementation.
In Part 1, we spent our time learning about Saga Pattern and its use. We also set the groundwork for the Order Management Saga that we would implement.
Next, in Part 2, we started implementing the Order Management Saga. We finished with the Order Service and the Core-APIs.
Further on, in Part 3, we continued to implement the other services i.e. the Payment Service and the Shipping Service. We also set up the Axon Server that forms a core part of the Axon Framework.
In Part 4 (this post), we will test our Saga and see it in action.
If you’ve directly reached this post, I would strongly recommend you to go through all the above posts in order.
Understanding the Saga Pattern Implementation
To recap what our Saga is supposed to do, let’s revisit the illustration we looked at in the first post of this series.
Basically, the Order Service is where the Saga steps are defined. Even though the Saga spans three services, the Order Management Saga class acts as the orchestrator.
As can be seen in the illustration, the Saga is initiated by creating a new Order using the Order Service.
The communication between the services, however, is handled by means of the Axon Server. On starting the three services along with the Axon Server, we get the below view on the Axon Dashboard.
In other words, all three services are registered to the Axon Server. Also, all the commands that we have declared are registered as well.
Initiating the Saga
Now is the time to initiate the Saga. To do so, we can simply visit the Swagger UI exposed by the Order Service.
We are basically placing a new order using the Order API exposed by our service. On pressing the Execute button, a new order id is generated.
This will also initiate the Order Management Saga.
The Saga Execution
By creating a new Order, we have actually initiated the Saga. Let’s see what happened.
In Axon Server, you can see the Commands that have been issued in the Commands Tab.
As we can see here, the Create Order Command was issued by the Order Service. The Payment Service issued the Create Invoice Command. The Shipping Service issued the Create Shipping Command. Lastly, the Order Service also issued the Update Order Status Command.
These commands are also responsible for publishing events. We can see the count of the number of events in the Overview tab. See below:
If you remember, we have used Event Sourcing to store our Aggregates. In case you don’t know what is Event Sourcing, you can refer to a detailed post on Event Sourcing with Axon Framework and Spring Boot.
With Axon Server, you can look at the Event Store in the Search tab.
If you see closely, you will be able to see events on all Aggregates i.e. Order Aggregate, Payment Aggregate and the Shipping Aggregate.
All of these events occurred as part of the Order Management Saga. They were initiated just by creating a new Order.
We have successfully completed Saga Pattern Implementation using Axon Framework and Spring Boot.
Of course, a real Order Management Saga for a typical e-commerce setup will have lot many rules and possible outcomes. But we have kept the example simple to focus on the core concept behind Saga Pattern Implementation using Orchestration.
The code for this Saga Pattern example is available on Github.