AFAS Profit – Power BI Historische data

Van niet alle data in AFAS Profit wordt de historie opgeslagen, in andere gevallen kan je deze minder gemakkelijk ophalen via connectoren. Een voorbeeld is bijvoorbeeld de forecast module, je kan de huidige status ophalen, maar het is niet te zien welke statussen deze nog meer gehad heeft in het verleden. We gaan dus kijken naar Historische AFAS Data in Power BI.

Mocht je dergelijke data nu wel in Power BI beschikbaar willen hebben zijn er een aantal mogelijke oplossingen. In dit bericht gaan we in op de quick and dirty oplossing. Mocht ik later nog tijd vinden voor een zal ik het bericht verder uitbreiden.

Wat gaan we doen?

We gaan een export ophalen uit AFAS Profit middels een getconnector, deze slaan we vervolgens op in Azure Storage. Dat doen we volgens de instructies uit dit artikel, met een kleine aanpassing. De files worden voorzien van een datumveld, in dit voorbeeld neem ik nog niet het opschonen van de historie mee en bouwen we de historie in principe eindeloos op.

Aanpassing Powershell script

Het enige echte verschil met het script uit het eerder genoemde artikel zit in de loop waar we data ophalen. In het eerste geval overschrijven we altijd de vorige export, maar in dit geval willen we graag meer versies van het bestand opslaan, hiervoor hebben we dus een extra variabele nodig:

foreach ($conn in $todo.getConnectors.id) {
    $naamDatum = Get-Date -Format "dd-MM-yyyy"
    $url = 'https://**URL_VAN_PROFIT_OMGEVING**/profitrestservices/connectors/' + $conn + '?skip=-1&take=-1'
    $file = '.\' + $conn + '.json'
    Invoke-WebRequest -Uri $url -OutFile $file -Headers $Headers -UseBasicParsing
    $filename = $conn + '_' + $naamDatum '.json'
    Set-azurestorageblobcontent -File $file -container $ContainerName -Blob $filename -Context $Context -Force
}

Iedere keer dat het script nu draait zal er een export gemaakt worden van de getconnector, deze wordt vervolgens op de blobstorage opgeslagen met de datum in de filename. Het gevolg hiervan is wel dat je maar 1 export per dag kan maken, iedere keer dat je het script opnieuw draait wordt de huidige dag overschreven.

Power BI

De handigheid zit hem in het consolideren van de diverse bestanden in Power BI. Hiervoor moet je eenmalig wat stappen doorlopen, maar vervolgens zal iedere keer dat je de rapportage ververst de nieuwe data opgehaald worden als die aanwezig is.

Stap 1: Toevoegen blob storage als datasource

In dit artikel staat (onder andere) uitgelegd hoe je blob storage kan toevoegen als datasource in PowerBI. In dit geval kan je de eerste stappen daarvan herhalen tot je dit scherm ziet:

Overzicht met files in de blobstorage
Blobstorage overzicht

Klik hier op OK, er zal een query ingeladen worden waarmee we verder kunnen werken.

Stap 2: Filter de bestanden die je nodig hebt (indien nodig)

Je kan in de tabelweergave die je vervolgens te zien krijgt op het “Name” veld filteren zodat alleen de velden (bestandsnamen) overblijven die je nodig hebt. Je kan hier allerlei filters, waaronder tekstfilters gebruiken.

Filterweergave power BI
Filter invoeren

Het resultaat is dan als het goed is de lijst met json files die je wil inlezen. Dit filter wordt iedere keer bij het verversen van de data toegepast, dus als er na een verversing meer bronbestanden zijn die aan het filter voldoen worden deze ook mee ingelezen.

Gefilterde weergave power bi
Het gefilterde resultaat

Stap 3: Het samenvoegen van de verschillende files

als het goed is hebben de files allemaal dezelfde structuur (LET OP: Dus niet de get-connector nog aanpassen nadat je dit gedaan hebt, dat levert problemen op met je historische data)! Je kan deze nu samenvoegen zodat we vanuit daar verder kunnen werken.

Klik voor het samenvoegen op de twee pijlen naar beneden naast “Content”

Samenvoegen files knop in power bi
Merge files

Je zal nu afhankelijk van de hoeveelheid data heel even moeten wachten, maar uiteindelijk zie je de volgende tabel (iets van die strekking)

Samengevoegde file-lijst power bi
Samengevoegde bestanden

Hier gaan we net als eerder weer een filter op toepassen, in de kolom “Name” filteren we zodat alleen de rows over blijven.

Stap 4: Bronbestanden “uitvouwen”

De volgende stap is het “uitvouwen” van het bronbestand. Door de aard van de JSON files moeten we de “lists” omzetten naar daadwerkelijke regels. Dat doen we als volgt:

Exploderen lijsten naar rijen
Expand to New Rows

Door op de “expand” knop te klikken krijgen we een keuze, kies hier voor “Expand to New Rows”. Je zal wederom even moeten wachten, maar daarna zie je dat er voor iedere regel uit iedere JSON file een regel gemaakt is in de tabel:

Toevoegen kolommen uit importbestanden
Uitgevouwen regels

