In this video, we are going to apply message filter pattern in Amazon since we can see that we are
in here, Amazon Sans and we will apply the message filter pattern in using the Amazon Sans.
So Amazon Sans has a message filtering feature by default.
Amazon says topic subscriber receives every message published to the topic.
In order to receive a subset of the message, a subscriber must assign a filter policy to the topic
subscription.
So a filter policy is a simple JSON object containing attributes that define which message the subscriber
receives.
When we publish a message to topic, Amazon Essence compares the message attributes to the attribute
in the filter policy for each of the topic subscriptions.
If any of the attributes match Amazon SMSs, send the message to the subscribers.
Otherwise, Amazon says skip the subscriber without sending the message.
If subscription doesn't have any filter policy, the subscription receives every message published to
its topic.
So we will apply these filter message publish to topics with creating event filter for the subscription
of the inventory.
As you remember that in the event of microservices, we have a business logic and business rules.
So if we open the widgets to the code and go to indexes, we can remember that we have a business rule
that in the incoming order type should be ship required or if the order type is not shipment required.
We are throwing an exception, but this happens an invocation.
So that means Lambda invocation happens and this return an error into business rule of the Lambda function
code.
But there is another way which is the best practice to use sans filter policy for that purpose.
Please open the a merchant console and go to order topic.
So basically if you scroll down you can see the all subscriptions and these are the records in our architectures.
So we will set a filter policy on the Amazon sans subscription of the inventory queue and we will set
that if the order type is shipment required.
After that, we will subscribe to Amazon sans topic and we will add the message into queue.
Otherwise, we don't want to relate it and interested in this topic message and we don't want to process
this message to the event through microservices.
Okay, let's implement these feature for that purpose.
Please go to Psns on a console, go to subscriptions and open the inventory queue subscription.
If you click this ID, this is a subscription page and if you scroll down you can see the subscription
filter policy.
We don't have defined any policy.
Now if you click the edit button, we will define the policy in the subscription filter policy section.
If you expand this line of what we will copy and paste our JSON filter policy.
So in this stage, I would like to remember the incoming object style of our post operation.
If you open the command text of the our lecture folder, you can see that this is the expected payload.
So please copy this payload and come back to our window of the subscription filter policy and paste
in here.
So basically I would like to remove these attributes and put only type attribute.
So this is the way that we are going to define subscription filter policy.
But at this stage also I have to add an array because we can add one more item into the type of the
these or the data.
So that's why we have to put an array brackets in here and save these files in order to activate the
subscription filter policy with the incoming event, JSON or type shipment requirement.
So basically this will look at the incoming event JSON object and check the type attribute and the type
is shipment requirement.
After that, it is direct to our order topic to the event.
Otherwise it is not redirect to the item in the inventory queue and this will skipping our inventory
Q Subscription.
If you scroll down and click the save change, we have successfully define our subscription filter policy
and you can see the details in here.
So now it is time to test our application.
Since we have three subscription in the order topic, we can see that one of the subscription has subscription
filter policy and when we send different types of to order request, it won't be published to inventory
queue and inventory lambda microservices.
So let's test these actions if you open the postman and if you come here, first of all, I would like
to send the same payload again.
HTTP post request will be sent with this payload and the type is shipment required.
If you click the send button you will see that we.
Get successful response.
And that means so that means in this case, all these downstream microservices invoked and invocation
happened one time.
So if you go back to our a main console and go to Lambda, open the inventory microservices, if you
come here and check the inventory and notification microservices, if you go to inventory microservice
and select the monitor and we logs in cloud logs, you can see the an invocation happens in this case
if you open this.
Look, you can see that this look is.
Including incoming message.
And if you check the message of the hour sending, you can see the type is ship required.
And it's the same way.
If you look at the notification microservices, go to monitor and wave cloud watch logs.
You should also verify that this is triggered from the same payload that we sent from the AC to post
request.
And as you can see that the type is required.
Okay, very good.
So we have verified that both notification and microservices triggered with our HTTP post operation.
So now I'm going to send another HTTP post request.
Please open the postman and this time I'm going to change the type as a notification.
So click the send button and see what's happened.
Again, we got the successfully finished Operation Message.
If you go back to our logs, so now if you come to event or microservices, we've again the cloud logs.
So this time we don't see any location.
See that this is the last invocation that only includes the message from the type as ship required.
If we check the notification microservices, weaving, cloud, watch logs, we can see that this time
notification also has one more invocation and this is the including the type of the order as a notification.
If you export this, you can see that you scroll down.
This is the second invocation.
The first invocation is ship required and the second invocation type is notification.
So as you can see that we have successfully define event filter of the subscription of the inventory
queue and verify that when we set the event filter.
This is not invoke our inventory lambda microservices, but notification microservices invoke in two
times with different order types.
So for that case, if you go back to our we used to do code, open the indexes, now we can remove this
condition.
We don't need this condition now we can delete this condition or remove this condition because because
for now it is impossible to invoke different type of the orders to our inventory of microservices so
we can remove these conditions and remove this validation in our actual business logic in the inventory
lambda function code.