Download dit artikel als pdf
Microsoft BizTalk Server is de tool om integraties tussen verschillende systemen en applicaties te versimpelen. Maar waarom zijn BizTalk implementaties zelf dan niet zo eenvoudig? De complexiteit blijkt vaak niet in de tool te zitten, maar veelal in keuzes op het vlak van architectuur en organisatie. Welke overwegingen zijn er en wat is hierbij belangrijk? In dit artikel gaan we in op de complexe vraagstukken die zich voordoen bij BizTalk implementaties en hoe deze beheersbaar gehouden kunnen worden.
Microsoft BizTalk Server is een zeer compleet product met meer dan twintig adapters die organisaties in staat stellen applicaties met verschillende systemen (bijvoorbeeld Peoplesoft, SAP, Oracle, IBM Mainframes) te integreren waarbij diverse communicatie protocollen (http, FTP, SOAP, POP3) worden ondersteund. Doordat BizTalk zo’n uitgebreid product is, zijn er vele mogelijkheden om applicaties met elkaar te integreren, zeker als er binnen een organisatie hoofdzakelijk voor Microsoft technologie is gekozen.
Belangrijk uitgangspunt blijft echter wel vooraf zorgvuldig te onderzoeken welke opties het beste passen bij de betreffende integratie uitdaging, dit zorgt ervoor dat de uiteindelijke doelen (minder kosten, betere beheersbaarheid en meer flexibiliteit) ook echt gehaald gaan worden. In alle fase van het project zijn deze keuzes belangrijk, zowel in de architectuur, de daadwerkelijke procesimplementatie als in de manier van beheren.
Architecturele keuzes
Hoe kan BizTalk optimaal binnen een bestaande architectuur worden ingezet? Voor welke keuzes komt een organisatie te staan en waar moet rekening mee gehouden worden nu met de komst van BizTalk Server 2009 ook voor BizTalk als Enterprise Service Bus (ESB) gekozen kan worden.
Om goede keuzes te maken is het belangrijk om het berichtenverkeer inzichtelijk te krijgen. Welke systemen moeten met welke systemen praten en gaat dit wel of niet via BizTalk verlopen. Hierbij speelt het aantal verschillende systemen en de hoeveelheid van type berichten een belangrijke rol.
Keep it simple
Keep it simple blijft ook hier van kracht. Zijn er maar een paar systemen of gaat het om enkele simpele synchrone interacties, dan is een point–to-point opzet waarschijnlijk nog steeds het meest efficiënt. In deze situatie is een broker of ESB veel te zwaar. Wanneer dit groeit, is hierbij wel lastig dat als er iedere keer een uitbreiding komt, deze uitbreiding op zich vaak weer te klein is om op basis daarvan te besluiten een broker in te zetten. Het gevaar van versplintering ligt daarmee toch altijd op de loer.
Broker of ESB
Een broker organiseert het aantal koppelingen beter en integratie krijgt daarmee een centrale plek in de architectuur en development, maar vermindert het aantal verbindingen niet. Bij een broker moeten alle combinaties uiteindelijk allemaal wel worden geprogrammeerd.
De Enterprise Service Bus (ESB) is de volgende stap waar op basis van configuratie wordt gewerkt en daarmee ook daadwerkelijk het aantal koppelingen wordt gereduceerd. Voor welke te kiezen hangt af van het groeipad dat voorzien wordt in het aantal integraties tussen systemen. Het rechttoe rechtaan mechanisme van een broker is makkelijk te doorgronden voor diegene die ermee moeten werken terwijl wijzigingen in een ESB veel sneller zijn door te voeren.
Wel of niet werken met een Canonical Data Model (CDM)
Het transformeren van het ene berichtenformaat naar het andere is een groot deel van het werk bij integratieprojecten. Zeker bij veel systemen of zelfs groepen van organisaties die samenwerken is dit een aspect waar goed over nagedacht moet worden. Uiteindelijk is een situatie wenselijk waar transformaties tot een minimum worden beperkt. Een canonical datamodel (centraal metamodel) kan hier voordelen bieden. Hierdoor hoeft er maar naar één model te worden getransformeerd per systeem. Dit geeft ook de mogelijkheid om de verantwoordelijkheid hiervoor te beleggen bij de aanleverende en afnemende systemen. Het beleggen van de verantwoordelijkheid voor deze translaties bij de aansluitende systemen biedt beheer- en dus kostenvoordelen als er sprake is van veel systemen of veel ingekochte functionaliteit. Door ook leveranciers hierop te selecteren die standaarden zoals het All Finance Datamodel of HL7 ondersteunen kan bespaard worden op één van de belangrijkste cost drivers van geïntegreerde oplossingen.
------------------------------------------------------------
Referentie
Macaw werkt mee aan een gemeenschappelijke service omgeving (GSO) voor vier gemeenten. Deze omgeving heeft als primaire doel het consolideren en opschonen van gemeenschappelijke data die binnen verschillende systemen wordt bewaard. Dit verhoogt de datakwaliteit en wordt voorkomen dat dezelfde informatie niet meerdere keren ingevoerd hoeft te worden.
Het bijzondere is dat er ook een Software as a Service (SaaS) aspect aanwezig is. Namelijk, elk van de vier gemeenten draait in een eigen (dedicated) omgeving terwijl er wel een centrale instantie is waar alle berichten op binnen komen. Deze mengeling van gezamenlijke en (fysiek) gescheiden componenten introduceert unieke “kansen”. Hier vanuit ontstaat dan ook de behoefte om vergaande beveiligingsfunctionaliteiten te implementeren ten aanzien van het uitdelen van rechten.
Voor dit project is de Enterprise Service Bus (ESB) van BizTalk ingezet om het berichtenverkeer tussen service consumers en service providers te ontkoppelen. Tevens biedt de ESB een aantal services waardoor andere service- of applicatiecomponenten - of tijdens het routeren van berichten – hiervan gebruik kunnen maken. De transformatieservices kunnen contract (versie) verschillen oplossen, de error service logt centraal alle foutboodschappen welke in een management console kunnen worden bekeken en de authorisatie (en authenticatie) service regelt op een centraal niveau toegang tot de door de services geboden functionaliteit.
------------------------------------------------------------
Realisatie
Goed, de architect heeft zijn keuze gemaakt en het project begint op gang te komen. De BizTalk developer gaat aan de slag en begint met de procesontwerpen die gemaakt zijn. De uitdaging waar de specialist voor staat is het definiëren van een proces. Maken we een verzameling kleine processen die samengevoegd moeten worden of kiezen we ervoor om toch wat grotere processen in één keer te modelleren in een orchestratie?
Long running processen
Echte long running processen hebben hier toch echt nadelen. Sommige processen (zie voorbeeld) lopen zo lang dat het werkelijke bedrijfsproces al een paar keer veranderd is voor het proces is afgelopen. Dit gaat ten koste van de flexibiliteit. Wat doe je immers met wijzigingen op processen die reeds lopen? BizTalk biedt vele mogelijkheden om dit te doen, maar de zogenaamde granulariteit voor de processen juist kiezen zodat processen nog wel als bedrijfsprocessen te herkennen zijn, maar niet onhandelbaar groot worden, blijft één van de lastigste keuzes.
Voorbeeld long running proces
Bij een uitkeringsinstantie werd gekeken naar langlopende processen. Hier wilde men het hele uitkeringsproces zien als één langlopend proces. Dat betekent dus iemand vraagt een uitkering aan en in het uiterste geval zou dat kunnen betekenen dat het proces voor meer dan 20 jaar blijft lopen. Dat is natuurlijk een duidelijk voorbeeld van overkill.
Groot proces hoeft niet in één orkestratie
Een veel voorkomend probleem dat Macaw al een aantal keer bij audits is tegengekomen zijn processen die uit te veel stappen bestaan, waarbij dezelfde stappen simpelweg werden gekopieerd. Een proces past dan allang niet meer op één of twee A4-tjes. Hierdoor wordt het proces erg onoverzichtelijk en is er bij wisseling van ontwikkelaars veel inwerktijd nodig om te zien wat het proces nu precies technisch doet.
Dit kan opgelost worden door orkestraties op te delen in logische sub-orkestraties. Orkestratie is in feite het coördineren van de geautomatiseerde bedrijfsprocessen. Zoals orderverwerkingsproces of het aanvragen van een nieuwe uitkering. In de sub-orkestraties kunnen stappen dan ook nog eens worden hergebruikt. Uiteindelijk is het natuurlijk niet aan de integratiespecialist hoe een bedrijfsproces er zelf uit ziet. Wanneer het een complex proces betreft zal het ook met goede keuzes in opzet en granulariteit een complex proces blijven, ook als het geautomatiseerd wordt. Processen nog eens goed onder de loep nemen in bijvoorbeeld een klein BPM traject kan zeker voor het IT deel grote voordelen hebben.
Hoe om te gaan met fouten
Foutafhandeling is misschien wel het minst tot de verbeelding sprekende integratieonderwerp. Voor het uiteindelijke succes van het project is het echter een niet te onderschatten aspect. Berichten die “kwijt” raken of totale integatieketens die niet meer betrouwbaar zijn, zijn een nachtmerrie voor iedere IT manager. Orders die wel geplaatst zijn, maar niet terug te vinden zijn in de leveringen of zelfs bestellijsten, zijn niet uit te leggen aan de business owners.
Twee zaken zijn hierbij belangrijk: Robuustheid van de software en inzichtelijkheid van het operationele proces. Zeker bij asynchrone processen (processen die acties uitzetten, maar ondertussen doorgaan met andere zaken terwijl de uitgezette acties uitgevoerd worden) moet erop vertrouwd kunnen worden dat de uitgezette acties ook goed worden afgehandeld. Bij problemen dient het systeem intelligent te reageren. Functionele problemen moeten anders worden afgehandeld dan problemen die ontstaan door hardware of netwerkissues. In alle gevallen moet het voor de beheerder geen spoorzoeken worden waar een bericht is gebleven of welke actie hij moet uitvoeren om de keten goed door te laten lopen. Een goede foutafhandeling verdient zich in de beheerfase zeer snel terug.
Operatie
Om een operationeel integratiesysteem goed en efficiënt in productie te houden zijn al in de architectuur en designfase belangrijke keuzes gemaakt. Voor de operatie kan hier goede monitoring op performance en herleidbaarheid van berichten aan worden toegevoegd. BizTalk biedt hiervoor BAM, Business Activity Monitoring, voor de functionele monitoring. Voor technische monitoring kan BizTalk gemonitored worden door SCOM (Service Center Operation Manager).
------------------------------------------------------------
Referentie Intrum Justitia
Voor incassobureau Intrum Justitia heeft Macaw een eLink oplossing gebouwd. Hiermee verloopt het uitwisselen van zaakberichten tussen de verschillende internationale kantoren van Intrum Justitia over een centrale hub, waar alle uitgewisselde gegevens in een database worden opgeslagen.
De eLink oplossing is gebouwd op BizTalk met een aantal zelfontwikkelde componenten. Berichtvalidatie (op juistheid) en berichtpersistentie zijn daar de belangrijkste van. De Business Activity Monitoring (BAM) van BizTalk is ingezet om inzicht in het berichtenverkeer te geven. Daarnaast is er een SQL-Server Reporting Services oplossing gebouwd waar zowel het kantoor zelf als de applicatiebeheerder de inhoud van de opgeslagen berichtgegevens kan raadplegen. Kantoren kunnen alleen hun eigen informatie raadplegen.
------------------------------------------------------------
Binnen BizTalk draait het om berichten. Bij het oplossen van problemen zoeken we nu net die ene set aan berichten welke zo lastig te vinden zijn. Het goed inregelen waar en welke berichten voor eventueel later onderzoek moeten worden opgeslagen hoeft niet complex te zijn. Het wordt alleen vaak over het hoofd gezien. “In welk gedeelte van het proces bevindt zich mijn bericht”, “ik wil alle berichten zien behorende bij deze specifieke aanvraag” of “ik wil alle berichten van vorige week donderdag tussen 20.00 - 21.00 uur zien”, zijn vragen die belangrijk zijn om mogelijke problemen zo snel mogelijk te kunnen onderscheppen, of zelfs kunnen helpen bij het primaire proces.
Binnen BizTalk kan aangegeven worden dat specifieke poorten, orkestraties of berichttypes kunnen worden gelogd. Ook is het mogelijk om een eigen log systeem te gebruiken om bijvoorbeeld vertrouwelijke informatie weg te laten. Of dit te combineren met log gegevens uit andere systemen.
------------------------------------------------------------
Referentie
Voor een zelfstandig bestuursorgaan van de Nederlandse overheid heeft Macaw een gemeenschappelijk elektronische berichtenbox gebouwd waar burgers zich op kunnen inschrijven. Vanuit deze box kan naar de burger bijvoorbeeld een herinneringsbrief voor een keuring of een verlenging worden gestuurd.
Om dit realiseren was een systeem nodig die de berichten op een centraal punt ontvangt. Binnen dit proces wordt het bericht, leverancier en ontvanger gevalideerd en vervolgens wordt het bericht opgeslagen in de berichtenbox van de desbetreffende burger. BizTalk is ingezet voor de koppelingen die de berichten van verschillende overheidsinstanties verwerkt naar de berichtenbox. Ook faciliteert deze applicatie in het aangeven of een burger de informatie elektronisch of per post wil ontvangen. BizTalk valideert de totale batch met berichten op correctheid en verzorgt de foutafhandeling bij een niet correct bericht of calamiteiten in de infrastructuur.
------------------------------------------------------------
Tot slot
Al met al zijn er veel uitdagingen met het succesvol krijgen van integratie. Ze zijn zeker niet onoverkomelijk, bij vooraf goed inschatten van risico’s wordt al een hoop ellende achteraf voorkomen. In veel BizTalk trajecten wordt de focus voornamelijk gelegd op het integreren van de applicaties/systemen, terwijl de operationele afdeling voorzien van de juiste tools om zo snel mogelijk problemen te kunnen oplossen of zelfs voorkomen vaak een sluitstuk op de begroting is. Door hier tijdens de ontwikkelfase meer aandacht aan te besteden wordt er ook winst geboekt in de ontwikkelfase omdat testen en uitzoeken waarom die ene integratie nu net niet werkt dan ook een stuk gemakkelijker gaat.
Door onze jarenlange ervaring kunnen wij organisaties die gaan beginnen met applicatie-integratie en daarvoor BizTalk willen gebruiken uitstekend van dienst bij het adviseren of ontwikkelen van de integratieoplossing. Voor organisaties die al applicatie-integratie met behulp van BizTalk hebben en daar met een scherp oog naar willen laten kijken, kunnen wij een BizTalk Audit doen.
Auteur: Wouter Crooy – Software Developer