3. Data: het nieuwe goud

Wat zijn de belangrijkste concepten in data integratie?

Er zijn steeds meer buren die het talent van Aleksandra weten te waarderen. Aleksandra noteert dit allemaal in een notitieboekje. Daarin staat iedereen die een gerecht van haar heeft gegeten en wat ze ervan vonden. Ook heeft ze een tweede notitieboekje met daarin haar eigen recepten. Tenslotte verzamelt ze de recepten van haar бабуся (babusya) en haar experimenten met Nederlands gebak.

Die recepten zijn voor haar van onschatbare waarde. Wat als ze haar notitieboekjes kwijt raakt? Wat als er brand ontstaat? Het beste is de notities ook op te slaan in de cloud. Eerst gebruikt ze gewoon Word en Excel en slaat een kopie hiervan op in de cloud met Dropbox.

Later komt ze er achter dat er ook een clouddienst is speciaal voor recepten. Die heeft echter een API die verwacht dat de recepten in specifieke velden staan. Dit is in het JSON Format. Aleksandra kent dit vanuit haar werk in het telecombedrijf, dus ze zet al haar recepten om naar dit formaat. Ze verstuurt de berichten via de veelgebruikte API tool Postman.

Data

Data is de kleinste eenheid binnen integratie. Het is een feit, zoals bijvoorbeeld de naam van een medewerker, een ingrediënt of een ordernummer. Data als verzameling feiten heeft een beperkte waarde. Data op dit niveau is vaak nog niet interessant voor een persoon of bedrijf. De echte waarde ontstaat als informatiesystemen en mensen die data kunnen gebruiken en interpreteren.

Echter, voor het zover is moet het wel op de juist plek komen. Dit is de rol van data integratie.

Data het nieuwe goud

Data wordt als het nieuwe goud gezien. Vaak wordt hierbij gekeken naar bedrijven als Facebook en Google. Op basis van data (Waar klik je op? Waar kijk je naar?) kunnen zij een profiel van je bouwen. Op deze manier sturen zij welke reclame je te zien krijgt en hoe hun producten worden ontwikkeld.

Maar het is zeker niet alleen bigtech waarvoor data waardevol kan zijn. Als voorbeeld hebben we al data als basis voor bestelalgoritmes in supermarkten gezien, maar denk ook aan data voor onderzoekers naar virussen, data voor de overheid met betrekking tot waar een nieuwe weg moet komen, enzovoort. Zelfs op persoonsniveau kan data waardevol zijn. Neem nu Thomas. Van al die taarten is hij flink aangekomen. Hij is aan het sporten geslagen. Om zijn resultaten te meten maakt hij gebruik van een Samsung Smartwatch. Dit horloge meet zijn hartritme, sportresultaten en slaappatronen.

Waar het in de context van data integratie om gaat, is hoe we data op de juiste plek krijgen, op het moment dat het nodig is en in alle volledigheid. Bij een smartwatch betekent dit dat data van de smartwatch via de telefoon in de cloud wordt gezet.

Thomas weet als gebruiker helemaal niet hoe de datastromen werken (hij vloekt hoogstens even als er iets niet goed gaat), maar om ze te synchroniseren zijn verschillende data formaten en middleware op de achtergrond nodig. We zoomen dus eerst verder in op data en daarna weer uit op de middleware-component die de data transporteert.

Dataformaten

Wanneer je de feiten van een dataverzameling volgens een vaste structuur opslaat spreken we van een dataformaat. De meest bekende dataformaten binnen integratie zijn CSV, XML en JSON. In de basis zijn dataformaten gewoon tekst. Maar wel tekst die is geordend volgens een aantal vaste regels.

Omdat tekstbestanden technologie-onafhankelijk zijn, zie je dat deze veel gebruikt worden voor het uitwisselen van gegevens. De dataformaten standaardiseren de wijze waarop de data wordt gestructureerd, zodat deze makkelijk verwerkt kan worden. Het zijn als ware de containers die door schepen, treinen en andere vervoersmiddelen getransporteerd worden.

CSV

CSV staat voor Comma-Separated Values. Waardes zijn meestal gescheiden door een komma, maar dat kan ook een ander teken zijn. Het formaat zou daarom beter DSV, “Delimeter-Separated Values”, kunnen heten, maar dat is historisch nu eenmaal anders verlopen.

Het is, zoals het scheidingsteken al aangeeft, een erg los formaat in een simpele tabelstructuur. Het voordeel van CSV is dat je alleen waardes weergeeft, waardoor je veel data op een klein stuk geheugen kwijt kan.

Het formaat is helaas niet erg strikt en daarom soms lastig te gebruiken voor data integratie. Door welk teken worden de waardes gescheiden? Hoeveel regels staan er maximaal in een bericht? Bevat het bericht headers? Daarnaast is het lastig leesbaar voor mensen en beperkt voor complexere structuren.

