java
BPMN : les premiers pas avec Camunda
Léa Joret, Développeuse Fullstack @DeliaTechnologies
January 11, 2024
10 min
BPMN signifie Business Process Model and Notation.
Mais dis moi Jamie, pourquoi donc est-ce que j’aurai besoin d’ajouter une couche supplémentaire à mon application alors que celle-ci est déjà suffisamment compliquée à maintenir ?
Mais c’est simple Fred !
Le BPMN a une valeur métier ET une valeur technique !
Valeur métier, car sa représentation graphique permet au PO/fonctionnel de se baser sur cette représentation pour comprendre et définir le besoin client, avoir une base solide d’échange avec les développeurs, mais également à la partie business pour appréhender au premier coup d’œil le service fourni.
Valeur technique car le BPMN n’est pas uniquement graphique, il fonctionne de pair avec un moteur de workflow, qui permet d’intégrer facilement ce BPMN à son application.
De plus, le XML utilisé pour décrire un workflow BPMN peut être visualisé par n’importe qui.
Afin de faciliter la prise en main du BPMN, il existe de nombreux outils permettant de visualiser et d’interagir avec ce BPMN.
La librairie Java Camunda est un orchestrateur de workflow et qui permet d’intégrer du BPMN à son application. Elle peut être couplée avec l’outil Camunda Modeler permettant la visualisation et la modification du BPMN.
Pour ajouter Camunda à son projet springboot (maven) :
Tous les composants disponibles pour le BPMN dans Camunda
https://docs.camunda.io/docs/components/modeler/bpmn/bpmn-coverage/
Une task est représentée visuellement par une boite et sert à effectuer des actions.
Idéalement, une service task ne fait qu’une seule action. Lorsque le process rentre dans la service task, celui-ci va attendre que l’action se termine pour reprendre.
Le paramètre taskDefinition est obligatoirement défini pour une service task. C’est ce qui permet de lier la service task du BPMN avec le code associé. Une service task peut également avoir un retry de défini, ce qui peut être utile lorsque l’action à mener comporte un appel à un SI externe ou interne.
En Java, une classe est liée à une service task et va permettre de venir implémenter l’action à effectuer. Cette classe doit implémenter l’interface JavaDelegate.
A la différence de la service task où l’action est faite automatiquement, la user task nécessite une action humaine. Tant qu’aucune action humaine n’est intervenue, le process va attendre.
On peut assigner des utilisateurs à cette user task, grâce à des valeurs statiques ou des expressions, via assignee, candidateUsers et candidateGroups.
On peut assigner une date limite.
Le process va attendre de recevoir un message précis, soit sous forme de valeur statique ou d’expression, avant de continuer. Cela peut être utilisé par exemple pour démarrer un traitement en parallèle.
Cette task permet de lancer un script, soit en Groovy, soit en JavaScript, soit en Python. Si le script est en erreur, le traitement stoppe, sinon il continue.
Task très similaire à une service task. Cette représentation est purement graphique et permet de savoir au premier coup d’oeil que cette task a une interaction avec un outil externe de gestion de file (RabbitMQ par exemple) ou d’envoi de mail.
Cette task sert à indiquer une interaction externe et non automatique au BPMN. Elle n’a aucun impact sur le parcours du process, celui-ci se poursuit normalement.
Une gateway permet d’articuler le BPMN.
Une exclusive gateway permet de déterminer quel est le chemin à prendre au sein du process.
Elle doit avoir obligatoirement le paramètres conditionExpression de renseigné, à l’exception de la voie par défaut qui peut être vide. Ce paramètre doit être une expression booléenne, et se doit de prendre en compte des variables de process.
Ces variables de process sont en général initialisée au sein des services tasks.
Une parallel gateway permet de traiter au moins deux flux en parallèle.
Une parallel gateway a forcément un point d’entrée et un point de sortie (en bleu). les encadrés rouges et verts sont les process qui vont se dérouler en parallèle. Il faudra attendre que ces deux process se terminent pour que la suite du workflow puisse se dérouler.
Cette gateway doit avoir minimum deux flux. Elle permet de déclencher l’un des flux en fonction de l’évènement qui arrive en premier (un timer, un message reçu, …)
Cette gateway est similaire à l’exclusive gateway, sauf que les flux ne s’excluent pas mutellement. En effet, plusieurs traitements peuvent être lancés suite à cette gateway (voir exemple). Le flux par défaut n’est pas obligatoire.
Un évènement, au sein du BPMN, peut être reçu ou envoyé.
Deux évènements sont obligatoires :
Il existe deux types d’évènements :
C’est un évènement vierge, qui peut servir de marqueur lorsqu’un certain stade du process est atteint. Il n’y a pas d’action particulière sur cet évènement, le process continue. Les start et end events sont des none events.
Permet d’envoyer et de recevoir un message. Un message peut être corrélé à un start event pour démarrer une partie du process lorsqu’un message spécifique est reçu.
Un message n’est adressé qu’à un seul destinataire. Un message comporte un nom, qui est émis lorsque l’évènement est émis. Pour un évènement de type réception, le paramètre correlationKey est obligatoire et permet de lier cet évènement à la réception d’un message.
Permet d’envoyer et de recevoir un signal. Contrairement au message event, le signal event peut être attaché à plusieurs évènements de réception car un signal a une portée globale. Un signal est identifié par son nom.
Evènement déclenché par un timer prédéfini par une date, une durée ou un cycle. Pour voir la manière de décrire un timer, voir https://docs.camunda.io/docs/components/modeler/bpmn/timer-events/.
Une façon de gérer les erreurs rencontrées lors du déroulement du workflow est d’utiliser le error event, qui permet au BPMN de réagir aux directement aux erreurs au sein d'une task. Contrairement à l’error event de réception, l’error event d’émission est défini obligatoirement par le paramètre errorCode pour matcher avec l’erreur reçue. Un error event de réception sans errorCode sera déclenché dès qu’un error event est émis, quelqu’il soit.
Un escalation event permet de remonter au process parent lorsque le process enfant se termine prématurément. Une escalation doit définir le paramètre escalationCode, permettant de lier process enfant et parent.
Voici ci-dessous une partie de Dota 2 modélisée via un BPMN.
Ce workflow se découpe en deux process : un process parent et un process enfant, signalisé par la boite “Partie” (également appelé call subprocess).
Le process parent comporte l’intégralité du workflow, avec le début et la fin du process.
Une service task va automatiquement assigner une partie au joueur.
Le rectangle rouge représente une parallel gateway, qui permet de bannir et de sélectionner un héro.
Le rectangle vert représente l’appel au subprocess (process enfant). Le subprocess permet de séparer visuellement un process trop important.
Le subprocess, ou process enfant, comporte deux workflow séparés.
Le premier workflow décrit le déroulement de la partie, avec dans l’ordre :
Le deuxième workflow décrit un évènement facultatif, soit la destruction du boss Roshan. Le déroulement est le suivant :
Le subprocess, afin d’être plus lisible, peut contenir des lanes. Néanmoins, Camunda Modeler ne semble pas le permettre.
Réservez un moment avec notre équipe RH en quelques clics, pour voir ensemble le meilleur moyen de nous rejoindre. Vous avez des questions sur Delia Technologies ? C'est le moment de les poser !
Rencontrer notre équipe