For starters, I need to start out saying I am very new to working with Windows Azure Logic Apps; so a lot of the issues we faced were just from lack of experience. That said, since it is a relatively new technology, most people are going to be new to it as well.
In general, the experience was straight forward and we were able to build an Enterprise class EDI solution in a short amount of time at a huge cost saving as compared to a new BizTalk Server installation. For clients who already have BizTalk up and running, the cost savings would not be as significant.
Overall, the Azure Logic Apps platform is fantastic. It gives great details into current and the past running instances with complete auditing on a per-shape basis. We were able to track down issues very quickly using all the tools provided. The Azure Logic Apps monitoring features are extensive.
Dev-Ops is challenging
The big trade off at this point comes in terms of Dev-Ops. While the Dev-Ops side of Azure Logic Apps is getting better all the time, it takes a change in thinking that is not going to work for every organization. When you look at traditional on-premises solutions, they generally have a rigid build and deployment process.
For Logic Apps, things are a little more free-flowing. To start with, you have two designer options. The Web Designer or Visual Studio.
- The Web Designer rocks and makes Logic App creation super simple but migration and source control is challenging
- The Visual Studio designer gives you both easy migration and adding to source control at the cost of being the web designer and semi-clunky.
Deciding what works best for you will take balancing between these features and the amount of time you want to spend filling the gaps. I’m confident you could build a robust deployment process around the Web Designer using PowerShell giving the right amount of time.
For us, it was not being able to easily change URL and SQL connections that made us go with Visual Studio.
Of course, if you are ok with needing to make these changes manually or don’t have a lot of them, the Web Designer could be the best option.
Key Lessons Learned
Below I summarized my key lessons learned from my first production Logic App project. This was for a smaller client with a very small Logic App implementation.
#1: Reacting to major workflow changes was easy and quick
We got an undocumented requirement after we went live that we needed to send separate EDI files for each location. We were able to re-work the Logic Apps in less than a day to accomplish this.
#2: For serious stuff, build your Logic App inside Visual Studio
Why? This seemed the simplest way to ensure the files are checked into source control and we can deploy to any region we wanted. Plus we took the time to create custom parameters for per-environment variables like web URLs and SQL Connections.
Using the web designer, you can clone, change resource groups, and change subscriptions but not sure how to easily change regions. Based on that, using Visual Studio seemed to give the most flexibility with the least effort.
#3: Working with the Visual Studio Designer : ensure the following
- If using an Integration Account, assign it right away.
- Always complete your shapes once you start them even if you just put in “foo”’.
- Always save (and do the two points above) before switching to code view (if you switch to code view and back, sometimes uncompleted shapes disappear).
- Do not panic when you are not able to get back from code view to the designer view; it will tell what needs to be fixed.
- If you have more than one Logic App project in a solution when you do a deployment ensure the Resource Group setting are correct plus confirm the results in the output windows. We saw cases that one project would deploy another. If you run into issues, clear All from the list of deployments then close and re-open Visual Studio.
#4: Pick a region and stay with it
In general, moving between regions seemed to cause some complexity. The web designer does not seem to support it at all and using Visual Studio seemed to work most of the time. If you deploy to a new region using Visual Studio, you need to open and save the Logic App using the Web Designer to get the internal APIs to update to the new region.
#5: Working with SQL Azure
- Returning output parameters of XML seem to not be supported.
- Doing a For-Each around a ResultSet seemed great – until the ResultSet returned no records. So we had to do a pre-check on the Count using a different procedure. This could have just been our ignorance in working with SQL in Azure.
#6: Brush up on your JSON skills
I found a lot of cases that I had to manually edit the JSON file. Some cases included parsing stored procedure out parameters and changing the RunAfter parameter for exception handling.
#7: Working with retry and exception handling
Logic Apps have powerful retry and exception handling options, but in most cases needs to be done manually inside the JSON file.
This gives a high-level overview of my experiences over the past few months taking my first Azure Logic Apps project live. What lessons have you learned from working with Logic Apps on your projects?
Serverless360 is one platform for Azure Serverless monitoring and management. It provides efficient tooling by complementing Azure Portal. Try Serverless360 free for 15 days!