Home > Workflow

Définition du workflow

• Définir une procédure
• Déclaration des étapes
• Tâches automatiques
  • Tâches automatiques de la bibliothèque de classes
  • Tâches automatiques spécifiques
• Conditions
  • Conditions de la bibliothèque de classes
  • Conditions spécifiques
• Tâches manuelles
  • Services natifs
  • UI services spécifiques
  • Variables en entrée
  • Variables en sortie
  • Rejet optionnel
  • Tâches temporelles
• Lien entre les étapes

Définir une procédure

Une procédure se définit en trois actes, au sein de la branche Workflow - définitions :

• Déclaration de la procédure

  • A une procédure correspond une adaptation dans la branche Workflows - définitions . Pour créer une nouvelle adaptation, il suffit d'utiliser la fonctionnalité standard d'ajout d'adaptation au niveau branche.

    La procédure est constituée :

    • de la documentation de l'adaptation qui correspond à celle de la procédure,

    • de noeuds d'adaptations pour la description générale de la procédure (variables utilisées, permissions),

    • d'une table déclarant les étapes composant la procédure,

    • d'une table définissant les liens entre les étapes ; il est à noter que cette table est masquée car mise à jour automatiquement.

• Définition des étapes de la procédure. Il existe différents types d'étape :

  • Tâches automatiques,

  • Tâches manuelles,

  • Conditions.

• Définition des liens entre les étapes.

L'image ci-après illustre cette définition :

Déclaration des étapes

Une étape est rattachée à une procédure, elle est décrite par un identifiant unique au sein de la procédure.

L'étape est ensuite spécialisée par des propriétés spécifiques à son type (un objet spécifique par type). Une étape est associée à un seul type.

Tâches automatiques

Deux types de tâches automatiques sont disponibles : 

• Tâche automatique de la bibliothèque de classes : elle doit être déclarée dans module.xml (voir exemple ci-dessus) : une tâche automatique de la bibliothèque de classes définit ses libellé, description et paramètres. Lors de la définition d'une tâche automatique, quand un utilisateur sélectionne une tâche automatique de la bibliothèque de classes, les paramètres associés sont automatiquement affichés.

• Tâche automatique spécifique : elle spécifie uniquement son nom de classe lors de la définition de la tâche automatique. L'affichage n'est pas dynamique. La classe associée doit alors appartenir au module de la définition du workflow.

Tâches automatiques de la bibliothèque de classes

Les tâches automatiques de la bibliothèque de classes sont des classes étendant ScriptTaskBean .

La méthode executeScript() est appelée dès que la procédure arrive à l'étape correspondant à cette tâche, comme montré dans l'exemple suivant . Cette méthode ne doit pas lancer de Thread car le workflow avance au retour de cette méthode. Il faut donc que tout le traitement nécessaire soit inclus dans cette méthode, et ce de manière synchrone.

Il est possible d'alimenter des variables du bean dynamiquement. Pour cela, il faut que le bean suive la recommandation JavaBean sur la notion de setter. Les variables doivent être déclarées comme paramètres du bean dans module.xml. Le contexte de données n'est pas accessible dans le Java Bean.

EBX.Platform fournit des tâches automatiques natives : 

• Créer une branche.

• Fermer une branche.

• Créer une version.

• Fusionner une branche.

• Importer une archive.

Tâches automatiques spécifiques

Les tâches automatiques spécifiques sont des classes étendant ScriptTask .

La méthode executeScript() est appelée dès que la procédure arrive à l'étape correspondant à cette tâche comme montré dans l'exemple suivant . Cette méthode ne doit pas lancer de Thread car le workflow avance au retour de cette méthode. Il faut donc que tout le traitement nécessaire soit inclus dans cette méthode, et ce de manière synchrone.

Il n'est pas possible de modifier la valeur des variables du bean de façon dynamique pour les tâches automatiques spécifiques. En revanche, le contexte de données est directement accessible dans le Java Bean.

Conditions

Deux types de condition sont disponibles : 

• Condition de la bibliothèque de classes : elle doit être déclarée dans module.xml (voir exemple ci-dessus) : une condition de la bibliothèque de classes définit ses libellé, description et paramètres. Lors de la définition d'une condition, quand un utilisateur sélectionne une condition de la bibliothèque, les paramètres associés sont automatiquement affichés.

• Condition spécifique : elle spécifie uniquement son nom de classe lors de la définition de condition. L'affichage n'est pas dynamique. La classe associée doit alors appartenir au module de la définition du workflow.

Conditions de la bibliothèque de classes

Les conditions doivent étendre ConditionBean comme dans l'exemple suivant .

Il est possible d'alimenter dynamiquement des variables du bean. Pour cela, il faut que le bean suive la recommandation JavaBean sur la notion de setter. Les variables doivent être déclarées comme paramètres du bean dans module.xml. Le contexte de données n'est pas accessible dans le Java Bean.

EBX.Platform fournit des conditions natives : 

• Tester si une branche est valide.

• Tester si une branche a été modifiée.

• Tester si la dernière tâche manuel a été acceptée.

• Tester si deux valeurs sont égales.

Conditions spécifiques

Les conditions doivent étendre Condition comme dans l'exemple suivant .

Il n'est pas possible de modifier la valeur des variables du bean de façon dynamique pour conditions spécifiques. En revanche, le contexte de données est directement accessible dans le Java Bean.

Tâches manuelles

Les tâches manuelles sont des classes étendant UserTask .

La méthode handleCreate est appelée pour initier la transaction utilisateur. Cette méthode va créer et allouer autant de bons de travail que nécessaire : si cette méthode n'est pas surchargée, le comportement par défaut est d'utiliser la liste de profils sélectionnés. Concrètement, pour chaque profil sélectionné, un bon de travail est créé.

