Les bases du développement Notes/Domino

Transcription

1 Les bases du développement Notes/Domino Tsoft et Groupe Eyrolles, 2004, ISBN : X

2 Archivage Champs Auteurs Champs Lecteurs Section d accès contrôlé Sous-masque Formule de masque Notification Routeur de messagerie Module 11 : Mettre en œuvre un workflow Objectifs Ce module a pour objectif d apprendre à traduire les diagrammes UML en programmes écrits en langage de formules pour un workflow Lotus Domino. Les ateliers contiennent des conseils et des techniques non décrites dans le cours. Savoir-faire Utiliser le routeur pour faire circuler les documents Utiliser les rôles et les champs Lecteurs et Auteurs pour contrôler la visibilité et la modification des documents Gérer les accès à l intérieur d un document par section d accès contrôlé Contrôler l état d un document dans le workflow Utiliser des documents profils Connaissance La typologie de workflow et Domino.workflow Progression La typologie de workflow Domino Workflow Application de suivi de tâches Le routeur de messagerie Envoyer une notification à un utilisateur Envoyer un document Atelier 11-1 Utiliser les rôles Atelier 11-2 Modifier un document sous condition Déterminer la visibilité d un document Atelier 11-3 Créer une section d accès contrôlé Contrôler l état d un document Atelier 11-4, 11-5 Contrôler l accès à une vue Contrôler le masque utilisé dans une vue Atelier 11-6, 11-7 Archivage de documents Atelier 11-8 Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-1

3 La typologie de workflow Typologie de workflow Workflow administratif Formulaires : demandes de congés, d achats de fournitures... Workflow ad hoc Orienté projet, procédures souples Conçu sous forme de bases partagées de suivi Workflow de production Processus complexes faisant l objet de procédures formelles Impliquent plusieurs services Circuits modélisés pouvant être modifiés en cours Associés à des captures d images, de documents par scanners Une application workflow automatise une séquence d actions, d activités ou de tâches dans un processus donné : une demande d achats, le règlement d un litige, une mise au contentieux, le règlement d un sinistre Le workflow comprend également les outils nécessaires pour connaître l état de chaque instance du processus ainsi que pour gérer le déroulement du processus. Le champ du workflow est donc vaste et les problématiques sont de complexité variable. La classification donnée ici est tirée de l ouvrage Introduction to Groupware, Workflow and Workgroup Computing de Setrag Khoshafian et Marek Buckiewicz (John Wiley & Sons, Inc.). Workflow administratif, Workflow ad hoc, Workflow de production. Lotus propose une classification assez proche qui est commentée ensuite. Workflow administratif Ces applications sont basées sur les capacités des logiciels de messagerie à intégrer des formulaires répondant à quantité de besoins simples, courants et répétitifs : demande de congés, demande d achat de fournitures Les fonctions supportées par un workflow administratif se caractérisent par des formulaires, leur routage, des itérations limitées, une gestion réduite des alarmes et des notifications Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

4 Workflow ad hoc Le workflow ad hoc supporte habituellement des processus à l intérieur d un projet : le circuit est plus complexe que celui suivi par un formulaire dans un workflow administratif : un processus peut s appuyer sur plusieurs documents circulant entre de nombreux acteurs. Un document peut itérer entre un ou des acteurs avant de poursuivre le processus (négociations, validation, vérification). Des alarmes et des notifications par courrier électronique identifient pannes et retards. Les utilisateurs disposent d une marge d autogestion pour résoudre les cas peu courants. Workflow de production Les workflows de production supportent des processus complexes et critiques pour le bon fonctionnement de l entreprise. Un grand nombre d acteurs interviennent dans la chaîne. Le système ne pouvant être complètement prédictible, il faut pouvoir modifier dynamiquement le modèle et les règles qui pilotent un processus afin de réagir à un événement imprévu ou peu fréquent. Ces applications s accompagnent de capture d informations (courrier entrant scanné par exemple) ce qui génère un volume très important d informations de valeur. L application de prêt précédente peut faire l objet d un workflow de production en détaillant et en formalisant davantage les étapes du processus. Classification proposée par Lotus Lotus propose une classification prenant en compte la technologie utilisée : Base de documents partagée : flexibilité, Processus décrits précisément : structuration forte. Ceci amène trois classes de workflow : Collaboratif : rassemble le workflow administratif, le workflow ad hoc et les techniques de travail en groupe, Structuré : il est proche du workflow de production. Un workflow standard décrit de façon précise les processus standardisés et récurrents. L utilisateur intervient pour gérer les exceptions par déviation du processus standard, Semi-structuré : comme son nom l indique, il est à mi-chemin entre le collaboratif et le structuré. La complexité est gérée par un découpage en activités chaînées (impliquant un nombre prédéfini d acteurs) et des techniques de travail de groupe. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-3

5 Domino Workflow Domino Workflow Conception par interface graphique Développement Maintenance Séparation des composants Logique : la programmation Les objets : données Visualisation de l état d un processus Interface graphique Prise en compte de workflows complexes Domino Workflow est une application Lotus Notes qui supporte le développement de workflows ad hoc et de production : analyse et conception de l application, exécution, visualisation d un processus en cours. Domino Workflow architect Le concepteur d application modélise les processus depuis une interface graphique. Les modifications de processus se font également depuis cette interface. Les éléments de conception sont enregistrés dans une base Design Repository. Domino Workflow engine Ce composant exécute l application. Les composants sont nettement séparés : Process Definition décrivant les processus, Organization Database décrivant l organisation de l entreprise, Application Database qui contient notamment les documents circulant manipulés dans les processus. Dans Application Database, les règles du workflow exprimées dans les deux autres bases Process Definition et Organization sont matérialisées et s appliquent sur les objets du workflow. Domino Workflow viewer Ce composant permet de visualiser graphiquement un processus en cours pour connaître son état d avancement. Documentation Le RedBook using Domino Workflow SG présente en détail l architecture de Domino Workflow. D autres documents et une version d évaluation sont disponibles sur Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

6 Application de suivi de tâches Application de suivi de tâches Champ : suivi des tâches distribuées pendant les réunions L application de suivi de réalisation de tâches qu il s agit de réaliser a été présentée dans module Méthodologie élémentaire. C est un workflow très simple qui parcourt les techniques de programmation utilisées dans ce type d application en les reliant à une méthode générale d analyse fondée sur UML. Les grandes lignes sont rappelées brièvement ici. Domaine et objectifs Cette application est une extension de l application de suivi de réunion et se trouve dans le même domaine : elle intéresse toutes les personnes participant à des projets de développement d applications. L objectif est d améliorer la distribution, le suivi et la publication des travaux nécessaires à l avancement du projet : il s agit essentiellement de production de documents de type présentations, rassemblement d informations nécessaires à l avancement du projet. Les acteurs Projet Acteur Exécutant Organisateur Suivi de réunion Description Un exécutant la personne affectée est responsable de l achèvement de la tâche qui lui a été attribuée et en rend compte au responsable de la réunion. Le compte rendu de réunion comporte une liste de tâches à effectuer. L organisateur affecte une tâche à un exécutant. Il valide également le résultat du travail et décide de diffuser ou non le document créé. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-5

7 Diagramme de cas d utilisation Projet Suivi de tâches Cas utilisation Description Attribuer une tâche Exécuter la tâche Contrôler le travail L objectif est de définir une tâche et de l attribuer à un exécutant. L objectif est de communiquer le document qui concrétise la réalisation de la tâche. L objectif est de valider le document produit et d en décider ou non la publication Diagramme de classes Deux types de documents sont représentés comme autant de classes : Compte rendu, Tâche. Les opérations applicables aux tâches méthodes dans la terminologie OO sont symbolisées dans la partie inférieure du cadre représentant la classe Tâche. Ce sont Notifier(), Terminer(), Corriger(), Publier() et Abandonner() Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

8 Projet Classe Opération Notifier() Terminer() Corriger() Approuver() Abandonner() Suivi de tâches Tâche Description Actionnée par l organisateur, si la notification n a pas déjà été envoyée. La tâche passe de l état En attente à En cours. L exécutant affecté à une tâche reçoit un message dans sa base Courrier avec un lien sur la tâche à effectuer. Actionnée par l exécutant sur une tâche qui lui est affectée et qui est En cours.. La tâche est à l état En cours et passe à l état Effectuée. Actionnée par l organisateur, sur une tâche Effectuée. La tâche passe de l état Effectuée à En cours. Actionnée par l organisateur, sur une tâche Effectuée. La tâche passe de l état Effectuée à Publiée. Le document produit est visible de tous. Actionnée par l organisateur, sur une tâche Effectuée. La tâche passe de l état Effectuée à Abandonnée. Diagramme d états-transitions Ce diagramme décrit les états successifs d une tâche. L attribut Statut de la classe Tâche prend les valeurs En attente, En cours, Effectuée, Publiée et Abandonnée. L état initial est symbolisé ci-dessous par un cercle plein au départ et l état final par deux cercles concentriques. Chaque rectangle symbolise un état et le texte sur la transition indique l acteur ou l événement à l origine de la transition et l action effectuée. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-7

9 Le routeur de messagerie Le routeur de messagerie Messager Routeur MAIL.BOX mail\aplanchou.nsf Notifier un acteur lorsqu un travail est en retard, publier un document dans une base s appuient communément sur le mécanisme de routage de courrier de Notes. Ce paragraphe décrit le mécanisme de fonctionnement du routeur sur le serveur. Dépôt d un message Un message (un document) est déposé depuis le client Notes dans la boîte aux lettres du serveur MAIL.BOX par la composante Messager du client. Ce message est un document Notes qui contient au minimum le nom du destinataire : une personne, une base Courrier en arrivée module Créer des agents/agent courrier, un groupe. Le messager vérifie que le destinataire est recensé dans l annuaire du domaine. Le message est déposé depuis la base Courrier de l utilisateur ou depuis une application de workflow par un bouton ou un agent qui tourne sur le poste client ou sur le serveur. Distribution d un message Le routeur est une tâche du serveur qui examine périodiquement la MAIL.BOX et qui est chargée de la distribution des messages (documents) déposés. Par consultation de l annuaire Domino du domaine names.nsf sur le serveur, le routeur détermine l emplacement de la base Courrier d un utilisateur onglet (Messagerie) du document Personne de l utilisateur ou de la base correspondant à la base Courrier en arrivée onglet (Informations sur la base) du document Base Courrier en arrivée. Si la base est trouvée, le message (document) est déposé, sinon un avis de non-distribution est retourné à l expéditeur. Si le destinataire est hébergé sur un autre serveur, le routeur ouvre une session sur le serveur de destination et dépose le message (document) dans la MAIL.BOX de ce serveur. Si le serveur distant ne peut pas être atteint directement, le routeur cherche la route la plus courte et dépose le message (document) dans la MAIL.BOX du premier nœud de la route Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

