Règles Workflow

Une règle de Workflow se définit dans l'entête par un code associé à unintitulé. A ce niveau, il est possible d'activer ou non une règle deWorkflow.

Cet onglet contient les caractéristiques générales de l'événementWorkflow. Les champs à saisir sont détaillés ci-dessous.

La catégorie permet un regroupement des règles dans la liste gauche. La gestiondes catégories est faite par la table diverse numéro 51 (CatégoriesWorkflow).

L'événement déclenchant permet de préciser dans quelle fonction ledéclenchement Workflow va se faire. Cet événement se définit par un type, etun code complémentaire.

Ce type peut être :

 Objet :dans ce cas, le déclenchement se fait sur une action réalisée dans un objet standard du progiciel. Rappelons qu'un objet debase correspond à la gestion des fiches du progiciel (client, articles,factures, commandes, écritures... sont des objets).

 Entrée fonction :l'entrée dans une fonction est alors le critèredéclenchant du Workflow. Une fonction correspond à l'exécution d'uneopération quelconque du progiciel, accessible depuis les menus (l'objet XXXest un cas particulier de fonction - le nom de la fonction correspondante estGESXXX - mais on a d'autres types de fonctions, en particulier lesconsultations, les traitements, etc. ).

 Edition :il s'agit du lancement d'un état via Crystal Reports.

 Fin de tâche :le déclenchement se fait sur la fin normale d'une tâche lancée via le serveurbatch (on entend par fin normale une fin déclenchée par le déroulement de latâche elle-même, que ce soit sur une erreur ou sans erreur). Pour que cetteoption fonctionne, il faut que la tâche batch soitdéclarée avec la case Message utilisateur cochée.

 Arrêt de tâche :le déclenchement se fait sur arrêt d'une tâche batch (c'est-à-dire d'une finde tâche provoquée par une interruption soit de l'opérateur par un fichier.kil ou via le gestionnaire des requêtes, soit du serveur batch surdépassement du temps autorisé).

 Divers :il s'agit là d'événements particuliers (connexion, déconnexion...).

En fonction du type d'événement déclenchant, les informationscomplémentaires à saisir seront différentes, et le contexte accessible seradifférent. Les différents cas possibles sont décrits plus précisémentci-dessous.

Evénement de type « objet »

Lorsqu'un événement de type Objet est défini, on précise d'abord lenom de l'objet concerné. Il est possible de ne pas définir d'objet, mais dansce cas, il s'agirait d'un événement de Workflow générique sur tous les typesd'objet (il est à noter que l'on pourrait tester de façon particulière dansles expressions la valeur de la variable GABREV, qui donne le code del'objet, ou GFONCTION, qui donne le code de la fonction,  pour connaîtreplus précisément le contexte).

Ayant défini l'objet, on précise quelles actions vont effectivementdéclencher le Workflow. Celles-ci peuvent être :

 des fonctionsstandards de l'objet (correspondant aux boutons standards de bas d'écran).Les fonctions en question sont la Création, la Modification, laSuppression , l'Impression par Fichier/Imprimer, lafrappe du Bouton Fonction / Workflow, et le Changement de clépar Fichier / Changement de clé(la lettre en gras représente le codeà saisir dans la liste des opérations, le changement de code étant symbolisépar X).

 l'exécution deboutons particuliers ou de fonctions accessibles depuis la barre de menu. Cesfonctions sont représentées par des lettres particulières liées à leurdéclaration dans la fenêtre associée à l'objet. Ilest à noter qu'une fenêtre de sélection permet de visualiser et de choisirles boutons ou fonctions accessibles.

Il est à noter que l'on peut saisir plusieurs codes, aussi bien dans lesfonctions standards que dans les boutons particuliers. Ainsi, en gestion desclients, on pourrait déclencher un Workflow à la fois en création et enmodification (code CM dans la zone Opérations) et en zoom sur Parcet sur Impayés(code IM dans la zone Boutons).

