Contexte et mode de fonctionnement
Cette règle de workflow est de type manuel (le workflow est lancé soit en direct, soit en batch).
Elle déclenche :
un message.
une action.
La règle d'affectation UPDPAR (Maj paramètres) est utilisée par la règle de workflow UPDPAR.
Cette règle parcourt la table d’audit et renvoie un message à un utilisateur défini par défaut par chapitre de paramètres (table diverse 911). On regroupe alors les modifications de paramètre par chapitre.
Le paramétrage est basé sur les éléments suivants :
- Un modèle de données nommé UPDPAR dont la table principale est la table AUDITL (lignes d’audit). On réalise une jointure de type (1,1) vers la table d’en-tête, et un lien de type (1,1) vers la table des paramètres. Comme la clé de la table ADOVAL sur laquelle est basée l’audit est le triplet (code paramètre, code société, code site), on retrouve le code paramètre dans le premier champ (ID1) de la table AUDITH, et les deux champs suivants, concaténés et séparés par le caractère ~, dans le champ ID2. Le champ ID2 aura toujours l’une des trois formes " ~SITE", "SOCIETE~ " ou "*~LEGISLATION" (ce champ est utilisé dans le texte ligne associé au message).
- Une règle d’affectation nommée UPDPAR, basée sur le champ chapitre, permet de définir, par chapitre de paramètre, un destinataire de message. Un Workflow Manuel est toujours considéré comme un Workflow Ligne, même s’il n’y a pas plusieurs niveaux de table dans le modèle de données. On définit dans le champ Regroupement le ou les champs sur lesquels doivent se faire la rupture (champs séparés par un point-virgule). Ici, on regroupe par le champ [ADP]CHAPITRE, ce qui correspond exactement au champ sur lequel on définit le routage à l’utilisateur.
Les conditions d’envoi sont les suivantes :
- Le champ STA de la table AUDITH vaut 2 (case Workflowcochée).
- La table concernée (champ TBL dans la table AUDITH) est la table ADOVAL, qui stocke les valeurs de variable.
- La variable en question est modifiable (le champ MODIF dans ADOPAR doit être égal à 2). Ce test permet de ne pas voir apparaître les changements de valeur d’un paramètre nommé MONO, qui est modifié pour des raisons techniques de façon transparente pendant la transaction de modification de paramètres.
- Le champ [L]USER, qui correspond au code utilisateur renvoyé par la règle, est non vide. Ainsi, si on ne veut pas tracer les modifications de paramètres d’un chapitre, il suffit de ne pas le lister dans la table d’affectation. Il est à noter que cette condition est de type En-tête, et pas de type Ligne. La raison en est simple : les conditions de ligne sont utilisées pour filtrer les ligne directement dans la base, elles ne peuvent donc pas utiliser un champ qui est n’est évalué que lorsqu’un premier regroupement de lignes est fait (précisément au niveau En-tête).
Le destinataire est défini par la variable [L]USER précédemment évoquée.
Le message comprend une partie objet et en-tête :
- La ligne de détail (insérée dans le texte par le biais de la formule |LIG|) formate dans l’ordre le code utilisateur et l’opération, la date et l’heure, les valeurs avant et après du paramètre. Pour ce faire, on utilise des fonctions de formatage définies dans la librairie AFNC, et on concatène l’ensemble des lignes obtenues avec un espace séparateur. Les fonctions utilisées sont les suivantes : La fonction F2C formate deux champs avec le format donné en tête. Elle est utilisée deux fois : la première fois, pour formater sur 5 caractères, avec le format "5X", les champs ADOUSR et une expression calculée à partir de la fonction OPR définie ci-dessous. La deuxième fois, on formate sur 10 caractères, avec le format "10X", le code du paramètre trouvé dans la table ADOPAR et le code site ou société, obtenu en supprimant les caractère "~" et "*" (fonction ctrans, pour remplacer par des espaces, puis fonction vireblc, pour supprimer lesdits espaces). La fonction OPR permet de transformer le code opération (INSERT,UPDATE, DELETE) en un intitulé plus parlant dans la langue de connexion de l’utilisateur. L’argument utilisé est bien entendu le champ EVT présent dans la table d’audit. La fonction FDH formate une date et une heure (les paramètres étant les champs correspondants dans la table d’audit). La fonction F2P formate deux valeurs de paramètres dont on donne le type et le numéro de menu local si nécessaire.
Enfin, l’onglet Suivi met à jour l’indicateur STA (dans la table d’audit, d’abréviation AUD)avec la valeur "3" (qui correspond au statut Traité et évitera de traiter à nouveau cette modification lors de la prochaine exécution de l’événement Workflow). On utilise pour ce faire l’action standard AWRKUPDFLG, dont les arguments sont précisément l’abréviation de la table, le nom de un à 4 champs, et les valeurs associées. Cette action est ici appelée sur chaque ligne de la table d’origine.
Critères de déclenchement
Les critères complémentaires de déclenchement sont les suivants :
- Le champ STA de la table AUDITH est cochée.
- La table concernée (champ TBL dans la table AUDITH) est la table ADOVAL, qui stocke les valeurs de variable.
- La variable en question est modifiable (le champ MODIF dans ADOPAR doit être égal à 2). Ce test permet de ne pas voir apparaître les changements de valeur d’un paramètre nommé MONO, qui est modifié pour des raisons techniques de façon transparente pendant la transaction de modification de paramètres.
- Le champ [L]USER, qui correspond au code utilisateur renvoyé par la règle, est non vide. Ainsi, si on ne veut pas tracer les modifications de paramètres d’un chapitre, il suffit de ne pas le lister dans la table d’affectation. Il est à noter que cette condition est de type En-tête, et pas de type Ligne. La raison en est simple : les conditions de ligne sont utilisées pour filtrer les lignes directement dans la base, elles ne peuvent donc pas utiliser un champ qui est n’est évalué que lorsqu’un premier regroupement de lignes est fait (précisément au niveau En-tête).
Destinataires
Le choix des destinataires est défini de la façon suivante :
- Le destinataire est défini par la variable [L]USER précédemment évoquée.
Le message comprend une partie objet et en-tête qui sont simples. La ligne de détail (insérée dans le texte par le biais de la formule TAB) formate dans l’ordre le code utilisateur et l’opération, la date et l’heure, les valeurs avant et après du paramètre. Pour ce faire, on utilise des fonctions de formatage définies dans la librairie AFNC, et on concatène l’ensemble des lignes obtenues avec un espace séparateur. Les fonctions utilisées sont les suivantes :
- La fonction F2C formate deux champs avec le format donné en tête. Elle est utilisée deux fois : la première fois, pour formater sur 5 caractères, avec le format "5X", les champs ADOUSR et une expression calculée à partir de la fonction OPR définie ci-dessous. La deuxième fois, on formate sur 10 caractères, avec le format "10X", le code du paramètre trouvé dans la table ADOPAR et le code site ou société, obtenu en supprimant le caractère "~" (fonction ctrans, pour remplacer par des espaces, puis fonction vireblc, pour supprimer lesdits espaces).
- La fonction OPR permet de transformer le code opération (INSERT,UPDATE, DELETE) en un intitulé plus parlant dans la langue de connexion de l’utilisateur. L’argument utilisé est bien entendu le champ EVT présent dans la table d’audit.
- La fonction FDH formate une date et une heure (les paramètres étant les champs correspondants dans la table d’audit).
- La fonction F2P formate deux valeurs de paramètres dont on donne le type et le numéro de menu local si nécessaire.
Actions déclenchées par l'événement
L'événement Workflow déclenche l'action suivante :
Code action | Déclenchement |
---|
AWRKUPDFLD : Mise à jour champs | Ligne |
Cette action met à jour l’indicateur STA (dans la table d’audit, d’abréviation AUD)avec la valeur "3" (qui correspond au statut Traité et évitera de traiter à nouveau cette modification lors de la prochaine exécution de l’événement Workflow).Elle est appelée sur chaque ligne de la table d’origine.
Tables mises en oeuvre
Les tables suivantes sont concernées par la règle UPDPAR :