Skip to main content
Developer portal
Switch Language
Katrien
Katrien Van Gijsel

Business Innovation Manager KBC

Maxime
Maxime Passenier

KBC Enterprise Architect

In het eerste deel van onze reeks over integratiemogelijkheden kwamen verschillende vormen van integraties zoals API’s, widgets en URL’s aan bod. Met elk van deze vormen kun je dezelfde functies aanbieden zoals een betaling doen, iets te koop aanbieden, enz. Eén ding hebben ze allemaal gemeen. De ene partij biedt een functie aan zodat de andere partij deze kan gebruiken. Afhankelijk van welke verantwoordelijkheid elke partner wil nemen, kies je voor een andere integratievorm. Deze keer gaan we een stap verder. We verdiepen ons in het principe van een gelaagde architectuur. Dit passen we toe bij zeer veel applicaties. We verdelen de verantwoordelijkheden van een applicatie over verschillende ‘lagen’ die met elkaar verbonden zijn.

 

Lagen van een applicatie

Presentatielaag

De bovenste laag is de presentatielaag. Dit is de laag die de gebruiker van de applicatie ziet en waarin hij werkt. De logica waarmee deze laag is opgebouwd, helpt de gebruiker om vlot te werken met de applicatie. Denk aan validatie op velden zodat de gebruiker onmiddellijk feedback krijgt van wat er moet verbeterd worden. Voorbeelden hiervan zijn: een geboortedatum in een bepaald formaat, de taal van de applicatie of een carrousel aan foto’s waar je de mogelijkheid hebt om door te klikken.

De middelste laag is de businesslaag. Deze laag bevat wat we business logica noemen en is de verbindende schakel tussen de andere twee lagen. Business logica betekent concreet de regels waarmee jij je business runt, maar dan vertaald in IT-logica. Hieronder vallen specifieke berekeningen of controles. Denk aan het uitrekenen van hoeveel commissie er wordt betaald op een aankoop of het controleren of partijen wel toegang mogen hebben tot bepaalde informatie.

Een mooi voorbeeld hiervan is een bank die naar je loonbewijs vraagt voor je een lening krijgt. Dit is een business rule die technisch vertaald werd in de businesslaag. Zo stuurt de businesslaag de presentatielaag: wat je ziet in de presentatielaag wordt bepaald door de regels die gedefinieerd zijn in de businesslaag. Een veld dat verplicht in te vullen is, wordt rood in de presentatielaag op basis van de logica die in de business laag zit.

De onderste laag is de persistente laag of ook wel de datalaag genoemd. Hier worden alle data, al dan niet gemanipuleerd door de businesslaag, opgeslagen. Het is de link tussen de toepassing en de achterliggende database(s) die de toepassing gebruikt. De datalaag zelf bevat in principe geen logica. Het is eigenlijk gewoon het notitieboekje waar de businesslaag in schrijft.

Dit is interessant omdat elk type integratie hier anders mee omgaat. De laag die niet vervat zit in de integratievorm, heb je dus zelf onder controle en is jouw verantwoordelijkheid.

De rol van API-consumer en API-producer

Het meest courante type, de API, biedt enkel de business logica aan. De persoon die de API maakt en aanbiedt, is de API-producer. De API-consumer is de partner die de API gebruikt en ter beschikking stelt van zijn klanten.

Bij API’s is het de verantwoordelijkheid van de API-consumer om zelf de nodige stappen te zetten om deze om te vormen naar een scherm voor zijn gebruiker. Dit houdt in dat de partner die de API ter beschikking stelt van zijn gebruikers zelf de presentatielaag maakt.

API-contract of swagger

De scheidingslijn tussen consumer en producer voor deze integratie is beschreven in het API-contract of de swagger. Deze beschrijft concreet waar de verantwoordelijkheid van de consumer eindigt en waar die van de producer begint.

Zo een technisch contract of de swagger is geschreven in een specifiek formaat. Hierin staat wat de API nodig heeft als informatie om zijn ding te doen en welke info je mag verwachten als antwoord. De swagger beschrijft enkel de vorm waarin de informatie terugkomt, niet hoe de achterliggende businesslogica in elkaar zit of hoe het gedrag wordt omschreven.