La fonction Best un peu particulière, dans la mesure où ellepermet de déclencher automatiquement un Workflow prédéfini sur frappe de lacommande Fichier / Workflow. Lorsque cette fonction est déclenchée, untest est fait pour vérifier s'il existe au moins un événement Workflow actif,basé sur l'objet courant, et se déclenchant sur la fonction B. Selonle résultat de cette recherche, le comportement est le suivant :

  si aucunerègle n'existe, on saisit le texte du message et la liste des destinataireset on l'envoie sur validation de l'opérateur, en y incluant une icônepointant sur l'objet et la fiche courante.

 si uneseule règle existe, cette règle est exécutée (l'opérateur n'intervient dansce cas sur le message que si la case à cocher Message modifiable estactive)

 siplusieurs règles existent, un choix de la règle à appliquer est proposé àl'opérateur avant déclenchement du Workflow.

Dans tous les cas de Workflow sur objet, le déclenchement a lieu lorsquela fonction est réalisée (ie. en fin d'exécution du bouton, c'est-à-dire auretour d'un zoom, par exemple, ou lorsque la création d'une fiche a étéréussie). Ceci permet, le cas échéant, de tenir compte d'informations liéesau résultat d'une opération, si elles peuvent être connues dans un contextedonné.

Dans ce type d'événement, les variables en ligne utilisables pour évaluerdes conditions ou des expressions utilisables sont :

 Les variables desmasques (classes [M :XXX]) contiennent la valeur de ce qui a été saisiet qui va être validé (ainsi, en cas de modification, on y retrouve lesvaleurs modifiées).

 Les variables de latable principale liée à l'objet (classe [F:XXX]) contiennent la valeurcourante de la fiche. En cas de modification, elle contiennent la valeurantérieure (avant modification), ce qui permet de détecter les modificationsde champs.

 Les variables de latable [F:AUS] contiennent les informations liées à l'utilisateur courant (ellessont en ligne dans tous les types d'événements de Workflow). De même, uncertain nombre de variables globales, dont le nomcommence par G, sont en ligne.

L'éditeur de formule, accessible par clic droit en mode client-serveur surles formules de calcul, donne une liste des variables, tables, et écransutilisables dans le contexte.

Dans le cas de Workflow sur Fichier / Imprimer,il est à noterque :

   le Workflow ne se déclenche pas sur l'action d'impression si l'utilisateurabandonne son impression (ie. s'il ne valide pas sa saisie de paramètresd'impression).

   la variable GOLDETAT permet de connaître l'état imprimé, et la variableGIMPETAT permet de connaître la destination (pré-visualisation, imprimante,mail...) conformément aux valeurs données par le menu local numéro 95.

Evénement de type « Entréefonction »

Lorsqu'un événement de type Entrée fonctionest défini, on précisele nom de la fonction concernée. Il est possible dene pas définir de nom de fonction, mais dans ce cas, il s'agirait d'unévénement de Workflow générique sur toutes les fonctions parcourues (il est ànoter que l'on pourrait tester de façon particulière dans les expressions lavaleur de la variable GFONCTION pour savoir dans quelle fonction on setrouve).

Il est important de noter que seule l'entrée directe depuis le menu esttestée ; une entrée par le biais d'un tunnel depuis un champ situé dansl'écran associé à une autre fonction n'est pas considérée comme une entréedans une fonction.

Les seules variables en ligne à ce stade sont les variables globales etcelles de la classe [F:AUS].

Evénement de type« Edition »

Lorsqu'un événement de type Editionest défini, on précise le nomde l'état concerné. Il est possible de ne pasdéfinir de nom d'état, mais dans ce cas, il s'agirait d'un événement deWorkflow générique sur tous les états lancés (il est à noter que l'onpourrait tester de façon particulière dans les expressions la valeur de lavariable [F:ARP]RPTCOD pour savoir quel état on lance).

Les variables en ligne à ce stade sont :

 les variablesglobales et celles de la classe [F:AUS].

 les variables liéesaux paramètres de lancement. On les trouve dans l'écran des paramètresaccessible en mode client-serveur via l'assistantde formules.

