Dit artikel is onderdeel van de themareeks BI-Tooltips, bedoeld om interessante nieuwsfeiten en gebruikstips voor specifieke BI-Tools te publiceren. Deze tooltip behandelt enkele aandachtsgebieden bij het gebruik van Ab Initio’s Continuous Flows voor (near) real-time oplossingen.
Ab Initio Continuous Flows
In de ‘traditionele‘ BI-omgeving vindt dataverwerking meestal plaats in batch vorm, waarbij grote hoeveelheden gegevens worden verzameld en in één keer worden verwerkt (in het algemeen ’s nachts of in het weekend). Steeds vaker is er vanuit onze klanten echter behoefte aan actuelere gegevens en informatie die constant up-to-date is.
Ab Initio biedt, op hetzelfde platform als hun batch oplossingen, ook real-time mogelijkheden in de vorm van Continuous Flows. Hierbij komt data binnen als een min of meer continue stroom van kleine datapakketjes of zelfs losse records (bijvoorbeeld op een queue) en wordt vrijwel direct verwerkt. Toepassingen hiervoor zijn allerhande operationele processen, bijvoorbeeld OLTP, maar dus ook real-time BI.
Een bijkomend voordeel is - naast de actualiteit van de data - dat de workload van de verwerking op deze manier verspreid wordt over de tijd, waardoor de server niet gedimensioneerd hoeft te zijn op de piekbelasting die vaak optreedt tijdens een batch window.
Ook voor het creëren van applicaties die een service aanbieden en daarom constant in de lucht moeten zijn (denk aan webservices), kunnen Continuous Flows gebruikt worden.
Een voorbeeld uit de praktijk: de Message Broker
Onlangs werd er bij een relatie van FourPoints een nieuw Microsoft Dynamics CRM systeem geïmplementeerd. Aan ons de taak om deze nieuwe applicatie te integreren in het reeds bestaande applicatielandschap, waarbij het noodzakelijk was om met de andere (legacy) systemen data uit te wisselen, in casu klant- en productgegevens.
Voor deze applicatie-interactie is met behulp van Ab Initio’s Continuous Flows een ‘Message Broker’ gebouwd; een flexibel systeem volgens een Hub-and-Spoke architectuur voor het routeren van datapakketjes van en naar verschillende applicaties. De Message Broker wordt ook gebruikt om bronnen te ontsluiten die real-time data aanleveren en om applicaties te voeden met live data, zoals in dit geval een website waar de klanten van onze relatie kunnen inloggen om hun gegevens te bekijken.
Implementatie
De Ab Initio implementatie van deze centrale integratie hub bestaat uit één continuous flow die constant luistert naar een input queue. Binnenkomende XML messages worden opgepikt en afhankelijk van het type message doorgestuurd naar één of meerdere micrographs. In deze micrographs vinden de validaties, transformaties en business ruling plaats die specifiek zijn voor het type message. Vervolgens wordt de output hiervan beschikbaar gesteld aan de relevante ontvangende systemen. Dit kan op verschillende manieren, zoals via XML messages op een output queue of in het geval van MS Dynamics, via webservices (SOAP en REST).
Het systeem is daarbij zo generiek en flexibel mogelijk opgezet, zodat het in de toekomst gemakkelijk uit te breiden is met bijvoorbeeld andere message types, of nieuwe senders en receivers. In principe kan het gebruikt worden om willekeurige gegevens in allerlei business areas binnen de organisatie te distribueren.
Aandachtsgebieden
De klassieke batch-verwerking is vaak een kwestie van alles of niets: als er één record in een inputbestand een fout oplevert, wordt het hele bestand gereject om wellicht na correctie later opnieuw in z’n geheel verwerkt te worden. Continue processen daarentegen moeten constant in de lucht blijven en in staat zijn om direct weer het volgende input request te verwerken. Er is geen rollback mogelijk. Vaak zijn er meerdere bronnen die soms niet allemaal even betrouwbaar zijn.
Vanwege dit verschil in karakter, deel ik hieronder enkele punten om extra op te letten bij data integratie implementaties met Continuous Flows:
- Besteed zo vroeg mogelijk in het proces aandacht aan data validatie (en eventueel reparatie en cleansing).
- Zorg voor robuuste graphs, bijvoorbeeld door de 'never abort' optie te gebruiken in transform componenten, met goede reject- en error-handling. Vooral het doorgeven van errors vanuit een micrograph naar de bijbehorende continue graph behoeft aandacht.
- Het moet op een eenvoudige manier mogelijk zijn om de afgekeurde records opnieuw aan te bieden. Er mag geen data verloren gaan. Rejects kunnen bijvoorbeeld worden verzameld en (eventueel na editing) opnieuw op de queue worden gezet als ‘re-injection’ message.
- Via hetzelfde mechanisme kan een testfaciliteit worden opgezet of een manier om ‘handmatig’ records of bestanden op te laden.
- Zorg voor goede logging en tracking van messages binnen de flow, zodat altijd nagegaan kan worden waar en waarom een message eventueel is gestrand.
- Gebruik een configuratie database voor de aansturing van je proces. Op deze manier is het systeem onderhoudbaar (eventueel door de business zelf) en hoeft het niet telkens uit de lucht gehaald te worden bij elke aanpassing.
- Continue graphs zijn in principe niet geschikt om in één keer grote hoeveelheden data te laden, terwijl een initial load soms wel noodzakelijk is. Het is dan het beste om daar een aparte batch graph voor te maken. Zorg ervoor dat de bestaande business logic herbruikbaar is in deze batches.
Heb jij nog andere aandachtspunten voor het gebruik van Continuous Flows?
Dit artikel is geschreven door: Arjen Bakker, Ab Initio expert