BPMN: les sous-processus

Une tâche est atomique. Quand le travail qu’elle nomme se décompose en un enchaînement d’étapes, le symbole change.

Le sous-processus (sub-process)

Un sous-processus est une activité dont le détail interne est modélisé avec des activités, des passerelles (gateway), des événements et des flux de séquence¹. C’est un objet graphique du processus contenant, qui peut s’ouvrir sur un processus de niveau inférieur¹.

Il délimite en outre une portée: visibilité des attributs, portée transactionnelle, exceptions, événements et compensation¹.

Le symbole reprend la forme de la tâche, le rectangle à coins arrondis, et le standard impose un seul trait fin¹. Trois autres tracés sont réservés, chacun à un sous-processus particulier¹:

• le trait épais à l’activité d’appel (call activity);
• le pointillé au sous-processus événementiel (event sub-process);
• le double trait à la transaction.

Le sous-processus ad hoc garde le trait fin et se signale par un marqueur.

Ce symbole correspond à l’embedded sub-process de BPMN 1.2¹. Le nom survit dans une partie des outils et de la littérature.

La vue réduite (collapsed)

Un sous-processus réduit masque son détail. Un marqueur le distingue de la tâche: le standard impose un petit carré portant un signe plus, au bas du symbole et centré¹.

La vue développée (expanded)

Un sous-processus développé montre son détail à l’intérieur de la vue du processus qui le contient¹. Le contenu prend la place du marqueur.

Les deux figures décrivent le même modèle. Silver l’établit sur la sérialisation: le XML des deux vues est identique². Le choix relève de la mise en page.

Le niveau enfant

Le contenu d’un sous-processus forme un niveau enfant, ce que Silver appelle le child level². Il se dessine de deux façons: à l’intérieur du symbole développé, comme sur la figure précédente, ou sur un diagramme séparé auquel le symbole réduit renvoie par un hyperlien². La seconde, qu’il appelle la modélisation hiérarchique, tient le processus de bout en bout sur une page et repousse chaque détail d’un cran².

Une règle vaut dans les deux cas: un flux de séquence ne franchit pas la bordure d’un sous-processus. Le standard l’énonce dans son tableau des éléments étendus³. Silver en fait l’une des règles fondamentales de la notation².

Le contrôle passe donc par les événements. À l’arrivée du flux de séquence sur le symbole parent, le processus repart de l’événement de début du niveau enfant; quand il atteint l’événement de fin de ce niveau, il reprend sur le flux de séquence sortant du symbole parent².

L’événement de début d’un sous-processus est de ce fait neutre. Le standard l’écrit: l’événement de début neutre s’emploie pour tous les sous-processus, intégrés comme appelés, les autres déclencheurs restant hors d’usage puisque le jeton venu du processus parent tient lieu de déclencheur⁴. Silver y insiste, en la donnant pour une règle du standard plutôt que pour une règle de style².

Le sous-processus développé sans étiquette

Un sous-processus développé sans étiquette, contenant des activités qu’aucun flux de séquence ne relie, montre un groupe d’activités parallèles sous une forme compacte; le standard appelle cet usage une parallel box¹. Il se passe d’événement de début, d’événement de fin et des flux qui y mèneraient. Le standard y voit la raison pour laquelle ces deux événements sont optionnels¹.

Silver en précise le comportement: toutes les activités enfants deviennent exécutables ensemble, dans un ordre indifférent, et toutes doivent être achevées pour que le sous-processus le soit⁵. Il range la construction parmi les héritages de BPMN 1.0 et la juge de peu d’utilité⁵.

Les marqueurs du sous-processus

Les trois marqueurs posés par le chapitre sur les tâches s’appliquent au sous-processus. Le standard compte cinq marqueurs de sous-processus¹. Le premier est celui de la vue réduite, le petit carré au signe plus. Les quatre autres sont la boucle, les instances multiples, la compensation et le marqueur ad hoc. Un sous-processus réduit peut porter jusqu’à trois de ces quatre-là, dans toutes les combinaisons sauf la boucle avec les instances multiples¹. Une tâche en porte au plus deux⁶.

Tous les marqueurs présents sont groupés, l’ensemble étant centré au bas du symbole¹.

Le sous-processus ad hoc (ad-hoc sub-process)

Un sous-processus ad hoc rassemble des activités entre lesquelles aucune relation de séquence n’est exigée⁷. Le modèle définit l’ensemble des activités; leur ordre et leur nombre d’exécutions sont déterminés par les exécutants⁷.

Le marqueur est un tilde, au bas du symbole et centré⁷. Il se combine avec n’importe quel autre⁷.

Les activités y sont généralement déconnectées. Pendant l’exécution, une ou plusieurs d’entre elles peuvent être actives, chacune pouvant s’exécuter plusieurs fois⁷. Les exécutants décident du moment où chacune commence⁷.

