������
������������
����������
���������������������
Les bases du développement Notes/Domino
© Tsoft et Groupe Eyrolles, 2004, ISBN : 2-212-11396-X
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
• Champs Auteurs
• Champs Lecteurs
• Section d’accès contrôlé
• Sous-masque
• Formule de masque
• Notification
• Routeur de messagerie
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.
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.
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 – SG245963 – présente en détail l’architecture de Domino Workflow. D’autres documents et une version d’évaluation sont
disponibles sur http://www.lotus.com/home.nsf/welcome/domworkflow.
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 Suivi de réunion Acteur Description
Exécutant 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.
Organisateur 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éé.
Projet Suivi de tâches Cas utilisation Description Attribuer une
tâche
L’objectif est de définir une tâche et de l’attribuer à un exécutant.
Exécuter la tâche
L’objectif est de communiquer le document qui concrétise la réalisation de la tâche.
Contrôler le travail
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().
Projet Suivi de tâches
Classe Tâche
Opération Description
Notifier() 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.
Terminer() 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.
Corriger() Actionnée par l’organisateur, sur une tâche Effectuée.
La tâche passe de l’état Effectuée à En cours.
Approuver() 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.
Abandonner() 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.
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.
Envoyer une notification à un utilisateur
Fonction @MailSend dans une formule de bouton, d’événement Sans paramètres : champ SendTo obligatoire
@MailSend
Avec paramètres : paramètre envoiA obligatoire
@MailSend(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], ...
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.
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 fonction @MailSend 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 courrier.
@MailSend 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 arrivée.
@MailSend 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.
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
Envoyer un document
L’envoi d’un document en entier se fait avec @MailSend 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 :
• 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.
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″ ;
MailOptions Bouton radio
Choix
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 : utiliser @UserRoles
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 : fonctions @ 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,
– 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
Utiliser @UserRoles
@UserRoles retourne la liste des rôles (LCA) de l’utilisateur courant. La fonction
@IsMember teste si une chaîne de caractères est membre d’une liste.
@IsMember ("[Gestionnaire]" ; @UserRoles ) ;
La fonction @IsMember retourne True si la chaîne “[Gestionnaire]” fait partie de la liste @UserRoles.
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]
Rôle apparaissant entre crochets Rôle sélectionné
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.
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
• Créer un champ de type Auteurs, calculé à la création, caché, supportant des valeurs 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 := @If ( Statut = "EA": "EC" ; Organisateur : Affecte ;
Statut = "" : "TE" : "AP" : "AB" ; Organisateur ;
AuteursDoc) ;
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.
Type Noms Modifiable
Type Auteurs Calculé à la création Autoriser entrées multiples
Formule : le nom du champ lui-même
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.
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 public
@If( @IsNull(LecteursDoc) ; "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
! ( @Contains (@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 formule
@If(@IsNull(LecteursDoc) ;
FIELD LecteursDoc := Organisateur;
FIELD LecteursDoc := Null );
@Command([RefreshHideFormulas]);
LecteursDoc reçoit le nom de l’organisateur. La commande @ 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
! ( @Contains (@UserRoles ; "[Organisateur]" ) ) Le bouton doit être visible si l’utilisateur courant a créé ce document.
• <Evénement Click> : taper la formule
LecteursAutorises := @PickList([Name]) ;
FIELD LecteursDoc := Organisateur : LecteursAutorises ;
@Command([RefreshHideFormulas]) ;
LecteursDoc reçoit le nom de l’organisateur et les noms choisis dans l’annuaire. La commande @ rafraîchit les formules de masquage des boutons.
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).
• <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 := @If ( !@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 :
@If (@IsNewDoc ; "smTacheOrganisateur" ;
@Name([CN];@UserName) = @Name([CN]; Organisateur) ; "smTacheOrganisateur" ; "smTacheAffecte" ) ;
Si le document est nouveau ou si l’utilisateur courant est l’organisateur, le sous- masque 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.
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.
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 := @If ( !@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 := @If (!@IsNull(orgStatut) ; orgStatut ; !@IsNull(empStatut) ; empStatut ; Statut) ;
FIELD Statut := @If (Statut = "EF" & DateFinPrevue < @ToDay ; "PU" ; Statut) ;
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" ;
@If ( @IsNull(notifAffecte) ; @Do(
@MailSend(Affecte;NULL;NULL;TitreTache;msg;NULL;
[IncludeDocLink] ) ;
FIELD notifAffecte := @Text(@Now)) ; @Success);
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."
+ @NewLine + "La date prévue initialement "
+ @Text(DateFinPrevue) + " est dépassée. "
+ @NewLine
+ "Merci de terminer votre travail et de mettre à jour l’information." ;
@If ( Statut = "EC" & DateFinPrevue < @ToDay ;
@MailSend(Affecte;NULL;NULL;TitreTache;msg;NULL;
[IncludeDocLink] ) ; @Success);
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 fonctions @ 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
• 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.
Vue privée
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.
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.
Type de vue
Emplacement
Modèle
Critères de sélection
Rôle sélectionné
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 := @Name([CN] ; @UserName) ;
estceOrganisateur := @Contains(@UserRoles ; "[Organisateur]") ; org := @Name([CN] ; Organisateur) ;
@If (utilCourant = org ; "masTacheOrganisateur" ;
@IsNewDoc & estceOrganisateur ; "masTacheOrganisateur" ; @IsNewDoc & !estceOrganisateur ; "masTacheErreur" ; "masTacheAffecte" )
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 travail,
– @If retourne le nom d’un masque à utiliser.
Condition Masque
Le document existe et l’utilisateur courant est l’organisateur identifié dans le document
masTacheOrganisateur Le document est nouveau et l’utilisateur a le rôle
[Organisateur]
masTacheOrganisateur Le document est nouveau et l’utilisateur n’a pas le rôle
[Organisateur]
masTacheErreur Le document existe et l’utilisateur n’a pas le rôle
[Organisateur]
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.
Archivage de documents
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
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. 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.
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 fonction @MailSend (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 fonction @DeleteDocument 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.
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.
Supprimer des documents
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.
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.
