Préambule

Ce document présente le fonctionnement des workflows Camunda® de validation dans Project Monitor et Perf Monitor, du point de vue utilisateur et du point de vue conception. Il s’adresse aux consultants qui doivent mettre en place des workflows de validation dans l’application. Camunda est disponible depuis la V6.5.2.

Convention de rédaction

Définition de

Principe d’architecture

Le nouveau moteur de workflow Camunda® propose de définir les workflows selon le standard BPMN (Business Process Model and Notation).

Il s’appuie sur l’utilisation des webservices.

Les API que l’on peut appeler dans le modeler Camunda sont répertoriées dans la page selon les standards suivants :

• le principe d’architecture REST (Representational State Transfer),
• le protocole HTTP (hyper text transfer protocol),
• le format de données JSON (JavaScript Object Notation).

Outils de test

Afin de s’assurer que chaque webservice utilisé dans le modeler Camunda® est juste, il est nécessaire de tester les requêtes au préalable.

Pour se faire plusieurs outils de type API REST :

• Rest Client (Mozilla Firefox®)
• Postman

Pour en savoir plus sur les API REST consultez le lien suivant :

Une API REST, qu'est-ce que c'est ?

Une API REST (également appelée API RESTful) est une interface de programmation d'application (API ou API web) qui respecte les contraintes du style d'architecture REST et permet d'interagir avec les services web RESTful. L'architecture REST (Representational State Transfer) a été créée par l'informaticien Roy Fielding.

www.redhat.com

Informations générales

Architecture technique

Pour envisager de migrer un environnement client sur le nouveau moteur de Workflow Camunda®, il est nécessaire de déployer Camunda® sur le serveur applicatif.

⏲ La procédure de déploiement est en cours de rédaction !

Modeler Camunda®

Il est nécessaire de disposer du modeler de Camunda® pour générer les fichiers bpmn 👇

https://camunda.com/download/modeler/

Workflow Camunda®

Camunda® vs JPDL

PM avec Camunda®

Principes du workflow dans PM

Les principes du workflow PM ne changent pas fondamentalement, la migration vers Camunda® a été pensée de manière ISO à JPDL.

• Aussi, le workflow se déclenche sur le statut de projet, le statut de document ou manuellement.
• Il est hérité du gabarit de création du projet.
• Il avance par validation de tâche.

Selon les webservices publics, il sera même possible d’ajouter des actions à ce jour inexistantes dans jpdl, comme la création de nouveaux objets dans le projet par exemple.

Paramétrage préalable

Activation Add-on

L’activation de l’add-on se fait au niveau MM > plateformes.

Dans la liste des add-ons, activer l’add-on “Workflow”.

⚠ Il faut avoir modélisé l’ensemble des WF Camunda® avant d’activer l’add-on car l’activation de l’add-on désactive le WF JPDL.

Utilisateur technique

Pour que Camunda® et PM puissent fonctionner, il faut créer un utilisateur technique avec les droits suffisants sur les actions de WF à mener.

Il est par conséquent nécessaire d’attribuer à l’utilisateur un rôle général avec des droits étendus.

Concordance des codes

Il est nécessaire pour assurer que le WF soit compatible avec PM que les codes utilisés dans les webservices correspondent à ceux de PM :

• Code Rôle
• Code valeur de liste statut tâche
• Code valeur de liste type de tâche
• Code valeur de liste statut projet/jalon/phase
• ...

Les actions workflow Camunda®

Le fichier de workflow de Camunda® doit être créé dans le modeler Camunda®.

Chaque WF doit contenir au minimum :

• un event start
• une task
• un event end

Chaque étape du WF est liée à l’étape suivante par un “flow”.

Structure du modeler

Le modeler de Camunda® est constitué de :

• Action de WF (1)
• Schéma (2)
• Panneau de propriétés (3)

Seuls les boutons d’action suivant sont utilisables en v6.5.2 :

