Hoofdstuk 1 (link), hoofdstuk 2 (link), hoofdstuk 3 (link), hoofdstuk 4 (link) en hoofdstuk 5 (link), nu tijd voor het 6e hoofdstuk, het verbinden met Azure services en ze gebruiken en services van andere providers.
We gaan de verschillende diensten behandelen;
Ontwerp een App Service Logic App
Door informatie tussen processen te delen verbetert vaak dat proces en kunnen er andere inzichten ontstaan. Met App Service Logic kun je workflows maken die verschillende systemen met elkaar verbinden, gebaseerd op voorwaarden en regels waarmee de uitwisseling makkelijker gemaakt wordt.
App Service Logic bestaat uit een aantal onderdelen wat het makkelijker maakt;
- workflows: hier geef je aan wat de bron en de bestemming van de informatie is. Je gebruikt een grafische interface om het weer te geven, ontwerpen, bouwen, automatiseren en te deployen.
- managed connectors: een connector is een object wat zorgt dat je toegang hebt tot data, services en systemen. Standaard zijn er een aantal Microsoft connectors beschikbaar die zelf de triggers en acties objecten bevatten die je nodig hebt om ermee te werken.
- triggers: op basis van bepaalde condities wordt een trigger geactiveerd, deze reageert dus op een event/gebeurtenis. Deze zit aan het begin van je workflow, bijvoorbeeld bij het binnen komen van een e-mail waarna er automatisch het onderwerp en inhoud in een database wordt toegevoegd
- actions: een actie is een stap in je workflow. Zodra een trigger actief wordt, worden vervolgens de acties uitgevoerd.
- enterprise integration pack: als de standaard mogelijkheden niet toereikend zijn, dan kun je hiermee BizTalk Server mogelijkheden toevoegen.
Als je iets met workflows moet doen, dan heb je niet alleen App Service Logic App, maar ook Azure Functions, Azure App Service Webjobs en Microsoft Flow, ieder met hun eigen mogelijkheden en eigen redenen om te gebruiken. Op deze pagina kun je daar meer over lezen: link.
Het voorbeeld in het boek toont hoe een succesvolle build in Azure DevOps een melding in een kanaal in Teams toevoegt. Meer uitleg over de stappen en de flow kun je hier nalezen: link.
Microsoft levert meer dan 200 connectors aan. Maar het kan natuurlijk voorkomen dat voor jouw use-case een eigen connector nodig is. Die kun je ook zelf maken voor Logic Apps, Flow en PowerApps. Een eigen connector is een wrapper om een eigen REST of SOAP API. Je kunt een andere publieke dienst gebruiken zoals Google Calendar, Amazon Webservices.
Een eigen connector bestaat uit de volgende stappen:
- Bouw je API. Als je een eigen API maakt neem dan mee dat je Azure Functions, Azure Web Apps of Azure API Apps zou kunnen gebruiken.
- Beveilig je API. Als je een Azure Function, Azure Web App of Azure API App gebruikt kun je deze afschermen met Azure Active Directory. Je kunt het natuurlijk ook in de API code zelf afdwingen. Je kunt gebruik maken van deze mechanismes:
- OAuth 2.0 (de algemeen gebruikte versie/flow/code)
- OAuth 2.0 (de specifieke versie die gebruikt wordt bij de dienst, zoals Dropbox, Github, SalesForce, Azure Active Directory)
- Basic Authentication
- API Key
- Beschrijf de API en definieer de connector. Dit doe je met OpenAPI (wat vroeger Swagger was) of Postman.
- Gebruikt de connector in een Azure Logic App.
- Een optionele stap is om deze connector te delen met andere developers binnen je organisatie.
- Een optionele stap is om je connector door Microsoft te laten certificeren, zodat ook andere gebruikers deze connector kunnen gebruiken.
Het boek geeft het voorbeeld om een connector te maken met de Text Analytics API van Microsoft: link. De specs van het voorbeeld zijn hier te downloaden: JSON-bestand.
Meer informatie over eigen connectors kun je hier nalezen: link.
Je kunt van je eigen Azure Logic App een sjabloon maken (template) wat dan ook door collega's gebruikt kan worden en door jezelf. De code wordt dan omgezet naar een ARM template. Als je dan de app deployed, kun je met een parameter-bestand dit via een script uitvoeren.
Dit sjabloon kun je op een 3-tal plekken downloaden:
- Azure Portal, bij de App zelf.
- Visual Studio, via de Azure Logic App Tools extension .
- PowerShell, met de LogicAppTemplate Powershell module kun je het sjabloon downloaden.
Het sjabloon is een JSON-bestand en bestaat uit deze 3 onderdelen:
- Logic App Resource: informatie over de app zelf, locatie van de resource, pricing-plan, workflow definitie.
- Workflow definition: beschrijving van de workflow, inclusief triggers en acties. Ook hoe de app deze zaken uitvoert.
- Connections: informatie over de connecties die in de app gebruikt worden.
Uitleg over het maken van deze sjablonen staat hier: link en over het deployen staat hier: link.
Integratie van Azure Search in oplossingen
Azure Search is een SAAS (niet software maar search-as-a-service) die data voor je kan indexeren, en met een REST API of .NET SDK in je applicatie gebruikt kan worden. Je moet eerst een Azure Search service instantie aanmaken. Daarna moet je indexen toevoegen. Dat kan via de Portal, maar ook met code, C#, PowerShell, Postman, Python. Elke keer als je een index aanpast moeten deze opnieuw opgebouwd worden.
De standaard workflow volgt deze stappen:
- Maak een initiële index in het portaal. Met de "import data wizard" krijg je al wat adviezen.
- Download het index schema. Hiermee krijg je een JSON bestand, wat je dan naar eigen inzicht aan kan passen.
- Als je tevreden bent laadt je dit aangepaste JSON bestand.
- Query je index. Kijk of je wijzigingen goed zijn.
- Gebruik code voor de volgende aanpassingen. Het boek stelt dat dit niet via de portal meer kan, omdat als je de index aanpast, deze opnieuw opgebouwd moet worden en je alle velden in je index opnieuw moet aanmaken. Met een upload van een JSON bestand ben je veel sneller klaar.
Tip: tijdens het tunen, gebruik een deel van je werkelijke dataset, zodat je die extra (onnodige) tijd bespaart bij het aanpassen en opnieuw opbouwen.
Het JSON bestand bevat een property "fields". Elk veld bevat de volgende eigenschappen:
- Name: naam van het veld
- Type: het datatype
- Attributes:
- key: elke index moet 1 veld hebben (minimaal en maximaal) welke de key is. Deze is van type Edm.String
- retrievable: het veld wordt meegenomen in het resultaat.
- filterable: je kunt dit veld in een lijst met filters gebruiken als er op data gezocht wordt.
- sortable: je kunt dit veld als sortering voor het resultaat gebruiken.
- facetable: dit veld kan gebruikt worden voor een faceted (??) navigatie-structuur.
- searchable: markeert het veld als volledig tekst-doorzoekbaar.
- Suggesters: welke velden gebruikt kunnen worden auto-complete.
- Scoring Profiles: je kunt beïnvloeden welke velden belangrijker zijn en hoger in je resultaten komen. Dit is inzichtelijk voor de gebruikers.
- Analyzers: als een veld "searchable" is moet je de language-analyzer instellen op dat veld.
- CORS: je kunt aangeven welke Javascript client-side code API calls kan uitvoeren. Standaard staat dit uit.
- Encryption Key: je kunt de service instellen dat deze gebruik maakt van keys die de gebruiker beheert om de indexen te encrypten in plaats van de standaard keys die door Microsoft beheerd worden.
Meer uitleg over wat zo'n index nu precies is, is hier na te lezen: link. Uitleg over hoe je met C# indexen aan kunt passen kun je hier nalezen: link.
Er zijn 2 manieren om data in de index te laten, met push of met pull. Push: je upload met JSON je data naar de index. Bij die push kun je aangeven welke actie uitgevoerd moet worden, upload: toevoegen van een nieuw document, overschrijven bij een bestaand document, merge: vervang de velden in een bestaand document, als het document nog niet bestaat mislukt het request, mergeOrupload: hetzelfde als merge, maar als het bestand niet bestaat is dit het nieuwe bestand en delete: verwijder het document uit de index. Bij pull staat de data niet in de index, maar in een gerelateerde dienst, Azure Blob Storage, Azure Table Storage, Azure Cosmos DB, Azure SQL Database en SQL Server in een Azure VM. En met push heb je (natuurlijk) het minste last van latency (wachten) omdat je daar de data direct beschikbaar hebt.
De link naar sample data om te testen werkt niet meer, maar mogelijk kun je dan de open datasets gebruiken: link en misschien is deze repo op Github wel wat we nodig hebben: link.
Uitleg over het laden van data: link. Uitleg over het laden van data met Indexers: link. Gebruik van Indexer acties met behulp van de API: link. Als je bepaalde cognitieve diensten van Azure wilt gebruiken, kun je daar hier meer over lezen: link.
Als je query's uit wilt voeren op de index, daar kun je verschillende tools voor gebruiken:
- search explorer: dit zit in de Azure Portal.
- web testing tools: met Fiddler of Postman je requests sturen en zien wat er ontvangen wordt.
- .NET SDK: gebruik de .NET Azure Search SDK, hiervoor gebruik je de SearchIndexClient class.
- REST API: je kunt je eigen favoriete programmeertaal gebruiken om hier POST en GET requests heen te sturen.
Je kunt kiezen uit 2 query-types:
- Simpel: vergelijkbaar met Google en Bing, zoeken op tekst, je kunt AND, OR, NOT, phrase, suffix en precedence operators voor gebruiken (dus welk zoekwoord belangrijker is).
- Full: hierbij wordt de Lucene Query Parser gebruikt. De Azure Search Engine is gebaseerd op de Apache Lucene high-performance search engine. Je kunt dan veel meer dingen gebruiken, waaronder regexen, proximity zoekopdrachten, fuzzy, wildcard search en meer. Je gebruikt in je request queryType=full.
Houd ook in de gaten wat je doet. Ben je aan het:
- Zoeken: Lucene doet een volledige tekst-zoekactie, verwijdert zelf al de "the" en "and", verkort de query naar de kernwoorden, maakt de query lowercase, breekt component woorden in delen en stuurt dan het resultaat terug.
- Filteren: dit doe je op basis van een validatie wat een true of false teruggeeft. Je kunt filteren met tekst, maar dan moet de tekst ook exact gelijk zijn (en dat zal niet vaak voorkomen).
Informatie over de Lucene engine kun je hier vinden: link. Informatie over het benaderen van de REST service en daar query's op uitvoeren kun je hier nalezen, simpel en full.
Bouw API gateways
Microsoft biedt de Azure API Management service (APIM). Hiermee kun je jouw back-end services aanbieden, op een veilige manier, beveiligd tegen DOS aanvallen en biedt het gebruik van JWT tokens aan.
Microsoft heeft de APIM service als een facade opgericht. Hierdoor kun je de front-end API naar wens aanpassen terwijl die van de back-end wel gelijk/consistent blijft. Je kunt ook SOAP gebruiken en deze als REST aanbieden (dus een makkelijke manier om te upgraden). Prijsklassen hiervoor kun je op deze pagina bekijken: link.
Als je het developer-portal wilt aanpassen, je kunt hier lezen hoe dat moet: link. Met revisies en versies kun je zorgen dat "breaking changes" niet oude versies/aanroepen kapot maken: link.
Als je eigen authenticatie afhandeling in je API hebt, dat wordt genegeerd als die API in een APIM gebruikt wordt, deze heeft namelijk eigen settings hiervoor. Met een Subscription kun je de keys die toegang hebben beheren. Een subscription heeft 3 verschillende scopes:
- Product: als een developer toegang tot 1 van je producten wil hebben.
- All API's: een developer kan bij alle API's met dezelfde subscription key.
- Single API: als een developer toegang tot 1 API wil hebben.
Naast een subscription key kun je ook gebruik maken van OAuth 2.0: link, client certificaten: link en IP whitelisting: link.
Definieer policies (regels) voor je API
Request komt in, antwoord gaat uit. Maar het kan zijn dat je retour-data wilt transformeren (van XML naar JSON). Of juist het aantal inkomende calls wilt beperken.
Elke policy bestaat uit 4 onderdelen:
- Inbound: elk statement dat betrekking heeft op requests van de API clients.
- Backend: stappen die uitgevoerd moeten worden op het request wat binnen komt en doorgestuurd gaat worden naar de back-end.
- Outbound: stappen of acties die op de response uitgevoerd moeten worden voordat deze naar de aanvrager gestuurd worden.
- On-Error: als er in 1 van de voorgaande secties iets fout gaat, dan komen we in deze sectie.
Zo'n policy kan verschillende scopes hebben:
- Global: alle API's in je APIM volgen deze regels/instellingen.
- Product: geldt alleen voor de API's van dat specifieke product.
- API: geldt voor alle acties in jouw API.
- Operation: geldt alleen voor een specifieke actie in jouw API.
Policy's zijn krachtig en flexibel, zo kunnen ze zorgen voor caching, monitoring uitvoeren, authenticatie met je back-end API of zelfs interactie uitvoeren met externe services.
Uitleg over fouten afhandeling in API Management kun je hier nalezen: link. Hoe je een policy in kunt stellen of aanpassen kun je hier nalezen: link. En met Request Tracing kun je jouw API's debuggen: link.
Ontwikkel event-gebaseerde oplossingen
Om je code zo onafhankelijk mogelijk te kunnen bouwen, is er communicatie tussen de onderdelen nodig. Azure heeft die diensten, Event Grid, notification hubs, event hubs.
Azure Event Grid biedt je een serverless architectuur waar je verbinding kunt maken met Azure Blob Storage, Azure Subscription, Event Hubs, IoT Hubs en meer.
Het boek toont een voorbeeld waarbij een Azure Function log meldingen maakt. Om die te bekijken heb je Application Insights nodig, meer informatie hier te vinden: link.
Als een event niet afgeleverd kan worden, kan er een retry-actie gedaan worden. Als het nog steeds niet lukt, dan moet het "ergens" afgeleverd worden, dat is de "dead letter location". Meer informatie is hier na te lezen: link.
De Azure Notification Hub biedt je de mogelijkheid om berichten af te leveren via verschillende mobiele diensten. Los heb je de Apple Push Notification Service (APNS), Google Firebase Cloud Messaging (FCM) en de Windows Notification Service (WNS). En dat zijn alleen nog maar de "belangrijkste" partijen. In het boek zie je de implementatie met Event Grid, op deze pagina kun je de implementatie (met code) van een servicebus zien: link.
Met Azure Event Hub is aan te raden als je een dienst hebt waarbij je miljoenen requests per seconde ontvangt en weinig latency moet hebben. Azure Event Hub is de toegangsdeur naar achterliggende pijplijn. Als de hub data ontvangt kan dit doorgestuurd worden naar een Event Grid, opslagen worden in een Azure Blob account of in een Data Lake Storage.
Het pushen van data naar de hub kan op basis van AMQP 1.0, Kafka 1.0 (of nieuwer) of HTTPS. Je kunt 1 event sturen of meerdere in 1 request, maar daar zit wel een maximum op van 1 MB. Het opslaan van die events gebeurt in partities. Dat kun je niet verwijderen, je moet wachten tot de data "verlopen" is. Het groeien van de partities is onafhankelijk van elkaar. Je kunt tussen de 2 tot 32 partities maken, wil je meer dan moet je bellen met het Azure Event Hub Team. Let op: je kunt het aantal later niet aanpassen! Bij het inschatten van het aantal partities, reken dan met het maximum aantal parallelle downstreams die verbinding maken met de Event Hub.
Er volgt nog een voorbeeld, daarbij is een Azure Blob Storage container nodig. Uitleg is hier te vinden: link (container maken) en link (access keys verkrijgen).
Als je de Event Hub nodig hebt en gaat inrichten, lees dan deze pagina goed door: link, bij een onjuiste configuratie ga je waarschijnlijk snel merken dat het traag is/niet goed werkt.
Ontwikkel oplossingen die gebaseerd zijn op berichten
Gebruik de Azure Service Bus, dit is een broker en deze kan berichten (JSON, XML, tekst) verzenden. Bij een Service Bus horen een aantal termen:
Namespace: een container voor alle "messaging components". Een enkele namespace kan meerdere queue's en meerdere topics bevatten.
Queue: een container van berichten. FIFO: first in, first out. Een bericht krijgt een timestamp bij toevoegen aan de bus. Als het bericht verwerkt is wordt deze in een redundante opslag gehouden. Queue's zijn vooral voor 1 op 1 connecties.
Topic: je gebruikt een topic (onderwerp) voor het versturen en ontvangen van berichten. Een topic kan meerdere applicaties hebben die zich geabonneerd hebben via publish/subscribe. Elke applicatie die via een subscribe actie zich aangemeld heeft krijg een kopie van het bericht.
Meer informatie over queue's, topics en subscriptions: link. Het gebruik van service bus om je performance te verbeteren: link. Topic-filters en acties: link.
Een alternatief is de Azure Queue Storage queue. Deze wordt aangeraden als alternatief voor de Service Bus als er meer dan 80 GB in een queue opgeslagen moet worden. Hoewel het werkt met FIFO is de volgorde niet gegarandeerd (dat klinkt buggy...). De verschillen tussen de diensten kun je hier nalezen: link. Hoewel je niet kunt "subscriben" op een queue, is er op deze pagina wel een work-around uitgewerkt: link.