Het grote voordeel is dat jij als consumer van de API zelf de verantwoordelijkheid houdt over de presentatielaag: jij kiest wat jouw klant ziet, wat hij moet doen of niet om de service te gebruiken. Het correct invullen van de API zoals omschreven in de swagger is de verantwoordelijkheid van de consumer. De producer van de API is verplicht om gepast te reageren op de aanvraag van de consumer. Ook de verdere verantwoordelijkheid over de datalaag ligt bij de producer.
 

Gedrag van de API

Zo een contract lijkt simpel. Maar op de scheidingslijn van verantwoordelijkheden zit wel wat marge voor misinterpretatie. De swagger omschrijft wat je aan de API’s kunt vragen en wat hij kan teruggeven maar niet het ‘gedrag van de API’.

Stel nu een lening-simulatie API. Deze vraagt 2 velden: het bedrag van de aankoop en de eigen inbreng. De swagger gaat niet omschrijven hoe de API reageert als de eigen inbreng hoger is dan het bedrag van de aankoop of als één van de 2 getallen negatief is. Er staat wel in wat je terugkrijgt van de API: je kunt de lening al dan niet krijgen.

Wil je meer weten over het gedrag van de API? Deze onderliggende businessregels vind je terug in de documentatie van de API. Het voorbeeld met de leningsimulatie is erg eenvoudig. Maar als we met complexere API’s werken waar bijvoorbeeld ook opgeslagen data invloed hebben op het resultaat van een API, dan wordt dit gedrag potentieel heel uitgebreid.

Wat de API teruggeeft aan de consumer noemen we het externe gedrag van de API. Het interne gedrag staat beschreven in de documentatie. Zo weet je als consumer van de API waarop je mag rekenen.

Samensmelten van interfaces

De Iframe, widget en SDK gaan we even op één hoop gooien. Al deze integraties gaan een stap verder dan de businesslogicalaag en bieden ook een grafische interface. Deze interface kan worden ‘ingesloten’ in de interface van de consumer en zo versnelt het implementatieproces aanzienlijk. De grafische interface ondersteunt in de meeste gevallen ook de interacties van de gebruiker en maakt zo deel uit van de presentatielaag.

De verantwoordelijkheden tussen producer en consumer liggen hier natuurlijk anders dan bij een API. Deze integratievormen hebben ook een contract, een manier waarop deze kunnen worden geïnitieerd door de software van de consumer. Daardoor zullen ze naast het aanbieden van een grafische schil ook een resultaat teruggeven aan deze software. Dit is heel overeenkomstig met de contracten van een API. Het grote verschil is nu net de grafische interface en wat deze juist doet. 

Voorbeeld van een integratie: mapswidget

Wanneer dergelijke integratie wordt opgezet, verwacht de consumer dat deze bepaalde functies opneemt. Zo kun je bijvoorbeeld verwachten van een mapswidget dat je als gebruiker kunt inzoomen of een route tekent. Dit alles maakt onderdeel uit van het externe gedrag van een widget. De producer van de widget is hiervoor verantwoordelijk. Bij deze integratievormen heeft de producer dus de verantwoordelijkheid over de presentatielaag en de businesslaag. Het nadeel voor de consumer van deze integratievorm is dat deze niet meer kan bepalen hoe en wat de eindklant ziet.

Impact van integraties

Dergelijke implementaties hebben ook in meer of mindere mate een invloed op de omgeving waarin ze draaien. Deze impact ‘constant’ houden is iets waarmee de producer van de integratie rekening moet houden.

Belangrijk in de keuze van integratietypes is weten welke verantwoordelijkheid je wilt dragen en welke niet. Dit zowel in het bouwen als in het onderhouden van de integratie. Ook goed om te weten, is dat de data uiteindelijk altijd in de persistente laag zit en dus altijd bij de producer van de integratiemethode.

 

meer weten

Meer weten over onze integratiemogelijkheden?

Op de KBC Developer Portal vind je een overzicht van de verschillende bedrijfsoplossingen en technische integraties.

Ontdek meer

About us

KBC Open Bankverzekeren stimuleert innovatie
om je bedrijf naar een hoger niveau te tillen.

Contact us

Oplossingsgerichte vragen : +32 2 4480 187 (op werkdagen van 8u tot 18u)

Technische vragen : Contact