Realiseren van Integratie oplossingen met Azure Logic Apps

Met de opkomst van de Cloud kwam ook de toename in Software-as-a-Service (SaaS) oplossingen zoals Salesforce, Dynamics 365, DropBox, ZenDesk, ServiceNow en Workday. Deze oplossingen stellen organisaties in staat hun bedrijfsprocessen rondom financiën, human-resources, logistiek, en vele andere te borgen. Kortom, het verschuiven van dergelijke processen ondersteund in on-premise systemen naar oplossingen in de Cloud. Het verschuiven wordt ook wel ‘ver-Saas-en’ genoemd. Echter, kan het ook zijn dat sommige systemen in nieuwbouw oplossingen met platform diensten kan worden gerealiseerd of middels ‘Lift-and-Shift’ naar de Cloud worden gebracht.

Door: Steef-Jan Wiggers

Los van waar bedrijfsprocessen zich afspelen wisselen systemen informatie met elkaar uit. Waarbij in het verleden en zelf vandaag de dag een server product als BizTalk kan worden gebruikt of sinds een aantal jaar Logic Apps in Azure. Met Logic Apps en BizTalk Server kunnen organisaties indien zij een ‘best-of-breed’ landschap hebben voor hun bedrijfsprocessen deze goed met elkaar laten aansluiten. Dit was en is de kracht van BizTalk Server en eveneens Logic Apps – echter zijn de technologieën niet hetzelfde.

De oorsprong van Logic Apps

Bijna vijf jaar geleden werd Logic App publiekelijk beschikbaar gesteld op het Azure platform en sindsdien is het in twee jaar tijd uitgegroeid tot een leider in de integratie Platform as a Service (iPaaS) Magic Quadrant van Gartner. En vandaag de dag nog steeds.

De publieke Cloud providers eerste poging om een dergelijke dienst in de Cloud te krijgen had de toepasselijk naam BizTalk Services. Deze naam werd na enkele updates van de dienst veranderd in Microsoft Azure BizTalk Services, afgekort MABS wat je ook als een tweede versie van BizTalk Services kunt beschouwen. Echter, bleek deze tweede versie niet afdoende en besloot het bedrijf om de EDI/B2B functionaliteit te verhuizen naar de derde iteratie genaamd Logic Apps. En nu in 2021 is de vierde versie in publieke preview beschikbaar.

Workflow definitie

Wat zijn Logic Apps nou eigenlijk en hoe verhoudt het zich tot zijn evenknie BizTalk Server. Welnu ontwikkelaars kunnen een Logic App bouwen, d.w.z. een workflow ontwerpen met behulp van de ‘designer’ in de browser of Visual Studio – gebruikmakend van de Azure Logic Apps Visual Studio Tools. Bovendien kun je een Logic app zelf zien als een logische container of host van een werkstroom definitie (workflow) – wanneer deze wordt uitgevoerd, worden resources (lees CPU cycles en dergelijke) op het Azure-platform verbruikt. De Logic App zelf is een Platform as a Service (PaaS) dienst in Azure.

Met de designer kun je een bedrijfsproces workflow of een integratie workflow definiëren door een van de vele vooraf gedefinieerde- of lege sjablonen (templates) te kiezen. De voor gedefinieerde sjablonen bieden zoiets als bijvoorbeeld een ‘Peek-Lock’ van een Service Bus-bericht. Naast de vooraf gemaakte templates, kun je ook met een lege beginnen en starten met het slepen van een trigger en acties naar het canvas van de designer – elke trigger, actie, conditie die je in de Visual Designer plaatst, wordt vastgelegd als JSON. Het laatste beschrijf ik in de Domain Specific Language voor Logic Apps.

Tot slot is de Visual Designer is geschreven in TypeScript/ React en wordt gehost in een iFrame in de portal. Bovendien is de designer in de Azure Portal dezelfde designer die beschikbaar is via de eerdere genoemde Azure Logic App Tools for Visual Studio. De ervaring is hetzelfde, ware het niet dat je de Logic App in Visual Studio niet kunnen laten draaien. Daar later mee over in dit artikel.

De Domain Specific Language (DSL) voor Logic Apps

Zoal eerder aangegeven kun je Logic Apps zien als een ‘Workflow as a Service’ in Azure, maar het gedraagt ​​zich echter niet als een normale workflow of workflows – die je mogelijk zult kennen van Windows Workflow Foundation (WF). Een dergelijke workflow werkt zoals: doe eerst stap A, dan stap B, dan stap C, en je kunt verder allerlei voorwaarden en loopings hebben – het is een zogenaamde ‘foward-chaining’ proces. Echte, een Logic App gedraagt zich echter heel anders.

De runtime onder de Logic Apps is eigenlijk een planner (scheduler), die allerlei taken uitvoert op basis van een JSON gebaseerde DSL. En die de taken beschrijft welke uitgevoerd dienen te worden. Wanneer je naar de codeweergave kijkt, ziet je dat er een RunAfter-stap is. En er staat RunAfter step A: Stap B wordt uitgevoerd na stap A – dus wanneer je een workflow maakt, heb je een reeks van taken (acties).

