Let’s take our first look at Logic Apps and their capabilities by completing the flow from the previous posts. We will also go a bit deeper into APIM policies to set one up that routes based on message size.

Logic Apps is Microsoft’s big push into hybrid- and cloud-based integration offering or Integration-Platform-as-a-Service (iPaaS). They allow you to easily model, design, test business processes in a visual designer that seamlessly integrates with your cloud and on premise resources.

The platform is still growing rapidly and receiving frequent updates in the form of new functionalities and connectors. Even if the application you want to connect does not have a connector, Logic Apps can easily access REST-endpoints. For a list of available connectors, go here.

Now that everything is in place to build our Logic App, we can try and build our Logic App to the process at hand. The following steps will be implemented:

1. Receive a call from APIM
2. Generate GUID
3. Store the body in Blob storage
4. Send the message to a new queue
5. Return a response to APIM

And here we already have most of our Logic App. The only difference is that we will still have to parse the GUID when we receive it.

Let’s get started!

Create logic app

Create a new Logic App, nothing new here.

Pick the HTTP Request-Response template. You will be put directly into the editor with a request and response block already defined. The URL that you can post to will be generated after we save.

Start by clicking on the arrow between request and response to add in a new block there.

Look for functions and add your newly created function.

You will have to click through a couple of times. Once your block is there, show advanced options, change the method to POST and put empty brackets in the body.

Add a new “Parse JSON” block to get your GUID out of the function response. Now, this is where the beauty of Logic Apps comes through. When you click content, you will be prompted to pick what you want to have parsed from all the data you got from previous blocks. Choose the Body from your Function block.

Now use the output from your function and generate a schema from it.

You will now have a GUID object available in your Logic App.

The next block can be one of two, you can either pick the integrated “Azure Blob Storage – Create blob” or you can send a HTTP request to the Blob Storage API. We will use the integrated action as it is… integrated into Logic Apps. For more info on the Blob API, go here.

Connect to your Storage Account and give the connection a name.

Click folder path and navigate to the container you created.

Use your GUID variable in the Blob name and Request Body for the Blob content.

Now that our Blob has been created, we still need to send out a message to BizTalk. Add a “Service Bus – Send Message” action.

Connect to your Service Bus and give it a meaningful name.

If you have problems with the namespace manager in the next section, go back to your Service Bus and add a new Shared Access Policy with the Manage option enabled.

Pick your queue name. The content only has to be a pointer where we can retrieve our Blob, so that’s all we’ll pass along. Type in the URL of your Blob and add Blob Path variable and Blob Name variable.

The response automatically sends out a 200 Status code, so we can leave that.

Save your Logic App and we’re almost done!

Copy the HTTP POST URL from the Request block at the very start of the Logic App so that we can route to it from the APIM.

Message size based routing in API Management Service

Now that everything is set up, head back to your API’s operation policy.

Implement a Control Flow Policy in the inbound part. What we will do here is test the String length of the request body. The limitation is 256 KB, so we will test if the body length is fewer than 256000 characters.

We’ll check the body size through the Content-Length header and cast that as an Int to compare with. The Content-Length header will be put in a variable before the check.

This section should then contain all your policies from before. In the tag, reroute the message to your logic app via a combination of the tag and the tag. I prefer to set my domain and port as the backend service and the rest in the tag.

Your end result should resemble something like this:

This routing policy can be seen in text below but it has also been uploaded to the Azure GIT and can be viewed here.

application/atom+xml;type=entry;charset=utf-8{}

The Content-Length header will not always be there. If the requests your API receives are of the media type “multipart/byteranges”, then your application will fail as the “Content-Length” header does not exist.

A costly solution to this could be to read out the entire body as a string and compare its length. This solution is a lot more intensive, especially in the use case that you work with media. The policy for this is displayed below.

Conclusion

And that’s it. You have now set up an API Management Service that is connected via Service Bus Queues to your on-premise BizTalk Server. To get around the limitation of the max size of 256KB in the queue, large messages are rerouted in the API Management Service to a Logic App. Enhanced by Azure Functions, the Logic App puts these messages on Blob Storages to be later retrieved while sending a pointer to the BizTalk Server.

There is a lot more that can be said about the Azure resources that have been used in this series. API Management, for example, has loads more features that are worth exploring and looking into.
But that’s not all! We could go a bit deeper into Azure logging, Power BI, KeyVault, Active Directory (B2C) and more. And most of these resources easily integrate into one another.

Thanks for reading!

Jochim