BPMN: les événements de bord et la compensation

Le chapitre sur la grammaire des événements a posé les trois positions du flux, la capture et l’émission, le caractère interruptif et les treize déclencheurs. Il réservait à celui-ci deux emplacements: la bordure d’une activité et l’événement de début d’un sous-processus événementiel.

L’attachement à la bordure

Un des usages de l’événement intermédiaire est le traitement des exceptions et de la compensation, noté en plaçant l’événement sur la bordure d’une tâche ou d’un sous-processus, en vue réduite comme en vue développée¹. L’événement peut se rattacher à n’importe quel endroit de la bordure, et son flux sortant partir dans n’importe quelle direction; le standard recommande, pour la clarté du diagramme, un emplacement constant, par exemple le bas de l’activité avec un flux dirigé vers le bas puis vers la droite quand le diagramme se lit horizontalement¹.

Le rattachement tient en deux attributs: attachedTo désigne l’activité concernée, cancelActivity décide de son sort quand le déclencheur survient².

À cette position, la capture est le seul mode¹: le marqueur d’un événement de bord est toujours vide, la règle générale du standard voulant qu’un déclencheur capturé porte un marqueur non rempli³.

Le flux d’exception

Le flux d’exception (exception flow) se déroule hors du flux normal du processus et repose sur un événement intermédiaire rattaché à la bordure d’une activité, survenant pendant l’exécution de cette activité³. Les éléments qu’il met en route forment le gestionnaire d’événement (event handler), le terme que le standard emploie pour la procédure déclenchée⁴.

Silver en décrit la lecture: tant que l’activité s’exécute, le processus écoute ce signal. Si le signal survient avant que l’activité s’achève, le flux d’exception se déclenche. Si l’activité s’achève d’abord, il est ignoré et le processus continue sur le flux normal sortant de l’activité⁵.

Dumas et ses coauteurs en tirent une question de conception préalable: il faut décider de la portée pendant laquelle le processus doit être réceptif à cet événement. Quand la portée couvre une seule tâche, l’événement se rattache à cette tâche; quand elle en couvre plusieurs, les activités concernées s’encapsulent dans un sous-processus et l’événement se rattache à sa bordure⁶.

Bordure et flux normal: le même symbole

Le dessin d’un événement de bord et celui d’un événement intermédiaire de capture placé dans le flux normal se ressemblent: même cercle à double trait, même marqueur vide. La position change le sens.

Dans le flux normal, un événement de capture retient le jeton jusqu’à ce que le déclencheur survienne, puis le laisse repartir sur le flux sortant¹. Sur une bordure, l’événement écoute pendant que l’activité s’exécute, et le chemin qu’il ouvre reste conditionnel: sans déclencheur avant l’achèvement, ce chemin n’est jamais emprunté⁵.

La compensation suit la même règle: le marqueur plein dans le flux normal ordonne la compensation¹, le marqueur vide sur une bordure déclare le gestionnaire qui l’exécutera².

Les règles de raccordement

Trois règles gouvernent les flux d’un événement de bord².

• Il ne peut jamais être la cible d’un flux de séquence.
• Il doit être la source d’un flux de séquence.
• Plusieurs flux de séquence peuvent en partir; chacun engendre un nouveau chemin parallèle.

La compensation fait exception à la deuxième et à la troisième: son événement de bord n’a aucun flux de séquence sortant, et il porte à la place une association².

Silver en fait une règle de style: un événement de bord a un flux sortant et un seul⁵.

L’événement de bord interruptif

Un événement de bord interruptif se dessine avec un double trait continu, tracé qui pose implicitement cancelActivity à true². Quand l’événement survient, l’activité associée est terminée; un jeton est engendré en aval, qui active l’élément suivant du processus, relié à l’événement par le flux d’exception⁴.

Sur la figure ci-dessus, l’arrivée du message d’annulation met fin à la préparation de l’expédition et le processus repart sur « Rembourser le client ». Le flux normal sortant de l’activité reste inutilisé.

L’événement de bord non interruptif

Un événement de bord non interruptif se dessine avec un double trait interrompu, tracé qui pose cancelActivity à false². Quand l’événement survient, l’activité associée reste active. Un jeton est engendré pour le flux de séquence sortant de l’événement, en parallèle de l’exécution; le standard demande de veiller à la façon dont ce flux rejoint le flux principal, en recommandant de le terminer sur son propre événement de fin⁴.

Quand l’activité n’est pas annulée, plusieurs instances du gestionnaire peuvent s’exécuter en parallèle². Pour les gestionnaires non interruptifs, ce nombre reste illimité pour une même déclaration d’événement, tandis qu’un seul gestionnaire interruptif est admis par déclaration, parce qu’il termine l’activité parente dès qu’il s’achève⁴.

Silver situe l’apport de la variante: les événements non interruptifs, nouveaux dans BPMN 2.0, sont probablement le plus important ajout à la palette, et sur le flux d’exception ils portent des actions qui s’ajoutent à celles du flux normal⁵. Il précise la lecture d’une minuterie de bord: le chronomètre démarre quand le flux de séquence entre dans l’activité, et l’alarme se déclenche si l’activité n’est pas achevée à l’échéance; tester la durée avec une passerelle placée après l’activité arriverait trop tard, puisque le processus n’atteint cette passerelle qu’une fois l’activité terminée⁵.

Dumas et ses coauteurs donnent le même mécanisme sous le titre Activity Timeouts: la minuterie s’active au démarrage de l’activité englobante, et fonctionne comme un délai maximal⁶. Ils rangent la variante non interruptive parmi les moyens de déclencher une procédure parallèle sans arrêter le travail en cours⁷.

Les déclencheurs admis au bord

Dix des treize déclencheurs sont admis à cette position. Un événement intermédiaire rattaché à la bordure d’une activité doit porter l’un des suivants: message, minuterie, erreur, escalade, annulation, compensation, condition, signal, multiple, multiple parallèle².

Le tableau des valeurs possibles de cancelActivity dit, déclencheur par déclencheur, si le choix du tracé est ouvert².

Cinq lignes demandent un commentaire.

L’erreur interrompt toujours: aucune variante non interruptive n’existe, si bien que le trait reste continu². L’annulation aussi, avec une restriction de position: elle ne se rattache qu’à la bordure d’un sous-processus dont l’attribut de transaction vaut true².

La compensation échappe à la distinction: la portée à laquelle elle s’applique s’est déjà exécutée et ne peut plus être annulée au moment où la compensation se déclenche². Son trait reste continu.

Le multiple hérite du plus restrictif de ses déclencheurs: le choix reste ouvert si tous les déclencheurs assignés l’autorisent; il se ferme sur l’interruptif dès qu’une erreur ou une annulation figure parmi eux².

L’escalade, enfin, part du réglage inverse de celui de l’erreur: le standard précise qu’une escalade est par défaut réputée ne pas arrêter l’activité à laquelle l’événement de bord est rattaché, le modélisateur pouvant revenir sur ce réglage par la notation².

Trois déclencheurs restent hors de cette liste. L’événement neutre intermédiaire n’est valide que dans le flux normal, ce que le standard écrit explicitement¹. Le lien de même, sa paire n’ayant de sens qu’à l’intérieur d’un même niveau de processus¹. La terminaison n’existe qu’en événement de fin⁸.

Le sous-processus événementiel

Un sous-processus dont l’attribut triggeredByEvent vaut true est un sous-processus événementiel (event sub-process)⁹. Le chapitre sur les sous-processus l’annonçait comme le quatrième tracé de bordure: un rectangle à coins arrondis dessiné avec un seul trait fin en pointillé⁹.

Il se situe hors du flux normal de son processus parent: aucun flux de séquence entrant ni sortant⁹. Là où un sous-processus ordinaire prend le flux du parent pour déclencheur, celui-ci a un événement de début porteur d’un déclencheur; il démarre chaque fois que cet événement survient pendant que le processus parent est actif⁹. Il peut ne pas survenir du tout, comme il peut survenir plusieurs fois⁹. Le sous-processus événementiel doit porter exactement un événement de début⁹.

En vue réduite, son événement de début lui sert de marqueur, dans le coin supérieur gauche du symbole⁹.

La figure suivante développe « Préparer l’expédition » et y écrit un troisième gestionnaire.

Quand le sous-processus événementiel est déclenché, le parent est interrompu ou poursuit son travail. Le type de l’événement de début tranche⁹. L’attribut isInterrupting ne s’applique qu’aux événements de début de sous-processus événementiel et vaut true par défaut¹⁰. Comme pour un événement de bord, le trait continu marque l’interruptif et le trait interrompu le non interruptif¹⁰.

Les déclencheurs de son événement de début

Le standard donne deux listes qui ne coïncident pas. La clause sur les sous-processus en cite sept: message, erreur, escalade, compensation, condition, signal, multiple⁹. La clause sur les événements de début en cite neuf, en annonçant les mêmes types que pour les événements de bord: message, minuterie, escalade, erreur, compensation, condition, signal, multiple, multiple parallèle¹⁰. Le tableau 10.86 détaille cette seconde liste ligne à ligne, et c’est elle qui fait foi ici. L’annulation est absente des deux.

Trois lignes de ce tableau se distinguent¹⁰.

• L’escalade de début n’est autorisée que pour déclencher un sous-processus événementiel.
• L’erreur interrompt toujours, la nature même de l’erreur l’imposant.
• La compensation n’interrompt jamais, puisque le processus doit être achevé avant qu’elle puisse se déclencher.

L’attribut isInterrupting suit ces deux dernières lignes: il ne s’applique ni à l’erreur, où il vaut toujours true, ni à la compensation, où il est sans objet¹⁰.

Le bord ou le sous-processus événementiel

Les deux constructions traitent le même genre de situation. Le standard décrit ce qui se passe quand elles sont posées toutes les deux pour la même définition d’événement: si le sous-processus événementiel réémet l’événement après s’être achevé, l’événement de bord se déclenche; s’il s’achève sans le réémettre, l’activité est réputée achevée et le flux de séquence normal reprend⁴. Le standard résume: le sous-processus événementiel absorbe l’événement⁴.

Les gestionnaires de bord s’exécutent hors du sous-processus, de sorte qu’ils n’accèdent pas à son contexte⁴. Un gestionnaire écrit à l’intérieur du sous-processus s’exécute dans ce contexte.

Dumas et ses coauteurs tranchent le choix par un critère de portée. Un sous-processus événementiel est autonome et doit se conclure sur un événement de fin, ce qui interdit de raccorder sa procédure au reste du flux de séquence; en revanche il se définit à l’échelle d’un processus entier là où un événement de bord se rapporte à une activité déterminée. Le sous-processus événementiel peut en outre être défini comme processus global puis réutilisé ailleurs. D’où leur recommandation: le sous-processus événementiel quand l’événement peut survenir à tout moment du processus ou quand la procédure mérite d’être réutilisée, l’événement de bord dans les autres cas¹¹.

Silver ajoute que le sous-processus événementiel se mappe plus facilement vers BPEL et accède au contexte du niveau de processus où l’événement survient, deux questions de développeur qui relèvent du BPMN exécutable¹². Et il couvre un cas hors d’atteinte de l’événement de bord: aucun événement ne se rattache à la bordure d’un processus de premier niveau, alors qu’un sous-processus événementiel interruptif s’y place et peut donc terminer une instance de ce processus depuis l’intérieur¹².

La compensation

Compenser, c’est défaire des étapes déjà achevées avec succès, parce que leurs résultats et leurs effets de bord ne sont plus désirés¹³. Le chapitre sur les tâches a posé le marqueur d’activité, celui sur les événements le déclencheur; le mécanisme complet tient en trois pièces: l’activité de compensation, l’événement de compensation en capture qui la désigne, l’événement de compensation en émission qui commande l’opération.

La compensation ne porte que sur une activité achevée; une activité encore active s’annule. Cette annulation peut à son tour entraîner la compensation des portions déjà achevées avec succès de l’activité, s’il s’agit d’un sous-processus¹³.

Le gestionnaire de compensation

La compensation est exécutée par un gestionnaire de compensation (compensation handler), un ensemble d’activités qui ne sont raccordées à aucune autre portion du modèle¹³. Il commence par un événement de compensation en capture, qui est soit un événement de bord, soit l’événement de début d’un sous-processus événementiel de compensation¹³.

Un gestionnaire raccordé par un événement de bord ne peut effectuer qu’une compensation en « boîte noire » de l’activité d’origine. Elle se modélise par une activité de compensation, tâche ou sous-processus, reliée à l’événement de bord par une association¹³. Cette activité porte un marqueur qui signale qu’elle sert uniquement à la compensation et qu’elle se situe hors du flux normal du processus¹³; l’attribut derrière ce marqueur est isForCompensation, qui vaut false par défaut et dit que l’activité n’est activée que lorsqu’un événement de compensation est détecté¹⁴.

L’association de compensation qui les relie se déroule hors du flux normal et sa cible doit être marquée comme activité de compensation³.

L’événement de bord de compensation capture, donc son marqueur est vide. Une compensation émise visant cette activité le déclenche². Silver en donne la lecture: sa raison d’être est de relier une activité à son activité de compensation, rien de plus¹⁵.

La compensation ne prend que si l’activité rattachée s’est achevée¹⁶. Silver la détaille: une activité qui n’a pas démarré, qui s’exécute encore ou qui s’est achevée sans succès au moment de l’échec ne voit pas son activité de compensation s’exécuter, même si celle-ci est définie¹⁵.

Le déclenchement

La compensation se déclenche par un événement de compensation en émission, qui est un événement intermédiaire ou un événement de fin¹³. Le standard en décrit l’origine caractéristique: il est levé par un gestionnaire d’erreur, dans le cadre d’une annulation, ou récursivement par un autre gestionnaire de compensation¹³.

La figure suivante fait suivre l’emballage d’un losange, la passerelle exclusive que documente le chapitre sur les passerelles.

Deux attributs paramètrent l’émission¹⁷.

• activityRef désigne l’activité à compenser. Sans désignation, la compensation est diffusée à toutes les activités achevées du sous-processus courant, ou de l’instance de processus entière au niveau global.
• waitForCompletion vaut true par défaut: l’émission attend l’achèvement du gestionnaire déclenché. À false, elle déclenche la compensation puis poursuit immédiatement, ce qui était le comportement de BPMN 1.2.

Silver nomme cette construction le Compensation throw-catch: le besoin de défaire apparaît après que l’activité visée s’est achevée. La cible du déclenchement est alors l’activité elle-même, ce qui n’exige aucune transaction¹⁵.

Le sous-processus événementiel de compensation

L’autre forme de gestionnaire est un sous-processus événementiel dont l’événement de début porte la compensation. Il se place dans un processus ou un sous-processus, se situe lui aussi hors du flux normal, et accède aux données de son parent telles qu’elles étaient à l’instant où ce parent s’est achevé, un instantané que le standard appelle snapshot data¹³. Il peut déclencher récursivement la compensation des activités que son parent contient¹³.

Dans l’exemple du standard, le gestionnaire exécute les activités de compensation dans un ordre différent de celui de la marche avant, en ajoutant une activité supplémentaire porteuse d’une logique que le corps du sous-processus ne suffit pas à déduire¹³.

La compensation par défaut

Un sous-processus peut être déclaré compensable sans qu’un gestionnaire soit défini. L’attribut compensable du sous-processus, lorsqu’il est posé, définit implicitement une compensation par défaut, laquelle compense récursivement toutes les activités achevées avec succès à l’intérieur de ce sous-processus¹³. La sémantique opérationnelle précise l’ordre: les activités de compensation s’exécutent dans l’ordre inverse de l’exécution des activités d’origine, la concurrence restant permise là où aucune dépendance n’existait; un flux de séquence de A vers B impose que la compensation de B précède celle de A¹⁸.

Un sous-processus en boucle ou à instances multiples possède un instantané par instance; déclencher la compensation du sous-processus déclenche celle de toutes les instances de la portée courante, un gestionnaire de bord étant alors invoqué une fois par instance¹³. La sémantique opérationnelle nuance ce dernier point: une activité de compensation associée n’est déclenchée qu’une fois et doit donc compenser les effets de toutes les instances¹⁸.

L’abandon présumé

La compensation applique un « principe d’abandon présumé » (presumed abort principle), dont le standard tire trois conséquences¹³.

• Compenser une activité en échec reste sans effet.
• Quand une activité échoue, c’est-à-dire quand elle est quittée parce qu’une erreur a été émise, il revient au gestionnaire d’erreur de garantir qu’aucune compensation supplémentaire ne sera nécessaire une fois qu’il aura terminé.
• Quand aucun sous-processus événementiel d’erreur n’est défini pour un sous-processus et une erreur donnés, le comportement par défaut appelle la compensation de toutes les activités contenues dans ce sous-processus si cette erreur est levée.

Le chaînage de l’annulation et de la compensation

Le dernier morceau du mécanisme est l’événement de bord d’annulation, dont l’unique emplacement légal est la bordure d’un sous-processus de transaction². Il se déclenche quand un événement de fin d’annulation est atteint à l’intérieur de la transaction, ou quand un message « Cancel » du protocole transactionnel arrive pendant que la transaction s’exécute². Il interrompt toujours². Le chapitre sur les sous-processus documente la transaction, ses trois issues et son retour au processus parent; ce chapitre-ci n’en retient que le chaînage avec la compensation, l’apport propre de l’annulation.

Le standard soumet les activités contenues aux actions d’annulation, lesquelles peuvent inclure un retour en arrière et la compensation de certaines activités, et ajoute que les autres mécanismes d’interruption d’une transaction ne provoquent aucune compensation¹⁹. Silver détaille l’enchaînement: l’annulation ordonne implicitement la compensation, de sorte que toutes les activités achevées avec succès à l’intérieur de la transaction et pourvues d’une activité de compensation sont défaites, puis le traitement de l’exception commence sur le flux d’exception ou le sous-processus événementiel associé à l’annulation²⁰.

Du côté de l’exécution, un événement de fin d’annulation n’est admis que dans le contexte d’un sous-processus de transaction; il annule ce sous-processus en abandonnant la transaction associée⁴.

Les classes de conformité

La sous-classe descriptive ne contient aucun événement de bord²¹.

La sous-classe analytique en ouvre six. Le message, la minuterie, le signal et la condition y figurent dans leurs deux variantes; l’erreur dans sa seule variante interruptive; l’escalade dans sa seule variante non interruptive²¹. Restent hors des deux sous-classes les quatre autres déclencheurs de bord, annulation, compensation, multiple et multiple parallèle, ainsi que le sous-processus événementiel, qu’aucun des deux tableaux ne mentionne²¹.

Silver situe le seuil du côté de l’outil: un outil qui prend en charge la sous-classe analytique sait dessiner les événements de bord non interruptifs, le double trait interrompu, qu’il range avec l’escalade et les magasins de données parmi les nouveautés utiles de BPMN 2.0¹².

Au bord d’une activité à instances multiples, enfin, un événement d’erreur n’interrompt que l’instance depuis laquelle l’erreur est levée, tandis que les autres événements de bord interruptifs, message, minuterie, signal et condition, interrompent toutes les instances²².

Le chapitre suivant

BPMN: les passerelles. Les cinq passerelles BPMN, exclusive, parallèle, inclusive, événementielle et complexe, la division et la fusion, le marqueur en croix et le flux par défaut.

Notes et références