Wat de JSON DSL je biedt is een set van taken die je parallel kan laten lopen – elke actie wordt in wezen een taak die op de achtergrond wordt uitgevoerd. Een zogenaamde ‘Resource provider’ interpreteert de DSL en laat vervolgens een orchestrator de taken uitvoeren.

Connectors

Eerder hebben we de workflow definitie en de DSL van Logic Apps behandeld en nu gaan we de connectiviteit – verbindingen naar andere systemen en diensten behandelen. De kracht van de Logic Apps zijn de beschikbare connectors voor diverse Azure diensten, en SaaS-diensten. Deze stellen je in staat om verbindingen (connections) aan te gaan. De connectors zijn in feite ‘wrappers’ om OpenAPI specificaties heen – oftewel de beschrijving van een API, waar Microsoft een implementatie op baseert. Het bedrijf heeft inmiddels meer dan drie honderd van dergelijke connectors gemaakt – welke je in de Logic App gebruik van kan maken. En mocht er geen connector zijn, dan bestaat er nog de mogelijkheid om zelf een connector te maken. Tot slot, kan je ook een proxy van een API aangemaakt in Azure API Management consumeren in de Logic App.

Bouwen van een Logic App

Een Logic App kun je eenvoudig in de Azure Portal aanmaken om vervolgens met de designer aan de slag te gaan om een workflow te maken. Je sleept een actie op het canvas voor de start van de flow, om vervolgens een of meerdere acties er op te laten volgen. Wat betreft acties zijn er diverse smaken, zoals:

• Acties om een andere systeem of service aan te roepen (connector);
• Acties om controle op de flow te kunnen verkrijgen – denk aan condities (‘if else’), loopings (‘do while’ en ‘for-each’) en stoppen van de flow (‘terminate’);
• Acties om transformaties uit te voeren.

Verder kun je ook bepaalde configuraties uitvoeren op de acties, zoals:

• Configureren van acties voor opnieuw proberen van een aanroep naar een ander systeem of service (zogenaamde ‘retry’)
• Configureren van al dan niet uitvoeren van een actie door middel van de ‘RunAter’ setting – dus voor een actie uit als de vorige gefaald heeft;
• Configureren van acties door eigenschappen (‘Tracked properties’) aan te brengen voor monitoring doeleinden.
• Configureren van ‘Time-outs’, en in- en outputs van de actie te beveiligen.

Kortom, bij het opbouwen van de flow heb je als ontwikkelaar een aantal mogelijkheden om het robuust te maken. Eveneens kan je met behulp van zogenaamde ‘function expressions’ data in de berichten, die in de Logic App komen te manipuleren. Je kunt bijvoorbeeld de input (data) van json naar xml formaat transformeren of een rekenkundige toepassing uitvoeren (delen van een waarden door een getal).

Door een workflow op te bouwen met alle mogelijkheden die de Logic App biedt met connectors en de designer kun je dus een integratie bouwen – wat je mogelijk gewend bent met BizTalk Server. Echter, biedt de Logic App geen ‘publish-subscribe’ mechanisme waar je berichten op een bus plaats of in het geval van BizTalk Server in een zogenaamde ‘MessageBox’ waar afnemers zich op kunnen abonneren. De Logic App is vergelijkbaar met de ‘orchestration’ functionaliteit van BizTalk. Andere functionaliteiten van BizTalk zijn terug te vinden in de Azure Service Bus, Event Grid, API Management en de Integration Account. Kortom, deze diensten kun in combinatie met Logic Apps gebruiken om je integratie oplossing in Azure te realiseren wanneer ontkoppelen van systemen en services een eis is. In dit artikel richt ik me meer op een voorbeeld waar dat niet noodzakelijkerwijs hoeft.

Hosting Opties

Voor dat ik een voorbeeld van een Logic App ga beschrijven behandel ik nog een aantal andere zaken zoals hosting opties, uitrollen (‘deployment’), monitoring en beveiliging (‘security’). Wat hosting opties betreft kun je een Logic App aanmaken in de Portal als een ‘Pay-as-you Go’ optie. Hierbij wordt de Logic App op de Azure regie naar keuze aangemaakt, waarbij je samen met vele andere gebruikmaakt van de dezelfde infrastructuur van Azure. Je kan echter ook kiezen om dat niet te doen en een deel te reserveren voor eigen gebruik – dit is de ‘Integration Service Environment’ (ISE) optie. Met een ISE heb je een deel van de Azure infrastructuur voor jezelf alleen en betaal je daar ook voor – de ‘Pay-as-you-Go’ optie vervalt. Tot slot is er een derde optie met Logic App preview waarbij je wederom een ‘Pay-as-you-Go’ optie hebt echter nu draait de Logic App in een ‘App Service’ runtime (dezelfde als Azure Functions). Bij deze optie kun je Logic App ook in een container laten draaien en dus hosten in een Kubernetes cluster met de daarbij komende voordelen.

Deployment 

