Last week the new Gartner Magic Quadrant for Enterprise Integration Platform as a Service (EiPaaS) was published, listing Microsoft in the coveted leader space. Having worked with Azure’s iPaaS products for a long time now, I wholeheartedly agree with this decision, and congratulate all the teams within Microsoft who have been working so hard to get to where we are today. The complete report, with all requirements and results can be found in this report.
Source: Gartner (April 2018)
When working with Azure Logic Apps, I like to have each Logic App do a single piece of work, as this allows us to mix and match these Logic Apps in various flows. For this demo, we will be using a very simple representation of this, where we have one Logic App which receives the message and send back a response to the original caller, another Logic App which does transformation of the message, and finally a Logic App which calls a backend system. To decouple these Logic Apps we will be using Azure Service Bus topics, providing us with routing capabilities and allowing us to handle downtime more easily.
Architecture
Now the challenge we were running into, is that we needed to give the response which we received from the backend, back as a response to the client.
Requested architecture
Of course, since we have implemented communication between the Logic Apps asynchronously and decoupled by using Service Bus in between, we don’t have a return channel on which we can send the response. In this post, I will show how we can solve this by using Service Bus sessions.
Last Saturday was the second edition of the Global Integration Bootcamp, and we can certainly say it was another big hit! In total we had 15 locations in 12 countries running the Bootcamp, and about 600 participants including the speakers.
Locations all over the world
This is an amazing achievement, and I would like to thank all the local organizers, and of course my fellow global organizers.
The global organizers
Another year has gone by, and looking back, it has been an amazing year for me. The year started with becoming a MVP, for which I am thankful and honored. I want to once again thank everyone who has helped me reaching this astounding accomplishment, with special thanks going out to my buddy Steef-Jan, who has been like a mentor to me.
Became a MVP
In the previous post, we have seen how we can implement the Message Router pattern when working with Logic Apps. As discussed, Logic Apps are a great fit if you have a limited set of endpoints to which you want to route the message, and if you have a need for various connectors. In this post we will look into another technology to implement this pattern, Azure Service Bus Topics. Topics are a great solution if we want to implement a publish / subscribe mechanism.
Azure Service Bus Topics
When implementing software, it’s always a good idea to follow existing patterns, as these allow us to use proven and reliable techniques. The same applies in integration, where we have been working with integration patterns in technologies like BizTalk, MSMQ etc. These days we are working more and more with new technologies in Azure, giving us new tools like Service Bus, Logic Apps, and since recently Event Grid. But even though we are working with new tools, these integration patterns are still very useful, and should be followed whenever possible. This post is the first in a series where I will be showing how we can implement integration patterns using various services in Azure.
Message Router Pattern
After having shown how to send our custom events to Event Grid in my previous blog post, we will now see how we can create custom subscribers. Event Grid will be integrated with all Azure services, but by allowing us to create our own custom subscribers as well, we can truly route events to any service or application. And what’s more, we will also see how we can use the API to create a subscription from our subscriber, allowing us to quickly onboard new services, which can then start listening to the events which are of interest to them. In this sample, we will create an Azure API App, which will receive the events from our previous blog post, and store them in Azure Table Storage. On starting, the API App will check if the subscriptions it uses are created, and if not, it will create them and point them to the various endpoints the API App exposes.
Azure Event Grid
In my previous post I showed how we can use the recently announced Event Grid service to integrate Azure services with each other. In this post, I will show how we can send custom events from any application or service into Event Grid, allowing us to integrate any service. My next post will show you in detail how we can subscribe to these custom events.
Integrate any service or application
Yesterday Microsoft announced their newest service on Azure, and it is called Azure Event Grid. With this new service, we now have event based serverless routing, from any source, to any destination. Of course, we all love integration, and Azure Event Grid brings a whole new world of possibilities. The service is currently in public preview, and we already have various publishes and event handlers to our disposal, and more will be rolling out over the coming months. In the end, expect every service within Azure to have a connection to Event Grid.
Event Publishers and Handlers
Last week, June 26th to 28th, Integrate 2017 was once again held in London. This is the largest integration centered event, and a great way to have fun with the community, see amazing sessions, and get to meet the product groups. I have been to these events since the beginning, and have seen it grow into one of the best events around.