10 Envoyer une notification à un utilisateur Envoyer une notification à un utilisateur dans une formule de bouton, d événement Sans paramètres : champ SendTo Avec paramètres : paramètre envoia ; copiea; copiecacheea ; objet ; remarques ; champs ; [Indicateurs]) envoia, copiea, copiecacheea : destinataire(s) objet, remarques : le message champs : expression contenant la liste des champs du document à inclure dans le message [Indicateurs] : [IncludeDocLink], [Sign], [PriorityLow],... Une notification est envoyée à un utilisateur dans sa base courrier : Lorsqu une tâche urgente le sollicite, Lorsqu une tâche est en retard. Remarque Il est conseillé d utiliser la base Courrier de l utilisateur uniquement pour les cas d exception. En effet, si un grand nombre de notifications sont envoyées par courrier, l utilisateur devra gérer et classer ces notifications. Il est plus rationnel de lui préparer des vues privées dans une base l équivalent de bannettes dans lesquelles il trouvera les tâches à effectuer préclassées. Une notification est générée avec la et contient habituellement un lien LienDoc avec le document, ce qui permet à l utilisateur d ouvrir le document à partir du message de notification. Cette fonction a été vue dans le module Créer des agents/agent sans paramètres Le destinataire du document est enregistré dans un item nommé SendTo nom réservé au minimum. L intégralité du document est envoyée au destinataire. Cette méthode est utilisée surtout pour envoyer des documents à une base de workflow définie comme base Courrier en avec paramètres Le destinataire du document est précisé comme paramètre de la fonction. Il est aussi possible de créer un LienDoc avec l indicateur [IncludeDocLink], de copier le contenu de certains items du document dans le message. Cette méthode est utilisée pour envoyer une notification à un utilisateur dans sa base Courrier. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-9

11 Envoyer un document Envoyer un document La base de destination contient un masque pouvant afficher le document Champ sendto obligatoire Le destinataire est un utilisateur ou une base Deux techniques Le masque présente un dialogue d envoi Le champ MailOptions détermine l envoi L envoi d un document en entier se fait sans paramètres. Il peut également être programmé avec l une des deux techniques suivantes : l affichage d un dialogue à l enregistrement du document par une propriété du masque, l utilisation d un champ MailOptions dans le masque qui laisse choisir l utilisateur ou force l envoi du document ou l interdit. Dans les deux cas, le champ SendTo détermine le nom du ou des destinataires. Dialogue par propriétés du masque Designer 6.0 Démonstrations/Masque Routage\Envoi document Cliquer sur cette icône ou commande Conception/Propriétés du masque... Cliquer sur l onglet (Défaut). <A la fermeture> : cliquer Afficher la boîte de dialogue d envoi de courrier Créer un champ de type Noms et le nommer SendTo Cliquer sur cette icône, ou commande Conception/Prévisualiser dans Notes. Saisir un destinataire puis sauvegarder et fermer le document La boîte de dialogue s affiche : Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

12 Cliquer (Envoyer uniquement) ou (Envoyer et enregistrer) Le document apparaît dans la base Courrier du destinataire. Remarque Si le document n est pas conçu comme un message, il ne sera que partiellement affiché dans la base Courrier. Au minimum, le nom de l expéditeur apparaîtra. Le masque Memo de la base Courrier affiche le contenu des items From, SendTo, CopyTo, BlindCopyTo, Subject et Body. Si un item est absent, le champ n affiche rien. Cette technique est donc applicable si le document envoyé contient les items reconnus par le masque Memo ou si la base destinataire n est pas une base de courrier utilisateur mais une base d une application de workflow. Champ MailOptions Ce champ du masque peut prendre les valeurs : 0 : bloque l envoi du document, 1 : force l envoi du document par routeur de messagerie. Designer 6.0 Démonstrations/Masque Routage\Envoi document par MailOptions Champ modifiable L utilisateur se voit proposer le choix par bouton radio, par exemple. L utilisation d un pseudonyme sépare le texte proposé à l utilisateur de la valeur enregistrée. MailOptions Bouton radio Choix Champ calculé Le champ est positionné par une formule en dehors de l événement valeur du champ : les contrôles détectent une anomalie, le document a déjà été envoyé, l état du document sa position dans le processus ne demande pas son routage, le document doit être routé. FIELD MailOptions := 0 ; Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-11

13 Utiliser les rôles Utiliser les rôles Le rôle au sens Domino/Notes détermine une catégorie d utilisateurs Qui initialise un processus : par exemple, le manager Qui peut intervenir à tout moment dans n importe quel processus Dans la LCA (liste de contrôle d accès) de la base Ajouter le rôle L affecter à une personne ou un groupe Dans l application : Pour connaître la liste des rôles de l utilisateur courant Montrer ou cacher des boutons, des vues, des paragraphes... Le rôle correspond à un acteur identifié dans les diagrammes de cas d utilisation. L acteur a un rôle dans l application qui est souvent traduit par un rôle dans la LCA Liste de contrôle d accès de la base. Pour éviter les confusions sémantiques, nous parlerons respectivement du rôle (fonction) et du rôle (LCA). La création et l utilisation d un rôle (LCA) dans la LCA d une base ont été vues dans les modules Gérer l accès à l application/lca : le rôle et Gérer l accès à l application/droits : spéciales. L utilisation du rôle (LCA) dans une application de workflow est présentée ici au travers d exemples. Une catégorie d utilisateurs Le rôle (LCA) est inutile ou inutilisable dans un certain nombre de cas tels que : l ensemble des utilisateurs a le même rôle (fonction) : par exemple, dans le cas d un formulaire de demande de congés, tout le monde a le droit de demander à partir en congés, donc a le rôle (fonction) d initialiser le processus, une catégorie d utilisateurs a un rôle (fonction) de faciliteur et doit pouvoir modifier n importe quel document de la base. Il suffit de leur donner l accès Editeur dans la LCA de la base pour que ce besoin soit satisfait, le rôle (fonction) de responsable hiérarchique est défini par un lien de dépendance recopié dans un document : par exemple, dans le cas de la demande de congés, le nom du manager qui accepte/refuse la demande est copié dans le formulaire au moment de la création de ce dernier. Du point de vue de l application de workflow Notes, le rôle (fonction) est déterminé par le contexte du document. Le rôle (LCA) est bien adapté dans des cas tels que : un groupe limité d utilisateurs dispose du rôle (fonction) d initialiser un processus, par exemple, la création d une tâche, la création du dossier de prêt un groupe limité d utilisateurs modifie les règles de gestion d une application listes de mots-clés, de codes, et accède à des vues réservées, peut créer ou modifier des documents particuliers, Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

14 un rôle (LCA) de dépannage qui correspond à un rôle (fonction) informatique et non pas de l application peut être utile pour afficher les valeurs de champs normalement cachés, ou pour des documents de visibilité restreinte. Création du rôle dans la LCA Le rôle (LCA) est créé dans la LCA de la base sous forme d une chaîne de caractères qui sera testée ensuite dans l application. Il faut donc avoir un standard pour la casse (majuscules/minuscules). Le rôle (LCA) est ensuite affecté à une/des personnes ou groupes. Remarque L application peut connaître les groupes auxquels appartient l utilisateur courant, donc effectuer des tests sur ces noms. Il est préférable d associer les groupes à des rôles (LCA) pour que l application ne soit pas liée à une nomenclature de groupe : il y a séparation entre la logique de l application et la façon dont elle sera mise en production. Cliquer sur une entrée, puis sélectionner le rôle Rôle apparaissant entre crochets Rôle retourne la liste des rôles (LCA) de l utilisateur courant. La teste si une chaîne de caractères est membre d une ("[Gestionnaire]" ) ; La retourne True si la chaîne [Gestionnaire] fait partie de la Initialiser un processus L initialisation d un processus consiste le plus souvent à créer un document depuis un bouton. Dans l exemple qui suit, le bouton (Création tâche) est visible si l utilisateur courant a le rôle [Organisateur]. Afficher les propriétés du bouton Cliquer sur l onglet (Masquer). Accès à des vues réservées Certaines vues sont destinées aux utilisateurs ayant un rôle (LCA). Par exemple, la vue Taches\1. Manager est visible des utilisateurs ayant le rôle [Organisateur]. Afficher les propriétés de la vue, puis cliquer sur l onglet (Sécurité) Désélectionner Tout utilisateur ayant au moins l accès Lecteur Sélectionner le rôle [Organisateur] Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-13

15 Modifier un document sous condition Modifier un document sous condition Les utilisateurs ont l accès Auteur dans la LCA Les champs Auteurs précisent qui peut modifier un document Liste d utilisateurs Liste de rôles Les champs Auteurs sont Modifiables par le propriétaire du document, (du processus) : délégation de l accès Auteur Calculés d après l état du document dans le processus : un document archivé n est plus modifiable Propriétaire Délégation Les utilisateurs qui ont besoin de créer et/ou de modifier des documents ont un droit d accès Auteur dans la LCA de la base. Le droit d accès Editeur qui permet de créer des documents et de modifier n importe quel document est trop élevé et ne devrait être donné qu à un groupe restreint d utilisateurs gérant la base. L accès Auteurs a été abordé dans le module Gérer l accès à l application/document : accès Auteur. Ce paragraphe présente les champs de type Auteurs et la manière d en modifier le contenu dans le contexte d une application de workflow. Contenu des champs Auteurs Les champs de type Auteurs précisent quels sont les utilisateurs ayant le droit d accès Auteur dans la LCA de la base qui peuvent modifier le document courant. Notes prend en compte l ensemble des champs Auteurs pour déterminer ces droits. Les champs Auteurs peuvent contenir des noms de personnes, des noms de groupes, des rôles (LCA). C est une bonne pratique que de prévoir un champ de type Auteurs, calculé à la création et qui contient un rôle (LCA) pour des besoins de dépannage et qui peut être également affecté aux serveurs. Le rôle peut s appeler [Admin] par exemple, le rôle [Gestionnaire] désignant plutôt les utilisateurs qui modifient les règles de gestion de la base. Modification des champs Auteurs Dans l exemple d application proposé ici, il y a deux personnes identifiées qui accèdent à un document en modification : Le manager qui a créé la tâche, et qui doit pouvoir la modifier ensuite, notamment pour pouvoir déclarer la tâche abandonnée ou approuvée, La personne désignée pour effectuer la tâche et qui devra modifier le document entre le moment où la tâche est en cours et celui où elle est publiée ou abandonnée Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