Wanneer je een Logic App hebt gemaakt en deze naar andere omgevingen wilt uitrollen dan kun je gebruikmaken van zogenaamde ‘Azure Resource Management’ (ARM) templates. Met de eerder beschreven Visual Studio Tools plug-in kun je met de Cloud Explorer in Visual Studio navigeren naar een Logic App, de workflow definitie (json) en bijhorende ARM template downloaden. Deze kun je vervolgens bewerken en van extra parameters voorzien alvorens je het borgt in een Azure repo. Vanuit de repo kun je een pipeline starten, die de ARM template gebruikt om de Logic App naar andere omgevingen uit te rollen. Naast Visual Studio kan je ook Visual Code gebruiken om naar de Logic App te navigeren in Azure om vervolgens de Logic App (JSON) te bewerken, enzovoort.

Het belangrijk je te beseffen dat het uitrollen van Logic Apps je de workflow en ARM gebruikt en niet direct je Logic App publiceert via Visual Studio of de Logic App kopieert en verplaatst naar een andere omgeving.

Monitoring

Een ander aspect wat van belang is voor Logic Apps is monitoring. De service biedt net als andere Azure diensten ‘metrics’, die je inzichtelijk kan krijgen via het tabblad onder monitoring. Je kunt echter ook via ‘Diagnostic Settings’ of bij aanmaken van de Logic App de ‘metrics’ van Logic App runs sturen naar een zogenaamde ‘Log Analytics Workspace’, zodat via de beschikbare functionaliteit dashboards e.d. kunt gebruiken voor monitoring doeleinden. Verder biedt het dashboard voor Logic Apps monitoring ook functionaliteit voor het herstarten van een of meerdere Logic Apps, inzage in eventuele ‘tracked properties’, en meer.

Security

Tot slot voordat ik een voorbeeld van een toepassing met een Logic App ga beschrijven wil ik nog in gaan op beveiliging. Logic Apps kunnen diverse andere Azure diensten benaderen waar je door middel van ‘Role Based Access Control’ (RBAC) functionaliteit zoals een ‘Managed Identity’ het een en andere wat betreft beveiliging kunnen regelen. Verder kun je een Logic App met een HTTP-trigger beveiligen via Azure API Management. Een Logic App met een dergelijke trigger krijgt een publiek benaderbaar adres (‘endpoint’), waarbij je toegang mogelijk wilt reguleren. Door een proxy aan te maken in API-management kan je toegang beperken – ook door het IP-adres van API Management te gebruiken bij toegang tot de Logic App.

Kortom, beveiliging speelt een belangrijke rol bij Logic Apps – niet alleen voor toegang echter ook de data die het binnenkrijgt – dus vergeet dat niet!

Scenario

Logic Apps bieden je met de connectoren heel veel mogelijkheden om een proces (workflow) of integratie te maken. Stel je wil bijvoorbeeld weten of de reistijd van je huis naar kantoor langer dan gebruikelijk gaat duren op bepaalde tijdstippen (07:00 – 09:00 en 15:00 – 18:00). Je kan Logic App bouwen met een ‘Schedule trigger’, die om het kwartier op de tijdstippen een flow start.

De vervolgactie naar de trigger gebruikt een ‘Bing Maps’ connector, die een methode heeft om de reistijd tussen twee gegeven adressen oplevert op basis van de verkeersdrukte op het tijdstip.

De uitkomst van de connector is input voor een vervolgactie, die de reistijd opslaat in een variabele met de volgende ‘function expression’:

div(body('Get_route_and_travel_time_with_traffic')?['travelDuration'],60)

De waarde van de variabele wordt gebruikt in een conditie (‘if else’), waarbij de reistijd hoger dan 35 minuten statement is opgenomen. Als dat het geval is zal een er een actie volgen met een email connector, die een mail stuurt.

Dit voorbeeld geeft weer hoe je een proces (flow) kunt maken, die met een ‘Bing Maps’- en email connector je op de hoogte kan brengen dat je mogelijk langer onderweg bent naar een bestemming waar je elke dag heen gaat. De flow kun je als een integratie met Bing Maps zien.

Afronding

Logic Apps bieden een mogelijkheid voor je om systemen met elkaar te laten communiceren en mogelijke integraties te bouwen. Logic Apps kunnen ook worden gebruikt om zaken te automatiseren in Azure. De service heeft zich sinds zijn beschikbaarheid vijf jaar geleden duidelijk ontwikkeld tot een volwassen dienst, die ook gebruikt kan worden in combinatie met andere diensten zoals Sentinel. Dit artikel heeft je een inkijk gegeven wat er bij bouwen van Logic Apps komt kijken en hoe je een proces kunt automatiseren en integraties kunt maken.

 

BIO: Steef-Jan Wiggers is werkzaam als Technical Integration Architect bij HSO. Hij is zeer actief binnen de Azure en Integratie community, internationaal spreker en auteur van diverse White papers en (e)Books. Verder is hij Cloud journalist bij InfoQ en schrijft hij nieuwsartikelen rondom Azure, AWS en GCP.