Wat is eventgestuurde architectuur?
Eventgestuurde architectuur (EDA) is een integratiemodel dat belangrijke “gebeurtenissen” in een bedrijf detecteert – zoals een transactie of een verlaten winkelwagentje – en er in realtime op inwerkt.
Overzicht eventgestuurde architectuur
Bijna elk evenement in een bedrijf is tijdgevoelig. Wanneer een klant een online aankoop doet, markeert een sensor een dreigende storing, daalt de aandelenprijs of wordt een beveiligingslek gedetecteerd – er moet onmiddellijk actie worden ondernomen. Hier komt een eventgestuurde architectuur (EDA) binnen. Een EDA kan gebeurtenissen creëren, detecteren en erop reageren terwijl ze zich ontwikkelen, waardoor bedrijven alles kunnen verbeteren, van klantervaringen tot operationele efficiëntie en flexibiliteit.
Wat is een evenement?
Eerst wat basics. Een gebeurtenis is elke handeling of verandering van staat die belangrijk is voor een bedrijf. Bijvoorbeeld wanneer iemand met een creditcard swipet, incheckt voor een vlucht of een wachtwoord opnieuw instelt, of wanneer de voorraad in een magazijn wordt bijgewerkt. Gebeurtenissen gebeuren voortdurend, in elke organisatie, in elke branche. Bedrijven worden ‘eventgedreven’ wanneer ze gebeurtenissen kunnen vastleggen en erop kunnen reageren zodra ze plaatsvinden.
Wat is een eventgestuurde architectuur?
Een eventgestuurde architectuur (EDA) is een integratiemodel dat is gebouwd om gebeurtenissen tussen gedistribueerde systemen in realtime te publiceren, vast te leggen, te verwerken en erop te reageren. Wanneer een gebeurtenis zich voordoet in één toepassing, wordt automatisch een bericht verzonden naar alle andere toepassingen die erover moeten weten, zodat ze er op hun beurt actie op kunnen ondernemen.
Eventgebaseerde architecturen worden ontkoppeld, wat betekent dat applicaties zich niet bewust hoeven te zijn van elkaar om informatie te delen en taken uit te voeren. Gebeurtenisinformatie, of berichten, kan vrij en automatisch tussen apps stromen. Hierdoor is het EDA-model veel sneller dan het traditionele aanvraag-/responsmodel, waarbij de ene applicatie de specifieke informatie moet aanvragen die het nodig heeft van een andere applicatie en moet wachten op een reactie voordat de volgende taak wordt uitgevoerd. Ook vanwege de ontkoppelde aard van een EDA worden zij algemeen beschouwd als beste praktijken voor communicatie met microdiensten.
Hoe werkt een EDA?
In een eventgestuurde architectuur fungeren applicaties als eventproducenten (apps die events produceren of vastleggen) of als eventconsumenten (apps die gebeurtenissen verwerken en erop reageren). Producenten verzenden evenementen naar consumenten via een broker, oftewel messaging-georiënteerde middleware, in realtime. Consumenten kunnen de gebeurtenis vervolgens verwerken en andere acties, workflows of eigen events starten.
In een zeer eenvoudige architectuur – wanneer er één producent en één consument is die direct met elkaar communiceren – kunnen makelaars optioneel zijn. In de meeste ondernemingen zijn er echter meerdere bronnen die evenementen naar meerdere consumenten sturen, zodat een makelaar, of zelfs een netwerk van makelaars (ook wel bekend als een "event mesh") nodig is. Wanneer een makelaar of een event mesh wordt gebruikt, creëert dit een “losse koppeling” van toepassingen.
Eventgestuurde architectuurpatronen
Er zijn twee hoofdpatronen voor het verzenden van gebeurtenissen in een eventgestuurde architectuur: publiceren/abonneren en eventstreaming.
Publiceren/abonneren (ook wel “pub/sub” genoemd): met pub/sub abonneren eventconsumenten zich op berichten en kanalen die door producenten van evenementen worden gepubliceerd. Wanneer een gebeurtenis wordt gepubliceerd, wordt deze rechtstreeks naar alle abonnees verzonden via een broker. Om duplicatie te voorkomen, kunnen events niet opnieuw worden afgespeeld of geopend zodra ze zijn verbruikt; ze worden verwijderd door de tussenpersoon.
Event streaming – Met event streaming publiceren producenten hele streams van evenementen aan een broker. Consumenten abonneren zich op de stream en kunnen deze uit elk deel lezen, waarbij ze alleen de events gebruiken die relevant zijn voor hen. Met dit patroon worden gebeurtenissen behouden door de makelaar, zelfs nadat ze zijn geconsumeerd.
3 benaderingen voor gebeurtenisverwerking
Er zijn drie verschillende benaderingen voor het verwerken van events zodra ze een consument bereiken: eenvoudige eventverwerking, complexe eventverwerking en verwerking van eventstromen.
- Eenvoudige eventverwerking: consumenten verwerken elk event zoals het wordt ontvangen.
- Complexe eventverwerking: consumenten verwerken een reeks events om patronen te detecteren en acties uit te voeren op basis van het resultaat.
- Verwerking van eventstream: consumenten verwerken en handelen op basis van een constante datastroom (data in beweging) in realtime met behulp van een datastreamingplatform.
Bedrijven kiezen hun aanpak voor eventverwerking op basis van hun individuele behoeften en use cases.
Use cases en voorbeelden van eventgestuurde architectuur
Er zijn veel verschillende use cases voor eventgestuurde architecturen in elke branche – van bankieren tot retail. Hier volgt een voorbeeld uit de horeca:
Een student plaatst een bestelling voor een pizza via een food delivery app, zoals Uber Eats. De app legt zijn basisinformatie vast (naam, adres, betalingsinformatie en bestelling) en publiceert het evenement “pizzabestelling”.
Het pizza-restaurant abonneert zich op het evenement, voert de bestelling uit en publiceert zijn eigen ‘order ready’-evenement terug naar de fooddelivery service
De service wijst vervolgens een afleverchauffeur toe, plant een ETA en waarschuwt de klant dat zijn cirkel onderweg is.
Een EDA-voorbeeld van e-commerce:
Op online shopper voert zijn/haar creditcardgegevens in op een e-commercesite, die de "betaling verzonden" gebeurtenis publiceert
Het betalingssysteem abonneert zich op de gebeurtenis, verwerkt de betaling en geeft een eigen “betaling verwerkt”-event uit dat succes of mislukking aangeeft – en routeert deze terug naar de website-UI.
De gebruikersinterface geeft de betalingsstatus aan de klant weer en vraagt om volgende stappen
Andere voorbeelden van EDA zijn:
Wanneer een online shopper op een product klikt en het systeem reageert door productaanbevelingen te genereren op basis van soortgelijke artikelen
Als een klant een cheque bij een bank stort en het systeem de storting automatisch naar zijn rekening boekt
Wanneer een retailer globale transacties op fraude controleert en verdachte aankopen aan de creditcardmaatschappij markeert
Wanneer een producent de streaming van IoT-gegevens van zijn equipment bewaakt en wordt gewaarschuwd voor mogelijke onderhoudsproblemen of storingen
Voordelen van een eventgestuurde architectuur
Er zijn veel voordelen van een eventgestuurde architectuur. De top 3 zijn:
- Realtime workflows en responsiviteit. Een EDA kan gebeurtenissen bewaken en er snel op reageren, vaak met behulp van Robotic Process Automation (RPA) om workflows te versnellen en vervolgstappen in realtime te starten. Dit is vooral van cruciaal belang in tijden van pieken in de vraag, bijvoorbeeld tijdens grote verkoopevenementen of feestdagen. Deze responsiviteit kan ook worden toegepast op elke dag (d.w.z. niet-piekworkflows, die alles verbeteren, van automatisering van de supply chain tot fraudedetectie.
- Asynchrone berichten. Aanvragen in een EDA communiceren asynchroon – dat wil zeggen dat producenten eventberichten publiceren zonder te wachten tot consumenten ze ontvangen. Hierdoor kunnen applicaties niet alleen naar andere taken gaan zonder te wachten, het vereenvoudigt de integratie.
- De- en losse koppeling. Toepassingen in een EDA worden losgekoppeld of losgekoppeld en zijn niet afhankelijk van elkaars beschikbaarheid. Ze kunnen onafhankelijk worden bijgewerkt, getest en geïmplementeerd. Ze kunnen ook onafhankelijk falen – dus de architectuur is duurzamer en hardnekkiger dan traditionele modellen. Ontkoppeling maakt het ook gemakkelijk om naar behoefte extra uitgevers en consumenten toe te voegen, waardoor het niet meer nodig is om code te herschrijven elke keer dat er een wijziging plaatsvindt.
Conclusie
Event mesh biedt implementatieopties in verschillende hyperscalers en in private cloudomgevingen. Het kan worden geconfigureerd om een gedistribueerde netwerk van event brokers te vormen die worden ingezet in omgevingen in private of public clouds. Event mesh biedt een volledige reeks eventingservices, waaronder gebeurtenisstreaming, evenementenbeheer en -bewaking, en geavanceerde functies zoals dynamische berichtroutering en fijnkorrelige filtering.
Ontdek de mogelijkheden van SAP Event Mesh
Versterk je apps met een eventgebaseerde architectuur van SAP Integration Suite.
Ideeën die u nergens anders zult vinden
Meld u aan voor een dosis business intelligence die rechtstreeks in uw inbox wordt bezorgd.