urbanisation-si.com

En tant que lecteur assidu de notre blog www.urbanisation-si.com, vous avez bien compris que nous préférons les notations normalisées et nous ne prenons pas beaucoup de risques quand nous vous recommandons de les utiliser. Selon les notations, leurs spécifications sont mises à jour plus ou moins régulièrement, mais la fréquence de ces mises à jour n’est pas forcément le signe de leur usage intensif. Nous allons démontrer ici que c’est même le contraire, ce qui semble paradoxal. C’est à travers ce prisme que nous allons faire le point dans cet article sur les évolutions des spécifications BPMN, CMMN et DMN, surtout DMN en fait, avec son langage FEEL et un exemple d’application.

BPMN (Business Process Model and Notation)

La dernière version 2.0.2 de BPMN fut publiée en janvier 2014, soit il y a plus de 11 ans déjà. Et encore, il ne s’agissait que d’un simple changement mineur concernant les formats d’échanges. La version 2.0.1 mineure précédente, publiée en septembre 2013, était plus importante, car elle permit à BPMN de devenir un véritable standard international : ISO/IEC 19510. En fait, la dernière version majeure 2.0 fut publiée en décembre 2010. Aucune mise à jour majeure depuis une quinzaine d’années donc, mais BPMN est pourtant une notation qui remporte un énorme succès. Peut-être que les spécifications de BPMN (une belle somme de 532 pages pour la version 2.0.2) ont approché, voire atteint, l’exhaustivité ?

Exemple d’un diagramme d’orchestration BPMN
représentant un processus d’approvisionnement (OMG)

CMMN (Case Management Model and Notation)

Seulement deux versions pour CMMN : la version initiale 1.0 en mai 2014, puis la version 1.1 en décembre 2016. Nous n’avons jamais été de fervents supporters de CMMN. En gros, CMMN permet de lister des tâches qui pourront être exécutées par les opérateurs dans n’importe quel ordre, en fait dans un ordre adéquat qui ne peut pas être prédéterminé et qui répond à un besoin de flexibilité. On reconnait un diagramme CMMN à sa représentation octogonale des étapes (stages) :

Exemple d’un modèle plan de cas CMMN représentant la gestion des réclamations (OMG)

Afin d’une notation normalisée soit utilisée, il faut qu’elle soit supportée par l’outillage. L’éditeur allemand Camunda a décidé d’arrêter de supporter CMNN en 2019, tandis que d’autres, comme l’éditeur australien Sparx Systems et l’éditeur canadien Trisotech, continuent de la supporter. Trisotech promeut le concept de Triple Crown - triple couronne, sorte de tiercé gagnant pour améliorer les processus métier - constituée de BPMN + CMMN + DMN. Finalement, CMMN ne semble pas avoir rencontré le succès escompté. Ce qui est absolument certain, c’est que CMMN est bien moins utilisé que BPMN.

Rappelons que BPMN propose le sous-processus Ad-Hoc, reconnaissable à son tilde « ~ », qui permet en partie de modéliser de tels cas, sans doute bien difficiles à automatiser. Voici l’exemple officiel de sous-processus Ad-Hoc, extrait de la spécification BPMN 2.0.2 :

Exemple d’un sous-processus BPMN Ad-Hoc représentant l’écriture d’un chapitre de livre (OMG)

Ce sous-processus Ad-Hoc représente l’écriture d’un chapitre de livre (mais aussi l’écriture de cet article !) : on effectue des recherches, on écrit du texte, on crée des illustrations, etc., dans un ordre quelconque (SANS flux de séquence entre les tâches) et souvent plusieurs fois, pourvu que le livrable final (un chapitre ou cet article donc) constitue un ensemble logique et cohérent (c’est ce que l’on espère !).

DMN (Decision Model and Notation)

Si la notation DMN peut s’utiliser seule, rappelons qu’elle est aussi destinée à compléter BPMN. Ou plutôt, selon le principe de séparation des préoccupations, à dissocier les prises de décisions des processus métier. Comme nous le démontrerons plus loin, cela permet de faire évoluer une prise de décision, sans modifier le processus métier qui invoque cette prise de décision. Rappelons que DMN ne sert pas qu’à représenter les prises de décisions, mais peut également servir à représenter des calculs plus ou moins complexes (exemple : calculer le pourcentage d’une remise commerciale, selon l’ancienneté du client, le montant de sa commande, etc.).

Tandis que la notation DMN semble encore peu utilisée, notamment en France, le groupe de travail de l’organisme normalisateur OMG est très actif, avec en moyenne une nouvelle version des spécifications DMN tous les 2 ans depuis 10 ans ! Voici l’historique des différentes versions de DMN :

Historique des différentes versions de DMN

N.B. Une version 1.6 Beta de la spécification DMN est déjà publiée.

Langage FEEL (Friendly Enough Expression Language)

Si le nombre de pages des spécifications DMN est un indicateur, la tendance étant généralement à la hausse d’une ancienne vers une nouvelle version (dans un volume toutefois contenu de 250 pages en moyenne depuis plusieurs années), un autre indicateur a retenu notre attention : le nombre de fonctions du langage FEEL (Friendly Enough Expression Language). Il s’agit donc d’un langage destiné théoriquement à une large audience : les développeurs, mais aussi les experts métier.

Si, au début, il était réservé pour les expressions littérales et les tables de décision de DMN, il est désormais possible de l’utiliser dans BPMN (bien que la dernière version 2.0.2 des spécifications n’en fasse aucune mention, mais vous avez bien noté que BPMN est antérieure à DMN) : dans les passerelles (gateways) conditionnelles et dans les tâches de type Script. L’éditeur Camunda offre également la possibilité d’utiliser le langage FEEL dans ses formulaires.

En 10 ans, le nombre de fonctions de FEEL a plus que doublé, atteignant la centaine ! Dans le tableau récapitulatif ci-dessous, nous nous sommes alignés sur les différents types de fonctions de la version 1.5 de spécifications DMN, alors que des regroupements fonctionnels pourraient être effectués (Date and time, Temporal et Miscellaneous, par exemple) :

Nombre de fonctions FEEL intégrées, par type et par version de DMN

Certains éditeurs comme Camunda ajoutent déjà certaines fonctions FEEL étendues (la dernière ligne du tableau ci-dessous), sans attendre qu’elles soient normalisées dans la dernière version 1.5 de la spécification DMN : nous vous recommandons d’utiliser ces fonctions avec parcimonie, en espérant qu’elles soient normalisées dans la prochaine version… Bon, l’éditeur Camunda est un membre très actif du groupe de travail DMN de l’OMG. Ces fonctions supplémentaires sont clairement reconnaissables dans la documentation en ligne grâce à la mention « Camunda Extension ».

Exemple d’application simple, mais opérationnel

Voici un exemple très simple pour illustrer l’utilisation du langage FEEL dans la notation DMN. Soit le processus métier d’un transporteur qui consiste à indiquer au destinataire d’un colis une date de livraison en fonction d’une date d’expédition. Dans la représentation BPMN du processus, une tâche de type Règle Métier (symbolisé par la petite table de décision au haut à gauche du rectangle) calculera cette date de livraison. Nous verrons que la méthode de calcul de cette date de livraison pourra évoluer au fil du temps et devenir plus élaborée, SANS modifier la représentation BPMN du processus : c’est là l’illustration du principe de séparation des préoccupations.

Diagramme d’orchestration BPMN simple, mais immuable, représentant le calcul d’une date de livraison

Il convient ensuite de créer un modèle DMN, en l’occurrence un diagramme DRD (Decision Requirements Diagram) avec au moins une décision - ou un calcul - complétée par une expression littérale ou une table de décision. Voyons en détail ces deux possibilités.

Selon le plan de transport, la livraison de colis est théoriquement effectuée le lendemain de l’expédition, délai que l’on nomme souvent « J+1 ». Le langage FEEL propose la fonction « duration » pour calculer cette date de livraison. En fait, il suffit d’ajouter une Période de 1 jour « P1D » (ce format de durée est défini dans XPath Data Model) à la date d’expédition. Voilà comment cela se traduit en langage FEEL, dans une expression littérale :

Diagramme DRD et expression littérale associée simple, en langage FEEL (DMN)

Mais les livraisons ne sont pas effectuées par ce transporteur durant le weekend, aussi : si la date d’expédition est un vendredi (5e jour de la semaine), on ajoutera deux jours de plus, et si la date d’expédition est un samedi (6e jour de la semaine), on ajoutera un jour de plus, afin de livrer le lundi qui suit. Voilà comment cela se traduit en langage FEEL, toujours dans une expression littérale :

Diagramme DRD et expression littérale associée plus élaborée, en langage FEEL (DMN),
afin de prendre en compte les weekends

Résultat de l’exécution de cette expression (variable d’entrée, puis variable de sortie).

Mais plutôt que d’imbriquer plusieurs tests « if-then-else » (disponible dans le langage FEEL donc) comme avec n’importe quel autre langage de programmation (cela reste toutefois lisible grâce à un effort sur l’indentation), il est préférable ici d’utiliser l’une des fonctionnalités de DMN, en l’occurrence une table de décision, plus lisible et donc plus facilement modifiable qu’une expression littérale (en cas de changement du plan de transport, dans cet exemple) :