De vervolgstap is om te bepalen welke kolommen uit de bronbestanden we zichtbaar willen maken in de eindtabel:

Filterweergave power bi
Kolomslectie

Vink de kolommen aan die je wil behouden en druk op OK.

Stap 5: Historisch datumveld prepareren

Je hebt nu de tabel met alle data, maar nog geen mogelijk om hier historisch op te filteren. Hiervoor moeten we het veld met de filename nog afmaken. we hebben de filename eerder in het Powershell script voorzien van de datum waarop de export gemaakt is. We zullen nu dus de overbodige tekst uit dat veld moeten weghalen en er een datumveld van moeten maken.

Onder het kopje “Transform” kan je voor “Replace” kiezen (selecteer eerst de kolom met de filenames):

Replace functie power bi
Replace Values

Je krijgt een dialoog te zien, afhankelijk van de opmaak kan je hier de tekst invullen die je niet meer nodig hebt. In mijn geval moet ik zowel voor als na de waarde die ik wil houden tekst verwijderen, dus ik moet deze handeling twee keer doen. Je voert de tekst in die je wil vervangen door “” oftewel niets, wat effectief betekend dat je de waarde verwijderd.

Replace functie power bi
Filterwaarde

Wanneer je dit zo veel gedaan hebt als je nodig hebt om alleen de datum nog in het veld over te houden kan je het veld transformeren naar een datumveld:

Transformeren kolom in Power BI
Transformeren naar datumveld

Tot slot kan je eventueel nog Kolommen verwijderen die je niet nodig hebt of andere transformaties doorvoeren. Wanneer je klaar bent kie je voor Close & Apply en daarna kan je met je data aan de slag!

Opslaan en verwerken in Power BI

Doordat we nu de exportdatum per regel beschikbaar hebben kan je deze datum als peildatum gebruiken voor bijvoorbeeld historische forecast statussen of debiteurenstanden vanuit AFAS Profit.

Tesla Model 3 VIN status met Azure Logic Apps

Als je je droomauto mag bestellen moet je vaak wachten tot je deze daadwerkelijk in ontvangst mag nemen. Bij Tesla is dat wachten een “beetje” een black box, dus wat doe je dan om de tijd te verdrijven? Inderdaad.. kijken hoe je Microsoft Azure kan toepassen op dat wachtproces ­čśë

Voor wie niet bekend is met het bestellen van een Tesla zal ik eerst kort opsommen hoe dat proces ongeveer gaat (in het geval van een leasemaatschappij):

  1. Je regelt intern de order en deze gaat naar de leasemaatschappij
  2. De leasemaatschappij bestelt daadwerkelijk de auto bij Tesla en doet de aanbetaling
  3. Je ontvangt een mailtje “Welkom bij de Tesla familie” en mag een account aanmaken
  4. Je krijgt een RN nummer en als je geluk hebt een leverindicatie
  5. Vervolgens is eerst alleen in de broncode het serienummer (VIN) van je auto zichtbaar
  6. Het serienummer is zichtbaar op je profiel pagina
  7. Je krijgt een leverdatum aangeboden
  8. Je mag je auto ophalen
