We zijn klaar met spelen. Het is tijd voor het echte werk. Tot nu toe hebben we alles lokaal gedaan met de Storage Emulator, maar nu is het tijd om te deployen naar Azure. We gaan de Cloud in! En daar lopen we ook tegen een paar dingen aan:

1. Beheer
2. Monitoring
3. Versioning bij veranderingen (deel B)
4. Security (deel B)

We zullen ze allemaal bekijken!

Deployment

Vanuit Visual Studio is het deployen van je Function App een fluitje van een cent. Je moet wel een Azure subscription hebben (een trial is gratis…). Verder raad ik je aan om alvast een Resource Group aan te maken in de portal. Dan heb je die maar vast.

Deployen gaat zoals altijd gewoon vanuit Visual Studio met de rechter button op het project en dan Publish. Uiteraard kan dit beter, maar we zullen naar CI / CD kijken als het moment daar is. Ik raad sowieso aan om eerst een handmatige deployment te doen.

In VS kunnen we dus Publish kiezen. Dan krijg je deze dialog:

Je hebt verschillende soorten van deployment. Ik raad in dit geval aan om Azure Functions Consumption plan te kiezen. Premium is sneller maar je betaalt een heel stuk meer. Bij Consumption betaal je naar gebruik. Dus als je workflow wacht op de beheerders tot ze eindelijk een keer die link in de email openen, betaal je niets. We blijven Hollanders, niet waar?

Klik op Create Profile.

Ik heb even wat waardes aangepast (naam van de service, location en zo) maar echt spannend is dit allemaal niet.

Click Create. Dit zorgt er niet voor de deployment plaats vindt, maar dat er een profile aangemaakt wordt waar vanuit je kunt gaan deployen. Er is dus nog niets naar Azure toe.

Laten we dat eens veranderen.

Dit scherm verschijnt. Nu kunnen we gaan deployen maar ik raad je aan om eerst op de link voor “Edit Azure App Service settings” te klikken:

Je kunt dit namelijk ook prima achteraf in de Azure Portal doen, maar nu krijg je ook te zien hoe je development settings waren.

Je ziet de settings voor de Usergroups en die voor SendGridAPIKey. Die kun je gewoon kopiëren. De AzureWebJobsStorage is lokaal ingesteld op de emulator, maar remote staat hij ergens anders op (je ziet maar een klein stukje van mijn AccountKey, dus die hoef ik niet zwart te maken). De rest laten we lekker zoals het is.

Klik OK. Klik Publish. Haal koffie…

Het duurt even maar op een gegeven moment is hij wel klaar. Onderin je output window staat iets als Publish: 1 succeeded.

Het wordt tijd om de Portal te bekijken. Ga naar de https://portal.azure.com, vind je Resource Group en kijk wat er allemaal gebeurt is. Bij mij ziet er nu zo uit:

Er zijn 3 resources aangemaakt.

1. meetingregistration: een Storage Account. Deze bevat de queues, TableStorage en meer. Die had ik al handmatig aangemaakt dus deze telt niet
2. MeetingRegistrationAppService: de App Service die de binaries bevat.
3. WestEuropePlan. Mijn App Service plan . Niet zo spannend.

Klik op de App Service om te kijken wat we daar hebben:

Als het goed is, zie je nu waarom ik met de O_ en A_ prefix werk. Zelfs in deze hele kleine flow hebben we al best wat functies. We hebben twee publieke functies (de starter en de cleanup), we hebben 3 orchestrators en we hebben 5 activities.

Kies de starter functie StartRegistration. In het detail window zie je nu </> Get Function URL.. Open die en kopieer de inhoud.

Deze URL kun je nu pasten in de browser. Vervang de standaard dummy waardes {name}, {email} en {wantsTweet} door echte waardes (om te testen geef ik hem even een ongeldige email zodat we niet door de hele flow heen hoeven).

Als ik dan op de statusQueryGetUri klik, krijg ik dit:

// 20191104161833
// https://meetingregistrationappservice.azurewebsites.net/runtime/webhooks/durabletask/instances/287094e6d11e48f8b7b73904c6ea206a?taskHub=DurableFunctionsHub&connection=Storage&code=4CtGP4ZKJJZYQ85RyhZ1PrILDm6zG3quHWOe9pkVtrOq26eCroxNsw==

{
  "name": "O_PerformRegistration",
  "instanceId": "287094e6d11e48f8b7b73904c6ea206a",
  "runtimeStatus": "Completed",
  "input": {
    "$type": "MeetingRegistration.Attendee, MeetingRegistration",
    "Name": "Dennis",
    "Email": "dennisatvroegop.org",
    "WantsTweet": true
  },
  "customStatus": null,
  "output": {
    "IsSucces": false,
    "Reason": "Not a valid email given."
  },
  "createdTime": "2019-11-04T15:18:29Z",
  "lastUpdatedTime": "2019-11-04T15:18:30Z"
}

Alles is goed gegaan. Nou ja, technisch dan. Het email adres was niet geldig, dus die rejecten we. Als je dit nu helemaal gaat uitvoeren, dus met geldig email adres, let er dan even op dat we in onze code hard-coded HTTP gebruiken in de link in de email. Dat moet hier uiteraard HTTPS zijn….

Monitoring

Als je wilt weten hoe het met je functies gaat, is Application Insights de beste methode. Om dat te doen, moet je in je Resource Group een AppInsights instance aanmaken:

Als de App Insights resource gemaakt is, kun je er naar toe navigeren. In het menu links kun je dan kiezen voor API Access.

Hier kun je dan een key genereren. Kies alle opties, voor nu is dat prima. Je krijgt dan een key die je moet kopieren en plaatsen bij de App Service. Dat gaat heel eenvoudig: navigeer naar je App Service en zie bovenin staan “Application Insights is not fconfigured”

Klik daarop en volg de wizard. Het enige wat dit doet, is in je settings van je app service een key toevoegen met de naam APPINSIGHTS_INSTRUMENTATIONKEY met de key die we net hadden aangemaakt erin.

Draai je workflow nog een keer, en ga dan naar die App Insights. Dit keer draai ik hem helemaal.

Dit is de map. Ik heb 1 instance, die doet 5 calls naar de Azure Table en 1 call naar de Queue. En oh ja, iets naar API.SendGrid.com

Als ik naar de Overview ga, zie ik 5 errors:

Dat klopt natuurlijk: dat zijn de exceptions van onze ‘twitter-client’.

Ik kan daarop helemaal inzoomen:

Je ziet: met Application Insights kun je enorm veel informatie verzamelen op een hele makkelijke manier.

En verder?

Ik had je nog een stukje beloofd over versioning en security maar dat doen we in de volgende post wel.

Succes!

Onze workflow is af. Alles doet het. Niets aan de hand. Mensen die zich op de website inschrijven worden nu gecontroleerd, gedeeld met andere groepen, worden beoordeeld door het bestuur van Stichting dotNed en hun aanwezigheid wordt gedeeld op Twitter (of ze het nu willen of niet: zie einde vorige post).

Er is alleen een maar: we hebben een database met potentiele attendees die goedgekeurd moeten worden. Die database vult zich langzaam aan met niet meer relevante data. Nu kunnen we dat eenvoudig oplossen door in de Azure Function die aangeroepen wordt vanuit de email de boel weg te gooien, maar ik weet een mooiere variant. Ik heb het over eeuwig durende orchestrations.

Orchestrations hebben een paar regels. Eentje hebben we al uitgebreid gesproken: ze moeten deterministisch zijn. We mogen dus niet een database uitlezen, de config uitlezen, Guid.NewGuid() aanroepen, DateTime.Now gebruiken enzovoorts. Iets wat WEL mag maar eigenlijk niet zo moeten mogen is de volgende dummy orchestrator:

[FunctionName("O_CleanUpDatabases")]
public static async void CleanUpDatabases(
    [OrchestrationTrigger] DurableOrchestrationContext ctx, 
    ILogger log)
{
    while (true)
    {
        log.LogWarning("Cleaning up the database.");
        // Call code to clean the database with old stuff
        await Task.Delay(TimeSpan.FromDays(1));
    } // And restart...
}

Op zich is hier niet zo heel veel mis mee. We starten de orchestration en die gaat de database opruimen in een of andere activity. Dan wachten een dag. En dan gaan we weer opnieuw beginnen.

Maar dit heeft een paar problemen: ten eerste kost dit geld. Als je het Consumption Plan gebruikt in Azure, betaal je alleen voor de tijd die het kost om je werk uit te voeren. Onze email verzending bijvoorbeeld wacht 24 uur (nou ja, 30 seconden in onze demo) voor hij verder gaat. Die hele 24 uur is onze workflow idle en kost ons geen geld.

Met een Task.Delay blijft de orchestration in de lucht, 24 uur lang. En daar betaal je voor.

Task.Delay is trouwens een van de calls die je niet mag doen in Durable Functions. Je kunt wel een TimerActivity maken, die doet ongeveer hetzelfde. Maar dan nog hebben we een probleem.

Event sourcing

Weet je nog die tabel in de TableStorage waar alle calls ingelogd werden? Weet je nog hoe groot die werd? Het idee erachter is dat je altijd de hele flow terug kan spelen door alle events van het begin af aan opnieuw te laten gebeuren. Dit is event sourcing: alle events, timestamps, input en output wordt opgeslagen.

Stel je nu eens voor een orchestration zoals bovenstaande, die iedere minuut iets doet. Voor altijd. Dat wordt heel veel data in de tabel. Op niets af: want je wilt nooit exact hetzelfde event afspelen van 2 jaar geleden.

Dus dat kan anders. En dat moet anders. En dat gaan we doen ook.

[FunctionName("O_CleanUpDatabases")]
public static async void CleanUpDatabases(
    [OrchestrationTrigger] DurableOrchestrationContext ctx,
    ILogger log)
{
    var counter = ctx.GetInput<int>();
    log.LogWarning($"Cleaning up the database, number {counter}.");
    // Call code to clean the database with old stuff

    counter++;
    var nextCallTime = ctx.CurrentUtcDateTime.AddSeconds(10);
    await ctx.CreateTimer(nextCallTime, CancellationToken.None);

    ctx.ContinueAsNew(counter);
}

Deze code lijkt wat ingewikkelder maar dat valt mee. Ik doe sowieso iets extra’s: ik hou bij hoe vaak dit uitgevoerd wordt. In de orchestration context heb ik nu een int waarde die die aantallen bijhoudt. Die lees ik uit in regel 6.

Vervolgens gaan we loggen en de database opruimen. Dat laatste doen we uiteraard in een activity, maar die kennen we nu wel dus ik laat het even zo. Ik verhoog daarna de counter.

Dan vraag ik aan de runtime de huidige datetime en tel daar 10 seconden bij op (dat moet uiteraard 24 uur zijn maar dat demo’ed zo lastig). Ik maak een timer aan die die tijd wacht en geef geen CancellationToken mee.

En dan roep ik ctx.ContinueAsNew(counter) aan.

Looping in een orchestration

Wat doet die call naar ContinueAsNew nu? Wel, er gebeuren een paar dingen.

Ten eerste wordt de counter variable opgeslagen. Dan verlaten we de orchestration waarna de runtime meteen een nieuwe aanmaakt. Alle data met betrekking tot de oude instance wordt weggegooid: die hebben we niet meer nodig. En dan begint hij weer van voor af aan: we hebben een nieuwe orchestration. Deze heeft een nieuwe ID, de IsReplaying is in het begin al False, en ctx.CurrentDateTime geeft ook echt ctx.CurentDateTime aan.

