AnyPoint Platform: een introductie

Het is alweer tijd geleden dat ik iets heb geschreven. Ik ben echter nog steeds een enthousiasteling op het gebied van integratie en APIs en daarom is het tijd om verder te gaan waar ik gebleven ben. In mijn eerste blog heb ik APIs geïntroduceerd als een pilaar voor de digital transformatie. We zijn alweer een aantal jaar verder, maar dit blijft belangrijk; alleen door het ontwikkelen van een ‘Composible Enterprise’ (Gartner) kunnen bedrijven snel innoveren of reageren op veranderende marktomstandigheden. APIs spelen hierin een sleutelrol.

In mijn tweede blog ben ik hier dieper op ingegaan en heb ik de API-Led connectiviteit aanpak toegelicht. Een gelaagde API-architectuur waarbij er ontkoppeling plaatsvindt van bronsystemen of databronnen waardoor er herbruikbare bouwblokken ontstaan; inderdaad, bouwblokken waarmee de bovengenoemde Composible Enterprise gerealiseerd kan worden. Het idee achter deze filosofie is dat door het ontsluiten van data via APIs er sneller en gemakkelijker geïnnoveerd kan worden omdat de data reeds beschikbaar is via bestaande (standaard) bouwblokken.

In deze blog wil ik ingaan op één van de technologieën die deze filosofie geadopteerd heeft en een hele suite aan componenten omvat die dit ondersteunt. Het mag geen verrassing zijn dat ik het hier dan heb over MuleSoft met het AnyPoint platform. Dit platform bestaat uit verschillende componenten ter ondersteuning van de zogenoemde API Management ‘lifcycle’. Hier is al veel over geschreven en dit artikel van Postman gaat hier ook mooi op in. De API-levenscyclus wordt omschreven als ‘de methode om APIs te ontwikkelen die voldoen aan de eisen van de gebruiker, veilig, performant en consistent zijn zodat ontwikkelaars op Enterprise schaal APIs van hoge kwaliteit kunnen ontwikkelen’. Dit ziet er als volgt uit:

Zoals je kan opmaken uit het bovenstaande plaatje draait dit geheel zowel om de producent (aanbieder) alsmede de consument (afnemer) van een API. Een API kan alleen succesvol worden gebruikt als deze gevonden kan worden en voldoet aan de eisen van de afnemer. Dit klinkt logisch maar is niet vanzelfsprekend, daarom heeft MuleSoft volop ingezet op een platform waarmee deze afstemming zo naadloos mogelijk kan gebeuren. Dit platform ziet er als volgt uit:

Het platform bestaat uit een management- en een runtime gedeelte. De Runtime is waar de uiteindelijke APIs draaien en als hybrid Integration Platform as a Service (iPaas) kunnen deze zowel ‘On Premise’ als in de Cloud worden gepositioneerd. Door een hybride vorm te gebruiken kunnen interne (private) of externe (publieke) APIs worden ontsloten. Als klant kun je ervoor kiezen om gebruik te maken van MuleSoft’s eigen Cloud omgeving (CloudHub) of één van de grote Cloudproviders. Het voordeel van CloudHub is dat MuleSoft de gehele infrastructuur en daarbij behorende lifecycle activiteiten voor zijn rekening neemt waardoor je als klant maximaal wordt ontzorgd.

Het management gedeelte is een Cloud omgeving waar alles gemanaged en beheerd kan worden. Je gebruikers (rollen en permissies), design, beveiliging, monitoring en de API catalogus. Dit is het gedeelte van het platform dat de eerdergenoemde API Management levenscyclus op vele vlakken ondersteund en hier gaan we dieper op in.

Designer Center

Het begint met data behoefte. Deze behoefte wordt binnen een software development methodiek omgezet in een behoefte voor een API. Meestal wordt een ‘contract eerst’ methodiek gebruikt waarbij (voor de implementatie) eerste wordt vastgesteld hoe het API-contract eruit dient te zien. Steeds vaker zien we dat dit gepaard gaat met een ‘domain driven approach’ en het aanhaken van een data architect zodat deze modellen voldoen aan de juiste eisen en goed beschreven worden. Deze wordt gespecificeerd (dit kan zelfs nog buiten MuleSoft), maar zullen uiteindelijk in een API-specificatie terecht komen. Dit gebeurt in de Design Center, een web gebaseerde omgeving waar API-specificaties gemaakt worden (als RAML). Dit is een zeer belangrijke stap; een API moet goed beschreven worden en voldoen aan de standaarden (denk REST), want alleen dan kan een ontwikkelaar of afnemer de API gaan gebruiken zonder dat er uitgebreide interactie nodig is met de ontwikkelaar. Hierin beschrijf je dus:

• Wat het doel is van de API
• Welke operaties er zijn en hoe de data eruitziet, aangevuld met voorbeelden
• Welke fouten er kunnen ontstaan en hoe deze eruit zien en met welke foutcode(s)
• Hoe de toegang en autorisatie geregeld is

API Designer biedt ook de mogelijkheid om de API te simuleren. In het AnyPoint platform wordt de API dan al aangemaakt die ook daadwerkelijk aanroepen kan worden met de gedefinieerde voorbeeldberichten. Het idee is dat de eerste interactie dan al mogelijk is met de afnemer en dat deze ook al feedback kan geven; op deze manier kunnen er al aanpassingen gedaan worden voordat de implementatie is gestart.

AnyPoint Exchange

Waar we in de vorige alinea spraken over data behoefte en we gelijk doorschoten naar het ontwerpen van een API had de eerste stap eigenlijk moeten zijn om in de catalogus te kijken of er al een API bestond. AnyPoint Exchange is namelijk een zeer uitgebreide catalogus waarin verschillende herbruikbare componenten (‘Assets’) te vinden zijn. Denk hierbij aan:

• APIs (uiteraard)
• Connectoren (bijvoorbeeld SAP, Workday, MongoDB), maar ook eigen gemaakte REST APIs
• Templates (denk ook stukken code ter standaard integratie tussen bijvoorbeeld SAP en Workday)
• API Management policies (rate limiting)
• Data transformative libraries

Dit is de plek waar nieuwe herbruikbare componenten beschikbaar zijn. Zo heeft MuleSoft zelf al een uitgebreide set aan connectoren gebouwd, maar ook de interne APIs van de organisatie komen hier terecht ( uiteraard alleen zichtbaar voor de organisatie zelf). Wanneer je klaar bent met je API-specificatie en deze voldoet na eventuele feedback, dan publiceer je de API in AnyPoint Exchange. Je specificatie is dan direct vindbaar. Dit is tevens de plek om nog extra informatie/documentatie toe te voegen zodat een ontwikkelaar nog beter met je API aan de slag kan. Dit betreft dan vaak release notes, extra (functionele) informatie over fouten, de beschikbarheid, SLA’s en/of supportgegevens. Alles om gemakkelijk met de asset aan de slag te gaan. Nadat je API ook nog is toegevoegd aan de API Manager (zie hieronder), kunnen afnemers ook echt toegang vragen tot de API en ermee aan de slag gaan!

API Manager

De API Manager is het component waar de API gemanaged wordt. Wanneer de API gepubliceerd is in Exchange is het mogelijk de API op te nemen in de API Manager. Je kan aangeven welke versie er draait, beveiliging en toegang beheren en SLA’s bijhouden. Ook zijn er statistieken beschikbaar over de load en informatie over succesvolle en/of gefaalde transacties. Wanneer jij dus een nieuwe versie van je API hebt doorgezet naar Exchange, betekent dit uiteraard nog niet dat echt draaiende APIs deze versie al hebben, dat moet immers nog geïmplanteerd worden. Via API Manager kun je per omgeving aangeven dat de versie is geüpdatete. Het mooie van dit mechanisme is dat dit dan direct zichtbaar wordt in Exchange, zodat consumenten (ontwikkelaars) hier toegang op kunnen aanvragen. Zo’n aanvraag wordt dan weer zichtbaar in de API Manager en de API (of data) eigenaar kan deze toegang dan verlenen of afwijzen. Ook kan reeds verleende toegang ook altijd weer worden ingetrokken.

Een belangrijke feature is het kunnen toepassen van zogenaamde ‘policies’. Dit zijn belangrijke additionele beheer componenten die je real-time kan toepassen op je API. Denk hierbij aan:

1. Toegang, via basic authenticatie of JWT
2. Rate limiting: Het limiteren van het aantallen bevragingen dat een afnemer kan doen op de API per tijdseenheid. Bijvoorbeeld 10 bevragingen per seconde
3. Caching: Het teruggeven van de data uit een cache (dus niet de echte API)
4. Header manipulatie: Toevoegen of verwijderen van HTTP headers

Tenslotte is het via de API Manager mogelijk om een proxy op te zetten naar een API en deze wederom te managen via de reeds benoemde mogelijkheden. Dit is een gemakkelijkere manier om een reeds bestaande API inde organisatie wel gemanaged te laten worden via het AnyPoint platform.

AnyPoint Studio

Nu je API gespecificeerd en gepubliceerd is kan deze worden gebouwd; het echte integratiewerk kan gedaan worden. Dit gebeurt in AnyPoint Studio, een Eclipse gebaseerd IDE die MuleSoft beschikbaar heeft gesteld om je API de bouwen middels een ‘low code’ principe en ziet er als volgt uit:

Via ‘drag en drop’ kun je een flow in elkaar kan klikken met verschillende activiteiten die nodig zijn voor de integratie en je API te laten werken zodat deze voldoet aan je specificatie. Dit begint dan ook met het toevoegen van je specificatie uit AnyPoint Exchange. Studio herkent de specificatie en zal gelijk aan je vragen om de verschillende operaties van je specificatie te genereren. Dit allemaal om jouw werk gemakkelijker te maken. Vaak hebben organisaties al een template ter beschikking gesteld om dit werk nog sneller en gemakkelijker te maken. Meestal is het nodig om een andere API (HTTPS) of databron (JDBC) aan te roepen of te ontsluiten en de data te transformeren naar het gespecificeerde datamodel. Dit gebeurt in MuleSofts eigen functionele programmeer- of scripttaal DataWeave. Dit is een bijzonder krachtige taal om data transformaties uit te voeren.

Binnen AnyPoint kun je datgene wat je gebouwd hebt ook unit testen via een unit test raamwerk dat MuleSoft beschikbaar heeft gesteld genaamd MUnit. Dit is een zeer krachtige manier om je flows te unit testen waarbij je al je externe afhankelijkheden kan simuleren. Door een groot aantal asserties is het mogelijk om je output te valideren en dit draagt dus sterk bij aan de kwaliteit van je opgeleverde code. Binnen je project (pom) is het mogelijk om aan te geven dat dit verplicht is en met welke dekking alvorens je applicatie (jar) gebouwd kan worden. Tevens maak je in je project een referentie naar je API Manager (via autodiscovery) waarmee je de API zichtbaar maakt voor API Manager.

Om je een beeld te geven van wat we ondertussen gedaan hebben kunnen we refereren naar het volgende plaatje:

1. We hebben onze specificatie gemaakt in Designer
2. We hebben de specificatie gepubliceerd en beschikbaar gemaakt in Exchange
3. We hebben een API Manager entry aangemaakt voor de in Exchange gedefinieerde API
4. We hebben de API-specificatie geïmplementeerd in AnyPoint Studio

Het laatste wat ons te doen staat het is daadwerkelijk uitrollen van onze API naar de Runtime. Dit kan via verschillende methoden (denk handmatige of via een CI/CD pipeline), en hierbij komt de volgende component om de hoek kijken.

Runtime Manager

De Runtime Manager is het onderdeel van AnyPoint Platform waarbij de API gemanaged kan worden in de Runtime. Concreet betekent dit dat je kan zien of de API draait en met welke resources. Je kan de API horizontaal of verticaal schalen (afhankelijk van je infrastructuur) of je logs inzien. Tevens kun je JVM-eigenschappen toevoegen om het gedrag je van je API te beïnvloeden of om debug logging aan te zetten. Niet onbelangrijk om te vermelden is dat je APIs kan stoppen en starten.

AnyPoint Monitoring

Tenslotte wil je inzicht hebben in je API, de bekende statistieken. Dit doe je in AnyPoint monitoring. Hier heb je inzicht in hoe vaak je API wordt aangeroepen, met succes codes (2XX) of foutcodes (4XX / 5XX) en wat de performance is van je API. Tevens krijg je extra inzicht in de infrastructuur (CPU / geheugen) zodat je kunt zien of deze niet aan de limiet zit en er wellicht geschaald dient te worden. Door hierop dan weer alerts te definiëren kun je proactief een bericht krijgen die aangeeft of er iets mis is met je API; hierdoor kun je nog voordat er een business incident wordt gelogd al analyseren en eventueel oplossen!

Hiermee hebben we de meest gebruikte onderdelen van het platform behandeld en geeft het inzicht op welke manier de API lifecyle door het AnyPoint platform wordt ondersteund met als doel een Composable Enterprise te realiseren.