What can you do with a logic app? Part One - Send tweets at random intervals based on a defined data set

March 11, 2018

I thought I’d start another of my patented series’. This one is about finding interesting things that can be done with Azure Logic Apps.

Let’s say, for example, that you have something that you want to say; for example, if you were Richard Dawkins or Ricky Gervais, you might want to repeatedly tell everyone that there is no God; or if you were Google, you might want to tell everyone how .Net runs on your platform; or if you were Microsoft, you might want to tell people how it’s a “Different Microsoft” these days.

The thing that I want to repeatedly tell everyone is that I’ve written some blog posts. For this purpose, I’m going to set-up a logic app that, based on a random interval, sends a tweet from my account (https://twitter.com/paul_michaels), informing people of one of my posts. It will get this information from a simple Azure storage table; let’s start there: first, we’ll need a storage account:

logic apps 1

Then a table:

logic apps 2

We’ll enter some data using Storage Explorer:

logic apps 3

After entering a few records (three in this case - because the train journey would need to be across Russia or something for me to fill my entire back catalogue in manually - I might come back and see about automatically scraping this data from WordPress one day).

In order to create our logic app, we need a singular piece of custom logic. As you might expect, there’s no randomised action or result, so we’ll have to create that as a function:

logic apps 4

For Logic App integration, a Generic WebHook seems to work best:

logic apps 5

logic apps 6

Here’s the code:



#r "Newtonsoft.Json"
using System;
using System.Net;
using Newtonsoft.Json;
static Random \_rnd;

public static async Task<object> Run(HttpRequestMessage req, TraceWriter log)
{
    log.Info($"Webhook was triggered!");
    if (\_rnd == null) \_rnd = new Random();
    string rangeStr = req.GetQueryNameValuePairs()
        .FirstOrDefault(q => string.Compare(q.Key, "range", true) == 0)
        .Value;
    int range = int.Parse(rangeStr);
    int num = \_rnd.Next(range - 1) + 1; 
    var response = req.CreateResponse(HttpStatusCode.OK, new
    {
        number = num
    });
    return response;
}

Okay - back to the logic app. Let’s create one:

logic apps 7

logic apps 8

The logic app that we want will be (currently) a recurrence; let’s start with every hour (if you’re following along then you might need to adjust this while testing - be careful, though, as it will send a tweet every second if you tell it to):

logic apps 9

Add the function:

logic apps 10

Add the input variables (remember that the parameters read by the function above are passed in via the query):

logic apps 11

One thing to realise about Azure functions is they rely heavily on passing JSON around. For this purpose, you’ll use the JSON Parser action a lot. My advice would be to name them sensibly, and not “Parse JSON” and “Parse JSON 2” as I’ve done here:

logic apps 12

The JSON Parser action requires a schema - that’s how it knows what your data looks like. You can get the schema by selecting the option to use a sample payload, and just grabbing the output from above (when you tested the function - if you didn’t test the function then you obviously trust me far more than you should and, as a reward, you can simply copy the output from below):

logic apps 13

logic apps 14

That will then generate a schema for you:

logic apps 15

Note: if you get the schema wrong then the run report will error, but it will give you a dump of the JSON that it had - so another approach would be to enter anything and then take the actual JSON from the logs.

Now we’ll add a condition based on the output. Now that we’ve parsed the JSON, “number” (or output from the previous step) is available:

logic apps 16

So, we’ll check if the number is 1 - meaning there’s a 1 in 10 chance that the condition will be true. We don’t care if it’s false, but if it’s true then we’ll send a tweet. Before we do that , though - we need to go the data table and find out what to send. Inside the “true” branch, we’ll add an “Azure Table Storage - Get Entities” call:

logic apps 17

This asks you for a storage connection (the name is just for you to name the connection to the storage account). Typically, after getting this data, you would call for each to run through the entries. Because there is currently no way to count the entries in the table, we’ll iterate through each entry, but we’ll do it slowly, and we’ll use our random function to ensure that all are not sent.

Let’s start with not sending all items:

logic apps 17 1

logic apps 17 2

logic apps 17 3

All the subsequent logic is inside the true branch. The next thing is to work out how long to delay:

logic apps 18

Now we have a number between 1 and 60, we can wait for that length of time:

logic apps 18 1

The next step is to send the tweet, but because we need specific data from the table, it’s back to our old friend: Parse JSON (it looks like every Workflow will contain around 50% of these parse tasks - although, obviously, you could bake this sort of thing into a function).

To get the data for the tweet, we’ll need to parse the JSON for the current item:

logic apps 18 2

Once you’ve done this, you’ll have access to the parts of the record and can add the Tweet action:

logic apps 19

logic apps 20

And we have a successful run… and some tweets:

logic apps 22



Profile picture

A blog about one man's journey through code… and some pictures of the Peak District
Twitter

© Paul Michaels 2024