• Event start
• Flow
• Task
• Gateway

Créer un fichier “bpmn”

🔧 Cette action nécessite un paramétrage.

Pour créer un nouveau fichier de workflow, 2 solutions :

• Créer un nouveau fichier et cliquer sur le bouton “BPMN diagram (Camunda Platform)” :
• Utiliser un fichier BPMN existant ci-dessous 👇 en l’ouvrant depuis Fichier > Ouvrir fichier
demo1.bpmn13.0KB

Lors de la création du fichier bpmn, le panel de properties est accessible sur la droite.

Il faut renseigner les éléments structurants suivants qui seront ensuite repris dans PM :

Camunda®	PM
id	code
Name	Libellé

Le nom du fichier bpmn à la sauvegarde n’est pas une entrée essentielle car non repise dans PM. En revanche elle permet de gérer les version dans votre environnement en développement.

Lors de l’import d’un WF, c’est l’id qui permet d’identifier s’il s’agit d’un nouveau WF ou d’une nouvelle version de WF.

Créer une action

Les actions sont créées par Drag&Drop.

Il suffit de saisir une action dans le menu et de cliquer glisser dans la zone “schéma”.

Idéalement on procédera en 2 étapes :

• Modélisation du WF dans son intégralité
• Paramétrage de chaque action

Une fois glissée dans le schéma, chaque action disposera de son propre menu de paramétrage 👉

Au clic sur la clé, le menu s’affiche et permet de déterminer la nature de l’action.

Le panel “properties” s’ouvre pour réaliser le paramétrage.

Chaque paramétrage d’action est détaillé ci-dessous.

Créer un “event start”

🔧 Cette action ne nécessite aucun paramétrage.

Chaque WF doit commencer par un “évènement”. Il est donc nécessaire de créer un “Event start” 👉

Créer une “task”

🔧 Cette action nécessite un paramétrage

Le principe du WF de PM est de travailler avec des tâches de WF, aussi il est nécessaire de matérialiser chaque étape à valider par une “Task” 👉

Il existe plusieurs types de tâche :

• Les tâches de WS “Service task”
• Les tâches user “User task”

Service task

🔧 Le paramétrage est essentiel et DOIT respecter les paramètres et leur casse.

Le service task crée la tâche de WF PM.

Elle se matérialise par l’icône roue crantée.

Elle utilise dans le panel properties les webservices et les variables de WF.

General

Id	Id de la tâche
Name	Nom de la tâche
Implementation	Connector

Connector

	Nom de la variable	Variable assignment type	Variable assignment value	Valeur
Connector id	http-connector	String or Expression	#NA
Input parameters	headers	Map	X-PM-API-LOGIN	user id
			X-PM-PASSWORD	user pw
			Content-type	application/json
	method	String or Expression	POST
	url	String or Expression	url	http://localhost:8080/MonitorMakerWeb/api
	payload	String or Expression	BeanTacheEntree	Voir liste de variable

Liste des variables

Les variables suivantes sont appelées dans le payload (webservice) pour exécuter les tâches de WF sur le projet et l’instance de WF du projet :

