Article parut dans le journal Programmez de Décembre 1998
WorkFlow & PeopleSoft
Vous avez tous entendu parlé de WorkFlow. Que peut bien devenir ce mot après quelques années.
Présentation d'un exemple simplifié, qui peut vous en dire plus et vous donner quelques idées.
Par Marc Perroulaz
Le WorkFlow né il y a bien longtemps peut ce traduire par :
- Une suite de procédures automatisées
- Un enchaînement de modules pre-programmés
- Partage d'informations sécurisées
- Contrôle de flux d'information
- Automatisation des liens inter-tâche
Nous n'allons pas débattre chaques définitions. N'importe quels programmes contient un ou du WorkFlow, souvent transparent pour l'utilisateur. Il est clair qu'un logiciel peut être basé sur un moteur de WorkFlow, surtout pour de la GED. Le moteur se chargera alors de déplacer l'information d'un bout à l'autre d'un processus défini avec l'utilisateur. Un moteur de Workflow devient indispensable pour des processus de production ou collaboratif.
En général le WorkFlow est utilisé pour la gestion électronique de document (GED), création de dossier, routage, validation.
Voici donc un exercice pratique avec PeopleSoft 7 comme environnement de programmation, mettant en place un WorkFlow de données, donc lié directement aux tables d'une base de données SQL.
Prenons, comme par hasard, la gestion de programmes et de ses versions. Chaque fois qu'une nouvelle version sort, nous aimerions automatiquement envoyer un mail à nos clients/utilisateurs si la version est publiable, ou dans tous les cas, placer l'information dans une liste de tâches pour ne pas oublier de la traiter, appelée "WorkList",.
Voici les étapes incontournables.
1) Création des tables (Applications et Versions)
2) Ecran de saisie ("Panel")
3) Ajout d'un Menu
4) Définition de Rôle et assignement d'utilisateurs
5) Définition du "Business Process" comprenant les activités
1) Pour définir des tables, il faut d'abord créer des champs (fig. 1). Ensuite en glisser ces champs dans les tables ("records") (fig. 2), donner les clefs et les champs de recherche (fig. 3). Une table contenant les données de l'état du futur WorkFlow doit également être présente. Pour pouvoir conditionner, l'envoi du email ou pour placer dans la WorkList, nous ajoutons un sémaphore (flag) à la table des versions, si celui-ci est Vrai, nous allons déclarer la version au Public, s'il est Faut, il faudra le traiter ultérieurement par la "WorkList".
fig. 1- Création des champs
fig. 2 Création des Tables
fig. 3 Définition d'un Champs
2) La construction de l'écran (fig. 4) est faite en plaçant (toujours du Drag&drop) chaque champ des tables dans un Panel. Les requêtes (code SQL) appropriées seront générées dynamiquement à l'exécution.
fig. 4 - Création de l'Ecran
3) En définissant des groupes d'écrans de saisie, on pourrai donc avoir plusieurs "Panel" accessibles par des onglets. Ici, nous n'en avons qu'un seul. Celui-ci est placé dans notre menu (fig. 5).
fig. 5 - Création du Menu
- La saisie des Applications et de ces versions est d'ors et déjà possible, après avoir donné accès au Menu aux utilisateurs. Mais, comme promis, nous vous montrons un exemple de WorkFlow, pas uniquement la création de deux tables, d'un écran et d'un menu fait en dix minutes, sans une ligne de code. :-)
4) Un "Rôle" est défini pour généraliser la/les tâche(s) d'une ou plusieurs personnes. Nous pourrions définir plusieurs "Rôle", un qui indique qu'une version est disponible et un autre qui ce chargerai d'envoyer les email. Le rôle de l'utilisateur consiste à définir quels seront les rôles que l'utilisateur va avoir accès (va pouvoir bien faire). Un "Rôle" pourrait rechercher ces ouailles par un Query. Dans notre exemple (fig. 6), nous indiquons "User List", ce qui veut dire que nous définissons les rôles de chaques utilisateurs par les "Role User" (fig. 7).
fig. 6 - Création d'un "Role"
Nous ajoutons donc un "Role User" (fig n) et indiquons dans "Currently In Roles" quels sont les "Roles" que l'utilisateur va avoir. Dans notre exemple, nous mettons "Application Administrator" (que nous venons de créer) et "Worklist Administrator" qui le "Role" qui permet entre autre de re-router (changer) une tâche à accomplir à une autre personne.
fig. 7 - Création d'un "Role User"
5) Un Business Process n'est rien d'autres qu'un enchaînement de "Panel" conditionné et d’objets divers. Si l'opérateur désire router directement cette version à la liste de distribution, il devra cocher le champs "Declare". S'il n'est pas coché, le système placera automatiquement l'information dans la "WorkList". Au moment où l'utilisateur demandera sa liste des tâches (fig. n), suivant son "role user", toutes les tâches en attente lui seront proposées. Au moment où l'utilisateur procède à une tâche, il va ce retrouver dans l'écran de saisie associé à l'activité. Le code est exécuté au moment où l'écran est sauvé, on déclenchera le bon événement du 'Process' suivant un flag (fig.n).
Voici quelques écrans important de la paramétrisation du WorkFlow.
fig 8 - Création de la première activité
fig. 9 - Définition d’une l'étape dans le tout le Processus
fig. 10 - Définition des attributs de l'étape
fig. 11 – Définition d’un événement
fig. 12 – Définition de la "WorkList"
fig. 13 – Définition d’attributs
fig. 14 – Indication du destinataire pour le traitement de la tâche
fig. 15 – Définition de l’objet email
fig. 15 – Définition des flag de l’objet email
fig. 16 – Définition des champs du message
fig. 17 – Lien entre les champs du message et les champs de l’écran
fig. 18 –Vue du « Business Process » terminé
Du code est nécessaire pour déclencher l'événement approprié. Dans PeopleSoft chaque champ reçoit une série d'événements pouvant exécuter du code. L'événement Workflow peut déclencher un "Business Event" (fig. 11), en général placé dans le premier champ-clef de l'enregistrement (fig. 19).
fig. 19 –Code de déclenchement
L'exécution sans commentaires:
fig. 20 – Création de l’application et de versions
Si l'utilisateur ne désire pas encore envoyer, par la messagerie, l’annonce de la mise à jour. L "Application Manager" ce verra attribué une nouvelle tâche.
fig. 21 – Vue de la « WorkList »
Le texte du message si la « boite à cocher » ‘Declare’ est flagé, le message (fig. 22) est envoyé.
fig. 22 – Message d’annonce
Il est clair qu'on peut faire beaucoup plus compliqué; avec des validations multiples "virtual approver", des agents qui pourraient contrôler que les applications ont bien été traitées après un laps de temps,...
Un programme prévu pour faire du WorkFlow vous offre aussi des possibilités d'Administration comme: avoir la liste des tâches non traitées, changer le statut d'une tâche...
En conclusion, faire du WorkFlow où l'utilisateur est impliqué directement n'est pas simple. Il doit être souple et efficace tout en donnant du goût. L'initiative d'en faire, devrait toujours venir de l'utilisateur lui-même; il est impératif de bien comprendre le business avant d'en faire.
Lien utile: