1. Home
  2. Fiches pratiques
  3. Bonne pratiques de modélisation

Bonne pratiques de modélisation

Nous allons voir ici quelques règles/pratiques permettant d’améliorer la lisibilité ainsi que la maintenabilité de vos processus.

À noter qu’il existe des circonstances dans lesquelles nous pouvons décider d’aller à l’encontre de ses bonnes pratiques afin d’obtenir des comportements spécifiques.

Utiliser un « sous-processus interne » pour isoler un morceau de processus

Les sous-processus internes ne servent pas qu’à rassembler des tâches pour y mettre des événements de bordure. Ils peuvent être bénéfiques pour regrouper des tâches et accompagner graphiquement l’utilisateur qui visualise le diagramme.

Les portes logiques sont toujours soit fermantes soit ouvrantes : on évite les deux en même temps.

Il est fortement déconseillé pour une porte d’être la fois ouvrante et fermante. Le modèle BPMN en perd considérablement en lisibilité. Même si une porte à double emploi permet dans certains cas d’éviter de croiser des flux.

Exception

Les portes événementielles sont les uniques exceptions et peuvent être fermantes et ouvrantes dans le seul cas elles bouclent sur elles-mêmes.

Mails/Webservice en parallèle

Une bonne pratique consiste à extraire du flux normal, les mails et certains webservices, afin d’éviter que le workflow ne soit bloqué en cas d’erreur sur le service. Alors, oui, cela complique légèrement le dessin, mais l’expérience utilisateur passe avant tout.

Dans ce cas-ci, en cas d’erreur lors du service, le flux est interrompu.
Dans ce cas-ci, en cas d’erreur lors du service, le flux n’est pas interrompu.

Dans ce cas, si le service plante : le processus est stoppé.
Alors que dans ce modèle, le service est indépendant du reste du processus.

Dépil de variable

Dépiler consiste à transformer une exécution unique en de multiples exécutions en lisant un à un les différents éléments d’une variable.

Par exemple : Sur un processus de commande, le demandeur remplira une variable composée, c’est-à-dire un tableau comme son panier et chaque ligne lancera individuellement le sous processus de picking.

Exemple d’un depil

Pour lancer N fois un sous processus en même temps et attendre les N fins avant de passer à la suite du traitement, vous devez utiliser les processus internes. Voici un exemple :

Voici le script à mettre dans dépil :

var json_content = JSON.parse(start_commandeClient); //contenu
io.set("depil_maxLecture", json_content.length-1);
var _index = parseInt(format.replaceValueIfNull(execution, "depil_index", -1))+1; // (dernier index lu ou -1)+1
io.set("depil_index", _index);

var _index;
if (utils.hasValue(execution, "depil_index")){
    _index= depil_index+1;

io.set("depil_var1",_variable[index].var1);
io.set("depil_var2",_variable[index].var2);
Exception

La porte logique doit être le résultat d’une comparaison entre l’index lu et le max de lecture.

Variabiliser les mails ou faire deux tâches ?

Nous déconseillons fortement d’utiliser une même tâche pour envoyer plusieurs mails.

Dès lors que le mail est un petit peu différent, il devient nécessaire pour un meilleur suivi, d’avoir un courriel par tâche.

Voici un exemple avec la gestion de 2 mails de rappel à 3 jours et à j-1.

Mauvaise gestion de 2 mails de rappel
Gestion conseillée de 2 mails de rappel

Privilégier le BPMN aux scripts

Afin d’améliorer la lisibilité du processus, nous conseillons de toujours privilégier une solution compréhensible à vue d’œil si c’est possible. Une tâche de script nécessite d’aller consulter et d’appréhender sa configuration pour saisir ce qu’elle fait.

Par exemple, voici 2 processus qui font la même chose, le premier avec une tâche de script que nous avons remplacée par un élément BPMN dans le second.

La tâche de script Set True peut être remplacée par une simple porte XOR.
Le processus devient bien plus lisible.

Utiliser des minuteurs de bordures sur des sous-processus

Pour augmenter encore plus la lisibilité de vos processus, il est conseillé d’utiliser les sous-process internes.

Par exemple, voici 2 processus qui font la même chose, nous avons placé la boucle dans un sous-processus pour rendre le processus bien plus lisible.

Processus à très longue durée de vie

Lorsqu’un processus à une durée de vie supérieure à un an, il est préférable de le découper en plusieurs processus plus courts afin de profiter des améliorations assez vite. Pour ce faire, mieux vaut utiliser des sous-processus qui s’appellent.

Il est préférable d’utiliser un sous-processus vers lui-même plutôt qu’une boucle au départ.

Processus avec une durée de vie infinie
Processus avec durée de vie maximum de un an

En cas de modification du start, il faudra penser à prendre en compte (souvent par script) les cas où le mapping n’aurait pas été fait correctement (processus déjà lancés avant évolution)

Dans le mesure du possible, il faudrait également éviter les affectations au lanceur car il ne sera jamais possible de le changer.

Updated on 13 janvier 2021

Was this article helpful?

Related Articles

Need Support?
Can't find the answer you're looking for?
Contact Support