16 Utilisation de deux types de champs Il apparaît donc que la présence du nom de la personne affectée dans un champ de type Auteurs n est pas permanente. Il s ensuit que le champ modifiable dans lequel le manager indique la personne affectée ne peut être de type Auteurs et sera plutôt de type Noms. Ce nom devra être dupliqué dans un champ de type Auteurs pour en être retiré une fois le travail accompli. Créer un champ de type Noms et modifiable Type Noms Modifiable Créer un champ de type Auteurs, calculé à la création, caché, supportant des valeurs multiples Type Auteurs Calculé à la création Autoriser entrées multiples Mise à jour du champ Auteurs La mise à jour se fait dans l événement onsubmit (QuerySave) par exemple, d après l état du document déterminé par le champ Statut, qui utilise des pseudonymes. Statut En attente En cours Effectuée Publiée Abandonnée Auteurs Organisateur : Affecte Organisateur : Affecte Organisateur Organisateur Organisateur La formule qui met à jour le champ AuteursDoc de type Auteurs sera : FIELD AuteursDoc ( Statut = "EA": "EC" ; Organisateur : Affecte ; Statut = "" : "TE" : "AP" : "AB" ; Organisateur ; AuteursDoc) ; Formule : le nom du champ lui-même Le champ contenant le nom de l organisateur est lui aussi de type Noms. De cette manière, la faculté est donnée de retirer l accès Auteur à l organisateur, par exemple lorsque l étude est publiée, elle sera gérée par un bibliothécaire. Remarque Le masque évalue une seule fois la formule de l événement valeur du champ AuteursDoc puisque celui-ci est calculé à la création. La valeur du champ est déterminée ensuite à l extérieur du champ. Le type calculé à la création est recommandé dans cette situation. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-15

17 Déterminer la visibilité d un document Déterminer la visibilité d un document Les utilisateurs ont l accès minimum Lecteur dans la LCA Les champs Lecteurs précisent qui peut voir un document Liste d utilisateurs, de serveurs Liste de rôles Les champs Auteurs permettent de voir également un document Les champs Lecteurs sont Modifiables par le propriétaire du document, (du processus) : document à visibilité réduite Calculés : un bouton (Privé) renseigne un champ Lecteurs avec le nom de l utilisateur courant Privé Les utilisateurs qui ont besoin de lire des documents ont un droit d accès Lecteur au minimum dans la LCA de la base. Le droit générique de lecture de n importe quel document peut être restreint en utilisant des vues réservées et des formules de sélection comme cela a été décrit dans le paragraphe Utiliser les rôles. Une autre technique consiste à utiliser des champs de type Lecteurs listant les personnes, groupes et rôles pouvant lire le document quelle que soit la vue dans laquelle il apparaît. L accès Lecteur pour un document a été abordé dans le module Gérer l accès à l application/document : accès Lecteur. Ce paragraphe présente les champs de type Lecteurs et la manière d en modifier le contenu dans le contexte d une application de workflow. Contenu des champs Lecteurs Les champs de type Lecteurs et Auteurs précisent quels sont les utilisateurs ayant le droit d accès Lecteur minimum dans la LCA de la base qui peuvent voir le document dans une vue et l afficher. Notes prend en compte l ensemble des champs Lecteurs et Auteurs pour déterminer ce droit. Ce schéma fonctionne dès lors qu il y a un champ de type Lecteurs non vide. C est une bonne pratique que de prévoir un champ de type Auteurs, calculé à la création et qui contient un rôle (LCA) qui peut être également affecté aux serveurs. Le rôle peut s appeler [Admin] par exemple. De cette façon, il est certain que les serveurs pourront toujours voir les documents pour les répliquer ou lors de l exécution d un agent. Remarque Les champs de type Lecteurs sont une protection par programmation des documents d une base. Ils offrent une protection convenable des documents confidentiels si le serveur est sécurisé. Cependant, il est toujours possible de faire sauter les verrous gérés par programmation en accédant au disque contenant la base sans passer par Domino. Le chiffrement offre un degré de protection supérieur Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

18 Modification des champs Lecteurs Document privé Le créateur du document est le seul à voir le document parce que ce dernier est en cours d élaboration et que le rendre visible serait source de confusion par exemple. Le plus simple est de créer un bouton d action avec deux libellés (Marquer privé)/(marquer public). Lorsque le libellé est (Marquer privé), un clic restreint la visibilité du document à son propriétaire puis le libellé devient (Marquer public). Un nouveau clic rend le document visible à tous. Le bouton est visible avec le rôle (LCA) [Organisateur]. Créer un champ LecteursDoc de type Lecteurs, calculé, caché, supportant des valeurs multiples Créer un bouton d action (Marquer privé)/(marquer Public) Le libellé dépend du contenu du champ de type Lecteurs. Si le champ est vide, le libellé est Marquer privé, sinon il est ; "Marquer privé" ; "Marquer public") Cliquer sur l onglet (Masquer) dans le dialogue des propriétés Cliquer Cacher l action si la formule est vérifiée et taper la formule! (@UserRoles ; "[Organisateur]" ) ) Le bouton doit être visible si l utilisateur courant a le rôle [Organisateur]. La négation de cette condition indique quand le bouton doit être caché. <Evénement Click> : taper la ; FIELD LecteursDoc := Organisateur; FIELD LecteursDoc := Null LecteursDoc reçoit le nom de l organisateur. La rafraîchit les formules de masquage des boutons ce qui remplace le libellé Marquer privé par Marquer public. Document partagé à visibilité restreinte Le créateur du document désire le partager avec un groupe restreint d utilisateurs pendant la phase d élaboration, ou parce que le document est de diffusion limitée. Créer un bouton d action (Partage restreint) Afficher les propriétés du bouton, puis cliquer sur l onglet (Masquer) Cliquer Cacher l action si la formule est vérifiée et taper la formule! (@UserRoles ; "[Organisateur]" ) ) Le bouton doit être visible si l utilisateur courant a créé ce document. <Evénement Click> : taper la formule LecteursAutorises ; FIELD LecteursDoc := Organisateur : LecteursAutorises ; LecteursDoc reçoit le nom de l organisateur et les noms choisis dans l annuaire. La rafraîchit les formules de masquage des boutons. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-17

19 Créer une section d accès contrôlé Créer une section d accès contrôlé L utilisateur est Auteur Sur le document Il est Editeur Sur des sections d accès contrôlé définies dans le masque Plusieurs utilisateurs Modifient dans le même document Une section (un paragraphe) propre à chacun Autre solution : sous-masque calculé ou masque déterminé par une formule de vue Les utilisateurs qui ont besoin de créer et/ou de modifier des documents ont un droit d accès Auteur dans la LCA de la base et sont présents dans des champs Auteurs des documents. A l intérieur d un document, la section d accès contrôlé détermine qui peut modifier telle ou telle partie du document. La section d accès contrôlé a été vue dans le module Gérer l accès à l application/masque : section d accès contrôlé. Ce paragraphe présente cette technique dans le contexte d une application de workflow. L alternative consistant à utiliser des sous-masques est vue ensuite. Conception des sections d accès contrôlé Organisation du masque Le masque doit être organisé pour regrouper tous les champs modifiables par une catégorie d utilisateurs. Dans l application exemple, il y a principalement deux intervenants : l organisateur et l employé affecté à la tâche. L organisateur détermine les règles de gestion du document et l employé doit remplir la partie destinée à recevoir le résultat du travail, puis déclarer la tâche effectuée. Formule d accès Le découpage étant effectué, la formule d accès d une section d accès contrôlé doit retourner la liste des éditeurs de la section, c est-à-dire la liste des personnes, groupes et rôles ayant le pouvoir de modifier les champs modifiables inclus dans la section. Les items dont le contenu sert aux calculs les règles sont extérieurs à la section le contenant pour éviter les blocages. Par ailleurs, il est prudent d inclure systématiquement un rôle de dépannage [Admin] dans les exemples précédents pour corriger les blocages éventuels. Créer la section d accès contrôlé, module Gérer l accès à l application/masque : section d accès contrôlé Clic droit sur le titre de la section puis commande Propriétés de la section Cliquer sur l onglet (Formule) Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