Voorbeeld CSV met headers:

ordernummer,klant,adres
12345,Dirk Hondenvriend,Stationsstraat 11
34523,Anneke de Vries,Dorpstraat 369a

Hetzelfde voorbeeld van de CSV zonder headers:

"12345";"Dirk Hondenvriend";"Stationsstraat 11"
"34523;"Anneke de Vries";"Dorpstraat 369a"

CSV worden veel gebruikt voor data-import en -export. Bijvoorbeeld voor een database. Voor een data flow met validaties, routeringen en andere integratiepatronen is dit formaat minder geschikt. Om CSV-bestanden makkelijker te bewerken, worden deze daarom vaak eerst omgezet naar het XML- of JSON-formaat.

XML

XML (eXtensible Markup Language) is een gestructureerd tekstformaat, waarmee je ingewikkelde structuren kunt weergeven die zowel door mensen als machines gelezen kunnen worden. Als een tekstbestand aan de regels van XML voldoet is de XML “well-formed”.

De belangrijkste regels van XML zijn dat het formaat precies één root- element bevat en dat elk element een begin- en eindtag heeft:

<root>
   <element attribuut="waardeX">waardeY</element>
</root>

Een waarde staat in een element of attribuut. In eerste instantie lijkt XML veel op HTML, aangezien deze ook van tags gebruik maakt:

<html>
   <b>tekst</b>
   <br>
</html>

Bij HTML zijn de tags echter al vooraf bepaald om te worden geïnterpreteerd door een browser. De tag <b> betekent bijvoorbeeld dat de tekst ertussen vetgedrukt dient te worden. De tag <br> betekent een enter.

Toch is een HTML-document niet per se een well-formed XML-document, omdat bijvoorbeeld de tag <br> helemaal niet afgesloten hoeft te worden. Er is ooit het plan geweest om HTML wel aan de regels van XML te laten voldoen (XHTML), maar dat is nooit doorgezet naar de browsermarkt.

Één van de belangrijkste kenmerken van XML is dat het uitbreidbaar is (de X in XML staat voor eXtensible). Je kunt dus zelf bepalen hoe je tags definieert. De tag <b></b> kan voor jouw organisatie iets heel anders betekenen dan voor een andere organisatie. Stel: ik wil een taart XML maken, dan is het prima om deze XML zelf op te stellen:

<taartjes>
     <taart>appeltaart</taart>
     <jarige>Thomas</jarige>
</taartjes>

Er zijn veel technieken om XML te kunnen verwerken. Bijvoorbeeld door een schema op te stellen dat aangeeft wat voor jouw systeem een geldig XML is. In dit zogenoemde XSD (XML Schema Definition) bepaal je zelf de voorwaarden voor de tags: op welke plek moet de tag voorkomen, is dit een tekstveld, wat is de maximale lengte? Als je vervolgens een bestelling voor het bakken van een taart krijgt, kun je controleren of dit in het afgesproken formaat is.

Stel dat de volgende XML wordt gestuurd:

<taartjes>
     <taart>appeltaart</taart>
     <jarige>Albert</jarige>
     <aantal>2</aantal>
</taartjes>

Als de tag <aantal> niet in het schema staat wordt de bestelling afgekeurd. Aleksandra vindt het een beetje veel om er twee te bakken, dat was niet de afspraak!

Er zijn nog een hoop andere technieken die met XML overweg kunnen. Een belangrijke techniek voor data integratie is XSLT (eXtensible Stylesheet Language Transformations). XSLT bouwt een nieuw document op en gebruikte waardes en velden uit het inputdocument. Stel: de ontvanger verwacht een andere volgorde van de tags en ook dat deze in het Engels zijn opgesteld. XSLT transformeert de oorspronkelijke XML dan naar:

<cakes>
      <number>2</number>
      <cake>Apple pie</cake>
      <name>Thomas</name>
</cakes>

JSON

Net als XML is JSON (JavaScript Object Notation) een dataformaat voor gestructureerde data die door mensen en systemen kan worden geschreven en gelezen. Omdat JavaScript de belangrijkste taal is voor websites zie je de laatste jaren dat JSON enorm aan populariteit heeft gewonnen. Vaak zie je dit als dataformaat tussen back end (op de server) en front end (in de browser) van een webapplicatie. Tegenwoordig zie je dit ook steeds meer verschijnen als formaat voor uitwisseling van data tussen systemen (vooral bij REST API’s).

Voorbeeld JSON:

{
   "number": 2,
   "cake": "Apple pie",
   "name": "Thomas"
}

Alternatieve dataformaten

Er zijn nog enkele alternatieve dataformaten:

