Objectifs, contenu et structure de ce guide

La définition de base des différents concepts de modélisation de Workey est adaptée à la plupart des procédures de travail simples. Elle doit être complétée dès que les règles du processus sont plus complexes. C’est la raison pour laquelle des fonctions avancées ont été définies pour permettre au concepteur de spécifier notamment des règles concernant les domaines suivants :

les opérations et leurs enchaînements,
les rôles, les acteurs et les affectations des opérations,
les formulaires
les documents, leur contenu et leur visibilité,
les délégations.

A partir du moment où l’on peut spécifier des règles dont la combinaison peut déboucher sur des situations parfois très complexes, un module de vérification est automatiquement activé, pour s’assurer de l’exécutabilité des procédures et, le cas échéant, évaluer les risques de blocage.
La présentation des fonctions avancées est structurée en fonction des domaines ci-dessus. L’utilisation des fonctions avancées est illustrée part de nombreux exemples pour lesquels, chaque fois que cela est pertinent, l’incidence du choix du concepteur sur l’application générée et l’interface utilisateur (Web) est présentée en détail.

Types d´opérations et enchaînement

On peut distinguer deux types d’opérations:

les opérations séquentielles: elles sont affectées à un seul rôle et s’enchaînent suivant les états spécifiés en entrée et en sortie,
les opérations parallèles: elles sont effectuées en parallèle par plusieurs acteurs, et se terminent quand tous les acteurs sont intervenus.

Les opérations séquentielles

Une opération séquentielle laisse un document dans un état donné. Depuis cet état, une autre opération peut à son tour être effectuée, constituant ainsi une séquence d’opérations.

Contexte d’exécution

Une opération séquentielle peut se dérouler dans plusieurs types de contexte d’exécution.

un seul type de document, dans l’état “Nouveau”, en entrée de l’opération: l’opération permet de créer un nouveau document du type spécifié en entrée,
un seul type de document en entrée de l’opération: l’opération ne peut être effectuée que sur un document dans l’état spécifié,
une condition “OU” figure au-dessus de l’opération: plusieurs types et états de document permettent d’effectuer l’opération,
une condition “ET” figure au-dessus de l’opération: l’opération ne peut s’effectuer que si une ou plusieurs règles de synchronisation sont respectées.

Contexte de sortie

Le résultat d’une opération peut également prendre plusieurs formes, plus ou moins complexes suivant ce qu’il est nécessaire d’exprimer.

un seul type de document en sortie de l’opération: le résultat de l’opération est de mettre le document en sortie dans l’état spécifié,
une condition “OU” figure en dessous de l’opération: plusieurs états de document sont possibles en sortie de l’opération, le choix d’un état sera effectué soit par l’acteur effectuant l’opération, soit par une règle automatique,
une condition “ET” figure en dessous de l’opération: un ou plusieurs documents seront créés en résultat de l’opération, donnant lieu à autant de sous-processus (ou documents dérivés).

Exemples

*L’opération crée un nouveau document:

*L’opération modifie l’état d’un document existant:

*L’opération peut s’effectuer sur un document possédant l’un ou l’autre des états:

L’opération peut s’effectuer sur un document dans un état donné,mais seulement si un autre document a atteint un état donné dans son parcours de vie(synchronisation):

*L’opération peut modifier l’état du document dans un des états spécifiés:

L’opération crée une instance d’un autre type de document (lancement de sous-processus).

(Dérivation d’un document fils)

Les opérations parallèles

Une opération parallèle est une opération effectuée par plusieurs intervenants qui interviennent sans ordre pré-établi, donc de manière non séquentielle.

Une opération parallèle comprend donc plusieurs opérations simples, affectées chacune à un rôle différent. Comme une opération séquentielle, elle est exécutable depuis un ou plusieurs types de document dans un état donné, et produit en sortie un type de document dans un état donné. Cet état ne sera atteint que lorsque toutes les opérations prévues dans le cadre de l’opération parallèle ont été effectuées.

