Les règles de Workflow permettent de définir l'exécution d'un certain nombre d'actions lorsque des événements particuliers arrivent au sein du progiciel Sage X3.

Les actions possibles sont :

  • l'envoi de messages par la messagerie
  • l'apparition de notifications dans des plans de travail
  • la mise à jour de données par l'exécution d'actions, soit directement au moment où l'événement se produit, soit ultérieurement lorsque le ou les destinataires de la notification auront réagi (action de visa ou de signature dans le plan de travail, clic sur un lien dans le message, double-clic pour se connecter dans un contexte lié et réaliser des mises à jour manuellement)

Des données issues du contexte de déclenchement pourront être utilisées dans les messages, les notifications, les actions.

Les événements à l'origine d'une règle de Workflow peuvent être très divers :

  • action de l'utilisateur dans une gestion d'objet (création, modification, déclenchement d'une action)
  • exécution d'une tâche batch, d'un import, d'une édition
  • action de signature sur une notification antérieure (dans ce cas, on peut avoir des circuits complexes de signature imbriqués)
  • traitement batch parcourant un ensemble de tables de la base  

L'envoi des messages est conditionné par l'utilisation d'une messagerie acceptant l'interface MAPI lors de l'envoi depuis le poste client ou SMTP POP3 lors de l'envoi depuis le serveur (ce qui est le cas de la plupart des messageries du marché).

Les destinataires des notifications du Workflow peuvent être paramétrés directement dans la règle, soit par le biais d'un code utilisateur, soit par le biais d'un code tiers et d'un type d'interlocuteur chez le tiers. Mais il est aussi possible de créer des tables multi-critères nommées règles d'affectation, pour permettre à un utilisateur tiers de définir les destinataires en fonction de valeurs des critères pré-définis.

Pré-requis

SEEREFERTTO Reportez-vous à la documentation de Mise en oeuvre

Gestion de l'écran

L'écran de paramétrage des règles Workflow est composé de 5 onglets, dont les 3 premiers relèvent du paramétrage de base, (il suffit de remplir les champs essentiels de ces trois écrans dans les cas simples de notification), et les deux suivants permettent un paramétrage avancé :

  • Le premier onglet permet de définir le contexte de déclenchement de la règle.
  • Le second donne la liste des destinataires du message ou des notifications.
  • Le troisième permet de saisir le corps du message, lorsqu'un message doit être envoyé, ainsi que la définition d'éventuelles pièces jointes.
  • Le quatrième permet de définir les conditions éventuelles de signature, lorsqu'une règle de Workflow suppose un enchaînement d'étapes ultérieures et un processus de signature.
  • Le cinquième est utilisé lorsqu'il est nécessaire de déclencher des actions particulières (par action, on entend des sous-programmes normalisés, soit pré-définis et documentés, comme par exemple les actions liées à l'engagement d'un budget, soit spécifiques réalisés par un intégrateur pour répondre à un besoin particulier).

En-tête

Une règle est identifiée par un code, mais on peut lui associer, pour des raisons d'organisation, une catégorie définie dans une table diverse. Ce sont donc ces informations que l'on retrouve en tête de l'écran.

Onglet Général

Cet onglet définit le contexte de déclenchement, donné par un type d'événement et un code associé, ainsi que, dans certains cas, des codes opération complémentaires. On trouve aussi un tableau de conditions : elles doivent être vérifiées pour que la règle soit déclenchée. Certains événement agissant sur des données organisées selon un schéma en-tête et lignes, on précise alors à quel niveau chacune des conditions porte.

On peut par ailleurs associer à une règle un modèle de données, qui décrit un ensemble de tables complémentaires qui seront lues lorsque la règle sera testée. Dans le cas d'une règle dont le type est Manuel, ce modèle de données est obligatoire, le seul contexte existant étant lié au modèle. Dans le cas de règles liés à des objets, ou à des événements divers, ce modèle est optionnel, et permet simplement de compléter les tables en ligne.

En fonction du type de règle et du modèle qui lui est associé, on pourra définir si le workflow porte sur les informations d'en-tête ou sur les informations de ligne, et, le cas échéant, on définira comment les lignes sont regroupées.

Enfin, une règle d'affectation peut être donnée pour définir la façon dont les destinataires du message seront définis. Une telle règle peut renvoyer un ou plusieurs destinataires. Les destinataires en question pourront recevoir la notification issue de la règle, ou être transmis à une règle suivante, dans le cas de signatures enchaînées.

On trouvera dans une annexe technique le détail des informations disponibles dans le contexte d'exécution.

Onglet Destinataires

Cet onglet permet la saisie de la liste des destinataires des messages ou des notifications. Un destinataire peut être défini comme un utilisateur (on retrouve alors son adresse de messagerie dans la fiche utilisateur), ou comme un tiers (on identifie alors les contacts concernés par leur fonction).

Chaque ligne du tableau définit un ou plusieurs destinataires (selon l'option délégués retenue), et ces destinataires peuvent recevoir :

  • un message
  • une notification impliquant un suivi simple (visa) ou une signature
  • ou les deux

Le groupe de destinataires définis par une ligne de tableau est considéré comme solidaire du point de vue des signatures : il suffit qu'un des membres du groupe ait signé pour que la ligne soit considérée comme signée (le nom du signataire étant propagé dans les signatures en attente pour le groupe).

Par contre, s'il y a plusieurs lignes, la signature d'un des destinataires d'une ligne ne se propage pas aux autres lignes. On pourra alors tester, dans un contexte de signature, le nombre de groupes (de lignes) ayant déjà signé, afin de provoquer une mise à jour en tenant éventuellement compte des autres signataires.

Onglet Message

Cet onglet permet la définition du contenu du message envoyé aux destinataires concernés. Un message est composé :

  • d'un champ "objet" (exprimé sous forme d'une formule adonix incluant si nécessaire des constantes, des fonctions, et des variables issues du contexte). Ce contexte est défini plus précisément dans l'annexe technique de la documentation.
  • d'un texte principal défini dans le bloc correspondant. On peut y inclure des formules adonix en les encadrant avec des barres verticales. La date courante, par exemple, serait exprimée sous la forme | date$ |, le code de l'utilisateur courant sous la forme | GUSER |. On peut insérer un clob (maximum 5) en écrivant |CLB/CLOB|, où CLOB est une variable de type clob ou expression dont le résultat est un clob.
  • d'un éventuel texte de ligne, correspondant à un sous-détail ligne quand le Workflow est de type en-tête/ligne. Le tableau des lignes associées à chaque en-tête est alors inséré dans le texte principal à l'endroit où la formule |LIG| a été définie.
  • d'éventuels liens permettant de déclencher des signatures par sollicitation d'un serveur http. Ces liens s'écrivent avec des formules de type |SIG/CODE/MESSAGE|, où CODE est le code de la réponse qui va être faite.

    Ainsi, par exemple, on pourrait écrire :
        |SIG/VAL/"Pour signer, cliquez sur :"|
        |SIG/REJ/"Pour refuser, cliquez sur :"|
    On verrait alors apparaître dans le corps du message :
        Pour signer, cliquez sur lien déclenchant la signature
        Pour refuser, cliquez sur lien déclenchant le refus
    Ces liens étant bien entendu des liens http variables incluant le contexte nécessaire pour transmettre l'information nécessaire.

Indépendamment de ces éléments, un certain nombre de champs complémentaires définissent les conditions de l'envoi, ainsi que les informations (pièces jointes) qui peuvent être insérées dans le message.

Il est nécessaire que le paramètre général TYPMES soit égal à Serveur pour que des pièces jointes puissent être envoyées. Si ce n'est pas le cas, seule la première pièce jointe est envoyée (ceci est signalé par un message d'avertissement lorsqu'on impose un envoi par Client). Par ailleurs, les pièces jointes doivent être accessibles depuis le serveur d'application (par un chemin réseau si elles ne sont pas stockées dans la base).

L'envoi des messages est conditionné par l'utilisation d'une messagerie acceptant l'interface MAPI lors de l'envoi depuis le poste client ou SMTP POP3 lors de l'envoi depuis le serveur (ce qui est le cas de la plupart des messageries du marché).

Les destinataires des notifications du Workflow peuvent être paramétrés directement dans la règle, soit par le biais d'un code utilisateur, soit par le biais d'un code tiers et d'un type d'interlocuteur chez le tiers. Mais il est aussi possible de créer des tables multi-critères nommées règles d'affectation, pour permettre à un utilisateur tiers de définir les destinataires en fonction de valeurs des critères pré-définis.

Onglet Suivi

Cet onglet permet de définir la façon dont les notifications de type Suivi sont faites dans les plans de travail des utilisateurs destinataires, et également les conditions de signature associées, s'il y en a. Ces conditions de signature ne sont applicables que si, dans le tableau des destinataires de l'onglet correspondant, les utilisateurs destinataires sont en suivi Avec signature.

On définit alors, sous la forme d'expressions évaluées, le message à faire apparaître dans le plan de travail, et la date limite attendue de signature si une signature est attendue.

On trouve ensuite un tableau permettant de préciser les réponses que l'utilisateur pourra faire lors de sa signature, avec la possibilité de mettre directement à jour un champ de la fiche courante lorsque le Workflow est de type Objet.

Il est à noter que les éléments évalués dans le tableau des réponses le sont au moment de la signature, alors que les éléments relatifs à la notification ou au message associé le sont au moment du déclenchement du Workflow d'origine. Ceci signifie que le contexte n'est plus exactement le même. Ainsi, dans un contexte Workflow de type objet, on a en ligne:

  • lors du déclenchement, l'ensemble des variables des écrans et des tables liées à l'objet, ainsi que les tables complémentaires liées à un modèle de données et à une règle d'affectation éventuelles, et les variables globales liées au contexte du signataire (GUSER représente le code de l'utilisateur ayant déclenché l'événement).
  • lors de la signature, on a en ligne l'enregistrement de la table principale de l'objet, ainsi que les tables décrites dans un modèle de données et une règle d'affectation éventuelles, mais on ne dispose plus des écrans en ligne, et les variables globales sont celles du contexte de la signature (GUSER représente alors le code de l'utilisateur qui signe).