L’exemple du standard est la rédaction d’un chapitre de livre: rechercher le sujet, écrire le texte, le corriger, produire les graphiques, les insérer, organiser les références⁷. Des dépendances existent, écrire avant de corriger, sans qu’une instance de l’écriture corresponde à une instance de la correction: la correction est rare et porte sur le texte produit par plusieurs écritures⁷.

Dumas emploie la construction pour la répétition non contrôlée, le client qui s’informe de l’avancement de sa commande, modifie ses coordonnées ou l’annule, jusqu’à ce qu’une condition soit remplie⁸.

Silver donne le critère d’achèvement: le sous-processus ad hoc est achevé quand l’exécutant le déclare achevé, sans que toutes les activités enfants aient à être exécutées⁵.

Les attributs

Trois attributs paramètrent le comportement⁷.

• ordering vaut parallel par défaut: un nombre quelconque d’activités du sous-processus, de zéro à leur totalité, peut s’exécuter en parallèle. La valeur sequential restreint l’exécution à une activité à la fois, restriction que le standard rattache au partage d’une ressource.
• completionCondition porte une expression: quand elle s’évalue à true, le processus est terminé.
• cancelRemainingInstances ne s’applique qu’en ordonnancement parallèle. Il décide du sort des instances en cours au moment où la condition d’achèvement devient vraie.

Le contenu autorisé

Le standard restreint les éléments BPMN utilisables à l’intérieur⁷.

• L’activité doit y figurer.
• L’objet de données (data object), le flux de séquence, l’association, l’association de données, le groupe, le flux de message (message flow, en source ou en cible), la passerelle et l’événement intermédiaire peuvent y figurer.
• L’événement de début, l’événement de fin, les conversations et les liens de conversation (graphiquement) ainsi que les activités de chorégraphie ne doivent pas y figurer.

L’absence des deux événements se voit sur la figure, et Dumas la signale comme la contrepartie de l’ordre libre⁸. Un ordre partiel reste exprimable par des flux de séquence: en ajouter un entre deux tâches impose qu’une exécution de la première soit suivie d’une exécution de la seconde, sans exigence d’immédiateté⁷. Un objet de données placé en entrée d’une tâche contraint de la même façon, puisque l’exécutant ne peut pas la démarrer sans cette entrée⁷.

Silver relève que le sous-processus ad hoc figure hors des sous-classes descriptive et analytique⁵, ce que les tableaux 2.1 et 2.2 du standard confirment⁹.

L’activité d’appel (call activity)

L’activité d’appel marque l’endroit d’un processus où un processus global ou une tâche globale est utilisé¹⁰. Elle sert d’enveloppe à l’invocation, et son activation transfère le contrôle à l’élément appelé¹⁰.

Quand elle appelle un processus, la forme est celle du sous-processus, réduite si le détail de l’appelé est masqué, développée s’il est disponible, avec un trait épais dans les deux cas¹⁰.

L’activité d’appel de BPMN 2.0 correspond au reusable sub-process de BPMN 1.2¹⁰.

L’activité d’appel doit déclarer exactement les mêmes entrées, sorties, ensembles d’entrées et ensembles de sorties que l’élément appelé¹⁰. Les erreurs et les escalades remontent de l’élément appelé vers l’activité d’appel, où elles se traitent sur la bordure¹⁰.

L’activité d’appel peut aussi redéfinir des propriétés de l’élément appelé: quand elle déclare ses propres ressources, celles de l’appelé sont ignorées¹⁰.

Pour Silver, un sous-processus employé par plusieurs processus gagne à être défini dans son propre fichier, puis appelé depuis chacun d’eux, la solution intégrée obligeant à répliquer la définition et à maintenir les copies synchronisées¹¹. Dumas va plus loin: son choix par défaut est le processus global, parce qu’il autorise la réutilisation à l’échelle d’un référentiel et qu’une modification du modèle global se propage d’elle-même à tous les processus qui l’invoquent¹². Il note le revers: une variante propre à un processus reste intégrée à son parent¹².

La tâche globale (global task)

Une tâche globale est une définition de tâche réutilisable et atomique, appelable depuis n’importe quel processus par une activité d’appel¹³. Le standard n’en définit que quatre: GlobalUserTask, GlobalManualTask, GlobalScriptTask et GlobalBusinessRuleTask¹³.

Elle n’a pas de symbole propre et se lit à travers l’activité d’appel qui l’invoque. Le standard impose alors la forme de la tâche avec un trait épais, ainsi que le marqueur du type de tâche globale appelée: une activité d’appel qui invoque une tâche utilisateur globale porte l’icône de la tâche utilisateur¹⁰.