A l'exécution, par défaut, la tâche utilisateur est considérée comme terminée quand chaque bon de travail est accepté. Il est possible de modifier ce comportement en sélectionnant une autre stratégie de terminaison : 

• Terminer la tâche utilisateur dès que tous ses bons de travail sont acceptés (stratégie par défaut).

• Terminer la tâche utilisateur dès qu'un de ses bons de travail est accepté.

• Terminer la tâche utilisateur dès que la moitié de ses bons de travail est acceptée.

• Terminer la tâche utilisateur dès que tous ses bons de travail, sauf un, sont acceptés.

• Terminer la tâche utilisateur dès que tous ses bons de travail sont acceptés ou dès qu'un bon de travail est rejeté.

• Terminer la tâche utilisateur dès que tous ses bons de travail sont terminés (accepté ou rejeté).

Si aucun seuil d'erreur n'est défini pour la tâche utilisateur, le workflow s'arrête si un bon de travail est rejeté à l'exécution : ce champ définit le nombre de rejets qui est toléré à l'exécution. Une exception est faite pour les stratégies qui gèrent le rejet ( 'Terminer la tâche utilisateur dès que tous les bons de travails sont terminés' et 'Terminer la tâche utilisateur dès que tous ses bons de travail sont acceptés ou dès qu'un bon de travail est rejeté' ). Pour ces stratégies, les rejets sont toujours tolérés.

La méthode handleCreate peut être surchargée si nécessaire comme dans l'exemple suivant .

Une tâche utilisateur correspond à un Manager Component

Services natifs

Les services suivants sont fournis nativement :

• Accéder à un contenu.

• Créer un nouvel enregistrement.

• Valider une branche, une version ou une instance d'adaptation.

• Fusionner une branche.

• Comparer des contenus.

• Exporter des données d'une table vers des fichiers XML.

• Exporter des données d'une table vers des fichiers CSV.

• Importer des données dans une table à partir d'un fichier XML.

• Importer des données dans une table à partir d'un fichier CSV.

UI services spécifiques

En plus des services natifs, l'utilisateur peut définir un service UI spécifique sur une adaptation, une branche ou une version.

Déclaration d'un UI service

Les services UI spécifiques doivent être déclarés dans module.xml pour être rendus disponibles dans la définition des tâches manuelles, comme dans l'exemple suivant .

Pour des informations supplémentaires, voir également InteractionHelper .

Extension de service

Il est possible d'étendre des services dans module.xml. L'extension de service est disponible pour tous les types de service (natifs, module, d'adaptation). Grâce au mécanisme d'extension, l'utilisateur peut créer un nouveau service à partir d'un service existant avec ses propres libellé et description et des propriétés supplémentaires. De cette manière, l'utilisateur a la possibilité d'ajouter des paramètres spécifiques à des services natifs (uniquement des paramètres d'entrée pour les services natifs).

Sauf pour les services natifs, l'extension du service et le service étendu doivent être déclarés dans le même fichier module.xml.

Les extensions de service ne peuvent pas être étendues à leur tour. La surcharge des propriétés n'est pas permise.

Pour des informations supplémentaires, voir également InteractionHelper .

Variables en entrée

Les noms de ces variables correspondent aux variables d'entrée du service à appeller. Elles sont automatiquement affichées quand l'utilisateur sélectionne un service dans la liste déroulante (l'affichage est basé sur la déclaration du service dans module.xml).

La valorisation peut correspondre soit à une variable issue du DataContext sous la forme ${variable}, soit à une constante.

Variables en sortie

La valeur correspond au mapping à réaliser dans le DataContext. Ainsi, le paramètre en sortie xpath peut correspondre à code dans le DataContext.

Les variables de sortie sont automatiquement affichées quand l'utilisateur sélectionne un service dans la liste déroulante (l'affichage est basé sur la déclaration du service dans module.xml).

Rejet optionnel

Par défaut, le rejet est désactivé. Dans ce mode, seul le bouton 'Accepter' est affiché durant l'exécution des bons de travail.

Il est possible d'activer le rejet pour une tâche manuelle, dans l'écran de définition d'une tâche manuelle.

Tâches temporelles

Le workflow fournit deux fonctionnalités pour contrôler que les tâches manuelles sont terminées à temps.

Relance mail

Il est possible de spécifier une périodicité pour la relance mail (en jours). Quand le temps de la période indiquée est dépassé, une notification de travail à effectuer est envoyée de nouveau pour les tâches manuelles qui ne sont pas terminées. La relance mail a lieu tant que la tâche n'est pas terminée (au maximum un rappel par jour).

Date limite

Une tâche manuelle peut avoir une date limite. Quand cette date est atteinte, et que la tâche n'est pas terminée, un mail spécifique est envoyé aux utilisateurs concernés, afin de les alerter. Une fois la date limite atteinte, un mail est envoyé une fois par jour.

La périodicité des contrôles peut être spécifiée : pour plus d'information, voir la configuration du workflow.

Il y a deux types de date limite : 

• Date limite absolue : date calendaire.

• Date limite relative : durée (en heure, jour ou mois). La durée est évaluée à partir d'une date de référence : soit au début de la tâche manuelle, soit au début de l'instance de procédure.

Lien entre les étapes

Deux étapes peuvent être reliées entre elles. Une relation peut être qualifiée de trois manières différentes :

• OTHER : cas général, enchaîne deux étapes sans condition.

• ifTrue : cas d'une condition ; enchaîne deux étapes si le résultat de la condition est vrai.

• ifFalse : cas d'une condition ; enchaîne deux étapes si le résultat de la condition est faux.

Home > Workflow