Documentation:Conception de Workflows
Un article de AlfrescoWiki.
Retour vers l'Accueil.
Ce document décrit les différentes étapes pour créer vos propres workflows (ou revue ou gestion de flux) avancés au sein d'Alfresco. Pour cela, on étudiera le cas du Workflow dit "Ad-Hoc Task".
Cet article est la traduction littérale du même article au sein du wiki Alfresco anglophone à l'adresse suivante :
WorkflowAdministration.
Pour aller plus en détails dans l'implémentation et l'utilisation des workflows au sein d'Alfresco (toujours sur le wiki anglais : Workflow Reqs and Design ou encore Workflow.
Sommaire
|
[modifier] Définition d'un Workflow
Un workflow (ou une revue) avancé Alfresco est décomposable en plusieurs éléments...
- Définition du Processus
La définition du processus décrit les états (les étapes) et les transitions (les choix) d'un workflow. Une étape peut-être effectuée soit par un acteur Humain soit Système (de manière automatique). Les étapes d'interaction humaine permettent de créer et d'assigner des tâches à des utilisateurs. Les étapes gérées automatiquement par le Système exécutent des opérations en relation avec l'entrepôt de données Alfresco. Ces 2 étapes sont décrites et implémentées dans la définition du processus.
Alfresco intégre le moteur de workflow JBPM et fournit donc le support du langage de définition de processus jPDL. jPDL peut être définit dans l'un des 2 formats suivants :
- JBoss jBPM process archive (fichier .par )
- JBoss jBPM jPDL xml document (fichier .xml)
- Modèle de Tâche
Les modèles de tâche fournissent une description pour chaque types de tâches humaines dans un workflow. Chaque description de tâche est constituée :
- d'un Nom et d'un Titre.
- de Propriétés et d'assocition (cad d'informations attachés à la tâche).
La description est utilisée pour définir et personnaliser les interfaces utilisateurs de gestion des tâches.
Alfresco fournit un dictionnaire de données (Data Dictionnary) pour décrire, voir et gérer les types d'objets de l'entrepôt. Ce même mécanisme est utilisé pour décrire les différentes tâches d'un workflow.
- Configuration du client Web
La configuration du client Web définit la présentation des tâches à l'utilisateur par le client Web Alfresco.
La configuration permet le contrôle :
- de l'affichage des propriétés de la tâche
- du rendu des propriétés obligatoire et en lecture/écriture
- du positionnement de chaque propriété dans le formulaire
- du formulaire de présentation de chaque type de tâche du workflow.
Le client web Alfresco fournit un système de configuration sophistiqué de contrôle de l'affichage et du rendu des fenêtres de dialogue. Ce mécanisme s'étend aux formulaires de gestion des tâches du workflow.
- Resource Bundle (optionnel)
Un "resource bundle" workflow (ensemble, paquet de ressources) permet de fournir à tous les acteurs humains des messages contextuels, affiché au niveau de l'interface utilisateur, pour la gestion du workflow. Les messages incluent les noms des tâches, les noms des propriétés, les choix...
Alfresco supporte la gestion multilinguistique du client web et donc du workflow. C'est pourquoi le même paquet de ressource peut gérer aussi les workflows.
[modifier] Etape n°1 : Créer une Définition de Processus
Il existe 2 façons de construire une définition de processus (en tout cas pour jBoss jBPM):
- A la main c'est à dire créer un fichier jPDL
- Par l'intermédiaire d'un outil de conception autrement dit un outil de génération automatique de fichier jPDL au format xml (désigné aussi sous le nom de process archive)
La documentation de référence JBoss jBPM se situe :
[modifier] Définir et développer à la main un fichier de définition de processus XML jPDL
Utiliser votre éditeur de texte préféré pour créer votre document jPDL. Nous commencerons tout d'abord par définir le squelette de base de la définition du workflow :
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.1" name="wf:adhoc">
<swimlane name="initiator"/>
<start-state name="start">
<task name="wf:submitAdhocTask" swimlane="initiator"/>
<transition name="" to="adhoc"/>
</start-state>
<swimlane name="assignee"/>
<task-node name="adhoc">
<task name="wf:adhocTask" swimlane="assignee"/>
<transition name="" to="completed"/>
</task-node>
<task-node name="completed">
<task name="wf:completedTask" swimlane="initiator"/>
<transition name="" to="end"/>
</task-node>
<end-state name="end"/>
</process-definition>
La définition précédente décrit les 3 étapes d'une tâche de workflow dit "Ad-Hoc".
Les points importants à noter sont
- Il y a toujours un début et une fin.
- Le nom de la définition du processus et de la tâche sont importants. Ils permettent de créer des références vers ces workflows au sein d'autres workflows.
- Les Swimlanes sont utilisées pour définir les rôles associés à un workflow.
- Les tâches sont associés à un Swimlanes.
[modifier] L'outil de conception de Processus
Une manière alternative pour développer le précédent document jPDL consiste à utiliser un plugin Eclipse connut sous le nom de JBoss jBPM Process Designer.
[modifier] Installer JBoss jBPM Process Designer
Pour des références à ce sujet, se réferrer au lien suivantJBoss jBPM Process Designer Installation Notes.
Pré-requis:
Si vous avez les droits adéquats, vous pouvez télécharger l'outil spécifique Alfresco : Alfresco Workflow Designer.
[modifier] Utiliser JBoss jBPM Process Designer
JBoss jBPM Process Designer est un éditeur graphique de développement de workflow. Il permet entre autre de passer d'une vue graphique du processus sous forme de diagramme à une vue sous format XML. La synchronisation des 2 vues est gérée ainsi il est possible de modifier le fichier XML et d'en voir la resultante sous format graphique.
[modifier] Déployer via JBoss jBPM Process Designer
JBoss jBPM Process Designer permet à une définition de processus d'être sauvée dans un fichier d'archive ou directement déployé dans un serveur. Alfresco supporte le déploiement dans une instance Alfresco.
- S'assurer que le serveur Alfreso est en route
- A l'invite de déploiement de la définition du processus :
- Server Name = le nom de la machine name où est installé Alfresco
- Server Port = le port d'écoute de l'instance Alfresco (par défaut: 8080)
- Server Deployer = /alfresco/jbpm/deployprocess
- Appuyez sur le bouton Test Connection...
- Si tout est OK, appuyez sur Deploy Process Archive...
Si le déploiement est réussit, la défintion du processus est maintenant utilisable au sein d'Alfresco.
A noter qu'il n'est pas nécessaire de rédemarrer le serveur Alfresco pour activer le déploiement de la définition de processus. Cela permet de tester rapidement le fichier et ainsi de le modifier à chaud via the JBoss jBPM Process Designer.
[modifier] Déployer manuellement un fichier jPDL XML ou une Process Archive
La définition des processus peuvent être configuré au sein d'Alfresco et donc d'être déployé une fois que le serveur Alfresco démarre.
Le Bean Spring "workflowDeployer" fournit le déploiement des défintions de Procesus. Il peut être utilisé en collaboration avec le mécanisme de configuration d'extension d'Alfresco pour créer des workflows personnalisés.
<bean id="myworkflows.workflowBootstrap" parent="workflowDeployer">
<property name="workflowDefinitions">
<list>
<props>
<prop key="engineId">jbpm</prop>
<prop key="location">alfresco/workflow/adhoc_processdefinition.xml</prop>
<prop key="mimetype">text/xml</prop>
</props>
</list>
</property>
</bean>
Le bean accepte une liste de description de workflow et donc leur déploiement. Chaque workflow est définit par les propriétés suivantes :
- engineId
- le moteur d'exécution à déployé. Note: Pour les utilisateurs de la v1.4 , il s'agit obligatoirement de jbpm
- location
- Le chemin d'accès du fichier de definition. Note: JBoss jBPM process definitions peut être déployé depuis une archive ou un fichier jpdl. Il suit le même mécanisme standard d'extension de la configuration, la localisation du processus peut être sous la forme alfresco/extension/workflow/xxx_processdefinition.xml.
- mimetype
- Le type du fichier de définition de processus. text/xml pour les fichiers jPDL XML, ou application/zip pour les archives de jBPM. Si non spécifié, il s'agit de application/zip.
- redeploy (true | false)
- Permet de forcer ou non de déploiement du fichier s'il est déja déployé. Cela s'avére utile dans les phases de tests du workflow. A chaque démarrage du serveur Alfresco, la définition est redéployé et une nouvelle version crée. Pour les environnements de production, il est recommandé de mettre cette valeur sur false. Si non spécifié, le paramètre est défini à false.
[modifier] Redéployer une définition de processus
Redéployer une définition permet de mettre à jour la définition. Le déploiement manuel et le déploiement via JBoss jBPM Process Designer permettent le redéploiement. Dans chaque cas, la version précédente est versionné et stocké afin de permettre l'éxecution des nouveaux.
[modifier] Etape 2: Créer un modèle de tâche
Pour chaque tâche dans la définition de processus (défini par la balise <task> dans le fichier jPDL), il est possible d'associer une description de tâche. Celle ci permet de définir les informations qui peuvent être attachées à une tâche c.a.d les propriétés (nom et type de données) et les associations (nom et type d'objet associé). Un utilisateur voit et édite ces informations dans le formulaire de Tâche au sein du client Web Alfresco.
Le modèle de tâche est caractérisé comme les modéles de contenus (Content Model) tel qu'il est supporté le Dictionnaire de Données. Pour créer un modèle de tâche :
- Créer un nouveau Modèle de Contenus pour la définition de processus
- Créer un type pour chaque tâche
- Pour chaque type, décrire les propriétés et les associations (informations) nécessaire à l'éxecution de la tâche.
Pour notre exemple de workflow "Adhoc" , on peut définir le modéle de contenu ainsi :
<?xml version="1.0" encoding="UTF-8"?> <model name="wf:workflowmodel" xmlns="http://www.alfresco.org/model/dictionary/1.0"> <imports> <import uri="http://www.alfresco.org/model/dictionary/1.0" prefix="d"/> <import uri="http://www.alfresco.org/model/bpm/1.0" prefix="bpm"/> </imports> <namespaces> <namespace uri="http://www.alfresco.org/model/workflow/1.0" prefix="wf"/> </namespaces> <types> <type name="wf:submitAdhocTask"> <parent>bpm:startTask</parent> <properties> <property name="wf:notifyMe"> <type>d:boolean</type> <default>false</default> </property> </properties> <mandatory-aspects> <aspect>bpm:assignee</aspect> </mandatory-aspects> </type> <type name="wf:adhocTask"> <parent>bpm:workflowTask</parent> </type> <type name="wf:completedAdhocTask"> <parent>bpm:workflowTask</parent> </type> </types> </model>
La puissance du Modèle de Contenus (modèle de données) peut être celui de décrire les tâches. Par exemple, les types de données des propriétés, les contraintes et les valeurs par défaut peuvent être déterminer. L'interface utilisateur et donc les formulaires de tâche sont initialisé et crée par ces définitions.
Important : Le nom des types dans le Modèle de Contenus doit correspondre avec les noms des tâches tel qu'il est défini dans le fichier de définition de processus.
Le modèle suivant définit :
- Une tâche de départ : 'wf:submitAdhocTask'.
- Cette tâche définis les propriétés à collecter quand le workflow est démarré. Dans ce cas, les propriétés sont workflow description, priority et due date (De types bpm:startTask) et 'wf:notifyMe'.
- Cette tâche inclus l'aspect 'bpm:assignee'. Celui ci permet de définir une collection d'assignée (une personne seule) dans le formulaire de démarrage de la tâche.
- Les tâches de workflow 'wf:adhocTask' et 'wf:completedAdhocTask'.
- Ces tâches ne définissent rien de plus qu'il n'est défini dans 'wf:workflowTask'.
[modifier] Le Modèle de Tâche Commun (Common Task Model)
Alfresco fournit un Modèle de Contenus pour décrire les attributs commun pour toutes les tâches. Cela inclus:
- Task Id (Identifiant de la tâche)
- Start Date (La date de départ)
- Due Date (La date de fin planifiée)
- Completion Date (La date réel de fin)
- Priority (La priorité)
- Status (Le status)
- Outcome (quel choix a été fait pour la complétion)
- Workflow Package (i.e. le contenu suivi tout le long du Workflow)
- Context (i.e. L'espace Alfresco dans lequel le workflow est initialisé)
- ...
Ces informations (et plus encore) sont définit par le modèle 'bpm:businessprocessmodel'. Il se situe dans le fichier de configuration alfresco/model/bpmModel.xml. Dans ce modèle, les 2 définition de types les plus importantes sont désigné par 'bpm:workflowTask' et 'bpm:startTask'. Les définition de types de workflow personnalisés doivent dérivé (explicitement ou implicitement) de l'un de ces types. Note: La tâche de départ est expliqué plus bas.
La base du modèle de tâche est définit dans le Modèle de Contenus de la manière suivante :
<imports>
<import uri="http://www.alfresco.org/model/bpm/1.0" prefix="bpm"/>
</imports>
Vous avez sans doute noté que le modèle de tâche du workflow Adhoc suivant défini simplement une seule propriété désigné par 'wf:notifyMe'. Mais alors d'où provienne les propriétés due date, assignee? Elles sont tous héritées de la définition des tâches de base.
[modifier] La Tâche de Démarrage (The Start Task)
Il existe une tâche spéciale connu sous le nom de Tache de départ (Start Task) qui est assigné à l'Initiateur du workflow. Il est utilisé pour collecter les informations requis pour procédérer au démarrage du workflow. Dans le client Web Alfresco, la tâche de départ est présenté comme une simple page dans l'assistant de Démarrage du Workflow sélectionné. Cette page (comme toutes les autres tâches) est conduite par la définition de tâche.
Dans la Définition de Processus (i.e. jPDL), la tâche de départ est celle défini dans les balises <start-state>. La description de la tâche dans le modèle de Tâche dérive de 'bpm:startTask'.
Souvent la tâche de départ collecte les participants (personne ou groupe) qui vont jouer un rôle au sein du workflow. Pour le permettre, les aspects prédéfinis suivants sont fournit et attaché à la tâche de départ :
- bpm:assignee collecte et désigne une seule personne pour jouer un seul rôle
- bpm:assignees collecte et désigne une ou plusieurs personne pour jouer un seul rôle
- bpm:groupAssignee collecte un seul groupe pour jouer un rôle (Alfresco v2.0 ou + uniquement)
- bpm:groupAssignees collecte un seul un ou plusieurs groupes pour jouer un rôle (Alfresco v2.0 ou + uniquement)
Des aspects personnalisés peuvent être ajoutés pour collecter le nombre de personne ou de groupe.
[modifier] Le Package d'Actions du Workflow (Workflow Package Actions)
Les workflows Alfresco travaille en collaboration avec le Contenu défini au sein de l'entrepôt de données Alfreco. Un Package est utilisé pour tenir à jour le contenu utilisé au sein du workflow. Le contenu dans le package peut être visualiser, éditer ou supprimer. Du contenu peut aussi être ajouté au package de Workflow.
Néanmoins, tous les packages ne peuvent pas être appliqué à toutes les tâches. Par exemple, une tâche de revue peut simplement visualiser et éditer du contenu.
Le client Web Alfresco supporte la notiton d'"Action Groups" c'est à dire un groupe d'actions au niveau de l'interface utilisateur. A chaque tâche est associé un groupe d'action. Cela est déterminé en spécifiant une valeur par défaut pour les propriétés de tâche dans le modèle de Tâche :
<property name="bpm:packageActionGroup"> <type>d:text</type> <default>add_package_item_actions</default> </property> <property name="bpm:packageItemActionGroup"> <type>d:text</type> <default>edit_package_item_actions</default> </property>
Alfresco fournit par défaut les Action Groups pour les Workflow Packages:
- read_package_item_actions
- permet de visualiser les données du Workflow Package
- edit_package_item_actions
- précédent + permet la modification (edition, bloquer, ...)
- edit_and_remove_package_item_actions
- précédent + permet la suppression de données dans le package
- remove_package_item_actions
- permet de supprimer (mais pas de modifier) les données
- add_package_item_actions
- permet l'ajout de nouvelles données
Ils sont définis dans le fichier de configuration alfresco/web-client-config-workflow-actions.xml qui fournit la liste exhaustive de l'ensemble des listes d'actions pour chaque groupe d'actions.
[modifier] Deployer un Modèle de Tâche (Deploy the Task Model)
Un modèle de tâche peut être déployé en utilisant un "Workflow Deployer" bean (tel qu'il est décrit dans Deployer une Définition de Processus).
<bean id="myworkflows.workflowBootstrap" parent="workflowDeployer">
<property name="workflowDefinitions">
...
</property>
<property name="models">
<list>
<-- Task Model associated with above process definition -->
<value>alfresco/workflow/adhocModel.xml</value>
</list>
</property>
</bean>
De manière alternative, le modèle de tâche est simplement un Modèle de Contenu, il peut donc être déployé de la même façon que n'importe quel autre Modèle de Contenu.
Un exemple de configuration :
<bean id="adhocWorkflow.dictionaryBootstrap" parent="dictionaryModelBootstrap" depends-on="dictionaryBootstrap">
<property name="models">
<list>
<value>alfresco/model/adhocTaskModel.xml</value>
</list>
</property>
</bean>
NOTE: L'expérience à montrer qu'en utilisant le dictionaryBootstrap pour un modèle de workflow personnalisé tel que montré auparavant il peut y avoir des problèmes. Le problème est qu'il n'est pas possible d'étendre le namespace wcmwf. Par contre lorsque que l'on utilise le workflowBootstrap bean, cela fonctionne.
[modifier] Les Définitions de Workflow par Défaut
Les workflows "Review & Approve" et "Ad-hoc Task" sont fournit par défaut et peuvent être trouvé dans le répertoire de configuration Alfresco suivant alfresco/workflow.
- review_processdefinition.xml - Process Definition pour "Review & Approve"
- adhoc_processdefinition.xml - Process Definition pour "Adhoc Task"
- workflow-messages.properties - Resource Bundle pour les deux
- workflowModel.xml - Task Model pour les deux
Ces 2 workflows sont configurés dans le fichier de bootstrap alfresco/bootstrap-context.xml par le bean appelé workflowBootstrap.
[modifier] Etape 3 : Ajouter du Comportement pour la définition de Processus
Avec les exigences des données spécifiés, il est possible de revisiter la Définition du Processus et d'ajouter du comportement c'est à dire de décrire le flux de données, l'assignation des tâches et les actions à exécuter.
Toutes les caractéristiques des fichiers jPDL sont supportés. Pour plus d'informations à ce sujet JBoss jBPM User Guide.
Revenons à notre exemple...
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.1" name="wf:adhoc">
<swimlane name="initiator"/>
<start-state name="start">
<task name="wf:submitAdhocTask" swimlane="initiator"/>
<transition name="" to="adhoc"/>
</start-state>
<swimlane name="assignee">
<assignment actor-id="#{bpm_assignee.properties['cm:userName']}"/>
</swimlane>
<task-node name="adhoc">
<task name="wf:adhocTask" swimlane="assignee">
<event type="task-create">
<script>
if (bpm_workflowDueDate != void) taskInstance.dueDate = bpm_workflowDueDate;
if (bpm_workflowPriority != void) taskInstance.priority = bpm_workflowPriority;
</script>
</event>
</task>
<transition name="" to="completed">
<action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
<script>
if (wf_notifyMe)
{
var mail = actions.create("mail");
mail.parameters.to = initiator.properties["cm:email"];
mail.parameters.subject = "Adhoc Task " + bpm_workflowDescription;
mail.parameters.from = bpm_assignee.properties["cm:email"];
mail.parameters.text = "It's done";
mail.execute(bpm_package);
}
</script>
</action>
</transition>
</task-node>
<task-node name="completed">
<task name="wf:completedAdhocTask" swimlane="initiator"/>
<transition name="" to="end"/>
</task-node>
<end-state name="end"/>
<event type="process-end">
<action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
<script>
if (logger.isLoggingEnabled())
logger.log("End of process. Cancelled: " + cancelled);
</script>
</action>
</event>
</process-definition>
Notes:
- Le swimlane 'assignee' est liée à la variable de processus bpm_assignee
- L'évènement task-create est utilisé pour initialiser la date planifiée et la priorité de la tâche adhoc
- Une fois la tâche adhoc complété, un évènement est déclenché pour appeler un Javascript Alfresco qui envoie un e-mail.
- L'évènement process-end est utilisé pour définir la fin du workflow
[modifier] Process Data
Tous les process data - incluant ce qui est spécifié dans le modèle de tâche - est stocké et exposé à des actions de scripting par jBPM. Pour manipuler le modèle de tâche par scripts, on doit en premier comprendre comment cela est représenté du côté jBPM.
Les propriétés standard properties sont liées comme suivant :
- bpm:taskId <--> taskInstance.id
- bpm:description <--> taskInstance.description
- bpm:startDate <--> taskInstance.start
- bpm:dueDate <--> taskInstance.dueDate
- bpm:completionDate <--> taskInstance.end
- bpm:priority <--> taskInstance.priority
- bpm:comment <--> taskInstance.comments.get(0).message
- cm:created <--> taskInstance.create
- cm:owner <--> taskInstance.actorId
Toutes les autres propriétés et associations sont liés (mapper) par les variables jBPM variables en utilisant la convention de nommage suivant :
- Task Model - <namespace_prefix>:<local_name> e.g. bpm:assignee, wf:notifyMe
- Task Variable - <namespace_prefix>_<local_name> e.g. bpm_assignee, wf_notifyMe
Si la variable n'existe pas encore, la propriété a une valeur par défaut spécifié dans le Modèle de Tâche (ou nul si le défaut n'est pas défini).
Par défaut, quand une variable de tâche est poussé à une variable de processus et vice-versa, le même nom est utilisé. Pour exemple, la tâche de démarrage Adhoc spécifie la propriété wf:notifyMe. Quand la tâche est terminé, la variable wf_notifyMe est poussé au niveau du processus en tant que variable de processus désigné aussi par wf_notifyMe.
JBoss jBPM fournit un mécanisme de contrôle manuel du mapping entre les variables de tâches et de processus. Ce mécanisme est appelé task controller qui permet le mapping entre des variables spécifiques et leur noms spécifiques utilisable c'est à dire de mapper la variable locale wf_notifyMe à la variable de processus notify_via_email...
<task>
<controller>
<variable name="notify_via_email" access="write" mapped-name="wf_notifyMe"/>
</controller>
</task>