Als we nu meerdere activities zouden aanroepen, gelden nog steeds de regels die we al hadden: na iedere aanroep van de activity verdwijnt de orchestration even om daarna weer verder te gaan met IsReplaying = true (en ctx.CurrentUtcDateTime geeft die oude waardes terug).

Het enige verschil met de vorige run is dat counter nu 1 hoger is.

Om hem af te maken geef ik je ook even de standaard Azure Function die hem aftrapt:

public static async Task<HttpResponseMessage> StartDatabaseCleanUp(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)]
    HttpRequestMessage req,
    [OrchestrationClient] DurableOrchestrationClient client,
    ILogger log)
{
    log.LogWarning("About to start the clean up method");

    var instanceId = await client.StartNewAsync("O_CleanUpDatabases", 0);
    return client.CreateCheckStatusResponse(req, instanceId);
}

De werking hiervan lijkt me duidelijk. Dit is een normale function en de runtime geeft ons de URL die we kunnen gebruiken.

Next steps

Ok. We gaan de veilige omgeving van onze emulators verlaten en we gaan deployen. Want: er is daar wel het een en ander over te zeggen, zoals monitoring en versioning. Maar: dat doen we een volgende keer!

Onze workflow is bijna klaar. We hebben nog een stap te gaan: het al dan niet versturen van de tweet met daarin de tekst “{attendee} komt naar onze bijeenkomst!” Deze tweet is optioneel: niet iedereen wil dat delen met de wereld.

Ik ga niet de code schrijven die daadwerkelijk naar Twitter gaat. Die voorbeelden zijn genoeg te vinden. Echter: Twitter wil wel eens fouten genereren. Je bent over je limiet heen, of Twitter is tijdelijk down. Hoe gaan we daar mee om? Laten we dat eens simuleren in de activity:

Uiteraard hebben we eerst een DTO nodig:

namespace MeetingRegistration
{
    public class TweetData
    {
        public string Name { get; set; }
    }
}

We hadden ook gewoon een string kunnen doorgeven, maar ik hou van expressieve code. Vandaar deze class.

De activity:

[FunctionName("A_SendTweet")]
public static void SendTweet([ActivityTrigger] TweetData tweetData, ILogger log)
{
    log.LogWarning($"About to send a tweet about {tweetData.Name}.");
    if (new Random().NextDouble() > 0.3)
    {
        throw new Exception("Twitter is down!");
    }
    log.LogWarning("Successfully sent out the tweet...");
}
    

Ok, ik geef toe: Twitter is wel wat robuuster dan dat. 1 in de 5 tweets lukken slechts. Maar dit geeft me wel mooi de kans om te laten zien hoe we de boel wat stabieler kunnen krijgen.

De orchestrator zouden we als volgt kunnen maken (na het wachten op het externe event):

var tweetData = new TweetData {Name = attendee.Name};
int maxCount = 5;
bool tweetIsSent = false;
while ((!tweetIsSent) && (maxCount-- > 5))
{
    try
    {
        await ctx.CallActivityAsync("A_SendTweet", tweetData);
        tweetIsSent = true;
    }
    catch (Exception ex)
    {
        log.LogError("Oeps!" + ex.Message);
        // Wait 5 seconds before retrying
        Task.Delay(5000);        
    }
}

if (!tweetIsSent)
{
    log.LogError("Tweet did not get sent after retrying.. too bad!");
}

Zo iets dus. Maar dit is niet echt handig: ten eerste is dit niet deterministisch, dus dit zou eigenlijk in een activity moeten. Daarnaast: het is weer plumbing. En daar willen we zo veel mogelijk vooraf.

Dit is hoe bovenstaande code WEL moet:

var tweetData = new TweetData {Name = attendee.Name};

var retryOptions = new RetryOptions(TimeSpan.FromSeconds(5.0), 5);
try
{
    await ctx.CallActivityWithRetryAsync("A_SendTweet", retryOptions, tweetData);
}
catch (Microsoft.Azure.WebJobs.FunctionFailedException functionFailedException)
{
    log.LogError("Tweet did not get sent after retrying.. too bad!\n" + functionFailedException.Message);
}