Par exemple:
L’opération parallèle (image ci-dessous) comprend deux opérations simples:Valider (effectuée par les acteurs du rôle “Resp technique”,Définir paramètres techniques (effectuée par les acteurs du rôle “technicien”)L’opération est exécutable depuis un document du type “fiche d’actions” dans un état “éditée” et change l’état de ce document en “validé” lorque les deux opérations ont été effectuées.

Ajout d’une opération dans une opération parallèle

Pour ajouter une opération dans une opération parallèle, glisser déposer le composant “opération” dans le cadre de l’opération paralléle et pour la colonne du rôle en charge de l’opération.

Les propriétés d’une opération au sein d’une opération paralléle

En éditant une opération, il est possible de renseigner des propriétés pour compléter le comportement attendu de cette opération. En plus des propriétés standards d’une opération, l’opération au sein d’une opération paralléle dispose d’une propriété supplémentaire : Le formulaire. Vous pouvez ainsi préciser pour chaque opération un formulaire distinct.

Opération avec règles de contrainte

Le lien de sortie d’une opération vers un document dans un état donné peut être assorti d’une règle, spécifiant la condition nécessaire pour la sélection de cet état. La propriété

du lien permet de spécifier une règle.
Il est ensuite possible de choisir un graphe de règles existant ou d’en créer un nouveau. Consulter le point traitant de la modélisation des règles dans cette documentation.

Opération automatique

Une opération prévoyant plusieurs états en sortie peut être déclarée automatique si des règles d’évaluation ont été définies.Pour spécifier une opération automatique, choisir la propriété “Automatique”.Cette propriété est présente si et seulement si une pré-condition OU est précisée en sortie de l’opération.

Dans ce cas, les règles de sélection de chacun des états possibles seront analysées dans leur ordre de priorité. La première règle présentant une évaluation positive sera retenue et l’état correspondant sera sélectionné. Si aucune des règles n’est retenue, l’état ne comportant pas de règle, s’il existe, est retenu.

Une conséquence de ce comportement est qu’il n’est pas possible dans le cas d’une opération automatique de laisser plus d’une branche de sélection d’état sans règle à évaluer (Workey ne saurait pas comment choisir l’état).

Il est par contre tout à fait possible de spécifier une règle pour tous les états: dans ce cas, on peut se trouver dans la situation où aucune des règles n’est satisfaite au moment de soumettre le document. Si c’est le cas, l’utilisateur, averti de l’échec de la vérification, peut modifier les données du document en cours et tenter une nouvelle soumission. Il peut également sauvegarder le document sous forme de brouillon et effectuer les corrections nécessaires plus tard.

Règles de création de sous-processus (ou documents dérivés)

Dérivation automatique

Lorsque dans un modèle d’opérations, une opération est suivie d’une post-condition de type ET et qu’elle produit un document différent de celui qui est spécifié en entrée, on parle de “dérivation“. Cette situation est illustrée par l’exemple ci-contre.
L’opération “Editer un plan d’actions” s’effectue sur des documents du type “Réclamation client” marqués “pour action”. Le document “Réclamation client” est le “principal” dans cette opération. Cette opération aura deux effets:le changement d’état du document principal en “en attente de TT” la création d’un nouveau document de type “Fiche d’action”, qui est le document “dérivé” par cet opération.
Le document dérivé démarre un sous-processus, en accord avec les règles modélisées pour ce type de document.

Héritage des informations

Lors de la dérivation, les valeurs des champs du document principal sont automatiquement copiées dans les champs portant le même nom dans le document dérivé.

Pour supprimer cet automatisme, décocher la case “Peut hériter sa valeur” dans le champ du document dérivé:

Propriétés d’une dérivation

La dérivation de documents est un élément modélisable.Les propriétés du lien de dérivation sont présentées ci-contre :

Cette option est celle par défaut, elle est automatiquement renseignée par Workey en fonction de l’environnement de la dérivation.

Dans ce cas, la dérivation de nouveaux documents est automatiquement assurée par Workey lors de la réalisation de l’opération.

Les options possibles dans ce cas sont:

au choix de l’utilisateur: l’utilisateur pourra décider si le ou les documents dérivés seront effectivement créés,

(par défaut, dérivation: cocher cette case si le choix par défaut présenté à l'utilisateur sera la création de document)

un document pour chaque acteur: un document dérivé sera créé pour chaque acteur sélectionné,
démarre un nouveau processus: si cette case est cochée, les documents dérivés seront considérés comme des nouveaux processus, et non plus comme des sous-processus, ce qui implique qu’aucun lien de filiation ne sera enregistré entre le document principal et les documents dérivés.

Dérivation manuelle par une vue embarquée

Définitions

Une vue embarquée est une vue visible dans un document, donc comme “embarquée” dans ce document. C’est une vue qui permet de créer des documents fils à partir d’un formulaire et de montrer des documents créés à partir de ce document de référence.

A la différence d’une vue autonome, une vue embarquée doit être créée dans un formulaire attaché à un document. La même vue peut apparaître dans plusieurs formulaires du même type de document, elle devient de ce fait visible par les utilisateurs accédant par ces formulaires.
De plus, la création de documents via une vue embarquée doit être spécifiée dans le modèle d’opérations, pour préciser à quel étape du flux, et donc à travers quel rôle, pourront être créés ces documents.

Lors de la création du lien depuis le document vers la vue embarquée, Workey vérifie si la vue est bien présente dans un formulaire attaché au document.

La modélisation d’une vue embarquée comporte donc trois phases:

la création de la vue depuis “Vue embarquée” dans l’arborescence du projet

la création de la vue dans le modèle conceptuel, afin de spécifier les états du document pére permettant la création du document fils

l’association de la vue dans le ou les formulaire(s)

Ce chapitre décrit la manière de spécifier l´utilisation des vues embarquées pour créer des documents dans le cours d´un processus. Une vue embarquée étant définie dans un formulaire, il reste en effet à préciser à quel(s) moment(s) du déroulement d´un processus les intervenants autorisés pourront créer des documents au moyen de cette vue embarquée, et quel sera le type des documents ainsi dérivés.

Rappel sur les vues embarquées

Il est nécessaire de rappeler qu´une vue embarquée est une vue au sens Workey, c´est à dire la spécification d´un ensemble de champs (les colonnes de la vue) qui sont évalués pour un ensemble de documents sélectionnés (les lignes de la vue). Une vue embarquée est définie dans un l’arborescence du projet, et associée à un formulaire, qui précise la mise en page de cette vue dans l´espace visible du document.

Accessibilité d´une vue embarquée

Un formulaire pouvant être attaché à un ou plusieurs types de document, un vue embarquée dans un formulaire est ainsi accessible pour tous les types de document utilisant ce formulaire.

Documents présentés

Une vue embarquée présente uniquement les documents créés depuis le document courant, s´ils sont du type précisé dans les conditions d´utilisation de la vue.

Modélisation

Dans un graphe de type procédure, ajoutez un Composant puis liez l’objet en sortie d’un document et en entrée d’un ou plusieurs autre documents.

La sémantique exacte exprimée par cet exemple est la suivante : depuis un document de type « Demande d’intervention » dans un état « pour action », il est possible de créer, par la vue nommée « Création de plan d’actions» des documents de type « plan d’actions» dans un état initial « éditée ».

Propriétés d’une vue embarquée:

Libellé : Permet de saisir un nom visible pour le vue

Nom interne : Attribut Designer_name de l’objet (Ce nom doit être unique)

Nom interne calculé automatiquement : Permet de garantir l’unicité des noms interne d’objets en laissant Workey les définir

Max Docs : Défini le nombre de documents dérivés qu’il sera possible pour l’utilisateur de créer à partir de la vue.

Doc dérivé : Spécifie le type de document à créer. Le document doit être existant dans la modélisation.

Description : Permet de saisir un texte de description pour la vue

Aide : Permet d’entrer un texte d’aide
Il est aussi possible d’ajouter des liens logiques aux objets Vue embarquée.

Définir la vue embarquée

Une fois la vue embarquée positionnée dans la procédure, il faut définir son contenu.
Pour ce faire, maintenir la touche ctrl et double-cliquez sur le composant ou sélectionnez le et cliquez sur le bouton “Graphe Zoom” du menu

Vous pourrez ainsi définir votre vue embarquée telle qu’elle sera présentée dans le formulaire

Insertion d’une vue embarquée dans un formulaire

Dans un formulaire, ajoutez le composant “vue embarquée” .

Il n’est pas possible de modifier manuellement les colonnes d’une vue embarquée dans un formulaire ni dans le graphe, seulement dans l’arborescence du projet.
Le formulaire prévoit l’emplacement de la vue et l’objet est entièrement créé entre la procédure et l’emplacement dédié dans les vues embarquées.

Règles de synchronisation

Principe

Une synchronisation est une règle spécifiant qu’une opération ne peut s’exécuter que si des documents dérivés du document principal ont atteint ou sont passés par un état donné.

Dans cet exemple, l’opération “Cloturer la demande” est soumise à une synchronisation avec les documents du type “Bon de commande”, qui sont créés par dérivation depuis un document “Demande d’achat” plus en amont dans le déroulement du processus.

L’opération ne pourra s’effectuer que si tous les documents dérivés de type “Bon de commande”, créés depuis la “Demande d’achat”, sont au moins passés une fois pas l’état “action OK” (ils peuvent se trouver maintenant dans un autre état).

Dans certaines modélisations, il peut se trouver qu’il n’y ait aucun document dérivé créé (cas d’un dérivation optionnelle, par exemple). Dans cette situation, la régle de synchronisation est considérée comme vérifiée: l’opération pourra s’exécuter.

Cas de plusieurs synchronisations

Une opération peut être mise en attente de plusieurs synchronisations. Dans ce cas, l’interprétation est que la satisfaction d’une seule de ces synchronisations suffit à rendre exécutable l’opération (interprétation de type “OU”).

Plus généralement, une synchronisation peut intervenir entre deux documents ayant un ancêtre commun. Ceci couvre donc les cas de synchronisation d’un document “père” avec ses “petits-fils”, ou l’inverse, de documents “cousins”, etc…

Synchronisation des données

Lors de la synchronisation, c’est à dire au moment où le document attendu par l’opération atteint l’état requis, les champs de ce document peuvent venir compléter les champs de même nom présent dans le document en attente de la synchronisation.

Pour activer cette synchronisation des champs, cocher la case “Synchronisé” des champs pour lesquels elle est désirée:

Gestion des délais

Principe

Il est possible avec Workey de spécifier à partir d’une opération quelle est l’action à entreprendre en cas de dépassement d’un délai fixé par le concepteur. Un dépassement de délai permet:

de positionner un document dans un état déjà présent dans le parcours du processus,
de positionner un document dans un état spécialement prévu pour un dépassement de délai,
de créer un nouveau document.

Modélisation

Sélectionner le type de lien “délai” parmi la liste des liens du panneau de droite.faire partir le lien “délai” depuis l’opération soumise au délai et pointer sur un document/etat.

*Pour éditer les propriétés de la gestion de délai, cliquer sur le lien précedement modélisé.

Choix de l’unité de temps:

Une unité de temps est nécessaire pour le calcul des délais (Jour ou Heure).

Toutes les durées exprimées dans la gestion de délais seront supposées exprimées dans cette unité de temps.

Changement automatique de l’état du document

La date à laquelle le document sera mis dans l’état spécifié peut être spécifiée de deux manières différentes:

Après un nombre spécifié d’unité de temps:

le délai (N) est fourni en nombre de jours ou d’heures, suivant l’unité de temps choisi.

Détermination de la date à partir de laquelle court le délai

Cette date peut être renseignée de deux manières

date de la dernière opération
date à laquelle le document a atteint un état spécifié

cette option permet par exemple de spécifier par exemple que le délai court depuis la création du document

A la date lue dans un champ spécifié

une liste de champs disponibles est affichée pour le choix de ce champ (en cochant la case “champs de type date seulement”, seuls les champs de ce type sont présentés)

Avertissements (éventuels)

Avant la date de mise autoritaire du document concerné par la gestion des délais dans l’état spécifié, un certain nombre d’avertissements peut éventuellement être adressé au personnel en charge de l’opération concernée. Jusqu’à 3 avertissements peuvent être prévus, en indiquant pour chacun le nombre d’unités de temps avant la date de changement d’état.

Personnalisation du corps des messages

Les mails sont construits sous forme de Messages MIME multipart. L’encodage des caractères dans le sujet du mail et dans le corps du message peut être spécifié à l’aide de la propriété com.clog.workey.engine.NotificationSender.mailCharset (lorsque cette propriété n’est pas présente, la valeur par défaut est utf-8).
Lorsque l’identité utilisé pour l’envoi de notification email est SERVER, alors le PERSONAL (l’identité apparente dans l’entête du mail) sera celui renseigné avec la propriété com.clog.workey.engine.NotificationSender.mailerName.

Les messages envoyés automatiquement par la gestion des délais peuvent être personnalisés.

Les boutons “Codifier le message d’avertissement” et “Codifier le message de survenance” permettent de saisir des formules exprimées en script STalk, le résultat de l’exécution de ces formules venant remplacer le texte du corps de ces messages (par défaut, le corps du message est le sujet du document).

Modélisation d’opérations réalisables depuis tout état d’un document

Une opération peut être modélisée comme étant réalisable depuis n’importe quel état d’un document.

Déclaration de “tout état”

Dans le dialogue de création/modification d’une instance de document, il est possible de choisir “<Tout état>” comme nom de l’état.

Conséquence dans le flux de travail

La conséquence de la modélisation “tout état” est que la ou les opérations concernées (en sortie de cet état particulier) seront proposées tout au long du parcours de vie du document à tous les acteurs jouant le rôle adéquat.

Gel et destruction de documents

l’état générique “<Détruit>” utilisé en sortie d’une opération permet de modéliser la destruction volontaire d’un document par un acteur.
l’état générique “<Gelé>” utilisé en sortie d’une opération permet de modéliser le gel volontaire d’un document par un acteur.

Destruction de documents dans le workflow

La possibilité pour les utilisateurs de détruire des documents participant au Workflow a été intégrée de la même manière que toute autre opération : elle est entièrement modélisable.

Destruction manuelle

Un état de document générique : <Détruit> figure dans la liste des
états possibles pour tout type de document, et peut donc être sélectionné en sortie d´une opération quelconque :

Naturellement, plusieurs opérations de destruction de document peuvent être spécifiées, et il peut s´avérer commode de grouper toutes les possibilités de destruction d´un processus dans un seul graphe « Destruction de documents » .

Lors de la génération des règles de flux, la règle suivante est vérifiée :

L´état <Détruit> doit être un état terminal

Dans l´application web, la sélection de cet état par l´utilisateur entraîne la destruction du document:

Destruction automatisée

Le document en fin de vie sera détruit à une date calculée par une règle. Par exemple, 15 jours ouvrables après la date de la dernière opération, ou bien encore, au 31 décembre de l´année suivant son année de création. Naturellement, cette règle peut varier en fonction du contenu du document. Elle est spécifique au métier abordé par le processus.

La modélisation de cette destruction différée est le meilleur outil pour maîtriser le volume de documents présents dans le système, tout en offrant aux utilisateurs une possibilité de consulter directement les documents en fin de vie pendant une durée jugée opérationnellement utile.

Elle peut prendre deux formes :

Une opération de destruction spécifique à un type de document confiée à un rôle agent dans le processus

Dans cet exemple, la règle « statut clos » pourra spécifier la condition qui doit être vérifiéepour qu´un document de ce type puisse être détruit.

Un processus particulier dans lequel un agent utilise
un connecteur pour détruire un ensemble
de documents, apparaissant éventuellement
dans d´autres processus.
Ceci est modélisable dans les propriétés du document à détruire.

Dans cet exemple, l´outil « Terminator » est un connecteur Java chargé de la destruction des documents, suivant des règles embarquées dans le code de ce connecteur.

Destruction après Archivage

L’outil Workey Archiver se charge de détruire les documents qui ont été archivés automatiquement.

Groupage et dégroupage de documents

La fonction de groupage/dégroupage permet de regrouper des documents afin de leur faire suivre un même flux.

Cette fonction est activée à la création d’une vue permettant d’afficher les éléments groupables.

Document groupe : Est nommé document groupe, le document qui contiendra les documents groupés

Documents groupés : Sont nommés documents groupés, les documents contenu dans le document groupe

Construction de la vue

Double-cliquer sur Vues dans le panneau des projets pour créer une nouvelle vue.

Cette vue filtre les types de document dits “groupables” par le choix de la collection initiale : type de document.
En spécifiant le ou les états de document, le filtre sera plus efficace.

Opération annulable

Définir l´annulation d´une opération et les conditions pour effectuer cette annulation.

Annulation : L´annulation d´une opération consiste à remettre le document dans l´état qui précédait l´opération annulée. Les documents dérivés qui auraient pu être créés par l´opération annulée sont détruits.

Annulabilité : Une opération est annulable si le concepteur du processus a spécifié son annulabilité (voir ci-après). Par défaut, une opération n´est pas annulable.

Historique : L´annulation d´une opération est une opération comme une autre, et sa trace est donc enregistrée dans l´historique du document. La trace de l´opération annulée ne persiste pas dans l´historique du document. Cette dernière est donc supprimée de l´historique.

Droit d´annulation : L´annulation d´une opération ne peut être effectuée que par l´utilisateur qui a effectué cette opération.

Reversibilité des données : lors de l’annulation d’une opération, les données sont conservées dans leurs états. Les modifications sur les données ne seront pas annulées.

Spécification

Objectif : Montrer la manière de spécifier l´annulation d´une opération.

Boîte de dialogue

Pour spécifier le caractère annulable d´une opération, lancer la création ou l´édition d´une opération, et cocher la case adéquate.

Utilisation

Objectif

Énoncer les conditions d´annulation et illustrer un cas d´annulation dans l´exécution d´un processus.

Visibilité

Dans l´application Web, l´annulation de l´opération apparaîtra comme une opération supplémentaire à disposition :

La possibilité d´annuler l´opération ne sera pas montrée si celle-ci n´est pas réalisable :car le document a évolué vers d´autres états que celui immédiatement atteint après l´opération annulablecar des documents dérivés, créés par l´opération annulable, ont évolué vers d´autres états que leur état primitif lors de leur dérivationcar le document est ouvert par un acteur différent de celui qui a effectué l´opération annulable.
Lors de l´annulation d´un document, ce dernier est replacé dans l´état précédent, mais il est réaffecté à l´ensemble des acteurs du rôle. certes les contraintes sont recalculées mais les sélections d´acteurs des opérations précédentes ne seront pas prise en compte.
Lors de l´annulation d´un document, les données ne sont pas restituées à leurs valeurs d’origines.

Rôles, acteurs et affectation des opérations

Un acteur peut jouer un ou plusieurs rôles. Un acteur disposant de plusieurs rôles peut réaliser toutes les opérations de ces rôles.

L’affectation des rôles aux acteurs est fondamentale pour le bon fonctionnement de l’application.

Dans les graphes d’opérations, les rôles sont placés en tête de page. Les marques de séparations entre les rôles( en pointillé) sont automatiquement créées. Les opérations situées dans la colonne d’un rôle sont déclarées pouvoir être réalisées uniquement par des acteurs de ce rôle. Il résulte de cette définition que :

tous les acteurs d’un rôle sont interchangeables : ils peuvent réaliser toutes les opérations affectées à ce rôle sur n’importe quel document.
tous les documents traitables par un rôle figurent dans l’espace de travail (et sont traitables) de tous les acteurs de ce rôle.

Un rôle est un ensemble de responsabilités confiées à un ou plusieurs acteurs (personnes physiques ou agents).

Un acteur peut jouer un ou plusieurs rôles. Un acteur disposant de plusieurs rôles peut réaliser toutes les opérations de ces rôles.

Cette gestion utilisant exclusivement les rôles ne tient pas compte de la structure administrative de l’entreprise, qui intervient dans des règles de gestion telles que:

seul le créateur d’un document a le droit de le modifier lorsque celui est dans l’état “à corriger”,
c’est au traducteur d’un document de décider qui sera (parmi les acteurs du rôle “réviseur”) la personne qui révisera le document,
un acteur du rôle “demandeur” est forcément acteur du rôle “chef de service”,
un acteur du rôle “contrôleur” ne peut pas être acteur du rôle “directeur”,
un acteur de “service commercial” doit faire signer sa demande par son chef de service.

Les fonctions avancées permettent au concepteur de spécifier des règles de ce type. La définition de contraintes entre opérations portant sur les acteurs permettent d’exprimer les deux premières règles, les notions de sélection d’acteurs et de notifications couvrent les cas illustrés par la troisième règle, les deux suivantes sont implémentées grâce aux graphes d’interdépendance entre rôles, enfin la dernière est gérée par la gestion des règles de hiérarchie et de contraintes entre opérations portant sur les unités.Ces différentes fonctions avancées permettent de spécifier des règles de gestion parfois complexes. Elles doivent être utilisées en connaissance de cause dans la mesure où elles peuvent aisément mener à des blocages dans l’exécution du Workflow.

Le cas le plus fréquent est la combinaison de contraintes d’interdiction et de sélection d’acteurs menant à des situation telles qu’un document ne peut plus être traité par aucun acteur. Le gestionnaire de la base, pourra cependant à tout instant débloquer de telles situations.

Le mode de définition des contraintes organisationnelles

Afin de ne pas surcharger le modèle d’opérations, Workey permet de se placer dans un plan différent, qui permet de visualiser uniquement les rôles et les opérations. Dans ce plan, il n’est pas permis pas de créer de nouveaux objets ni de les déplacer. Par contre, les liens permettant d’exprimer des contraintes y sont autorisés.

Par exemple, soit le modèle d’opérations suivant:

Pour passer dans le plan “Contraintes”,cliquer sur l’icône

.
ainsi le modèle suivant apparaît :

Pour revenir dans le plan initial, il vous suffit de cliquer à nouveau sur l’icône

A partir du plan Contraintes, vous pouvez exprimer des contraintes portant sur les opérations afin de préciser par exemple les règles suivantes:

seul le créateur d’un document a le droit de le modifier lorsque celui est dans l’état “à corriger”,
même s’il joue les deux rôles, un acteur ne peut pas être à la fois l’auteur et le contrôleur d’un document,
un acteur du rôle demandeur appartenant au service commercial doit faire contrôler sa demande par le chef de service de son unité.

Le calcul des autorisations d´accès à la modification des documents et à leur avancement dans le flux de travail s´effectue en premier lieu dans Workey au moyen du concept de rôle: seuls les acteurs jouant le rôle voulu peuvent effectuer une opération sur un document dans un état donné. Le concept de contrainte organisationnelle permet d´affiner ce mécanisme en prenant en compte l´appartenance des acteurs aux unités organisationnelles: parmi les acteurs jouant le rôle voulu, seuls ceux appartenant à des unités bien spécifiées seront autorisés à effectuer l´opération. Ce mécanisme ne remplace donc pas celui basé sur les rôles, mais le complète et l´affine. Il est basé sur la modélisation des unités et de leur liens de dépendance.

Pour spécifier une contrainte entre deux opérations, il faut lier ces deux opérations.

Une contrainte organisationnelle entre deux opérations “A” et “B” du cycle de vie étendu d´un document exprime que l´ensemble des acteurs pouvant effectuer l´opération “B” dépend de l´acteur particulier ayant effectué l´opération “A”. Cette dépendance est définie par une contrainte faisant intervenir les unités organisationnelles, d´où le nom de contrainte organisationnelle.

Une contrainte est une liaison orientée, et n’exprime donc pas la même sémantique suivant l’origine et le destination du lien.

Si “Acteur A” désigne l’acteur ayant effectué l’opération “A”, et “Acteur B” un acteur autorisé à effectuer l’opération “B”, il est possible de spécifier une des contraintes suivantes:

“Acteur B” doit être uniquement “Acteur A” (c´est le même acteur qui fait les deux opérations),
“Acteur B” ne peut pas être “Acteur A” (le même acteur ne peut pas effectuer les deux opérations),
“Acteur B” doit appartenir à une des unités auxquelles appartient “Acteur A”,
“Acteur B” doit appartenir à une unité hiérarchiquement supérieure (ou inférieure) aux unités auxquelles appartient “Acteur A”.

Les deux premiers cas montrent que la définition de l´ensemble des acteurs autorisés peut soit s´opérer “en positif” (en spécifiant l´ensemble des possibles) ou en “négatif” (en spécifiant l´ensemble des exclus).

Dans les deux derniers cas, il est possible de spécifier le nombre de niveaux hiérarchiques pouvant être parcourus (1,2, ou N), un nombre négatif désignant un niveau hiérarchique inférieur.

Par exemple, une contrainte portant sur un intervalle [-1, +2] signifie que l’unité de “Acteur B” doit être soit, d’un niveau immédiatement inférieur à l’unité de “Acteur A”, soit égal, soit supérieur de 1 ou 2 niveaux.

Il est également possible de spécifier directement l´ensemble des acteurs possibles pour une opération en indiquant dans le document lui-même l´unité ou les unités autorisées. Un champ du document est désigné pour être renseigné sur le choix d´une ou plusieurs unités, lors des opérations précédentes.

Dans le cas de contrainte (d´acteur ou d´unité), si Workey n´arrive pas à affecter un document, le document sera automatiquement affecté au Process Manager. Dans le cas où aucun Process Manager ne serait défini, le document sera affecté au Workflow Manager.

Contraintes entre opérations portant sur les acteurs

Définitions

Il existe deux types de contraintes entre opérations:

les contraintes d’obligation,
les contraintes d’interdiction.

Obligation: opération 1 “oblige” opération 2 signifie que, pour un document donné, l’acteur y ayant réalisé l’opération 1 fera partie des acteurs seuls autorisés à y réaliser l’opération 2.

Interdiction: opération 1 “interdit” opération 2 signifie que pour un document donné, l’acteur y ayant réalisé l’opération 1 n’aura pas le droit d’y réaliser l’opération 2.

Modélisation d’une contrainte d’acteurs

Pour modéliser une contrainte, il faut d’abord se placer dans le plan “Contraintes” du modèle d’opérations. Ensuite, à partir d’une opération donnée, il faut définir quelles sont les opérations “obligées” ou “interdites” selon la définition ci-dessus, en liant cette opération aux opérations concernées.

Deux objets et deux types de lien sont disponibles dans les Composants d’un modèle de contraintes.

Champ : Permet de définir un champ existant sur la valeur duquel portera la contrainte, ou d’en créer un nouveau.

Opération externe : Permet de définir une opération existante dans une autre procédure dont le traitement conditionnera la contrainte.
Restriction : Restreint l’exécution de l’opération à un acteur précis ou une unité d’acteurs.

Interdiction : Interdit l’exécution de l’opération à un acteur précis ou une unité d’acteurs.

Dans notre exemple nous souhaitons exprimer la contrainte suivante :

C'est le même acteur du rôle Responsable support qui créé les fiches d'actions et qui clôture la fiche d'incidents.

Pour exprimer cette contrainte vous devez effectuer les actions suivantes :

dans la zone type de lien : choisir l’objet “Restriction”,
dans les propriétés du Lien de restriction, choisir l’option “Acteur” dans la section Général.

Dans notre exemple nous souhaitons maintenant exprimer la contrainte suivante :

Si un acteur joue le rôle Support, il ne peut pas traiter une action et aussi la valider.

Pour exprimer cette contrainte vous devez relier les deux opérations traiter l’action et valider puis effectuer les actions suivantes :

dans la zone type de lien : l’objet “Interdiction”,
dans les propriétés du Lien d’interdiction, choisir l’option “Acteur” dans la section Général

Portée de la contrainte

Une contrainte telle que décrite ci-dessus est définie localement dans la procédure: on ne pourra obliger ou interdire que les opérations de la même procédure.Pour exprimer des contraintes portant sur des opérations présentes dans d’autres procédures, dans l’ensemble du projet, vous devez surcharger le modèle en intégrant des opérations “externes” provenant d’autres procédures.

Ajoutez un objet opération externe dans la colonne de l’opération concernée.

Choisissez la procédure contenant l’opération et l’opération en question.

Une fois l’opération externe présente dans le graphe vous pouvez exprimer les contraintes organisationnelles comme précédemment. Pour spécifier par exemple que le représentant de la Hot line qui a déclaré un incident doit être celui qui valide la fiche d’actions correspondante, ajoutez l’opération externe “déclarer“, puis liez-la à l’opération “valider” avec un lien de restriction.A partir des contraintes déclarées par le concepteur, Workey déduit logiquement par symétrie ou transitivité toutes les autres contraintes que l’on peut en déduire.

On notera la présence d’un icône en bas à droite de l’objet Opération venant d’être lié

. Cette icône sera affichée tant qu’au moins 1 lien de restriction ou d’interdiction entrera sur l’opération.

Impact au niveau de l’utilisation de l’application

Pour l’utilisateur de l’application générée, la présence de contraintes d’interdiction ou d’obligation entre opérations est parfaitement transparente.

Lorsqu’il est le seul à pouvoir réaliser une opération sur un document donné (généralement à cause d’une contrainte d’obligation) l’icône en regard du document dans la vue l’en informe. Lorsqu’en raison d’une contrainte d’interdiction il ne peut réaliser une opération donnée sur un document, celui-ci n’apparaît tout simplement pas dans sa liste de documents à traiter.

Contraintes entre opérations portant sur les unités organisationnelles

Les contraintes organisationnelles portant sur les unités permettent d’exprimer des règles de type :

la note de frais d’un acteur appartenant à l’unité “Département des ventes” doit être contrôlée par l’acteur jouant le rôle de Contrôleur mais faisant partie de la même unité organisationnelle que celui-ci,
une demande d’achat doit être validée par son supérieur hiérarchique, puis approuvée par le niveau N+2.

Ce mécanisme vient en complément du mécanisme de rôle et du mécanisme de contraintes portant sur les acteurs.

Modélisation d’une contrainte d’unité organisationnelle

Modéliser une contrainte consiste à de placer d’abord dans le plan “Contraintes” .

Ensuite, à partir d’une opération donnée, lier cette opération aux autres opérations concernées par ces règles hiérarchiques.

Après la création du lien, choisissez l’option “Unités” dans la section Général, puis ajustez le niveau hiérarchique désiré de l’unité.

Tout comme une contrainte d’obligation ou d’interdiction, les contraintes hiérarchiques peuvent être définies localement dans la procédure ou globalement pour l’ensemble du projet.

Impact sur l’utilisation de l’application

Pour l’utilisateur de l’application générée, la présence de contraintes hiérarchiques entre opérations est parfaitement transparente. En mode client Web, les droits d’accès aux opérations sont calculés automatiquement en fonction des contraintes et des unités organisationnelles.

Lorsqu’il est le seul à pouvoir réaliser une opération sur un document donné l’icône en regard du document dans la vue l’en informe. Si un acteur ne peut réaliser une opération donnée sur un document, celui-ci n’apparaît tout simplement pas dans sa liste de documents à traiter.

Calcul dynamique des unités et des acteurs (contrainte sur valeur de champ)

Principe

La liste des acteurs ou des unités éligibles pour opérer sur un document donné est calculée par Workey en fonction des règles exprimées dans le modèle :

règles portant sur les acteurs,
règles portant sur les unités.

Il est parfois intéressant de calculer cette liste dynamiquement en fonction de champs présents dans le formulaire.Par exemple, un acteur précise dans le formulaire quel est le département chargé de prendre en compte son document. Dans ce cas, Workey utilise cette information comme une nouvelle contrainte lui permettant de calculer cette liste d’acteurs éligibles.Ce mécanisme s’appliquant aussi bien pour les acteurs que pour les unités, il est ainsi possible de préciser, en renseignant un champ du document, quel acteur peut prendre en compte le document pour une opération donnée.

Calcul automatique de l’unité

Workey offre la possibilité de spécifier directement l´ensemble des acteurs possibles pour une opération en indiquant dans le document lui-même l´unité ou les unités autorisées.

Par exemple, dans un formulaire, un champ peut être réservé , soit pour saisir directement le nom d’une unité, soit pour retourner par le résultat d’un script le nom d’une unité. Ce champ doit naturellement être renseigné avant l’opération concernée par la contrainte.

Pour préciser ce type de mécanisme, vous devez rester dans le plan “Contraintes” d’un modèle d’opérations.

Soit le modèle suivant :

Pour préciser que l’opération “Préparer paiement”, affectée au rôle “Aide comptable”, doit être réalisée par les acteurs de ce rôle, mais appartenant également à une unité organisationnelle précisée dans un champ du formulaire, vous devez insérer le champ dans le modèle, en utilisant le menu “Créer” et l’item “Champ”.

Par exemple, le champ “DEPARTEMENT” pourra être créé, avec un domaine de valeurs proposant une liste d’unités.

Par exemple, le service France qui dépend du Département Ventes, qui dépend lui-même de la Direction Générale, s´écrit :

ou=Service France,ou=Département Ventes,ou=Direction Générale.

Pour préciser ensuite la règle organisationnelle, lier le champ “DEPARTEMENT” et l’opération “Préparer paiement”.

Dans la boîte de dialogue, préciser ensuite le type de contrainte, dans cet exemple :

type : Restriction
portée de la contrainte, l’unité “0” à+ “0”.

Cela signifie que l’on retiendra uniquement les acteurs du rôle appartenant à l’unité retournée par le champ DEPARTEMENT.

Exemple

Un formulaire de “Demande d’achat” comporte un champ “NATURE”. Ce champ pssède une domaine de valeurs “logiciel” ou matériel”.
En fonction de la nature renseignée pour l’achat, logiciel ou matériel, il doit être géré par le service informatique ou le service logistique, respectivement.

L’opération “Approuver” est contrainte par le champ “NATURE”.

Au niveau de l’Organigramme, il suffit maintenant de créer deux unités :

Il n’est pas nécessaire dans ce cas, de préciser le type d’unité (direction, service) ni même un lien de hiérarchie.

Calcul automatique de l’acteur

Le principe est identique à celui précisé pour une unité. La différence est que la portée de la contrainte précisée dans la boite de dialogue doit être renseignée à “Acteur”. Le champ utilisé pour exprimer la contrainte doit quant à lui retourner un nom d’acteur (distinguished name dans le ldap).

Le nom de l’acteur doit être présent dans le Ldap (distinguished name).

Le rôle “agent”

Un rôle au sein d’une procédure peut être confié à un agent, c’est à dire à un programme s’exécutant sur le serveur, déclenché selon une certaine fréquence (par exemple, à chaque heure, au début de chaque jour, le premier jour du mois, etc..).Le comportement précis engendré par la déclaration d´un agent jouant un rôle est le suivant :un agent de même nom que le rôle est enregistré,cet agent est reconnu comme un nouvel acteur jouant ce rôle, la période de déclenchement de l´agent est définie, ainsi que l´instant de sa première exécution (selon les règles définies ci-dessous),à chaque exécution de l´agent, celui-ci effectue les opérations prévues par son rôle, sur tous les documents pour lesquels il y est autorisé,après chaque exécution, la date de la prochaine exécution est déterminée suivant la périodicité.

Workey permet la définition et l´activation de plusieurs types d´agents, ici, nous traitons uniquement des agents pouvant exécuter des tâches dans les processus.

Modélisation

Afin de définir dans une procédure un agent jouant un rôle spécifique, ajoutez le rôle existant désiré et éditez ses Propriétés.

Cochez l’option Agent et remarquez que l’objet rôle à maintenant une couleur bleue signifiant l’activation de la fonction de rôle agent.

Propriétés de l’objet Rôle

Général Libellé : Permet de saisir un nom visible pour le rôle

Nom interne : Attribut Designer_name de l’objet (Ce nom doit être unique)

Nom interne calculé automatiquement : Permet de garantir l’unicité des noms interne d’objets en laissant Workey les définir

TypePublic : tous les acteurs du rôle pourront avoir accès au document, qu’ils aient ou non traité ce document

Privé : seul les acteurs ayant effectué une opération en jouant ce rôle auront accès au document

Agent : défini qu’un agent s’exécutera la ou les opération en utilisant les accès du rôle

Périodicité : Spécifie le type de fréquence d’exécution de l’agent en Heure, Jours ou Mois

Formulaire : Spécifie un formulaire présenté à l’acteur du rôle

Description : Permet de saisir un texte de description pour le rôle, poiter vers un fichier externe contenant le texte de description et entrer un texte d’aide.
Il est aussi possible d’ajouter des Liens logiques aux objets Rôle.

La fréquence exacte (par exemple toutes les 2 heures), ainsi que la date de chaque déclenchement (le 15 de chaque mois) sera ensuite affinée au niveau de la base générée via la Console d’administration.

L’agent crée dans vôtre procédure sera crée par Workey automatiquement dès le déploiement du processus.

Une restriction évidente est imposée quant au type d’opérations à la charge d’un agent : il ne peut traiter des opérations faisant intervenir un choix libre parmi plusieurs possibilités. En conséquence, la génération de la base Notes ne pourra être effectuée si une des opérations faisant partie de la tâche de l’agent est assortie d’une post-condition de type “OU” sans règle de calcul de l’état suivant</div>En corollaire sont donc autorisées :

les opérations « simples » (sans post-condition)
les opérations avec une post-condition “ET”, permettant ainsi la dérivation automatique de un ou plusieurs documents
les opérations avec une post-condition “OU” “automatiques”, c’est à dire avec un ensemble de règles de calcul permettant de déterminer un et un seul état possible dans toutes les situations

Règle de déclenchement

L´instant de la première exécution est déterminé par les règles suivantes:

pour une période de type « Jour », le premier déclenchement est fixé au lendemain matin, après 2 heures du matin et un nombre de minutes déterminés de manière aléatoire (par exemple, 2h 18)
pour une période de type « Heure », le premier déclenchement est fixé au début de l´heure suivante additionné d´un nombre de minutes déterminés de manière aléatoire.

Modifications des caractéristiques de l´agent

La date de la prochaine exécution de l´agent, ainsi que sa périodicité, peuvent être re-définis par les administrateurs des processus.

(voir le document Console d’administration)

Exécution des connecteurs

Tout comme les opérations effectuées par les acteurs humains, les opérations effectuées par des agents provoquent la mise en oeuvre de tous les connecteurs prévus pour cette opération.

Notifications

Les notifications aux acteurs prévues pour l´opération sont également prises en compte par l´agent, qui envoie les e-mails correspondants en utilisant sa propre adresse.

Ré-utilisation des agents lors de l´évolution des processus

Lors de la mise à jour d´un processus, les agents existants et jouant déjà un rôle dans la version précédente du processus sont conservés et affectés à la nouvelle version de ces rôles.

Administration des agents

Workey Admin permet de configurer vos agents ainsi que de superviser leurs activités.

A partir de la Console d’administration, vous allez pouvoir définir pour l’agent créé en modélisation comme décrit ci-dessus les éléments suivants :

Options

Journalisation de l’activité
Permet de construire une trace de l’activité de l’agent
Autoriser les instances multiples
Permet d’utiliser plusieurs de ces agents simultanément

Tâche

Activer/Désactiver (Utilisé)
Permet d’activer ou suspendre l’activité le l’agent
Valeur
Permet de préciser la taille du batch

Déclenchement

Mode d’exécution
- Répétition à intervalle régulier : Permet de définir une fréquence régulière selon l’unité de temps choisie
  - Intervale de temps : Défini l’unité de temps de la fréquence d’exécution de l’agent
- Expression CRON : Permet de spécifier une expression CRON de planification personnalisée du déclenchement
Mode de démarrage
- Dès que possible : Exécute l’agent aussitôt que l’état de disponibilité du serveur web le permet
- Compte-à-rebours : Permet de spécifier un laps de temps entre 1 et 120 minutes avant l’exécution de la tâche de l’agent
- Heure fixe : Spécifie une heure exacte à pour l’exécution de l’agent
- Date Fixe : Permet de choisir dans un calendrier une date précise pour le déclenchement

Exclusion

Utiliser calendrier : Permet de choisir un calendrier personnalisé pour exclure des dates et/ou heures dans la planification du déclenchement de l’agent

Notification / Sélection d’acteurs

Il peut être souhaitable, à certaines étapes du processus, de laisser le libre choix des intervenants suivants aux acteurs eux-mêmes.

Ce choix s’effectue dans une ensemble d’acteurs qui est peut-être le résultat du calcul des différentes contraintes exprimées : appartenance au rôle voulu, contraintes organisationnelles de différents types. C’est sur cette liste éventuellement restreinte que pourra s’effectuer le choix par l’acteur.

Avec ce choix, vient en général le souhait de notifier les acteurs ou les intervenants choisis
Au niveau de la modélisation, c’est dans les propriétés définies comme suit sur le(s) lien(s) en sortie d’une opération que les notifications sont définies.

Sélection d’acteurs

Dans les Propriétés d’un lien de sortie d’une opération, il est possible de spécifier des critères de sélection des acteurs pour l’opération suivante.

Aucun acteur : Spécifie qu’aucune sélection automatique d’acteur est active. Les acteurs suivants sont tous les acteurs de la liste des candidats.

Un acteur : Spécifie que l’utilisateur devra sélectionner un (un seul) acteur spécifique dans la liste des candidats pour exécuter la prochaine opération.

Plusieurs acteurs : Spécifie que l’utilisateur devra choisir un ou plusieurs acteurs spécifiques dans la liste des candidats pour exécuter la prochaine opération. En cas de non-sélection, la liste de candidats toute entière est retenue. Vous pouvez préciser un nombre minimum ainsi qu’un nombre maximum d’acteurs

Groupe de travail : Possibilité de choisir un nombre quelconque d’acteurs dans la liste des candidats pour définir un groupe de travail autour du document concerné (tous les acteurs du groupe devront avoir “fait suivre” le document pour que le document passe à l’étape suivante). Vous pouvez préciser un nombre minimum ainsi qu’un nombre maximum d’acteurs.Tous les acteurs du groupe de travail devront alors faire envoyer sur le document pour que ce dernier puisse changer d’état. On notera que le document sera placé dans le dernier état choisi. Il faut donc ne pas proposer plusieurs états (par un OU) en sortie d’une opération parallèle.
– si aucun minimum et aucun maximum n’est défini (zone vide). Tous les acteurs du rôle seront nominés pour participer au groupe de travail.
– si un minimum et un maximum sont définis, alors un choix sera proposé à l’utilisateur pour qu’il désigne les acteurs qui devront participer au groupe de travail.Dans l’historique sera renseigné l’action de chaque acteur du groupe mais sous l’opération Groupe de travail. Lors de la participation à un groupe de travail le document comportera une zone indiquant les acteurs ayant ou non déjà réalisé leur actions.

Afficher les unités : Spécifie que la sélection d’acteurs concerne des unités organisationnelles et non des acteurs spécifiques.

On définit par “liste des candidats” la liste des acteurs jouant le rôle concerné par l’opération suivante dans le flux, après la prise en compte de contraintes éventuelles d’obligation ou d’interdiction sur cette opération (voir le point “Contraintes entre opérations” ).

Notification d’acteurs

Il est utile d´informer les acteurs du processus par le biais d´e-mails. Pour ce faire, il est possible de choisir les acteurs que l´on désire notifier des actions en cours.

Acteurs candidats

Acteurs suivants : Tous les acteurs potentiels suivants recevront un courriel les informant qu´ils ont une action à mener.

Automatiquement : (uniquement valide dans ce cas) permet de rendre automatique l´envoi d´un courriel ; si cette option n´est pas choisie, l´utilisateur pourra décider lui-même de l’envoi de ce courriel.

Acteur précédant : Un courriel d´information sera envoyé automatiquement à l´acteur ayant réalisé l´opération précédente.

Acteurs intermédiaires : Un courriel d´information sera envoyé automatiquement aux acteurs ayant réalisé les opérations précédentes depuis la création du document.

Auteur du document : Un courriel d´information sera envoyé automatiquement à l´acteur ayant créé le document.

Superviseurs : Un courriel d´information sera envoyé automatiquement aux acteurs étant définis comme Superviseur du processus.

Utilisateurs du champ : Un courriel d´information sera envoyé automatiquement aux acteurs étant renseignés un la valeur du champ spécifié. On notera que ce champ peut être multivalué.

Mode de notification

Par messagerie : Un courriel d´information sera envoyé.

Par alerte : Un pop-up d´information sera envoyé sur le poste du candidat.

Notification personnalisée

Les champs magiques

Il est possible de personnaliser le contenu des e-mails de notification, en spécifiant un traitement particulier pour les éléments du courriel envoyé (sujet, corps, etc…).

Pour mettre en oeuvre cette personnalisation des mails, il faut suffit de créer dans le formulaire des champs dont le nom respecte une syntaxe particulière. Cette syntaxe définira le champ comme étant un champ “magique“, en ce sens que le contenu de ce champ modifiera comme par magie l’e-mail de notification.

Si « myField » désigne un nom valide de champ, les syntaxes suivantes sont reconnues:

myField_cc : les e-adresses présentes dans ce champ sont ajoutées au champ carbon copy du message (de préférence, utiliser pour ce champ, obligatoirement du type texte, une apparence Text Area avec plusieurs lignes, les adresses peuvent être séparées par des retours de ligne ou des point-virgules)
myField_bcc : les e-adresses présentes dans ce champ sont ajoutées au champ blind carbon copy du message (même remarque)
myField_subject : le texte contenu dans le champ alimentera le champ subject du message (en lieu et place du message par défaut)
myField_body : le texte contenu dans le champ alimentera le champ body du message
myField_attach : le texte contenu dans le champ alimentera les pièces jointes au message.

La notification aura lieu lors du changement d´état et le courriel sera constitué (personnalisé) avec les éléments spécifiques.

Notification par alerte

A partir de la version 4 de Workey, il est possible de choisir un mode de notification complémentaire : Alerte. Cette notification vient en complément des notification par mail.

Le principe est d’envoyer la même information que celle présente dans le mail à une application client installé sur le poste utilisateur. Cette fonction nécessite au préalable l’installation de ce client sur le poste utilisateur soit manuellement soit par déploiement automatique via la page d’accueil Workey.

Mémo

Les Mémos servent à intervenir lors du déroulement d’un processus au moyen d’annotations à destination des intervenants.

Le sens précis de ces annotations résulte du nom choisi pour l’opération qui va les créer. En utilisant le verbe “relancer”, par exemple, ces annotations pourront être interprétées comme des injonctions visant à relancer l’activité du processus.

Tout acteur ayant obtenu un droit de lecture sur un document du processus peut être muni du droit d’effectuer ces annotations, qui sont enregistrées dans l’histoire du processus.

Ces annotations pourront être diffusées par un des moyens installés (e-mails ou alertes sur les postes de travail).

Elles seront directement visibles par les personnes concernées lors de l’ouverture des documents en ayant fait l’objet.

La modélisation

La modélisation consiste tout d’abord à déterminer:

qui peut effectuer ces annotations,
quand peuvent-elles être effectuées.

Dans l’onglet des Composants, choisissez l’objet et glissez-le dans le graphe de procédure.

Général Libellé : Permet de saisir un nom visible pour l’objet.

Nom interne : Attribut Designer_name de l’objet (Ce nom doit être unique).

Nom interne calculé automatiquement : Permet de garantir l’unicité des noms interne d’objets en laissant Workey les définir.

Mémo : Permet d’entrer un texte informatif.

Diffusion privée : Permet de restreindre la diffusion du message

Par alerte : Permet d’installer une alerte pop-up sur le poste du destinataire du message.

Description : Permet de saisir un texte de description, pointer vers un fichier externe contenant le texte de description et entrer un texte d’aide.
Il est aussi possible d’ajouter des Liens logiques aux objets Mémo.

Le mémo est une opération particulière et comme toute opération,

elle est placée sous le rôle permettant de l’effectuer,
elle est reliée à l’état de document à partir duquel elle est possible.

La modélisation permet:

de nommer cette opération en accord avec le but recherché,
de préciser si les annotations sont en accès:

privé (elles ne seront visibles que par les personnes explicitement désignées comme destinataires, et par celles qui les ont créées)
ou public (elles seront visibles par toute personne auorisée à lire le document),

de préciser son mode de diffusion (par défaut, la diffusion se fait par l’envoi d’ e-mails, il est possible de spécifier une diffusion par alertes).

L’utilisation

A l’ouverture du document, une section “Annotations” est affichée, montrant à l’utilisateur courant les annonces reçues et émises par lui. La colonne ‘Objet’ reprend les 120 premiers caractères de la relance.

(les “process managers” ou “workflow managers” voient toutes les annonces effectuées).

Si les conditions le permettent (l’utilisateur joue un des rôles prévus et le document se trouve dans un des états prévus), une zone de saisie lui permet de saisir le texte du message, puis de diffuser l’annonce:

Dans la vue “Actions possibles”, les utilisateurs jouant le rôle voulu peuvent visualiser tous les documents qu’ils sont en mesure d’annoter:

Gestion des délais et annotations

La gestion des délais à respecter dans un processus est confiée à un agent. Il est possible de spécifier que les notifications envoyées par cet agent aux acteurs donnent automatiquement lieu à des annotations reprenant les termes de ces notifications. Ceci aura pour effet de conserver ces messages et de les rendre visibles aux acteurs concernés. Dans l’outil de conception, il faut afficher la page du graphe du processus et éditer ses propriétés.

Tâche programmées / Evénements liés aux données

Ce chapitre décrit la notion d’événements pouvant se déclencher dans un processus à la suite de circonstances créés par certaines données.

Par exemple, dans un processus d’accueil de nouveaux collaborateurs, les données comme “le contrat est un CDD” et “la date de fin de contrat est le 15 janvier” pourrait donner naissance à un événement “Fin de CDD”. Cet événement devrait être porté à la connaissance des intervenants du processus pour les en rendre attentifs.

Modélisation

Dans un modèle de procédures, faites glisser un objet
Tâche programmée, puis liez-le à une opération.

L'événement doit être lié en sortie d'une opération. 
La signification du lien est : lorsque l'opération est réalisée, l'événement est créé 
et considéré comme potentiellement activé. 
Il ne le sera que lorsque sa condition d'existence (définie dans les propriétés de l'objet) 
sera vérifiée par les données.

Propriétés d’un objet tâche

Général

Permet de spécifier le libellé de l’objet et son nom interne.Unité: Défini la fréquence d´exécution de la tâche en jour ou en heure.

Lancement

Date d´occurrence : Permet de saisir une date spécifique, pointer sur un champ de date ou d’entrer une instruction de calcul de date.Message : Permet de composer un message personnalisé.Condition : Permet de conditionner grâce à une fonction Stalk l’exécution de la tâche.Classe Java : Permet d´appeler une classe Java lors du déclenchement de la tâche.

Avertissements

Échéancier d’avertissements : Permet de définir un nombre d’unité de temps (spécifiée dans la section Général) avant et/ou après le déclenchement de la tâche pour l’envoie d’avertissements par mail.Message : Permet de composer un message personnalisé.

Notifications

Intervenants futurs : Envoie une notification aux acteurs définis pour les rôles agissant sur les opération suivantes.Intervenants passés : Envoie une notification aux acteurs ayant déjà agi sur le document.Auteur du document : Envoie une notification à l’acteur qui à crée le document.Superviseurs : Envoie une notification aux acteurs définis pour le rôle de Superviseur.Utilisateurs du champ : Permet de définir un champ existant dans un formulaire et contenant un ou plusieurs destinataires pour une notification.Acteurs du rôle : Permet de sélectionner un rôle existant en modélisation pour informer les acteurs définis pour ce rôle.

Description

Description : Saisissez une description de la fonctionnalité de la tâche.

Étendue : Permet de pointer sur un fichier du texte de description.

Aide : Permet de saisir un texte d’aide pour la tâche.

Lorsque l’on lie une opération à une tâche, Workey colore automatiquement le lien en vert foncé, couleur significative de des tâche actives.

La disparition d’un événement

Dans certaines situations pratiques, l’événement peut ne plus avoir de sens ou ne plus présenter d’intérêt dés qu’une opération particulière a été effectuée.

Par exemple, dans le cas de l’événement lié à la fin d’un contrat CDD, l’opération “changer le contrat en CDI” doit entraîner la suppression de l’événement.

La modélisation d’une fin de tâche s’effectue dans les propriétés du lien venant de son opération.
Type : Spécifie le type de lien géré sur l’opération courante

Lancer : Détermine la création d’une tâche

Stopper : Détermine l’arrêt d’une tâche

Lorsque l’option Stopper est activée, Workey colore automatiquement le lien en rouge foncé, couleur significative des tâches inactives.

Scénario de prise en compte d’une tâche dans un processus

Pour une exécution particulière d’un processus comportant la modélisation d’une tâche programmée, le scénario-type est le suivant.

L’opération déclenchant la tâche est effectuée: la tâche est créée, avec sa date de survenance déterminée. Si les données le permettent, elle est déclaré activée.
Selon l’échéancier prévu pour la période précédant sa survenance, des notifications d’avertissement sont envoyées aux intervenants prévus.
A chaque opération survenant dans la suite du processus, la condition d’existence de la tâche est re-calculée: la tâche peut donc être désactivée ou ré-activée plusieurs fois dans le parcours de vie du processus.
Si une opération prévoyant la suppression de la tâche est réalisée, la tâche est supprimée.
A la date de survenance prévue, si la tâche est encore active, des notifications sur la survenance du message sont envoyées aux intervenants prévus.
Selon l’échéancier prévu pour la période après sa survenance, des notifications de survenance de la tâche sont envoyées aux intervenants prévus.
A la fin du parcours de vie du document, la tâche est supprimée, si elle existe encore.

Événements prédéfinis

Workey Designer propose aussi une série de classes d’événements prédéfinies que l’on peut appeler depuis une procédure.

A partir de la version 4.0 de Workey, le moteur gère la gestion des évènements. Le principe de fonctionnement est le suivant :

On crée un classe d’événements correspondant à l’événement que l’on souhaite intercepter (les interfaces sont dans le package com.clog.workey.events). Ces classes ressemblent beaucoup au connecteurs
On déclare les événements dans le fichier properties-service.xml (voir exemple ci-dessous)
Les classes ainsi déclarées seront exécutées à chaque fois que l’événément se produit dans le moteur. A charge au développeur de la classe de déterminer si celle-ci doit s’exécuter (en fonction du processus ou document, par exemple)

Exemple de configuration dans properties-service.xml sous Jboss 4 ou workey.properties sous Jboss 6 ou catalina.properties sous Tomcat 7 :

#; événement lancé après l'ouverture d'un document
#; implemente la classe com.clog.workey.events.IPostOpenDocumentEvent
com.clog.workey.events.postOpenDocument=com.client.PostOpenDocument
#; événement lancé après la soumission d'un document, plusieurs classes peuvent être appelées (séquentiellement)
com.clog.workey.events.postSubmitDocument=com.client.PostSubmitDocument,com.client.AnotherPostSubmitDocument

Evénements disponibles

DeployProcess

Classes à implémenter:

Pre: com.clog.workey.events.IPreDeployProcess
Post: com.clog.workey.events.IPostDeployProcess

Méthodes à implémenter :

PreDeployProcess(String) : Document XML à deployer.
PostDeployProcess(List) : List des processus déployés.

OpenDocument

Classes à implémenter:

com.clog.workey.events.IPreOpenDocument
com.clog.workey.events.IPostOpenDocument

pas encore implémenté.

OpenView

Classes à implémenter:

Pre: com.clog.workey.events.IPreOpenView
Post: com.clog.workey.events.IPostOpenView

pas encore implémenté.

SubmitDocument

Classes à implémenter:

Pre: com.clog.workey.events.IPreSubmitDocument
Post: com.clog.workey.events.IPostSubmitDocument

Méthodes à implémenter :

PreSubmitDocument(CoreDocument, UserAuth)
PostSubmitDocument(CoreDocument, UserAuth)

SaveDocument

Classes à implémenter:

Pre: com.clog.workey.events.IPreSaveDocument
Post: com.clog.workey.events.IPostSaveDocument

pas encore implémenté.

Attach

Classes à implémenter :

Pre: com.clog.workey.events.IPreAttach
Post: com.clog.workey.events.IPostAttach

Méthodes à implémenter :

PreSubmitAttach(Actor, Attachment)
PostSubmitAttach(Actor, Attachment, java.io.File attachedFile)

Notification

Classes à implémenter:

Pre: com.clog.workey.events.IPreNotification

Méthodes à implémenter :

PreNotification(javax.mail.Message, Notification)