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:
Then a table:
We’ll enter some data using Storage Explorer:
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:
For Logic App integration, a Generic WebHook seems to work best:
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:
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):
Add the function:
Add the input variables (remember that the parameters read by the function above are passed in via the query):
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:
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):
That will then generate a schema for you:
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:
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:
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:
All the subsequent logic is inside the true branch. The next thing is to work out how long to delay:
Now we have a number between 1 and 60, we can wait for that length of time:
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:
Once you’ve done this, you’ll have access to the parts of the record and can add the Tweet action:
And we have a successful run… and some tweets:
