In dit hoofdstuk volgt een beschrijving van een systeem voor werkstroomondersteuning van IBM. Een metamodel voor procesmodellering vormt de basis voor de architectuur van het systeem, en dit is meteen het antwoord op een eerste tekort van het referentiekader van de Workflow Management Coalition (§3.2.8.5 "Nood aan een consistent objectmodel", p. 1). Na een inleiding tot de gebruikte terminologie, wordt de implementatie van het metamodel uitgewerkt en worden een aantal voorbeelden gegeven van mogelijke implementatiescenario's (cf. §3.2.6 "Architecturen voor workflow management systemen", p. 1). Vervolgens plaatsen we FlowMark in het referentiekader van de Coalitie. In de paragraaf over Lotus Notes geven we aan hoe FlowMark kan uitgebreid worden om meerdere delen van het workflow continuüm te bestrijken (cf. §2.3 "Classificatie van workflow management systemen", p. 1). In de paragraaf over transactiemanagement wordt aangegeven hoe aan de gebrekkige invulling van het gegevensbeheer in het referentiemodel van de Coalitie een mouw kan gepast worden (§3.2.8.1 "Gegevensbeheer", p. 1). Na een korte bespreking van een product uit de FlowMark familie dat een verband legt tussen werkstroombeheer en Internet, zetten we kort de voordelen en nadelen van FlowMark op een rijtje.
FlowMark is een objectgeoriënteerd client-server productiewerkstroomsysteem van IBM. Het biedt ondersteuning voor zowel het modelleren van processen ("build time") als het uitvoeren ervan ("run time"). Daarnaast biedt het ook een repository voor de opslag van procesdefinities. FlowMark wordt door IBM binnen het kader van hun "Information Warehouse Framework" gepositioneerd als de workflow management component.
FlowMark werd ontwikkeld in IBM's German Software Development Laboratory. Het is aanvankelijk ontworpen voor OS/2 en geschreven in C++, met uitzondering van het animatiegedeelte dat werd ontworpen in Prolog. Voor de opslag van gegevens werd geopteerd voor ObjectStore, een objectgeoriënteerde database van Object Design Inc..
IBM positioneert het product duidelijk in de markt van grote bedrijven die grote volumes van gegevens te verwerken krijgen (Populiers, 1997). In die omgevingen wordt dan ook veel belang gehecht aan beschikbaarheid van het systeem en integriteit van de gegevens. Daarnaast kenmerken dergelijke omgevingen zich door heterogeniteit van de onderliggende systemen, en ook daarmee moet FlowMark dus overweg kunnen. Maar naast een systeem voor werkstroomondersteuning is het ook een systeem voor het ontwerpen van gedistribueerde applicaties en voor procesmodellering. Tot slot moet het mogelijk zijn om FlowMark te koppelen met ad-hoc workflow systemen, en is ondersteuning van workflow management vanuit het sterk in opgang zijnde Internet een troef die IBM wil uitspelen met dit product.
IBM komt als een van de weinige constructeurs naar buiten met een goed gefundeerd onderliggend model voor de uitbouw van hun werkstroomproduct. Er werd bijzondere aandacht besteed aan de modelleringskracht van het product. Deze aanpak bouwt duidelijk voort op de definitie van een workflow management systeem als software waarvan de uitvoer bepaald wordt door een computerrepresentatie van de werkstroomlogica (zie §2.2.1 "Workflow management: definitie", p.1). Het uitgangspunt voor deze computerrepresentatie is het bedrijfsmodel met zijn onderscheiden bedrijfsprocessen. Het model van een bedrijfsproces kan dienen als opmaakprofiel voor een klasse van gelijkaardige bedrijfsprocessen. Een bepaalde instantiatie en interpretatie van zo'n model stelt een individueel proces in uitvoering voor (cf. §3.2.4 "Basisterminologie voor de beschrijving van workflow management systemen", p. 1). In de volgende paragrafen worden de syntactische elementen en bouwstenen van bedrijfsprocessen, zoals gezien door IBM, beschreven (Leymann, 1994a en Leymann, 1994b).
Activiteiten zijn de fundamentele elementen van het meta-model. Ze stellen gebeurtenissen voor die in het kader van de bedrijfsvoering plaatsvinden en vormen binnen het te modelleren bedrijfsproces een semantisch zelfstandige eenheid. Activiteiten kunnen op hun beurt verfijnd worden door procesmodellen, hetgeen toelaat een bedrijfsproces bottom-up of top-down te modelleren. Zo kan een bedrijfsproces uit een aantal activiteiten bestaan die op hun beurt uit een aantal processen zijn opgebouwd, of kunnen een aantal processen geaggregeerd worden tot een enkele activiteit die een onderdeel van een bedrijfsproces vormt.
Bv. een activiteit "controleer solvabiliteit" kan verfijnd worden als een proces model, en deze verfijning kan gebeuren door verschillende modelleerders.
Het werk dat door een activiteit is gepresteerd, wordt in een output container geplaatst die hoort bij die activiteit. Aangezien activiteiten onderling gerelateerd zijn, zullen de output containers van bepaalde activiteiten verbonden zijn met input containers van andere. Bij uitvoering vormen de gegevens in de input container de context van een instantiatie van een activiteit.
Activiteiten worden niet in willekeurige volgorde uitgevoerd. Activiteiten kunnen voorgesteld worden als knooppunten van een netwerk. Zij zijn aan elkaar gebonden door controleconnectoren. Deze kunnen vergeleken worden met "directed edges": een activiteit aan het eindpunt van de pijl kan niet starten vooraleer de activiteit aan het beginpunt succesvol is afgehandeld. Controleconnectoren modelleren aldus de potentiële stroom van controle binnen het weergegeven bedrijfsproces.
Met elke controleconnector is een booleaanse variabele geassocieerd die een overgangsconditie vormt. Wanneer tijdens uitvoering een activiteit succesvol eindigt, worden alle overgangscondities geëvalueerd. Enkel de eindpunten van de controleconnectoren die als 'waar' (true) geëvalueerd werden kunnen mogelijks geselecteerd worden als volgende uit te voeren activiteit in het kader van het bedrijfsproces. Overgangscondities modelleren de context-afhankelijke feitelijke stroom van controle.
Om van elke activiteit te bepalen of deze succesvol is uitgevoerd, is aan elke activiteit een exit conditie gekoppeld. De activiteiten waarvan de exit-conditie als 'waar' geëvalueerd wordt in de feitelijke context, worden aanzien als succesvol beëindigd. Deze bepalen ook de feitelijke stroom van controle.
Parallellisme van activiteiten kan voorgesteld worden door twee activiteiten die het eindpunt vormen van twee pijlen (controleconnectoren) met dezelfde activiteit als beginpunt. Dergelijke activiteit fungeert dan als 'fork'. De semantiek van meerdere connectoren die samenkomen in één activiteit kan gedefinieerd worden met behulp van synchronisatiecondities. Deze condities bepalen wanneer de uitvoering kan doorgaan: als alle transitiecondities van inkomende controleconnectoren 'waar' zijn, of als tenminste één van de transitiecondities 'waar' is. Zo'n activiteit kan als 'join' geïnterpreteerd worden.
Aangezien activiteiten die parallel uitgevoerd kunnen worden mogelijks van dezelfde gegevens gebruik maken, moet een vorm van gedeelde toegang tot de brongegevens mogelijk zijn. In plaats van locking gebruikt men een meer restrictieve benadering: input en output containers worden als privaat en lokaal beschouwd. Deze containers van een activiteit of proces bevatten parametertypes. De gegevens die door de activiteiten of processen worden gegenereerd of verwerkt, worden geassocieerd met deze parametertypes. Teneinde het delen van gegevens toe te laten bij parallelle uitvoering van activiteiten, moet er een mechanisme voorzien worden om instantiaties van parameters in containers te delen. Een pijl die vertrekt bij een parametertype van de output container van een activiteit en aankomt bij een parametertype van de input container van een andere activiteit, wordt een dataconnector genoemd. Tijdens uitvoering worden dan overeenkomstige instantiaties van parameters (de werkgegevens) doorgegeven "langs" deze dataconnectoren.
Naast een beschrijving van de potentiële stroom van controle en gegevens, geeft een bedrijfsmodel ook een beschrijving weer van de verdeling van activiteiten tussen "middelen" (resources) die het werk uitvoeren zoals het is vastgelegd in de activiteit. Een taak is niets anders dan de koppeling van een activiteit met de middelen. "Middelen" kunnen gespecificeerd worden als personen, rollen of organisatorische eenheden. Tijdens uitvoering worden taken vertaald in aanvragen gericht aan bepaalde personen om bepaalde activiteiten uit te voeren.
De samenhang tussen
de besproken termen is visueel weergegeven in Figuur 18. Een
volledige wiskundige beschrijving van het FlowMark model is terug
te vinden in (Leymann, 1994a, pp. 341 tot 346).
Figuur 18 FlowMark terminologie
Zoals reeds gesteld in de inleiding is FlowMark gebouwd volgens de filosofie van een client-server architectuur zoals in Figuur 16 (p. 1). Dit geldt voor de beide client componenten waaruit het product bestaat, namelijk de 'build time component' en de 'run time component' (vergelijk met §2.4 "Algemene structuur van een workflow management systeem", p. 1). De client handelt de interactie af met de gebruiker en heeft een grafische gebruikersinterface. Verder zorgt de client voor de invocatie van lokale programma's (run time component) of voor de animatie van het workflow proces (build time client). De server onderhoudt de databank met proces instantiaties, doorloopt het procesmodel en wijst activiteiten toe aan de gepaste uitvoerders. In de volgende paragrafen wordt verder ingegaan op de beide client componenten waaruit FlowMark bestaat (Leymann, 1994a, Leymann, 1994b en IBM, 1996h) en de functionaliteiten van de servers (IBM, 1996h).
De build time component bestaat uit een aantal bouwblokken die toelaten een bedrijfsproces te modelleren en van alle nodige informatie te voorzien opdat het zou kunnen uitgevoerd worden binnen de run time omgeving. Deze bouwblokken zijn :
Het maken van een procesdefinitie houdt in dat de activiteiten moeten gemodelleerd worden samen met hun input en output containers, hun controleconnectoren en hun dataconnectoren. Hiertoe kan de meegeleverde grafische editor gebruikt worden. De activiteiten zijn dan knooppunten van een acyclische graf, en de connectoren vormen de verbindingslijnen van deze graf.
FlowMark kent drie soorten activiteiten:
Programma-activiteiten worden geïmplementeerd door middel van programma's die geregistreerd worden via de 'program registration facility' (zie infra).
Procesactiviteiten worden geïmplementeerd als processen. Deze kunnen gebouwd worden volgens een principe van stapsgewijze verfijning (top-down), of door aggregatie van een verzameling kleinere subprocessen (bottom-up) die eventueel door meerdere modelleerders zijn ontworpen. Aan programma- en procesactiviteiten kan een tijdslimiet gekoppeld worden. Deze activiteiten dienen dan binnen de gestelde tijd voltooid te worden. Zoniet wordt een op voorhand aangeduide persoon verwittigd van de vertraging. De verwittingen worden eveneens opgenomen in een audit trail systeem (zie §4.1.5.2 "De run time component - Audit trail" p. 1).
Blokken bevatten een verzameling van procesactiviteiten en bestaan dus uit dezelfde elementen, maar hebben een eigen exit-conditie. Op die manier kan een 'do until'-constructie opgezet worden, die de activiteiten in het blok herhaalt tot er aan de exit-conditie is voldaan.
Containers van activiteiten worden opgebouwd volgens profielen die de datastructuren van de parameters in de containers bevatten. De datastructuren worden gedefinieerd met behulp van de 'data structure definition facility'. De elementaire datatypes die ondersteund worden zijn string, long en float en arrays van deze elementaire datatypes. Deze datastructuren kunnen gecombineerd worden tot nieuwe, door de gebruiker gedefinieerde, datastructuren. Het centraal beheren van de datadefinities moet de consistentie van de interfaces naar de activiteiten en de implementatie ervan garanderen, zoals bij het gebruik van header-bestanden in bijvoorbeeld C.
Tijdens de uitvoering van een proces worden activiteiten toegewezen aan bepaalde personen. Van deze personen worden een aantal basiselementen bijgehouden zoals de naam en identificatiegegevens. Elke persoon behoort tot een bepaalde eenheid (unit), en aan elke persoon kunnen ook een bepaalde verzameling rollen toegekend worden. Met de importfunctie kunnen deze gegevens in FlowMark ingeladen worden uit externe personeels- of organisatiedatabases. Wanneer het proces dan gedefinieerd wordt (process definition, cf. supra), dient ook voor elke activiteit vastgelegd te worden wie deze kan uitvoeren. Twee opties zijn beschikbaar, met name het toekennen van een of meerdere personen aan een activiteit of het toekennen van een of meerdere rollen of organisatorische eenheden (zoals departementen of projectgroepen) aan de activiteit. Volgens de laatste optie wordt het dan ook mogelijk om uitvoerders te vervangen door anderen die dezelfde rol vervullen. Binnen eenzelfde rol kan nog een onderscheid tussen uitvoerders gemaakt worden door een indeling in niveaus (bijvoorbeeld op basis van expertise). Verder kunnen uitvoerders ook dynamisch (dus tijdens uitvoering) toegekend worden op basis van gegevens die via de FlowMark API worden doorgegeven.
Met de program registration facility kunnen programma's die programma-activiteiten implementeren gedefinieerd worden. De naam van het in te roepen programma, de lokatie ervan en de door te geven parameters worden hierbij opgegeven. Deze parameters zijn variabelen die tijdens uitvoering gesubstitueerd worden door feitelijke waarden. Indien later beslist zou worden om andere toepassingen te gaan gebruiken, kan deze informatie aangepast worden in de programmaregistratie zonder het FlowMark model te moeten herzien (IBM, 1995b). Nieuw te bouwen programma's kunnen gebruik maken van FlowMark interfaces via API-aanroepen.
Deze module laat toe een gemodelleerd proces te testen en kan in twee modes werken: debugger mode en regressiemode. In debugger mode kunnen, vertrekkend vanuit eender welke activiteit, voorwaarts of achterwaarts de verschillende stappen van een proces doorlopen worden. Dit proces wordt grafisch voorgesteld. Verschillende elementen van activiteiten kunnen ondertussen worden weergegeven, zoals inhoud van de werklijsten van uitvoerders of de toestanden van activiteiten of connectoren. Op deze manier is het mogelijk inefficienties of fouten in de modellering op te sporen vooraleer tot implementatie over te gaan. De gegevens die tijdens het doorlopen van een animatiesessie worden opgeslagen, kunnen opgenomen worden. Zo kan het model later opnieuw afgespeeld worden in wat regression mode genoemd wordt.
Naast de met FlowMark meegeleverde process definition tool kan ook gebruik gemaakt worden van een ander pakket van IBM dat thuishoort in de categerie tools die ondersteuning bieden voor business proces reengineering, met name Business Process Modeler. De exportfaciliteit van dit product is in staat FlowMark Definition Language (FDL) te genereren die op zijn beurt kan geïmporteerd worden in de build time omgeving van FlowMark (IBM, 1996d). Verder kunnen de definities geïmporteerd of geëxporteerd worden als tekstbestanden (IBM, 1995b).
Met behulp van deze bouwsteen worden de verschillende run time servers geregistreerd die voor de uitvoering van de processen zullen instaan. Zowel servers van het eigen domein als van domeinen waarnaar de definities moeten kunnen geëxporteerd worden dienen hierin opgenomen te worden.
Ook deze component bestaat uit een aantal blokken die samen instaan voor de correcte uitvoering van een model, zoals gedefinieerd met de build time component. De componenten die we hier terugvinden zijn:
Van de procesdefinities wordt een template gemaakt die als basis fungeert voor de creatie van instantiaties van het betreffende proces. Wanneer het procesmodel vertaald wordt naar een uitvoerbare template, wordt dit op consistentie en volledigheid gecontroleerd. Het startbare proces bestaat onafhankelijk van het model. Op die manier kunnen wijzigingen doorgevoerd worden in de procesdefinities zonder instantiaties die nog in uitvoer zijn te moeten onderbreken. Anderzijds is het in de huidige versie van FlowMark (V2R2) nog niet mogelijk de in uitvoer zijnde processen te synchroniseren met wijzigingen in de definities.
Wanneer een proces start, worden de startactiviteiten gelokaliseerd, de juiste uitvoerders uitgezocht en worden de activiteiten op de werklijsten van de geselecteerde uitvoerders geplaatst. Als een gebruiker een activiteit selecteert voor uitvoering, dan wordt deze verwijderd uit de werklijsten van alle andere gebruikers die aanmerking kwamen voor het uitvoeren ervan. Nadat een activiteit beëindigd is, wordt haar exit-conditie geëvalueerd. Indien hieraan niet voldaan is, wordt de activiteit opnieuw gepland. In het andere geval worden alle uitgaande controleconnectoren en de daarmee geassocieerde transitiecondities nagegaan. Controleconnectoren waarvan de condities 'waar' zijn worden geselecteerd en de controleconnectoren van de daaraan verbonden activiteiten worden vervolgens geëvalueerd. Indien aan de overeenkomstige startcondities voldaan is, wordt deze activiteit op haar beurt toegewezen. Een proces is beëindigd wanneer alle eindactiviteiten beëindigd zijn.
Alle informatie met betrekking tot de uitvoering van activiteiten wordt bijgehouden in de database van de server, zodat forward recovery mogelijk is in het geval van een systeemfout (soft crash).
De work list handler is de grafische eindgebruikersomgeving van het workflow systeem. Een gebruiker kan over meerdere werklijsten beschikken om uit te voeren werk te organiseren. Uit te voeren activiteiten worden voorgesteld door icoontjes. Door te dubbelklikken wordt een geassocieerd programma (in het geval van een programma-activiteit) of het onderliggend subproces gestart (in het geval van een procesactiviteit). Daarnaast kan ook de documentatie die bij de activiteit is opgenomen in de definitie geraadpleegd worden. Afhankelijk van de rechten van de gebruiker kan deze werk dat aan hem is toegewezen verder doorsturen naar andere gebruikers en/of de werklijst van een andere gebruiker inzien.
Indien het gaat om een programma-activiteit, zoekt de program registration facility de juiste registratie-informatie waarmee het programma gestart kan worden. Deze toepassingen kunnen lokaal opgeslagen zijn op OS/2, Windows of AIX werkstations of verwijderd op MVS of AS/400 hosts, onder de vorm van uitvoerbare bestanden, scriptbestanden of dynamisch gelinkte bibliotheken (DLL's of dynamic link libraries). De "program execution client"-component voor OS/2, AIX of Microsoft Windows maakt het voor activiteiten mogelijk de toepassingen remote te starten. CICS (Customer Information Control System), IMS (Information Management System) en TSO (Time Sharing Option) host programma's kunnen transparant aangeroepen worden door middel van de Application Support Facility (ASF) (IBM, 1995b). Door middel van de "FlowMark for MVS/ESA Application Integration Feature (FM/MVS AIF)" die gebruik maakt van CICS scripts en MQSeries kunnen ook toepassingen en gegevens op MVS systemen (S/390) geïntegreerd worden (IBM,1995c). Dit wordt geïllustreerd in §4.1.5.5 "MQSeries-support building block" op p. 1.
Onder OS/2 draaien applicaties als aparte processen. Resynchronisatie met FlowMark gebeurt via het OS/2 wachtrijmechanisme (Leymann, 1994a). FlowMark communiceert over meerdere platformen door gebruik te maken van IBM's MQSeries software die instaat voor zogenaamde "once and once only delivery" tussen meerdere servers. Andere platformen voor de uitwisseling van berichten worden echter ook ondersteund (IBM, 1996b, p. 4).
Verder kunnen speciaal geschreven toepassingen ook gestart, beëindigd, onderbroken of hervat worden door gebruik te maken van de beschikbare proces-API's. Een programma kan opvragingen doen omtrent de structuur van de containers en bijvoorbeeld gegevens uit de invoercontainer selecteren, verwerken en de resultaten wegschrijven in de output container. Aan legacy programmatuur kunnen FlowMark-gegevens doorgegeven worden op de commandolijn als parameters. Tijdens uitvoering worden deze parameters dan gesubstitueerd door actuele waarden uit de input container van dit programma.
Alle acties die FlowMark uitvoert tijdens run time worden opgenomen in een audit logbestand. Onder acties wordt verstaan: de start van een proces, de start van een activiteit, het doorwerken van een activiteit, het transfereren van activiteiten naar andere medewerkers of de beëindiging van een proces of activiteit. Van deze acties worden de gebruiker, de datum en tijd en de proces identificatie bijgehouden. Ook de gemiddelde duur van een proces wordt bijgehouden, de tijd die een activiteit gemiddeld nodig heeft om uitgevoerd te worden en het aantal keer dat een activiteit niet binnen de gestelde tijdsnormen werd voltooid.
Dit is de objectgeoriënteerde ObjectStore database die alle informatie met betrekking tot de werkstroommodellen opslaat. Zowel procesdefinities als informatie omtrent lopende instantiaties van processen en activiteiten worden centraal bijgehouden. Het navigeren doorheen een proces in uitvoering gebeurt door het transactioneel bijwerken van de gegevens in de database. Een database transactie kan bijvoorbeeld bestaan uit (Alonso et al., 1996):
De database server coördineert alle database transacties.
Deze component bestaat op zijn beurt uit een aantal onderdelen:
De run time server coördineert de processen in uitvoering. Het is een database client die de link vormt tussen de database en de run time clients.
Een delivery server coördineert de communicatie tussen de verschillende domeinen en is eveneens een database client.
Meerdere instantiaties van een bepaalde activiteit worden "bundles" genoemd. Het beheer van deze bundles wordt door deze service waargenomen. Ook deze module is een database client.
Deze database client controleert of er beëindigde processen zijn en verwijderd deze. Als er processen of activiteiten zijn die niet binnen de gestelde tijdsnorm voltooid zijn, dan brengt deze dienst een aangeduid persoon daarvan op de hoogte.
In bijlage 2 is een schema opgenomen dat weergeeft welke componenten met elkaar communiceren.
Een service broker
zet een sessie op met een vreemd serversysteem en onderhoudt deze
voor de duur van de werksessie, zonder dat de verbinding opnieuw
moet opgezet worden bij elke service request. De service broker
manager beheert de verschillende sessies van service brokers
waarvoor hij bevoegd is (IBM, 1996i).
Figuur 19 Gebruik van de requester om
diensten aan te vragen aan een FlowMark workflow engine (IBM,
1996i)
Een service broker voorziet een interface naar de diensten die door de server worden aangeboden. Een aanvraag gaat eerst naar de service broker manager, die de correcte service broker aanroept. De service broker maakt gebruik van twee bibliotheken (DLL's), waarvan er één de connectie met de server tot stand brengt, en de andere aangevraagde diensten afhandelt via API's. De client toepassing communiceert niet rechtstreeks met de service broker manager, maar via een service requester. Op die manier kunnen login prompts voor de gebruiker afgeschermd worden. Een toepassing roept aldus een service requester aan, die de gegevens van de gebruiker formatteert en een aanvraag plaatst bij de service broker manager. Deze selecteert de juiste service broker en roept daar de gevraagde dienst op. Op die manier kunnen toepassingen gebruik maken van FlowMark diensten via de FlowMark requester. Requesters worden aangeroepen via API's. Dit proces wordt schematisch weergegeven in Figuur 19 (op de figuur is enkel de bibliotheek voor de afhandeling van diensten, ServiceDLL genoemd, weergegeven).
De FlowMark service broker biedt zes diensten aan:
Figuur 20 op p. 1 illustreert een mogelijke service requester implementatie (in C) die de FlowMark server vraagt een proces te starten op basis van het "FlowMark Template1"-profiel (de regelnummers maken uiteraard geen deel uit van de code).
Op regel 30 wordt het sessie-ID opgevraagd van de connectie; op regel 33 wordt de aanvraag doorgegeven naar FlowMark requester: hierbij wordt het sessie-ID meegegeven van de connectie, en de dienst die aangevraagd wordt. De aanvraag is een string ("SBWBFM SBWSFM StartProcess FlowMark Template1") die wordt samengesteld op regel 9 en volgende. De declaratie van de variabelen waaruit de string is opgebouwd (pszBroker, pszService, pszFunction en pInAreaPtr) gebeurt op regel 8 en volgende.
Het concept van
service brokers komt verder nog ter sprake bij integratie van
Lotus Notes (§4.1.7 "FlowMark en Lotus Notes",
p. 1).
1 VOID CallFMRequester() 2 { 3 char pszSessionID[EXMPJ_SESS_BUF_LEN]; 4 char pszActivityString[ACTIVITY_LENGTH]; 5 char pszmsgbuf[256]; 6 unsigned ulCurrentLength; 7 RETURNCODE rc; 8 char FAR # pszBroker = "SBWBFM"; 9 char FAR # pszService = "SBWSFM"; 10 char FAR # pszFunction = "StartProcess"; 11 char FAR # pInAreaPtr = "FlowMark Template1"; 12 /########################################################/ 13 /# Fill the activity string in the sequence: #/ 14 /# 1) Broker #/ 15 /# 2) Service #/ 16 /# 3) Function #/ 17 /# 4) Inarea #/ 18 /########################################################/ 19 strcpy (pszActivityString, pszBroker ); 20 strcat (pszActivityString, " " ); 21 strcat (pszActivityString, pszService ); 22 strcat (pszActivityString, " " ); 23 strcat (pszActivityString, pszFunction ); 24 strcat (pszActivityString, " " ); 25 strcat (pszActivityString, pInAreaPtr ); 26 /########################################################/ 27 /# Get FM's session ID and call FMRequest to handle #/ 28 /# the request. #/ 29 /########################################################/ 30 rc = ExmcGetSessionID(pszSessionID); 31 if (rc == EXMPJ_OK) 32 { 33 apiRc = FMRequest(pszSessionID, pszActivityString); 34 } 35 return; 36 }
Figuur 20 Voorbeeld van C code voor een
service requester (IBM, 1996j)
MQSeries is een communicatiesubsysteem van IBM dat voorziet in persistent messaging. Door API aanroepen naar een queue manager worden berichten in een wachtrij geplaatst. Het subsysteem staat verder in voor de afhandeling van de berichtenstroom. Aangezien een toepassing enkel wachtrijen gebruikt, heeft dit het voordeel van protocolonafhankelijk te zijn (Alonso et al. (a)). Het onderliggend mechanisme maakt gebruik van elementen uit het domein van het transactiebeheer om persistentie van de wachtrijen te garanderen.
Met FlowMark worden
een aantal modules meegeleverd die in staat zijn processen te
starten, onderbreken, hervatten en beëindigen op andere FlowMark
systemen door gebruik te maken van MQSeries. Een proces start dan
een programma-activiteit die door API-aanroepen een nieuwe
wachtrij voor uitgaande en/of inkomende berichten creëert (1 op
Figuur 21). Vervolgens kunnen dan gegevens uit de containers
worden doorgegeven (application data), samen met gecodeerde
proces-relevante gegevens (workflow relevant data) zoals de naam
van een proces dat op het andere systeem moet gestart of beheerd
worden (2). Er wordt informatie teruggestuurd voor latere
synchronisatie (3). Op gelijkaardige manier kunnen gegevens via
calls uit de wachtrij gelezen worden. Een serverprogramma gaat op
geregelde tijdstippen na (5) of er nieuwe berichten zijn
aangekomen die door de MVS-activiteiten verstuurd werden (4). Dit
hervat het proces dat de remote activiteit in gang had gezet (6).
Het proces start dan een volgende programma (7) dat de gegevens
uit de wachtrij inleest (8) en overhandigt aan het lokale proces
(9) dat zijn werking verderzet.
Figuur 21 Communicatie en interactie
tussen FlowMark voor OS/2 of AIX en MVS (op basis van (IBM,
1996i))
De vier toepassingen waaruit het product bestaat - de database server, de workflow server, de run time client en de build time client - maken een scala aan implementaties volgens het client-server paradigma mogelijk. De meest geschikte architectuur hangt af van de grootte en organisatiestructuur van de onderneming, de beschikbare hardware en netwerkinfrastructuur, de geografische spreiding van de lokaties waarmee gecommuniceerd wordt en de doelstelling van het systeem.
Voor het testen en ontwerpen van processen kan het volledige systeem van servers en clients op één en dezelfde machine geïnstalleerd worden. Op die manier kunnen op een veilige manier nieuwe modellen gedefinieerd worden en opgeslagen in een testdatabase. Na verificatie kan het het model dan geëxporteerd worden naar een FDL-definitiebestand, dat vervolgens in de productiedatabase(s) van de run time omgeving wordt geïmporteerd. Voor versie 2 release 2 van het product moet dit gebeuren op een machine met OS/2 Warp, aangezien dit het enige platform is dat ondersteund wordt voor de build time client (IBM, 1996h). Communicatie tussen de modules onderling gebeurt door gebruik te maken van pipes.
Voor een productie-omgeving zijn globaal genomen drie scenario's denkbaar: een waarbij gebruik gemaakt wordt van één server met meerdere clients, één waarbij de database en de workflow server(s) op verschillende machines draaien, en tenslotte een opstelling waarbij meerdere database servers ingezet worden (IBM, 1996g).
In het geval van weinig gebruikers in één werkgroep en niet meer dan een paar duizend processen in uitvoering kan een gelijkaardige opstelling gebruikt worden als de testopstelling waarbij de servers op één en dezelfde machine draaien. Onderliggende besturingssystemen voor de servers kunnen OS/2 en AIX zijn; van de run time client bestaan versies voor Windows, OS/2 en AIX.
Voor de grotere gecentraliseerde omgevingen met relatief kleine belasting van de servers en het netwerk kan het systeem opgezet worden zoals in Figuur 22. Hierbij wordt er gebruik gemaakt van een enkele database server en eventueel meerdere FlowMark servers voor de afhandeling van de procesinstantiaties. Hier dient echter een belangrijke opmerking gemaakt te worden. Indien de verschillende workflow servers dezelfde procesprofielen uitvoeren en dus gebruik maken van dezelfde definities, kunnen deadlocks optreden bij de database server (IBM, 1996g)!
De communicatie
tussen de verschillende domeinen wordt afgehandeld door de
delivery server, die optreedt als database client (IBM, 1996h).
Als netwerkprotocollen worden TCP/IP en APPC ondersteund.
Figuur 22 Scenario met dedicated
database server (IBM, 1996g)
Verder kunnen
meerdere databaseservers gebruikt worden die elk een domein voor
hun rekening nemen (Figuur 23). Deze opstelling is aanvaardbaar
als er meerdere werkgroepen zijn, een groot aantal
procesdefinities en draaiende processen en als de lokaties van de
werkgroepen verspreid zijn. Nadeel is wel dat de procesdefinities
manueel moeten verbreid worden naar de verschillende database
servers aangezien automatische replicatie niet ondersteund wordt.
Figuur 23 Scenario met meerdere database
en run time servers
(IBM, 1996g)
IBM gebruikt bij de beschrijving van het werkstroommodel een aantal termen waarvan de betekenis enigszins afwijkt van deze die er door de Coalitie aan gegeven werd. Deze termen en de impact van de afwijking worden hieronder kort besproken.
Volgens de WfMC Glossary (WfMC, 1996a) is een activiteit de beschrijving van een logische stap binnen een proces, en vormt een activiteit typisch de kleinste eenheid van werk die door een workflow engine wordt gepland. Een activiteit kan een geautomatiseerde activiteit of een manuele activiteit zijn. IBM categoriseert activiteiten als program activities, process activities of blocks.
Hoewel IBM FlowMark positioneert als een product voor procesmodellering, hetgeen verder reikt dan enkel een beschrijving opstellen van activiteiten die geautomatiseerd worden, wordt er nergens naar manuele activiteiten verwezen.
Verder zou volgens de bepalingen van de Coalitie een activiteit moeten opgevat worden als de kleinste eenheid van werk. Procesactiviteiten kunnen in dit opzicht niet als activiteit gedefinieerd worden, maar als subproces (subprocess) en aggregatie van verdere activiteiten. Dit kan van belang zijn omdat uit de interoperabiliteitsmodellen van de Coalitie blijkt dat processen en subprocessen (en niet activiteiten) de basis vormen van coöperatie tussen workflow engines (WfMC, 1996c). Een reden voor het onderscheid kan misschien gevonden worden in de aanpak die gevolgd wordt bij het opstellen van de terminologie. De semantiek bij IBM is gebaseerd op het begrip van processen zoals die gehanteerd worden bij het beschrijven van een organisatie, daar waar de Coalitie eerder een implementatiegerichte visie aanhoudt en processen ziet als een verzameling van activiteiten die door computers en software worden uitgevoerd.
De Coalitie geeft geen sluitende definitie van het begrip "task": het komt zowel voor als synoniem voor "activity" als "work item". De notie van taak als het geheel van activiteit en resource is een benadering die verder gaat dan de invulling die hieraan gegeven wordt door de Coalitie. Niet alleen wordt het begrip activiteit erin opgenomen, ook de bijhorende work items zijn ermee verbonden (aangezien zij bij uitvoering als parameterwaarden zijn opgenomen in een container) en de voorgeschreven uitvoerder of programma. Deze laatste interpretatie lijkt correcter, aangezien bij evaluatie van een taak zowel de activiteit als de uitvoerder van belang zijn. (Zie ook §2.1.1 "Workflow : definitie", p. 1, waar gesteld wordt dat personen binnen een organisatie een functie toegewezen krijgen, en overeenkomstig die functie een bepaald takenpakket opgelegd krijgen. Het uitoefenen van een bepaalde taak impliceert dat een aantal activiteiten uitgevoerd worden).
IBM is stichtend lid
van de Workflow Management Coalition. Het is dan ook niet
verwonderlijk dat FlowMark is opgebouwd volgens het model dat
door de Coalitie naar voor wordt geschoven als raamwerk voor de
standaardisatie.
Figuur 24 FlowMark volgens het
WfMC-referentiemodel (IBM, 1996j)
Hier komt duidelijk de build time client van FlowMark mee overeen. Daarnaast kan hier nog een ander product van IBM geplaatst worden, met name Business Process Modeler. Hiermee kunnen volledige reengineering projecten worden gemodelleerd volgens de IBM LOVEM-techniek (Line of Visibility Enterprise Modeling Technique). Ook bepaalde niet-IBM producten, zoals de ARIS Toolset, kunnen hiervoor aangewend worden, zolang deze in staat zijn definities te genereren die kunnen geïmporteerd worden door FlowMark. Op dit ogenblik wordt enkel FDL (FlowMark Definition Language, zie bijlage voor een voorbeeld) ondersteund. Om meerdere heterogene producten in staat te stellen samen te werken, is een standaard definitieformaat duidelijk onontbeerlijk.
Als we er van uitgaan dat het belang van BPR en de software die erbij gebruikt wordt zich doorzet, dan zal de flexibiliteit en inzetbaarheid van workflow management systemen in grote mate bepaald worden door de koppeling van de ondersteunende producten. Een algemene standaard voor procesdefinities dringt zich op. Niet alleen de gebruikte methodologie voor procesmodellering speelt hierbij een rol, ook de graad van verfijning van het model is van belang (integratie met gegevens uit personeelsdatabanken, toekennen van uitvoerders en platformen, integreren van te gebruiken toepassingen en dergelijke). Op dit ogenblik moet FDL-code die door BPR toepassingen wordt opgesteld, nog steeds verfijnd worden door de build time client door het toevoegen van uitvoerders en te gebruiken applicaties (Leymann, 1997). Bovendien blijft de build time client hoe dan ook nodig, al was het maar om het geïmporteerde model te compileren naar een vorm die kan gebruikt worden door de workflow engine. De FlowMark server en build time client communiceren niet rechtstreeks via API's, maar via de ObjectStore database, die dus de interface vormt tussen process definition en workflow engine (interface 1).
De run time client
verzorgt aan- en afmelding van gebruikers, procesuitvoering en
afhandeling van werklijsten en beschikt over een grafische
gebruikersinterface. Werklijsten en alle verdere informatie
omtrent aan de gang zijnde activiteiten en processen worden op de
database server bijgehouden. De toegang tot de gegevens vindt
plaats via de run time server. Communicatie tussen client en
workflow server gebeurt via API's. Door gebruik te maken van
programmeertaal-API's voor C, C++, REXX, Visual Basic of Cobol
kunnen gegevens uit containers benaderd worden en kunnen
processen gestuurd worden (niet voor Cobol). De functies van de
WAPI, zoals door de Workflow Management Coalition gespecificeerd,
worden geïmplementeerd door een C-API die op haar beurt gebruik
maakt van de FlowMark C++-API (Figuur 25). De specificaties van
de naamgeving en functionaliteit komt overeen met de
WAPI-standaard (zie §3.2.5.3 "De Workflow Application
Programming Interface (WAPI)", p. 1). Deze
"Coalition API" maakt gebruik van een DLL die enkel
beschikbaar is voor OS/2-clients. (IBM, 1996j).
Figuur 25 Relatie tussen API's, client
modules en workflow engine
(IBM, 1996j)
Toepassingen kunnen op drie verschillende manieren met FlowMark geïntegreerd worden (IBM, 1996i). In de eerste plaats kunnen workflow enabled applications geschreven worden in programmeertalen (zie supra) die gebruik kunnen maken van de FlowMark API. In de tweede plaats kunnen bestaande toepassingen op verschillende platformen aangeroepen worden via de programmadefinitiemodule (zie §4.1.5.1 "Program registration", p. 1 en §4.1.5.2 "Local/remote program execution", p. 1), waarbij gegevens via de commandolijn uitgewisseld worden. Op de stations waar deze toepassingen ingeroepen worden, moet de program execution client draaien, die communiceert met de workflow server. Tenslotte kan er gebruik gemaakt worden van een gateway-structuur, het zogenaamde service broker concept, die via API's met de workflow engine communiceert (zie §4.1.5.5 "De service broker manager", p. 1 ).
Op het vlak van directe interoperability is niets voorzien. Coöperatie tussen meerdere servers, al dan niet workflow servers, kan afgedwongen worden door gebruik te maken van service brokers (gateways). Deze kunnen door middel van API's gegevens en commando's uitwisselen. Om FlowMark diensten aan te vragen vanuit een OS/2 of Windows omgeving wordt ook de FlowMark requester meegeleverd (zie §4.1.5.5 "De service broker manager", p. 1). Daarnaast wordt een service broker meegeleverd voor Lotus Notes. Om integratie tussen VisualInfo (een document management product van IBM) en FlowMark te bewerkstelligen, wordt een service broker meegeleverd met VisualInfo.
De toestand van een proces kan opgevolgd worden vanuit een module die deel uitmaakt van de run time client. Er is met andere woorden geen aparte applicatie voor voorzien. De volgende toestanden van activiteiten worden weergegeven: Idle, Ready, Running, Suspended, Force-finished, Finished, Skipped en Disabled (IBM, 1996k). Een aparte server module, de notification service, gaat na of de activiteiten binnen de gestelde tijdsnormen afgewerkt worden. Zoniet wordt de toegewezen uitvoerder op de hoogte gebracht, en na een tweede oproep wordt ook de procesbeheerder ingelicht.
De audit logs zijn gewone tekstbestanden die automatisch door de database server aangemaakt worden. Er worden geen toepassingen meegeleverd die de gegevens grafisch voorstellen of interpreteren. Er wordt wel een programma meegeleverd waarmee de audit trails kunnen geïmporteerd worden in een DB2 database. In een logbestand wordt onder meer volgende informatie opgeslagen (IBM, 1996j):
Deze gegevens worden enkel gelogd indien daarvoor gekozen werd bij de definitie van het proces.
Zoals reeds in de inleiding gesteld werd, richt FlowMark zich op de markt van heavy of production workflow. Om ook ondersteuning te bieden voor andere vormen van samenwerking, bijvoorbeeld via e-mail, is integratie met een ander type workflow systeem wenselijk.
FlowMark biedt standaard ondersteuning voor zowel sterk gestructureerde werkstromen, als voor exception handling en ook voor predefined team semistructured workflow (vergelijk met kolommen 4, 3c en 3b van Figuur 2 op p. 1). Automatische exception handling kan gemodelleerd worden bij de creatie van de procesdefinitie. Ondersteuning voor groepen waarbij de precieze uitvoerder niet van belang is, gebeurt door deze personen op te nemen in bepaalde organisatorische eenheden, of door hen een rol toe te kennen (cf. de paragraaf over "Staff definition" op p. 1). Men kan dan tijdens de procesdefinitie opgeven dat een activiteit op de werklijsten terechtkomt van alle uitvoerders die tot een bepaalde eenheid behoren. Van zodra deze activiteit door één bepaalde uitvoerder geselecteerd wordt voor uitvoering, verdwijnt deze van de werklijsten van de andere kandidaat-uitvoerders (zie tevens het stuk over "Process execution", p. 1).
Door gebruik te maken van de diensten van Notes kan men bovendien de andere gebieden van het spectrum bestrijken. Standaard voorziet Notes in messaging en shared databases. Door Notes functionaliteiten in te roepen door middel van een programma-activiteit (zie "Process definition", p. 1) met een eigen entry conditie en een exit conditie waarvan de toestand bepaald wordt op basis van waarden die door Notes worden teruggegeven, kan ook een opstelling zoals in kolom 3a van Figuur 2 gemodelleerd worden.
Interactie met Notes
kan tot stand komen door gebruik te maken van het service broker
concept (§4.1.5.5 "De service broker manager",
p. 1), zoals weergegeven in Figuur 26. Deze keer is echter
FlowMark vragende partij, en is de Notes-server de
dienstverlener.
Figuur 26 Toegang tot Notes door gebruik
van een service broker (IBM, 1996i)
Een FlowMark activiteit roept een Notes service aan via de requester, die de aanvraag eerst doorstuurt naar de service broker manager. Deze selecteert de juiste service broker die de aanvraag verder afhandelt. De Notes service-DLL voorziet onder andere in diensten als het openen en sluiten van Notes databases en het creëren, opvragen, encrypteren, signeren en verwijderen van 'notes' (berichten). Daarnaast is het ook mogelijk gegevens uit een Notes database op te zoeken door gebruik te maken van views die in Notes gedefinieerd werden.
Vrij recent bracht IBM ook een Lotus Notes client voor FlowMark uit (hierbij treedt FlowMark terug op als server). Hiermee kunnen de gegevens van werklijsten (de work items) voorgesteld worden als berichten uit een Notes database. Het laat toe in Notes templates te ontwikkelen die de werklijst van een gebruiker voorstellen als een formulier. Zo kan ook een "postbakje" ontworpen worden waar zowel standaard e-mail als workflow work items in terecht komen. Figuur 2 toont hoe een combinatie van workflow en e-mail toelaat om ad-hoc workflow exceptions af te handelen (een combinatie van kolom 3a en 3c): wanneer een exception optreedt kan een gebruiker eerst via een discussiedatabase van Notes met collega's overleggen vooraleer acties te ondernemen om het FlowMark proces te laten verdergaan. De Notes client laat tenslotte ook toe om werk af te handelen zonder constant op het netwerk aangesloten te zijn (bij het gebruik van een draagbare PC bijvoorbeeld). FlowMark processen kunnen gewoon terug verder gaan van zodra de client terug op het netwerk is aangekoppeld en zijn afgewerkte work items ter beschikking stelt.
Twee punten van kritiek op het referentiemodel hadden betrekking op enerzijds het ontbreken van een theoretisch gefundeerd metamodel, en anderzijds op de gebrekkige benadering van databeheer in een werkstroomomgeving. Het eerste punt werd behandeld in §4.1.5, en in deze paragraaf wordt gekeken op welke manier aan het andere tekort kan tegemoet gekomen worden. Eerst wordt bekeken waarom traditionele oplossingen moeilijk in een werkstroomomgeving ingepast kunnen worden. Vervolgens worden twee methoden voor geïntegreerd transactiebeheer beschreven. Voor elk van de methoden worden de voor- en nadelen besproken. Er dient opgemerkt dat geen enkele van onderstaande benaderingen standaard gevolgd wordt bij FlowMark, maar dat de implementaties theoretisch wel mogelijk zijn.
Transacties in een workflow management systeem verschillen in zekere mate van transacties zoals die gekend zijn uit de wereld van de database systemen. Zo komen in een workflow management systeem vaak zowel transactie- als niet-transactie-activiteiten voor (Leymann, 1997). De activiteiten die deel uitmaken van primaire bedrijfsprocessen, zullen vaak transactie-activiteiten zijn (bijvoorbeeld voorraadwijzigingen). Dit betekent dat de uitvoering van deze activiteiten moet voldoen aan de ACID-eigenschappen. Daarnaast komen ook niet-transactie-activiteiten voor die eerder betrekking hebben op ondersteunende processen waarvan de correcte uitvoering niet precair is voor het goede verdere verloop van het proces (bijvoorbeeld het opstellen van een onkostennota).
Het systeem moet in staat zijn om meerdere transacties te aggregeren tot een nieuwe transactie, omdat bepaalde transacties binnen eenzelfde proces semantisch niet onafhankelijk zijn: indien de ene transactie niet succesvol kan beëindigd worden, moet de andere ook ongedaan gemaakt worden (bijvoorbeeld bij het parallel uitvoeren van activiteiten die later samenkomen). De activiteiten die uitgevoerd worden maken vaak deel uit van processen die een lange doorlooptijd vergen en intermediaire resultaten produceren. Bijgevolg moet het transactiesysteem in staat zijn een lang tijdsbestek te overspannen, ermee rekening houdend dat het systeem tussentijds kan stilgelegd worden of uitvallen. Het gebruik van traditionele technieken als locking is hier dus niet aanvaardbaar. In deze context werd het begrip geïntroduceerd van compensation spheres:
"a compensation sphere is any collection of activities of a process model such that finally either all activities must have run successfully, or all activities must have been compensated" (Leymann, 1997)
Binnen een dergelijke compensatiesfeer wordt voor elke activiteit een compenserende activiteit gedefinieerd die de resultaten die door de eerste activiteit geproduceerd waren, ongedaan maakt en de gegevens in hun oorspronkelijke staat herstelt. Deze opeenvolgende, succesvol uitgevoerde activiteiten worden dan ongedaan gemaakt door de compenserende activiteiten in omgekeerde volgorde uit te voeren en aldus het systeem in zijn originele toestand terug te brengen.
Het coördineren van transacties waarbij verschillende activiteiten betrokken zijn, gaat verder dan de doelstellingen van een gedistribueerd transactiesysteem. Het is namelijk het workflow management systeem dat dynamisch het uitvoeringspad bepaalt, en zo de activiteiten die gecoördineerd dienen te worden. Deze logica is niet voorgeprogrammeerd in de objecten die deel uitmaken van het proces, zoals dat in traditionele gedistribueerde transactiemanagementsystemen wel het geval is. Activiteiten die elk individueel een commit/abort-protocol implementeren, kunnen opgenomen worden in een zogenaamde atomic sphere:
"An atomic sphere is a set of activities each of which is "transactional" in the sense that they access recoverable resources. Furthermore, the control flow between two transactional activities of an atomic sphere must not leave the sphere and enter it again at a later point in time." (Leymann, 1997).
Het is de taak van het workflow management systeem om bij voltooiing een globale commit te bevelen. Atomaire sferen hebben echter het nadeel dat ze gebruik maken van 2-phase commit protocollen, en dus veel berichten genereren en gebruik maken van tussentijdse locking, zodat performantieproblemen en deadlocks kunnen optreden. Tenslotte moet er rekening gehouden worden met het heterogene karakter van een workflow management systeem (Alonso et al., 1996). Methodes voor transactiebeheer moeten dan ook onafhankelijk zijn van de onderliggende logische en fysieke databasemodellen (relationeel, objectgeoriënteerd etc.). Ook dit houdt in dat systemen voor herstel moeten voorzien worden op applicatieniveau, hetgeen betekent dat het workflow management systeem hiervoor moet instaan.
Onder een saga verstaat men een transactie met lange levensduur (long-lived transaction) die bestaat uit een aantal subtransacties die een eenheid vormen in termen van de ACID-eigenschappen. In tegenstelling tot een locking-protocol, laat een saga-model toe dat een transactie gegevens vrijgeeft vooraleer te committeren (Alonso et al. (b)). Een saga bestaat uit twee fasen: tijdens de eerste fase worden de subtransacties uitgevoerd. Indien een subtransactie beslist tot een abort, dan worden in de tweede fase de reeds uitgevoerde subtransacties ongedaan gemaakt door compenserende activiteiten.
Om een FlowMark procesmodel te vertalen naar een saga-model, gaat men als volgt te werk (Alonso et al. (b)). Elke activiteit van een proces wordt aanzien als een subtransactie. Alle subtransacties van een saga worden vervolgens gegroepeerd in een block (zie p. 1, "Process definition"). Met elke controleconnector is een transitieconditie geassocieerd die aangeeft of de vorige activiteit succesvol is uitgevoerd of niet. (Hiertoe wordt, in het geval van een programma-activiteit, de return-code van programma als parameter doorgegeven). Bovendien wordt dit gegeven gekopieerd naar de output container van het block waartoe de activiteit behoort. Op die manier wordt bijgehouden hoe ver de saga was gevorderd, en welke activiteit als laatste succesvol werd uitgevoerd. Indien de transitieconditie van een bepaalde activiteit als 'false' wordt geëvalueerd, aborteert de saga en wordt in de tweede fase een andere saga ingeroepen die de inverse activiteiten start op basis van de gegevens in de output container van het aborterende block. Een block voert een commit uit indien de laatste activiteit van het block committeert.
Het gebruik van saga's beperkt zich echter tot het efficiënt afhandelen van exceptions (het falen van programma's, of meer algemeen, activiteiten), maar leunt voor consistente uitvoering van processen nog steeds op de onderliggende database(s). Indien, zoals bij FlowMark, het database systeem over onvoldoende backup en recovery mogelijkheden beschikt, kunnen de waarden van transitiecondities en output containers verloren gaan. Daardoor is men verder aangewezen op de forward recovery mogelijkheden van het databasemangement systeem, maar door het eventueel dubbel uitvoeren van reeds gecommitteerde activiteiten kunnen inconsistenties geïntroduceerd worden.
Om de beschikbaarheid van de werkstroomgegevens te kunnen vrijwaren in grote omgevingen, werd binnen het Exotica project ook een backup-architectuur ontwikkeld die kan geïmplementeerd worden in FlowMark (Alonso et al., 1996). Waar de benadering van linear saga's zich richt tot de semantiek van het workflow management systeem, wordt hier aandacht besteed aan de fysieke consistentie van de werkstroomgegevens.
Uitgangspunt is een model zoals in Figuur 23 (p. 1). Elke database server kan gebruikt worden als primaire server voor het eigen domein, en als secundaire (backup) server voor een andere primaire server.
Men gaat uit van drie types van processen, en met elk daarvan is een backup strategie verbonden:
In grote omgevingen waar duizenden processen tegelijkertijd uitgevoerd worden, kunnen vrij snel performantieproblemen opduiken. Hier is dan ook extra aandacht aan besteed. Verder gaan de auteurs van het model ervan uit dat recovery en backup moet kunnen gebeuren over heterogene databasesystemen heen. Zij kiezen dan ook voor een oplossing waarbij geen gebruik gemaakt wordt van replicatie van table spaces of logbestanden, maar zij nemen de toestandsgegevens van werkstroomobjecten (activiteiten, connectoren, parameters en dergelijke) als basis voor replicatie. Alleen de veranderingen van deze elementen worden naar de backup server gestuurd. Op de database servers zelf gebeurt dan een vertaling van deze gegevens naar een logisch en fysiek databasemodel.
Indien een primaire databaseserver uitvalt, stelt de backup server een nieuwe backup server aan, en neemt de uitvoering van de primaire over. Indien de secundaire server werkt volgens een cold standby principe, moet dan wel nog eerst de database bijgewerkt worden vooraleer de verwerking van het proces kan overgenomen worden. Wijzigingen op "belangrijke" maar "niet kritieke" gegevens zijn immers nog niet noodzakelijk doorgevoerd, hoewel ze wel al zeker ontvangen zijn.
De cold standby opstelling heeft het voordeel sneller te zijn, omdat de secundaire server een commit uitvoert na ontvangst van de replicatiegegevens, en leent zich daarom vooral om gebruikt te worden bij de processen waarvan veel instantiaties gecreëerd worden. Deze processen worden dan beschouwd als "belangrijk", maar niet "kritiek". Zij heeft echter het nadeel dat het overschakelen naar de backup server meer tijd vergt dan in het geval waar een hot standby secundaire server wordt gebruikt (Alonso et al., 1996). Bovendien bestaat het gevaar dat de consistentie verloren gaat indien de secundaire de wijzigingen niet kan verbreiden op de kopie van de database; de transactie is dan immers al gecommitteerd.
Dit model is toepasbaar in een omgeving waar meerdere (eventueel heterogene) database subsystemen worden gebruikt. Het gaat er echter wel van uit dat de workflow servers homogeen zijn, of minstens dezelfde run time gegevensformaten kunnen gebruiken. Dit is bijvoorbeeld niet het geval wanneer FlowMark uitgebreid wordt met Lotus Notes.
Sinds kort is IBM ook met FlowMark op het Internet aanwezig. Dit wordt verwezenlijkt door het IBM Internet Connection for FlowMark-pakket. De voordelen liggen in het vlak van "inter enterprise workflow" en "electronic commerce" (Figuur 27 - Reynaert, 1996). Daarnaast wordt het ook mogelijk om werknemers op verplaatsing deel te laten nemen aan de werkstroom. Ze dienen hiertoe enkel over een PC met Internet aansluiting en een webbrowser te beschikken.
IBM Internet
Connection for FlowMark bestaat uit drie componenten die op de
server-zijde inwerken: een webserver interface, een internet
gateway en een program execution module (zie Figuur 28). Als
client volstaat een gewone webbrowser die HTML 2.0 kan weergeven.
Als server platform wordt enkel OS/2 ondersteund.
Figuur 27 Electronic commerce op
Internet
Vanaf de browser wordt een connectie gemaakt met de traditionele webserver. Via de CGI-interface wordt vervolgens een verbinding opgezet met de Internet gateway. De CGI-interface extraheert de parameters uit de HTML-code en stuurt die door naar de Internet gateway. Deze gaat toegangsrechten na en bouwt een aanvraag op die doorgestuurd wordt naar de workflow server, en treedt dus op als worklist handler. Toepassingen die gegevens moeten kunnen verwerken van en terugsturen naar een webclient, moeten speciaal gedefinieerd worden. Een dergelijke toepassing wordt dan een web-enabled activity program genoemd, omdat het in staat is toepassingsgegevens uit te wisselen met een webbrowser. Zo kunnen parameters van de webbrowser vertaald worden naar input container gegevens, en kunnen output container gegevens in parameters gegoten worden die door de webclient kunnen verwerkt worden. Hiertoe worden ze eerst terug in een HTML-bestand verpakt door de CGI-interface.
Er worden een aantal
HTML-voorbeeldbestanden met het pakket meegeleverd die kunnen
aangewend worden om webpagina's te maken voor het starten en
beheren van processen en het afhandelen van werklijsten (zie
Figuur 29).
Figuur 28 Werking van Internet
Connection for FlowMark (IBM, 1997)
De functionaliteit
die door de webbrowser kan geleverd worden is echter beperkt. Dit
vloeit voort uit de statische benadering van het
internet-concept. Webbrowsers werken van nature uit volgens een
'pull'-principe, waarbij de gebruiker zelf bepaalt welke gegevens
worden opgevraagd en doorgestuurd. (Dit wordt bijvoorbeeld
geïllustreerd de 'next screen'-lijst op Figuur 29, waardoor de
gebruiker zelf veranderingen van de werklijsten dient na te
gaan). Het is verder ook niet mogelijk om lokale toepassingen te
laten uitvoeren onder controle van de workflow server, gezien er
geen alternatief voorzien is voor de lokale program execution
client. Het blijft nog afwachten hoe IBM zal inspelen op de
evoluties die nog volop aan de gang zijn in de wereld van
Internet, zoals dynamische uitbreidingen van HTML, het
push-concept en Java.
Figuur 29 Webbrowser als run time client
Zoals reeds vroeger werd gesteld kan FlowMark steunen op goede theoretische fundamenten. Het gaat uit van een wiskundig model voor procesmodellering, dat geïmplementeerd wordt door toepassing van moderne objectgeoriënteerde technologie. Als een van de weinige commerciële producten maakt het gebruik van een objectgeoriënteerde database, wat zeker revolutionair is voor een omgeving waar men zware belasting van de database server mag verwachten.
Omtrent de performantie van dit onderdeel kunnen echter vragen gesteld worden, zeker als we zien dat in de handleidingen bijzonder veel aandacht besteed wordt aan de fine-tuning van de database. De centrale database is ook een kwetsbaar punt van het ganse systeem. Ondersteuning voor andere databases is niet voorzien; FlowMark V2R2 is bijgevolg ook niet database onafhankelijk. Wanneer meerdere run time servers gebruik maken van dezelfde database server, kunnen deadlocks optreden. Indien men gebruik wil maken van meerdere database servers, moeten de procesdefinities manueel gerepliceerd worden. De ObjectStore database is niet rechtstreeks toegankelijk, en het beheer ervan moet gebeuren vanop de commandoregel. Ook de herstelmogelijkheden lijken onvoldoende uitgebouwd: transactiebeheer is niet standaard ingebouwd, en reservekopies van de gegevens moeten manueel gemaakt worden.
De client-server opstelling maakt het beheer van het workflow management systeem er niet eenvoudig op. Het lijkt onvermijdelijk dat in grotere omgevingen gespecialiseerde workflow en database managers noodzakelijk zijn om het beheer van procesdefinities, personeelsgegevens en databases in goede banen te leiden. Daar staat tegenover dat in grotere bedrijven de werklast kan verdeeld worden over meerdere servers. De meegeleverde beheerstools voor auditing en rapportering vallen ook wat mager uit.
IBM biedt een fors uitgebouwd raamwerk voor integratie van FlowMark met andere systemen door een open omgeving (request brokers, MQSeries) met goed gedocumenteerde API's. Waar het systeem in release 2 nog sterk georiënteerd was naar IBM-platformen (servers enkel beschikbaar onder OS/2 en AIX, build time client enkel voor OS/2, APPC-protocol enkel onder OS/2), lijkt hierin met de recente versie 3 enige verandering in gekomen te zijn (zo zijn de servers nu ook beschikbaar voor Windows NT).
Een sterk punt is de integratie met Internet, hoewel hier nog enige ruimte is voor vooruitgang, bijvoorbeeld door de functionaliteit van de run time client volledig toegankelijk te maken voor webbrowsers (de client als Java-toepassing?). Een mooi perspectief voor de integratie van workflow management met electronic commerce.
Voor de bespreking van een tweede workflow management systeem gaan we kijken naar wat FileNet te bieden heeft. Ook hier gaan we wat dieper in op de terminologie en implementatie van het product. De bespreking blijft verder beknopt door gebrek aan technische informatie. Handleidingen of functionele versies van het product waren niet beschikbaar. De documentatie die door de marketing afdeling van Olivetti werd doorgestuurd beperkte zich tot een samenvatting van een technische beschrijving van het product. De vraag naar een metamodel waarop het systeem gebouwd was, of naar documentatie van de API's en naar de relaties met de Workflow Management Coalition leverden niets op.
De evaluatie van het systeem is dan ook opgesteld op basis van een korte kennismaking met Visual WorkFlo in de Generale Bank.
Visual WorkFlo is een product van FileNet Corporation en wordt in Europa verdeeld door Olivetti (tegenwoordig Olsy). FileNet is voornamelijk actief in de wereld van document imaging en document management. Op het vlak van workflow ondersteuning biedt FileNet drie producten aan: FileNet:WorkGroup, FileNet Visual WorkFlo en FileNet Ensemble.
FileNet:WorkGroup is een document imaging en workflow management systeem bedoeld voor werkgroepen en departementen binnen kleine tot middelgrote ondernemingen. Voor administratieve ad-hoc workflow is er Ensemble, dat samenwerkt met Novell GroupWise of Microsoft Exchange. Visual WorkFlo is dan weer afgestemd op de markt van production workflow systemen.
Visual WorkFlo is een objectgeoriënteerde client-server toepassing die bestaat uit drie componenten, met name Visual WorkFlo/Composer, Visual WorkFlo/Performer en Visual WorkFlo/Conductor (zie verder). De basis van het systeem wordt gevormd door zogenaamde werkobjecten of work objects. De processen die de work objects verwerken worden beschreven in instruction sheets, en elke stap in een proces wordt een work performer genoemd.
Visual WorkFlo is opgebouwd volgens een objectgeoriënteerde architectuur die het mogelijk maakt work objects en instruction sheets te gaan hergebruiken.
Een te bouwen toepassing kan gebruik maken van templates voor verschillende soorten werk. Dergelijke template bevat de definities van van de work objects die zowel toepassingsgegevens (application data) als werkstroomrelevante gegevens (workflow relevant data) bevatten. Toepassingsgegevens kunnen formulieren, documenten of rapporten uit een onderliggend COLD-systeem zijn, multimediale gegevens als audio of video of andere data. De werkstroomrelevante gegevens omvatten routing en statistische informatie met betrekking tot het object waartoe ze behoren. Ook gegevens die te maken hebben met beveiliging, zoals gebruikersrechten, worden mee opgenomen.
De procesroute en de acties die uitgevoerd moeten worden op de work objects worden vastgelegd in instruction sheets. Deze kunnen eveneens als opmaakprofiel dienen voor andere processen.
Instruction sheets worden opgebouwd uit work performers, die eigenlijk activiteiten zijn. Zo'n work performer kan een voorgedefinieerde activiteit zijn uit de instruction palette zoals 'suspend processing' of een zelfstandig programma. Voorbeelden van dergelijke programma's kunnen zijn (Bartholomew, 1997):
Met behulp van de performers kunnen dus software acties gemodelleerd worden (via DDE of OLE, programma's geschreven in C, Visual Basic, etc.), kan randapparatuur aangestuurd worden voor input of output (printers, faxen, scanners) of kan aangegeven worden dat menselijke tussenkomst vereist is.
System instruction work performers kunnen controle-operaties uitvoeren zoals
De work object templates worden work classes genoemd. Work classes en instruction sheets ondersteunen overerving en polymorfisme.
De composer is een Microsoft Windows applicatie die een aantal hulpmiddelen aanbiedt om de bouwblokken van een werkstroomsysteem te definiëren en in elkaar te steken. Door gebruik te maken van de Windows "drag and drop" interface kan de werkstroom binnen een departement of bedrijf visueel worden voorgesteld en kunnen flowcharts aangemaakt worden. Verder wordt een notebook representatie gebruikt waarmee de eigenschappen van procesdefinities en werkobjectdefinities kunnen ingesteld worden. Met behulp van de Composer kunnen applicaties gebouwd worden die dynamische routering en werklastverdeling omvatten. De definities kunnen in real-time aangepast worden. Er is voorzien in tweewegsintegratie tussen de Composer en business process reengineering tools, in de zin dat de WorkFlo software rechtstreeks kan gevoed worden met het ontwerp van de BPR tool, en dat statistische gegevens die betrekking hebben op productiviteit vanuit de Composer kunnen overgedragen worden aan de BPR tool (cf. infra, Visual WorkFlo/Conductor). (Bartholomew, 1997a).
Composer draait op Microsoft Windows 3.1, Windows 95, Windows NT of IBM OS/2.
De Performer is de run time control component (enactment service) van het workflow management systeem. Zowel het 'push' als het 'pull' werkstroommodel worden ondersteund. Het presenteert de eindgebruikers de te verwerken werkobjecten of geeft hen de toestemming deze van een lijst af te halen. De Performer bepaalt de status van de werkobjecten en bepaalt de volgende uit te voeren work performer (activiteit).
Het systeem maakt gebruik van een relationeel database management systeem. Work objects met al hun relevante gegevens worden hierin opgeslagen als binary large objects (BLOBs). Voor elk object worden slechts twee rijen in de database bijgehouden om performante opvragingen te garanderen. Meerdere SQL-transacties kunnen worden samengenomen in één remote procedure call (zogenaamde bulk transactions). Het aantal werkobjecten dat opgevraagd wordt met een RPC kan ingesteld worden, om op die manier het aantal connecties dat moet opgezet worden met de database te minimaliseren en antwoordtijden te verbeteren.
De Performer vereist Image Management Services (IMS) software 3.2.2 of Visual WorkFlo/Services en een IBM RS6000 met AIX 3.2.5, een HP9000 met HP/UX 9.04, Sun Solaris 2.4 of Windows NT/AS 3.5, Oracle 7.0 of andere databases die IMS ondersteunt. (Bartholomew, 1997b).
Conductor voorziet in de beheers- en onderhoudshulpmiddelen om een Visual WorkFlo toepassing te beheren, opvolgen, veranderen en modelleren. Het traceert volume en doorvoersnelheid van werk in uitvoering. Statistieken die worden bijgehouden van work objects hebben betrekking op de snelheid waarmee deze verwerkt worden, het aantal objecten in het systeem aanwezig en het aantal objecten dat per uur wordt gecreëerd. Statistieken van work performers houden bij hoeveel mensen aan een bepaalde taak werken, de gemiddelde duurtijd van de volledige uitvoering van de performer en de gemiddelde doorvoersnelheid per uur. Informatie over wachtrijen geeft aan hoe lang objecten in de wachtrij verblijven, hoeveel er in de wachtrij aanwezig zijn en de gemiddelde wachttijd in de wachtrij.
Veranderingen kunnen in real-time plaatsvinden en eerst worden gesimuleerd vooraleer over te gaan tot implementatie: het herverdelen van de werklast of veranderen van zowel gegevens als definities van werkobjecten of processen is mogelijk terwijl uitvoering bezig is.
In tegenstelling tot FlowMark start Visual WorkFlo automatisch roll-back en roll-forward operatiesindien het serversysteem is platgegaan tijdens een operatie. In het geval het systeem de gegevens niet automatisch kan herstellen, worden de betreffende werkobjecten naar de Conductor gestuurd voor manuele herstelling. (Bartholomew, 1997c).
Het bleek bijzonder moeilijk om technische documentatie te verkrijgen over het product Visual WorkFlo. Ook de goede bedoelingen van de Belgische verdeler (aanvankelijk Olivetti, tegenwoordig onder de naam Olsy) konden hier weinig aan veranderen. Deze korte evaluatie is dan ook gebaseerd op besprekingen van het product tijdens bezoeken aan de Generale Bank (Generale Bank, 1996), waar het product wordt geïntegreerd met de document management oplossingen van FileNet en een e-mail systeem van Digital, Oasis.
De integratiekost was de drijvende factor bij de keuze en implementatie van een werkstroomsysteem voor het opvolgen en beheren van de afhandeling van kredieten bij de Generale Bank. Aangezien men reeds over een imaging en document management systeem van FileNet beschikte, viel de keuze voor een werkstroomsysteem al snel op het product Visual WorkFlo van hetzelfde software bedrijf.
Uitgaande van de implementatie bij de bank, lijkt goede integratie op het eerste zicht een troef te zijn van Visual WorkFlo.
De implementatie gebeurt in een sterk heterogene omgeving: FileNet draait in de zonezetels op een IBM RS6000 server met Oracle database en COLD-hardware. De input voor het workflow systeem passeert langs de API en komt van e-mail of gebeurt door het gebruiken van scanners of faxtoestellen. Ook voor de output wordt gebruik gemaakt van de API, en deze output gaat naar printers, faxen of e-mail. Het e-mailpakket is geïnstalleerd op een Digital VAX. Printaanvragen worden doorgestuurd naar printerservers en scannen gebeurt op speciale scanstations. Voor faxverkeer worden faxservers gebruikt en applicaties worden afgeladen van file servers. Als werkstations worden Intel machines gebruikt met Windows for Workgroups (3.11) en binnenkort wordt overgeschakeld naar Windows NT 4.0 Workstation. Deze systemen zijn via een ethernet LAN met elkaar verbonden. Het geheel staat op zijn beurt in verbinding met de filialen via G-Net, een X.25 WAN.
Snelheid en performantie worden verzekerd door gebruik te maken van prefetching technieken, waarbij de benodigde documenten op voorhand worden opgevraagd bij de imaging server, en door caching op speciaal daartoe voorziene servers.
Bij de implementatie
van het geheel komt behoorlijk wat programmeerwerk kijken. Visual
WorkFlo beschikt dan ook niet over een grafische interface
voor de client. Notificatie en integratie aan de client-zijde
moeten dus volledig zelf geschreven worden door toepassingen te
bouwen (in dit geval met PowerBuilder) die "workflow
enabled" zijn en gebruik maken van de API's van het product.
Het was niet mogelijk om na te gaan in hoeverre deze overeenkomen
met de WfMC WAPI-standaarden. Het beoordelen van integratie is
dus moeilijk: enerzijds geeft de praktijk aan dat onder andere
e-mailsystemen kunnen geïntegreerd worden (in dit geval Digital
Oasis), aan de andere kant gaat dit gepaard met hoge kosten
omwille van het vele programmeerwerk.
© Filip Schepers, 1997 - Thesis: Standaardisatie van workflow management systemen en beoordeling van een aantal producten.