20 <Type> : sélectionner Calculé : la liste des éditeurs est calculée à partir de valeurs provenant d autres champs <Formule d accès> : taper une formule qui retourne la liste des éditeurs possibles : noms ou groupes contenus dans un champ, rôles. Chaque élément de la liste est séparé du suivant par le caractère deux-points ( : ) pour la section d accès contrôlé concernant l organisateur : Organisateur : [Admin] pour la section d accès contrôlé concernant la personne affectée : Affecte : [Admin] Mise à jour d un champ depuis deux sections Un champ Statut pilotant l état du document peut être mis à jour depuis deux sections. Une solution possible consiste à utiliser un bouton zone sensible d action ou un champ de saisie supplémentaire dont le contenu est affecté au champ Statut. Dans l exemple d application, l état du document peut être modifié par : l organisateur : il gère les valeurs En attente, En cours, Publiée, Abandonnée, l employé affecté : il gère la valeur Terminée. Une solution consiste à créer deux champs de saisie séparés par exemple orgstatut et empstatut, les listes de valeurs étant calculées d après l état actuel du document. La formule de l événement onsubmit (QuerySave) se charge d écrire le résultat de la saisie dans le champ Statut lequel est calculé (Formule d événement valeur : Statut), et vide les deux champs de saisie intermédiaires. FIELD Statut (!@IsNull(orgStatut) ; orgstatut ;!@IsNull(empStatut) ; empstatut ; Statut) ; FIELD orgstatut := NULL ; FIELD empstatut := NULL ; Utilisation de sous-masques L utilisation de sous-masques a été vue dans le module Gérer l accès à l application/masque : section d accès contrôlé. Une application de ce principe est proposée ici en remplacement des sections d accès contrôlé. Création des sous-masques L ensemble des champs modifiables par l organisateur doit être simplement affichable pour l employé affecté et inversement. Il faut donc créer deux sous-masques autant de sous-masques que d acteurs pour cet ensemble : un sous-masque smtacheorganisateur destiné à l organisateur qui contient tous les champs qu il peut modifier, les autres champs étant calculés à l affichage, un sous-masque smtacheaffecte destiné à l employé affecté qui contient tous les champs qu il peut modifier, les autres champs étant calculés à l affichage. Formule d insertion La formule d insertion du sous-masque sera du type (@IsNewDoc ; "smtacheorganisateur" Organisateur) ; "smtacheorganisateur" ; "smtacheaffecte" ) ; Si le document est nouveau ou si l utilisateur courant est l organisateur, le sousmasque smtacheorganisateur est inséré, sinon c est le sous-masque smtacheaffecte. Le document est protégé par le champ AuteursDoc de type Auteurs et une personne doit être présente dans ce champ pour modifier les champs dans un sous-masque. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-19

21 Contrôler l état d un document Contrôler l état d un document Le diagramme d états-transitions documente les états d un document dans un processus Les états sont les valeurs d un indicateur L indicateur (un item) est mis à jour Par bouton : (Approuver),... Par un agent : traitement de clôture... Pour un état déterminé Certaines transitions internes et de sortie sont possibles à partir de l état actuel, des valeurs d autres items, du temps Des transitions internes sont mémorisées : notification envoyée... Activité (traitement récurent) : rappel périodique (date)... Le diagramme d états-transitions a mis en évidence les états de gestion d un document : ceux qui ont un sens pour les utilisateurs. Le passage d un état vers un ou d autres états se fait par des transitions sortie d un état et entrée dans le suivant qui correspondent à des actions de l utilisateur ou à des actions déclenchées automatiquement en fonction du temps le plus souvent. L état est un attribut de la classe entité qui correspond à un item spécifique du document par exemple Statut dans Domino. Les valeurs de cet item mémorisent les positions successives du document dans le processus. Lorsque le document est dans un état donné, deux types de transitions et des activités sont habituellement identifiés : Transitions de sortie : l utilisateur agit en cliquant sur un bouton ou un agent traite le document et le traitement change la valeur de l état. Ces transitions sont figurées sur le diagramme d états-transitions par le texte attaché à la flèche matérialisant la transition. Transitions internes : toute une série de traitements peuvent se dérouler sans pour autant modifier l état du document. Ce sont par exemple des notifications envoyées aux acteurs, ou des relances ou un calcul effectué périodiquement. Il peut être nécessaire de mémoriser certains traitements pour être sûr qu ils ne s exécuteront qu une seule fois, par exemple une notification. Il faudra alors créer des états internes non visibles de l utilisateur. Ces transitions se documentent également dans le diagramme d états-transitions. Activité : il s agit de traitements récurrents notés Do dans un diagramme UML qui ne peuvent se rattacher qu à l état et qui cessent quand le document sort de l état. Ce peut être une mise à jour périodique d un item (le calcul d un âge), des rappels périodiques envoyés, des requêtes vers une source de données externe pour synchronisation, etc. Le scénario va s intéresser ici à la mise à jour de l indicateur d état Statut suite à l enregistrement du document de tâche la transition s effectue à partir de valeurs actuelles et du facteur temps et à la mise à jour d un indicateur d état interne suite à l envoi d une notification Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

22 Création d un indicateur L indicateur d état est un item dont le contenu est déterminé par des formules n appartenant pas à des événements attachés au champ correspondant dans le masque : formules d événement Clic de bouton, événement onsubmit (QuerySave) du masque, agent, etc. Pour définir l indicateur dans le masque : Créer un champ Calculé à la création, par exemple Statut, de type Texte le plus souvent <Evénement valeur du champ> : taper Null ou le nom du champ, ici Statut, si la chaîne de caractères vide est requise au départ ou taper la valeur correspondant au premier état du document, par exemple En attente pour la tâche Remarque Une bonne pratique consiste à associer pour un état un libellé affiché à l utilisateur et un code testé par formule pour une plus grande souplesse d évolution de l application. Lorsque des indicateurs n ont pas besoin d être visibles de l utilisateur, une pratique courante consiste à les grouper en tête du masque dans un paragraphe caché. Les applications écrites par Lotus utilisent une police de caractères avec un corps de 9, normal et rouge et des commentaires placés à côté des indicateurs. De la même façon, les indicateurs internes attachés à des transitions internes sont créés comme champs Calculés à la création. Il peut être pratique de créer des champs calculés à l affichage qui déterminent en fonction de l état d un document, de l utilisateur connecté, de la dimension temps, quels sont les boutons devant être affichés, les libellés de ces boutons, les transitions possibles. Mise à jour d un indicateur d état Evénement onsubmit (QuerySave) Reprenons l exemple du Statut de la tâche qui évolue selon le schéma : Statut En attente En cours Effectuée Publiée Abandonnée Pseudonyme EA EC EF PU AB Dans le paragraphe Créer une section d action contrôlée, l organisateur agit sur le Statut depuis un champ de saisie orgstatut et l employé fait de même depuis un autre champ empstatut. L événement valeur de Statut est : FIELD Statut (!@IsNull(orgStatut) ; orgstatut ;!@IsNull(empStatut) ; empstatut ; Statut) ; FIELD orgstatut := NULL ; FIELD empstatut := NULL ; Une variante est proposée ici, qui consiste à ne pas calculer Statut depuis l événement Valeur : c est pourquoi il a été transformé en Calculé à la création. Par ailleurs, les spécifications ont évolué et disent que si le Statut de la tâche est Effectuée et que la DateFinPrevue est dépassée alors le Statut passe à Publiée (PU). La programmation est effectuée dans l événement onsubmit (QuerySave) du masque. FIELD Statut (!@IsNull(orgStatut) ; orgstatut ;!@IsNull(empStatut) ; empstatut ; Statut) ; FIELD Statut (Statut = "EF" & DateFinPrevue ; "PU" ; Statut) ; Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-21

23 FIELD orgstatut := NULL ; FIELD empstatut := NULL ; Dans la pratique, la mise à jour de Statut se fait à l extérieur du champ pour une plus grande souplesse quant au choix du moyen et du moment où elle est effectuée : onsubmit, bouton ou agent. Evénement Clic de bouton Le scénario proposé ici illustre la mise en place d un indicateur lié à une transformation interne : l organisateur notifie l employé affecté en pressant sur un bouton prévu à cet effet. La notification ne doit être envoyée qu une seule fois et est contrôlée avec un indicateur notifaffecte qui contient la date et l heure de l envoi. msg := "Merci d intégrer cette tâche à votre plan de travail" @MailSend(Affecte;NULL;NULL;TitreTache;msg;NULL; [IncludeDocLink] ) ; FIELD notifaffecte Cette séquence pourrait aussi bien être incorporée dans l événement onsubmit (QuerySave) pour une notification systématique lorsque le Statut est En cours si les spécifications le prévoient ainsi. Mise en place d une activité Le scénario proposé ici illustre la mise en place d une activité de relance automatique : tous les jours lorsque la tâche est dans l état En cours et que la date de fion prévue est dépassée. Evénement Action d agent Cette relance est effectuée par un agent planifié tous les jours, par exemple à 5h du matin, sur le serveur. msg := "La base de suivi ne contient pas d information de fin de la tâche qui vous a été confiée." + "La date prévue initialement " + " est dépassée. " + "Merci de terminer votre travail et de mettre à jour l information." ( Statut = "EC" & DateFinPrevue [IncludeDocLink] ) Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

24 Contrôler l accès à une vue Contrôler l accès à une vue Une vue partagée est visible Par tout utilisateur ayant au moins l accès Lecteur dans la LCA Par un utilisateur désigné : nom, rôle, nom de groupe Une vue privée est visible De l utilisateur qui la crée De l utilisateur qui ouvre une vue partagée devenant privée Utilisation de la méthode Vues réservées à l acteur gestionnaire d application : les documents en conflit de réplication, les listes de codes Vues réservées à d autres acteurs identifiés par un rôle dans la LCA Par défaut, une vue est visible de tout utilisateur ayant au moins l accès Lecteur dans la LCA de la base. L utilisateur ne verra cependant pas les documents pour lesquels son nom est absent de champs de type Lecteurs et Auteurs lorsque un ou des champs de type Lecteurs sont présents. L utilisation de champs de type Lecteurs devrait être limitée dans une application : une systématisation peut déboucher sur de mauvaises performances. Le contrôle de l accès et de l affichage au niveau de la vue sont préférables au contrôle de l affichage au niveau document avec les champs Lecteurs. Les solutions mises en place tiennent compte des recommandations suivantes : Spécialiser les vues par catégories d acteurs pour le confort des utilisateurs en jouant sur les rôles de la LCA, Utiliser l affichage d une catégorie de la vue (vue intégrée dans un masque), Masquer des colonnes selon le rôle de l utilisateur, Créer des vues privées ou partagées devenant privées à la première utilisation, Minimiser le nombre de vues. Remarque Si un utilisateur n a pas accès à une vue, il peut toujours en construire une et consulter les documents compris dans la formule de sélection de la vue, à moins que les documents soient protégés par un champ de type Lecteurs. Les vues à accès restreint ne sont donc pas une mesure de protection de la confidentialité des informations. Ce paragraphe aborde le contrôle d accès à une vue partagée et privée et quelques exemples d utilisation de cette technique. Vue partagée Le module Gérer l accès à l application/droits spéciales présente le scénario qui suit : la vue Codes\2. Type de réunion n est visible que des utilisateurs ayant le rôle [Gestionnaire]. Afficher les propriétés de la vue Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-23