Tesla bestelling overzicht. (goed irritant dat de kleur van het interieur op het plaatje niet klopt :()
Beetje jammer dat de interieurkleur niet overeen komt met de kleur in de bestelling ­čÖü

Stap 1 tot 4 gaan redelijk vanzelf, en dan begint het kijken naar sheets zoals deze om te zien wanneer er weer een schip/shit-load aan Tesla Model 3’s deze kant op komen, in de hoop dat die van jou daar ook bij staat en je dus een serienummer toegekend krijgt.

Het vervelende is echter dat je dus iedere keer (als je een beetje ongeduldig bent, zoals de gemiddelde Tesla besteller) met de hand in de source moet zoeken of er een VIN beschikbaar is (of je gebruikt een Chrome plugin)

Automatiseren die hap

Alles wat of vervelend is om te doen, of je meer dan eens moet doen moet je proberen te automatiseren, en gelukkig zijn er dan oplossingen als Azure Logic Apps om dat te realiseren.

Tesla heeft een API beschikbaar waar je met je account gebruik van kan maken, er is niet echt officiele documentatie van, maar zoals vaker heeft dat het internet er niet van weerhouden er toch gebruik van te maken.

De stappen die we gaan doorlopen:

  1. Een autorisatie token genereren met je Tesla account
  2. Een Azure Logic App bouwen die ieder uur:
    1. Een webrequest doet bij Tesla
    2. Het webrequest interpreteert en een als dan functie uitvoert
    3. Je een mailtje stuurt bij goed nieuws

Ik heb eigenlijk alleen Postman gebruikt voor het maken van de initiele requests, maar met de code voorbeelden hier onder kan je als het goed is zelf wel uit de voeten zonder het gebruik van Postman.

Door wat tijdgebrek ben ik er niet aan toe gekomen om een generator te maken voor je autorisatie token, dus dat moet voor nu nog met de hand middels postman. Je kan eventueel ook een externe website gebruiken voor het genereren van je token, zoals bijvoorbeeld deze.

Autorisatie token genereren

Je kan je (Oauth) autorisatie token ophalen door de onderstaande stappen te volgen. Samengevat gaan we een API call doen om met je inloggegevens een token te genereren.

Als je Postman geopend hebt kies je voor “New request”:

Postman "Create New" menu
Postman – New Request

Je moet het request een naam geven en toevoegen aan een “Collection”, je kan hier een bestaande kiezen of een nieuwe aanmaken.

Postman save request menu
Postman – New request details

Als je een nieuw request aangemaakt hebt krijg je onderstaand scherm te zien (alleen dan nog leeg):

Postman request editor
Postman request
  1. Pas het type request aan naar een “POST”
  2. Voer de volgende URL in: https://owner-api.teslamotors.com/oauth/token
  3. Maak de volgende parameters aan en vul de value’s
    1. grant_type – password
    2. client_id – De waarde voor dit veld vind je hier: https://pastebin.com/pS7Z6yyP en de toelichting hier: https://tesla-api.timdorr.com/api-basics/authentication
    3. client_secret – De waarde voor dit veld vind je hier: https://pastebin.com/pS7Z6yyP en de toelichting hier: https://tesla-api.timdorr.com/api-basics/authentication
    4. email – het email adres van je Tesla account
    5. password – het wachtwoord van je Tesla account
  4. Druk vervolgens op Send

Je krijgt nu een response te zien die er grofweg zo uit ziet:

{
    "access_token": "****",
    "token_type": "bearer",
    "expires_in": 3888000,
    "refresh_token": "****",
    "created_at": 1568872567
}

Het access_token heb je in de volgende stappen nodig.

LET OP: Het token dat je hier aanmaakt (en je login gegevens sowieso) geven controle over veel meer dan alleen de data die we nu ophalen, ook zodra je je auto eenmaal hebt kan dit token gebruikt worden voor bijvoorbeeld het openen van de deuren.. Zorg er dus voor dat je zorgvuldig om gaat met het token. Tokens zijn momenteel 30 dagen houdbaar en moeten dan vervangen worden (zie daarvoor de documentatie)

Azure Logic App aanmaken

Logic apps kosten (zoals veel services op Azure als je ze goed gebruikt) zo ongeveer niks, en zeker niet als je het voor dit doel gebruikt. Als het wachten een beetje mee zit zou je zelfs in je trial account genoeg dagen gratis gebruik moeten hebben zitten om daarmee de wachttijd uit te zitten.

Als je nog geen account hebt kan je deze aanmaken via portal.azure.com, als je wel al een account hebt kan je daar inloggen en in de zoekbalk zoeken naar “Logic Apps”

Azure overzicht
Azure Logic Apps

Op de volgende pagina kan je vervolgens middels “Add” een nieuwe logic app aanmaken:

Azure logic apps
Logic app overzicht

Het aanmaken van de lege Logic App is in tegenstelling tot sommige andere Microsoft Azure onderdelen relatief eenvoudig:

Logic App aanmaken interface
Logic App Aanmaken

Je voert een naam in, kiest een subscription en een bestaande of nieuwe resource group (een bundel gerelateerde services en onderdelen) en kiest tot slot een locatie, waarbij het zinnig is een locatie zo dicht mogelijk bij je eigen locatie te kiezen.

Het aanmaken zelf duurt vervolgens even (1-2 minuten, verwaarloosbaar in Tesla-tijd), maar na een tijdje zie je je gloednieuwe Logic App in de lijst staan:

Azure Logic App overzicht
Logic App overzicht na aanmaken App

Je kan hier vervolgens op klikken en zal dan naar de design view gestuurd worden waar we de logic app kunnen gaan inrichten.

Azure Logic App configureren

In het eerste overzicht dat je krijgt zie je allerlei templates staan. Deze zijn leuk om eens mee te experimenteren, maar voor deze app kiezen we voor een “Blank Logic App”

Lege logic app template
Een leeg template

De eerste stap die je vervolgens zet is het bepalen van een trigger. De trigger bepaalt wanneer het proces in de Logic App moet starten. Je hebt hier een grote hoeveelheid opties die interessant zijn om te bekijken. In dit geval kiezen we voor de “Schedule” optie, en vervolgens voor recurring (oftewel, starten op basis van een timer):

Logic app recurrence
Logic App trigger

De vervolgstap is het invoegen van de daadwerkelijke actie waar het proces mee moet beginnen. In ons geval gaan we een “GET” actie uitvoeren tegen de Tesla API. We geven hierbij een autorisatie header mee met het Autorisatie token dat we eerder in deze post aangemaakt hebben met ons account.

Voor het toevoegen van deze stap zoeken we naar HTTP, en kiezen voor de HTTP actie, je krijgt dan een veld zoals hier onder:

Logic app http request
HTTP Request opbouwen

De waardes die je hier invult:

  • Method: GET
  • URI: https://owner-api.teslamotors.com/api/1/vehicles
  • Headers: Authorization | Bearer “token zoals eerder gegenereerd”

Wat deze stap doet is het webrequest opbouwen dat volgens het schema dat we eerder samengesteld hebben aangeroepen wordt.

De volgens stap is het oppakken van het resultaat van het webrequest dat we hiervoor aangemaakt hebben. We gaan het resultaat omzetten naar een JSON object, dat is niet per definitie nodig voor de werking zoals de app nu is, maar bied wel meer mogelijkheden voor de toekomst en is een kleine moeite.

Voeg een action toe en zoek naar “Parse JSON”. Je krijgt een blok te zien zoals hier onder:

Logic app JSON parser
Parse JSON configuratie

Klik hier eerst in het “Content” vak (1) en vervolgens in het Dynamic Content veld onder HTTP (eventueel even op klikken als je geen opties ziet) op “Body” (2). Tot slot klik je dan op ” Use Sample Payload to generate schema ” (3) en voer deze code in:

{
    "response": [],
    "count": 0
}

Er zal een schema gegenereerd worden waar we later naar refereren.

De volgende stap is een stukje “Als, dan” logicia om te zorgen dat je alleen een bericht ontvangt als er een VIN gekoppeld is aan je account. Je zoekt hiervoor naar de actie “Control” en kiest vervolgens voor “Condition”:

Logic app controller / condition
Condition Operators

De eerste stap die we hier zetten is de werkelijke vergelijking bepalen. In her eerste veld klikken we en kiezen we in de “Dynamic” content voor de waarde “Count”. Deze stap is iets makkelijker geworden door het schema dat we hier voor toegevoegd hebben, anders had je dat veld hier handmatig moeten specificeren.

Als de “Count” waarde niet gelijk is aan 0 is er dus blijkbaar een auto toegevoegd aan je account, dus dan gaan we in de volgende stap een “If true” actie instellen. Klik hiervoor op “Add an action” in het “If true” blok. Vervolgens zoek je naar “Send email”, in mijn geval kies ik hier voor Office 365 en vervolgens opnieuw voor “Send Email”, je mag vervolgens inloggen:

Logic app mailer connector
O365 Sign In

Na het inloggen kan je de mail opmaken, je kan hierbij elementen gebruiken uit alle eerdere stappen, deze zijn beschikbaar als dynamic content. Ik heb het niet al te moeilijk gemaakt en gewoon de hele HTTP response gepakt, als de auto eenmaal gekoppeld is maakt het me niet zo veel meer uit dat het mailtje niet zo mooi is ;). Als het menu bij Dynamic Content leeg blijft moet je even op “See more” klikken.