We beginnen weer met een TweetData instance. Hierna maken we een instance aan van een RetryOptions class. Deze heeft als constructor parameters de tijd die tussen retries in moet zitten, en een aantal keer dat het opnieuw geprobeerd mag worden. Er zijn nog meer opties, zoals de initiële tijd tussen de eerste call en de tweede, of de tijd moet toenemen tussen pogingen door en nog meer van dat soort dingen.

We roepen in een try catch CallActivityWithRetryAsync aan en geven, naast de normale parameters, nu ook de RetryOptions mee. Als er nu iets fout gaat in de activity, wordt deze, na 5 seconden, nog een keer aangeroepen. En dit tot een maximum van 5 keer. Als het dan nog niet gelukt is, krijgen we een FunctionFailedException en daar kunnen we wel wat mee.

Het zal je niet verbazen dat CallSubOrchestratorAsync ook een dergelijke variant heeft: CallSubOrchestratorWithRetryAsync. En die werkt net zo.

Ik raad je aan om deze variant zo veel mogelijk te gebruiken op plekken waar er maar iets fout zou kunnen gaan. Op deze manier is je function veel robuuster geworden.

Oh ja: ik weet dat ik NIET controleer of de parameter wantsTweet wel op true staat… Maar dat soort code laat ik graag aan jou over. Het vervuilt mijn voorbeelden zo…

En nu?

Onze workflow is klaar! We kunnen aan het werk en we kunnen inschrijvingen verwachten op onze events. Maar wij als ontwikkelaars zijn nog niet klaar (zijn we dat ooit?).

Want: onze approvalAttendee database loopt lekker vol met data die we niet meer nodig hebben. Maak je geen zorgen: dat gaan we in de volgende post oplossen!

Onze workflow begint al aardig volwassen te lijken. We hebben de input gevalideerd, we hebben berichten verstuurd naar andere groepen en we hebben een email verstuurd en de info daarover in de database geplaatst. Dat laaste hebben we in onze vorige post gezien.

Onze workflow staat nu keurig te wachten tot het een seintje krijgt om verder te gaan (of tot er een time-out plaatsvindt). Hoe doen we dat? Simpel: met Azure Functions!

De link die we in de mail versturen is een link naar een Azure Function. Dus we gaan die maar eens maken. Het is een gewone, recht-toe, recht-aan Azure Function dus niet Durable. Hij is publiek dus hij kan in de class PublicFunctions.cs.

[FunctionName("ApproveAttendee")]
public static async Task<HttpResponseMessage> ApproveAttendee(
    [HttpTrigger(
        AuthorizationLevel.Anonymous,
        "get",
        Route = "processApproval/{rowKey}/{isApproved}")]
    HttpRequestMessage req,
    [OrchestrationClient] DurableOrchestrationClient client,
    string rowKey, bool isApproved,
    ILogger log
)
{
    log.LogWarning($"We received {isApproved} for key {rowKey}.");
    return req.CreateResponse(HttpStatusCode.OK);
}

De FunctionName heeft geen prefix. Het is immers een gewone publieke method. We zetten de authenticatie op anonymous: we willen geen authenticatie keys delen met het publiek en de unieke ID is authenticatie genoeg voor ons. Voor de rest doen we niets spannends. We zetten de route goed zodat we de parameters krijgen. Deze route past bij de route die we in de activity hebben waar we de email aanmaken.

Ik vraag ook gelijk een instance van de DurableOrchestrationClient toe: die hebben we later nodig.

Als we dit nu starten, zien we in de debug informatie van de runtime nu ineens twee publieke functions:

We hebben nu dus ApproveAttendee erbij. Ik weet het: de naam is niet helemaal goed want we kunnen potentiele Attendees ook afwijzen maar ik benader dingen graag positief.

