Creating a basic integration with Logic Apps
Introduction
The new kid on the block in Microsoft’s integration portfolio is Logic Apps. And for those who do not know what a Logic App is; it’s a hosted piece of integration logic in Microsoft Azure. To be more precise the hosting is done in Azure in a similar way as a Web App and the logic are built by creating a trigger followed by a series of actions similar to a workflow. And you can simply create and built them in a browser reducing development and lead-time. In just a couple minutes up to perhaps an hour you can have one running.
The beauty of Logic Apps is that Microsoft provides tons of connectors that will enable you to connect quickly through various protocols and with an wide range of applications. And runs in the cloud meaning that you as developer have to worry less about hosting, scalability, availability and management. As a developer, you can focus on the connectivity and logic in the Logic App. Add a trigger, a few actions, configure, save, secure, test and you are ready to add value to your business. Integration at the speed of light as figure of speech or in other words integrations will no longer be the bottleneck for IT to run at the speed of business.
With Logic Apps, its connectors and other capabilities, there are numerous, if not countless, scenario’s you can think of. For example, you can setup HTTP trigger i.e. endpoint that accept a payload, which subsequently is handled in the Logic App to be processed.
Scenario
The last couple of years I am using Discogs, a comprehensive music database and marketplace. And I am buying and selling music items (CD’s, Vinyl’s and DVD’s) here. The Discogs Marketplace connects buyers and sellers across the globe. With more than 23 million items available and thousands of sellers, this is the premier spot from new releases too hard to find gems. Because the Marketplace is built on top of the accurate Discogs database, it is easy for sellers to list their inventory and buyers are able to specify the exact version they want. Cool, and there’s no surprise here, also an API available.
The Discogs API v2.0 is a RESTful interface to the Discogs data and you can access JSON-formatted information about Database objects such as Artists, Releases, and Labels. And I can access my own data too, like what orders I have received or made. With these features of the API, I can think of various scenarios using Logic Apps.
A scenario could be as follows:
- I post a JSON payload (order identifier) through an application (client like postman of fiddler) to an endpoint generated by an HTTP trigger in a Logic App.
- Consume the payload and use the order identifier (that resides in the JSON payload) to call the Discogs API to retrieve an order made to my store.
- Subsequently store the response of the API in a service bus queue.
- Return the response to the calling application.
The functional flow is shown above and it is to demonstrate that you can use your imagination to build any type of scenario to explore the capabilities of Logic Apps.
To piece together a Logic App that will support my scenario I have to go through a series of steps that are described in the following paragraphs. And I will start with prerequisites that enabled me to build the Logic App.
Prerequisites
The most obvious prerequisite is, of course, having access to Microsoft Azure. If you do not have an account, then you can simply try it out through the following link: https://azure.microsoft.com/en-us/free/. Once you have access to Azure by logging in to your account, you have access to provision a Logic App and create a flow in it.
The other prerequisites for this particular scenario is a Discogs account. You can sign up for that. This will enable you to use the MarketPlace methods of the Discogs API in case you already have an account and done business on Discogs. If not, then you can simply just use the Database API method (see Discogs API documentation for both).
Finally, you need to setup a Service Bus Namespace and create a queue, see Create a Service Bus namespace using the Azure portal and Learn how to create a queue, place and read a message using Azure Service Bus Queues in 5 minutes.
Building the Logic App Walkthrough
The following steps described how to build the Logic App.
Provisioning
In the new Azure Portal click the +, navigate to Web + Mobile and subsequently click Logic App. Or in the search in the marketplace type Logic App. It’s easy to find the Azure Service in the portal to provision.
The next step is to specify a name of your Logic App, the subscription (in case you would have multiple subscriptions), the resource group the Logic App should belong to and location i.e. which Azure datacenter. And subsequently decide if you want to see the Logic App on the dashboard or not and click Create. You wait until the Logic App is provisioned to be able to proceed with building up the flow (trigger and actions).
Once the Logic App is provisioned, you have setup a service, also known as iPaas (integration Platform as a Service). The Logic App is fully managed by Microsoft Azure and the only thing you need to do is add the logic i.e. specify the trigger and defining the actions.
Building the logic in the Logic App
Once the Logic App is provisioned, you can click on it and access the Logic Apps designer. In the Logic App designer, you can add a trigger. You select various triggers like HTTP, recurrence, WebHook, etcetera (see Workflow Actions and Triggers). In my scenario, it’s the HTTP trigger, which I have to provide with a schema of the payload it can accept/expect. The schema can be generated using JsonSchema.net, a tool that automatically generates JSON schema from JSON according to the IETF JSON Schema Internet Draft Version 4. JSON Schema will be automatically generated in three formats: editable, code view, and string.
The generated schema can be pasted into the Request Body JSON Schema part of the HTTP Trigger. Note that the URL is generated after the Logic App has been saved for the first time.
Subsequently, you add an action, for instance, in our scenario this will be a HTTP action. With this action, you can call a specified endpoint. Once you add the HTTP action you can specify the method, endpoint (address), headers, body and authentication. The first two are mandatory, and in this particular HTTP action, I defined the Method GET, the URI i.e. endpoint address for the MarketPlace orders object method of the Discogs API with a parameter the ordered, which is obtained from the HTTP Trigger.
The third step is to add an action that will enable the Logic App to send the response of the first action (HTTP) to a service bus queue. This action is a managed API or connector by Microsoft. Beside managed connectors you have ability to look for other API's in the same region, API Management hosted API's, other Logic Apps or Azure Functions.
To be able to send the response to the queue you need to specify the connection details of your service bus namespace. These can be retrieved through Azure Portal, by navigating to service bus and access the shared access policies. Here you can obtain the connection name and -string.
Once the connection is specified the other steps involve specifying the content, which is the body of HTTP action i.e. response, the content-type (I want to say the response in a JSON format), and add a property to the message (the orderid).
The final step is adding a response action, that contains the entire response payload of an HTTP request (including status code, body and headers). The status code is a mandatory field that has to be specified in this action. I have added the body of the response of the HTTP action.
After the last step, I saved the design. Once you are done with your design or after one of two steps you can save your flow. And in the designer, you also have to ability to look at the code i.e. Jason. In the so-called code view you can manually edit the JSON if necessary like adding retry policy in a HTTP action (see HTTP Action documentation).
The logic (flow) in the Logic App has been defined and can be tested by posting a request (payload) to the generated endpoint. The endpoint contains a SAS key (sig) in the query parameters used for authentication (see also Logic apps as callable endpoints).
Exploring monitoring
Logic App provides several features for monitoring (its section with the Logic App labeled Monitoring):
- Metrics
- Alert Rules
- Diagnostics logs
- Log search
- Diagnostics
And these features can be very useful to see what happens with your Logic App. For instance, metrics gives a broad range specifics you can view of your Logic App. In the screenshot below you see an example of a number of actions that have succeeded.
You easily can view other metrics of the Logic App by selecting another metric. Another feature is alerting. You can create an alert on the Logic App depending on the requirements you might have for monitoring.
The Diagnostic logs and log search provide you the necessary means of looking into any log that will be created for your Logic App. Through diagnostic log feature can setup Microsoft Operations Management Suite. The last feature is diagnostics, which gives you a view of your diagnostics i.e. monitoring and alerts.
Testing the Logic App
To test the Logic App with a HTTP Trigger you can use tools like Fiddler or postman to send a request with payload (orderid). For testing the Logic App I used Postman.
Once I sent a request to the endpoint I receive a response back almost instantly. In the overview of my Logic App I can see if the run of logic has succeeded and select a run to drill into the actions of the Logic App.
I can for instance, review the call to the Discogs API, the response being sent to the service bus queue and back to the client i.e. postman.
With the service bus explorer, I can verify if the responses are stored as Json messages on the queue.
The monitoring capability provides me the means to look into my Logic App.
Considerations
The possibilities with creating Logic Apps are endless considering the set of connectors, which are expanding as we speak. And the flows you create inside a Logic App provide you connect to almost anything with either the managed connectors or custom one or through the HTTP action as described in this article. Second you can chain actions and/or apply conditions, looping (for each, do until) and scopes. This basically means you are quite flexibility in building a Logic App, hence there are considerations:
- Monitoring as briefly discussed in this article.
- Security, securing the HTTP endpoint that is exposed to the outside world. Or leverage the IAM feature of the Logic App.
- Deployment, you can automate it via ARM templates. Under settings you can find Automation script that enables you to download a template of your Logic App or proceed with a custom deployment.
- Granularity, how much logic will you put into the Logic App or will you chain several Logic Apps together in a loosely coupled manner leveraging the service bus. You can also directly call other Logic Apps or Functions.
- Managing the connections.
- Linking to Integration Account to have access to maps, schemas, agreements, certificates and partners. See the article Overview of integration accounts.
- Some of the other quality attribute like availability, scalability and governance.
Call to action
This article demonstrated how you fairly simple can create a Logic App. This new Azure Service or iPaaS has gone GA end of July 2016 and more features and capabilities are being added as we speak. Logic Apps will be a game changer in the integration space. Developers can easily create a type of fine grained integration that runs hassle free in Microsoft Azure. You can go and try it out today, and have a Logic App setup in minutes.
The following resources can get you started with Logic Apps:
- What are Logic Apps?
- What are Connectors and BizTalk API Apps?
- Create a Logic App
- Use Logic App features
- Introduction Video
- Monitor your Logic Apps
- Build and Deploy Logic Apps in Visual Studio
See Also
Another important place to find Logic App related articles is the TechNet Wiki itself. The best entry point is: Logic App Resources on the TechNet Wiki.