BPMN: la chorégraphie et la conversation

Le chapitre sur les pools a laissé deux diagrammes de côté. Le standard les définit à part entière, les sous-classes de conformité que les outils revendiquent d’ordinaire n’en contiennent aucun élément et la littérature de référence les écarte.

Les figures de ce chapitre sont des collaborations, et chacune se lit seule. Le moteur de rendu de cette référence, la bibliothèque libre bpmn-js, dessine les processus et les collaborations, et ignore silencieusement les tâches de chorégraphie comme les nœuds de conversation. Chaque symbole propre à ces deux diagrammes est donc décrit en toutes lettres, et les figures montrent la collaboration équivalente, celle que le standard place à côté de nombre de ses propres exemples. Qui veut voir les formes les trouvera dans la spécification publique, aux figures 11.2, 11.8, 11.10, 11.15, 11.17 et 11.21 pour la chorégraphie, aux figures 9.16, 9.18 et 9.27 pour la conversation.

La chorégraphie

Une chorégraphie est un type de processus qui diffère du processus BPMN ordinaire par son objet. Un processus d’orchestration définit l’enchaînement des activités d’une organisation. Une chorégraphie formalise la façon dont des participants coordonnent leurs interactions, en portant l’attention sur les messages échangés entre eux plutôt que sur le travail accompli à l’intérieur de chacun¹. Le standard propose une autre lecture: un contrat commercial entre deux organisations ou davantage, une définition du comportement attendu de chacune d’elles¹.

La chorégraphie emprunte au diagramme de processus ses activités ordonnées par des flux de séquence. L’unité atomique y est une interaction, un échange de messages entre participants, ce que la littérature des services web appelle un message exchange pattern (MEP). Le plus simple porte un message unique, un autre une requête et sa réponse, et le standard en admet de plus complexes, portant par exemple des messages d’erreur¹.

Un processus vit dans un pool et relève d’un participant unique. Une chorégraphie n’a pas de pool: chacune de ses étapes engage deux participants ou davantage, donc elle se dessine en dehors des pools, entre eux².

La question que pose une chorégraphie

Le standard formule la question à se poser à chaque étape de la conception: de quelle information les participants disposent-ils? Chacun ne connaît l’état de la chorégraphie que par le comportement observable des autres, c’est-à-dire par les messages envoyés et reçus. À deux participants la réponse est immédiate, chacun sachant à qui revient le message suivant. Au-delà, le modélisateur ordonne les activités de façon que chacun sache quand vient son tour².

Une collaboration ne le dit pas. Le standard relève que les modèles interconnectés de collaboration sont vulnérables aux erreurs de séquencement, la logique des échanges étant considérée un partenaire à la fois, ce qui conduit à des interblocages difficiles à reconnaître sur le diagramme². La chorégraphie met la séquence complète des échanges sur un seul diagramme.

La tâche de chorégraphie (choreography task)

Une tâche de chorégraphie est l’activité atomique d’une chorégraphie. Elle représente une interaction, soit un ou deux échanges de message entre deux participants³.

Elle se dessine en rectangle à coins arrondis d’un trait unique, la même forme qu’une activité BPMN. Elle s’en distingue par son découpage en bandes: deux bandes de participant au moins et une bande centrale portant le nom de la tâche³. Les noms des participants s’inscrivent dans leurs bandes.

La tâche hérite de l’activité de chorégraphie (choreography activity), la classe abstraite dont relèvent aussi les deux éléments suivants: participantRefs avec deux participants au minimum, initiatingParticipantRef qui désigne celui qui déclenche, loopType pour la répétition et correlationKeys pour la corrélation des flux de message⁴. La tâche référence enfin un messageFlowRef au moins, les flux de message qui portent l’interaction sans être dessinés sur la forme³.

La bande du participant initiateur (participant band)

La bande du participant qui n’initie pas l’interaction doit être ombrée d’un remplissage clair³. La bande restée blanche désigne donc celui qui envoie le premier message.

Les messages attachés

Le message envoyé par l’un des participants, ou par les deux, peut s’afficher. L’icône d’enveloppe se relie par un trait au participant qui l’émet. L’icône du message initiateur reste vide, celle du message de retour porte un remplissage clair, la même convention que les bandes³.

Ces messages se rattachent à une tâche de chorégraphie et à une chorégraphie d’appel qui référence une tâche de chorégraphie globale. Une sous-chorégraphie et une chorégraphie d’appel qui référence une autre chorégraphie ne les admettent pas³.

Les marqueurs de répétition

La tâche de chorégraphie reprend les marqueurs de l’activité d’orchestration, un seul à la fois³:

• la boucle standard, un trait fléché qui s’enroule sur lui-même, avec loopType à Standard;
• les instances multiples parallèles, trois traits verticaux, avec loopType à MultiInstanceParallel;
• les instances multiples séquentielles, trois traits horizontaux, avec loopType à MultiInstanceSequential.

Le marqueur se centre au bas de la bande du nom³.

Le participant à instances multiples

Un participant peut lui-même compter plusieurs instances, plusieurs transporteurs possibles selon la destination par exemple. Sa bande reçoit alors le marqueur d’instances multiples, trois traits verticaux centrés au bas de la bande de ce participant, et s’élargit pour contenir le nom et le marqueur³. Deux marqueurs identiques disent donc deux choses différentes selon la bande qui les porte.

La sous-chorégraphie (sub-choreography)

Une sous-chorégraphie est une activité composée: son détail est lui-même une chorégraphie. Elle engage deux participants ou davantage et se dessine comme la tâche, en bandes de participant plus une bande de nom⁵.

Réduite, elle cache son contenu et porte le marqueur en petit carré frappé d’un signe plus, centré au bas de la bande du nom. Développée, elle montre la chorégraphie qu’elle contient⁵. Elle admet les mêmes trois marqueurs de répétition que la tâche, et le marqueur d’instances multiples sur une bande de participant⁵.

Au-delà de deux participants, une bande s’ajoute pour chacun. Toute bande au-delà des deux premières est facultative à l’affichage, et chaque bande ajoutée se place alternativement en haut et en bas de la forme. L’ordre et la position des bandes reviennent au modélisateur ou à son outil⁵.

La chorégraphie d’appel (call choreography)

Une chorégraphie d’appel marque l’endroit où une chorégraphie globale ou une tâche de chorégraphie globale est employée. L’élément appelé devient partie de la définition de la chorégraphie parente⁶.

Sa forme suit sa cible, et la bordure porte toujours un trait épais⁶:

• appelant une tâche de chorégraphie globale, elle prend la forme d’une tâche de chorégraphie;
• appelant une chorégraphie dont le détail reste caché, elle prend la forme d’une sous-chorégraphie réduite;
• appelant une chorégraphie dont le détail est montré, elle prend celle d’une sous-chorégraphie développée.

C’est le procédé de l’activité d’appel du diagramme de processus, transposé aux interactions.

La tâche de chorégraphie globale (global choreography task)

Une tâche de chorégraphie globale est une définition d’interaction réutilisable et atomique, appelable depuis n’importe quelle chorégraphie. Le standard la décrit comme une chorégraphie vide: elle ne contient aucun élément de flux et se réduit à un jeu de participants et de flux de message dont l’un est désigné comme initiateur⁷.

Le séquencement des activités

Les flux de séquence s’emploient dans une chorégraphie comme dans un processus. Ils relient les événements, les passerelles et les activités de chorégraphie⁸.

L’ordre, en revanche, obéit à une contrainte propre. L’initiateur d’une activité de chorégraphie doit avoir participé à l’activité précédente, comme initiateur ou comme destinataire. La première activité de la chorégraphie échappe à la contrainte⁹.

Une séquence qui viole la règle reste dessinable, sans être exécutoire: un participant devrait envoyer un message après un échange auquel il n’a pas pris part, sans moyen d’en connaître le moment⁹.

Une tâche de chorégraphie à deux messages se reflète d’ordinaire en trois tâches dans les processus des participants, l’initiateur employant une activité unique pour l’envoi et la réception, souvent une tâche de service⁹. La première figure de ce chapitre la montre déjà. L’attribut isImmediate d’un flux de séquence interdit ou autorise, entre les deux éléments qu’il relie, des messages absents du modèle, et l’attribut isClosed de la chorégraphie l’emporte sur lui⁸.

Les données et les conditions

Une chorégraphie n’a ni mécanisme de contrôle central, ni donnée centrale. Les objets de données et les magasins de données s’emploient exclusivement dans les processus, qui disposent d’un tel centre. Une donnée ne peut servir dans une expression que si elle a circulé dans un message de la chorégraphie¹⁰.

Cette contrainte unique explique la plupart des restrictions qui suivent.

Les événements de chorégraphie

Les événements s’emploient largement comme dans un processus, avec une exclusion: un déclencheur visible d’un seul participant n’a pas sa place dans une chorégraphie.

En début, l’événement neutre sert de repère graphique, l’arrivée du premier message étant le déclencheur réel. La minuterie est admise si les participants s’accordent sur l’heure approximative, la condition parce que les autres participants l’apprennent par l’interaction qui suit, le signal parce que tous doivent pouvoir le voir, le multiple à condition de ne combiner que des signaux ou des minuteries. Le message, l’escalade, l’erreur et la compensation sont refusés¹¹.