Pour permettre de transmettre des valeurs du contexte de déclenchement vers le contexte de signature, on dispose d'un tableau nommé Contexte. Les expressions qui y sont décrites sont évaluées et transmises au moment de la signature sous la forme d'un tableau de variables locales nommées [L]CTX. Ces variables peuvent alors être utilisées dans le paramétrage des plans de travail, dans les conditions et valeurs liées à la signature, et également dans les valeurs et variables liées aux Actions de l'onglet suivant, lorsqu'il s'agit d'action déclenchées lors de la signature.

Onglet Action

Cet onglet décrit, dans un premier tableau, une liste d'actions qui peuvent être déclenchées lors du déclenchement de l'événement ou lors de la phase de signature. Ceci permet d'appeler soit des actions standards prédéfinies à cette fin (on en trouvera une liste dans l'annexe technique correspondante), soit des actions spécifiques. Il est à noter que l'action en question n'est appelée que si la condition d'exécution est réalisée.

Le tableau situé en dessous est automatiquement chargé avec la liste des paramètres de l'action, afin de permettre de saisir en regard une liste d'expressions évaluées dans le contexte et transmises (soit comme des valeurs, soit comme des pointeurs : dans ce dernier cas, les valeurs de retour sont utilisables dans la suite).

Boutons spécifiques

Validation

Ce bouton permet de générer et de compiler le traitement automatique associé à l'événement de Workflow. Ce traitement est codifié par les caractères WMK suivis du code du Workflow. Comme la validation se fait de façon automatique à l'enregistrement ou à la modification d'un Workflow, ce bouton n'est utile que pour valider un événement qui aurait été transféré par copie depuis un autre dossier.