This post was originally published here
What a day it was at ‘Integrate 2017’ today. For Logic Apps enthusiasts, it was a treat. have you missed the sessions? don’t worry, I am going write on all that was talked about today on logic apps.
Azure Logic Apps – Microsoft IT journey with Azure Logic Apps – By Divya Swarnkar and Mayank Sharma
Microsoft has a large IT wing to serve its business which is called ‘MSIT’. This team is well known for ‘eating its own dog food’. Mayank and Divya are from MSIT’s integration team. When they started their session by describing the scale of business their team is serving, we were all blown away. Look at the number of business entities they are serving. Around 170 million messages flow through their 175 BizTalk servers serving 1000 plus trading partners across various business entities.
“We are moving all of this Integration to Logic Apps.”
MSIT is modernizing their integration landscape completely. Divya and Mayank made it very clear that they are moving all the BizTalk interfaces to Logic Apps and BizTalk is only going to be used as a proxy to serve existing partner requests. They so far were able to deliver three releases.
- Release 1.0 they moved most of their interfaces relying on X12 and AS2, Logic Apps.
- Release 1.5 they were able to move interfaces related to EDIFACT to Logic Apps.
- Release 2.0 release they moved many of the XML-oriented interfaces.
All these interfaces helped them to achieve following goals.
- Enable Order to Cash Flow for digital supply chain management.
- Running trade integrations and all customer declaration transactions.
- They became ready to retire “Microsoft BizTalk Services” instances by end of July.
Solution Architecture
They then continued to explain their solution architecture. Below is the slide that they presented. Following are some of the important aspects of their solution architecture.
- Azure API Management: All trading partners send the messages(X12/EDIFACT/XML) through Microsoft’s Gateway store. Azure API management service then routes the message to an appropriate logic app.
- Integration Account: The Logic apps they have built, make full use of Integration account artefacts such as Trading Partner Agreements, Certificates, Schemas, Transformations etc.
- On-premises BizTalk: On-premises BizTalk is merely used as a proxy for Line of business applications. This makes sense as they may not want to change all the connections which already exist for Line of Business Applications and also they need to support the continuity of other interfaces. This is the perfect example of how other organizations can start migrating their interfaces to Logic Apps.
- Logic App Flow: The Logic apps make use of typical VETER pipeline which involves AS2 connector, X12 connector, Transformation, Encoding and HTTP connectors as shown below.
- OMS for Diagnostics and Monitoring: Operational Management Suits(OMS) is used for collection of diagnostic logs from Integration Accounts, Logic Apps and Azure functions which are part of their solution. Once all the diagnostic data is collected they will be able to query and create nice dashboards for getting analytics on their interfaces. Currently, Integration accounts have their built-in solutions for OMS. Please refer the video http://www.integrationusergroup.com/business-activity-tracking-monitoring-logic-apps/ to know about Diagnostic logs in Logic Apps and Integration accounts.
Fall-back and Production Testing Using APIM
They have scenarios where they want to test the logic apps in production and also want to fall back to previous stable versions of the logic app. They make use of APIM to achieve this requirement. APIM is configured with rules to switch between the logic apps end points.
Disaster Recovery
Business continuity is very important especially for MSIT with the scale of messaging they are handling. In order to achieve the business continuity assurance, they make use of Disaster Recovery feature which comes along with integration account.
The disaster recovery is achieved by creating similar copies of logic apps, integration accounts and azure functions in two different regions. As you can see from the picture they have this replication in both Central US and West US regions. Visit the documentation https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-b2b-business-continuity to know more about disaster recovery feature.
Huge confidence Boost to Customers who are contemplating on moving to Logic Apps
Azure Logic Apps – Advanced integration patterns By Jeff Hollan and Derek Li
I am a big fan of Jeff Hollan. When he is on the stage it’s a treat to listen to him. He brings life into technical talks and involves the audience by leaving a lasting impression. Enough of personifying him. Jeff Hollan and Derek Li were on to the stage to talk about advanced integration patterns in Logic apps.
Internals of Logic Apps Platform
Jeff arrived on the stage with the clear intention of explaining the internal architecture of Logic Apps platform. You might be wondering why we should be knowing about the internals of Logic Apps as it is a PaaS offering and we generally treat them as a black box from the end user perspective. However, he gave three powerful reasons why we should understand the internals.
- There are some published limits for the Logic apps. We need to understand them in order to design enterprise grade solutions.
- Understanding the nature of the workflows
- Internals help us to clearly understand the impact of design on throughput especially when we are working with Long running flows.
- We will be able to leverage the platform as much as possible for concurrency.
- Helps us to understand the structure and behavior of our data
Agenda
The agenda was not just talking about the internal architecture of logic apps but also to talk about Parallel Actions, Exception handling, workflow expressions.
Logic Apps Designer
Logic apps designer is apparently a TypeScript/React JS application. All the functionality that we observe in logic apps designer is all self-contained in this application. This is the main reason how they are able to host it in visual studio. This makes use of Swagger to render the inputs and outputs. Also as we already aware it generates the workflow definition in JSON.
Logic Apps Runtime
As we know logic apps will have triggers and actions. When we create a logic app all these will be defined in a JSON file. When we click save button, logic apps runtime handles it as below.
- Runtime engine reads the workflow definition and breaks down into various tasks and identifies the dependencies. the tasks will not be executed until their dependencies are worked out.
- It spins distributed workers which coordinate to complete the execution of the tasks. This is very revealing to know that all the workers are distributed which makes the logic app more resilient
- Runtime engine ensures that all the tasks inside the flow are executed at least once. he announced that in the history of logic apps he has not seen any instance where a task is left unexecuted.
- There is no limit on the number of threads executing these tasks and hence there is no overhead of managing active threads.
Example logic App
He gave an example of a logic app with a service bus trigger receiving list of products, and writes each product to a SQL database.
In this example, his main intention was to show how runtime identifies the tasks which can be executed. In this example, a for each loop decides that run time can spin parallel tasks to execute the SQL task. The workflow orchestrator then completes the message by calling service bus complete connector and ends the workflow.
Parallel action
Now with run times ability to spin parallel tasks, he showed us how to use parallel action in logic app definition.
From above picture, it is clear that we can add as many parallel actions we want to add by just clicking Plus symbol on the branches.
Exception handling
At this point, Derek Li took over the stage to show some geeky stuff. He started off by creating a logic app in which one of the action fails and when it fails he would send an email to Jeff. To achieve this he puts a scope and adds all the actions required. After the scope, he configured the run after settings for an action. I do not have an exact snapshot from his slide but it was something like below.
With run after configuration for an action, it is easy to handle the error conditions. Also, he showed how we can set the timeout configuration for an action.
When the timeout expires, we can take some action again by setting run after configuration to “has time out”
Workflow expressions
He spoke about important aspects of workflow expressions. Following are the highlights.
- Any input that changes for every run is an expression. He showed some example expressions.
- He explained the difference between different constructs such as “@”, “{}”,”[]” and “()”.
@ is used for referring a JSON node, {} means a string, [] is used as JSON path and () is used to contain the expressions for evaluation. He also showed the order in which elements of an expression executed.
Summary
As explained earlier it was a real treat for all the logic app enthusiasts and gave a lot of insights into a logic app platform.
- The first session from Mayank and Divya gave the audience a great level of confidence about going with logic app implementations.
- The session from Jeff and Derek brought an understanding of logic apps internals and patterns.