Logic app mail
Logic App mail

Uiteindelijk heb je dan iets zoals hier onder:

Logic app totaaloverzicht
Logic App overzicht

Als je hier eerst nog op “Save” (1) en vervolgens op “Run” (2) klikt zal de app eerst een keer zichtbaar draaien en vervolgens ieder uur op de achtergrond (volgens het eerder ingestelde schema). Je kan op deze pagina meteen zien wat er in iedere stap gebeurt is en wat het resultaat is geweest. Als het “goed” is zal je geen mail krijgen omdat er nog geen gekoppelde auto is. Als je zeker wil weten dat alles naar behoren werkt zou je ook een bericht kunnen koppelen aan de “If false” branch, maar dat is normaal gezien eigenlijk niet nodig.

Wachten

Als de logic app eenmaal draait merk je daar doorgaans niets van (tot je goed nieuws krijgt). Als je dan toch de status wil zien kan je de logic app op de Azure Portal opzoeken en open klikken. Je ziet dan altijd een overzicht van de keren dat de app gelopen heeft en de resultaten van iedere run:

Logic app history
Azure logic app history

Verder rest er nu dan niets meer dan wachten tot de mail komt.

Tot slot

Echt heel erg zinnig is deze logic app natuurlijk niet, maar het is wel een (erg simpele) introductie tot een zeer krachtig Microsoft Azure onderdeel wat eindeloos veel toepassingen kent en eigenlijk voor iedereen relatief goedkoop beschikbaar is.

Azure Function App Proxy

In de voorgaande posts hebben we het gehad over een directe koppeling tussen AFAS Profit en Power BI en het gebruik van een Azure Function App om scripts te kunnen draaien. Deze twee onderdelen hebben echter nog een extra toepassing.

Wanneer je een Power BI rapportage die gebruik maakt van directe AFAS Profit data wil publiceren ga je bij de refresh problemen krijgen met het autoriseren van de (web) databronnen. Het probleem is dat het deel van de URL met de autorisatie token afgekapt wordt (samen met eventuele filters). Waarom dit precies gebeurt is mij niet helemaal duidelijk. Een mogelijke oplossing is het gebruik van een Azure Function App Proxy. Als je toch al een Azure Function App hebt voor het draaien van je scripts kost deze proxy je normaal gezien niets extra.

Wat gaan we doen?

Een Azure Function App Proxy kent vele mogelijke toepassingen. In dit voorbeeld gaan we de Proxy tussen de AFAS Profit Webconnector (REST) en Power BI plaatsen. Power BI gaat een request naar de proxy sturen met een aantal parameters, de proxy reformat het verzoek en doet het verzoek bij de Profit omgeving. Het resultaat wordt vervolgens 1-op-1 doorgestuurd naar Power BI. (We zouden hier eventueel nog acties aan de response kunnen hangen, maar dat is nu niet nodig).

De stap voor het maken van de function app zelf slaan we deze keer even over, als je wil weten hoe dat werkt kan je dit item lezen. Ik ga dan ook uit van dezelfde demo als in die post, het startpunt is dan ongeveer het volgende:

Azure Function App

Toelichting endpoint (AFAS Profit REST API)

Wanneer je gebruik wil maken van de AFAS Profit REST API moet er gewerkt worden met een bepaalde opbouw van de URL gecombineerd met een een autorisatie header. Wanneer je deze direct vanuit Power BI ingeeft als bron kan je deze handmatig autoriseren, echter, wanneer je de rapportage publiceert werkt deze authenticatie niet meer. Dat betekend dat we een tussenstap moeten maken.

Het doel is uiteindelijk dat we een request zoals deze naar naar de REST API van Profit kunnen sturen:

https://url_van_omgeving/profitrestservices/connectors/{connector}

Vervolgens moeten daar de connector specifieke velden, filters en autorisatie aan meegegeven worden. Alle velen die we nodig hebben zijn al bekend gezien we deze in de directe koppeling uit de eerdere posts ook al gebruikt hebben.

Inrichting Azure Function App Proxy

Wanneer je in het Function App menu zit zie je bij Proxies ongeveer het volgende:

Azure Function Apps menu

Je kan daar op de + klikken om een nieuwe proxy aan te maken, daarvoor moet het een en ander ingevoerd worden, dat ziet er dan uiteindelijk ongeveer als volgt uit:

Azure Function Apps - Proxies

We lopen even door de velden heen:

Route template

Hier geef je de structuur van de proxy url op, in dit geval beginnen we met de “/naca” dit doet van zichzelf niets. Het geeft een stukje structuur waarmee de url’s en verwijzingen van elkaar onderscheiden kunnen worden. Dit wordt gevolgd door een aantal velden tussen {} geplaatst zijn. Dit zijn de variabelen die we willen kunnen gebruiken in de “request override” of de “header”. In dit geval zijn dat:

Token = Autorisatie token (zie eerdere posts)
Periode = De periode waarvan we de data op willen halen, dit gaan we in een filter gebruiken
Connector = De naam van de connector die we op willen roepen.

Het resultaat van deze route template komt terug in de URL die je gebruikt in Power BI.

Backend url

Dit is het adres waarop de AFAS Profit REST API benaderd kan worden. Je ziet hier aan het einde {connector} staan, dat wil dus zeggen dat hij de variabele uit de request URL overneemt naar de backend url.

Request override

Vervolgens zal je de “Request override” open moeten klikken en invullen, voor de duidelijkheid staat hieronder nog specifiek een screenshot van dat onderdeel:

Azure Function Apps - Request override

Dit is het deel waar we het request dat naar de Azure Funtion App Proxy gestuurd is om gaan zetten naar het request waar onze AFAS Profit omgeving wat mee kan.

De skip en take velden zijn gelijk aan wat we kennen uit de directe koppeling. We kunnen hier direct ook een specifieke periode ophalen. We gebruiken hiervoor de standaard filter opties van de AFAS Profit REST API. Het “filterfieldsids” geeft de velden aan waar je op wil filteren. Het “filtervalues” veld is de waarde waarop je op wil filteren, je ziet hier {periode}  staan, wat weer betekend dat we de variabele die we in de route template gespecificeerd hebben overnemen in het filter voor AFAS. Tot slot staat er nog “operatortypes” en dat is weer een onderdeel van de filteropties vanuit Profit.

Je kan in deze velden eigenlijk alles kwijt wat je normaal ook zou gebruiken bij het ophalen van een getconnector in AFAS Profit.

Headers

Tot slot moeten we nog de autorisatie headers mee geven. Dit is namelijk de hele reden dat we de directe koppeling niet in de gepubliceerde rapportages kunnen gebruiken. Het token wat we nodig hebben zit al in het route template. Zoals eerder zie je ook hier weer dat we de variabele kunnen gebruiken, in dit geval het veld {token}:

Het “ContentType” veld en de inhoud (“application/json;charset=utf-8”) zijn voor Profit connectoren altijd gelijk.

Als we dit alles ingevuld hebben kan de proxy opgeslagen worden. Je krijgt dan een URL terug die je in het vervolg kan gebruiken voor het ophalen van de data uit AFAS Profit. De URL ziet er grofweg als volgt uit:

https://****.azurewebsites.net/naca/{token}/{periode}/{connector}

Verwerking in Power BI

Je kan de URL hier boven nu gebruiken in de rapporten die je wil publiceren. Hiervoor maak je in Power BI een “web” bron aan:

Je bouwt deze vervolgens op aan de hand van de structuur voor de proxy url zoals we deze in de vorige stap gemaakt hebben:

Power BI databron gevuld

