Mocking data in Azure Logic Apps

In any distributed system development, various pieces of an application gets developed by multiple teams from different parts of the geography. This is a OK till you hit a roadblock when you cannot proceed until another team finishes their work and provide the data you need. In today's microservices design model this is even more relevant where you need a dependent service to return the data you need so that you can complete your work.

This type is scenario is inevitable and you cannot help but rather have to live with it. So what to do? 😒 

Mocking!! Yes you are right. Why not mock the data you need to finish your work and later just do the plumbing work with the actual service when it's up and ready to throw back actual data. This is a great idea where teams can work on their own schedule without waiting and running after each other.

In Azure, when it comes to mocking, developers often fall back on API Management to implement this with the help of APIM polices. But why going for such costly idea where the need is only to mock data when you can use your other friend Logic Apps to achieve the same. Let's check it out 👍

Scenario:

We need to get the employee details from the database service (developing by the back-end team) by passing the employee code. But the back-end team is not yet there and hence we need to mock the employee details.

Let's get started.

Define an http endpoint where we will send the employee code as below

Add a new action and search for the HTTP action

Fill the details as per your requirement. In my case it's a GET call with the following details.

As mentioned the URI is the service that's getting developed by the backend team which is not yet ready. So, in this action we have to inject out mocking logic. 

Click the "..." eclipse at the top right section of the action and select "Static result (Preview)" from the context menu. Yeah it's preview but works just fine. Go ahead!

Enable the Static result to get the following window. The default selections are good to go for our mocking purpose

But strangely there's no place to provide the static json response content here. Don't worry! It's there but we need to tweak a bit 😉

Hit the JSON mode icon to switch to the JSON view mode as below

Now here in the outputs section paste your return JSON in a body tag as below. I just need the employee first_name, last_name , "dept" and "rank" from the database service. So, I have mocked that piece as the back-end service is not yet ready and I can continue with my development 😃

Hit Done as return to the workflow. Now you will find a new icon added to the action which denotes that this action has a static result configured

As a last step let's add an "Response" action in the workflow and return back the employee details to the caller. 

Save your logic app.

Done! let take a bird's eye view of our logic app workflow. This will help you to match if you are doing it in parallel along with this article

Testing time! Copy the http endpoint from the trigger (first action) and paste it in any rest client to make the call. I have used postman rest client as below. Hit Send and get your static result back.

That's it. You have successfully implemented mocking and what a cool way to do so. 

Isn't that great! 

Congratulations! for coming this far. Hope this article will help you to further explore more on this feature.

Do share with me about your experience and what you have built upon this foundation. You can take it upto any level and integrate. I would love to hear from you.

Inject Inline javascript code in your Azure Logic App workflow

JavaScript is web developers all time favourite. Writing small snippets of JS code into your application to implement few cool functionality is very tempting and developers; I know one cannot think of any web application which do not have any JS flavor in some form or the other 😀 

Wouldn't it be great if we can use our JavaScript knowledge and inject a JS snippet into an Azure Logic App workflow and pull a magic out of it. I know you are thinking "Yessss! Why Not", so lets see how it an be done. 

[Please note that is article expects you to have the basic understanding of Azure Logic Apps and Functions. You can check on Microsoft Azure documentation for such] 

Our scenario for this article:

We need an Http endpoint which will accept a temperature and will do the Celsius or Fahrenheit conversion accordingly. If we send the temperature as Celsius then it will give us its Fahrenheit value and vice-versa.

In most cases I have seen developers quickly jumps into writing Azure Function to do this kind of simple stuff but after going through this article I hope you would think twice.

Our JSON payload will be as below which we will send while calling the Logic App endpoint. It's just sending the temperature in Celsius and expecting its respective Fahrenheit value.

{
   "temperature":"40",
   "metric":"C"
}

Now the JavaScript snippet to do the conversion is as below. It's just applying the formula and doing the respective Celsius and Fahrenheit conversion after reading the temperature and metric from the http request. If metric is coming as "C" then the result will be it's respective Fahrenheit and vice-versa.

var temp = workflowContext.trigger.outputs.body.temperature; 
var metric = workflowContext.trigger.outputs.body.metric;
var cf; 
if (metric == "C")
    cf = (temp * 9/5) + 32 + " degree Fahrenheit";
else if(metric == "F")
    cf = (temp - 32) * 5/9 + " degree Celsius";
else
    cf = "Invalid input"
return cf;

That's it! really 😲

Now lets create a Logic App and inject this piece of JavaScript snippet. There is an "Inline Code" Operation with an Action "Execute JavaScript Code (preview)" in Logic App workflow which we will use to achieve our result. Yes it's in preview but works just fine. Don't worry... you can safely use it 👍

Below is the full workflow and by looking at it you can pretty well understand what's it doing. So simple! 

Save your Logic App and copy the Http Post Url to test it. I will use Postman rest client to test the endpoint but you can use any rest client of your choice.

Test 1: Sending 20 degree Celsius and getting it's respective Fahrenheit value

Test 2: Sending 68 degree Fahrenheit and getting it's respective Celsius value

Cool! the outputs are as expected. With few line of JS snippet you are able to pull out the magic of temperature conversion which would otherwise need an Azure Function.

Isn't that great! 

Great Job and Congratulations! for coming this far. Hope this article will help you to further explore more on this feature.

Do share with me about your experience and what you have built upon this foundation. You can take it upto any level and integrate. I would love to hear from you.

Implementing Fan-Out/Fan-In Design Pattern using Azure Logic Apps

Azure Logic Apps are great for building system integrations. It doesn't matter your systems are running on premise or in cloud (any); with this great iPaaS service you can bring them all together in a common platform very quickly. 

But did you ever thought that you can also use this service to host multiple web services which can work in parallel to give the desired output. 

Think of a situation below:

"You have three web services each destined to perform a special task and return back a result. Now this result from each service individually doesn't makes any sense. You need to collate all the results, do some data massaging on it and return back the end result to the caller.". Very common scenario nowadays. Right?

Yes you can achieve this by

• Calling each service one-by-one, store their individual result and then write code to prepare the end result
• Azure Durable Functions with Orchestrator controller
• Azure API Management with APIM policies.

All are right answers! 

This article is not to discourage you from using any of the above but rather intended to give you one more thought process to achieve the same using Azure Logic Apps which is worth a shot. Let's check it out.

[Please note that is article expects you to have the basic understanding of Azure Logic Apps and Functions. You can check on Microsoft Azure documentation for such. 👍]

I will use three very simple web services for this article. The services are nothing but Azure Functions which would simply return an integer value to the caller (in this case the logic app) where all will get summarized before flushing out the end result.

I have used one .Net and two Node.JS HttpTrigger function apps just to give it a multi-language web service flavour. The apps are just returning 10,20 and 30 respectively as their output.

.Net Function app - 01

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;

public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{    
    log.LogInformation("C# HTTP trigger function processed a request.");
    return new OkObjectResult(10);
}

Node.JS Function app - 02

module.exports = async function (context, req) {
    context.log('JavaScript HTTP trigger function processed a request.');    
    var responseMessage = 20;
    context.res = {
        body: parseInt(responseMessage)
    };
}

Node.JS Function app - 03

module.exports = async function (context, req) {
    context.log('JavaScript HTTP trigger function processed a request.');
    var responseMessage = 30;
    context.res = {
        body: parseInt(responseMessage)
    };
}

We are done with our three web services hosted as Azure Function apps. Cool 😊

Now let's put a Logic App in front which will act as an abstraction layer to all the web services and would give us a single http endpoint to consume. The logic app will call all the web services in parallel (Fan-Out), collect all results (Fan-In), do a summation and would flush out the end result. So, in our case the end result would be 60.. right!

Let's take a bird's eye view of our Logic App

The first three variables are declared to store the respective values from the three web services. The fourth and fifth variable are for doing the summation and final result.

Three web services are fanned-out in parallel as there is no dependency between each other. This will boost the speed as parallel processing is always faster. When all the runs are complete then the flow will be fanned-in for performing the data massaging (i.e. adding all the three results). The fourth and fifth variable are used to store the summation and ultimate flushing out the end result as a response to the caller.