En intermédiaire, l’événement de message au bord d’une tâche de chorégraphie est admis et s’attache à la bande du participant qui reçoit le message, l’autre participant de la tâche en étant l’émetteur¹². Dans le flux normal, le même événement est refusé, faute de pouvoir dire qui envoie et qui reçoit. La minuterie est admise dans le flux normal, au bord et dans une passerelle événementielle, avec la réserve que le temps n’y est jamais exact: il se règle sur la dernière activité visible. L’annulation et la compensation sont admises au bord, en capture, sur la bande du participant concerné. La condition, le lien et le multiple en capture sont admis. Le signal en capture l’est aussi, au bord comme dans le flux normal, avec une réserve: un signal au bord ne doit jamais s’attacher à une bande de participant, ce qui laisserait croire que ce participant en est le destinataire désigné alors qu’un signal n’en a aucun. L’escalade est refusée dans le flux normal comme au bord, l’erreur au bord, le tableau ne prévoyant pas d’erreur dans le flux normal. L’événement neutre y est enfin admis dans le flux normal, où il documente qu’un point est atteint, et refusé au bord, faute pour les participants de savoir quand l’activité doit être interrompue.

En fin, seuls l’événement neutre et la terminaison sont admis. Le standard note que la terminaison ne termine rien, faute de système de contrôle: les participants comprennent qu’aucun message ne suivra, et le procédé ne fonctionne vraiment qu’à deux participants, un troisième absent de la dernière tâche n’ayant aucun moyen de savoir que la fin est atteinte¹³.

Les passerelles de chorégraphie

Les passerelles créent des chemins alternatifs et parallèles, dans une chorégraphie comme dans un processus. L’absence de donnée centrale et d’évaluation centrale y ajoute des contraintes portant sur les participants placés avant et après la passerelle¹⁴.

La passerelle exclusive s’emploie, mais une chorégraphie qui décrit ses conditions en langage naturel est sous-spécifiée et non exécutoire. Une chorégraphie exécutoire demande des expressions de condition formelles, dont la donnée a circulé dans un message antérieur à la passerelle, que tous les participants affectés ont envoyé ou reçu, et dont tous ont la même compréhension. Les initiateurs des activités qui suivent la passerelle sont ceux qui décident, puisque la décision se manifeste par le message qui suit¹⁵. La passerelle inclusive obéit aux mêmes règles, son comportement de synchronisation ne pouvant être imposé que par un seul participant¹⁶.

La passerelle événementielle sert quand la donnée de la décision n’est visible que du processus interne d’un participant: les autres n’apprennent le résultat que par le message qui arrive. À droite de la passerelle, ou bien les émetteurs sont les mêmes, ou bien les destinataires le sont. Les événements intermédiaires de message y sont interdits, la minuterie et le signal admis, et aucun autre type¹⁷.

La passerelle parallèle ne porte aucune condition, donc elle s’emploie telle quelle. Les émetteurs des activités qui suivent doivent avoir participé à toutes celles qui précèdent immédiatement¹⁸.

La passerelle complexe trouve ici un emploi que le standard illustre en détail: l’appel d’offres, où une demande part vers plusieurs prestataires qui répondent à des moments différents et où l’évaluation démarre à un quorum de réponses¹⁹. Enchaîner des passerelles sans activité intermédiaire reste possible, sous réserve des contraintes sur les participants placés de part et d’autre de la chaîne²⁰.

La chorégraphie dans une collaboration

Une chorégraphie peut s’insérer dans un diagramme de collaboration, entre les pools. La collaboration précise alors comment les participants et les flux de message de la chorégraphie correspondent aux siens, par des associations de participant et des associations de flux de message²¹.

La correspondance rattache les bandes de participant aux pools, donc les noms inscrits dans les bandes deviennent facultatifs, les pools les portant déjಹ. Le standard donne aussi le mécanisme de déduction: deux participants partageant la même entité partenaire peuvent être présumés se correspondre²¹.

Les pools et les couloirs, eux, ne s’emploient pas dans une chorégraphie. Le pool appartient à la collaboration, et le couloir est une sous-partition du pool, alors qu’une chorégraphie se place entre les pools. Les participants, en revanche, servent des deux côtés, dans les pools d’une collaboration comme dans les bandes d’une chorégraphie²².

La conversation

