The previous blog posts introduced APIM, Queues and the SB-adapter. One drawback of using queues is that it is limited only to messages with a size of 256KB. In this blog post we will setup an Azure Function and use Blob storage to handle larger messages.
We’ll start with setting up Blob Storage, a queue and end with a logic app (in the next post). I will be making use of an Azure Function to generate GUID’s and we will need to adjust our policies to be able to route based on message size.
Create a new Storage Account with the following information:
- Deployment model
This is here for the users who are on Classic virtual networks. Stick to Resource manager.
- Account kind
As we will specifically use our storage for Blob storage, take that
Go for Locally-redundant storage if your data is not critical. Azure will still keep 3 versions of your data, just in the same datacenter. Only a datacenter level incident will impact your data.
- Access tier (only with Blob storage)
Cool is for data that will be stored and infrequently accessed. Hot for data that will be frequently accessed. Pick Hot.
- Storage Service encryption
- Resource group
After deployment, navigate to your Storage and add a new container. Provide a name and the Access type that you want to provide. In this use case, as I will procedurally generate my Blob ID’s and remove the data after it has been read, I will go for Blob and let the blobs be publicly accessible.
We have our Blob storage and made it publicly available. By sending a GET-request to the namespace/Name, we can now easily get our too large messages.
Before we start with Logic Apps, I would like to create a simple Azure Function to return a GUID.
Create a new Function App and fill in the form.
- App name
- Resource Group
- Hosting Plan
How you want to pay for running your Azure Function. Do you let Azure host and scale it and pay per execution with the consumption plan or plug it in an existing/new storage account with the App Service Plan?
What is very important here is that your function MUST be in the same region as your Logic App.
After our Function has been created, click the plus sign beside functions.
Choose “Custom Function” to get started on your own.
Create a GenericWebHook-CSharp and give it a fitting name.
Navigate to Integrate and change the Allowed HTTP methods to only allow POST Requests.
Modify the function so that it returns a new GUID. Remove the code that attempts to read the body.
Click save and run and you should get something like this.
All we need now to make things a little bit easier for us, is a copy from the output so we can get started on the logic app.
We made ourselves a blob storage that has public read-access for ease of connecting to it. To counter our information being publicly available for skimming, the names of our blobs are going to be a randomly generated GUID which we made available via Functions.
Functions offers us a way to serverless implement custom snippets of code which can be very helpful in the integration story. For some more information on functions, Microsoft has published this article that helps you get on your way.
Now that everything is in place, we will develop the Logic App and APIM policy based routing in the next post.
Thanks for reading!
Author: Jochim Vandooren
Business integrator @Integration.team