Wanneer je deze bron nu opslaat kan je de data gebruiken op dezelfde manier als de directe koppeling die we in een van de eerdere posts gemaakt hebben. In het voorbeeld hierboven heb ik gebruik gemaakt van parameters in Power BI om de variabelen op te slaan en mee te nemen. Je kan hier ook direct de waardes voor de variabelen vullen.

Veiligheid

Op zich is het gebruik van de proxy net minder veilig dan de directe koppeling naar Profit. Echter, het is wel altijd een goed idee om een stap extra te zetten om de hoeveelheid mensen die potentieel de data kunnen benaderen te verkleinen. Je kan daarvoor op IP niveau filtering aanbrengen voor je Azure Function App. In ons geval weten we zeker dat alleen vanaf 2 kantoren en onze datacenters gewerkt mag worden met deze data (alles voor Power BI loopt via onze “On-premises Data Gateways”).

Open hiervoor het overzicht van je function app, kies hier voor “Platform features”:

Azure Function Apps  - Overview

Vervolgens voor “networking”:

Azure Function Apps - Networking

Onderaan zie je de optie “ip restrictions”:

Azure Function Apps - beveiliging - IP

Je ziet dan een pagina zoals hier onder:

Azure Function Apps - beveiliging - IP Filter

Hier kan je regels toevoegen om de adressen vanaf waar de apps benaderd mogen worden te beperken.

Tot slot

Het heeft even geduurd voordat ik dit artikel daadwerkelijk helemaal af heb kunnen maken. De techniek hier achter is niet heel complex maar er zijn talloze mogelijkheden en oplossingen denkbaar in Azure. Ik wilde graag iets meer ervaring opdoen voordat ik dit stuk helemaal af zou ronden. Dit zodat iemand die hier mee aan de slag gaat geen onnodige stappen hoeft te zetten of onnodige risico’s loopt.

Mochten er naar aanleiding van dit stuk nog vragen zijn hoor ik het graag!

Azure function apps in combinatie met AFAS Profit

Als je wil proberen om zo min mogelijk eigen infrastructuur te gebruiken zonder dat dat meteen veel geld moet kosten zijn er talloze opties te bedenken. Een van die opties is Microsoft Azure. De eerste stap die je zal moeten zetten is gaan denken in de daadwerkelijke handelingen die er uitgevoerd moeten worden. Deze handelingen wil je vervolgens in logische blokken opdelen, met als voorwaarde dat deze blokken moeten onafhankelijk van elkaar kunnen functioneren. Vervolgens kan je per blok gaan kijken wat de beste manier is om de gewenste functionaliteit te realiseren.

Het “Probleem”

In dit voorbeeld gaan we voor nieuwe medewerkers in AFAS Profit een aantal velden vullen. Omwille van de eenvoud van het voorbeeld heb ik het gebruikte script even eenvoudig gehouden. Gezien het in Profit niet mogelijk is om logica toe te passen bij het automatisch vullen van velden hebben we een externe oplossing nodig om dit te doen. Het heeft mijn voorkeur om dit soort zaken met Powershell en de connectoren in Profit op te lossen. Voorheen gebruikte ik hiervoor altijd een van onze applicatieservers voor (om het script te draaien). We kunnen dit echter ook prima in Azure oplossen

De oplossing (Microsoft Azure)

Als je in Microsoft┬áAzure scripts wil laten draaien die gebruik kunnen maken van web connectiviteit zijn de “Function Apps” een goede optie. Binnen dit systeem heb je bijvoorbeeld ook Web Proxies beschikbaar en die gaan we in een latere post gebruiken :). We gaan dus een Function App aanmaken waarbinnen we ├ę├ęn of meerdere scripts op een tijdschema laten draaien. In dit voorbeeld gaan we een lijst ophalen van medewerkers die nog geen licenties toegekend gekregen hebben. Deze lijst met medewerkers krijgt vervolgens de juiste licenties toegekend op hun medewerkerkaart. Voor deze stappen heb je een actieve Azure Subscription nodig (je moet dus of in de trial zitten of een betaalmethode gekoppeld hebben). De kosten van het draaien van dit script (15 uur per dag) zijn 6 eurocent per maand (afhankelijk van de gebruikte opslag / data). Ik zou Azure altijd instellen op de Engelse taal gezien de vertalingen naar het Nederlands erg verwarrend kunnen zijn. Daarnaast zijn niet alle vertalingen correct.

Stappenplan (functie)