Le diagramme de conversation est un usage particulier du diagramme de collaboration, dont il garde toutes les caractéristiques. Un processus peut apparaître dans les pools d’un diagramme de conversation, pour montrer comment les conversations et les activités se rejoignent. Deux éléments graphiques lui sont propres: les nœuds de conversation et le lien de conversation²³.

Une conversation est un regroupement logique d’échanges de messages qui peuvent partager une corrélation. Le lien logique porte le plus souvent sur un objet métier, une commande, une expédition ou une facture, si bien que la conversation s’associe à un jeu de paires nom-valeur, une clé de corrélation telle que l’identifiant de commande, inscrite dans les messages. Un message peut ainsi être acheminé vers l’instance de processus qui doit le traiter²³.

Le standard le dit: développer un nœud de conversation en ses flux de message donne un diagramme qui ressemble à une simple collaboration²³. L’intérêt du diagramme est l’inverse: son exemple de logistique montre treize conversations distinctes entre des participants d’un même domaine, ce qu’il appelle une perspective à vol d’oiseau²³.

Une conversation peut engager plus de deux participants. La multiplicité y signifie un ou plusieurs, jamais zéro ou plusieurs. Et le comportement des conversations se modélise par des chorégraphies séparées, qui détaillent les séquences d’échange²³.

Le standard nomme enfin trois dépendances entre conversations: le recouvrement (overlap), quand deux conversations partagent certains échanges sans partager les autres, la division (split), quand un échange engendre une conversation nouvelle et distincte, et la fusion (join), quand plusieurs conversations se réunissent en une seule et cessent²³.

Le nœud de conversation (conversation node)

Le nœud de conversation est la classe abstraite dont dérivent les trois éléments qui peuvent composer la partie conversation d’un diagramme de collaboration: la conversation, la sous-conversation et la conversation d’appel²⁴.

Ses attributs sont peu nombreux: name, participantRefs avec deux participants au minimum, messageFlowRefs qui référence tous les flux de message regroupés et correlationKeys qui porte les clés servant à ce regroupement²⁴.

La conversation (conversation)

Une conversation est l’élément atomique du diagramme. Elle représente un ensemble de flux de message regroupés sur un concept ou sur une clé de corrélation, et elle engage deux participants ou davantage. Elle se dessine en hexagone d’un trait fin unique²⁵.

La sous-conversation (sub-conversation)

Une sous-conversation est un nœud qui divise hiérarchiquement la collaboration parente. Elle se dessine en hexagone du même trait fin, avec le marqueur en petit carré frappé d’un signe plus, centré au bas de la forme, et peut s’ouvrir pour montrer son détail: des flux de message, des conversations et d’autres sous-conversations. Elle partage les participants de sa parente²⁶. L’imbrication descend à un nombre quelconque de niveaux, et le signe plus signale aussi bien une sous-conversation qu’une conversation d’appel²³.

La conversation d’appel (call conversation)

Une conversation d’appel marque l’endroit où une conversation globale ou une collaboration est employée. Sa forme suit sa cible et sa bordure porte un trait épais: la forme d’une conversation quand elle appelle une conversation globale, celle d’une sous-conversation quand elle appelle une collaboration. L’élément appelé ne peut être ni une chorégraphie ni une tâche de chorégraphie globale. Un jeu d’associations de participant relie les participants de l’élément appelé à ceux de la conversation parente²⁷.

Une conversation globale (global conversation) est une collaboration restreinte, que le standard qualifie de collaboration vide: elle ne contient aucun nœud de conversation et se réduit à un jeu de participants, de flux de message et de clés de corrélation destinés à la réutilisation²⁸.

Le lien de conversation (conversation link)

Le lien de conversation relie un nœud de conversation à un participant, donc à un pool. Il se dessine en double trait fin²⁹.

Ses deux extrémités obéissent à une règle unique: un lien de conversation se raccorde à exactement un nœud de conversation, si bien que la source doit en être un dès que la cible n’en est pas un, et réciproquement²⁹.

Le lien descend aussi vers l’intérieur d’un pool. Il peut atteindre les activités et les événements d’un processus, et le standard précise le sens d’un tel raccordement: un lien vers une activité qui n’est ni une tâche d’envoi ni une tâche de réception indique que cette activité enverra ou recevra les messages de la conversation à un certain niveau d’imbrication²⁹. La contrainte symétrique vaut du côté des couloirs: quand un couloir représente une conversation, les éléments de flux qu’il contient et qui échangent des messages doivent le faire dans le cadre de cette conversation³⁰.

L’association de conversation (conversation association)

