Going with the Flow: Part 6 - Completing the Flow

Going with the Flow: Part 6 - Completing the Flow

In all the steps leading up to this point we have created a Flow to save an attachment from our email to Azure Blob Storage, and created a Powershell Runbook in Azure to parse the PDF and extract the bill values.

In this step, we're going to take the output of the Runbook and feed it into a new Flow that will create the item in our Calendar.

Introduction

The first Flow that we created is unique to each bill that you want to process. It contains unique values such as the email subject that acts as the Flow's trigger, and the attachment type (if any), and it's content. For example, the email and bill from my electricity provider is going to be different from that of my mobile phone provider.

The ultimate goal is to create multiple Flows for each different bill type you want to process (i.e. electricity / mobile phone etc), and send a key/value pair in the POST body (such as BillName=Electric) that we can reference in our Azure Runbook to execute code that is unique to the processing of that particular bill type.

Even though that the bill email content is different, the bill attachment content is different, and the powershell code necessary to process each bill type will be different, we will want to write the Powershell in such a way that the output will be of a standard that we define. We want to extract the exact same values from each of the bills and return it to a new 'generic' Flow that we can use to take action in a standardized way - such as adding an event to a calendar.

Steps

Update the trigger Flow

Edit the HTTP post of the trigger flow we created earlier, to include a JSON key/value pair in the body.

{ "BillName":"electric" }

This value will determine which Powershell code to run in our Azure Runbook later on.

Create the 'Take Action' Flow

Back in Microsoft Flow, create a new Flow called Take Action. This Flow will contain a trigger that will accept the JSON data to from our Azure Runbook, allowing us to take action on the results.

Create a new action of type Request / Response

Note: You won't be able to see the HTTP POST URL until the Flow is saved.

The Powershell code we created in Step 4 extracts our important bill info, and returns a JSON object of the values. For each different bill type that is being processed, you'll want to make sure you're returning the same JSON object structure, with the same keys but with different values - this is what defines our standard.

In the Request Body JSON Schema we need to define what a valid JSON request looks like by telling it about our key/value pairs that we defined as our standard.

{
  "properties": {
    "provider": {
      "type": "string"
    },
    "service": {
      "type": "string"
    },
    "billingPeriodStart": {
      "type": "string"
    },
    "billingPeriodEnd": {
      "type": "string"
    },
    "dateDueUTC": {
      "type": "string"
    },
    "dateDue": {
      "type": "string"
    },
    "amount": {
      "type": "string"
    },
    "paymentType": {
      "type": "string"
    }
  },
  "type": "object"
}

Add a new step to create an Outlook Calendar event. You should now be able to select the dynamic fields that relate to your JSON schema definitions and apply them to the appropriate places on your calendar event.

.. And add a push notification for good measure.

Save the Flow.

Update the Azure Runbook

With Azure Runbooks, we can store the body of a POST made to it's webhook by storing it within a built-in paramerter called $WebhookData. To utilize it, simply add a parameter definition to the very top of the Powershell code.

param (
    [object]$WebhookData    
)

The WebhookData object contains three properties with each HTTP Post.

  1. $WebhookData.WebhookName = The name of the webhook that was executed
  2. $WebhookData.RequestHeaders = The request headers included in the POST request.
  3. $WebhookData.RequestBody = the request body included in the POST request.

In our case, it's the WebhookData.RequestBody that will contain the BillName key/value pair that we defined in our Flow - so that's the one we're going to want to utilize in our Powershell code for determining how to process the attachment.

$WebhookBody = $WebhookData.RequestBody
$bill = ConvertFrom-JSON -InputObject $WebhookBody
$billName = $bill.BillName

Write-Output "Bill identified as $billName"

In order to prevent us from having to create a separate Runbook for processing each bill type, we can use the bill name to determine which Powershell code to execute.

Switch ($billName) {
    "MobilePhone" { 
        # Mobile Phone bill parsing code here ...
    }
    "Gas" {
        # Gas bill parsing code here ...
    }
    "Electric" {
        # Electric bill parsing code here ...
    }
}

As explained earlier, the output of your parsing code should be the same JSON structure that we defined as our standard when creating the 'Take Action' Flow.

    # Execute the 'Take Action' Flow by calling it's webhook.
    $uri = '<Webhook URL>'
    Write-Output "Executing Web Request to 'Take Action' Flow"
    Invoke-RestMethod -Uri $uri `
                        -Method Post `
                        -Body $json `
                        -ContentType 'application/json'

A full working code example of my Azure Powershell Runbook code can be found on my github https://github.com/caseymullineaux/blog-goingwiththeflow/blob/master/myBillParser.ps1

What we learned

  • How to start a Flow by posting to a HTTP trigger.
  • How to move data between Microsoft Flow and Azure Runbooks using HTTP POST requests with JSON payloads.

Next Steps

Now that all the hard work is done and our workflow is automated end-to-end, let's have some fun with it by adding data visualizations in PowerBi.

Continue to Step 7: Visualizing data in PowerBI

Related Article