Diagramme DRD et table de décision associée, en langage FEEL (DMN),
prenant en compte les weekends

Une démarche « Low Code » ? Vous remarquerez que dans la formalisation des règles métier dans une table de décision, le « when » remplace le « if ». Pas de changement pour le « then ». Quant au « else », il devient implicite : chaque règle, c.-à-d. chaque ligne (numérotée de 1 à 4 dans la table de décision ci-dessus) correspond plus ou moins à un « else » (pour être précis, cela dépend de la Hit policy, mais ce point important mériterait un prochain article pour lui tout seul).

Des éditeurs interactifs en ligne permettent de tester partiellement vos expressions en langage FEEL. Cette méthode de calcul de la date de livraison est encore assez sommaire. La prochaine étape consisterait à prendre en compte dans le calcul, en plus des weekends, les jours fériés. Toujours SANS modifier (et SANS redéployer) la représentation BPMN du processus, qui se contente de la simple tâche « Calculer Date Livraison ».

Conclusion

BPMN est une norme (et même un standard ISO) peu mise à jour, mais très utilisée, tandis que DMN est une norme bien vivante et régulièrement mise à jour, mais encore peu utilisée : pas forcément très logique, tout cela !

Continuez à utiliser BPMN, dont si nécessaire ses sous-processus Ad-Hoc pour remplacer CMMN. Mais surtout, n’hésitez pas à séparer les prises de décisions et les calculs complexes dans des modèles DMN, puis à évaluer puis utiliser les nombreuses fonctions du langage FEEL, dans vos expressions littérales et tables de décision notamment.

« Le secret pour réussir, c’est de toujours prendre de bonnes décisions.
Et comment prend-on de bonnes décisions ? Grâce à l’expérience.
Et comment acquiert-on de l’expérience ? En prenant de mauvaises décisions. »
Citation attribuée à Mark Twain

Annexe

Cet exemple opérationnel d'application du langage FEEL de DMN a été réalisé avec :

• Camunda Modeler version 5.33.1,
• Camunda 8 Run version 8.6.12.

L'installation de Camunda Modeler n'a rien de particulièrement difficile.

L'installation de Camunda 8 Run nécessite l'installation préalable d'un JDK (Java Development Kit) version 21 ou supérieure, qui n'est pas une version très courante (bien que la dernière version du JDK en cours de développement soit la version 25, Oracle recommande toujours la version 8 de Java aux utilisateurs finals !). Comme avec d'autres composants, choisissez de préférence une version LTS (Long Term Support). Enfin, n'oubliez pas d'initialiser les variables d'environnement JAVA_HOME et JAVA_VERSION :

Une fois la version adéquate de JDK installée et le paquet ZIP de Camunda 8 Run extrait dans un répertoire, il suffit de le démarrer en saisissant "c8run start". Le moteur de base de données Elasticsearch démarre avant Camunda, après un nombre aléatoire de tentatives, ce qui est assez surprenant :

La fin du démarrage de Camunda lance automatiquement votre navigateur web préféré avec l'URL "Operate" (Username = Password = demo) :

Avec Camunda Modeler, il faudra choisir la version 8 de Camunda lors de la création d'un nouveau fichier, que ce soit pour BPMN, DMN ou Form (Formulaire). Ces trois types de fichiers devront ensuite être déployés sur Camunda 8 Run de la même façon avant utilisation. Pour cela, il suffit de cliquer sur la petite fusée en bas à gauche de la fenêtre principale de Camunda Modeler, puis sur le bouton Deploy :

Seul le processus métier peut être démarré à partir de Camunda Modeler. Il suffit de cliquer sur la petite flèche en bas à gauche, puis sur le bouton Start. Inutile d'indiquer une variable optionnelle au format JSON, car cette variable va être renseignée lors de la saisie du formulaire.

Pour effectuer cette saisie du formulaire, indiquez l'URL de la Tasklist, choisissez la tâche en attente, cliquez sur le bouton M'assigner, saisissez la Date d'expédition (ou sélectionnez-là dans le calendrier qui s'affiche) et enfin cliquez sur le Bouton du bas "Terminer la tâche" (un message fugace "Tâche terminée" s'affiche) :

Retournez sur l'URL Operate, cliquez sur l'onglet Decisions, puis cliquez sur la Decision Instance Key la plus récente.

La règle qui a été appliquée pour prendre la dernière décision est surlignée (ici la #2).
Cliquez enfin sur l'onglet Result pour voir le résultat, suite à l'application de cette règle.

A la fin de l'utilisation, pour arrêter Camunda 8 Run, saisissez "c8run stop" :