Microsoft Flow as a Service for Custom Applications

I've been so eager to write about Microsoft Flow since I have started using it about a year ago! However, I've seen a lot of articles out there by community contributors talking about almost every single capability that Flow can do ... In addition, I personally believe that the Microsoft Flow team is doing a good job putting people on the right learning track.

There are many scenarios that we could consider using Flow with, however in this very post I'll be writing about when to consider Flow while building custom developed applications ... Flow could be your "LEGO" building block for almost every application!

As developers, almost every single one of us have developed against at least one API, and I surely believe that many have developed APIs that connects to third party services and/or social media ... Now, this task is usually a bit costly during the project, whereas developers have to go through the technical documentation for those APIs and absorb them in order begin development, not to mention the troubleshooting (trial and error) until the APIs' authentication and functionalities are set correctly and ready to be used.

Microsoft Flow team have already been through this process, building those nicely done, "ready to use" connectors. So instead of -reinventing the wheel- developing the APIs from scratch (in our application), we could build our service block (Twitter for example) in Flow and then call it from our custom application(s) through the HTTP request trigger available in Flow! something similar to the figure below.

This would save a lot of time when building a third party API service, in addition, service blocks are maintained and managed outside the code, giving more flexibility and scalability to the application. 
For example, user account/authentication can be managed from Flow not from the code! There might be one downside, this can only be utilized with Flow licensed clients, however a considerable amount of custom applications are deployed in Azure which in turn means that such deployments most likely has a license for Flow :)

Enough with the talk! Here comes an example...
Let's assume -a common scenario- that we want to build a custom application that posts tweets from within.

Flow Service Block

We start by building our service block in Flow. First we need an HTTP request trigger, which going to initiate the workflow and later action(s) once received. Notice that the HTTP post URL will be available once we save the workflow. 

In addition we need to define the JSON request body schema that will hold our parameter(s) from the custom application to Flow. In our case we will keep it simple and send one parameter, which is the tweet text, and the JSON schema will be as follows:

1:  {   
2:   "type": "object",   
3:   "properties": {   
4:      "tweetText": {   
5:        "type": "string"   
6:            }   
7:          },   
8:      "required": [ "tweetText" ]   
9:  }  

The next thing we need to do is add our Twitter connector/action. 
Notice that the JSON object property(ies) that we have defined in the trigger is(are) now available within the next action. Now, in the Tweet text field we add tweetText property from the JSON object.
Notice that right before this step we can add any logic that we want, and by that we minimize the amount of code to be written. Additionally, we could add changeable check logic maintainable outside of our code, for example, checking the number of characters in a tweet.

Finally, we want to return a response back to the application indicating that the flow (service) succeeded ... So we add a response action returning a status code of 200, the same headers came with the request and the following JSON:

1:  {  
2:   "status": "success"  
3:  }  

Notice that we could return more properties along with the JSON object sent back to the application (e.g. Tweet ID) but we are keeping it simple this time!

Application Calling Flow

At this point, we are ready to call our flow (service) from the application ... We will make it simple and easy, so let's create a windows console application and throw the following code in:

1:  using System;  
2:  using RestSharp;  

Make sure you install the "RestSharep" NuGet package so you could reference it in your code and then add: 

1:  static void Main(string[] args)  
2:      {  
3:        Console.ForegroundColor = ConsoleColor.Magenta;  
4:        Console.WriteLine("Enter text to Tweet! -->");  
5:        Console.WriteLine();  
6:        Console.ForegroundColor = ConsoleColor.Cyan;  
7:        string tweetText = Console.ReadLine();  
8:        Tweet(tweetText);  
9:      }  
10:    
11:      static void Tweet(string tweetText)  
12:      {  
13:        var client = new RestClient("HereGoesTheLinkFromRequestActionInFlow");  
14:        var request = new RestRequest(Method.POST);  
15:        request.AddHeader("cache-control", "no-cache");  
16:        request.AddHeader("content-type", "application/json");  
17:        request.AddParameter("application/json", "{\r\n  \"tweetText\": \"" + tweetText + "\"\r\n}", ParameterType.RequestBody);  
18:        IRestResponse response = client.Execute(request);  
19:        Console.ForegroundColor = ConsoleColor.Green;  
20:        Console.WriteLine(response.StatusCode);  
21:        Console.WriteLine(response.ResponseStatus);  
22:        Console.ForegroundColor = ConsoleColor.Yellow;  
23:        Console.WriteLine(response.Content);  
24:        Console.ReadLine();  
25:      }  

Demo!

Voilà