25 Vue privée Cliquer sur l onglet (Sécurité). Désélectionner Tout utilisateur ayant au moins l accès Lecteur Sélectionner le rôle Dans l application de gestion des tâches, on peut imaginer une vue réservée aux organisateurs acteurs identifiés par un rôle qui présente l ensemble des documents quel que soit leur Statut. Une vue privée ou une vue partagée devenant privée à la première ouverture n est visible que de son créateur ou de l utilisateur qui l a ouverte. La formule de sélection de la vue comprend habituellement le nom de l utilisateur courant. La vue partagée devenant privée à la première ouverture peut être protégée pour que seule une catégorie d utilisateurs puisse créer des vues privées à partir de ce modèle. Type de vue Emplacement Modèle Critères de sélection Rôle sélectionné Ce type de vue est identifié avec une icône spéciale dans la liste des vues de Designer. Utilisation de la méthode Cette méthode sert principalement à limiter le nombre de vues affichées à un utilisateur ce qui simplifie la navigation dans l application. Les autorisations d accès sont liées à l utilisation de rôles dans la LCA pour délimiter les catégories d utilisateurs. Les vues qui sont d accès restreint sont : Les vues affichant les listes de codes internes à l application, Les vues destinées à la correction d anomalies d exploitation comme les conflits de réplication, Les vues réservées aux utilisateurs intervenant dans le processus du workflow Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

26 Contrôler le masque utilisé depuis une vue Contrôler le masque utilisé depuis une vue Une formule dans la vue détermine le nom du masque D après l utilisateur, l état du document Le même document peut être visualisé ou modifié par plusieurs masques : attention au contenu de Form après enregistrement Les masques ont plusieurs pseudonymes Un pseudonyme pour l identification dans la formule de masque Un pseudonyme le dernier pour l enregistrement dans Form Recommandations Préférer les sous-masques calculés Réserver le contrôle de masque dans la vue à l affichage pour impression (masque avec SaveOptions = 0 ) Le paragraphe Créer une section d accès contrôlé montre comment utiliser des sections d accès contrôlé et des sous-masques pour personnaliser le masque chargé d afficher un document à l utilisateur. Le choix du masque peut également être déterminé par une formule au niveau de la vue. Ceci permet d atteindre des objectifs similaires : Choisir le masque d après l état du document : en cours de création, existant, test d un indicateur (par exemple le Statut), Choisir le masque d après l utilisateur et son rôle (type d acteur) par rapport au document : le créateur du document, un auteur par délégation, Utiliser une mise en page spécifique à l impression : c est la raison principale d utilisation de cette technique actuellement. Ce paragraphe décrit comment écrire la formule dans la vue et les précautions à prendre pour la codification des pseudonymes de masques. Formule de masque dans la vue Cliquer sur l événement de vue Formule de masque utilcourant ; estceorganisateur ; "[Organisateur]") ; org ; Organisateur) (utilcourant = org ; "mastacheorganisateur" & estceorganisateur ; "mastacheorganisateur" &!estceorganisateur ; "mastacheerreur" ; "mastacheaffecte" ) Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-25

27 L application a prévu trois masques : mastacheorganisateur (masque spécifique aux utilisateurs ayant le rôle [Organisateur]), mastacheaffecte (masque destiné aux autres utilisateurs) et mastacheerreur (pour afficher un message d erreur). L exemple proposé ici se décortique comme suit : le prénom et le nom de l utilisateur courant sont récupérés dans une variable de travail et son rôle (LCA) [Organisateur] sous forme d un booléen, le prénom et le nom de l organisateur sont récupérés du document tâche dans une variable de retourne le nom d un masque à utiliser. Condition Le document existe et l utilisateur courant est l organisateur identifié dans le document Le document est nouveau et l utilisateur a le rôle [Organisateur] Le document est nouveau et l utilisateur n a pas le rôle [Organisateur] Le document existe et l utilisateur n a pas le rôle [Organisateur] Masque mastacheorganisateur mastacheorganisateur mastacheerreur mastacheaffecte Pseudonymes de masques Lorsqu un document peut être affiché et modifié par plusieurs masques, il est essentiel que le contenu de l item Form soit identique : il faut donc que le pseudonyme de tous ces masques soit toujours le même. Le nom de masque retourné par une formule de vue ne peut donc être celui qui est enregistré dans l item Form. Il faut donc jouer sur le nom du masque à gauche du caractère pipe ( ) ou jouer sur des pseudonymes multiples. Afficher les propriétés du masque <Nom> : taper le nom du masque suivi de deux pseudonymes, par exemple Tache Organisateur mastacheorganisateur mastache <Affichage> : décocher les deux options Inclure dans le menu et Inclure dans le Générateur de requêtes pour limiter l usage des masques Le nom de gauche Tache Organisateur, n est pas utilisé dans une formule. Le premier pseudonyme mastacheorganisateur est utilisé dans une formule de masque de vue. Le second pseudonyme mastache est enregistré dans l item Form et testé dans les formules de sélection de vue. De la même façon, le masque destiné aux autres utilisateurs aura comme nom : Tache Affecte mastacheaffecte mastache Cette technique est inutilement complexe dans le cas présenté ici : il vaut mieux concevoir un masque avec deux sous-masques incorporés par formule. Si la technique est retenue pour l impression des documents, ajouter dans le masque d impression un champ SaveOptions Calculé à l affichage, caché, de valeur 0 par précaution Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

28 Archivage de documents Archivage de documents Chapitre 11 : Mettre en œuvre un workflow L archivage a été identifié dans le diagramme d états-transitions Etat du document : la transition d archivage est possible Acteur : un utilisateur archiviste ou un agent selon que la transition est déclenchée manuellement ou d après l âge du document La transition d archivage consiste A copier le document dans une base spéciale, par exemple par routage A le supprimer dans la base d origine Base d archives : il est prévu de conserver les documents Les documents peuvent être affichés mais non modifiés Notes offre des méthodes d archivage standard qui sont parfaitement applicables à des bases de conférences, des kiosques d informations toutes bases pour lesquelles la règle d archivage est simple et peut s exprimer en une durée de vie applicable à tous les documents de la base. Les bases documentaires gérant des versions de documents, ou les bases de workflow dans lesquelles les documents appartiennent à un processus, demandent des règles plus élaborées qu il vous appartient de développer. Ce paragraphe examine les règles d archivage, la création d une base d archives et le processus d archivage proprement dit. L archivage a été prévu lors de la modélisation du processus et apparaît dans les cas d utilisation et le diagramme d états-transitions. Règles d archivage L événement qui déclenche l archivage peut être : Les tâches dont le statut est Abandonnée doivent être archivées dans une base réservée automatiquement dans les 24 heures, Les tâches dont le statut est Publiée doivent être copiées dans une base de Publication immédiatement, Dans la base de gestion de la qualité, un document décrivant une procédure ISO remplacé par une nouvelle version est archivé par l acteur archiviste qui procède manuellement au déplacement des documents dans la base d archives. La gestion de l archivage nécessite éventuellement la création d un nouvel état du document, lorsqu il reste en attente d archivage pendant un certain temps. Cet état détermine sa visibilité limitée et l exécution de l archivage proprement dit. Base d archives La base d archives est munie des fonctions suivantes : affichage des documents archivés dans les vues conçues pour la consultation, affichage des documents avec des masques ne permettant pas de mise à jour. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-27

29 La base d archives peut donc être créée à partir de la base d origine par copie puis par simplification de la structure. La base d archives étant créée, un document Base Courrier en arrivée associé permettra l utilisation du routeur pour envoyer les documents dans la base. Processus d archivage Le processus d archivage est implanté comme formule dans un agent planifié, l événement Clic d un bouton ou d une action, l événement onsubmit (QuerySave) d un masque Elle se décompose en trois étapes principales : vérification de l état du document : peut-il être archivé par l utilisateur courant qui en fait la demande, envoi du document dans son intégralité à la base d archivage, suppression du document de la base. Envoi du document La (sans paramètres) associée à un champ SendTo contenant le nom de la base d archives (d après le document Base Courrier en arrivée) accomplit cette étape. Un indicateur contenant la date et l heure d envoi du document est créé. Suppression du document de la base La accomplit cette étape. Elle fonctionnera si l utilisateur courant ou le signataire de l agent planifié a le privilège Supprimer des documents dans la LCA de la base. Supprimer des documents La suppression d un document d une base devrait être gérée dans les applications de type workflow par des contrôles supplémentaires. Dans l exemple de workflow de tâches, seul l organisateur peut supprimer les documents dont il est l auteur. Il a donc seul ce privilège parmi les utilisateurs. On peut préciser ce droit avec les règles suivantes : tant qu une tâche est En attente il n y a pas de personne affectée alors l organisateur peut supprimer le document, si une tâche est déclarée Abandonnée et si l indicateur d envoi du document à la base d archives est renseigné avec une date/heure, alors l organisateur ou un agent planifié peuvent supprimer le document. Une solution courante consiste à écrire ces règles en LotusScript dans l événement QueryDocumentDelete de la base qui s exécute avant que le document soit marqué pour suppression ou l événement PostDocumentDelete qui s exécute avant que le document soit réellement supprimé. Cliquer Autres, puis Ressources de base de documents, puis Script de la base Les suppressions peuvent aussi être de type soft delete et récupérées par programmation Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

