2. Data in motion

Wat is data integratie?

Aleksandra is gevlucht naar Nederland. Eenmaal aangekomen moet zij zelf haar weg weten te vinden. Hoe leer ik de taal? Wat zijn de wetten en regels? Hoe ga ik met de buren om? Zij doet na verloop van tijd wellicht een inburgeringscursus, maar ze doet het integreren vooral zelf. Ze past zich aan de samenleving aan en als er veel ‘vreemden’ zijn, past de samenleving zich vervolgens ook aan de nieuwkomers aan.

Als je aan integratie denkt, dan denk je waarschijnlijk aan buitenlanders die integreren in de Nederlandse samenleving. Hoewel hier veel debat en zorgen over zijn, zijn mensen wat integratie betreft heel flexibel.

Wanneer we spreken van integratie tussen systemen, dan is dit helemaal niet zo flexibel. Stel: je zet programmatuur uit het ene systeem in het andere, dan zal het systeem onmiddellijk vastlopen. Bij programmatuur luistert dit namelijk ontzettend nauw, één vreemd teken kan een applicatie al laten vastlopen. Twee verschillende systemen, bijvoorbeeld AFAS en SAP, kunnen dus niet op magische wijze met elkaar samenwerken.

Bij data integratie is er daarom altijd een brug nodig. Het kan heel specifiek betekenen dat een extern component geïntegreerd wordt, zodat het als één systeem te gebruiken is. In brede zin spreken we over alle overbruggingstechnieken om data met elkaar uit te wisselen.

Soms wordt er naast data integratie ook wel over systeem- of applicatie-integratie gesproken. In dit boek is het idee de nadruk op data te leggen en niet op de systemen of applicaties die de bron of ontvangers van de data zijn.

Datastromen

Het belangrijkste kenmerk van data integratie is, dat er altijd sprake is van dataverkeer tussen componenten. Een component is een systeem, een database, een service, enzovoort. Als data tussen zulke componenten stroomt, spreekt men in het Engels ook wel over Data in motion of Data in transit. Er zijn drie manieren waarop data tussen componenten kan stromen:

1. versturen

A --> B

2. ophalen

B <-- A

3. interactie

A <--> B

Waarom data integratie?

Aleksandra woont inmiddels een paar weken in Zaandam. Haar buurman Thomas is jarig en ze is er eerder al achter gekomen dat hij gek op appeltaart is. Bakken is één van de hobby’s die ze al in Oekraïne had. Haar zus zei zelfs tegen haar: “je zou een eigen bedrijf moeten starten”. Thomas zal het allemaal een worst wezen, hij geniet met volle teugen van de door Aleksandra gebakken appeltaart.

Wat heeft dit nu met integratie te maken? Ja, de buren hebben contact met elkaar en Aleksandra ‘integreert’ de ingrediënten tot een taart? De analogie met data integratie is dat er iets van van A naar B gaat, namelijk de taart:

Aleksandra --> Taart --> Thomas

Als de taart in de oven is, staat hij stil, maar als Aleksandra de taart naar haar buurman brengt, is hij onderweg. Zodra de taart bij Thomas op tafel is, staat hij weer stil. Bij data integratie gaat er natuurlijk geen taart, maar data van A naar B:

A --> data --> B

Zolang de data nog in applicatie A is, is de data in rest, maar zodra uitwisseling tussen componenten plaatsvindt, is de data in motion. Aangezien applicatie A de data maakt, wordt deze ook wel de producer genoemd en applicatie B, die de data ontvangt, de consumer.

Producer --> Data --> Consumer

Push & Pull

Er zijn dus drie manieren van integreren, namelijk versturen, ophalen en interactie.

Aleksandra kan zelf het initiatief nemen, omdat ze weet dat Thomas appeltaart lekker vindt en brengt de taart naar hem toe. In het geval van sturen spreken we van een push-mechanisme. Het kan ook zijn dat Thomas de taart ophaalt. In dat geval spreken we van een pull-mechanisme.

Er kan ook overleg ontstaan, zo kan Aleksandra vragen of hij van appeltaart houdt en als die bevestiging er is, kan ze taart gaan bakken en een appje sturen als deze klaar is. Thomas kan tenslotte de taart ophalen en de buurvrouw bedanken (als de taart lekker is tenminste). Dit is een interactie.

Nu is er bij mensen iets bijzonders aan de hand. Het zijn sociale wezens. Aleksandra is op de hoogte van wat Thomas lekker vindt. Bij systemen is dit niet zo. Data-overdracht moet geïnitieerd worden. Bij push is de producer de initiator van dataoverdracht, bij pull de consumer.

Ontkoppeling: direct versus indirect

Inmiddels kennen Thomas en Aleksandra elkaar al erg goed. Ze wonen naast elkaar. Aleksandra heeft niemand nodig om de taart naar de buurman te brengen. In 10 seconden staat ze al voor zijn deur. En Thomas herkent haar al aan het klopje op het raam.

Bij data integratie geldt hetzelfde principe. Stel: je hebt twee applicaties in het bedrijf. Dan kun je die betrekkelijk makkelijk met elkaar verbinden. Je hebt geen extra tools nodig, dit gaat direct.

Maar hoe is het nu met de ingrediënten van de taart? Aleksandra is niet allerlei boeren langsgegaan om appels, graan en suiker te halen. De graanboeren leveren graan aan de fabrikant die er meel van maakt en die brengt dat weer naar het distributiecentrum, waarna een vrachtwagen het tenslotte samen met de appels en suiker bij de supermarkt aflevert. Daar koopt ze alle benodigdheden voor haar taart. Er zitten dus tussen boer en consument allerlei logistieke schakels.

In het geval van data integratie zijn er allerlei schakels bedacht, die uitvoerig in de volgende hoofdstukken besproken worden. Deze schakels worden “middleware” genoemd. Dit kunnen zowel schakels op technisch als op functioneel niveau zijn. Het centrale punt is dat producer en consumer van elkaar worden ontkoppeld, zodat applicaties een deel van de distributie van data kunnen uitbesteden.

Waarom niet gewoon direct?

In 2011 onderzocht Het Parool het imago van de makelaar. Dat was niet al te best: een snelle jongen in pak op een scooter met te hoge provisies, een arrogante houding en gebrekkige kennis. De beroepsgroep is, zo is het idee, eigenlijk overbodig.

Tegenwoordig is het imago niet veel beter, maar makelaars worden nog altijd ingeschakeld. In de praktijk is het kopen van een huis toch vaak een emotionele aangelegenheid. Makelaars leiden dit in goede banen. Ze fungeren als intermediair, in het Engels “brokers”. Ze kennen de lokale markt, stellen de prijs vast, regelen de administratie, enzovoort.

Bij data integratie kun je ook brokers tussen applicaties zetten. En ook hier kan het idee van overhead ontstaan. Uiteindelijk moet toch alleen een bestandje van A naar B?

In de praktijk komt er toch vaak meer bij kijken. Stel applicatie A zet bestanden neer in een map en applicatie B heeft een script die deze bestanden ophaalt en inleest. Het script is speciaal gemaakt voor deze data interface. Dat betekent dat er een afspraak is gemaakt over de directory, de naam van het bestand en het script converteert het bestand naar iets wat applicatie B begrijpt. In de praktijk wordt vaak aan één kant maatwerk geleverd om de systemen op elkaar af te stemmen.

Al met al is het de meest intuïtieve weg om in een rechtstreekse lijn van A naar B te gaan. Maar dit is één interface tussen twee applicaties. Als de omgeving slechts een paar applicaties kent die enkele bestanden uitwisselen is hier niets mis mee. Maar wat gebeurt er als het aantal applicaties, koppelingen en gegevens groeit?

In dat geval worden de datastromen al snel één spaghetti. Hieronder een stuk uit de documentatie van de integratie module Assimbly over de problemen die dan ontstaan:

When you want to integrate two systems, you soon find out that integration was an afterthought. This is because applications are designed with one main function in mind.

For example an application created for customer relation management is designed around managing customers. The designer creates a datamodel that matches exactly the needed business functionality. All technological components like the database and code are derived from this main function. Mostly the focus is hereby on one interface: The user interface. This is all logical, but what if another application needs some customer related data as well?

When it’s still easy…

A webshop has another function with other business needs. That’s why its data model is completely different from the CRM system. Now both have no well-defined data interface, so how do we exchange data? What mostly is done that in one of the applications some custom module is created. This module acts as a bridge between the two data models.

Another aspect is that the data needs to be transported from one application to another. In this case the CRM system could have a daily export to a fileshare on the webshop server. The custom module of the webshop can now import the exported data into its database.

So one custom module and a fileshare needed to be created, so what the problem?

More possibilities

In our example we have two systems and one type of message. What when there is another system that manages data like articles and prices. This data should also go to the webshop. But there is also a warehouse management system that needs this data. And the webshop orders should go to warehouse management system and update customer data should go back to the CRM system. All of these data should be sent to an analytics platform. With every messagetype, every system, more possibilities arise. In the first example we have only one flow, but in second example we already have 11 flows.

More systems, more message types mean more possible flows. It’s impossible (and just too much work) to create custom modules every time. Besides using file shares aren’t safe and don’t scale.

Waarom data integratie?

Als we het voorgaande nader beschouwen zien we dat er bij het integreren van systemen via directe koppelingen de volgende zeven problemen ontstaan:

1. Interoperabiliteit

Er zijn tientallen programmeertalen, applicaties en bestandsformaten. Sommige zijn oud en andere zijn nieuw. Het is vaak onmogelijk deze allemaal op elkaar af te stemmen. Gelukkig zijn er enkele protocollen, zoals HTTPS, TCP, FTP die dit vereenvoudigen.

Ook zijn er meerdere bericht- en dataformaten om gegevens in te transporteren. Maar moet een applicatie die allemaal ondersteunen? De meeste applicaties, zeker de standaardapplicaties, ondersteunen slechts één protocol en dan moet je het zelf maar uit zoeken als deze niet matcht met de andere kant.

2. Overzichtelijkheid

Omdat elke applicatie technologisch uniek is, is het vrijwel onmogelijk om directe koppelingen te standaardiseren. Er wordt telkens een nieuwe verbinding gebouwd. Mensen vertrekken, infrastructuur en het applicatielandschap verandert. Op een gegeven moment is de vraag: wat is precies verbonden met wat? Dit staat ook wel bekend als het spaghetti-probleem.

3. Afhankelijkheid

Bedrijven maken van oudsher gebruik van applicaties on premise. Daarnaast draaien er applicaties in de cloud en zijn ze verbonden met externe applicaties. De ene applicatie kan sneller data verwerken dan de andere. Ook kan een applicatie tijdelijk offline zijn. Koppel je direct, dan zijn de gevolgen ook direct merkbaar. Bijvoorbeeld dat het versturende systeem zijn data niet kwijt kan.

4. Schaalbaarheid

Zodra de hoeveelheid uit te wisselen data groeit, wil je er modules bij kunnen plaatsen. Zo heb je meer ‘handjes’ om de grotere datastromen te kunnen verwerken.

5. Veiligheid

Bij de uitwisseling van berichten met derden via het internet, maar ook binnen de organisatie is veiligheid van belang. In de berichten staat soms concurrentie- of privacy-gevoelige informatie. Hoe veilig is dit via een directe koppeling? Is hier überhaupt wel rekening mee gehouden?

6. Reactiviteit

Er zijn veel gebeurtenissen in een applicatie. Denk aan het verwijderen of aanmaken van een order. Soms dient ook een derde applicatie hiervan op de hoogte zijn. Mechanismen die op gebeurtenissen reageren worden reactief genoemd.

Naast normale gebeurtenissen (de happy flow), zijn er ook altijd gebeurtenissen die mis kunnen gaan. We hebben al gesproken over systemen die offline kunnen gaan, maar er zijn ook andere gebeurtenissen die kunnen voorvallen. Plotseling veel data binnenkrijgen of de data is in heel ander formaat als verwacht. Hoe zorg je dan dit niet teveel impact heeft?

7. Maatwerk

Om systemen op elkaar af te stemmen is er vaak maatwerk nodig. In het voorbeeld is er één ontvanger van data, maar wat als er nog een paar bij komen? Dan zijn er telkens kopieën nodig. Dit is nog wel te doen, maar elke ontvanger heeft zijn eigen eisen en wensen, die vaak terug te voeren zijn op de functie van de applicatie.

Hoe ga je zorgen dat elke applicatie precies datgene krijgt wat hij nodig heeft? De oplossing is maatwerk, waardoor het bouwen van integraties langdurige trajecten worden. In de applicatie krijg je dan vaak logica van andere applicaties.

Om met deze 7 problemen om te gaan zijn er allerlei software-oplossingen bedacht. Er zijn bij data integratie technische en functionele oplossingen.

Technische integratie

Er zijn veel oplossingen om goederen te verplaatsen. Dit kan bijvoorbeeld per vliegtuig, trein of schip. Ook hebben we kranen en vorkheftrucks om goederen op de vervoersmiddelen te plaatsen. Kenmerkend is dat ze niets met de inhoud van de goederen doen, ze verplaatsen die alleen en zorgen dat de afstand wordt overbrugd. Kortom: dit zijn transportmiddelen.

Transportmiddelen zijn vrij praktisch. Je kunt namelijk pakketjes in de zee gooien, maar de kans is dan groter dat het zinkt dan dat het op de plaats van bestemming aan komt. Een containerschip vaart gelukkig (meestal) netjes de oceaan over van Singapore via het Suezkanaal naar Rotterdam. In de haven vindt er overslag plaats, de goederen blijven dan tijdelijk in een magazijn waarna ze naar de uiteindelijke plaats van bestemming worden getransporteerd.

Als er niets met de inhoud van data gebeurt dan spreken we van technische integratie. Er wordt gezorgd dat data van A naar B komt.

Net zoals dat er tussen Singapore en Rotterdam een grote oceaan ligt, zijn er tussen applicaties ook vaak barrières. Er zijn namelijk enorm veel technologieën die niet goed op elkaar aansluiten.

Gelukkig zijn er allerlei protocollen bedacht die dit overbruggen. Een bekende is FTP (File Transfer Protocol). Als applicatie A een bestand neerzet op een FTP-directory, kan een andere applicatie daar de data ophalen. De barrière is geslecht.

Adaptoren

Technische integratie is echter niet altijd zo eenvoudig. Stel: applicatie A is een legacy-systeem dat op een mainframe draait. Elke nacht om 01.00 uur zet het duizenden bestanden klaar in een FTP-directory. Applicatie B is een webapplicatie in de cloud. Hoe gaan deze applicaties nu data met elkaar uitwisselen?

Applicatie A plaatst berichten dus op een FTP-locatie. Daarentegen biedt applicatie B een REST API aan. Er zijn dus wel integratieprotocollen beschikbaar, namelijk FTP en REST (HTTP), maar deze matchen niet. Er is dan een extra integratiemodule nodig.

Bij data integratie kan een module tussen applicatie A en B worden geplaatst:

A (FTP) --> Integratie Module (Adapter) --> B (HTTP)

Deze adaptor is de brug tussen de twee protocollen, zodat de applicaties toch gegevens kunnen uitwisselen. Deze functionaliteit wordt vaak een adapter genoemd. In dit geval een FTP-naar-HTTP-adapter.