Comme pour le bouton Fichier / Imprimer, la variable GOLDETATpermet de connaître l'état imprimé, et la variable GIMPETAT permet deconnaître la destination (pré-visualisation, imprimante, mail...)conformément aux valeurs données par le menulocal numéro 95. Par ailleurs, la variable GFONCTION permet de savoir lafonction ayant déclenché l'impression. Ainsi, au lieu de passer par unWorkflow sur Fonction / Imprimer, on peut aussi passer par un Workflowsur l'impression, en testant la fonction appelante.

L'utilisation des variables liées au paramètres de lancement est un peucomplexe. En effet, ces paramètres sont stockés dans les valeurs de tableau[M :RPT]VALEUR1 et [M :RPT]VALEUR2 (la deuxième valeur étantutilisées pour les valeurs début/fin), à un indice qui peut être retrouvé enrecherchant le code du paramètre dans le tableau [M :RPT]PARDES (entreles indices 0 et [M :RPT]NBPAR-1). Par exemple, en supposant qu'un paramètrenommé SITE existe dans les paramètres de l'état, on retrouverait sa valeurpar la formule suivante :

  [M :RPT]VALEUR1(find("SITE",[M :RPT]PARDES(0..[M :RPT]NBPAR-1))-1)

Si un paramètre SITEDEB existait dans les paramètres de l'état, les deuxvaleurs début fin seraient obtenues successivement par :

  [M :RPT]VALEUR1(find("SITEDEB",[M :RPT]PARDES(0..[M :RPT]NBPAR-1))-1)

  [M :RPT]VALEUR2(find("SITEDEB",[M :RPT]PARDES(0..[M :RPT]NBPAR-1))-1)

Evénement de type « Fin detâche »

Lorsqu'un événement de type Fin de tâcheest défini, on précise lenom de la tâche batch concernée. Il est possible dene pas définir de nom de tâche, mais dans ce cas, il s'agirait d'un événementde Workflow générique sur toutes les tâches lancées (il est à noter que l'onpourrait tester de façon particulière dans les expressions la valeur de lavariable [F:ABR]TACHE pour savoir quelle tâche on lance).

Les variables en ligne à ce stade sont :

 les variablesglobales et celles de la classe [F:AUS].

 lesvariables liées aux paramètres de lancement. On les trouve dans les écransassociés à la fenêtre de lancement ; ces écrans sont accessibles parl'intermédiaire de l'assistant de formules.

 lesvariables liées aux conditions de fin d'exécution de la tâche (codes d'erreuréventuels). On retrouve ces variables dans l'annexetechnique liée au serveur batch.

Evénement de type « Arrêtde tâche »

Lorsqu'un événement de type Arrêt de tâcheest défini, on précisele nom de la tâche batch concernée. Il est possiblede ne pas définir de nom de tâche, mais dans ce cas, il s'agirait d'unévénement de Workflow générique sur tous les arrêts de tâches lancées (il està noter que l'on pourrait tester de façon particulière dans les expressionsla valeur de la variable [F:ABR]TACHE pour savoir quelle tâche on arrête).

Les variables en ligne à ce stade sont :

 le nom dela tâche arrêtée ( [F:ABR]TACHE)

 les variables du contextedu serveur batch (en effet, ce type d'événement est lancé depuis le serveurde tâches batch et pas depuis l'instance exécutant la tâche).

Evénement de type« Divers »