30 Rappel des objectifs Rappel des objectifs Savoir-faire Utiliser le routeur pour faire circuler les documents Utiliser les rôles et les champs Lecteurs et Auteurs pour contrôler la visibilité et la modification des documents Gérer les accès à l intérieur d un document par section d accès contrôlé Contrôler l état d un document dans le workflow Utiliser des documents profil Connaissance La typologie de workflow et l analyse d une application workflow Domino.workflow Le workflow consiste pratiquement à faire circuler entre les acteurs d un processus des documents dématérialisés. Domino/Notes se prête bien à certaines formes de workflow. Ce chapitre a pour objectif d apprendre à mettre en œuvre un workflow modélisé avec des outils UML, essentiellement les cas d utilisation et le diagramme états-transitions. Le lecteur saura également utiliser les fonctions de routage de Domino dans le langage de formules pour notifier les acteurs ou déplacer un document d une base vers une autre. Les contrôles d accès aux documents sont approfondis. Le générateur Domino Workflow est présenté rapidement. La sécurité et le routage de documents sont revus et mis en application. Résumé du chapitre La typologie du workflow Une application workflow automatise une séquence d actions, d activités ou de tâches dans un processus donné : une demande d achats, le règlement d un litige, une mise au contentieux, le règlement d un sinistre Le workflow comprend également les outils nécessaires pour connaître l état de chaque instance du processus ainsi que pour gérer le déroulement du processus. Le champ du workflow est donc vaste et les problématiques sont de complexité variable. Une classification est proposée par Setrag Khoshafian et Marek Buckiewicz dans Introduction to Groupware, Workflow and Workgroup Computing (John Wiley & Sons, Inc.) : Workflow administratif, Workflow ad hoc, Workflow de production. Lotus propose une classification assez proche prenant en compte les fonctions de partage collaboratif de Notes. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-29

31 Domino Workflow Domino Workflow est une application Lotus Notes qui supporte le développement de workflows ad hoc et de production : analyse et conception de l application, exécution, visualisation d un processus en cours. Domino Workflow se décompose en : Architect : la conception du workflow, Engine : le moteur d exécution, Viewer : l outil d interrogation et de suivi des processus. Application de suivi des tâches L application de suivi de réalisation de tâches qu il s agit de réaliser a été présentée dans module Méthodologie élémentaire. C est un workflow très simple qui parcourt les techniques de programmation utilisées dans ce type d application en les reliant à une méthode générale d analyse fondée sur UML. Diagramme des cas d utilisation Ces diagrammes présentent l application du point de vue des utilisateurs. Les acteurs qui interagissent avec l application, personnes et processus externes, souvent représentés par des rôles dans la LCA de la base, ici l organisateur et l employé, Le domaine couvert par l application et ses interfaces avec les autres applications vues comme des acteurs, Les fonctions attendues, ici attribuer une tâche, exécuter une tâche, contrôler le travail. Diagramme de classes Deux types de documents sont représentés dans le diagramme de classes : le Compte rendu et la Tâche. Zéro, une ou plusieurs tâches sont reliées au compte rendu et chaque tâche ne dépend que d un compte rendu (cardinalité). Les opérations applicables aux tâches méthodes dans la terminologie OO sont symbolisées dans la partie inférieur du cadre représentant la classe Tâche. Ce sont Notifier(), Terminer(), Corriger(), Approuver() et Abandonner(). Diagramme d états-transitions Ce diagramme décrit les états successifs d une tâche. L attribut Statut de la classe Tâche prend les valeurs En attente, En cours, Effectuée, Publiée et Abandonnée. L état initial est symbolisé par un cercle plein au départ et l état final par deux cercles concentriques. Chaque rectangle symbolise un état et le texte sur la transition indique l acteur ou l événement à l origine de la transition et l action effectuée. Le routeur de messagerie Notifier un acteur lorsqu un travail est en retard, publier un document dans une base s appuient sur le mécanisme de routage de courrier de Domino. Le routeur de messagerie est la tâche s exécutant sur le serveur Domino qui achemine les messages depuis la boîte de routage MAIL.BOX vers leurs destinataires. Le routeur consulte l annuaire Domino du domaine names.nsf pour obtenir des informations sur les destinataires : personnes et bases Courrier en arrivée. Envoyer une notification à un utilisateur Une notification est envoyée à un utilisateur dans sa base Courrier : Lorsqu une tâche urgente le sollicite, Lorsqu une tâche est en retard Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

32 Une notification est générée avec la codée avec des paramètres. [IncludeDocLink] permet de créer un LienDoc avec le document faisant l objet de la notification. Envoyer un document L envoi d un document en entier se fait sans paramètres. Il peut également être programmé avec l une des deux techniques suivantes : l affichage d un dialogue à l enregistrement du document par une propriété du masque, l utilisation d un champ MailOptions dans le masque qui laisse choisir l utilisateur ou force l envoi du document ou l interdit. Dans les deux cas, le champ SendTo détermine le nom du ou des destinataires. Utiliser les rôles Le rôle correspond à un acteur identifié dans les diagrammes de cas d utilisation. L acteur a un rôle dans l application qui est souvent traduit par un rôle dans la LCA Liste de contrôle d accès de la base. Le rôle dans la LCA correspond normalement à un type d acteurs accomplissant des fonctions données dans le workflow : initialiser un processus ou intervenir dans un processus en dehors du simple contexte du document. Modifier un document sous condition Les utilisateurs qui ont besoin de créer et/ou de modifier des documents ont un droit d accès Auteur dans la LCA de la base. Le droit d accès Editeur qui permet de créer des documents et de modifier n importe quel document est trop élevé et ne devrait être donné qu à un groupe restreint d utilisateurs gérant la base. Déterminer la visibilité d un document Les utilisateurs qui ont besoin de lire des documents ont ont un droit d accès Lecteur au minimum dans la LCA de la base. Le droit générique de lecture de n importe quel document peut être restreint en utilisant des vues réservées et des formules de sélection comme cela a été décrit dans le paragraphe Utiliser les rôles. Une autre technique consiste à utiliser des champs de type Lecteurs listant les personnes, groupes et rôles pouvant lire le document quelle que soit la vue dans laquelle il apparaît. Créer une section d accès contrôlé Les utilisateurs qui ont besoin de créer et/ou de modifier des documents ont un droit d accès Auteur dans la LCA de la base et sont présents dans des champs Auteurs des documents. A l intérieur d un document, la section d accès contrôlé détermine qui peut modifier telle ou telle partie du document. Une section d accès contrôlé peut être remplacée par deux sous-masques insérés par formule : un sous-masque permettant de modifier les champs et le second ne faisant que de l affichage. La formule d insertion des sous-masques est logiquement la même que la formule qui détermine les éditeurs d une section. Contrôler l état d un document Le diagramme d états-transitions met en évidence les états de gestion d un document : ceux qui ont un sens pour les utilisateurs. Le passage d un état vers un ou d autres états se fait par des transitions sortie d un état et entrée dans le suivant qui correspondent à des actions de l utilisateur ou à des actions déclenchées automatiquement en fonction du temps le plus souvent. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-31

33 L état est un attribut de la classe entité et correspond à un item spécifique du document par exemple Statut dans Domino. Lorsque le document est dans un état donné, deux types de transitions et des activités sont habituellement identifiés : Transitions de sortie figurées sur le diagramme d états-transitions par le texte attaché à la flèche matérialisant la transition. Transitions internes correspondant à des traitements qui ne modifient pas l état du document et documentées dans le diagramme d états-transitions. Activité correspondant à des traitements récurrents notés Do dans un diagramme UML qui ne peuvent se rattacher qu à l état et qui cessent quand le document sort de l état. Contrôler l accès à une vue Par défaut, une vue est visible de tout utilisateur ayant au moins l accès Lecteur dans la LCA de la base. L utilisateur ne verra cependant pas les documents pour lesquels son nom est absent de champs de type Lecteurs et Auteurs lorsque un ou des champs de type Lecteurs sont présents. Les solutions mises en place tiennent compte des recommandations suivantes : Spécialiser les vues par catégories d acteurs pour le confort des utilisateurs en jouant sur les rôles de la LCA, Utiliser l affichage d une catégorie de la vue (vue intégrée dans un masque), Masquer des colonnes selon le rôle de l utilisateur, Créer des vues privées ou partagées devenant privées à la première utilisation, Minimiser le nombre de vues. Contrôler le masque utilisé dans une vue Le choix du masque utilisé pour visualiser ou modifier un document peut être déterminé par une formule au niveau de la vue. Ceci permet de : Choisir le masque d après l état du document : en cours de création, existant, test d un indicateur (par exemple le Statut). Choisir le masque d après l utilisateur et son rôle (fonction) par rapport au document : le créateur du document, un auteur par délégation. Créer un masque ne servant qu à l affichage et/ou l impression du document. Archivage de documents Notes offre des méthodes d archivage standard qui sont parfaitement applicables à des bases de conférences, des kiosques d informations toutes bases pour lesquelles la règle d archivage est simple et peut s exprimer en une durée de vie applicable à tous les documents de la base. L archivage a été prévu lors de la modélisation du processus et apparaît dans les cas d utilisation et le diagramme d états-transitions avec des règles déterminées. Points essentiels La modélisation du workflow permet d identifier les états d un document, les transitions d un état vers un autre, le rôle des acteurs utilisateurs, processus, mécanismes externes et du temps dans le déclenchement des transformations. La recommandation est d utiliser un style de programmation regroupant autant que possible les règles du workflow dans un nombre limité d événements. Cette approche est facilitée en LotusScript avec lequel la création d objets métier fait correspondre la modélisation et la programmation Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

34 Atelier 11 Atelier 11 Objectifs : Ecrire un workflow de gestion de tâches Contrôler les accès de deux acteurs Envoyer des notifications Durée : 4 heures 45 minutes Exercice 1 : Créer le masque Tâche et une notification 45 mn Le workflow de tâches est développé dans la base de suivi de projets. Un seul document est pris en compte dans le workflow de tâches : il décrit une tâche à accomplir et doit recevoir le résultat du travail sous forme d une ou plusieurs pièces attachées : fichier de traitement de texte, présentation, feuille de calcul. L organisateur (de la réunion) crée un document à chaque fois qu il y a une tâche à accomplir définie au cours de la réunion et affecte un employé à cette tâche. Un mécanisme de notification signale à l employé qu il a un travail à accomplir. Etapes L exercice se divise en trois étapes : La création du masque, La création d une vue permettant de visualiser les tâches, La création du système de notification. Modifiez les propriétés de la base pour ne pas afficher l agencement de cadre et sélectionnez Afficher la dernière vue utilisée Les vues créées seront intégrées dans le plan de navigation quand elles seront au point. Créez le masque Tâche avec le pseudonyme mastache dans la base de Suivi de projets Créez les champs selon le tableau Champ Organisateur Propriétés Type Noms, Modifiable, Nom de l utilisateur courant par défaut, Obligatoire. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-33