Silver tempère l’intérêt de la construction hors modèle exécutable: dans un modèle descriptif ou analytique, la définition d’une tâche se réduit à son type et à son nom. En BPMN exécutable, une définition de tâche utilisateur porte ses données et son interface, et la partager entre plusieurs points d’appel devient utile¹¹.

La transaction

Une transaction est un sous-processus dont le comportement est régi par un protocole transactionnel, WS-Transaction par exemple¹⁴. Sa bordure est un double trait fin¹⁴. L’attribut method porte le protocole, sous forme d’URI technique pour un processus exécutable¹⁴.

La transaction demande un autre exemple. La figure suivante reprend le processus une fois la commande vérifiée et fait de la réservation du transport une transaction. Elle emprunte deux symboles à des chapitres à venir: la passerelle exclusive, qui sépare les deux issues de la réservation, et l’événement de bord (boundary event), qui porte ici l’annulation.

Les trois issues

• L’achèvement normal se lit comme un flux de séquence sortant de la transaction¹⁴.
• L’annulation soumet les activités contenues aux actions d’annulation, qui peuvent inclure un retour en arrière du processus et la compensation de certaines activités¹⁴. Les autres façons d’interrompre le sous-processus, une erreur, une minuterie ou ce qui vaudrait pour une activité non transactionnelle, laissent la compensation de côté¹⁴.
• Le hazard, l’incident grave, couvre le cas où le succès comme l’annulation propre sont hors d’atteinte. Il se note par un événement intermédiaire d’erreur: l’activité est interrompue sans compensation et le flux repart de cet événement¹⁴.

Les deux signaux d’annulation

• Un événement de fin d’annulation (cancel end event) atteint à l’intérieur du sous-processus, dont c’est le seul emplacement légal¹⁴.
• Un message d’annulation reçu par le protocole qui soutient l’exécution¹⁴.

L’événement intermédiaire d’annulation (cancel intermediate event) attaché à la bordure dirige ensuite le flux, une fois le retour en arrière effectué et toute la compensation terminée¹⁴. Son seul emplacement légal est la bordure d’une transaction¹⁴. Le chapitre sur les événements de bord reprend le mécanisme d’attachement.

Le retour au processus parent

Quand chaque chemin a atteint un événement de fin autre qu’une annulation, le flux attend avant de remonter au processus parent: le protocole vérifie d’abord que tous les participants ont achevé leur part¹⁴. Le plus souvent c’est le cas et le flux remonte. L’un des participants peut cependant rencontrer un problème qui provoque une annulation ou un hazard, auquel cas le flux part vers l’événement intermédiaire correspondant, alors même que la transaction paraissait achevée¹⁴.

Aucun autre sous-processus ne bascule ainsi après coup.

Le sous-processus événementiel

Un sous-processus dont l’attribut triggeredByEvent vaut true est un sous-processus événementiel (event sub-process), tracé en pointillé¹. Il se déclenche par son propre événement de début plutôt que par le flux du processus parent. Le chapitre sur les événements de bord le traite avec les déclencheurs qu’il admet.

Le choix du niveau

Deux repères aident à décider quand descendre d’un cran.

Le premier est la taille. Dumas rappelle qu’au-delà d’une trentaine d’objets de flux, activités, événements et passerelles réunis, la probabilité d’erreur augmente, et il fait de ce seuil sa règle empirique de décomposition¹⁵. Réduire un sous-processus est l’un des moyens les plus efficaces d’améliorer la lisibilité d’un modèle¹⁵.

Silver ajoute trois usages qui n’ont rien à voir avec l’encombrement². Le sous-processus réduit sert de tenant-lieu quand le détail reste à découvrir, ce qui laisse le modèle de bout en bout valide. Il découpe la gouvernance, chaque partie du processus revenant à un responsable distinct qui la maintient. Il délimite enfin la portée d’un gestionnaire d’exception: un événement attaché à un sous-processus se déclenche pour n’importe quelle étape qu’il contient.

Le second est la classe de conformité. La sous-classe descriptive, la plus restreinte des deux, admet le sous-processus dans ses deux vues ainsi que l’activité d’appel⁹. Le sous-processus ad hoc et la transaction figurent hors de la descriptive comme de l’analytique⁹. Ces sous-classes fixent ce qu’un outil doit prendre en charge pour revendiquer le niveau⁹: un modèle qui s’en tient à la descriptive n’utilise que des éléments que tout outil revendiquant cette sous-classe doit prendre en charge.

Au-delà de la bordure

Trois des quatre tracés de bordure sont désormais lus. Le quatrième, le pointillé du sous-processus événementiel, demande d’abord la grammaire des événements: leur position dans le flux, ce qu’ils capturent ou émettent et les treize déclencheurs que le standard définit.

Le chapitre suivant

BPMN: la grammaire des événements. Les treize déclencheurs d'événement BPMN, leur position dans le flux, la capture et l'émission et les traits qui séparent début, intermédiaire et fin.

Notes et références