This blog is an extraction of the webinar “Interesting and new features in Azure Logic Apps” presented by M.R Ashwin Prabhu in Integration Monday series.
The following are some of the Azure Logic Apps features discussed in this article
- Starting a Logic App from another Logic App
- Concept of Nested Logic Apps
- Publish-Subscribe model
- Do-Until Looping in a Logic App
- C-sharp API App
Start a Logic App from another Logic App
Azure Logic Apps can be chained together in different ways. One way is to start a Logic App from another Logic App. This is like the start orchestration shape that you have in BizTalk server. It is identical in terms of the flow of control and also the invocation of other Logic Apps but not to the underlying protocols which are of asynchronous is nature.
The parent Logic App proceeds invocation without waiting for the child Logic App to complete its work. It provides you the modularity approach. Even Though API app and Logic App are based on microservices architecture, these discrete components can be combined to form a composite service or modular service.
In some Logic App orchestration, you may have common services like Error handlers, Auditing service and many more which can be reused from other orchestrations in Middleware.
In this demo there are two Logic Apps 1) Message validator 2) Exception Handler
There is a hybrid file folder from which a message will be received by the Logic App and validated against the predefined schema. If the received message is valid then the file will be dropped in another folder. Otherwise, it will make an HTTP (Hypertext Transfer Protocol) post to call the other Logic App. In the second Logic App, it receives and intercept the message and checks the Severity ID. Depending upon the severity ID it performs the action.
Since you are making an HTTP post internally, the underlying protocol will show the ‘202 Accepted’ status as a response which is why this process is like start orchestration shape and not asynchronous in nature.
Demo to start a Logic App from another Logic App
In this demo, there are two Logic Apps,
- Parent Logic App (Message validator)
- Child Logic App (Exception Handler)
Child Logic App
First, let us see the child Azure Logic Apps also known as the second Logic App. There are two actions that will execute based on the conditions. From the above picture, you can observe the Logic App is manually triggered and also there are two actions with their respective conditions. Even Though the Logic App is triggered manually, each action contains a condition because the HTTP post message is going to trigger one of these actions.
Before triggering these actions from the parent Logic App, let us test to see what the parameters required to invoke Logic Apps are.
To invoke this Logic App, you need URL Access endpoint and Primary Access key values. Select properties under settings in the Azure portal where you can find these values.
The URL should be in the below format,
{Access Endpoint}/ run?api-version=2015-02-01-preview
This URL can be executed by an action ‘run’ to pass the API version as a parameter.
Now, paste the Access endpoint URL in ‘Postman’. Some Authentication keys and Headers must be passed to HTTP post to manually trigger the Logic App. There are two Headers,
Content-Type: application/json
Authorization: <paste the Primary access key>
The Primary access key must be base64 encrypted. It can be done in two ways
1) ARM client
2) Base64 encoder from Bing
Construct the Body of the ‘Postman’ with the below code
{“outputs”:{“body”:{“severityID”: “100”, “ErrorInformation”: “Matching Xml schema not found for Root Node ‘Employees’ and Namespace ‘http://TyrBizTalk.XMLValidator Employee’”}}
Send the message from ‘Postman’ and you will receive the status as ‘202 Accepted’. Now, you should receive an email as notification.
Let us see how the child Logic App can be triggered from the Parent Logic App.
Parent Logic App
There is a hybrid on-premise folder and files will be dropped in it. The File Connector triggers the action once the file becomes available and it will be validated using BizTalk XML validator. If the file is valid it will be moved to another File connector otherwise it will be redirected to the other action.
The HTTP action contains the same URL and Headers which is used in ‘Postman’. The Body contains,
@concat (‘{“outputs”: {“SeverityID”: “100”, “ErrorInformation”:”’, body{‘xmlvalidator’}.ErrorDescription,’”}}}’)
It defines the concatenation of outputs from XML validator and Error description. Also, it passes the Severity ID as 100.
The file connector is scheduled to pull the files from the folder every minute. Now, drop an invalid XML file in the hybrid folder. After a minute, you can find the file has been received by the File connector. Now, check the Run action in the portal.
In child Logic App, an HTTP listener can be used as an action rather than manually triggering it. Behavior wise it is the same, but the difference is in the way you handle it. Calling the HTTP listener in the child Logic App invokes only the API app host and not the whole entity.
Nested Logic App
In the Nested Logic App, there are two Logic Apps 1) Parent Logic App (Message validator) 2) Child Logic App (Age validator).
Here, a message will be validated in the parent Logic App and sent to the child Logic App. The Child Logic App validates the age and sends back the result to the Parent Logic App and also the message will be moved to a folder from Parent Logic App.
It is similar to the call orchestration shape in BizTalk where the parent Logic App waits for the child orchestration to complete and receives the response from it to work on.
Demo for Nested Logic App
In parent Logic App, there is a File Connector out of the box which will receive the message from the hybrid folder. The message will be validated by BizTalk XML validator action and the HTTP action next to the validator moves the control to the Child Logic App. The Child Logic App, initially it has an HTTP listener which automatically triggers the action, unlike the first demo.
Next to it, the BizTalk XPath Extractor extracts age value and based on the age, the corresponding actions will run. The HTTP listener allows the developer to have more control over the response. Once the response is returned from the Child Logic App, the file connector will come into the action. In File Connector the content field contains the body of the HTTP action.
In the Middleware perspective, the same functionality can be achieved by using the existing API. Using the same service but building it in forms can enable us to achieve a complex business process.
Drop the XML file in the folder which contains the schema as,
<ns0: Employee xmlns:ns0= “http://TryBizTalk.XMLValidator.Employee”>
<ID>ID_0</ID>
<Name>Name_0</Name>
<Age>20</Age>
<Department>Depatment_0</Department>
</ns0 : Employee>
Now, the message will be processed by Logic Apps and the response will be moved to the other folder. You can also check the Run history and Trigger history from the portal.
Azure Logic Apps: Publish-Subscribe
In the Publish-Subscribe method, the Logic Apps will be chained similar to BizTalk server. Here, a message will be posted from a process and lets the other process to subscribe it. This concept can be achieved through Service Bus Topics. Service Bus Topics enables the user subscription. From Logic App 1 (Publisher), post a message and any Logic App which are subscribed to it will receive the message.
Note: Provision the Service Bus Topics and Service Bus Connector API app in the Azure portal. Then provide Service Bus Connection String, Service Bus Entity Name, Service Bus Subscription credentials in the portal to provision it.
A demo for Publish-Subscribe Logic App
Initially, in Publisher Logic App there is an HTTP Listener to post a message to Azure Service Bus Connector and an HTTP Listener to send a response to the message. Now, the message will be posted to Service Bus Topic to subscribe it.
In Subscriber Logic App, Service Bus Topic which is subscribed to the Publisher Topic and a file connector to receive the file in a folder.
From ‘Postman’ send the below schema as a message,
<ns0: Employee xmlns:ns0= “http://TryBizTalk.XMLValidator.Employee”>
<ID>ID_0</ID>
<Name>Major</Name>
<Age>10</Age>
<Department>Depatment_0</Department>
</ns0 : Employee>
Check the corresponding folder where you can find an output file.
Using Do-Until Loop
One of the latest entrants in Azure Logic Apps is Do-Until Loop. Do-Until loop enables us to execute the action until a certain condition is satisfied or timeout.
Consider a scenario, in your organization where you may have to receive an order and process the order messages and also acknowledge it. This process is based on invoice message processing. You can issue an invoice only when the order is acknowledged, so you need to continuously check the status of the order for a certain count. Once the order is acknowledged, you can issue the invoice. Here you are constantly checking until some condition is met.
It may sound similar to Retry policy. The difference between Retry policy and Do-until is, in Retry policy you wait until a positive response is received but in Do-Until, it executes till the condition is satisfied and does not care about the nature of the response.
Demo on Do-Until Loop
Request-Bin is a utility which is used for development purposes. The HTTP Listener is used to post a message to the HTTP endpoint. From the Request-Bin create a Bin URL. Once the URL is synced to the Logic App, it generates the response for all the triggered actions.
Paste the Bin URL in the HTTP action. At the time of this webinar, it is not possible to add Do-Until condition using Designer view so switch to code view.
Go to the ‘HTTP post action’ attribute in the code view and append the below code.
Code
“until”: {
“Limit”: {
“Count”: “5”
},
“Condition”: [
{
“Expression”: “@less(length(action().outputs.body),0)”
}
]
}
The code executes the action until the condition is met but not more than 5 times.
Now, send the message from ‘Postman’ and the corresponding responses will reflect at the Request-Bin.
The construction of Logic Apps is not restrained to the Logic Apps designer page but can also be extended to the code view.
Using the C-Sharp API App
Recently, C# API app has been introduced to Logic App along with JavaScript API app. This is one of the most requested features in Logic Apps. You can download the c-sharp api app from the marketplace. As of now, it is not available in the designer page.
You can leave your feedback here
In this, a message is posted, a C# script will be executed and also a response will be returned.
To deploy the API app, you need to fill the credentials like Resource group, Gateway name, Service plan and many more. You need to be conscious and provide the credentials right. Otherwise, it may affect the previous work in that Resource group.
Here, Post a message to HTTP Listener which passes the message to ‘csharpapi’ action. The ‘csharpapi’ action contains two values 1) C# script 2) context
The C# Script field contains the following script:
return DataFromTrigger.ToString().Replace(“Major”, “Ashwin”);
The Context field contains:
{“DataFromTrigger”: “@triggers().outputs.body.Content”}
On executing the C# Script, the control passes to HTTP Listener next to it.
Now, send the below message from Postman.
<ns0: Employee xmlns:ns0= “http://TryBizTalk.XMLValidator.Employee”>
<ID>ID_0</ID>
<Name>Major</Name>
<Age>10</Age>
<Department>Depatment_0</Department>
</ns0 : Employee>
The name ‘Major’ has changed to ‘Ashwin’ in the output. In this demo, the ‘csharpapi’ act as an action but it can also act as a trigger.
Wrap up
This blog discusses the different ways of chaining Azure Logic Apps and the new features introduced in Azure Logic Apps. Also, few real-time demos have been demonstrated for a better understanding of the audience. Currently, there are a lot of features available in Azure Logic Apps and more to come soon. Stay tuned for further updates. Happy Learning!
Strengthen your Azure Logic Apps monitoring and get powerful toolsets, actionable insights to troubleshoot issues with the help of Turbo360.
