Modélisation du workflow
Création d'un modèle de workflow
Un modèle de workflow peut être créé à partir de la section 'Modèle de workflow'. La seule information requise à la création est un nom de modèle unique dans le référentiel.
Les étapes du modèle de workflow sont initialisées avec une transition initiale. Pour implémenter le modèle de workflow, il faut définir la séquence des étapes qui suivent cette transition initiale.
Implémentation des étapes
Un modèle de workflow définit des étapes correspondant à des opérations et des conditions. Les étapes possibles sont les suivantes :
Tâche utilisateur
Tâche automatique
Condition
Appel à des sous-workflows
Tâche d'attente
Un contexte de données est lié à chaque workflow de données. Ce contexte de données peut être utilisé pour définir des variables, qui pourront être utilisées en entrée et/ou en sortie dans les différentes étapes du workflow.
Stratégie d'avancement de l'étape suivante
Pour chaque type d'étape (excepté pour les appels de sous-workflows), une propriété est disponible pour préciser la stratégie d'avancement pour l'étape suivante. A la terminaison de l'étape, cette stratégie est évaluée pour conditionner la navigation lors de l'exécution du workflow. Par défaut, la stratégie d'avancement est 'Afficher la table des bons de travail'. Dans ce cas, après l'exécution de l'étape, la table des bons de travail est automatiquement affichée pour sélectionner le prochain bon de travail à ouvrir.
Une autre stratégie est disponible : 'Ouvrir automatiquement l'étape suivante'. Cette stratégie permet à l'utilisateur de garder la main sur ce workflow et d'exécuter directement l'étape suivante. Si, à la suite de cette exécution, un bon de travail est atteint et que l'utilisateur connecté peut le démarrer, le bon de travail est automatiquement ouvert (si plusieurs bons de travail sont atteints, le premier créé est ouvert). Sinon, la stratégie d'avancement de l'étape suivante est évaluée. Si aucun bon de travail n'est finalement atteint, la table des bons de travail est affichée.
Cette stratégie est préconisée pour exécuter plusieurs étapes à la suite sans repasser par la corbeille de tâches.
Il existe actuellement plusieurs limitations qui font que cette stratégie peut être ignorée. Dans ce cas, la table des bons de travail est automatiquement affichée. Les cas où cette propriété est ignorée sont les suivants : si l'étape suivante est un sous-workflow, ou si l'étape courante est une tâche utilisateur avec plus d'un bon de travail.
Dans le cas des conditions, deux autres stratégies sont proposées : 'Si vrai, ouvrir automatiquement l'étape suivante' et 'Si faux, ouvrir automatiquement l'étape suivante'. Ces stratégies permettent de conditionner la stratégie à appliquer en fonction du résultat de la condition.
Masquée dans la vue graphique
Pour chaque type d'état, une propriété est disponible pour définir quelles étapes doivent être masquées dans la vue graphique de workflow par défaut.
Si cette propriété est activée, l'étape sera automatiquement masquée dans la vue graphique de workflow pour les utilisateurs non-administrateurs (ni administrateurs built-in, ni administrateurs de workflow).
Tâche utilisateur
Une tâche utilisateur est une étape qui nécessite une action de la part d'un utilisateur humain. Son libellé et sa description peuvent être localisés.
Mode
Pour des raisons de compatibilité ascendante, deux modes de tâche utilisateur sont disponibles : le mode par défaut et le mode de compatibilité.
Dans le mode par défaut, une tâche utilisateur génère un seul bon de travail. Ce mode propose d'avantage de fonctionnalités, comme proposer un bon de travail à une liste de profils, ou afficher les avatars directement dans la vue graphique de workflow.
Dans le mode de compatibilité, une tâche utilisateur peut générer plusieurs bons de travail.
Par défaut, le service de création de tâche utilisateur est masqué en mode compatiblité. Pour l'afficher, il faut activer une propriété dans le fichier ebx.properties. Pour plus d'informations, voir Disabling user task legacy mode.
Liste de profils
La définition des profils d'une tâche utilisateur varie en fonction du mode de la tâche utilisateur.
[Mode par défaut] Proposée aux profils suivants
Les profils définis sont les rôles ou les utilisateurs auxquels la tâche utilisateur est proposée. Lors de l'exécution de la tâche utilisateur, un seul bon de travail est généré. Si un seul utilisateur est défini, le bon de travail est automatiquement alloué à cet utilisateur. Si un rôle est défini, le bon de travail est proposé aux membres du rôle. Si plusieurs utilisateurs et rôles sont définis, le bon de travail est proposé à la fois à ces utilisateurs et aux membres de ces rôles.
[Mode de compatibilité] Participants
Les participants sont les rôles ou les utilisateurs auxquels la tâche utilisateur est destinée. Par défaut, lors de l'exécution de la tâche utilisateur, un bon de travail est généré par profil. Si un profil est un utilisateur, le bon de travail est automatiquement alloué à cet utilisateur. Si un profil est un rôle, le bon de travail est proposé aux membres du rôle.
For more information
Voir aussi
Service
TIBCO EBX® propose les services prédéfinis suivants :
Accéder à des données
Accéder à l'interface de fusion des espace de données
Accéder à un espace de données
Comparer deux contenus
Créer un nouvel enregistrement
Dupliquer un enregistrement
Exporter les données depuis une table au format CSV
Exporter les données depuis une table au format XML
Fusionner un espace de données
Importer les données dans une table depuis un fichier CSV
Importer les données dans une table depuis un fichier XML
Valider un espace de données, une image ou un jeu de données
Voir aussi
Configuration
Options générales > Rejet activé
Par défaut, seulement l'action accepter est proposée à l'utilisateur lorsqu'il enregistre sa décision.
Il est possible d'activer l'action 'rejeter' en positionnant ce champ à 'Oui'.
Options générales > Demande de confirmation activée
Par défaut, quand un utilisateur enregistre sa décision en cliquant sur le bouton 'Accepter' ou 'Rejeter', une demande de confirmation est affichée.
Il est possible de désactiver cette demande de confirmation de la décision en positionnant ce champ à 'Non'.
Options générales > Activation des commentaires
Par défaut, les commentaires sont activés. Lorsqu'un bon de travail est ouvert, un bouton 'Commentaires' est affiché et permet à l'utilisateur de saisir un commentaire.
Il est possible de masquer ce bouton 'Commentaires' en positionnant cette propriété à Non.
Options générales > Caractère obligatoire du commentaire
Par défaut, le commentaire associé à un bon de travail est optionnel.
Il est possible de forcer l'utilisateur à saisir un commentaire avant d'enregistrer sa décision en positionnant ce champ sur le comportement attendu : 'toujours obligatoire', 'obligatoire seulement si le bon de travail a été accepté' ou 'obligatoire seulement si le bon de travail a été rejeté'.
Options générales > Libellés personnalisés
Durant l'exécution des tâches utilisateur, l'utilisateur peut accepter ou rejeter son bon de travail en cliquant sur le bouton correspondant. Dans la modélisation de workflow, il est possible pour certaines tâches utilisateur de définir un libellé et un message de confirmation personnalisés pour ces boutons. Cette fonctionnalité est particulièrement utile pour ajouter une signification particulière à l'action d'accepter ou rejeter un bon de travail.
[Mode de compatibilité] Terminaison > Critère de fin de tâche
Une tâche utilisateur peut être assignée à plusieurs participants et générer plusieurs bons de travail durant l'exécution du workflow. Lors de la définition d'une tâche utilisateur dans le modèle de workflow, il est possible de sélectionner un des critères prédéfinis qui déterminent quand une tâche utilisateur est terminée, en se basant sur le statut des bons de travail associés. Lorsque la condition de sortie de la tâche utilisateur sera remplie, le workflow de données avancera jusqu'à l'étape suivante définie dans le modèle.
Par exemple, pour le cas d'une tâche utilisateur qui demande la validation de l'enregistrement d'un produit, il est possible de désigner trois participants. Le critère de fin de tâche permet de préciser si l'enregistrement du produit doit être validé par les trois participants, ou uniquement par le premier utilisateur à répondre.
Le critère de fin de tâche par défaut est 'Quand tous les bons de travail ont été acceptés'.
Remarque : Si une extension de service surcharge la méthode UserTask.handleWorkItemCompletion pour gérer la fin de la tâche utilisateur, c'est à la charge du développeur de l'extension de vérifier dans le code de cette méthode que le critère de fin de tâche définie dans l'interface a été satisfait. Voir UserTask.handleWorkItemCompletion dans la JavaDoc pour plus d'informations.
[Mode de compatibilité] Terminaison > Tolérance de rejet
Par défaut, si un utilisateur rejette un bon de travail durant l'exécution d'un workflow, la tâche utilisateur est positionnée en erreur et l'avancement du workflow est stoppé.
Pour changer ce comportement par défaut, il est possible de définir un nombre de bons de travail rejetés à tolérer. Tant que la limite de rejets tolérés n'est pas dépassée, aucune erreur ne se produit et c'est le critère de fin de tâche qui détermine quand la tâche utilisateur est terminée.
Les critères de fin de tâche suivants tolèrent automatiquement tous les rejets :
'Quand tous les bons de travail ont été acceptés ou rejetés'
'Quand tous les bons de travail ont été acceptés, ou dès qu'un bon de travail a été rejeté'
Extension
Il est possible d'étendre programmatiquement le comportement de la tâche afin que cette dernière s'insère plus finement dans le contexte du workflow. Par exemple si un comportement spécifique est nécessaire, pour la création du bon de travail ou pour terminer la tâche de l'utilisateur.
La règle spécifiée est une classe Java Bean qui doit étendre la classe UserTask.
Attention
Si une règle est spécifiée et la méthode handleWorkItemCompletion surchargée, la stratégie de fin n'est plus automatiquement contrôlée. C'est au développeur de la vérifier dans cette méthode.
Notification
Une notification par courrier électronique peut être envoyée aux utilisateurs quand des événements spécifiques se produisent. Pour chaque événement, vous pouvez spécifier un message type à utiliser.
En outre, il est possible de définir un profil, auquel une copie de chaque courrier envoyé sera transmise.
Voir aussi
Relance
Des courriers électroniques de relance pour les bons de travail proposés ou alloués et inachevés peuvent être envoyés aux utilisateurs concernés de manière périodique.
Le contenu des courriers de relance dépend de l'état courant du bon de travail. En effet, si le bon de travail est proposé, la notification utilisera le modèle de courrier électronique 'Bons de travail proposés' ; si le bon de travail est alloué, la notification utilisera le modèle 'Bons de travail alloués'.
Echéance
Une tâche utilisateur peut avoir une échéance. Quand cette date est atteinte et si les bons de travail associés n'ont pas été terminés, un courrier électronique spécifique est envoyé aux utilisateurs concernés. Ce courrier électronique va alors être renvoyé tous les jours jusqu'à l'achèvement de la tâche.
Il y a deux types d'échéances :
Echéance absolue : une date du calendrier.
Echéance relative : durée (en heures, jours ou mois). La durée est évaluée à partir d'une date de référence : début d'une tâche utilisateur ou début d'un workflow.
Tâche autonome
Il existe deux types de tâches automatiques :
Script de la bibliothèque | EBX® fournit des scripts de la bibliothèque prédéfinis, qui peuvent être utilisés directement. Les scripts de la bibliothèque spécifiques doivent être déclarés dans un fichier |
Script spécifique | Spécifie une classe Java qui exécute des actions spécifiques. La classe associée doit être dans le même module que celui associé au modèle de workflow. Ses libellés et ses descriptions ne sont pas affichés dynamiquement aux utilisateurs dans un modèle de workflow. |
Script de la bibliothèque
EBX® inclut les scripts de la bibliothèque prédéfinis suivants :
Créer un espace de données
Créer une image
Fusionner un espace de données
Importer une archive
Fermer un espace de données
Modifier une variable du contexte de données
Envoyer un courrier électronique
Supprimer des enregistrements (Note : ce script peut supprimer plusieurs enregistrements à la fois)
Les scripts de la bibliothèque sont des classes qui étendent la classe ScriptTaskBean. En complément des scripts de la bibliothèque prédéfinis, vous pouvez définir des scripts de la bibliothèque additionnels pour les utiliser dans les modèles de workflows. Leurs libellés et descriptions peuvent être localisés.
La méthode ScriptTaskBean.executeScript est appelée lorsque le workflow de données atteint l'étape correspondante.
Attention
La méthode ScriptTaskBean.executeScript ne doit créer aucun Thread. En effet, le moteur de workflow passera à l'étape suivante quand le script se terminera. L'exécution d'une partie du script en mode asynchrone ne garantit donc pas sa terminaison avant le passage à l'étape suivante.
Voir l'exemple.
Il est possible de paramétrer dynamiquement les variables du script de la bibliothèque, si son implémentation suit la spécification Java Bean. Les variables doivent être déclarées comme paramètres du script de la bibliothèque dans le fichier module.xml. Le contexte des données n'est pas accessible depuis le Java bean.
Note
Certains scripts de bibliothèque prédéfinis sont marqués comme "obsolètes" car ils ne sont pas compatibles avec internationalisation. Il est recommandé d'utiliser les nouvelles tâches qui sont compatibles avec internationalisation.
Scripts spécifiques
Les scripts spécifiques ont la particularité d'étendre la classe Sample of ScriptTask.
La méthode ScriptTask.executeScript est appelée lorsque le workflow de données atteint l'étape correspondante.
Attention
La méthode ScriptTask.executeScript ne doit créer aucun Thread. En effet, le moteur de workflow passera à l'étape suivante quand le script se terminera. L'exécution d'une partie du script en mode asynchrone ne garantit donc pas sa terminaison avant le passage à l'étape suivante.
Voir l'exemple.
Il n'est pas possible de paramétrer dynamiquement les variables d'un script spécifique. Toutefois, le contexte des données est accessible depuis le Java Bean.
Conditions
Les conditions sont des étapes décisionnelles du workflow.
Il existe deux types de conditions qui, une fois définies, peuvent être utilisées dans les étapes de modélisation du workflow :
Condition de la bibliothèque | EBX® fournit des conditions de la bibliothèque prédéfinies, qui peuvent être utilisées directement. Les conditions de la bibliothèque spécifiques doivent être déclarées dans un fichier |
Condition spécifique | Spécifie une classe Java qui implémente une condition spécifique. La classe associée doit être dans le même module que celui associé au modèle de workflow. Ses libellés et ses descriptions ne sont pas affichés dynamiquement aux utilisateurs dans un modèle de workflow. |
Condition de la bibliothèque
EBX® inclut les conditions de la bibliothèque prédéfinies suivantes :
Espace de données modifié ?
Espace de données valide ?
Dernière tâche utilisateur acceptée ?
Valeur nulle ou vide ?
Valeurs égales ?
Les conditions de la bibliothèque sont des classes qui étendent la classe ConditionBean. En complément aux conditions de la bibliothèque prédéfinies, vous pouvez définir des conditions de la bibliothèque additionnelles pour les utiliser dans des modèles de données. Leurs libellés et descriptions peuvent être localisés.
Voir l'exemple.
Il est possible de paramétrer dynamiquement les variables de la condition de la bibliothèque, si son implémentation suit la spécification Java Bean. Les variables doivent être déclarées comme paramètres du script de la bibliothèque dans le module.xml. Le contexte des données n'est pas accessible depuis le Java bean.
Conditions spécifiques
Les conditions spécifiques ont la particularité d'étendre la classe Condition.
Voir l'exemple dans l'API Java.
Il n'est pas possible de paramétrer dynamiquement les variables d'une condition spécifique. Toutefois, le contexte des données est accessible depuis le Java bean.
Appels à des sous-workflows
Les étapes du type appel à des sous-workflows positionnent le workflow de données courant dans l'état "en attente" et lancent un ou plusieurs sous-workflows.
Il est possible d'inclure un autre modèle de workflow dans le modèle de workflow courant en définissant un appel unique à ce sous-workflow dans une étape.
Si plusieurs sous-workflows sont appelés par une étape, ils sont exécutés simultanément, en parallèle. Tous les sous-workflows doivent être terminés pour que le workflow parent passe à l'étape suivante. Le libellé et la description de chaque sous-workflow peuvent être localisés.
Deux types d'appels à des sous-workflows existent :
Statique | Définit un ou plusieurs sous-workflows à lancer chaque fois que cette étape est exécutée dans un workflow de données. Pour chaque sous-workflow, il est possible de spécifier ses libellés et ses descriptions, ainsi que les mappings d'entrée et de sortie dans son contexte de données. Ce mode est utile quand on sait à l'avance quels sous-workflows doivent être lancés, et comment le mapping de sortie doit être realisé. |
Dynamique | Spécifie une classe Java qui implémente un appel spécifique à des sous-workflows. Tous les workflows qui peuvent éventuellement être appelés comme sous-workflows par le code doivent être déclarés comme dépendances. Le contexte de données est directement accessible depuis le Java bean. Les appels de sous-workflows dynamiques doivent être déclarés dans un fichier Ce mode est utile quand le lancement des sous-workflows est conditionnel (par exemple, lorsqu'il dépend d'une variable du contexte de données), ou quand le mapping de sortie dépend de l'exécution des différents sous-workflows. |
Tâches d'attente
Une étape d'attente dans un modèle de workflow met le workflow en pause en attendant la réception d'un événement donné.
Lorsqu'une tâche d'attente est appelée, le moteur de workflow génère un identifiant unique de réveil lié à la tâche d'attente. Cet identifiant est requis pour réveiller la tâche d'attente et, par conséquent, le workflow associé.
Une tâche d'attente spécifie quel profil est autorisé à réveiller la tâche d'attente ; et la classe Java qui implémente un bean de tâche d'attente : WaitTaskBean.
Le contexte de données du workflow est directement accessible à partir du Java bean.
Les beans de tâche d'attente doivent être déclarés dans un fichier module.xml.
Le bean de tâche d'attente est d'abord appelé lorsque le workflow est mis en pause. L'identifiant de réveil est alors disponible pour appeler un web service, par exemple. Puis, le bean de tâche d'attente est appelé lorsque la tâche d'attente est réveillée. De cette façon, le contexte de données peut être mis à jour en fonction des paramètres reçus.
Note
L'administrateur built-in est toujours autorisé à réveiller un workflow.
Visualisation du diagramme de workflow
A propos
Lorsqu'un modèle de workflow est défini, il est possible de le visualiser sous forme d'un diagramme qui se rapproche de la norme BPMN.
Le service est disponible via un bouton dédié dans la vue hiérarchique. Le bouton est le suivant : 
Ce service fournit une vue aux possibilités d'édition limitées : il est possible d'éditer les étapes existantes, mais pas d'en modifier les liens ni de créer de nouvelles étapes.
Notez également que ce diagramme s'inspire des normes BPMN mais n'en est pas une stricte implémentation, puisque les concepts du workflow d'EBX® sont légèrement différents.
Sauvegarde de la mise en page
Il est possible de sauvegarder la mise en page du diagramme et de le sauvegarder. Notez toutefois que la sauvegarde est globale et non locale ; elle est donc partagée par tous les utilisateurs.
Actions
Exporter en PNG | Crée une image PNG du modèle. |
Exporter en SVG | Crée une image SVG du modèle. |
Exporter en PDF | Créer un PDF sur une page |
Vue
Mise en page > Mise en page par défaut | Applique la mise en page par défaut. |
Grille > Afficher/Masquer la grille | Affiche la grille lorsque celle-ci est invisible, sinon masque la grille. |
Boutons
Sauvegarder | Sauvegarde la mise en page. |
Sauvegarder et fermer | Sauvegarde la mise en page et ferme le service. |
Recharger | Annule les modifications de la mise en page en cours et recharge la mise en page précédemment sauvegardée. |
Fermer | Ferme le service. |
Fonctionnalités additionnelles
La vue graphique offre également des fonctionnalités additionnelles
Annuler l'action précédente | CTRL + Z |
Zoomer/Dezoomer | Bouton du milieu de la souris puis roulette / CTRL puis roulette |
Sélection multiple | liquer sur le noeud ou lien à sélectionner tout en appuyant sur la touche CTRL / Dessiner un rectangle de sélection (Il faut attendre 1 seconde après le clic pour activer la zone de sélection) |
Personnaliser le tracé des liens | Lorsqu'on clique sur un lien, on peut déplacer chaque segment grâce aux carrés de sélection qui apparaissent sur les coins de chaque arête, ou fractionner le segment en déplaçant le cercle qui apparaît au milieu de chaque segment |
Aperçu | Un panneau est maintenant disponible avec un diagramme de workflow miniaturisé qui pourra être utilisé pour la navigation. Il sera possible de le réduire, l'agrandir et le déplacer dans la surface correspondant à la vue du diagramme de workflow. |
Sommaire du guide utilisateur