35 Champ NomProjet Categories TitreTache Affecte DateFinPrevue DatePublication DateFinReelle Propriétés Type Liste de dialogue ou Liste déroulante. Valeurs prises de la vue vuenomprojet, Obligatoire. Type Liste de dialogue ou Liste déroulante. Valeurs identiques à celles du champ Categories utilisé dans les documents Ordre du jour et Compte rendu. Obligatoire. Type Texte, obligatoire. Type Noms, valeur récupérée de l annuaire Domino du domaine. Type Date/Heure, afficher la date seulement. Type Date/Heure, afficher la date seulement. Type Date/Heure, afficher la date seulement. Statut Type Liste de dialogue ou Liste déroulante. Valeurs (synonyme) : En attente (EA), En cours (EC), Effectuée (EF), Publiée (PU), Abandonnée (AB). Ce champ est provisoirement modifiable. Body Utiliser le champ partagé : type Texte riche. Créez la vue Taches\1. Par Organisateur catégorisée par Organisateur qui affiche uniquement les tâches Créez les colonnes Colonne Propriétés 1 Nom propre de l organisateur, catégorisée 2 Nom du projet, catégorisée Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

36 Colonne Propriétés 3 Date de fin prévue, classée par ordre croissant 4 Titre de la tâche et nom de la personne entre parenthèses si renseigné Créez dans le masque Tâche un bouton d action (Notifier) qui envoie à la personne affectée un message reprenant le titre de la tâche et un LienDoc vers le document de tâche. S il n y a pas de personne affectée, envoyez un dialogue indiquant que l envoi n a pas été effectué Créez un deuxième bouton (Envoyer) qui envoie la totalité du document à la personne affectée Est-ce que le document apparaît dans la corbeille Arrivée de la base Courrier du destinataire? Est-ce que le document peut être consulté? Pourquoi? Procédures Reportez-vous aux pages 11-8 à Exercice 2 : Rôles 20 mn La création d une tâche est du ressort de l organisateur qui initialise le processus. Par ailleurs, il est nécessaire de créer des vues spécifiques aux organisateurs et de les séparer des vues utilisées par les personnes affectées. Etapes Créez un rôle [Organisateur] dans la LCA de la base Créez la vue Taches\2. Par Affectation catégorisée par Personne affectée qui affiche uniquement les tâches Réservez la vue Taches\1. Par Organisateur aux seules personnes de rôle [Organisateur] Créez une vue Taches\0. Par organisateur(privée) de type Partagé, devenant privé à la 1ère ouverture sur le modèle de Taches\1. Par Organisateur. Cette vue est réservée aux utilisateurs ayant le rôle [Organisateur] et doit afficher les seules tâches gérées par l utilisateur courant Procédures Reportez-vous aux pages à Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-35

37 Exercice 3 : Champs Auteurs et Lecteurs 35 mn La personne affectée doit pouvoir modifier le document de tâche. Le traitement de détermination de l auteur se fait automatiquement à l enregistrement du document. Lorsqu un document de tâche est en cours de rédaction, il faut pouvoir en limiter la visibilité. Etapes Modifiez le masque Tâche Statut En attente En cours Effectuée Publiée Abandonnée Pseudonyme EA EC EF PU AB Auteurs [Admin] Organisateur [Admin] Organisateur Affecte [Admin] Organisateur [Admin] [Admin] Les règles récapitulées dans le tableau indiquent, par état du document, qui peut le modifier. Créez un champ AuteursDoc qui permette à la personne affectée par l organisateur à la réalisation de la tâche de modifier le document. La valeur de ce champ est calculée à l enregistrement du document : événement onsubmit (QuerySave) Vérifiez le fonctionnement de AuteursDoc en créant un document avec un ID (l organisateur) et en le modifiant avec un autre ID (la personne affectée) Le test doit s effectuer avec la base sur serveur ou bien avec une base locale et une LCA cohérente. Créez un champ LecteursDoc de type Lecteurs pour enregistrer les lecteurs du document. La valeur de ce champ sera toujours calculée en dehors de ses propres événements Créez un bouton d action (Marquer privé/marquer public) avec les caractéristiques suivantes : Au premier clic, il rend le document visible uniquement de l organisateur et de la personne affectée en utilisant un champ LecteursDoc Au clic suivant, il rend le document visible de tous Son libellé change selon l action qu il va effectuer Pour éviter les situations de blocage, un rôle Admin est prévu pour déverrouiller toutes les situations : si un organisateur remplace son nom par celui d une autre personne et qu il marque le document privé, il ne verra plus le document qu il a créé. Créez le rôle [Admin] dans la LCA de la base Créez un champ AuteursAdmin qui contienne uniquement le rôle [Admin] et tel que l utilisateur en possession de ce rôle puisse toujours voir et modifier le document Vérifiez le fonctionnement de LecteursDoc avec des utilisateurs présents ou non dans ce champ Procédures Reportez-vous aux pages à Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

38 Exercice 4 : Section d accès contrôlé 30 mn Etapes La personne affectée à une tâche ne doit pas avoir accès en modification aux champs de la responsabilité de l organisateur et réciproquement. Une première solution passe par la création de sections d accès contrôlé dans un masque. Une autre solution consiste à créer des sous-masques dédiés à chacun des deux acteurs. Le champ Statut est accessible par les deux acteurs puisqu ils le font évoluer par leurs actions. Il ne sera pas protégé pour le moment et la bonne volonté de chacun devrait suffire en attendant une solution prochaine. Faites une copie du masque Tâche de façon à en avoir une sauvegarde Organisez le masque de telle façon que les données modifiables par l organisateur Organisateur, NomProjet, Categories, TitreTache, Affecte, DateFinPrevue, DatePublication soient séparées de celles modifiables par la personne affectée Body et DateFinReelle. Vous devez tenir compte du fait qu un tableau ne peut être inclus partiellement dans une section Créez une section d accès contrôlé Organisateur modifiable par l organisateur et par une personne ayant le rôle [Admin] qui sert de dépannage. La règle ne peut être modifiée et doit toujours s appliquer Pour faciliter le développement et la mise au point, vous pouvez créer un champ calculé à l affichage pour chaque section qui retourne la liste des éditeurs de la section. Ce champ est repris dans la formule d accès de la section d accès contrôlé, elle-même du type calculé à l affichage. Créez une section d accès contrôlé Affecte modifiable par la personne affectée et par une personne ayant le rôle [Admin] qui sert de dépannage. La règle ne peut être modifiée et doit toujours s appliquer Remarque Le champ Statut est en dehors de toute section. Effectuez un test et constatez également que même si vous êtes Gestionnaire dans la LCA de la base, vous ne pourrez pas accéder en modification au contenu d une section d accès contrôlé si vous ne faites pas partie des éditeurs de la section Double-cliquez sur l en-tête d une section pour voir les éditeurs de la section Constatez qu en vous donnant le rôle [Admin], vous avez accès à toutes les sections d accès contrôlé dans votre base Modifiez le nom du masque en Tâche (sections) mastachesection pour ne pas perdre votre travail et de façon à ce qu il n interfère pas avec le développement qui suit Procédures Reportez-vous aux pages à 11-19, 9-16 à Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-37

39 Exercice 5 : Alternative : sous-masque 30 mn Etapes La solution consistant à créer des sous-masques dédiés à chacun des deux acteurs plutôt que les sections d accès contrôlé est développée maintenant. Repartez de la copie du masque Tâche que vous avez faite en début d exercice précédent, avant l incorporation des sections d accès contrôlé Créez le sous-masque smtacheorganisateur qui comprend tous les champs du masque Tâche : opérez par copier/coller. Reportez-vous au module Fonctions avancées du masque/sous-masque Transformez les champs qui suivent pour qu ils ne soient plus modifiables mais calculés à l affichage : Body (Calculé), DateFinReelle. Reportez-vous au module Programmer avec le langage de formule/masquer un paragraphe Créez le sous-masque smtacheaffecte qui comprend tous les champs du masque Tâche : opérez par copier/coller Transformez les champs qui suivent pour qu ils ne soient plus modifiables mais calculés à l affichage : Organisateur, NomProjet, Categories, TitreTache, Affecte, DateFinPrevue, DatePublication Créez le sous-masque smtacheaffiche à partir du sous-masque smtacheaffecte : opérez par copier/coller Transformez les champs modifiables restants en champs calculés à l affichage : Body (Calculé), DateFinReelle Modifiez le masque Tâche pour que l insertion d un sous-masque tienne compte de l état du document et de l utilisateur courant Situation Nouveau document Document existant, l utilisateur est l organisateur Document existant, l utilisateur est la personne affectée Document existant, l utilisateur n est ni l organisateur, ni la personne affectée Sous-masque smtacheorganisateur smtacheorganisateur smtacheaffecte smtacheaffiche Vérifiez le résultat Remarque La technique du sous-masque permet une plus grande liberté de mise en page que les sections d accès contrôlé. Par ailleurs, dans certaines versions de Designer, les sections d accès contrôlé ne fonctionnent pas très bien. Constatez la différence avec le champ Body : s il y a une pièce attachée, les deux techniques sont identiques. S il y a des objets incorporés, des images, le résultat peut être différent à l affichage. Décidez de conserver l une des deux solutions : le masque qui appelle deux sousmasques ou le masque avec des sections. Le masque que vous conservez devra avoir comme pseudonyme mastache et être le seul à porter ce pseudonyme. Si vous conservez la première solution, vous devrez porter des modifications dans le masque et les deux sous-masques dans l atelier qui suit Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