Now our Logic App is in place and we are ready to test. Just copy the Logic App Http endpoint from the workflow and call it from Postman (or any other rest client is just fine). In a moment you will find the output of 60 flashing in your screen. Voila! It just worked as expected and we have successfully showcased a very rich design pattern with the help of Azure Logic App. 

Great Job and Congratulations! for coming this far. Hope this article will help you to further explore more on this feature.

Do share with me about your experience and what you have built upon this foundation. You can take it upto any level and integrate. I would love to hear from you.

Azure Logic App Integration : Transform XML to JSON

In Enterprise Integration or iPaaS, a scenario that often comes up is to convert a XML payload to Json. You might be receiving XML data from one system but needs to convert that to JSON before pushing it to another system. If both the source and destination systems understands same language then it's OK but that is not always the case. So, there's a challenge.

Azure Logic App has some cool power and we will try to leverage on such in our integration scenario. Here our legacy source system can only send XML data but our destination system only understands JSON. 

Prerequisites:

• Azure Subscription (Free subscription will also do)
• Basic XML, XSLT understanding
• Basic JSON understanding
• Azure Logic App basic Request/Response understanding

Let's get Started

• Create a simple xml document (Vendor.xml). This is the payload our source system will send.

<?xml version="1.0" encoding="UTF-8"?>
<Vendor>
   <VendorNumber>VND1</VendorNumber>
   <VendorName>My Vendor</VendorName>
   <GroupId>10</GroupId>
   <Company>USRT</Company>
   <VendorCity>My City</VendorCity>
   <VendorContactPhone>1234567890</VendorContactPhone>
   <VendorContactEmail>myvendor@vendoremail.com</VendorContactEmail>
   <VendorCountryRgn>USA</VendorCountryRgn>
</Vendor>

• But our destination system only understands JSON. Now we need to transform the above XML into JSON keeping all other information intact. So after transformation the data should look like this

{
   "VendorNumber":"VND1",
   "VendorName":"My Vendor",
   "Company":"USRT",
   "VendorCity":"My City",
   "VendorContactPhone":"1234567890",
   "VendorContactEmail":"myvendor@vendoremail.com",
   "VendorCountryRgn":"USA"
}

• Looks simple! but not that simple in Logic App. There's a few marketplace connectors available but that won't help much when it comes to customization and also they not free and has licensing and pricing model complexities. So why to go that route when we have a free yet powerful friend in hand which can do this task quite comfortably and also is a first class citizen in Azure Logic App. XSLT Transformation. 

Here goes our Vendor.xsl document. Save it in your machine as you would need this later. It's quite simple and self-explanatory. XSLT has immense power and hence you can understand what level of control you will have in handling XML complexities.

<?xml version="1.0" encoding="UTF-8"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" method="text" media-type="application/json"/>
    <xsl:template match="/">
        <xsl:text>{ </xsl:text>
        
        <xsl:text>"VendorNumber" : "</xsl:text>
        <xsl:value-of select="Vendor/VendorNumber"/>
        <xsl:text>", </xsl:text>
        
        <xsl:text>"VendorName" : "</xsl:text>
        <xsl:value-of select="Vendor/VendorName"/>
        <xsl:text>", </xsl:text>
        
        <xsl:text>"Company" : "</xsl:text>
        <xsl:value-of select="Vendor/Company"/>
        <xsl:text>", </xsl:text>
        
        <xsl:text>"VendorCity" : "</xsl:text>
        <xsl:value-of select="Vendor/VendorCity"/>
        <xsl:text>", </xsl:text>
        
        <xsl:text>"VendorContactPhone" : "</xsl:text>
        <xsl:value-of select="Vendor/VendorContactPhone"/>
        <xsl:text>", </xsl:text>
        
        <xsl:text>"VendorContactEmail" : "</xsl:text>
        <xsl:value-of select="Vendor/VendorContactEmail"/>
        <xsl:text>", </xsl:text>
        
        <xsl:text>"VendorCountryRgn" : "</xsl:text>
        <xsl:value-of select="Vendor/VendorCountryRgn"/>
        <xsl:text>" </xsl:text>
        
        <xsl:text> }</xsl:text>
    </xsl:template>