• YAML — Een dataformaat dat probeert om de benodigde syntax te minimaliseren. Het wordt veel gebruikt voor de configuratie van systemen en minder in data integratie. Hoewel YAML er anders uitziet dan JSON, is YAML een superset van JSON. Daardoor kan een geldig YAML-bestand JSON bevatten.
• Protocol Buffers — Een dataformaat ontwikkeld door Google. Deze is met name ontwikkeld voor hoge performance. Op basis van het dataformaat kan code in verschillende talen gegenereerd worden om data te lezen of te schrijven naar het formaat.
• AXON — Dit staat voor An eXtended Object Notation, een dataformaat voor het vastleggen en uitwisselen van objecten, documenten en data. Het poogt het beste van JSON, XML en YAML te combineren.
• MARK — Dit is een nieuw dataformaat. Ook dit probeert de voordelen van verschillende oudere formaten, zoals JSON, XML en YAML, met elkaar te verenigen.
• MessagePack — Een dataformaat voor de weergave van eenvoudige gegevensstructuren zoals arrays in binaire vorm. Het is vergelijkbaar met JSON, maar geoptimaliseerd voor efficiënte verwerking.
• TOML -Tom’s Obvious, Minimal Language is voor data en configuratie die eenvoudig vanuit verschillende programmeertalen te bewerken is.

Hoewel de bovenstaande formaten in sommige opzichten superieur zijn aan de meer gangbare dataformaten, ontbreken ze vaak in de ondersteuning van programmeertalen, applicatiesystemen en tools.

Nog meer over data

Hier nog enkele begrippen rondom data.

Dataverzameling

Een verzameling data kan enerzijds duiden op gegevens die bij elkaar horen (bijvoorbeeld alle gegevens van een specifieke order), anderzijds kan dit ook de verzameling van alle gegevens betekenen, bijvoorbeeld de orderdata van de laatste jaren.

Databestanden

Wanneer een dataverzameling wordt opgeslagen (meestal in een tekstbestand), dan betreft het een databestand. Een databestand heeft een fysieke plaats op een systeem.

Databerichten

Een databericht is een dataverzameling die onderweg is. Je kunt het het beste vergelijken met een pakket dat onderweg is. Een databericht is meestal onderweg in een netwerk. De inhoud ervan kan vaak als databestand worden opgeslagen en bevat vaak headers, zoals een timestamp of een afzender. Binnen protocollen als HTTP of JMS zijn de bericht headers gestandaardiseerd. Headers zijn als het ware de adressticker op het pakket of de envelop om een brief.

Data interface

Een interface is het snijpunt waar twee componenten samenkomen. Bij een user interface is dat het punt waar de gebruiker de applicatie bedient. Bij een data interface is dat waar twee systemen verbonden zijn. Bij een directe koppeling zit hier geen (of wellicht één) middleware component tussen. Bij ontkoppelde systemen kan de data interface uit vele schakels bestaan. Dit wordt ook wel een data flow of dataproces genoemd. Een data interface is dan het gehele pad van schakels (middleware componenten) waarover databerichten lopen.

Datastandaard

Dit zijn databerichten waarbinnen de velden en structuur zijn gestandaardiseerd, meestal voor een specifiek dataformaat. Bijvoorbeeld het artikelbericht in XML door de standaardisatieorganisatie GS1:

Corporate Data Model

Binnen bedrijven ontstaan vaak allerlei termen waarmee hetzelfde wordt bedoeld, terwijl hetzelfde weer net iets anders betekent. Een Corporate Data Model (CDM) is een standaard manier binnen een organisatie om over data te praten. Wat verstaan we onder “assortiment”. Zijn dit artikelen die we bestellen bij leverancier, die we op voorraad hebben of die we verkopen in de winkel?

Een Corporate Data Model kan data definiëren en zo één manier van communiceren opleveren. Dit principe is ook wel bekend onder de namen Canonical Data Model of Common Data Model. Gelukkig blijft de afkorting dan steeds hetzelfde.

Aangezien de meeste oplossingen vallen of staan bij goede communicatie kan een Corporate Data Model veel opleveren, ook voor ‘communicatie’ tussen systemen. Dit kan het aantal integratiestappen verminderen of een duidelijke tussenvertaalslag maken naar het algemene datamodel.

Een Corporate Data Model kan ook vertragend of bureaucratisch werken, omdat de definities moeten worden opgesteld en onderhouden. Hier geldt dan ook bedenk vooraf goed waar je aan begint. Als er geen data governance in de organisatie aanwezig is en niet aan elke nieuwe integratie tijd wordt besteed, dan kan er beter voor gekozen worden het eerste bronsysteem voor een specifiek datatype leidend te maken.

Middleware

Middleware is software die tussen andere software in staat. Binnen data integratie zijn het de componenten die het berichtenverkeer regelen tussen verschillende applicaties. Het is mogelijk om één middleware component als centraal component tussen alle applicaties te plaatsen. Het is ook mogelijk om meerdere kleinere middleware componenten te gebruiken die decentraal data met elkaar uitwisselen.

