Règles Workflow

• Code (champ CODE)

Ce champ identifie la règle de Workflow.

• Intitulé (champ INTIT)

Permet de définir un intitulé associé à chaque fiche.

• 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.

• Type événement (champ TYPEVT)

Le type d'événement Workflow peut prendre les valeurs suivantes :

• Objet : on est dans une fonction de type objet (gestion d'une fiche en création, modification, duplication, suppression...). Le code événement correspond alors au code de l'objet.
• Entrée fonction : on déclenche la règle à l'entrée dans une fonction du progiciel. Le code événement correspond au code de la fonction (un objet codé XXX correspond à la fonction GESXXX, ce type d'événement peut donc aussi être utilisé pour les objets).
• Edition : on lance un état, dont le code peut être spécifié dans le champ code événement.
• Fin de tâche: on déclenche un Workflow en fin de tâche batch, dont le code correspond au code événement (il faut que la tâche batch en question ait la case Message utisateur cochée, sinon cela ne fonctionnera pas : un message d'avertissement signale si ce n'est pas le cas, sans pour autant empêcher la saisie).
• Arrêt de tâche : cette règle de Workflow est déclenchée lorsqu'un utilisateur décide, depuis la surveillance des tâches, d'arrêter une tâche batch, dont le code correspond au code événement. Il envoie alors une demande d'arrêt au serveur batch, et c'est le serveur qui arrête la tâche. Compte tenu du contexte d'exécution de cet événement, on est limité dans les possibilités de déclenchement. Ainsi :
• on ne dispose pas des variables d'environnement habituelles (GUSER, par exemple), mais uniquement de l'enregistrement courant dans la table ABATRQT d'abréviation [ABR].
• on ne peut envoyer qu'un message via messagerie (aucune table de suivi ne peut être mises à jour).
• Import/Export : ce type d'événement se déclenche en début (et/ou en fin) d'import (et/ou d'export), le code événement permettant de préciser le modèle utilisé.
• Signature : cette règle est déclenchée lors de la signature d'une règle antérieure, dont le code peut être donné par le code événement.
• Manuel : cette règle est déclenchée sur le parcours d'un ensemble de tables décrites dans le modèle de données. Ce parcours est déclenché par une opération manuelle, qui peut bien entendue être lancée en batch. Ceci permet notamment de déclencher les règles Workflow liées à des modifications de champs dans la base (la règle parcourt les tables d'audit).
• Divers : cette règle est déclenchée sur des événements particuliers identifiés par une liste finie de code événements. Ces événements peuvent soit être génériques pour tous les progiciels écrits en technologie adonix (par exemple connexion, déconnexion...),  soit dépendre d'une fonction propre au progiciel utilisé. On trouvera la liste des événements génériques dans une première annexe de documentation, et la liste des événements propres à chaque progiciel dans une seconde annexe de documentation.

• 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 :

• pour un type Objet, on donne le code de l'objet qui correspond.
• pour un type Entrée fonction, on donne le code de la fonction.
• pour un type Edition, on donne le code de l'état.
• pour un type Fin de tâche ou Arrêt de tâche,  on donne le code de la tâche batch.
• pour un type Import/Export, on donne le modèle d'import/export utilisé.
• pour un type Signature, on donne le code de la règle à l'origine de la demande de signature.
• Pour un type Manuel, le code n'est pas saisi.
• Pour un type Divers, on donne le code identifiant l'événement divers à l'origine du déclenchement de la règle.

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 :

• Pour un type Objet, on saisit une série de codes permettant de définir les opérations standard ( M comme modification, C comme création...) et particulières à un objet s'il est spécifié (boutons et items de menus) qui provoqueront le déclenchement de l'événement. Au moins un code opération est alors obligatoire.
• Pour un type Edition, on saisit C (ou rien) pour impression ou P pour envoyer l'état en pièce jointe.
• Pour un type Signature, on saisit le code opération attaché à la réponse faite dans le processus de signature.
• Pour un type Import/Export, on précise par une liste de 4 codes maximum si le déclenchement de la règle doit être fait en début et/ou en fin, et s'il concerne les opérations d'import/et ou d'export.
• Pour tous les autres types, cette zone n'est pas saisie.