We starten op de Azure portal en kiezen daar voor het aanmaken van een nieuwe resource:
Azure portal "Create Resource"
In het volgende venster zoek je naar “Function app”:
Azure function app aanmaken
Je krijgt een nieuw menu te zien waar je een aantal instellingen in kan geven. De “App name” is voor dit stappenplan niet zo van belang. Mocht je later de Proxy functionaliteit wil gaan gebruiken wordt dit de URL waarop je de proxy kan benaderen. In ons geval moeten we een nieuwe resoursegroup aanmaken waar alle elementen voor deze functionaliteit gebundeld worden. als locatie kiezen we voor West Europe gezien die geografisch het dichtste bij onze AFAS Profit omgeving zal staan. De naam van de storagegroup is niet heel belangrijk in dit geval, als je het maar eenvoudig terug kan vinden. Uiteindelijk heb je dan grofweg het onderstaande. Als je nu op “Create” klikt wordt de Function App aangemaakt, dit kan ongeveer een minuut duren.
Na een minuutje wachten kan je de Function App openen en krijg je een overzicht zoals dit te zien:
Function app overzicht.
We kunnen nu daadwerkelijk de functie aan gaan maken die het script gaat draaien. We klikken hiervoor bij “Funtions” op het plusje om de wizzard te openen. Er zijn een groot aantal standaard functies beschikbaar, maar in ons geval willen we een custom function bouwen:
In het volgende venster zal je de beta talen aan moeten zetten. Powershell is nu nog in beta (al tijden), maar werkt prima. Om deze mogelijkheid te krijgen moet je deze switch even omzetten:
Vervolgens kan je de “Time Trigger” optie kiezen:
Azure function Time Trigger
In het volgende venster zal je de taal moeten kiezen (in ons geval PowerShell) en het schema moeten defini├źren. Dit schema maakt gebruik van dezelfde notatie als CRON en is niet heel erg gemakkelijk leesbaar als je er niet veel mee werkt. Je kan hiervoor eventueel een generator gebruiken. In het voorbeeld hier onder draaien we het script ieder uur vanaf 7.00 in de ochtend tot 20.00 in de avond. (let wel op dat je je tijdzone goed ingesteld hebt).
Na het aanmaken van de functie krijg je een leeg venster te zien waar het script geplaatst kan worden. Je kan dit allemaal integreren met bijvoorbeeld Github (of andere repositories), maar dat gaat voor dit voorbeeld even te ver.

Het script

De laatste stap is het toevoegen van het script zelf. Ik ga niet al te veel in op de werking van het script, maar kort samengevat gebeurt er het volgende:
  • Roep een getconnector aan die een gefilterde lijst met gebruikers zonder licenties ophaalt.
  • Loop door deze lijst en voer de gewenste licentiecodes in bij de diverse users.
Om het voorbeeld een beetje overzichtelijk te houden staat hier onder een versimpelde versie van ons script. We gebruiken zelf een complexer script met een aantal randvoorwaarden om te bepalen welke licentie nodig is voor welke gebruiker.
begin {

    # define the access token for the AFAS service
    $token = '<token><version>1</version><data>***</data></token>'
    $encodedToken = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($token))
    $authValue = "AfasToken $encodedToken"
    $Headers = @{
        Authorization = $authValue
    }

    # Connect and retrieve the table
    $url = 'https://**/profitrestservices/connectors/***?skip=-1&take=-1'
    $records = ((Invoke-WebRequest -Uri $url -UseBasicParsing -Headers $Headers).content  | ConvertFrom-Json).Rows
}

process {
    # Specify update authorization
    $token = '<token><version>1</version><data>***</data></token>'
    $encodedToken = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($token))
    $authValue = "AfasToken $encodedToken"
    $Headers = @{
        Authorization = $authValue
    }
    $connectorname = "KnEmployee"
    
    # Process records 
    foreach ($record in $records) {
        $url = "https://***/profitrestservices/connectors/KnEmployee"

        Write-Host $record.profituser
        $medewerker = $record.profituser

        $messagecontent = '{"AfasEmployee": {"Element": {"@EmId": "' + $medewerker + '", "Fields": { "***": "02", "***": "01"}}}}'

        $results = ((Invoke-WebRequest -Uri $url -UseBasicParsing -ContentType 'application/json;charset=utf-8' -Method PUT -Headers $Headers -Body $messagecontent).content | ConvertFrom-Json)
        Write-Host $results
    }
}
Na het invoeren van het script kan je op “save en run” klikken en daarna zal het script volgens het voorgestelde schema draaien. Je kan eventuele fouten opsporen door de logging na te kijken, deze is voor de losse run direct onder in het scherm beschikbaar:
En later via het monitor menu:

Tot slot

Dit is natuurlijk maar een eenvoudig voorbeeld, maar je kan je voorstellen dat je op deze manier veel zaken kan automatiseren zonder dat je hier eigen infrastructuur voor nodig hebt. Het script wat ik gebruikt heb in dit voorbeeld is gemaakt samen met Jaap de Koning, lees ook eens zijn blog als je geïnteresseerd bent in automatisering. Laat even een berichtje achter als je meer wil weten over deze manier van automatiseren rondom AFAS Profit of het gebruik van Azure functions. De komende tijd zal ik meer in gaan op deze aanpak. Daarbij kijken we naar de veranderingen die nodig zijn in de manier van denken om goed gebruik te maken van cloud en hybride oplossingen.

Detron Open Script Night – Ronde 1

Als een van de Business Developers bij Detron IT Consultants mag ik samen met het als team altijd zoeken naar methoden om onze collega’s kennis te laten maken met nieuwe systemen en technieken. Maar soms moet je ook de aanpak van deze kennisdeling eens op de schop gooien om zo een andere groep mensen te bereiken of een hoger niveau te behalen. Zeker op het gebied van het schrijven van een script ten behoeve van automatisering zien we het niveau flink stijgen en moeten we de aanpak dus veranderen.