• "projet": { "id": #{execution.getVariable('projectId')}} —> récupère l’id projet de l’instance en cours
• "idInstance":"#{execution.getProcessInstanceId()}” —> récupère l’id de l’instance de WF
• "id": #{execution.getVariable('documentId')} —> récupère l’id document de l’instance en cours
• "idWorkflow":"validation_statut_tache1” —> définit la user task en attente de l’exécution de la tâche
• #{statusCode=='CODE_STATUT_TACHE'}
• #{execution.getVariable('projectLabel')} —>récupère le libellé du projet
• “code” : “CODE-DONNE-POUR-LA-TACHE” —> Permet de déterminer un code pour la tâche
• “parent” : {”code”:”CODE-DONNE-POUR-LA-TACHE-PARENTE”} —>Permet de rattacher une tâche à une tâche parente
• “listeRolesParticipants” : ["ARBITRE_DEMANDE","ROLE_CONTRIBUTEUR"] —> Permet de définir une liste de code rôle (ex : pouvoir notifier plusieurs rôles et participants sur une tâche)

User task

🔧 Cette action ne nécessite pas de paramétrage

Le user task définit le paramètre d’écoute de la tâche, la plupart du temps le statut tâche et permet l’avancement du WF dans PM.

Elle se matérialise par l’icône User.

Une tâche user task est toujours précédée d’une service task.

Créer un “flow”

🔧 Cette action peut porter du paramétrage lorsque c’est nécessaire.

L’évènement flow sert à modéliser le chemin du process d’un évènement à un autre 👉

Lorsque le flow porte une décision de WF, il est nécessaire de paramétrer le statut écouté.

General

id	id
Name	Nom
Condition type	Expression
Expression	#{statusCode=='STATUT_TACHE_REFUSEE'}

Créer une “gateway”

🔧 Cette action ne nécessite pas de paramétrage.

Une gateway permet de créer plusieurs chemin de WF.

2 type de gateway en V6.5.2 fonctionnent correctement :

• Exclusive gateway

Une gateway exclusive permet de déterminer de plusieurs chemins indépendants qui mèneront chacun vers une fin de WF.

• Parallele gateway

Une gateway parallèle permet de créer plusieurs évènements ou tâches en parallèle et qui se rejoignent vers un event end commun.

Créer un “event end”

🔧 Cette action ne nécessite pas de paramétrage.

Chaque flow du processus décrit doit finir par un event end.

Sauvegarder le fichier de WF

Le nom de fichier sert à identifier les versions de WF, mais n’est pas utilisé par ailleurs dans PM.

Fonctionnement dans PM

Une fois réalisée la modélisation du process dans le modeler Camunda, il est possible de le charger dans PM.

Toutefois, il est nécessaire de s’assurer que l’add-on a été activé.

Activation de l’Add-on

L’activation de l’Add-on se fait au niveau MM, connecté en savirage.

Dès que l’add-on est activé, plusieurs conséquence sont effectives dans PM :

Proposition de check list avant activation de l’add-on :

Upload WF

L’administration des WF se fait de la même manière qu’avec les fichiers JPDL, depuis l’admin > Workflow.

Plusieurs WF peuvent être chargés dans PM. Plusieurs versions de WF peuvent être chargées au fur et à mesure de l’évolution des processus.

Le versionning permet aux projets existants engagés dans un processus de terminer l’ensemble des étapes quand bien même le processus aurait changé.

Camunda® apporte la possibilité de visualiser les schéma de WF, les instances en cours à chaque étape, naviguer vers les instances de projet.

Associer le WF à un gabarit

Le WF a été importé dans l’administration, il faut alors l’associer à un gabarit.

C’est la seule manière à partir de laquelle un projet hérite d’un WF sous-jacent.

Si le projet n’a pas été créé depuis le gabarit il est possible a postériori d’appliquer unitairement ou en masse le gabarit aux projets. Il deviendra ainsi possible de déclencher le WF sur les projets existants.

Définir un statut déclencheur

Lors de l’association d’un WF à un gabarit, il est possible de définir le mode de déclenchement du WF sur les projets :

• déclenchement par statut projet
• déclenchement par statut document
• déclenchement manuel

Il suffira alors de sélectionner la valeur de liste dans le sélecteur proposé.

Visualisation des WF

Il existe 2 modes de visualisation des workflow :

• La visualisation dans le projet
• La visualisation en admin

Visualisation projet

Visualisation admin

Historique des workflows

Chaque définition de workflow dispose de son propre historique. Cela permet d’identifier quelles création/modification/suppression ont été réalisées.

Exemple de fichier de WF

Exemple avec libellé du projet dans le libellé de la tâche

Exemple avec lien entre 2 tâches

Exemple avec Notification de plusieurs participants