Beeklaan 444 2562 BK Den Haag www.darwin-it.nl
[email protected] KvK 27283780 ING 65.35.40.663
Mar tien van den Akker Technical Architect
Sturen en Bewaken in BPEL Introductie Over SOA is inmiddels veel gezegd en geschreven. Het is een Concept of een Architectuur (het is maar net van welke kant je het bekijkt) dat een logisch gevolg is op de ontwikkelingen in de lijn van gecentraliseerd “computeren” middels Terminal – Mainframe oplossingen via Client Server naar multitier Web-based computing. Twee belangrijke onderdelen in de Service georienteerde architectuur zijn de Gebeurtenis Gedreven Architectuur (EDA: Event Driven Architecture) en Orchestratie. De gebeurtenis gedreven architectuur worden veelal uitgewerkt middels een Enterprise Service Bus en BPEL is een goede taal voor het bedrijven van Orchestratie. De BPEL Process Manager van Oracle is ideaal voor relatief kort lopende processen. Net als elke andere Process Manager (inclusief alle workflow en case oplossingen) heeft het een versiebeheer dat er op is gericht om lopende processen af te laten lopen met de definitie waarin ze zijn gestart. Wanneer er een nieuwe definitie wordt “gedeployed” worden nieuwe processen gestart met die nieuwe definitie. Lopende processen gaan gewoon verder in de oude definitie. Dit is precies wat een process manager zou moeten doen. Je zou niet anders willen. Toch kan het een probleem zijn met langer lopende processen. In de Justitie keten bijvoorbeeld kunnen processen potentieel 2 jaar duren. Ook andere overheidsprocessen kunnen langduren. Bijvoorbeeld de trajecten met betrekking tot het bouwen van bruggen, wegen en andere infrastructuur. Maar bouw trajecten van gebouwen of grote schepen kunnen lang duren. In die tijd dat een proces loopt kan veel gebeuren, een wijziging in regelgeving of bedrijfsvoering zit er zo in. En het zou maar zo kunnen gebeuren dat deze ook geldt voor lopende processen. Wat doe je daar dan mee? Hoe kun je ervoor zorgen dat deze toch met een nieuwe proces-definitie mee kunnen, zonder dat het gehele proces van het begin tot de huidige proces-stand overnieuw moet? Dat stelt namelijk ook eisen aan de te orchestreren services. Die moeten namelijk “idempotent” zijn, wat betekent dat ze niet alleen “re-entrant” zijn, maar ook dat ze bij elke volgende aanroep hetzelfde resultaat leveren. Als een entiteit al is opgevoerd zal dit moeten worden geconstateerd en zal deze eventueel moeten worden gewijzigd. De services moeten dit dan wel moeten ondersteunen. Over eventuele wacht en bewakingstermijnen moet ook goed nagedacht worden. Deze moeten rekening houden met het feit dat die wacht-tijd al is geweest. Alleen dan kan een proces veilig opnieuw worden gestart. Een functie die ik in Oracle Workflow wel kon waarderen, maar die in BPEL PM (en ik denk ik veel andere process managers) mist is de “Expedite” functionaliteit. Oracle Workflow bezat de mogelijkheid om een processinstantie “terug in de tijd” te zetten. Je kon een andere activiteit
benoemen en de processinstantie daar naar toe terug zetten. De processflow werd dan gereset zodat de executie vanaf dat punt kon worden voort gezet. Eventuele eerdere stappen werden dan gearchiveerd in een History tabel. Het kunnen overdoen van eerder processtappen op basis van binnen komende gebeurtenissen (externe berichten of mutaties in de applicatie) kan een functionele vereiste zijn.
Finite State Machine Bovenstaande problematiek speelde bij mijn vorige klant. Zowel de problematiek van de lang lopende processen als het opnieuw kunnen uitvoeren van eerdere processtappen. Men had daar de wens om elke processtap dynamisch op basis van bedrijfsregels te kunnen evalueren. Het zou bijvoorbeeld kunnen zijn dat een brief is uitgestuurd en er na verloop van een paar dagen van de reactietermijn een bericht van adreswijziging binnen komt. Ook heeft elke klant of betrokkene het “recht om onder de tram te komen”. Dat is geen uitzondering, dat is iets waar je proces rekening mee moet houden. Adreswijzigingen en overlijdensberichten, evenals meldingen van verzet of anderszins kunnen gewoon voor komen en daar moet het bedrijfsproces mee om kunnen gaan. Een oplossing zou kunnen zijn het implementeren van een Finite State Machine. Start Beslisregels Initialiseer
Bepaal volgende stap
Stuur deelprocess aan Afsluiten
Einde Illustratie 1: Finite State Machine Een Finite State Machine zoals bedacht was zou voor elke processtap een bedrijfsregel evaluatie moeten doen. Op basis van de uitkomst van die evaluatie kan dan worden bepaald wat de volgende stap zou moeten zijn. In bovenstaande figuur is het schematisch uitgewerkt. Het proces begint met een initialisatie stap. Vandaar uit komt het in de status “Bepaal volgende Stap”. Hierin
worden de beslisregels geraadpleegd en geëvalueerd. Op basis daarvan wordt in de volgende status “Stuur Deelproces aan” de betreffende processtap uitgevoerd. Daarna komt het weer terug in de “Bepaal volgende stap” status. Dit geheel heeft de bijnaam “de dansende robot” gekregen, omdat het geheel net zolang “heen en weer” danst, tot dat de beslisregels uitwijzigen dat het aan het einde van de dans is gekomen. Vervolgens wordt in de “einde” status de afrondende functionaliteit uitgevoerd en wordt het proces beeindigd. Het idee is heel ingenieus, maar de implementatie stuit op nogal wat uitdagingen. Het belangrijkste bezwaar is eigenlijk dat vanwege het dynamische en generieke karakter bij het ingaan van de evaluatie-stap niet bekend is wat de volgende stap is. Het is ook niet bekend welke beslisregels moeten worden uitgevoerd om te komen tot de juiste volgende stap, althans wanneer het concept zuiver generiek gehouden wordt. Het bepalen welke beslisregels nodig zijn voor het juiste resultaat kan worden overgeladen aan een Business Rules Enige. Maar wanneer niet bekend is welke beslisregels moeten worden uitgevoerd is uiteraard ook niet bekend met welke gegevens de Business Rules Engine op enig moment moet worden gevoed. Immers, op basis van de beschikbare feiten voert hij de betreffende Beslisregels uit. Om dit te ondervangen dienen dus alle eventueel voor de beslisregels benodigde feiten te worden aangeleverd. Hiertoe is het idee van een “werkbriefje” bedacht. Deze bevat alle eventueel benodigde feiten. Maar dit werkbriefje zou dan zo generiek moeten worden opgezet dat het ook eenvoudig is om feiten toe te voegen zonder dat de XML Structuur daar significant door verandert. Een belangrijk probleem van het werkbriefje is de synchronisatie met de database. Hoe zorg je ervoor dat deze redundante informatie altijd voldoende synchroon is met de applicatie database en dus altijd de juiste actuele gegevens bevat? Tenslotte is een nadeel van zo'n generieke Finite State Machine dat het nogal wat ontwikkelcapaciteit kost om dit goed te implementeren. Bovendien, wanneer je het implementeert in BPEL dan bouw je eigenlijk een proces engine in een proces engine. En dat is vergelijkbaar met het bouwen van een interpreter in een geinterpreteerde programmeertaal: niet iets waar je goede prestaties van mag verwachten.
Processturing in BPEL – Initiatie Om de problematiek zoals hierboven beschreven op te lossen hebben we een eigen concept bedacht van afhandelen van processtappen en gebeurtenissen. De processturing wordt verzorgd door een hoofdproces dat werkt volgens het “Dirigent Model”: dit proces stuurt de onderliggende services aan. Die onderliggende services kunnen zogenaamde atomaire of basis services zijn, maar ook gecombineerde of samengestelde services. Deze samengestelde services kunnen uitgewerkt zijn als regulier georchestreerd proces, maar ook volgens hetzelfde concept als hier onder beschreven. Het stuurproces kan op drie manieren worden aangeroepen: ●
Initieel: dit gaat via de standaard “initiate” operatie en levert een nieuwe instantie van het proces op
●
●
Externe Gebeurtenis: hiervoor wordt een aparte operatie “ExternalEvent” gedefinieerd en wordt aangeroepen op basis van een gebeurtenis van buitenaf. Interne Gebeurtenis: ook hiervoor wordt een aparte operatie “InteralEvent” gedefinieerd en wordt gebruikt om het proces zichzelf aan te laten roepen. Dit wordt in de volgende paragraaf uitgelegd.
Een proces moet een begin hebben dat leidt tot een nieuwe instantie van het proces. Dit kan zijn omdat een nieuwe order of een nieuwe zaak middels een bericht via Oracle Integration B2B (of een andere B2B gateway) wordt ontvangen. Ook kan het voorkomen dat het Process opnieuw moet worden gestart met een nieuwe proces definitie en dus vanaf een bepaalde status moet beginnen. Hiervoor moet het Initiate-bericht de volgende parameters hebben: ● ●
●
Status: default “Initieel” Stabiele Toestand: indicator om aan te geven of het proces direct door moet naar een “wacht toestand”. Dit wordt in de volgende paragraaf uitgelegd. Context: een structuur waarin de toestandsvariabelen die nodig zijn voor de normale verwerking van het stuurproces. Bij een herstart moeten deze waarden uiteraard meegegeven worden.
Een lopend stuurproces moet kunnen reageren op externe gebeurtenissen. Dit kunnen berichten zijn van wijzigingen of interventies die voor een lopend proces binnenkomen. Bijvoorbeeld een adreswijziging of een bericht van overlijden. Of een bericht dat de order of zaak om wat voor reden tijdelijk geparkeerd moet worden. Maar er kunnen ook gebeurtenissen vanuit een ERP pakket komen, bijvoorbeeld omdat een tape met bank-transacties wordt ingelezen waardoor orders als betaald kunnen worden aangemerkt. Of juist dat de Collections-applicatie (de applicatie die de binnenkomende betalingen administreert) constateert dat er betalingstermijnen zijn overschreden en er aangemaand moet gaan worden. Deze vervolg berichten of gebeurtenissen moeten door het stuurproces worden afgehandeld. Hiertoe wordt het stuurproces gecorrelleerd aangeroepen met de “ExternalEvent” operatie. Gecorreleerd wil zeggen dat er in het BPEL stuur proces een of meerdere “Correlation sets” zijn aangemaakt waarin een identificerend gegeven is opgenomen. In het bericht dat meegegeven wordt in de ExternalEvent operatie is ditzelfde gegeven opgenomen zodat de Process Manager weet welke instantie van het BPEL Stuurproces moet worden gevoed met het betreffende bericht. In het ExternalEvent-bericht moeten een aantal parameters mee worden gegeven: ●
●
●
Proces – Operatie of Gebeurtenis: hiermee wordt aangeven om welk type gebeurtenis het gaat, waar het stuurproces op moet reageren. Proces Identificatie: Een order of een zaak ID: de correllerende identificatie op basis waarvan door de proces manager de juiste proces-instantie kan worden gevonden. Bericht: Dit kan een “anytype” parameter zijn, omdat per gebeurtenis een andere berichtstructuur meegegeven kan worden. Hierin staan aanvullende gegevens met betrekking tot de gebeurtenis.
Het verdelen van de Initiele en vervolg gebeurtenissen wordt geillustreerd in onderstaande illustratie.
Illustratie 2: Verdeel Initierende en vervolg gebeurtenissen Wanneer een vervolg bericht of gebeurtenis binnenkomt, hetzij vanuit B2B hetzij vanuit een Business Event System Queue, dan wordt eerst de voor die gebeurtenis of interventie specifieke logica uitgevoerd. Deze logica omvat logica die uitgevoerd moet worden nog voordat het stuurproces wordt geintervenieerd. Bijvoorbeeld het bij de Gemeentelijke Basis Administratie controlleren van de adreswijziging of het bericht van overlijden van een betrokkene. Een gebeurtenis of interventie kan betrekking hebben op een specifieke order of zaak of component van een zaak of order, maar kan ook betrekking hebben op meerdere orders van een klant of zaken van een betrokkene. Vandaar dat na de interventie/gebeurtenis specifieke logica bepaald moet worden welke relevante zaken of componenten van zaken het stuurproces moet worden aangeroepen om vervolgens de betreffende processen ook daadwerkelijk aan te roepen.
Processturing in BPEL – Proces Afhandeling Onderstaande illustratie geeft het stuurproces schematisch weer. In het witte gedeelte vindt de daadwerkelijke process uitvoer plaats. In het paarse gedeelte is een proces-deel gemodelleerd dat in een parallele flow draait, dus simultaan aan de process-uitvoer in het witte gedeelte. Vanuit de Initate operatie worden beide flows tegelijkertijd gestart.
Het hoofdproces Het hoofdgedeelte begint met een tweetal afvragingen. De eerste is de bepaling of er een interventie is geweest. Dit is een bevraging van een indicatie die gezet kan worden in het paarse gedeelte waarover straks meer. Standaard staat deze indicator uit. De tweede bevraging is of er naar de stabiele toestand moet worden gesprongen. Deze indicator kan specifiek zijn gezet wanneer dit is meegegeven bij een herstart van het proces. Initieel staat deze uit. Vervolgens wordt de huidige processtatus uitgevraagd, waarna een van de betreffende Proces-Takken (branches) wordt uitgevoerd. Het proces gaat normaal gesproken cyclisch door deze proces-takken heen, waarbij telkens eerst de voor die tak benodigde feiten worden opgevraagd uit de applicatie database(s), om vervolgens op basis van business rules te bepalen of de betreffende stap moet worden uitgevoerd en wat vervolgens de volgende processtatus moet zijn. In de processtatussen wordt onderscheid gemaakt in Vluchtige Toestanden en Stabiele Toestanden. Een vluchtige toestand houdt in dat de ene processtatus direct leidt tot een volgende processtatus. Er is geen externe gebeurtenis nodig om van de ene toestand in de andere te komen. Een stabiele toestand daarentegen vereist wel een externe gebeurtenis, bijvoorbeeld het verstrijken van een termijn of het ontvangen van een bericht, om een volgende transitie uittevoeren. Wanneer uit de transitie blijkt (of bij een herstart) dat de betreffende processtatus een stabiele toestand is, dan wordt er gewacht. Dit wachten wordt in BPEL geimplementeerd door te luisteren naar een
InternalEvent bericht.
De Event Handler Het paarse gedeelte in het proces laat de zogenaamde “EventHandler” zien. Dit proces luistert naar ExternalEvent berichten. Wanneer een ExternalEvent bericht binnenkomt wordt eerst gecontroleerd of het om een Herstart of Afsluit gebeurtenis gaat. Is dat namelijk het geval dan wordt een Indicatie “Einde” gezet. Anders wordt de betreffende Interventie Processtatus en Interventie Type gezet. Vervolgens wordt gecontrolleerd of het hoofdproces in een Stabiele Toestand zit. Is dat het geval dan heft de Event Handler dit op door het proces zichzelf gecorrelleerd met een InternalEvent bericht aan te laten roepen. Dit bericht komt dan terecht in de Stabiele toestand wacht activiteit terecht, in het witte gedeelte, waar gewacht wordt op een InternalEvent bericht. Wanneer de “Einde” indicator niet is gezet dan gaat de EventHandler weer terug om naar een volgend ExternalEvent-bericht te luisteren. Is de indicator gezet dan wordt er nog een InternalEvent bericht gestuurd om het hoofdproces door te laten gaan. Daarna stopt de Event Handler. Het hoofdproces zal ondertussen bij de eerst volgende cyclus bij de eerste afvraging “Interventie” terecht komen en vervolgens in de interventie afhandeling terecht komen.
Processturing in BPEL: afhandeling van gebeurtenissen per type De afhandeling van Interventies of gebeurtenissen zouden in het normale Hoofdproces uitgemodelleerd kunnen worden. Dit levert potentieel een hele brede processtatus afvraging op met heel veel proces-takken. Om nu de normale afhandeling nog enigszins overzichtelijk te houden is bedacht om de Interventie/Gebeurtenis afhandeling te scheiden van het hoofdproces en ook te categoriseren per type interventie/gebeurtenis. Daarom wordt in de afhandeling van de interventies eerst afgevraagd om wat voor interventie/gebeurtenis het gaat, zoals weergegeven in onderstaande illustratie.
Illustratie 3: Afhandeling van gebeurtenissen per type
Processturing in BPEL: Afhandelen van een gebeurtenis De afhandeling van een gebeurtenis kan vervolgens conventioneel uitgemodelleerd worden, wanneer het om een eenvoudige kortlopende afhandeling gaat. Maar net zo goed kan het op eenvergelijkbare manier worden uitgemodelleerd als het hoofdproces. Dit laatste wordt geillustreerd in de onderstaande flow:
Illustratie 4: Afhandelen van een gebeurtenis Wanneer de gebeurtenisafhandeling klaar is, wordt weer teruggekeerd naar het hoofdproces. De Herstart gebeurtenis neemt hierin een aparte plaats in: hier roept het proces zichzelf aan maar nu met de “initiate” operatie. Er wordt dus een nieuwe instantie van het proces gecreeerd, maar met mede geving van de proces-context en de huidige processtatus. Hierna wordt de huidige instantie beëindigd.
Bewaken Het onderwerp “bewaken” is nog niet aan de orde gekomen. Tot nu toe ging het eigenlijk alleen om het “dynamisch” sturen. Bewaken is ook eigenlijk geen onderdeel van het basis-concept. Bewaken in BPEL kan op een betrekkelijk eenvoudige manier worden geimplementeerd. Het enige dat nodig is, is een standaard (asynchrone) service met een wacht activiteit. De input van het proces is het correllerend gegeven waarmee het Stuur-proces wordt aangeroepen via de ExternalEvent operatie, aangevuld met een wacht-periode. Vervolgens wacht de Bewaak service op het verstrijken van de termijn, waarna het het hoofdproces aanroept via de ExternalEvent operatie met als event-type “Bewaak-termijn verstreken”. Eventueel kan aan de Bewaak-service een “cancel”-operatie worden toegevoegd, zodat het Stuur-proces kan aangeven dat de bewaking gestaakt kan worden. Ook kan gekozen worden het stuurproces de gebeurtenis te laten negeren.
Conclusie Het hier beschreven concept gaat te ver voor eenvoudige, kort lopende processen. Dit concept heeft toegevoegde waarde als aan een van de volgende eisen moet worden voldaan: 1. flexibiliteit van uitvoering is benodigd: de volgorde van uitvoering is afhankelijk van business rules en er moet eventueel terug gesprongen (heruitvoering van activiteiten) of vooruit gesprongen (overslaan van activiteiten) kunnen worden; 2. een proces is potentieel langlopend en moet herstart kunnen worden in een nieuwe definitie; 3. een proces moet flexibel kunnen reageren op externe events. Wanneer geen van deze eisen is gesteld, is het verstandiger om het process “conventioneel” uit te modelleren. In dat geval blijft het model het dichtst bij wat de “business” definieert als bedrijfsproces. Voldoet je te ontwerpen proces wel aan een van de drie bovengenoemde criteria, dan biedt dit concept de mogelijkheid deze problemen op te lossen en met het proces toch nog redelijk dicht bij het bedrijfsproces te blijven. Wel adviseer ik een goede granulariteit van procesdelen te kiezen die je uitmodelleert in de diverse takken. Wanneer je elke knooppunt in het bedrijfsproces als “toestand” definieert, dan wordt elke activiteit in je bedrijfsproces een tak in het “sturen en bewaken” concept. Dit kan leiden tot een onnodig ondoorzichtig proces dat erg ver van het bedrijfsproces staat, met in BPEL een onnodig “brede switch”: een keuze stap met heel veel mogelijke vervolg paden.