De rol van de adaptor is die van een kraan die containers van het containerschip op de havenkant plaatst. Daar worden ze vervolgens tijdelijk opgeslagen, waarna ze weer verder wordt vervoerd door een vrachtwagen.

Tijdelijke opslag

Nu zet applicatie A de bestanden ’s nachts in één keer neer. Wat als de ontvangende applicatie even niet beschikbaar is of de bestanden niet zo snel kan verwerken? In dat geval kan er een buffer (tijdelijke opslag) tussen worden geplaatst:

A (FTP) --> Integratie Module (Adapter) --> Integratie Module (Buffer) --> Integratie Module (Adapter) B (HTTP)

Net als bij logistieke distributie kunnen er meerdere schakels tussen producer en consumer worden geplaatst.

Functionele integratie

Wanneer goederen de haven binnenkomen, dienen ze eerst te worden geklaard door de douane. De douane kijkt of alle papieren in orde zijn en of deze overeenkomen met de goederen in de container. Ze houden zich dus echt bezig met de inhoud van de goederen.

Bij functionele integratie is dit altijd het geval. Dit kan net als bij de douane een controle zijn: Is de data volledig? Is het formaat volgens afspraak geleverd? Het kan ook een stap verder gaan. Bijvoorbeeld door data aan te vullen of weg te laten. Als de douane iets met de inhoud doet, is dat meestal niet geoorloofd. Bij functionele integratie is ingrijpen juist wel geoorloofd, het overbruggen van functionaliteit is juist de bedoeling.

Er zijn veel manieren van functionele integratie, zoals

• filteren
• splitsen
• converteren
• verrijken
• transformeren
• valideren
• routeren

We bespreken elke vorm in detail:

Filteren

Bij filteren worden soms velden of zelfs het gehele bericht niet doorgestuurd. Denk bijvoorbeeld aan artikelberichten van een supermarkt. Zo zijn weegschalen ontvangers van artikelgegevens. Er kan een filter in de integratie worden gezet, zodat alleen “groente en fruit”-artikelinformatie naar de weegschalen wordt doorgestuurd.

Splitsen

Bij splitsen wordt één bericht in meerdere opgedeeld. Dit kan zowel vanuit technisch als functioneel oogpunt gebeuren. Een voorbeeld is dat de bron met artikelinformatie, alle artikelen van het assortiment in één bericht plaatst, maar de ontvanger uitgaat van één artikel per bericht. In dit geval kan het assortiment worden opgesplitst in afzonderlijke artikelen.

Converteren

Databerichten kunnen worden geconverteerd. Converteren betreft de omzetting van een data formaat naar een specifiek ander formaat, bijvoorbeeld van XML naar JSON.

Verrijken

Een verrijking betekent dat data van aanvullende data uit een extern systeem wordt voorzien. Bijvoorbeeld: applicatie A verstuurt een bericht met artikeldata naar applicatie B. Het bericht bevat 95 % van de gegevens, maar mist nog data die in een applicatie C staat. Het is mogelijk twee berichten naar de ontvanger sturen. Dus één bericht met data van applicatie A en één bericht van applicatie C, waarna applicatie B deze zal moeten samenvoegen. Je kunt ook het bericht van applicatie A verrijken met extra data van applicatie C in de integratie. In dit geval krijgt applicatie B één compleet bericht.

Transformeren

Bij transformeren wordt over het algemeen verstaan het omzetten van de structuur en inhoud van één bericht naar een bericht met een andere structuur en inhoud. Dit kan technische redenen hebben: de ontvanger verwacht alle velden in hoofdletters en in een andere volgorde. Maar het kan ook inhoudelijk redenen hebben: de ontvanger verwacht een andere berichtstructuur of -benamingen. Dit wordt ook wel data mapping genoemd.

Valideren