40 Procédures Reportez-vous aux pages à 11-19, 9-16 à Exercice 6 : Etat d un document 45 mn Etapes L état du document est géré manuellement dans le champ Statut. Le masque Tâche va être modifié pour prendre en compte le fait que deux acteurs peuvent modifier le Statut. Les directives données ici ne correspondent pas exactement aux exemples donnés dans le module dans le but de créer des variantes pédagogiques. La solution proposée est loin d être la seule. Statut du document Le Statut modifiable par acteur : organisateur et employé affecté. Un champ modifiable spécifique à chacun est créé, respectivement orgstatut et empstatut. Le statut saisi par un acteur est reporté dans le champ Statut qui devient calculé à la création (donc, non modifiable directement). La liste des états proposés à l utilisateur devra dépendre de l état actuel du document. Acteur Statut courant Nouveaux statuts possibles Organisateur EA (En attente) En cours (EC) Effectuée (EF) Abandonnée (A) Publiée (PU) 1. EA (En attente) 2. En cours (EC) 5. Abandonnée (AB). 4. Publiée (PU) 5. Abandonnée (AB) 2. En cours (EC) -vide- Employé affecté En cours (EC) 2. En cours (EC) 3. Effectuée (EF) Si le Statut est EC, la DateFinReelle ne peut être renseignée et elle est vidée. La difficulté de l atelier consiste : à calculer la liste des valeurs proposées à l utilisateur courant en fonction de son rôle et de l état du document à ne montrer les boutons (Modifier) et (Enregistrer) que lorsqu ils sont utilisables à gérer par formule les listes de valeurs et les pseudonymes du Statut Affichage du statut Les valeurs possibles du statut et les pseudonymes associés sont créés sous forme de liste dans un champ calculé à l affichage. Le texte ne servira qu à l affichage et les pseudonymes seront testés dans les formules. Il faut pouvoir associer le pseudonyme à un texte. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-39

41 Créez le champ listestatut, de type Calculé à l affichage et caché. La valeur est la liste des textes et des pseudonymes "En attente EA" : "En cours EC" : "Effectuée EF" : "Publiée PU" : "Abandonnée AB" Le caractère pipe ( ) sépare texte et pseudonyme exactement comme dans le dialogue de saisie des valeurs du champ Statut. Le caractère deux-points ( : ) sépare les éléments d une liste. Modifiez le champ Statut pour que la liste de valeurs proposées vienne du champ listestatut (c est une formule très simple) Vérifiez que l affichage des valeurs proposées à l utilisateur sont inchangées et que le pseudonyme est bien enregistré dans le document Transformez le champ Statut en calculé à la création, l événement valeur contenant la valeur initiale, soit EA Le contenu de Statut sera modifié depuis l événement onsubmit. Pour le moment, il est clair que la valeur EA enregistrée dans le document doit être affichée En attente pour plus de clarté. Créez un champ Statut_D, calculé à l affichage L événement valeur du champ contient une formule qui teste le contenu de Statut et retourne le libellé correspondant qui se trouve dans le champ listestatut. Pour atteindre ce résultat, les éléments suivants sont utilisés : tests de Statut (pseudonymes) accès à un poste de listestatut par la notation listestatut[1], listestatut[2], etc. accès au libellé par la en utilisant le caractère pipe ( ) comme séparateur Testez le résultat à l affichage en créant un nouveau document Modification de Statut L organisateur et la personne affectée vont chacun saisir le statut dans des champs séparés à l intérieur de leur section. Nous allons supposer dans un premier temps que les utilisateurs sont bien élevés et qu ils ne choisiront que les valeurs licites. Le calcul des listes de valeurs licites sera effectué ensuite. Créez les deux champs modifiables orgstatut et empstatut dans les sections Manager et Affecte. La liste complète des valeurs de Statut est proposée à l utilisateur Mettez à jour Statut dans l événement onsubmit (QuerySave) du masque Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

42 L événement contient déjà le calcul des champs Auteurs. Comme ce calcul s appuie sur Statut, il faut que le statut soit calculé avant. La règle de calcul de Statut depuis les champs de saisie est très simple : Si le champ orgstatut est renseigné, alors Statut prend sa valeur Si le champ affstatut est renseigné, alors Statut prend sa valeur Sinon, rien ne se passe Le postulat est que soit orgstatut, soit affstatut est renseigné, mais pas les deux. Ceci est normalement assuré par l accès aux sections. Vérifiez le résultat : la valeur de Statut et le libellé associé Saisie d une tâche Modification du statut En cours par l organisateur Modification du Statut Effectuée par l employé affecté Modification du Statut Publiée par l organisateur Calcul des valeurs possibles de Statut La liste des valeurs possibles est maintenant calculée pour que les utilisateurs ne voient que les valeurs possibles. Une solution consiste à calculer ces listes dans des champs calculés à l affichage, puis à utiliser le nom de la liste dans la formule du champ modifiable. Champ de saisie Valeur actuelle de Statut Valeurs possibles champ de saisie orgstatut empstatut EA (En attente) En cours (EC) Effectuée (EF) Abandonnée (A) Publiée (PU) -vide- En cours (EC) 1. EA (En attente) 2. En cours (EC) 5. Abandonnée (AB). 4. Publiée (PU) 5. Abandonnée (AB) 2. En cours (EC) -vide- -vide- 2. En cours (EC) 3. Effectuée (EF) Créez deux champs calculés à l affichage listeorgstatut et listeaffstatut L événement valeur de chacune de ces listes suit la logique exposée dans le tableau. La programmation requise est du style : Condition : Statut = "EA" : "EC" Action : FIELD listeorgstatut := listestatut[1]:listestatut[2]:listestatut[5]; Masquez les champs de saisie orgstatut et affstatut lorsque les listes correspondantes sont vides Testez en utilisant le tableau ci-dessus Remarque Dans le scénario, l utilisateur choisit un Statut, ce qui équivaut à confondre le nom d une action avec l état résultant pour le document. C est une entorse aux principes énoncés précédemment. Elle est voulue pour se concentrer ici uniquement sur les aspects techniques d implantation. Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-41

43 Lorsque l utilisateur organisateur, employé affecté choisit un état suivant pour lequel il n est plus auteur, l enregistrement du document fonctionne une fois mais pas deux. Un dialogue s affiche à la seconde tentative d enregistrement. C est évidemment perturbant pour l utilisateur qui n est pas sûr de l état du document enregistré. Une solution est proposée dans l atelier qui suit. Procédures Reportez-vous aux pages à Exercice 7 : Notification, masquage de boutons, agent 45 mn Etapes Des fonctions supplémentaires sont implantées : Notifier l employé affecté lorsque la tâche arrive à l état En cours, depuis En attente ou depuis Effectuée. Un bouton est proposé à l organisateur, ou bien l opération se fait automatiquement à l enregistrement du document Masquer les boutons (Modifier), (Enregistrer), (Enregistrer et Quitter), (Marquer Public/Privé) lorsque l utilisateur n est pas Auteur du document Envoyer un message à l utilisateur lorsque le document a été enregistré et lui proposer de fermer la fenêtre pour éviter les messages perturbateurs lorsque l utilisateur n est plus auteur du document Développer un agent planifié qui calcule le nombre de jours de retard pour l affichage dans les vues Notification Créez un champ notifaffecte qui enregistre la date et heure d envoi de la notification Modifiez le bouton (Notifier) pour qu il ne s affiche pas si le message a déjà été envoyé Modifiez les règles de onsubmit pour que si le statut repasse à En cours, le bouton s affiche à nouveau Masquage de boutons Plusieurs boutons doivent être masqués avec la même formule. Pour éviter de dupliquer la formule, une solution possible est de créer un champ calculé à l affichage, numérique, qui retourne la valeur 1 ou 0 (zéro) selon qu il faut afficher un bouton ou non. Créez le champ SHB_ModEnr, numérique et calculé à l affichage Utilisez ce champ comme un booléen dans une formule de masquage!shb_modenr Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement

44 Confirmation d enregistrement Lorsque l utilisateur enregistre un document, une confirmation lui est envoyée s il n est plus auteur avec proposition de fermeture de la fenêtre. Ceci peut être codé par formule dans l événement PostSave du masque. Testez si l utilisateur courant fait partie des Auteurs du document Envoyez le message de confirmation, d explication et de demande de fermeture de la fenêtre Agent planifié Créez un agent planifié une fois par jour qui détecte les tâches en retard selon la règle Si la date de fin réelle n est pas renseignée, la date prévue est comparée à la date du jour Si la date de fin réelle est renseignée et si le retard n a pas été calculé, la date de fin réelle est comparée à la date de fin prévue L agent enregistre dans un item enretard le nombre de jours de retard Note : cet item n apparaît pas dans le masque Tâche, ce qui n empêche pas son utilisation dans les vues. Faites apparaître le nombre de jours de retard dans les vues Taches\1. Par Organisateur et Taches\2. Par Affectation Procédures Reportez-vous aux modules 10 et 6. Exercice 8 : Archivage et publication d un document 35 mn Etapes Un agent d archivage planifié déplace les documents à l état Abandonnée dans une base d archivage. Lorsque le document est à l état Publiée, il est copié dans une base de publication. L archivage et la publication utilisent le routeur de messagerie. Le nom de la base d archive et celui de la base de publication doivent être enregistrés dans le profil de la base de suivi de projets. Base d archive Créez une base Archives sur le serveur par copie de la base actuelle Créez une vue affichant tous les documents de la base catégorisés par pseudonymes de masques et affichant le titre de la tâche, et la date et l heure de dernière modification Mettez l accès par défaut de cette base à Lecteurs : les managers et les personnes ayant rédigé les documents ne peuvent pas les modifier Créez un document Base Courrier en arrivée pour cette base Vérifiez qu un document envoyé à cette base est bien distribué Modifiez le profil de la base actuelle pour que le nom de la base archive y soit enregistré Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement 11-43

45 Créez l agent planifié archivetache qui envoie les documents tâches à l état Abandonnée vers la base d archives et supprime le document de la base de Suivi de projets Remarque Il faut que l agent soit signé par un utilisateur ayant le droit de supprimer les documents dans la base Suivi de projets. Base de publication Créez une base Publications sur le serveur par copie de la base actuelle Créez une vue listant les tâches par Projet et Titre Copiez le masque Tâche de la base Suivi dans la base Publications Mettez l accès par défaut de cette base à Lecteurs : les managers et les personnes ayant rédigé les documents ne peuvent pas les modifier Créez un document Base Courrier en arrivée pour cette base Vérifiez qu un document envoyé à cette base est bien distribué Modifiez le profil de la base actuelle pour que le nom de la base Publications y soit enregistré Lorsque l organisateur passe le Statut à l état Publiée, le document est copié vers la base Publications une seule fois et la date de publication est renseignée Procédures Reportez-vous aux modules 10 et Tsoft/Eyrolles Lotus Domino Designer 6 : Bases du développement