Als we nu naar de mail gaan die we verzonden hebben terwijl de runtime draait, kun je op de link klikken (approve of deny, net wat je wilt). De URL is immers geldig nu. Zo gauw je dat doet, zul je het resultaat in de debug zien verschijnen.

Vervolgen van de workflow

Ok. Laten we de code gaan schrijven die de workflow weer verder helpt.

Als eerste hebben we de instanceId van de workflow nodig. Die moeten we immers een signaal sturen. Die instanceId staat in de database. Om die op te halen moeten we een partitionkey en een rowkey hebben. Die hebben we ook: de partitionkey was hardcoded op AttendeeApprovals en de rowkey krijgen we mee in de call naar deze function. Door middel van de juiste injection in de signature van deze method kunnen we de data dus opvragen:

[FunctionName("ApproveAttendee")]
public static async Task<HttpResponseMessage> ApproveAttendee(
    [HttpTrigger(
        AuthorizationLevel.Anonymous,
        "get",
        Route = "processApproval/{rowKey}/{isApproved}")]
    HttpRequestMessage req,
    [OrchestrationClient] DurableOrchestrationClient client,
    [Table(
        "Attendees", 
        "AttendeeApprovals", 
        "{rowKey}", 
        Connection = "AzureWebJobsStorage")] 
    StoredOrchestration storedOrchestration,

    string rowKey, bool isApproved,
    ILogger log
)
{

De method heeft nu een Table erbij gekregen, maar in tegenstelling tot de activity, geven we hier nogal wat extra data mee. In het attribuut Table hebben we nu de Table name, de partitionkey en de rowkey (die komt uit de route) en de Connection weer. Het is in de vorm van een StoredOrchestration, want zo hadden we hem ook weggeschreven. Dit keer is het geen out-parameter want we krijgen hem nu mee.

Als iemand nu deze function aanroept, zal de runtime de juiste data ophalen en in de storedOrchestration plaatsen. Als er geen data is voor deze rowKey krijg je een NULL value terug. Daar kunnen we op controleren: als iemand maar wat verzint en intypt, hebben we geen bijbehorende entry in de tabel en dus hoeven we er niets mee.

Het enige wat ons nu nog rest is de runtime vertellen dat de flow verder mag en wat de beslissing van het bestuur is geweest. De hele method ziet er nu dus zo uit:

[FunctionName("ApproveAttendee")]
public static async Task<HttpResponseMessage> ApproveAttendee(
    [HttpTrigger(
        AuthorizationLevel.Anonymous,
        "get",
        Route = "processApproval/{rowKey}/{isApproved}")]
    HttpRequestMessage req,
    [OrchestrationClient] DurableOrchestrationClient client,
    [Table(
        "Attendees", 
        "AttendeeApprovals", 
        "{rowKey}", 
        Connection = "AzureWebJobsStorage")] 
    StoredOrchestration storedOrchestration,

    string rowKey, bool isApproved,
    ILogger log
)
{
    log.LogWarning($"We received {isApproved} for key {rowKey}.");

    if (storedOrchestration == null)
    {
        log.LogWarning("Received illegal request.");
        return req.CreateResponse(HttpStatusCode.NotFound);
    }

    await client.RaiseEventAsync(storedOrchestration.OrchestrationId, "E_BoardHasApproved", isApproved);

    return req.CreateResponse(HttpStatusCode.OK);
}

Dus: we halen de data op, we krijgen de storedOrchestration (of niet…). We controleren die data en als die null is, geven we een mooie 404 terug.

Als de data er wel is, roepen we de workflow runtime aan met de method RaiseEventAsync. Die krijgt de naam die we ook al bij WaitForExternalEventAsync hadden gebruikt: “E_BoardHasApproved” en als payload geven we de waarde true of false mee. Daarna geven we een 202 status code terug.

Als je dit nu runt, zul je zien dat zo gauw we de RaiseEventAsync aanroepen, de orchestrator gaat replayen en weer verder gaat.

En nu?

We zijn er bijna. We moeten alleen nog een tweet versturen. Dat doen we in de volgende post!