Veelal is er een combinatie van centrale en decentrale middleware componenten in gebruik. In dit geval ontstaan er schakels van middleware componenten. Dit is soms nodig omdat elke middleware component zijn eigen functie heeft. Een aantal concepten zie je terug bij meerdere types middleware componenten.

Het meest gangbare type middleware is MOM (Message Orientated Middleware) dat databerichten gebruikt voor uitwisseling en verwerking van gegevens. De meeste brokers, gateways, API’s en ESB’s zijn voorbeelden van message orientated middleware.

The MOM with a message

Middleware concepten

We bespreken de verschillende types middleware in het volgende hoofdstuk. Hier alvast de belangrijkste concepten die je bij de meeste types middleware tegenkomt:

Endpoint

Een endpoint is een bestemming waarop data kan worden geplaatst of vanwaaruit data kan worden opgehaald. Voorbeelden van zulke bestemmingen is een directory, een URL of een queue.

“Endpoint” hoef je niet te letterlijk als “Eindpunt” te nemen. Het kan net zo goed een startpunt van een integratie zijn of ergens midden in een integratie staan.

Quality Of Service

De meeste middleware ondersteunt een “Quality of Service” (QoS). De QoS geeft aan wat de mate van aflevergarantie is. Bekende niveaus zijn:

• Exactly once
• At least once
• Best Effort

Exactly once geeft aan dat er precies één bericht wordt afgeleverd, terwijl het bij At least once kan voorkomen dat een bericht twee keer wordt afgeleverd. Meestal is Exactly once het wenselijke niveau. Dit niveau komt echter wel met een performance trade off. Hoe hoger de QoS, des te meer checks het middleware component moet doen om deze garantie waar te kunnen maken. De verwerkingssnelheid is daarom lager.

In verschillende middleware zoals brokers of een ESB kan de QoS worden ingesteld, andere middleware zoals FTP Servers of REST API’s kennen het concept weer niet.

Fire and Forget

Een middleware component kan op verschillende manieren worden aangeroepen. De eenvoudigste is Fire and Forget. Dit betekent dat de producer van de data het databericht verstuurt, maar verder geen terugkoppeling verwacht.

Je ziet dit vooral met event-driven systemen. Er is bijvoorbeeld een wijziging aangebracht in een systeem. Een nieuwe taart is opgevoerd als artikel. Het systeem geeft dit door aan een middleware component en is dan klaar. Wellicht dat de data bij verschillende andere systemen terecht komt, misschien gebeurt er niets mee, misschien gaat het ergens fout. Voor het versturende systeem maakt het allemaal niet uit.

Het kan nog wel zijn dat er bevestiging van de middleware komt dat deze het bericht ontvangen heeft, maar er komt geen direct inhoudelijk antwoord. Fire-And-Forget zie je soms onder verschillende namen, zoals:

• Fire-And-Forget
• Event
• One-Way
• InOnly

Request-and-Reply

Bij Request-and-Reply wordt er altijd een antwoord verwacht. De applicatie die het bericht verstuurt kan een officiële bevestiging terug krijgen dat het bericht door de ontvanger is verwerkt. Het kan ook zijn dat de producer van het bericht maar een zeer beperkt aantal gegevens heeft. In dit geval doet hij een verzoek voor meer gegevens en in de response ontvangt hij deze.

Synchroon vs Asynchroon

Er zijn twee manieren waarop berichten worden afgehandeld bij Request and-Reply. Bij synchroon wordt gewacht op het antwoord (response). Je ziet dit vooral bij webapplicaties. Iemand drukt op een website op de knop “betalen”, het bericht gaat naar de backend en als de betaling voldaan is komt er een reply. De gebruiker heeft de taart betaald.

Bij asynchroon wordt er niet gewacht op het antwoord. Stel: je wilt weten waar de taart het goedkoopste is en surft naar een vergelijkingssite. Deze website doet een verzoek bij drie verschillende externe partijen. Wellicht krijgt de website geen antwoord (of niet snel genoeg) van de eerste website, maar wel van de tweede en derde. In dit geval kan hij die laatste twee al tonen op de website.

Transacties

Een transactie geeft aan dat een bewerking in zijn geheel moet worden uitgevoerd. Stel: een databericht gaat langs meerdere middleware componenten totdat deze bij de consumer komt. Het geheel van alle stappen van bron tot eindpunt wordt dan beschouwd als één transactie.

Kenmerkend is dat als er ergens in het proces iets fout gaat, alles weer terug naar het beginpunt wordt hersteld (Roll-Back). Net als een hoge Quality-of-Service kan transactionele integratie veel resources vergen.

4. De belangrijkste integratieconcepten

Inhoudsopgave:

Raymond Meester

Data Integratie

View list

21 stories