Les événements de ce type sont d'une part des événements génériquesdu superviseur, d'autre part d'éventuels événements plus fonctionnelsdépendant des modules utilisés dans le progiciel (ces événements fonctionnelssont décrits dans une documentation annexe) :

 la Connexiond'un utilisateur (de code GUSER), ou une tentative de connexion. Ladifférence entre les deux est connue par la variable  GERR : GERR=0  signifie connexion réussie, et GERR=1,2,3 signifierespectivement code utilisateur inexistant ou inactif, code bloqué (trop detentatives de connexion infructueuses), mot de passe incorrect. Dans le cas d’uneerreur, on dispose en plus de la variable GMESSAGE, qui contient un message d’erreurexplicite (la chaîne est vide si la connexion a été réussie). On peut dans cecas connaître les paramètres de connexion du poste ayant tenté une connexionpar la fonction getenv$("ADXCLIENT"). Cette fonction renvoieune chaîne sous la forme suivante :

     (client=adresse_ip_client , port=numéro_interne,service=numéro_de_service)

 sa Déconnexion(de façon normale, par un arrêt décidé par l'utilisateur)

 sa déconnexionen Time-out (c'est le cas où l'utilisateur n'a rien tapé sur son écranpendant une durée paramétrable, définie par le paramètre utilisateur TIMEHGUP1).

 l'Arrêtdela tâche par le biais de la surveillance des connexions.

 l'entréedans la trace.

Pour les trois premiers événements, on ne dispose, à ce stade, que desvariables liées à l'utilisateur en ligne.

Pour le quatrième événement, l'utilisateur en ligne est celui qui arrêtela session, les caractéristiques de la tâche arrêtée étant définis dansl'écran associé à la fonction de surveillance (c'est l'écran PSADX). Dans cetécran, on retrouve un tableau présentant l'ensemble des processus en cours.L'indice courant de la ligne décrivant le processus arrêté est défini par[M:PSA]LIGSES-1. On retrouve dans le tableau en question l'identification duposte client, de l'utilisateur connecté, de la fonction en cours d'exécution,ainsi que les numéros de processus correspondants. Par ailleurs, le deuxièmetableau de l'écran (dimensionné par la variable NBPROC) donne les numéros deprocessus ayant été supprimés.

L'événement TRACE permet quant à lui de disposer d'un bouton Workflowactif en lecture de trace, afin de pouvoir envoyer un mail à desutilisateurs. Le fichier trace est alors automatiquement joint à l'envoi. Lemail peut être ou pas modifiable selon les informations définies dans leparamétrage du Workflow.

Enfin, il existe un événement générique nommé MSG, qui estutilisable en spécifique dans les actions déclenchées en retour de mail deWorkflow. L’utilisation de cet événement se fera par une ligne telle quecelle ci-dessous :

CallWORKFLOW("MSG",” ”,” ”) From SUBAMSC

Il faudra que le contexte déclenchant soit complété par le développeurpour qu’un événement Workflow basé sur ce type d’événement puisse êtreexécuté avec un contexte significatif.

Autres informations liées aucontexte de déclenchement

Des conditions complémentaires sont saisies sous la forme d'expressions logiques incluant des variablesen ligne au moment de l'exécution de la règle (contenus de masques d'écransou de tables en ligne...). Si ces conditions sont toutes vraies, le Workflowsera effectivement déclenché.

Un tableau nommé bas de page peut également être saisi dans cetonglet. On y décrit des variables de bas de page qui pourront intervenir dansl'évaluation des conditions et des expressions évaluées (notamment la listedes destinataires et du texte du message). Elle n'a de sens que sur lesévénements déclenchants concernant des objets du progiciel. Son utilisationsera abordée plus largement dans le paragraphe 'Utilisation des variables basde page'.

Enfin, des cases à cocher précisent ce qui se passe lorsque le Workflow sedéclenche :

 Traceactivepermet d'activer ou non l'enregistrement de la trace (log)

 Messageactif permet de déclencher l'émission du message.

 Mise aupoint provoque l'affichage d'une boîte détaillant les erreurs de calcul àl'exécution

 Messagemodifiable provoque l'ouverture d'une boîte permettant la modification dumessage, des pièces jointes, et des destinataires par l'opérateur lors dudéclenchement du Workflow.

Enfin, un radio-bouton permet d'imposer le mode d'envoi du message, quipeut être envoyé depuis le Serveur, le Client, ouindifféremment les deux (dans ce cas, le paramètre TYPMES le détermine). Implicitement,certains événements déclenchants imposent le mode d'envoi (par exemple, pourtous les événements liés à une tâche batch, événement pour lequel aucunutilisateur n'est en ligne, le seul mode d'envoi possible est Serveur).

Cet onglet permet de définir :

 lesconditions de retour vers le progiciel si des messages sont envoyés par leWorkflow. En effet, la case à cocher Icône de retourdéfinit si lemessage doit inclure une icône permettant de lancer le progiciel afin quel'utilisateur se retrouve dans les conditions de l'appel déclenchant (cecisuppose bien entendu que le destinataire du message ait accès au progiciel).Si cette case est cochée, on peut définir la fonction dans laquellel'utilisateur va se retrouver après son double clic (si cette fonction n'estpas renseignée, c'est la fonction appelante), et également l'expressionpermettant de calculer la valeur de clé courante de la fiche (si la fonctionde retour est un objet). Dans le cas où le retour se fait sur la fonctiondéclenchante, on se retrouvera par défaut sur la fiche courante au moment dudéclenchement du Workflow. La case à cocher Retour menu permet dedéfinir si l'utilisateur reviendra au menu ou fermera sa session lorsqu'ilquittera la fonction sur laquelle il s'est connecté via double-clic. Enfin,la case à cocher Accusé réception permet, si elle est cochée, dedemander un accusé de réception lorsque le mail est envoyé. Attention, cettedemande d'accusé de réception ne peut fonctionner que si le message estenvoyé depuis le poste client, et pas depuis le serveur.

 le fait quele Workflow déclenche l'exécution d'une action. Cette action sera exécutée enpremier (ce qui permet d'utiliser les informations de retour dans les mailset/ou les log de Workflow générés). Son exécution ne sera lancée que si lacondition se trouvant sur l'onglet est vérifiée. L'action doit être de type Traitement(elle ne peut pas ouvrir de fenêtre),elle doit en outre avoir la caseWorkflowcochée. La valeur des paramètres passés à l'action est donnéesous la forme d'expressions. Les valeurs de retour peuvent être utiliséesdans les expressions liées au mail ou au log de Workflow. Les variablesentières GBIDI1, GBIDI2, GBID3, décimales GBIDD1, GBIDD2, GBIDD3,alphanumériques GBIDC1, GBIDC2, GBIDC3, dates GBIDA1, GBIDA2, GBIDA3 peuventêtre utilisées pour nommer ces variables de retour.

Il est à noter que l'action Workflow peut avoir une action suite qui seraexécutée si la condition se trouvant sur l'action est réalisée.

Cette fonctionnalité, nouvelle en version 140, permet d'étendreconsidérablement le champ du Workflow en déclenchant des traitementsspécifiques. En standard, seules deux actions sont livrées : une actionACRELNK permettant de créer des liaisons (visibles par l'explorateur deliaison), et une action ASUPLNK permettant de supprimer des liaisons.L'intérêt de cette action est de permettre la création automatique deliaisons conditionnelles, ce qui n'est pas possible directement dans ladéfinition des liaisons.

Cet onglet permet de définir les conditions d'envoi du message.

Le tableau des destinataires permet de définir la liste dedestinataires du message en renseignant :

 un type dedestinataire. Les choix disponibles sont 'Utilisateur' ou 'Tiers'.

 undestinataire. Cet élément est écrite sous la forme d'expressions. On peutfaire intervenir par exemple des champs de la table des utilisateurs qui esten ligne, pour envoyer un message à l'un des supérieurs hiérarchiques del'utilisateur ayant réalisé l'opération déclenchante.

 unefonction. Ce choix n'est accessible que pour le type de destinataire 'Tiers'et définit quels sont les contacts répertoriés sur la fiche Tiers quirecevront le message. Seuls les contacts ayant la bonne fonction (définie parle menu local 233) recevront le message.

 unindicateur Copie, qui permet de préciser si chaque destinataire estdestinataire principal ou reçoit le message en copie. Au moins undestinataire doit être destinataire principal (valeur = Non dans lacolonne).

Si l’option permettant de recevoir des réponses directe au mail estactivée, des colonnes supplémentaires apparaissent  dans ce tableau :

 unindicateur Lien action(oui/non) qui sera à Oui si on désiredéclencher une action par une réponse de l’utilisateur. Dans ce cas, le lienest inséré à la suite de la ligne courante.

 un codeaction, suivi de l’expression de deux paramètres. C’est ce code action quisera déclenché en cas de clic sur le lien action. L’action définie par cecode ne doit pas ouvrir de fenêtre (elle doit définie comme étant de type Workflow).

A l'exécution, les adresses d'envoi dépendent du résultat de l'expressiondestinataires :

 si celui-cicontient le caractère '@', on considère qu'il s'agit de l'adresse e-mail eton ignore le type.

 sinon, sic'est un utilisateur, on utilise l'adresse de messagerie définie dans safiche

 sinon, sic'est un tiers, on prend toutes les adresses de messagerie des contactsassociés avec la bonne fonction.

On définit ensuite, sous forme d'expressions, le sujet, et le texte dumail lui-même, sous la forme de ligne évaluées (formules de 250 caractèresmaximum). La colonne Saut ligne se trouvant dans le tableau des textespermet de provoquer une rupture de paragraphe. Il est aussi possibled'utiliser la formule chr$(13) pour provoquer un tel saut.

Il est à noter que les messages envoyés via MAPI sont limités (parl'interface) à environ 700 caractères maximum (taille des pièces jointesexclue). L'interface messagerie sur le serveur limite à environ 65.000caractères la longueur du message (taille des pièces jointes toujoursexclue).

Cet onglet permet de définir, lorsqu'un message est envoyé, les pièces quel'on souhaite y adjoindre.

Le champ pièce à joindredoit contenir le chemin d'accès au fichierque l'on désire joindre. Si on désire, par exemple, dans le cas d'un Workflowsur facture client, joindre le texte d'en-tête de facture, il suffirait d'yinsérer la formule suivante :

En effet, les textes sont stockés dans le répertoire TXT du dossier, avecune extension .txt (ce qui est géré par la fonction filpath). Le champSIHTEX1 contient le nom du fichier d'en-tête courant. Par ailleurs, si le nomdu fichier est vide, il convient de ne rien passer du tout (d'oùl'utilisation de la fonction string$).

Lorsque l'événement est lié à une tâche batch, il est possible d'adjoindrele fichier de trace généré par la tâche au mail envoyé, en cochant la case Fichiertrace lié.

Lorsque l'événement est lié à un objet, il est possible d'adjoindre lespièces jointes liées à la fiche courante de l'objet en cochant la case Piècesjointes à la fiche. Dans ce cas, il est possible de dire si tous lestypes de pièces sont concernés, ou un seul, et si toutes les catégories sontconcernées, ou une seule. Attention, l'envoi de ce type de pièces jointesne fonctionne que si les pièces jointes sont sur le même serveur que leserveur d'application, et si l'envoi est fait par le serveur. En effet, sil'envoi est fait depuis le client, on est limité à une seule pièce jointe, etpar ailleurs cette pièce jointe doit être accessible par un chemin réseau.

Cet onglet permet de décrire les renseignements qui seront portées par le fichierde log. Ces renseignements sont au nombre de cinq maximum et sont identifiéspar : 

 une nature.Cet élément est géré par la table diverse Nature Workflow à la disposition del'utilisateur pour classer ces informations. Le code 'DES' est réservé auclassement des destinataires des messages.

 uneinformation. L'écriture est analogue à celles des conditions et s'écrit doncsous la forme d'expressions logiques incluant des variables en ligne aumoment de l'exécution.

Un exemple sur l'objet commande des achats (OBJPOH) pourrait être lecouple nature = CDE et information = [POH0]POHNUM qui permettraitd'identifier une commande passée par cet objet.

Une consultation du log avec le moniteur de Workflow permettraitalors de retrouver les enregistrements concernant la nature CDE pour unnuméro de commande particulier.

Outre les messages génériques, les messages d'erreur suivants peuvent apparaître lors de la saisie :

Expression incorrecte Erreur desyntaxe

Ce message est affiché lorsqu'on saisit une expression adonix dont lasyntaxe est invalide (par exemple, lors de la saisie des conditions ou des destinatairesdu message). Un message plus explicite peut être affiché selon le contexte(par exemple, il manque une parenthèse ouvrante).