Annexe technique Workflow

Algorithme principal Workflow objet

Un Workflow de type objet se décompose en une série d'étapes qui sont les suivantes :

• Initialisation des variables d'environnement
• Pour un workflow de type en-tête ou de type ligne sans regroupement, traitement de la règle d'affectation si elle existe, puis traitement du workflow
• Pour un workflow de type ligne avec regroupement, lecture des lignes avec rupture sur les différentes valeurs du groupe. A valeur constante, on exécute les actions de type ligne qui existent, et on formate le texte ligne. Puis on traite la règle d'affectation pour le groupe si elle existe, et on traite le workflow pour le groupe, avant de passer au groupe suivant.

Initialisation des variables d'environnement

Cette étape consiste à affecter des variables globales. On dispose notamment de la variable USRWRK qui correspond à l'utilisateur courant du workflow d'origine.

Traitement de la règle d'affectation

Dans cette étape, on évalue les formules données dans la règle, et on les stocke dans une variable dimensionnée nommée VALEXP. Ceci permet de disposer notamment de valeurs agrégées qui ne sont pas forcément utilisées comme critère de définition des destinataires, mais simplement utiles dans la suite du Workflow (par exemple pour décider de l'envoi d'un message en fonction de valeurs minimum, maximum, moyennes d'un élément).

Le nombre de valeurs calculées est connu par la variable NBCOL.

On recherche ensuite, à partir des valeurs calculées, la ligne de règle qui correspond, pour affecter le tableau de variables USER (indicé de 1 à 10 maximum).

Traitement du Workflow

Cette étape se décompose en plusieurs sous-étapes. Tout d'abord, on détermine un certain nombre de valeurs :

• on initialise la variable CTX, qui contient le contexte courant, d'après les formules paramétrées. Ce contexte est stocké dans l'historique Workflow et sera ensuite restituée si un événement Workflow ultérieur est déclenché en suivi du premier.
• On affecte les variables S_USER, S_CLEOBJ, S_ABREV, qui définissent l'utilisateur à l'origine du Workflow, la clé de l'objet ou du groupe de lignes, et le code objet concerné.
• On calcule S_NBRUSER, qui donne le nombre de signataires réellement définis dans la règle.

Ensuite, on vérifie les conditions d'exécution en tête du Workflow. Si ces conditions sont réalisées, on réalise les opérations suivantes :

• Constitution du contexte de retour (icône).
• Attribution d'un numéro de chrono à chaque traitement d'une règle. Dans le cas du Workflow manuel, une attribution est faite à chaque fois que l'on change de valeur de clé sur la table principale (s'il n'y a pas de champ regroupement) ou de valeur de regroupement (s'il y en a une).
• Attribution d'un numéro de chrono pour chaque ligne (il y en a plusieurs par groupe s'il y a un regroupement).
• Exécution de l'action de début de Workflow (s'il en existe et que les conditions sont réunies).
• Si un message doit être envoyé, ou un suivi fait, recherche des utilisateurs délégués.
• Si un message doit être envoyé, traitement du message.
• Si un suivi doit être fait, traitement du suivi.
• Exécution des actions de type fin de Workflow (s'il en existe et que les conditions d'exécution sont vérifiées).

Traitement du message

Cette étape réalise les opérations suivantes :