</xsl:stylesheet>

• We are done with our basic ground work. Now it's time to step into Azure. 😃
• Login to Azure portal 
• We cannot apply this XSLT file straightway on our input XML in Logic App. For that we need to create an "integration accounts". Let's do that. Search for integration in the Azure search bar and select.

• Click +Add at the top and fill up the necessary details as per your choice. Create the account.

• Once the integration account is created it will take you to the following landing page. There are lots of components available but for the sake of simplicity I won't go into those as it's not required for your case. It's required for typical B2B scenarios and if you are keep to learn then Azure has good documentation around it.  Here we only need the Maps component. So click on that.

• Click +Add at the top and upload your Vendor.xsl file. This is the XSLT file we have created earlier. Click OK

• Great. Now let create the logic app for some real action. Search for Logic App in the Azure search bar and select.

• Click +Add at the top and fill up the following details as per your choice. One important point to remember here. Make sure your logic app location is same as your integration account location. This is a requirement. Create your logic app.

• Now the most important part. We need to tell the Logic App to use the integration account so that it could pick up the XSLT transformation map from there. Go to the Settings>>Workflow Settings and map your integration account. Click Save

• Click Logic App designer under Development Tools and choose "When a HTTP request is received" trigger from the list of common triggers

• This will take you to the logic app workflow designer with the above trigger as the first element in the workflow. Do nothing here and click the "Next Step"

• Search for "Transform XML" and select Transform XML from the list of actions.

• For Contents, select the Body from the Dynamic content list. The is the http request body which we are going to send as an XML payload later.

• Choose the XSLT map from the "Map" dropdown. This is coming from your integration account where we have uploaded the Vendor.xsl file.

• Now select the Add new parameter dropdown and select "Transform options" and the value as "Apply XSLT output attributes". This is very important else you will get a runtime error "Code": "InvalidXsltContent", "Message": "An error occurred while processing map. 'Token Text in state Start would result in an invalid XML document. Make sure that the ConformanceLevel setting is set to ConformanceLevel.Fragment or ConformanceLevel.Auto if you want to write an XML fragment. ".  This is to just to inform the runtime to use the output format as defined in the XSLT file which in our case is application/json. So, make sure you do not miss this step 👍

• Now we do not have any real source and destination system for this demo. So, we would return back the transformed JSON to the caller to simulate the XML to JSON conversion. Click on "+New Step", search for "Response" and select the Response Action

• Select the "Transformed XML" from the Dynamic content selection window 

• So, we have 3 steps in the workflow. Save the Logic app. This will generate the HTTP endpoint for us to test. Copy the HTTP POST URL endpoint and open any rest client of your choice. My favorite is Postman

• Paste the url endpoint to make a POST call. In the body copy-paste the XML data from the Vendor.xml file we have created previously. Hit Send and Voila!! We are successfully getting back JSON response by sending XML request. Isn't that great stuff😚

Great Job and Congratulations! for coming this far. Hope this article will help you to further explore more on this feature.

Do share with me about your experience and what you have built upon this foundation. You can take it upto any level and integrate. I would love to hear from you.

Azure Logic App : A must have weapon in your armoury

I often get involved in discussions where people talks about automation and orchestrating stuff so that manual operations can be mitigated. This discussion generally leads towards implementing DevOps tools and practices and to setup a sound CI/CD pipeline, etc. But, I rarely come across a situation where people brings Logic App in this discussion. It a great service and should be a part of any automation discussion. 

Take an example (Order handling in an arbitrary eCommerce scenario). The situation is like

1. Receiving the order in the system
2. Save the order details in a database 
3. Generate a service ticket (ITSM) so that the order can be handled
4. Generate a SMS and send it to the customer confirming the order 

A very common workflow..right! What would you prefer here? A DevOps Automation or an Workflow Automation? Obviously the second one, and here in this article we will implement the above scenario with the help of a Logic App workflow and would try to feel the power of this awesome service. 

