Ask Learn
Preview
Please sign in to use this experience.
Sign inThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Editor’s note: The following post was written by Microsoft Azure MVP Kent Weare as part of our Technical Tuesday series with support from his technical editor, Microsoft Azure MVP Steef-Jan Wiggers .
In this blog post we are going to discuss two emerging Azure services--Azure Logic Apps and Azure Functions— and how, when used together, they can provide customers with a unique value in the form of extensibility.
Azure Logic Apps is an Integration Platform as a Service (iPaaS) which recently achieved a General Availability milestone. The service allows developers and citizen integrators to build integration interfaces using workflow and the ability to connect to a wide variety of SaaS applications quickly.
Azure Functions is a relatively new service which is still in Public Preview. Functions allow developers to build methods (AKA functions) which are to be executed in the cloud without deploying other hosts, such as a web application. It is also considered to be “serverless” in the sense that it is event driven, scalable and does not require fixed infrastructure to be pre-provisioned in order for it to be used. It is also metered differently than most cloud-based services as costs are determined based upon code execution time and the number of executions instead of a service being online for ‘x’ hours.
Please note: you can find all code snippets referenced in this article here: https://snipplr.com/view/151590/extending-azure-logic-apps-using-azure-functions/
Azure Logic Apps + Azure Functions = Better Together
When building integration interfaces, a developer will often have to deal with a requirement that may not be addressed through out-of-the-box tooling. The result is, the developer needs to write some custom code to address this problem. In BizTalk Server, this can be achieved by writing .NET helper methods that belong to a .NET DLL assembly. In Logic Apps, we don’t have the ability to call a .NET DLL assembly directly. Enter Azure Functions. Azure Functions allow us to write methods where we can execute our custom code, but offers a friction-less deployment model.
Sample Scenario
Let’s now work through a scenario that highlights how these two services can work together. In this scenario, we have business users who need to see the forecasted energy production output for the next 6 days. However, each day they will need to see what the data is. We are going to build a Logic App that uses recurrence. We will use this as our batch scheduler to ensure this Logic App fires each day. We will then use Azure Functions to determine what are the right dates we want to provide our SQL Stored procedure so we are returning the right dataset each day. Lastly, we will publish this SQL result set to an OneDrive for Business folder.
NOTE: The Azure Function logic will not be very complex on purpose. The goal of this blog post is to demonstrate how these two services function together and as a result, we are not focusing on trying to solve a very difficult logic problem inside of Azure Functions.
Creating Azure Function
Within this code we are going to capture what the current date is and the future date which is 6 days from now. We can then construct a Json message that will include both of these dates. Also note, that we can include additional assemblies by including the using statement.
Creating Logic App
{"CurrentDate":"2016-08-13T06:00:000","FutureDate":"2016-08-19T06:00:000"}
The problem is the SQL Connector is not fully understanding the shape of the message being returned. It only understands that a “Body” will be returned. For now, we will select Body as the inputs to the SQL Stored Procedure as this will help us in our next step where we will fix this. Click Save to persist our changes.
Notice that our endDate and startDate properties contain our “Body” that we previously discussed. We now need to add in the names of our CurrentDate and FutureDate properties so that we can retrieve those specific values from our Azure Function message. In order to do this, modify these two lines to be: 17
Why do I have to do this? The reason is that Logic Apps is not aware of the message shape that is being returned from Azure Functions. Usually, Logic Apps will have Swagger metadata that it can use to interrogate a message’s characteristics, but in the case of our Azure Function, there is no Swagger metadata.
20. Our end result is we see a new file in our LogicApps folder within our OneDrive for Business
Conclusion
In this blog post we walked through creating a very simple Azure Function and a Logic App that used the outputs of the Azure Function. While our Azure Function was very simple in nature, on purpose, it does highlight Azure Function’s ability to be an extensibility point for Logic Apps. In our scenario, we included some custom logic to determine what dates should be passed to a stored procedure, but the opportunities to use Azure Functions and Azure Logic Apps are endless. We can also use Azure Functions to perform calculations, provide message enrichment or use it to clean-up unwanted serialization or formatting of data.
From a Logic Apps perspective, it is very easy to plug Azure Functions into existing workflows. While we did not cover it, developers can also create Azure Functions “inline” from the Logic Apps editor. This allows developers to create simple Azure Functions without accessing the broader Azure Function portal experience. This may be useful when a developer may not require access to the logs or testing facilities provided by the Azure Functions editor.
Lastly we took a quick look at the visual run details that Logic Apps is providing which allows developers to trace and debug their code to ensure everything is working properly. Azure Logic Apps provides this as an out-of-the-box experience, which means that developers do not need to write their own logging or tracing tools.
About the author
Kent is a senior enterprise architect at TransAlta, a multi-national power generation and energy trading company. His expertise includes BizTalk, logic apps, API management and service bus technologies. In addition to his enterprise architect responsibilities, he also writes for InfoQ.com on matters relating to cloud computing. Kent holds a master’s degree in Information Management from Arizona State University and a computer science degree from the University of Regina.
Please sign in to use this experience.
Sign in