• Constitution du texte par assemblage du texte principal et du texte du détail des lignes (s'il y en a).
• Constitution de l'objet du message.
• Affichage de la fenêtre de modification du message (si le message est modifiable et si le déclenchement interactif).
• Transaction d'écriture dans les tables correspondantes : AWRKHISMES contient le corps du message, AWRKHISJOI les pièces jointes, et AWRKHISDES les destinataires.
• Envoi du message si l'option d'envoi groupé est non activée. Sinon, l'envoi groupé sera fait en fin de traitement du workflow.

Traitement du suivi

Cette étape réalise la mise à jour de la ligne de suivi à traiter dans la table AWRKHISSUI. La transaction correspondante est séparée des précédentes (mais elle n'est exécutée que si les précédentes se sont bien passées).

Algorithme principal Workflow signature

Un Workflow de type signature est déclenché à la suite d'une action de signature (soit manuelle depuis le plan de travail, soit automatique via un autre événement de Workflow ou une notification via un clic sur un lien).

Les étapes correspondantes sont les suivantes :

• Initialisation des variables héritées
• Chargement des classes de variables [F] (tables) définies par l'événement d'origine
• Si c'est un Workflow de type en-tête ou de type ligne sans regroupement, traitement de la règle d'affectation, puis traitement du Workflow.
• Si c'est un workflow avec un regroupement de lignes, lecture des lignes de groupement correspondant au suivi, traitement de la règle d'affectation, puis traitement du Workflow.
• Pour chaque ligne, exécution de l'action de type ligne et formatage du texte de la ligne.
• La suite du processus est identique à un Workflow standard.

Initialisation des variables héritées

Les variables héritées du contexte de signature sont affectées dans cette phase. Ces variables sont les suivantes :

NUMORG	numéro chronologique d'origine.
USRORG	destinataire de l'événement d'origine.
NUMSIG	chrono sur lequel a été déclenché le processus de signature.
USRDES	destinataire du chrono sur lequel a été déclenché le processus de signature.
USRWRK	utilisateur qui signe.
MAIWRK	adresse de messagerie du signataire, lorsque la signature se fait par un lien http externe.
LEVSIG	Niveau de signature (l'événement d'origine porte le numéro 0, les événements qui s'enchaînent portent les numéros successifs à partir de 1).
RETORG	Clé de l'objet sur lequel a été déclenché le Workflow d'origine.
CONTXT	Référence de l'icône de retour.
CLEOBJ	Numéro du chrono signé.
CTX(1..15)	Variables du contexte.
S_USER	Destinataire ayant déclenché le Workflow d'origine.
S_CLEOBJ	Clé de déclenchement (objet ou regroupement).
S_ABREV	Abréviation de l'objet du Workflow d'origine.
S_NBRUSR	Nombre d'utilisateurs définis dans la règle de Workflow d'origine

Algorithme de traitement d'une signature

La phase de signature d'un événement se fait par le processus suivant :

• initialisation du contexte de signature.
• Vérification de l'existence du chrono et verrouillage.
• Evaluation (au vu des conditions) de la liste des réponses autorisées.
• Saisie d'une réponse parmi les réponses possibles.
• Verrouillage de la fiche qui a généré le premier suivi.
• Chargement des classes de variables [F]
• Mise à jour de la variable RESULT en fonction de la réponse
• Modification de cette variable par saisie (si la réponse est modifiable)

Ensuite, la transaction de signature à proprement parler est faite :

• Exécution des actions de signature s'il y en a
• Mise à jour du champ correspondant à la réponse (s'il existe)
• Traitement de la règle de Workflow associée à la signature (s'il en existe une)
• Mise à jour de la ligne de suivi (flag signé, signataire correspondant).

Initialisation du contexte de signature

Lorsqu'un utilisateur signe un suivi, les variables disponibles dans le contexte sont les suivantes :

CHRONO	chrono de l'événement sur lequel on va faire une signature.
USRDES	code utilisateur du destinataire.
USRSIG	Code utilisateur du signataire.
USRMAIL	adresse de messagerie du signataire, lorsque la signature se fait par un lien http externe.
NUMORG	Chrono événement d'origine sur lequel a été fait la première signature.
USRORG	Destinataire de cet événement.
LEVSIG	Niveau de signature (l'événement d'origine porte le numéro 0, les événements qui s'enchaînent portent les numéros successifs à partir de 1).
USRTOP	Destinataire principal (les autres sont des délégués).
NUMGRP	Groupe de l'événement à signer.
CTX(1..15)	Variables du contexte.
S_USER	Destinataire ayant déclenché le Workflow d'origine.
S_CLEOBJ	Clé de déclenchement (objet ou regroupement).
S_ABREV	Abréviation de l'objet du Workflow d'origine.
S_NBRUSR	Nombre d'utilisateurs définis dans la règle de Workflow d'origine

Le tableau de variables REPCHR permet de savoir si d'autres destinataires du même événement ont déjà signé. On compte en fait le nombre de groupes (un groupe est égal à une ligne dans le tableau des signataires, dès qu'un délégué a signé, l'événement est signé et ne peut pas être signé une deuxième fois par un autre membre du même groupe).

On a alors :

REPCHR(0) = nombre de réponses qu'il reste à faire : si par exemple il y a 4 lignes de signataires dans la description de l'événement et qu'un seul a signé, cette valeur est égale à 3.

REPCHR(NO), où NO peut valoir de 1 à 10, donne le nombre de signataires qui ont répondu avec la réponse placée sur la ligne numéro NO dans le tableau des réponses.

Ces variables permettent notamment de conditionner les étapes suivantes par le fait que le dernier signataire en attente a répondu, ou de travailler sur des logiques majoritaires de signature.