Règles Workflow
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
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.
Bloc numéro 1
Code (champ CODE) |
Ce champ identifie la règle de Workflow. |
Intitulé (champ INTIT) |
Permet de définir un intitulé associé à chaque fiche. |
Bloc numéro 2
Catégorie (champ CATEG) |
Ce champ permet de faire des regroupements par typologie des règles de workflow. |
Actif (champ ENAFLG) |
Tant que cette case n'est pas cochée, la règle de Workflow n'est pas susceptible de se déclencher. |
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.
Evénement déclenchant
Type événement (champ TYPEVT) |
Le type d'événement Workflow peut prendre les valeurs suivantes :
|
Code événement (champ CODEVT) |
Ce champ permet de préciser le contexte déclenchant, selon le type qui est défini au préalable :
Ce champ n'est obligatoire que pour le type d'évènement Divers. S'il n'est pas renseigné, l'événement se déclenche de façon générique, sachant qu'il est toujours possible de tester davantage le contexte pour être sélectif (grâce notamment aux variables GFONCTION, GOLDETAT...) |
champ LIBEVT |
Intitulé associé au code saisi dans la rubrique précédente |
Opérations (champ OPERATION) |
Ce champ permet de préciser de façon plus fine le contexte d'exécution de la règle de Workflow. Selon les types de Workflow, les informations saisies sont différentes :
|
Fin de transaction (champ TYPDEC) |
Dans le cas de la modification d'une fiche d'un objet simple, le worflow peut être déclenché avant la mise à jour des tables (ce qui permet de définir des critères sur les classes [F] et [M]) ou en fin de la transaction de modification (après la mise à jour des tables). |
Bloc numéro 4
Modèle de données (champ MODELE) |
On peut indiquer ici un modèle de données qui définit un ensemble de tables liées qui doivent être disponibles dans le contexte du Workflow. Dans le cas d'un événement de type Manuel, ce code est obligatoire pour définir le contexte d'exécution; dans les autres cas, il permet simplement de compléter ce contexte. |
Règle d'affectation (champ REGLE) |
Ce champ permet de définir des règles d'affectation des destinataires de Workflow de façon externe à la règle. Il fait référence à une table de règles dans laquelle on définit une liste de champs sur lesquels porteront les critères d'affectation des destinataires. Une règle est évaluée au moment du déclenchement du Workflow, en fonction du contexte, et renvoie un ou plusieurs utilisateurs définis par un tableau de variables locales [L]USER, ce qui permet soit de donner une liste de destinataires pour un Workflow donné, soit une chaîne de destinataires dans le cas d'un enchaînement de règles. Il est important de noter que :
|
Bloc numéro 5
Type workflow (champ TYPWRK) |
Définit si on déclenche un Workflow sur chaque ligne de détail ou uniquement sur l'en-tête. Ce champ n'est pas saisi, mais affiché :
Si aucune règle d'affectation n'est donnée, mais qu'un modèle intégrant des liens (1,N) est associé, le champ est saisi. On peut alors choisir si le déclenchement se fait à la ligne ou à l'en-tête (sachant que les lignes peuvent être regroupées par ailleurs pour envoyer une notification par groupe). |
Table ligne (champ TABLIG) |
Permet de définir le champ ligne dans le cas d'une règle où le contexte intègre des tables d'en-tête et des tables de ligne. |
champ ABRLIG |
Regroupement lignes (champ GROUPE) |
Ce champ permet de définir des critères de regroupement en donnant une liste d'expressions (ou de champs) séparés par des points virgule. Ceci permet de regrouper des lignes de détail pour ne déclencher qu'un Workflow qu'à chaque rupture sur les valeurs définies par ces expressions. Ceci est possible dans deux cas :
|
Tableau Conditions
Type (champ TYPCND) |
Lorsque l'événement de Workflow est de type Ligne, les conditions peuvent porter soit sur l'en-tête, soit sur la ligne, selon le choix saisi ici. |
Conditions (champ CONDITION) |
Ces champs permettent des conditions complémentaires sous la forme d'expressions logiques ( Formule de calcul) incluant des variables en ligne au moment de l'exécution de la règle (contenus de masques d'écrans ou de tables en ligne, selon la description du contexte...). Si ces conditions sont toutes vraies, le message sera envoyé et/ou la trace écrite dans le fichier log. Il est à noter que, lorsque le contexte est de type en-tête et lignes, on peut filtrer une partie des lignes reliées à un en-tête en définissant des conditions lignes pour ne pas tenir comptes des lignes pour lesquelles la condition est fausse. S'il reste au moins une ligne concernée et que les conditions de l'en-tête sont vraies, le déclenchement se fera quand même. |
Gestion
Activation mail (champ ENAMES) |
Indicateur permettant d'activer ou non l'envoi des messages indiqués dans l'onglet correspondant. |
Activation action (champ ENAACT) |
Indicateur permettant d'activer le déclenchement des actions indiquées dans l'onglet correspondant. |
Activation suivi (champ ENASUI) |
Ce champ permet de définir des règles d'affectation des destinataires de Workflow de façon externe à la règle. Il fait référence à une table de règles dans laquelle on définit une liste de champs sur lesquels porteront les critères d'affectation des destinataires. Une règle est évaluée au moment du déclenchement du Workflow, en fonction du contexte, et renvoie un ou plusieurs utilisateurs définis par un tableau de variables locales [L]USER, ce qui permet soit de donner une liste de destinataires pour un Workflow donné, soit une chaîne de destinataires dans le cas d'un enchaînement de règles. Il est important de noter que :
|
Mise au point (champ DEBUG) |
Indicateur permettant d'activer une aide à la mise au point. Lors de l'exécution d'une règle et si cette option est active, le moteur de workflow émet à l'écran les messages éventuels d'erreur d'évaluation sur les conditions, le log et le message. |
Utilisation thème (champ USETHEMEFL) |
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.
Tableau Destinataires
Condition (champ CNDDES) |
Ce champ permet de définir une condition logique. Si l'évaluation de cette condition renvoie une valeur fausse (ie. nulle), la ligne de destinataires n'est pas concernée par l'événement. Il est à noter que l'on dispose, outre des variables liées au contexte de l'événement, du tableau de variables [L]COND, qui permet, sur une ligne donnée, de faire référence à la condition de la ligne numéro N (N étant l'indice). Ainsi, par exemple, si on exprime une condition sur la première ligne du tableau, et que sur la deuxième ligne, on utilise l'expression : not [L]COND(1), cela signifie que les destinataires de la deuxième ligne seront pris en compte si la condition de la première ligne est fausse. |
Type (champ TYPDES) |
Dans l'application Sage X3, le destinataire peut être lié à :
Dans l'application Sage HRM, le destinataire peut être lié à :
Dans l'application Sage Géode, le destinataire peut-être lié à :
|
Destinataires (champ DESTIN) |
Fonction (champ FNCDES) |
Cette information n'est saisie que si le type de destinataire est un tiers. Elle fait référence au menu local qui définit les fonctions des interlocuteurs dans la fiche tiers. |
Envoi mail (champ ENVOI) |
Trois valeurs peuvent être saisies ici, qui concernent les destinataires de la ligne :
|
Suivi (champ SUIVI) |
Cet indicateur précise si les destinataires de la ligne vont recevoir une notification dans leur plan de travail, selon la valeur saisie :
Dès lors qu'une notification est envoyée à au moins une des lignes de destinataires, l'onglet Suivi définit le texte apparaissant dans le suivi, ainsi que les réponses pouvant être apportées en cas de demande de signature. |
Natures (champ NATURE) |
Ce champ peut être utilisé pour classer les lignes de suivi selon leur catégorie. C'est notamment un critère qui peut figurer dans le plan de travail ou être utilisé comme filtre sur un de ses onglets. |
Option délégués (champ OPTDEL) |
Ce champ permet de préciser la façon dont est géré le fait que le destinataire identifié dans la ligne soit absent (ie. qu'il ait défini un utilisateur délégué pour une période de temps incluant le moment où la règle s'est déclenchée). S'il a défini des utilisateurs délégués Avec pouvoir, la valeur de ce champ définit qui est destinataire de la notification ou du message :
|
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.
Message
Email expéditeur (champ SENDMAIL) |
Objet (champ OBJET) |
Ce champ permet de de définir le contenu du champ Objet du message envoyé, sous la forme d'une expression calculée qui sera évaluée au moment du déclenchement de l'événement. |
Texte
Texte (champ TEXTE) |
Ce champ permet de définir le contenu principal du message. Son écriture se fait sous la forme de texte libre incluant des expressions logiques (Formule de calcul) entre deux barres verticales qui tiennent lieu de séparateur. Ainsi, par exemple, on pourra écrire des contenus tels que : L'événement survenu le | num$(date$) | a donné lieu à cet envoi par | GUSER | Balises particulières : "LIG" Permet d'insérer l'expression définie dans le champ "Ligne" de la règle workflow. |
Gestion
Ligne (champ TEXLIG) |
L'expression calculée saisie dans ce champ est évaluée, au moment du déclenchement de l'événement, pour chaque ligne de détail (dans le cas d'un Workflow de type ligne avec un regroupent des données). Chaque ligne ainsi calculée est insérée dans le corps du message à l'endroit où se trouve la formule |LIG|. En fonction de la longueur de la ligne, il faut parfois rajouter l'expression "chr$(13)+chr$(10)" dans la formule pour forcer le saut de ligne entre chaque ligne. |
Gestion
Envoi (champ TYPMES) |
Ce champ permet de préciser si l'envoi doit être fait localement par le poste (en interface MAPI), depuis le serveur (via SMTP), ou indifféremment depuis l'un ou l'autre (auquel cas un paramètre général nommé TYPMES le définit. |
Icône de retour (champ RETOUR) |
Ceette case permet, si elle est cochée, d'insérer en pièce jointe, dans le message envoyé, un icône contenant le contexte permettant de rappeler la fiche (par double-clic dessus). Attention, ceci ne fonctionne que pour une connexion en mode client-serveur. |
Fonction de retour (champ BAKFCT) |
Lorsqu'une icône permettant de revenir à Adonix X3 est jointe dans le corps du message, ce champ permet d'indiquer une fonction de retour différente de la fonction ayant déclenché le Workflow. En Workflow objet, dans le cas de la création ou de la modification d'une fiche, ceci permet, plutôt que de se connecter sur la fiche par défaut, d'aller sur une fiche liée (la fiche de l'utilisateur ayant créé ou modifié l'information qui a déclenché le Workflow, par exemple). |
Clé de lien (champ BAKLNK) |
Ce champ permet, si la case à cocher Icône de retour est cochée, de définir la fonction sur laquelle l'utilisateur sera connecté après double-clic sur l'icône incluse dans le message. Si la fonction de retour est de type objet, il n'est utile de saisir la fonction que si elle est différente de l'objet d'origine. Dans la cas d'un Workflow Manuel, le code fonction est obligatoire si l'icône de retour est incluse (il ne peut pas y avoir de valeur par défaut dans ce cas). |
Bloc numéro 6
Desktop (champ BAKSYRA) |
Clé de lien (champ BAKLNKSYRA) |
Mobile (champ BAKMOBILE) |
Clé de lien (champ BAKLNKMOBI) |
Bloc numéro 7
Message modifiable (champ INTERV) |
Cet indicateur permet de rendre le message modifiable avant l'envoi : un écran s'ouvre alors pour saisir des modifications. Ceci n'est possible que si le déclenchement du Workflow se fait de façon interactive (sinon, la fenêtre ne s'ouvrira pas). Attention, le fait de cocher cette case provoque l'interruption temporaire du processus de Workflow, puisque l'on est en attente d'une validation de l'utilisateur. Si l'événement de workflow se produit alors qu'une transaction est en cours (ce qui peut être testé par la condition adxlog<>0), tous les autres événements de workflow concurrents sont bloqués par cette saisie. Il est donc fortement recommandé de ne cocher cette case que sur des événements se produisant hors transaction (sauf éventuellement, de façon très temporaire, à des fins de déboguage). Une bonne façon de s'assurer contre ce risque consiste à ajouter, dans les critères de déclenchement d'un événement de ce type, la condition adxlog=0 (ce qui revient à empêcher le déclenchement d'événements de ce type). |
Groupage par destinataire (champ GRPENV) |
Lorsqu'un événement de Workflow crée plusieurs notifications, cette case sert à regrouper les messages créés par l'événement. Il y a plusieurs notifications si le Workflow est de type "Ligne", ou s'il s'agit de l'évènement spécial "ANU" (déclenché sur l'annulation de signature). Les notifications sont regroupées entre elles si elles ont les caractéristiques suivantes en commun :
|
Accusé lecture (champ REQREC) |
Cette case permet, si elle est cochée, d'envoyer le message en demandant un accusé de réception. Attention, ceci ne peut fonctionner que si le message est envoyé depuis le poste client, et pas depuis le serveur. |
Pièces jointes
Fichier trace lié (champ TRACE) |
Cette case ne peut être cochée que si l'événement déclenchant correspond à la fin d'une tâche batch. Dans ce cas, si elle est cochée, le fichier trace associé à la tâche batch va être joint au message envoyé. |
Pièce à joindre (champ JOINT) |
Ce champ permet d'associer une pièce jointe au message, en donnant un chemin d'accès réseau sous la forme d'une expression calculée qui sera évaluée au moment du déclenchement de l'événement. |
Pièce jointe (champ JOIOBJ) |
Quand cette case est cochée, sur un Workflow de type objet, les pièces jointes à la fiche peuvent être envoyées en pièces jointes du message. |
Tous types (champ ALLTYPJOI) |
Ce champ permet, lorsque la case Tous types n'est pas cochée, de définir un filtre sur le type de pièces jointes à la fiche (table diverse 902) qui doivent être envoyées avec le message. |
Type pièce jointe (champ TYPJOI) |
Toutes catégories (champ ALLCATJOI) |
Cette case n'est saisie que :
Si cette case est cochée, toutes les catégories de pièces jointes à la fiche déclenchant le Workflow sont envoyées comme des documents joints au message. Sinon, on saisira la catégorie concernée. |
Catégorie (champ CATJOI) |
Ce champ permet, lorsque des documents joints à une fiche doivent être envoyées en pièce jointe au message, de filtrer les documents liés par leur catégorie (menu local 96) |
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.
Texte
Texte suivi (champ TEXSUI) |
Ce champ contient une expression évaluée au moment du déclenchement du Workflow. Le résultat de cette évaluation est une chaîne alpahnumérique stockée dans la variable [AWS]TEXSUI. C'est cette valeur qui est normalement présentée dans le moniteur Workflow pour qualifier l'événement à signer. |
Signature
Signature (champ FLGSIG) |
Si cette case est cochée, le suivi donne lieu à un processus de signature : on retrouve alors, dans le tableau situé en bas de l'écran, un certain nombre de choix de signature possibles. |
Date limite (champ DELSIG) |
Dès lors que la case Signature est cochée, il est possible de définir une expression de type date définissant la date au delà de laquelle on considère qu'il y a retard si la signature n'a pas été faite. La valeur du champ correspondant est stockée dans le champ DATREL de la table des suivis AWRKHISSUI. Ce champ peut être exploité dans le moniteur Workflow, pour définir un ordre de classement, une mise en valeur par un style particulier (condition de type date$>=[AWS]DATREL+1, par exemple). Mais il peut aussi être exploité pour une gestion de relance des événements en attente de signature, sachant que le champ [AWS]NBREL permet de compter les relances éventuelles faites. |
Tableau Contexte
Contexte (champ VARCTX) |
Ce tableau contient des expressions évaluées au moment du déclenchement d'un Workflow. Ces variables sont :
L'intérêt de ces variables est qu'elles permettent de transmettre des informations qui ne sont pas situées dans les tables à l'origine du contexte déclencheur, et donc qui ne sont pas transmises automatiquement d'un événement à la signature ou à l'événement suivant. En effet, les tables de l'objet, ou celles de la règle d'affectation sont transmises automatiquement; par contre, ne sont pas transmises :
C'est donc ce type de variable qu'il est intéressant de transmettre via le contexte. Mais il est aussi intéressant de définir dans le contexte des variables transmises par ailleurs dans le contexte, simplement pour savoir les visualiser dans le moniteur de Workflow. |
Tableau Réponse
Réponse (champ ACTSIG) |
Ce champ fait référence à la table diverse numéro 54, qui définit des choix possibles à la signature (par exemple Validation, Refus). Dans le plan de travail des signatures, un clic droit sur la ligne à signer permettra de proposer parmi la liste des choix issus de cette liste, ceux pour lesquels la condition est vérifiée. |
Opération (champ OPESIG) |
Ce code opération, défini par la table diverse 55, est le code qualifiant la signature réalisée. Il correspond au code opération utilisé dans un événement de type Signature consécutif à l'événement signé. Il est à noter que plusieurs lignes peuvent porter le même code opération. Ce code n'est pas stocké dans l'historique de Workflow à l'issue de la signature. C'est en effet la valeur du champ Réponse, qui n'admet pas d'homonymes entre les différentes lignes, qui est stocké). |
Condition (champ CNDSIG) |
Cette colonne contient une expression logique évaluée au moment de la signature. Si la condition est réalisée, alors la réponse définie sur la ligne est proposée parmi les choix possibles. Ceci permet, par exemple, de disposer de plusieurs niveaux de signature, en fonction du nombre de signataires ayant déjà signé (seul le dernier signataire ayant accès à une signature qui déclenche une mise à jour finale). De même, il est possible de définir un choix apparemment impossible (par une condition toujours fausse de type 1=0). Ce choix pourra être forcé par une action de signature déclenchée par un autre événement de Workflow. C'est ainsi que sont traités, dans des paramétrages standards, des escalades dans les processus de signature. |
Motif (champ REANUM) |
Cette colonne permet d'indiquer un numéro de table diverse contenant des motifs de réponse. |
Champ mis à jour (champ FLDMAJ) |
Cette colonne contient le nom d'un champ issu d'une des tables du contexte déclencheur. Ce champ va être mis à jour par la valeur calculée à partir de l'expression suivante, lors du processus de signature. Ainsi on peut, par exemple, mettre à jour un champ tel que ENAFLG (indicateur Actif) de l'objet courant lors d'un processus de signature. |
Valeur (champ EXPVAL) |
Cette colonne permet de définir l'expression d'une valeur calculée au moment de la signature. La valeur correspondant à la ligne de réponse choisi sera utilisée, en cas de signature :
|
Modifiable (champ MODSIG) |
Si ce champ vaut Oui, la valeur calculée dans la colonne correspondante est proposée, après le choix de la signature, afin de permettre une éventuelle modification. Ceci permet par exemple de saisir un modif détaillé. La valeur résultant de la saisie sera utilisée pour réaliser la mise à jour s'il y en a une, et transmise à la variable [L]RESULT pour exploitation par une action complémentaire. |
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).
Tableau Action
Code action (champ ACTION) |
Ce champ contient un code action dont l'exécution peut être déclenchée si les conditions sont remplies. Il est à noter que cette action doit avoir la case Workflow cochée, et que par conséquent elle ne peut pas interagir avec l'interface utilisateur (pas de fenêtre associée). |
Déclenchement (champ DECACT) |
Ce champ, dont les valeurs sont définies par le menu local 2923, définit les conditions de déclenchement du Workflow. Les valeurs suivantes sont utilisables :
Dans le cas général, du point de vue transactionnel, il faut noter que l'action fait partie de la transaction de Workflow du message (si un Rollback est fait lors de la constitution du message, les mises à jour faites dans l'action sont affectées). Une transaction indépendante est faite pour le suivi (mais cette transaction étant réalisée ensuite, les valeurs retournées par l'action peuvent être utilisées. Dans le cas particulier du Workflow sur objet, tout est fait dans une seule transaction. Autrement dit, si la création ou la modification d'une fiche échoue, un Rollback est fait sur l'ensemble des mises à jour déclenchées par les actions. Il en est de même pour le suivi : la transaction qui suit la saisie du suivi inclut le déclenchement des actions. |
Condition d'exécution (champ CONACT) |
On saisit ici une expression logique, évaluée dans le contexte de déclenchement de l'action. Si le résultat de l'évaluation est vrai (ie. non nul), l'action est déclenchée. Si le résultat est faux, l'action n'est pas déclenchée. Si aucune expression n'est saisie, l'action est toujours déclenchée. |
Tableau Paramètres
Paramètre (champ PARAM) |
Type (champ TYPPAR) |
Retour (champ ADRVAL) |
Valeur paramètre (champ PARVAL) |
On saisit ici une expression évaluée qui est transmise comme argument à l'action, ou le code d'une variable qui contiendra une valeur de retour (si l'argument est de type Pointeur). Toutes les variables du contexte de Workflow peuvent être utilisées ici. |
Boutons spécifiques
Copie
Ce bouton permet de copier un événement Workflow vers un autre dossier, simplement en donnant son code. Dans la boîte qui s'ouvre, une case à cocher permet de réaliser le transfert vers tous les dossiers définis dans la table des dossiers courante. Bloc numéro 1
Bloc numéro 2
|