1
00:00:00,090 --> 00:00:06,390
In this video, we are going to apply message filter pattern in Amazon since we can see that we are

2
00:00:06,390 --> 00:00:12,210
in here, Amazon Sans and we will apply the message filter pattern in using the Amazon Sans.

3
00:00:12,540 --> 00:00:16,400
So Amazon Sans has a message filtering feature by default.

4
00:00:16,410 --> 00:00:22,020
Amazon says topic subscriber receives every message published to the topic.

5
00:00:22,140 --> 00:00:28,260
In order to receive a subset of the message, a subscriber must assign a filter policy to the topic

6
00:00:28,260 --> 00:00:29,190
subscription.

7
00:00:29,460 --> 00:00:36,000
So a filter policy is a simple JSON object containing attributes that define which message the subscriber

8
00:00:36,000 --> 00:00:36,690
receives.

9
00:00:37,110 --> 00:00:42,900
When we publish a message to topic, Amazon Essence compares the message attributes to the attribute

10
00:00:42,900 --> 00:00:46,470
in the filter policy for each of the topic subscriptions.

11
00:00:46,680 --> 00:00:51,810
If any of the attributes match Amazon SMSs, send the message to the subscribers.

12
00:00:51,900 --> 00:00:56,280
Otherwise, Amazon says skip the subscriber without sending the message.

13
00:00:56,490 --> 00:01:02,370
If subscription doesn't have any filter policy, the subscription receives every message published to

14
00:01:02,370 --> 00:01:03,270
its topic.

15
00:01:03,570 --> 00:01:10,380
So we will apply these filter message publish to topics with creating event filter for the subscription

16
00:01:10,380 --> 00:01:11,520
of the inventory.

17
00:01:12,120 --> 00:01:17,330
As you remember that in the event of microservices, we have a business logic and business rules.

18
00:01:17,340 --> 00:01:23,250
So if we open the widgets to the code and go to indexes, we can remember that we have a business rule

19
00:01:23,250 --> 00:01:30,780
that in the incoming order type should be ship required or if the order type is not shipment required.

20
00:01:30,810 --> 00:01:34,860
We are throwing an exception, but this happens an invocation.

21
00:01:34,860 --> 00:01:42,600
So that means Lambda invocation happens and this return an error into business rule of the Lambda function

22
00:01:42,600 --> 00:01:43,010
code.

23
00:01:43,020 --> 00:01:49,440
But there is another way which is the best practice to use sans filter policy for that purpose.

24
00:01:49,440 --> 00:01:53,570
Please open the a merchant console and go to order topic.

25
00:01:53,580 --> 00:02:00,150
So basically if you scroll down you can see the all subscriptions and these are the records in our architectures.

26
00:02:00,150 --> 00:02:08,430
So we will set a filter policy on the Amazon sans subscription of the inventory queue and we will set

27
00:02:08,430 --> 00:02:11,550
that if the order type is shipment required.

28
00:02:11,580 --> 00:02:18,300
After that, we will subscribe to Amazon sans topic and we will add the message into queue.

29
00:02:18,330 --> 00:02:25,980
Otherwise, we don't want to relate it and interested in this topic message and we don't want to process

30
00:02:25,980 --> 00:02:28,950
this message to the event through microservices.

31
00:02:29,130 --> 00:02:31,680
Okay, let's implement these feature for that purpose.

32
00:02:31,680 --> 00:02:39,030
Please go to Psns on a console, go to subscriptions and open the inventory queue subscription.

33
00:02:39,030 --> 00:02:43,860
If you click this ID, this is a subscription page and if you scroll down you can see the subscription

34
00:02:43,860 --> 00:02:44,820
filter policy.

35
00:02:44,820 --> 00:02:46,710
We don't have defined any policy.

36
00:02:46,710 --> 00:02:53,370
Now if you click the edit button, we will define the policy in the subscription filter policy section.

37
00:02:53,370 --> 00:02:58,850
If you expand this line of what we will copy and paste our JSON filter policy.

38
00:02:58,860 --> 00:03:06,660
So in this stage, I would like to remember the incoming object style of our post operation.

39
00:03:06,660 --> 00:03:12,000
If you open the command text of the our lecture folder, you can see that this is the expected payload.

40
00:03:12,000 --> 00:03:17,850
So please copy this payload and come back to our window of the subscription filter policy and paste

41
00:03:17,850 --> 00:03:18,420
in here.

42
00:03:18,420 --> 00:03:22,860
So basically I would like to remove these attributes and put only type attribute.

43
00:03:22,980 --> 00:03:28,860
So this is the way that we are going to define subscription filter policy.

44
00:03:28,860 --> 00:03:38,230
But at this stage also I have to add an array because we can add one more item into the type of the

45
00:03:38,310 --> 00:03:39,720
these or the data.

46
00:03:39,720 --> 00:03:47,250
So that's why we have to put an array brackets in here and save these files in order to activate the

47
00:03:47,250 --> 00:03:52,710
subscription filter policy with the incoming event, JSON or type shipment requirement.

48
00:03:52,710 --> 00:03:58,860
So basically this will look at the incoming event JSON object and check the type attribute and the type

49
00:03:58,860 --> 00:04:00,360
is shipment requirement.