L’association de conversation applique une conversation réutilisable aux flux de message d’une collaboration ou d’une chorégraphie. Le cas visé est l’inclusion d’une chorégraphie entre les pools d’une collaboration: les nœuds de conversation du diagramme intérieur doivent alors correspondre à ceux du diagramme extérieur, ce que portent les attributs innerConversationNodeRef et outerConversationNodeRef³¹.

La corrélation

La corrélation est le mécanisme qui affecte les messages à la bonne instance de processus. Elle se définit pour les flux de message qui appartiennent à la conversation³².

Le standard en donne les conditions d’emploi. Les données conceptuelles de la conversation sont connues et définies par les processus participants, sans que les systèmes de types soient identiques de part et d’autre: il suffit qu’elle soit connue conceptuellement, au besoin à un niveau métier très élevé. L’échange se fait par messages simples, sans convention supplémentaire. Il existe des tâches d’envoi et de réception qui acceptent ces données. Et la corrélation se définit par des champs de corrélation (correlation fields), un sous-ensemble de ces données conceptuelles: si la donnée conceptuelle est une commande, le champ de corrélation peut être son identifiant³².

La même clause porte le sens de l’attribut isClosed d’une collaboration, qui décide si des messages absents du modèle peuvent circuler, et ajoute qu’une collaboration contenant une chorégraphie doit lui donner la même valeur qu’à elle-même³².

Les classes de conformité

Le chapitre sur les niveaux de modélisation a posé les quatre types de conformité. Deux d’entre eux décident du sort de ces diagrammes.

La conformité de modélisation de chorégraphie est un type distinct, que le standard déclare mutuellement indépendant de la conformité de modélisation de processus: une implémentation qui revendique l’une n’a pas à prendre en charge l’autre³³. La clause 11 du standard n’est exigée que pour cette conformité et pour la conformité complète¹. Ses éléments sont énumérés à part: le message, la tâche de chorégraphie, la tâche de chorégraphie globale, la sous-chorégraphie dans ses deux vues, une sélection d’événements de début, intermédiaires et de fin, les passerelles, plus les pools et les flux de message pour la chorégraphie insérée dans une collaboration³⁴. Une note de la clause sur les éléments de processus dit l’autre versant: les implémentations ne sont pas censées prendre en charge les éléments de chorégraphie tels que la tâche de chorégraphie et la sous-chorégraphie³⁵.

La conversation suit l’autre chemin. Les diagrammes de conversation figurent parmi les quatre familles de paquets exigées par la classe pleine de la conformité de modélisation de processus, celle dont les trois sous-classes sont des alternatives, avec les pools, les conversations et les liens de conversation³⁶. Le vocabulaire y est toutefois restreint: l’inventaire retient les conversations limitées au regroupement de flux de message et à l’association des corrélations³⁵.

Reste la question pratique. Ni la sous-classe descriptive ni la sous-classe analytique ne contient un seul élément de chorégraphie ou de conversation³⁷. Un outil qui revendique l’un ou l’autre de ces deux niveaux, ceux que la quasi-totalité des modélisateurs métier emploient, n’en offre donc aucun.

Deux diagrammes rarement rencontrés

Les classes de conformité les excluent du périmètre courant.

La littérature de référence les écarte explicitement. Silver ouvre son livre en prévenant que le lecteur n’y trouvera rien sur la chorégraphie ni sur la conversation, ayant vu jusque-là peu d’intérêt pour ces ajouts au standard, tournés vers les échanges interentreprises³⁸. Dumas et ses coauteurs les mentionnent dans leurs lectures complémentaires, en trois phrases qui disent d’où ils viennent, la notation Let’s Dance de modélisation des interactions de services web³⁹. Sinur, Misiak et Biernatowski les qualifient de deux types de diagramme supplémentaires peu répandus⁴⁰.

La prise en charge par les outils suit. Nous n’avons aucune mesure de cette couverture. Notre seule observation porte sur un outil, bpmn-js: il importe un fichier de chorégraphie ou de conversation sans avertissement, puis n’en dessine que les pools.

Un modèle destiné à être lu, validé et échangé gagne à rester dans le vocabulaire du processus et de la collaboration. La chorégraphie garde sa valeur là où le standard la place, la négociation d’un contrat d’échange entre partenaires.

Au-delà des quatre diagrammes

Le chapitre suivant quitte l’OMG pour la Suisse et lit BPMN à travers le standard eCH, qui fixe les conventions de modélisation de l’administration publique.

Le chapitre suivant

BPMN: le standard eCH de l'administration publique suisse. Les trois standards eCH qui règlent la modélisation BPMN dans l'administration publique suisse: eCH-0140, eCH-0074 et eCH-0158, ses deux annexes et sa palette.

Notes et références