Wat is een proces?
Concept
Een proces is een unieke instantie van een workflow. We kunnen ook spreken over unieke process instances die afgeleid zijn van een generieke process definition.
Types processen
Het proces dat verantwoordelijk is voor de opstart van het dossier, noemen we het hoofdproces. Vanuit dit hoofdproces kan je andere processen aanroepen en opstarten (zie call activities & called workflows). Een bijkomende mogelijkheid is dat er een binnen een proces een subproces genest zit.
Workflow engine
Processen worden uitgevoerd door de Camunda workflow engine volgens de XML-beschrijving van de BPMN-workflow. De workflow engine begeleidt en orchestreert het proces en houdt er op elk moment de correcte status van bij. Het verdeelt op de gepaste momenten de gepaste taken aan de gepaste uitvoerders. Met uitvoerders bedoelen we menselijke gebruikers (zie gebruikerstaken), interne Skryv backend functies (zie servicetaken), de DMN-engine (zie business rule taken) of externe services (zie servicetaken & connectoren).
Process token
De process token symboliseert de status van het proces op elk gegeven ogenblik. Je kan je de process token voorstellen als een bolletje die zich doorheen de workflow beweegt (zie screenshots hieronder). Een process token kan nooit op twee of meerdere plaatsen tegelijk zijn. Aldus vermijdt het ambiguïteit en garandeert het de integriteit van de processtatus, en bij uitbreiding de dossierstatus.
BPMN-elementen
De workflow bestaat uit verschillende BPMN elementen zoals events, flows, activities, enzovoort. Elk element heeft zijn eigen betekenis en beïnvloedt het verloop van het proces op zijn eigen manier.
Life cycle van een proces
Processen initiëren
Het hoofdproces is opstartbaar via specifieke triggers vanuit de frontoffice, de backoffice of via de exposed API. Bij opstart van het hoofdproces volgt meteen ook de initialisatie van een nieuw dossier met een unieke business key. Deze key wordt ook toegekend aan het hoofdproces en alle daaruit voortvloeiende gelinkte processen. Op die manier ontstaat een logisch geheel of samenhangende context.
Processen uitvoeren
Elke keer dat er een nieuw proces wordt gestart, wordt er een process token aangemaakt. De token ontstaat in het start event. Vervolgens duwt de workflow engine de token voort langs de verschillende paden en elementen zoals beschreven in de BPMN-workflow. Vooral bij gateways bestaat de mogelijkheid dat de process token zich opsplitst in twee of meer onderling gelinkte tokens. Al deze tokens bewegen nu tegelijkertijd door de workflow. Op een verder gelegen punt in de workflow kunnen deze tokens weer worden samengevoegd (of niet). Het proces wordt voltooid als alle onderling gelinkte process tokens een end event hebben bereikt, of als één van hen een terminate end event bereikt.
Voorbeeld 1
Eén enkele process token wordt door de workflow gepusht door de process engine.
Voorbeeld 2
De process token splitst zich in twee gekoppelde tokens. Het proces eindigt als beide tokens een end event bereiken.
Zoals hierboven aangehaald, is het mogelijk dat binnen een proces een subproces genest zit, of dat er vanuit het proces andere processen opgestart worden. Deze zijn allemaal onderling gelinkt en kunnen (naargelang configuratie) informatie met elkaar uitwisselen. Uiteindelijk werken ze allen samen aan de opbouw van een concreet dossier.
De uitvoering van elk proces vertoont een zekere ritmiek en cadans. Zo komt de process token regelmatig tot stilstand. Bijvoorbeeld in een gebruikerstaak waar het moet wachten op de uitvoering van de taak door een menselijke gebruiker. Of in een intermediate event waar het wacht op een specifieke timer of message. Daarnaast zijn er ook stukken van de workflow die in één vloeiende beweging (synchroon) uitgevoerd worden. Deze afwisseling tussen asynchrone en synchrone stukken wordt geconfigureerd binnen de BPMN-beschrijving van de workflow en heeft belangrijke technische en functionele implicaties. Klik hier voor meer informatie over asynchroniciteit.
Proces- & dossierinformatie opbouwen
Naargelang een process token zich doorheen de workflow beweegt, laat het een spoor achter. Dit spoor noemen we het uitvoeringspad of execution path en wordt gedocumenteerd via concrete procesinformatie.
Het is duidelijk dat een uitvoeringspad niet één op één samenvalt met de volledige BPMN beschrijving van de workflow. Het kan heel goed zijn dat het proces slechts één pad binnen de workflow bewandelt en dat vele andere mogelijke paden nooit actief worden.
De opgebouwde procesinformatie vormt een belangrijke bron voor de opbouw van het dossier en de daarin opgenomen dossierinformatie.
Processen opvolgen en consulteren
Eindgebruikers
In tegenstelling tot dossierinformatie is procesinformatie standaard niet toegankelijk voor eindgebruikers. Het bevat immers een grote hoeveelheid technische data zonder enige relevantie voor de doelgroep.
Hierop zijn een aantal uitzonderingen:
Backoffice dossierpagina bevat een aantal schermen (gepaste UI-autorisatie vereist) waar het verloop en de historiek van processen gevisualiseerd worden (zie bijvoorbeeld diagrammen).
Frontoffice dossierpagina bevat een voortgangsbalk waar de burger de status van zijn of haar dossier kan aflezen. De voortgangsbalk is niet standaard zichtbaar, maar moet opgezet worden door de configurator (zie de secties mijlpalen en dossiertype instellingen voor meer info).
Zowel binnen de backoffice als de frontoffice komen de gebruikerstaken en al hun gerelateerde informatie naar boven.
Via expliciete configuratie is het altijd mogelijk om vanuit de workflow specifieke procesinformatie bewust te gaan opslaan in formuliervelden.
Configuratoren en infrastructuurbeheerders
Voor configuratoren en infrastructuurbeheerders is toegang en diepgaand inzicht in de technische procesinformatie wel relevant. Denk bijvoorbeeld aan volgende use cases.
Configuratoren bouwen iteratief aan hun workflows en configuratie-items. Telkens er een change of aanpassing is, willen ze die testen, waarbij ze onvermijdelijk tegen fouten aanlopen. Inzicht in deze onregelmatigheden is essentieel om verder te gaan met configureren.
Infrastructuurbeheerders van applicaties willen incidenten in de productieomgeving zo snel mogelijk kunnen detecteren en analyseren.
Om deze noden te lenigen, schuift Skryv volgende oplossingen naar voren.
Binnen de backoffice is er een ondersteuningsportaal dat informatie visualiseert over alle incidenten binnen de applicatie. Er is ook een retry-functionaliteit per incident.
Binnen Studio verschijnen de logs voor de preview omgeving van de applicatie.
De volledige procesinformatie met alle logs en alle functionaliteiten op vlak van incident management wordt per applicatieomgeving toegankelijk gemaakt via de Camunda cockpit.
Processen verwijderen
Nadat de laatste token in alle binnen een dossier onderling gelinkte processen een end event heeft bereikt, is het dossier volledig en compleet opgebouwd. Nu het doel bereikt is, verliest het proces als middel zijn relevantie. Toch worden processen voor de eeuwigheid bijgehouden in de applicatie. Mocht dit niet wenselijk zijn, dan zijn er een aantal manieren om in te grijpen.
Configuratoren kunnen via de anonymisatie functionaliteit op een gerichte manier alle procesvariabelen binnen de scope van een specifiek proces verwijderen. Meestal gaat het om gevoelige, persoonsgebonden data.
IT-infrastructuurbeheerders kunnen via de Camunda cockpit specifieke processen verwijderen.
IT-infrastructuurbeheerders kunnen rechtstreeks op de database ingrijpen en zo processen definitief verwijderen uit de applicatie.