In this video, we are going to do Hands on up, suck up a ten four, orchestrate distributed transactions
using a step functions.
So we are going to design a step functions state machine for implementing place order use cases.
You can see the image on the slide.
This is the place, the use cases.
So we will create an a step function state machine for implementing order fulfillment process with creating
these steps will be placed order after that update inventory, perform payment and if everything goes
well, we can succeed to order.
If something goes wrong in any step, we will revert back to payment inventory, remove order and go
to face statement.
For that purpose, please open the pseudocode code.
I have created separate lecture and section folder in the command text.
I have designed our architecture which will be state machine.
You can see that we are starting here and there is a task which is the place order accommodate the incoming
place order request and after that we will have a choice that explaining the is place order and we have
yes or no.
If yes we have separate task which is the update inventory.
If inventory updated, we can update the make the payment.
If payment successful, we can succeed to order with incoming request.
So this is the pivot.
But in every step we have, if an yes and no statement, if we can't place an order, we should go to
the paid order statement.
If we cannot update the inventory, we can revert back to inventory and remove the order.
If we cannot make the payment, we can revert back the payment, revert inventory, remove order and
fail order status.
So now I am going to open a console and design our workflow.
Go to step functions and state machines and click the create state machine.
We will create standard state machines.
So for that purpose, I'm going to select the standard and click the next button.
Here you can see that we can design our workflow with workflow to so now we will implement our logic.
So basically I will start with adding the lambda.
So this is the task that we can place order.
So that's why I'm going to say place order.
By this way, if you open the architecture, you can see that every lambda function is a microservices.
So we will perform distributed transaction across multiple microservices, which are the order inventory
payment microservices.
So these are the path from our order fulfillment process for the distributed transaction and implementing
the setup pattern.
So that's why we will select the lambda function as a task off to our every step.
And these lambda functions can be interacted on databases and also payment can be interact with the
third party services in order to perform payment operation.
So if you come back to our designer, the first step is place order.
So this will be placed order with lambda function.
And after that we will go to follow section and add the choice.
So this choice is confirmed with the is order placed or not?
This will be checked.
Response from the lambda function and according to response it is accommodate and redirect to this event
to the update inventory or the fail of the order place operation.
For that purpose we have defined two rules.
So you can come here and now we can edit the rule one if you open the rule one so a the condition,
we can get a condition from the dollar sign and that so is order placed.
And we can choose that the actual 2 billion construct and true is order placed.
Then we can continue our save this condition.
Okay.
And also, I have one more rule.
We can add the new rule, add the condition, and we can copy from the condition from this state.
You can see that we have checked the is order placed and if you come to rule two a the condition so
what will should be is order placed and again is equal to and the value is the building constant.
And you can see the force.
Look, we have to enforce is order placed and is also placed to enforce.
So now I am going to add the required steps which we can continue our support pattern implementation.
So if you add the additional lambda function, that means microservices, this will be the ah event
or database event or microservices.
For that purpose I'm going to say update inventory.
Okay.
So this is going to update eventually and if the order placed equal force, so that means we got exception.
I have the flow statement which is the fail I drag and drop the fail statement.
This will be a failed order.
Okay, so now I'm going to continue with the happy.
Is order placed?
Yes.
Now we have updated the inventory.
So now, again, I need to check the inventory update or not for that purpose.
The choice statement.
In the choice statement, we can add a rule definition.
So in the rule definition we have at the assignment condition, if you condition we can we have a dollar
sign and the.
Is.
Update inventory.
You can copy paste and choose the operator equal to and again volume constant and to the end post.
If the update inventory true, that means we will continue happy bet.
And again I'm going to add a new choice and condition is the same and this time I'm going to set a given
constant and say the false.
So we have two conditions.
Of course, we should put the dollar sign and that notation.
By this way, we can reach the output data from the previous task set.
Okay, click the save condition and now I'm going to remove the default result.
We can clear this one.
Yes.
As you can see that we have to choose after the update inventory.
Basically, we will use the happy pet which is the is updated one, two, three, four for the happy.
But I'm going to add an additional Microsoft lambda function, which is the payment microservices and
we can set the state name as a make payment.
This will be power from payment operations and if there is any problem for that action.
So in that case, if we cannot update the inventory again, I am going to add additional lambda function.
But this time this lambda function performed the revert back to inventory.
So that means what that means when we update the inventory, if there is a problem, that means if it
is cannot update the inventory, we should revert back to change from the dynamo db.
Think about that.
These microservices is communicate with the its database dynamo DB database table and it is updating
the status.
But this should be revert back to the statement.
So that's why we should additional lambda function in the choice statement.
We should give the name as to choice statement is inventory updated?
Okay.
So as you can see that we have implement the inventory part now focus on the payment part.
This is the last step in the distributed transaction, which is the order fulfillment for that purpose.
I am going to add a choice statement again.
This statement name is a, is payment done?
Immense success.
Okay.
So according to payment success operation, we can put a rule definition upon the rule, add the condition.
Again, I'm going to set a dollar sign.
That is payment.
Success.
And copy paste this variable we can choose is equal to and value is boolean construct and give as a
true.
So this is the first condition.
And the second condition is add a new choice, add condition and choose is equal to boolean constant.
And this time we will select the false.
And now I'm going to remove the default one.
Okay.
Very good.
So as you can see that we have set the payment success operation.
If payment success is correct and true, we basically make it success.
So if you drag and drop the success order, we will succeed the order.
That means order created successfully with full operations.
But when it comes to the fail is if the payment is the fail, we should also revert back to payment
operation for that purpose.
Drag and drop the lambda function.
And so this time we are going to revert back to payment.
So you can think about that in the payment operation, we can integrate with the third party system.
So even we perform the operation.
If we got an exception in our business logic or in our microservices, we should again go back to our
third party system and revert back to payment.
It is very important and critical when it comes to business related use cases, so that's why we add
additional lambda function, which is revert back to payment.
Okay.
After that, we perform the operation of the removing to order.
You can see that we will continue to our fail statement.
So basically before fail statement, we will one by one revert back the payment and revert back to inventory
for that purpose.
I'm going to add additional step in here after the revert.
Eventually we should remove the order.
As you know, that made me place an order.
We are creating an order in the automotive table.
By this way, if there is an exception, we should remove the order.
But after the payment, actually, we should not go to the directly end statement because this will
be also update the inventory for that purpose.
Select this task, which is the word payment.
If you go to the scroll down and next date, the next step should be the revert inventory.
You can scroll down and select the revert inventory.
Okay, very good.
So this time we are also design our worst case.
So if we over with our architecture, we can come to our first place.
And if I make it zoom out.
Okay, very good.
So basically we are accommodate to place order in the lambda function and these will be interact with
the Dynamo DB and insert a new order item in our database which is status of the creating.
So after that we are looking to is order placed correct or true or false according to these value.
If there is a force and that means the exception, we directly go to face statement and closed and to
this workflow.
If order placed successfully, that means create order successfully.
We go to the update inventory part.
We will update the inventory and deduct the item in Dynamo DV database.
And after that we will check that is matter updated.
If there is a problem when we updating inventory, then we will go to the full statement and go to revert
inventory face.
We will revert back to the our database and consistent make consistent data and after that remove order
because in the first place we will create an order.
In this phase we will create and remove an order and finish the workflow.
And if the inventory update successfully, we go for the payment operation and perform the payment.
If the payment is failed, we will revert payment and after the revert inventory, remove order.
And these are the compensated steps in the step function that we design and implement such a pattern.
If the payment is done, we will go to the success statement and finish the order.
So basically we will implement and design our order or according to our architecture that we see on
the image.
So as you can see that I have designed the workflow with the implementing saga pattern, but we don't
develop our order, inventory and payment microservice lambda functions.
So please take these as an assignment that will connect to your Dynamo DV databases and perform record
actions to complete this flow.
For now, I am not going to proceed this flow to create state machine.
Before that we should develop these order monetary and payment microservice lambda functions with rollback
methods.
So for that purpose please take an assignment and try to implement this logic before closing section.
Make sure that you have the all resources, AWG resources on your Atlas Cloud environment.
So as you can see that we don't create any state machine.
So that's why I don't expect any state mission or state function.
Please go to state function and make sure that you don't have any state machine on your environment.