This blog covers the final session of Integrate 2020 day -2 which is “Messaging Patterns with Azure AIS” by our Azure MVP – Wagner Silveria
Wagner Silveira spoke about some common Messaging Patterns that can be implemented on Azure Integration services.
First Things, first…
He started with one of the widely asked question “What is the differentiation between Messages and Events?”.
He gave a teardown comparison on what is the message and what is the event.
In this above illustration, we got a clear understanding for What is message and event but what is the stream? Stream is a collection of events.
We got to see about Messages and Events but what are the AIS that can handle them? There he gave a comparison on well known Azure Services that are Azure Service Bus and Azure Event Grid
Below is the illustration that shows tear down a comparison of Azure Service bus Azure Event Grid and how are being used for handling Messages and Events:
So, it was more about Messages and Events handling services. Then What about others?
And there he gave a comparison on how Azure Logic Apps and API Management processing the messages.
Implementing Messaging Patterns in AIS
In this section, he explained about different messaging patterns available for a better message or event handling.
- Publisher/ Subscriber Pattern
- Claim check pattern
- Sequential convoy
Publisher/ Subscriber pattern will have a single publisher with Multiple Subscribers being data replicated for individual subscribers
Now we got to know about Publisher/Subscriber pattern but let us see if it can be implemented into our AIS
As shown in the above image both the Azure Service Bus and Azure Event grid works based on the Publisher/Subscriber model
We can replicate the data with the help of this pattern when there are multiple subscribers but what if every subscriber needs their respective data. Can we implement routing in AIS?
Well, it is possible to implement Routing as mentioned in the below illustration
Both the Azure Service Bus and Event Grid can filter the messages and events based on the filters provided by the user
Claim Check Pattern
In the Publisher/ Subscriber model, we were dealing with the actual message. What if there is a message lost?
There comes the Claim check pattern. Here Instead of sending the actual message, a copy of the message will be sent through the messaging service whereas, the message will be stored in the common Storage by the send through other AIS like Logic Apps or API Management.
As mentioned in the above illustration, both the Azure Service Bus and Event grid can act as message handler to send the copy of a message and API Management & Logic Apps acts as a proxy to put the original message in the common Data repository of Sender and Receiver.
Azure Integration Services are very powerful tools that can satisfy both Publisher/ Subscriber and Claim check pattern but there is another complex pattern which involves a stream of data – Sequential Convoy
In this pattern, there will be a stream of data which needs to be received in an order based on the receiver requirement. This can be achieved by Correlation or sequence Id with which the messages can be retrieved in order very easily
We saw the pattern but how it can be achieved in AIS?
This can be directly achieved by sessions in Azure Service bus and even Azure Logic App can be used to retrieve data in sequence
It’s a Demo Time
In the Demonstration, He took an Azure Logic App which will put the actual message into a Storage blob and send the copy of the message to the Message handling system Azure Service bus
In the other End, there will be receiver logic which will receive the message from the Azure service bus and validate that message with an original message in the Storage Blob. If it is a valid message it will be taken for the further process.
Below is the illustration of how the above Claim check pattern can be implemented through the Azure Integration Services
Wagner interestingly covered this session with a lot of illustrations and a great real-world demonstration. He concluded with the summary and answered a few questions from the audience.
- How can you guarantee at least once execution if Service Bus doesn’t have endpoints supporting distributed transactions? – John Brockmeyer
We can use the peek-lock option that guarantees all the message we received but before you commit it back
- When is subscription filter access via the Azure Portal due to become available? – John Anderson
It is already available there. Filtering based on Message properties and SQL filtering is already available there in Azure portal
- How do you handle retries with azure service bus topic-subscriptions? – Rodrigo Groener
We can re-submit the messages from the client-side. All message will be there in the Azure Service bus if you are receiving the message in peek-lock. You can any time retry the messages
Stay tuned for the awesome sessions of 3rd day of Integrate 2020 remote…