Bij valideren wordt gecontroleerd of een bericht geldig is. Meestal wordt eerst een schema opgesteld dat een bericht een bepaalde structuur geeft en eisen aan velden stelt. Als een bericht niet aan deze eisen voldoet, wordt het meestal afgekeurd en niet verder doorgestuurd.

Routeren

Een bericht routeren is de route bepalen van een bericht. Bijvoorbeeld berichten van type X worden alleen gestuurd naar applicatie C en D, maar type Y ook nog naar applicatie E.

Enterprise Integration Patterns

We hebben nu de meest gangbare integratiepatronen beschreven. Er zijn er echter veel meer. Vijfenzestig daarvan zijn vastgelegd door Gregor Hohpe en Bobby Woolf in het boek Enterprise Integration Patterns (2003). Ze zijn onderverdeeld in negen categorieën:

Zoals te zien is, vallen verrijken (enrichment) en valideren in de categorie “Message Transformation”. In de praktijk worden sommige termen tegenwoordig anders gebruikt. Transformeren duidt meestal op het converteren of mappen van data.

Veel van deze integratie patterns (soms onder een wat andere naam) zijn geïmplementeerd in integratie frameworks of platforms. Het Java integratie framework Apache Camel implementeert deze patterns bijvoorbeeld relatief strikt.

Integratieplatform

Net zoals er niet slechts één vervoermiddel is voor alle logistieke vraagstukken, zo is er ook niet één integratiecomponent de oplossing voor alle integratievraagstukken. Er zijn wel integratiecomponenten die als product in de markt worden gezet, maar dat is vaak maar één schakel in een totaaloplossing.

Vaak zie je dat zulke producten samengevoegd worden tot een product suite. Is zo’n totaaloplossing geïmplementeerd bij een organisatie dan noemen we dit een integratieplatform.

Een integratieplatform is een verzamelnaam voor een product suite waarmee integratievraagstukken kunnen worden opgelost. Dit kunnen zowel technische als functionele integratie vraagstukken zijn.

Vaak zie je dat bij een volwassen platform meerdere middleware componenten worden aangeboden. Wat deze meeste integratie suites kenmerkt, is dat het zowel middelen bevat voor het maken van integraties (design time) als voor het draaien van integraties (run time).

Toch is integratieplatform een breed begrip; welke componenten en technieken er worden gebruikt is per softwareleverancier zeer verschillend. De combinatie van componenten is vaak wat een integratieplatform uniek maakt en onderscheidt van de concurrenten.

Type integratieplatformen

Integratie bestaat uiteraard al zolang er systemen zijn, maar echte integratieplatformen zijn pas opgekomen met het ontstaan van applicatielandschappen. De eerste integratieplatformen zijn vooral gecreëerd door softwarebedrijven die commerciële software maakten.

Hier zie je al in de jaren negentig een beweging naar toe, bedoeld om voornamelijk on premise in een applicatielandschap te draaien. Aangezien ze al langere tijd bestaan, hebben ze componenten voor een veeltal aan integratievraagstukken met goede ondersteuning aan technologieën en protocollen.

Later ontstonden er ook open source-alternatieven. Deze waren lange tijd niet op het niveau van andere open source-projecten, zoals Linux of MySQL. Meestal betrof het één specifiek middleware component, zoals een adapter of een broker, het waren nog niet echt platformen. De laatste vijf jaar zie je dat er verschillende open source-spelers zijn die volwassen integratieproducten aanbieden (denk aan Mule, Red Hat, WS02 en Talend).

Een andere beweging is het integratieplatform als cloudoplossing. Dit is ook wel bekend onder de naam iPaaS (integration Platform as a Service). Het integratieplatform met verschillende componenten wordt als cloud- applicatie beschikbaar gesteld. Vooral bij bedrijven die een cloudstrategie hebben, zie je dat deze platformen aan populariteit winnen.

3. Data: het nieuwe goud

Inhoudsopgave:

Raymond Meester

Data Integratie

View list

21 stories