Please note that for simplicity purpose and to make this article an easy read we will go over a waterfall workflow model with sequential steps. 

Let's revisit out scenario once again and this time we will put the integration pointers. 

1. Receiving the order in the system 👉 Postman REST API client
2. Save the order details in a database 👉 Azure Table Storage
3. Generate a service ticket (ITSM) so that the order can be handled 👉 FreshDesk (free account will do)
4. Generate a SMS and send it to the customer confirming the order 👉 Twillio (free account will do)

Make sure you have the above settings done before moving forward.

OK, now we are all set. Let's dive.

• First let's define the order information. We will use a simple JSON payload here for this demo just to simulate an order. Please replace the phone number with yours (with proper +Country code) 📱

{
   "orderNo": "1",
   "orderItem" : "Headphone",
   "orderCustName": "My Good Customer",
   "orderCustMobile" : "+91XXXXXXXXXX",
   "orderCity": "Bangalore",
   "orderState": "Karnataka"
}

• Login to Azure and search for Logic Apps. 

• Select your subscription, fill up the necessary details as per your choice, review and create the logic app.

• Select "When a HTTP request is received" trigger in the designer

• Click the link "Use sample payload to generate schema" hyperlink at the bottom and paste the order JSON payload to generate the JSON schema. Save the logic app to generate the HTTP Post Url.

• Click "+ New Step" to add an Azure Storage table data insert step. Make sure you have already created a blank table in Azure Storage account so that you can insert data in that table directly using this step. You can create that table from Logic app as well, but it's upto you. Here I have already created that table inorder to reduce an extra step

          Search for Azure Table Storage and select "Insert Entity" action

• Give a name for your table storage connection, select your storage account and hit "Create"

• Select your table name from the Table dropdown. Paste the JSON payload here and replace the values with the parameters from the dynamic content selection box. As we are saving data in Azure Storage Table so make sure to modify your payload with PartitionKey and RowKey parameters to make an unique combination for each row item. I have used the orderNo and orderCustMobile fields but you can make your wish here 😐

• Click "+ New Step" to add a FreshDesk service ticket action.

• Provide your FreshDesk connection parameters and hit Create

• Fill up the ticket details to be logged. You can decorate it as per your requirement. For the Email dropdown choose any dummy name as it doesn't matter for this demo. In real life scenario you will be having your user list. Here our purpose is to log a service ticket.

• Click "+ New Step" to add a Twilio SMS action. Select "Send Text Message (SMS)" action

• Enter the Connection Name of your choice, Twilio Account id (the ACCOUNT SID value in the Twilio portal) and the Twilio Access Token (the AUTH TOKEN value in the Twilio portal) and hit "Create"

• Select the From Phone number which will be automatically populated from your Twilio account. Decorate your SMS message as you wish. 

• Click "Save" at the top to save your logic app. This step is very important 😀

Show Time !!!!!!!

Copy the Http POST Url from the first step of your logic app and open postman. We are about to make a rest call. 

Paste the Url at the address bar, select JSON (application/json)  as content type and put your JSON payload in the body as raw input. Hit Send to get a 202 Accepted response back.

You have successfully made a rest call. Now three activities should happen. We must receive a record in table storage, service ticket logged in FreshDesk and a SMS in our mobile phone.

Open Azure Storage explorer and Aha! we have a new record in table

Open your FreshDesk ticketing dashboard and Voila! we have new service ticket 😲

Click the ticket and drill down to its details. Yep it showing the order details just as we configured it to be 👍

Awesome!... now as a last step lets check the mobile phone only to find the SMS sitting in our inbox. Now how cool is that !!!!!!!!  👏👏👏

We have successfully achieved our goal and the power of logic app simply drives us crazy. We have achieved a complicated, cost-effective and integrated solution using the serverless flavour of Azure with NO CODE.  Good job! 

Congratulations! for coming this far. Hope this article will help you to further explore this feature.

Do share with me about your experience and what you have built upon this foundation. You can take it up to any level and integrate. I would love to hear from you.