Notifications

• Code workflow (champ CODE)

Ce champ identifie la règle de Workflow.

• Intitulé (champ INTIT)

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

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

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

• 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

• Création (champ ACREA)

Ce champ permet de délencher le workflow dans le cas de la création d'une fiche si le type d'évènement est "Objet".

• Modification (champ AMODI)

Ce champ permet de délencher le workflow dans le cas de la modification d'une fiche si le type d'évènement est "Objet".

• Suppression (champ ASUPP)

Ce champ permet de délencher le workflow dans le cas de la suppression d'une fiche si le type d'évènement est "Objet".

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

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

• champ FLD1

Indiquez un champ de la table.

• champ OPE1

Indiquez l'opération de comparaison :

• l'opérateur 'indifférent' est utilisé pour obtenir toutes les fiches d'un objet,
• l'opérateur '* ?' est utilisé pour définir les jokers.

• champ VALEUR1

Ce champ permet d'indiquer la valeur de comparaison (sans les guillemets pour les champs alphabétiques).

• champ ANDOR2

Indiquez le lien entre les lignes de critères.
Exemple :
Pour 'Expr1 et Expr2 ou Expr3', on obtient '(Expr1 & (Expr2 | (Expr3)))'.

• champ FLD2

• champ OPE2

• champ VALEUR2

• champ ANDOR3

• champ FLD3

• champ OPE3

• champ VALEUR3

• champ ANDOR4

• champ FLD4

• champ OPE4

• champ VALEUR4

• champ ANDOR5

• champ FLD5

• champ OPE5

• champ VALEUR5

• Expression (champ EXP1)

Indiquez une expression pour éventuellement complèter la recherche.
Ce critère est rajouté aux critères précédents par le lien ET.
L'expression ne peut pas contenir des champs d'une table autre que la table principale de l'objet. Ceux-ci peuvent être indicés.

• Type (champ TYPDES1)

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

• champ DESTIN1

Ce champ identifie les destinataires. Son écriture se fait sous la forme d'expressions logiques (Formule de calcul) incluant des variables en ligne au moment de l'exécution.

Dans l'application Sage X3 People, l'utilisation du type "Circuit de signatures" nécessite de préciser le point de départ du circuit de signatures.
Ainsi, si l'utilisateur souhaite démarrer le circuit au niveau de la structure "Contrat", l'expression logique débutera par les caractères "CTR" suivis du numéro de contrat : "CTR~"+[F:CTR]CTRNUM.
De la même façon, si l'utilisateur souhaite démarrer le circuit au niveau de la structure "Salarié", l'expression logique débutera par les caractères "MAT" suivis du numéro de matricule : "MAT~"+[F:DPI]REFNUM.

• champ FNCDES1

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 ENVOI1)

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.

• Alerte (champ SUIVI1)

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.

• Type (champ TYPDES2)

• champ DESTIN2

• champ FNCDES2

• Envoi mail (champ ENVOI2)

• Alerte (champ SUIVI2)

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