• 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).

• 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 :

• lorsqu'une règle d'affectation est définie dans une règle de Workflow, l'ensemble des destinataires est évalué en fonction des critères définis et stocké dans le tableau [L]USER.
• lorsqu'aucune règle d'affectation n'est définie, mais que la règle de Workflow est de type Signature, on hérite des valeurs de [L]USER calculées dans l'événement à l'origine de la signature (ces valeurs sont stockées dans l'historique). Si on désire que la règle d'affectation d'origine soit ré-évaluée (parce que des valeurs de critère ont pu changer), il faut renseigner à nouveau cette règle d'affectation dans la règle de Workflow.

• 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 ni aucun modèle de données ne sont définis. Le type vaut Ligne si le Worfklow est manuel, sinon il est de type En-tête.
• Si une règle d'affectation utilisant une table ligneest définie, le Workflow est de type Ligne.

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 :

• Quand un événement de Workflow utilise un modèle de données faisant apparaître des liens (1,N), et que le Workflow est de type ligne (il parcourt l'intégralité de ligne de la table ligne choisie), on peut regrouper les lignes entre elles.
• Quand un événement de Workflow est de type Manuel (l'ensemble des lignes lues peut être regroupé de la même façon).

• 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.

• 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 :

• lorsqu'une règle d'affectation est définie dans une règle de Workflow, l'ensemble des destinataires est évalué en fonction des critères définis et stocké dans le tableau [L]USER.
• lorsqu'aucune règle d'affectation n'est définie, mais que la règle de Workflow est de type Signature, on hérite des valeurs de [L]USER calculées dans l'événement à l'origine de la signature (ces valeurs sont stockées dans l'historique). Si on désire que la règle d'affectation d'origine soit ré-évaluée (parce que des valeurs de critère ont pu changer), il faut renseigner à nouveau cette règle d'affectation dans la règle de Workflow.

• 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.

• 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é à :

• un code utilisateur (on recherche alors ses coordonnées dans la fiche utilisateur),
• un tiers (on saisit sa fonction dans le tableau pour identifier, sur la fiche tiers, quels sont les destinataires concernés).

Dans l'application Sage X3 People, le destinataire peut être lié à :

• un tiers,
• un utilisateur,
• un salarié,
• un chef,
• un circuit hierarchique.

Dans l'application Sage Géode, le destinataire peut-être lié à :

• un utilisateur,
• un site,
• un déposant,
• un transporteur,
• un fournisseur,
• un client société.

• 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  :

• Non: aucun message ne leur sera envoyé.
• Oui: un message leur est envoyé en tant que destinataires principaux.
• Copie : un message leur est envoyé en copie.

• 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 :

• Non: dans ce cas, aucune notification ne sera disponible dans le plan de travail.
• Oui : une notification leur sera envoyée, elle pourra être simplement visée, pour signaler que l'utilisateur l'a lue.
• Avec signature : cette notification devra être signée par un des destinataires de la ligne.

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 :

• S'il vaut Non, seul le destinataire indiqué d'origine est concerné.
• S'il vaut Tous, le destinataire  d'origine et tous les utilisateurs définis comme délégués direct du destinataire sont concernés. Le destinataire direct et ses délégués directs peuvent signer.
• s'il vaut Cascade, le destinataire d'origine, ses délégués, les délégués de ses délégués, etc... sont concernés. Le destinataire, ses délégués directs, et les délégués de ses délégués peuvent signer.
• S'il vaut Premier libre, le premier destinataire qui n'a pas de délégué est concerné. Le destinataire direct ne peut plus signer dans ce cas s'il y a au moins un délégué.

• Objet (champ OBJET)

Ce champ permet de de définir le contenu du champ Objetdu message envoyé, sous la forme d'une expression calculée qui sera évaluée au moment du déclenchement de l'événement.

• 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.
"CLB/variable clob ou expression" permet d'insérer le contenu d'un champ clob dans le texte. Ce nombre de balises est limité à 5.
"SIG/code réponse/expression texte" permet d'afficher un lien http dans le texte. Le clic sur ce lien déclenche la réponse de la règle workflow. Ce paramètrage ne peut être opérationnel que si les paramètres généraux superviseur du groupe "WRK" sont correctement renseignés.

• 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.

• 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).