Zo gaan we na 2 jaar aan PowerShell bootcamps eens proberen om op een hele andere wijzen kennis te delen over niet alleen PowerShell, maar ook andere scripttalen waar we in onze dagelijkse werkzaamheden mee in aanraking komen. Het resultaat van wat berichten heen en weer tussen collega’s was dat we vanuit het Detron ICT Kenniscaf├ę (communicatie middel en organisatie van een deel van onze kennissessies en trainingen en mijn hobby op het werk ­čśë ) ook wel een Open Script Night konden houden. Hier kunnen collega’s of externe sprekers in 10-20 minuten een demo en toelichting geven van iets wat ze zelf gemaakt hebben en misschien handig is voor collega’s.

Als we deze korte sessies combineren met een introductie van een nieuwe of bestaande techniek die voor iedereen interessant kan zijn hopen we een leuke actieve avond te hebben. Het is niet de bedoeling dat bezoekers alleen maar gaan zitten luisteren, maar ook direct met de laptop aan de slag kunnen om ervaring op te doen met wat ze horen en zien.

Ondanks dat ik met al 6 jaar bezig houd met het organiseren van trainingen en sessies heb ik anders dan het welkomstwoord nog nooit zelf inhoudelijk gesproken op een sessie, gezien een van mijn hobby’s nogal wat met scripting te maken heeft (clickfarm.nluitleg) was dit een mooie gelegenheid om hier ook een keer verandering in te brengen. Tijdens de eerste Detron Open Script Night zal ik 30 minuten spreken over twee tools die mij enorm helpen en een stukje techniek waar ik dagelijks mee in aanraking kom. Een van de andere onderwerpen┬á waar we deze eerste avond naar gaan kijken is git, wat mij betreft ook een onmisbaar stuk gereedschap voor het onderhouden van je scripts.

Onderwerp 1: Visual Studio Code (script editor)

Visual Studio Code een erg mooi stukje gratis software van Microsoft voor het schrijven van je code. Voor de meeste talen is er een intellisense module beschikbaar. Daarnaast zorg de Emmet.io integratie voor een aanzienlijke versnelling van het schreven van de code. Ook een directe integratie met git draagt bij aan een goede workflow. Visual Studio Code - Script editor

Onderwerp 2: Postman

Eigenlijk al een stukje voorbereiding op het derde onderwerp, maar Postman is een tool voor het testen van allerlei web connectoren (om het maar eens heel simpel uit te leggen). De eerste keer dat ik er mee in aanraking kwam was voor het testen van de backend voor Clickfarm, maar inmiddels gebruik ik de tool ook zakelijk.

Postman API Test suite

Onderwerp 3: Web-connectoren (API’s)

Wanneer je meerdere (SaaS) systemen aan elkaar wil koppelen ontkom je niet meer aan allerlei verschillende API’s. Nou zijn er aardig wat standaarden, maar in hoofdlijnen werken ze technisch veelal hetzelfde. Reden genoeg om eens beter te kijken wat nu de kracht kan zijn van een goede API, maar ook wat de uitdaging kan zijn als je meerdere passieve systemen wil koppelen.

api grafische weergave

 

Microsoft Edge vergeet zijn settings

Ik ben denk ik een van de 6 Edge gebruikers in de wereld, maar om de andere vijf dan toch te helpen even een korte post over een vreemd probleem dat ik nu al drie keer gehad heb. Overigens vind ik normaal gezien Edge inmiddels een serieus goed werkende browser. Ik kan iedereen die dat tot op heden nog niet gedaan heeft het warm aanbevelen Edge eens een kans te geven.

Eens in de zoveel tijd wil Edge na een schone installatie van Windows 10 niet naar behoren werken. De settings worden niet onthouden, cookies worden niet goed opgeslagen en je history wordt niet opgeslagen. Dit alles zonder dat je de instellingen van de browser zelf hebt aangepast.

De vorige keren was het steeds even zoeken naar de oplossing en om te voorkomen dat ik de volgende keer weer moet zoeken bij deze de oplossing.

Stappenplan:

Open Command als administrator

CMD Startmenu Windows 10

Klik hier rechts en kies voor openen als administrator

Voer het volgende commando in:

sfc /scannow

SFC Command promt

Reboot je systeem zodra de command promt daar om vraagt. Als het goed is zou het probleem nu verholpen moeten zijn.

Wat doet SFC dan nou precies? Edge is een core onderdeel van Windows en kan dus maar tot op zekere hoogte via de herstel optie via “Apps” (in het settings menu) hersteld worden. Om iets grover te werk te gaan voert SFC (System File Checker) een scan uit van de systeembestanden van Windows en voert waar nodig herstel uit. In het geval van de problemen die ik met Edge ervaar gaat er dus iets mis met de core bestanden van Edge. Geen idee wat de oorzaak is, maar deze oplossing heeft voor mij tot op heden altijd gewerkt.

Mocht iemand een idee hebben waar deze corruptie vandaan kan komen hoor ik het graag, voorkomen is nog altijd beter dan genezen :).