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.

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.