• Retour menu (champ BAKMEN)

Cette case définit si le retour de Workflow est limité à la fonction définie (lorsqu'on la quitte, la fenêtre se ferme) ou si on revient au menu en sortant de la fonction appelée.

• Clé de lien (champ BAKLNK)

Ce champ permet, si la case à cocher Icône de retourest 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).

• 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 :

•  l'émetteur
• le type de serveur
• le contexte de retour
• l'objet du message
• l'accusé de réception
• les destinataires
• le flag signataire

• 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.

• 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 typesn'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 :

• pour un workflow de type objet
• pour lequel la case Pièce jointe est cochée (envoi des pièces jointes à la fiche comme documents liés au message).

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)

• 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 (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.

• Contexte (champ VARCTX)

Ce tableau contient des expressions évaluées au moment du déclenchement d'un Workflow. Ces variables sont :

• stockées dans l'historique de Workflow (variables VALCTX1 à VALCTX15).
• utilisables dans le contexte de signature (tableau de variables CTX(1) à CTX(15)) associé à l'événement originel, ou à un événement de Workflow consécutif à la signature.

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 :

• des variables globales (les variables GUSER, GFONCTION, GABREV, CLEOBJ, par exemple, qui définissent respectivement l'utilisateur courant, la fonction courante, le code de l'objet, et la clé courante au moment du déclenchement d'un Workflow objet).
• des variables liées aux écrans en ligne
• des expressions telles que date$, time$... qui qualifient le contexte du déclenchement

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.

• 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.
Si elle est renseignée, un motif de réponse sera demandé à la signature de l'évènement.

• 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 :

• soit pour mettre à jour le champ défini dans la colonne précédente avec cette valeur.
• soit lors du déclenchement d'éventuelles actions définies dans l'onglet suivant. Dans ce cas, on retrouve la valeur correspondante dans la variable alphanumérique [L]RESULT.

• 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.

• 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 :

• Début Workflow : l'action est déclenchée en début de constitution du texte du message. Lorsque le Workflow est de type Ligne, elle n'est exécutée qu'une fois par en-tête, avant la constitution du texte d'en-tête. Les variables retournées par l'action peuvent être utilisées dans le texte du mail (mais plus pour définir les destinataires ou les conditions de l'envoi, qui sont déjà évalués à ce stade).
• Fin Workflow : l'action est déclenchée après l'envoi du message. Lorsque le Workflow est de type Iligne, cette action n'est exécutée qu'une fois par groupe de lignes.
• Avant Ligne : l'action est déclenchée avant la lecture de la première ligne, lorsqu'on a un Workflow de type en-tête et lignes. Ceci permet par exemple d'initialiser des variables de cumul pour obtenir un total des lignes, le cumul étant réalisé dans une action Ligne.
• Ligne : l'action est déclenchée juste avant la constitution de chaque ligne de message, dans le cas d'un Workflow de type ligne. Les variables retournées par l'action peuvent donc être utilisées dans le texte ligne.
• Signature : l'action est déclenchée après la saisie de la signature (la variable [L]RESULT issue de cette saisie est donc connue), mais avant la mise à jour (on peut modifier cette valeur durant l'action). Dans le cas d'une signature, toutes les mises à jour sont réalisées dans une seule transaction. Ainsi, si un Rollback est réalisé dans une des actions déclenchées par l'événement, on revient à la situation de départ pour toutes les mises à jour faites.

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 Rollbackest 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.

• 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.