Subprocessen
Definitie
Een subproces is een proces dat genest zit binnen een hoofdproces. Een subproces behelst een welomschreven stuk van de workflow met één duidelijke functie. Een subproces heeft twee weergaves: expanded view (met alle details zichtbaar) of collapsed view (zonder details).
Er zijn drie types subprocessen, elk met eigen use case, symbolen en gedrag.
Embedded subprocess
Event subprocess
Transactional subprocess
Use case
Via embedded subprocessen kan je het hoofdproces onderverdelen in verschillende compartimenten die elkaar sequentieel opvolgen. Dit zorgt ervoor dat het geheel duidelijk leesbaar is (bijvoorbeeld voor een business owner) en minder foutgevoelig wordt (hoofdproces en subprocessen worden voor een stuk ontkoppeld).
Via een event subprocess kan je gebeurtenissen opvangen die op een willekeurig moment binnen de scope van het proces kunnen optreden. Onder gebeurtenissen vallen messages, signals, timers, escalations, compensations, conditions, enzovoort.
Binnen een transactional subprocess kan je de verschillende activiteiten die onderling logisch samenhangen (en waarvan je wil dat ze allen samen slagen, dan wel mislukken) binnen één geheel onderbrengen. Het bijzondere aan dit type subprocess is dat je het kan cancellen waardoor alle reeds uitgevoerde externe acties automatisch gecompenseerd worden (op voorwaarde dat je de nodige compensation activities definieert).
Symbool
Een embedded subproces wordt weergegeven door een afgeronde tegel. Bij de collapsed view verschijnt een plus icoon onderaan de tegel.
Een event subprocess wordt weergegeven door een vierkante of licht afgeronde tegel waarvan de rand bestaat uit een stippellijn. Binnen Studio kan dit type subproces niet ingeklapt (collapsed) worden.
Een transactional subprocess wordt weergegeven door een afgeronde tegel waarvan de rand bestaat uit een dubbele lijn. Binnen Studio kan dit type subproces niet ingeklapt (collapsed) worden.
Beheer subproces
Schakelen tussen de verschillende types subprocessen of tussen de expanded view en de collapsed view gebeurt via het 
icoon. Via het eigenschappen panel krijg je toegang tot onderstaande instellingen.
Tabblad gevanceerd > general
Eigenschap | Beschrijving |
|---|---|
Id | Unieke key of id van het subproces. |
Name | Naam of label van het subproces zoals visueel zichtbaar in de bpmn-workflow. |
Asynchronous before | |
Asynschronous after | |
Exclusive | Enkel beschikbaar indien Asynchronous before en/of Asynchronous after ingeschakeld zijn. Zie asynchroniciteit voor meer info. |
Element documentation | Volledige beschrijving van het element als de |
Tabblad geavanceerd > variables
Oplijsting van procesvariabelen aangemaakt binnen de scope van het subproces.
Tabblad geavanceerd > listeners
Listeners zijn scripts of expressies die getriggerd worden bij opstart of op het einde van het subproces. Zie de pagina over listeners voor meer info.
Tabblad geavanceerd > input/output
Declareren en mappen van input en output parameters. Zie verder hieronder voor extra uitleg.
Gedrag embedded subproces
Gedrag embedded subproces binnen hoofdproces
Een embedded subproces maakt integraal deel uit van de workflow die het hoofdproces weergeeft, d.w.z. het zit in dezelfde bpmn-workflow definitie. Het subproces wordt getriggerd door een incoming process token. Eenmaal het subproces beëindigd is, wordt een outgoing process token doorgegeven. Op die manier bekeken, functioneert een subproces precies zoals een taak. In onderstaand voorbeeld volgen vijf subprocessen elkaar sequentieel op. Bemerk dat deze dichtgeklapt zijn (collapsed view) zodat het geheel overzichtelijk blijft voor een business owner.
Intern gedrag embedded subproces
Als je de interne opbouw van een subproces van naderbij bekijkt, dan merk je dat een subproces altijd start met één en slechts één start event (“untyped”). Daar wordt een subprocess token gecreëeerd. Het subproces eindigt wanneer dit subprocess token (of alle onderling gelinkte subprocess tokens) bij een end event is (of zijn) aangekomen. Een subproces heeft dus een interne opbouw en werking zoals bij een workflow. Het is een workflow in de workflow. In het onderstaand voorbeeld zullen er in het subproces ‘Controle aanvraag’ twee taken aangemaakt worden, ééntje voor dossierbehandelaar A en ééntje voor dossierbehandelaar. Pas op het ogenblik dat beide afgerond zijn, wordt het subproces afgesloten en gaat het hoofdproces verder. Zie ook het voorbeeld onderaan.
Input- en outputvariabelen
Om een subproces hermetisch af te sluiten van het hoofdproces (compartimenteren), maak je gebruik van input- en outputvariabelen. Via inputvariabelen creëer je lokale variabelen die enkel binnen de scope van het subproces geldig zijn. Via outputvariabelen zet je lokale informatie vanuit het subproces terug om naar globale procesvariabelen. Door in het subproces enkel gebruik te maken van lokale variabelen ontkoppel je het dus van het hoofdproces. Dit betekent dat wijzigingen in de workflow geen onbedoelde invloed kunnen hebben op wat er in het subproces gebeurt, en vice versa. Dit alles zorgt ervoor dat je het subproces makkelijker kan beheren en aansturen. Het geheel wordt bovendien robuuster en minder foutgevoelig.
Voor een meer praktische uitleg, zie workflows > taken > taak input & output parameters.
In het voorbeeld hieronder zie je hoe het subproces de functie ‘Documenten versturen’ uitvoert. Als input neemt het de lokale variabele ‘getal’ (hier gemapt op de procesvariabele formulier.geefGetal), als output produceert het de procesvariabele ‘documentVerstuurd’ (boolean).
Gelijkenissen en verschilpunten met called workflows
Zowel bij embedded subprocessen als bij called workflows is het mogelijk om binnen een workflow een andere workflow aan te roepen en op te starten. Hoewel er inderdaad gelijkenissen zijn, bestaan er toch ook enkele fundamentele verschilpunten.
Gelijkenissen
Subproces | Called workflow |
|---|---|
Het hoofproces activeert het subproces en wacht totdat het subproces afgesloten is vooraleer zelf verder te gaan. | Het hoofdproces roept een andere workflow aan en wacht totdat deze afgesloten is vooraleer zelf verder te gaan. |
Een subproces heeft een lokale scope waarin je lokale variabelen kunt definiëren die geen effect uitoefenen op het hoofdproces. | Een called workflow heeft een eigen scope met eigen variabelen die geen effect uitoefenen op het hoofdproces. |
Verschilpunten
Subproces | Called workflow |
|---|---|
Hoofdproces en subproces zitten vervat in één enkele BPMN-workflow definitie. | De twee worflows hebben elk een aparte BPMN-workflow definitie. |
Een subproces is niet apart versioneerbaar. Het maakt immers deel uit van één en dezelfde BPMN-workflow definitie. | Een called workflow is apart versioneerbaar. Dit betekent dat je vanuit het hoofdproces een specifieke versie van de called workflow kan aanroepen. |
Hoofdproces en subproces maken noodzakelijkerwijs deel uit van één en hetzelfde dossiertype. | De twee workflows kunnen ofwel deel uitmaken van hetzelfde ofwel van een ander (gelinkt) dossiertype. Beide opties zijn mogelijk. |
Hoewel je in de praktijk met lokale variabelen werkt, kan het subproces beschikken over alle informatie die in de scope van het hoofdproces beschikbaar is (d.w.z. de globale variabelen). | Wanneer je werkt met een call activity heeft de aangeroepen worfklow geen enkele notie van het eerste proces. In dat geval moet je expliciet vastleggen welke informatie je van het ene naar het andere proces overbrengt. Dit gebeurt via mapping van globale procesvariabelen. |
Een subproces is altijd een bpmn-proces. | Een called workflow kan ofwel van het type bpmn, ofwel van het type cmmn zijn. |
De use case van een subproces is het duidelijk structureren en compartimenteren van een workflow. Dit om de leesbaarheid te verhogen en de foutgevoeligheid te verminderen. | De use case van een called workflow is het centraliseren van bepaalde gestandaardiseerde functies die gedeeld kunnen worden over verschillende worfklows heen. |
Gedrag event subprocess
Gedrag event subprocess binnen het hoofdproces
Ook een event subprocess maakt integraal deel van het hoofdproces en zit dus vervat binnen dezelfde BPMN-definitie (XML). Het grote verschil met een embedded subprocess is dat een event subprocess niet opgenomen is in de vaste flow van het hoofdproces. Het hangt als het ware te ‘zweven’ binnen het hoofdproces en wordt niet getriggerd door een incoming process token, maar door een gebeurtenis of trigger die zich voordoet. Hieronder vallen messages, signals, timers, escalations, compensations, conditions, enzovoort. Elk event subprocess kan slechts één trigger hebben en zit geconfigureerd binnen een start event. De trigger is ofwel interrupting (d.w.z. het hoofdproces wordt volledig stopgezet en afgesloten), ofwel non-interrupting (d.w.z. het hoofdproces loopt gewoon verder en het event subprocess start er parallel mee op).
Intern gedrag event subprocess
Het intern gedrag van een event subprocess is volledig gelijklopend met dat van een embedded subprocess, met uitzondering van het start event dat nooit leeg ('untyped') kan zijn, maar een specifieke trigger of gebeurtenis moet bevatten. Zie ook voorbeeld hieronder.
Gedrag transactional subprocess
Gedrag transactional subprocess binnen het hoofdproces
Een transactional subprocess is een specifieke vorm van een embedded subprocess (zie ook hoger). Het expliciteert het concept van een transactie binnen de context van de workflow engine. Een transactie is een logisch samenhangend geheel van taken waarvan je wil dat ze ofwel samen slagen, ofwel samen falen. Vanaf het ogenblik dat één taak faalt, zal je typisch een cancellation throw event opwerpen en deze opvangen via een cancallation catch event dat als boundary event op het transactional subprocess gedefinieerd zit. Dit triggert tegelijk alle compensation activities die via boundary events vastgemaakt zitten op de taken binnen het subprocess. Op die manier zullen alle reeds uitgevoerde taken (of die nu succesvol waren of niet), teruggedraaid of gecompenseerd worden.
Intern gedrag transactional subprocess
Het interne gedrag van een event subprocess is gelijklopend met dat van een embedded subprocess, alleen zal het typisch cancellation en compensation events bevatten. Zie ook voorbeeld hieronder.
Subprocess markers (uitvoeringsmodus)
Net als bij taken(zie deze sectie) is het mogelijk om aan subprocessen specifieke markers toe te voegen.
Parallel multi-instance
Per item in een input collectie (zoals een lijst) moet een aparte instantie van het subproces opgestart en uitgevoerd worden. Parallel betekent dat alle instanties tegelijk worden aangemaakt. Deze marker kan je op dezelfde manier instellen als bij de task markers.
Sequential multi-instance
Per item in een input collectie (zoals een lijst) moet een aparte instantie van het subproces opgestart en uitgevoerd worden. Sequentieel betekent dat instanties één na één worden aangemaakt. De eerste moet afgewerkt zijn vooraleer de tweede klaargezet wordt. Deze marker kan je op dezelfde manier instellen als bij de task markers.
Loop
Een subproces dat meerdere keren wordt uitgevoerd totdat aan een specifieke conditie is voldaan. Dit element wordt echter niet ondersteund door de Camunda 7 workflow engine.
Ad hoc
De ad hoc marker geeft aan dat het subproces een verzameling is van flows en/of tools die al dan niet gebruikt kunnen worden in het proces. Dit element wordt echter niet ondersteund door de Camunda 7 workflow engine.
Voorbeeld embedded subproces
In onderstaand voorbeeld hebben we het aanmaken en klaarzetten van communicaties in de frontoffice ondergebracht in een subproces. Zie expanded view. Dit subproces zit genest in het hoofdproces.
Expanded view
Collapsed view
Eenmaal we tevreden zijn over de werking ervan kunnen we omschakelen naar de collapsed view. Op die manier wordt het volledige proces een stuk overzichtelijker.
Voorbeeld event subprocess
In onderstaand voorbeeld zijn twee event subprocesses gedefinieerd. Beiden worden getriggerd door een timer event. Het verschil is dat de bovenste het hoofdproces niet onderbreekt (non-interrupting), terwijl de onderste dat wel doet (interrupting).
Voorbeeld transactional subprocess
In onderstaand voorbeeld modelleert het transactional subprocess de verwerking van de aanvraag. Deze bestaat in essentie uit twee stappen ('Doe A' & ‘Doe B’). Als deze beide succesvol zijn, dan sluit het subproces zichzelf op normale manier af. Indien niet, dan wordt de verwerking van de aanvraag gecancelled. Het subprocess sluit zichzelf af via het cancellation throw event en de process token verlaat het subprocess via het cancellation boundary event. Tegelijk worden de compensation activities ‘Draai A terug' en ‘Draai B terug’ uitgevoerd.