50
00:04:00,390 --> 00:04:05,430
After that, it is direct to our order topic to the event.

51
00:04:05,820 --> 00:04:12,810
Otherwise it is not redirect to the item in the inventory queue and this will skipping our inventory

52
00:04:12,810 --> 00:04:13,830
Q Subscription.

53
00:04:13,830 --> 00:04:20,310
If you scroll down and click the save change, we have successfully define our subscription filter policy

54
00:04:20,310 --> 00:04:22,290
and you can see the details in here.

55
00:04:22,290 --> 00:04:25,380
So now it is time to test our application.

56
00:04:25,380 --> 00:04:32,880
Since we have three subscription in the order topic, we can see that one of the subscription has subscription

57
00:04:32,880 --> 00:04:39,240
filter policy and when we send different types of to order request, it won't be published to inventory

58
00:04:39,240 --> 00:04:41,970
queue and inventory lambda microservices.

59
00:04:41,970 --> 00:04:48,750
So let's test these actions if you open the postman and if you come here, first of all, I would like

60
00:04:48,750 --> 00:04:51,210
to send the same payload again.

61
00:04:51,580 --> 00:04:56,520
HTTP post request will be sent with this payload and the type is shipment required.

62
00:04:56,520 --> 00:04:59,890
If you click the send button you will see that we.

63
00:05:00,270 --> 00:05:01,950
Get successful response.

64
00:05:01,950 --> 00:05:09,240
And that means so that means in this case, all these downstream microservices invoked and invocation

65
00:05:09,240 --> 00:05:10,260
happened one time.

66
00:05:10,260 --> 00:05:18,240
So if you go back to our a main console and go to Lambda, open the inventory microservices, if you

67
00:05:18,240 --> 00:05:23,610
come here and check the inventory and notification microservices, if you go to inventory microservice

68
00:05:23,610 --> 00:05:30,060
and select the monitor and we logs in cloud logs, you can see the an invocation happens in this case

69
00:05:30,060 --> 00:05:31,560
if you open this.

70
00:05:32,520 --> 00:05:34,710
Look, you can see that this look is.

71
00:05:36,000 --> 00:05:37,740
Including incoming message.

72
00:05:37,740 --> 00:05:44,040
And if you check the message of the hour sending, you can see the type is ship required.

73
00:05:44,040 --> 00:05:45,000
And it's the same way.

74
00:05:45,000 --> 00:05:49,410
If you look at the notification microservices, go to monitor and wave cloud watch logs.

75
00:05:49,710 --> 00:05:56,820
You should also verify that this is triggered from the same payload that we sent from the AC to post

76
00:05:56,820 --> 00:05:57,450
request.

77
00:05:57,450 --> 00:06:00,270
And as you can see that the type is required.

78
00:06:00,480 --> 00:06:01,710
Okay, very good.

79
00:06:01,710 --> 00:06:09,720
So we have verified that both notification and microservices triggered with our HTTP post operation.

80
00:06:09,720 --> 00:06:13,160
So now I'm going to send another HTTP post request.

81
00:06:13,210 --> 00:06:18,780
Please open the postman and this time I'm going to change the type as a notification.

82
00:06:20,130 --> 00:06:24,240
So click the send button and see what's happened.

83
00:06:24,270 --> 00:06:27,730
Again, we got the successfully finished Operation Message.

84
00:06:27,750 --> 00:06:35,440
If you go back to our logs, so now if you come to event or microservices, we've again the cloud logs.

85
00:06:35,460 --> 00:06:38,190
So this time we don't see any location.

86
00:06:38,190 --> 00:06:45,390
See that this is the last invocation that only includes the message from the type as ship required.

87
00:06:45,420 --> 00:06:52,050
If we check the notification microservices, weaving, cloud, watch logs, we can see that this time

88
00:06:52,050 --> 00:07:00,930
notification also has one more invocation and this is the including the type of the order as a notification.

89
00:07:00,930 --> 00:07:04,980
If you export this, you can see that you scroll down.

90
00:07:04,980 --> 00:07:06,450
This is the second invocation.

91
00:07:06,450 --> 00:07:11,190
The first invocation is ship required and the second invocation type is notification.

92
00:07:11,190 --> 00:07:18,000
So as you can see that we have successfully define event filter of the subscription of the inventory

93
00:07:18,000 --> 00:07:21,240
queue and verify that when we set the event filter.

94
00:07:21,270 --> 00:07:28,110
This is not invoke our inventory lambda microservices, but notification microservices invoke in two

95
00:07:28,110 --> 00:07:30,090
times with different order types.

96
00:07:30,090 --> 00:07:37,920
So for that case, if you go back to our we used to do code, open the indexes, now we can remove this

97
00:07:37,920 --> 00:07:38,460
condition.

98
00:07:38,460 --> 00:07:43,890
We don't need this condition now we can delete this condition or remove this condition because because

99
00:07:43,890 --> 00:07:51,000
for now it is impossible to invoke different type of the orders to our inventory of microservices so

100
00:07:51,000 --> 00:07:56,850
we can remove these conditions and remove this validation in our actual business logic in the inventory

101
00:07:56,850 --> 00:07:57,900
lambda function code.