Cloud Software Group, Inc. EBX®
Documentation > Guide utilisateur > Modèles de workflow
Mode navigation Documentation > Guide utilisateur > Modèles de workflow

# 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 (sauf les tâches utilisateurs à multi bons de travail), 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. Le cas où cette propriété est ignorée est le suivant : 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.

Dans le cas des appels sous-workflows, une propriété dédiée "Sous-workflow de premier plan" est disponible pour la stratégie d'avancement. Pour la stratégie d'avancement "Ouvrir automatiquement le prochain bon de travail", un sous-workflow de premier plan doit être sélectionné. Seuelemnt les tâches de ce sous-workflow de premier plan et leurs stratégies d'avancement seront évaluées. Veuillez noter les règles spécifiques de la propriété sous-workflow de premier plan.

- Si un seul sous-workflow est deployé, il sera automatiquement considéré comme premier plan,

- La propriété de sous-workflow de premier plan sera ignoré si l'étape précédante n'a pas sa stratégie d'avancement définit sur "Ouvrir automatiquement le prochain bon de travail",

- When all the sub-workflow are completed, and if the last completed sub-workflow is the foreground one, then the progress strategy defined on the sub-workflow invocation step is evaluated: if the progress strategy is « automatically open the next step », the next step can be opened without displaying the inbox. In all cases, the progress strategy of the last step of the sub-workflow is always ignored. Quand tous les sous-workflows sont temrinés et que le dernier complété est celui de premier plan, dans ce cas, la stratégie d'avancement de l'appel sous-workflow sera évaluée: si la stratégie est "Ouvrir automatiquement le prochain bon de travail", la prochaine étape sera ouverte au lieu d'ouvrir la corbeille. Dans tous les cas, la stratégie d'avancement de la dernière étape du sous-workflow sera ignorée.

### 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

- Extension

### 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

- Services prédéfinis de EBX®

### 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

- Modèles de message génériques

#### 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 trois types de tâches automatiques :

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 `module.xml`. Un script de la bibliothèque spécifique doit définir son libellé, sa description et ses paramètres. Quand un utilisateur sélectionne un script de la bibliothèque dans une étape d'un modèle de données, les paramètres associés sont affichés dynamiquement.
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 | Définie un script basé sur le langage DSL pour définir des opérations personnalisées. Le EBX® IDE est utilisé pour faciliter l'écriture des scripts. Un script est défini par son nom, son libellé, sa description et ses paramètres. Quand un utilisateur sélectionne le nom de script dans une étape d'un modèle de données, les paramètres associés sont affichés dynamiquement.

Packaging TIBCO EBX® modules

### 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.

### 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.

### Script

EBX® Script is un langage procedural basé sur DSL (Domain Specific Language). Il propose une large bibliothèque qui peut être utilisée pour définir des tâches personalisées.

La méthode executeScriptTask est appelée lorsque le workflow de données atteint l'étape correspondante. Voir les exemples.

## 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 `module.xml`. Une condition de la bibliothèque spécifique doit définir son libellé, sa description et ses paramètres. Quand un utilisateur sélectionne une condition de la bibliothèque dans une étape d'un modèle de données, les paramètres associés sont affichés dynamiquement.
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.

Packaging TIBCO EBX® modules

### 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.

The property « Foreground sub-workflow » is useful to precise the progress strategy when several sub-workflows are launched. If the previous step progress strategy is « directly open the next step », this property defines which sub-workflow should be considered in the foreground (only one sub-workflow can hold this behavior). Only the work items which have been generated in this foreground sub-workflow will be able to be opened automatically without passing by the inbox. If only one sub-workflow is defined, this property is ignored (the single sub-workflow is automatically considered in the foreground). La propriété "Sous-workflow de premier plan" est utile pour déterminer la stratégie d'avancement quand plusieurs sous-workflows sont lancés. Si la stratégie d'avancement de l'étape précédante est "Ouvrir automatiquement le prochain bon de travail", cette propriété définit quel sous-workflow sera considéré de premier plan (seulement un peu avoir ce comportement). Seul les bon de travail généré dans ce sous-workflow de premier plan pourront être ouvert automatiquement sans passer par la corbeille. Pour plus d'information, veuillez vous référez à la stratégie d'avancement : Stratégie d'avancement de l'étape suivante

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 `module.xml`. 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.

Ce service est accessible en vue par défaut dans l'éditeur de modèles de workflow et permet de faire l'intégralité des actions de création, d'édition et de suppression.

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 document PDF basé sur le modèle workflow. Vous pourrez configurer l'orientation des pages du pdf (Paysage, Portrait), la taille des pages (A3, Lettre, etc ...). Ainsi que deux propriétés qui pourraient donner plus de détail au modèle: Afficher les identifiants (valeur par défaut est vrai): Même comportement que "Afficher les identifants d'étapes" dans la barre d'outil du diagramme de workflow mais restreint pour l'export pdf. Les identifiants de chaque étapes seront affichées. Ajouter l'index (valeur par défaut est vrai): A la fin du pdf, un index listant chaque étapes du diagramme sera ajouté. Cela pourra être utile dans le cas où le titre de plusieurs étapes seraient trop long pour pouvoir être affiché dans leur intégralité. Pour cette propriété, il est recommandé d'afficher les identifiants des étapes puisqu'ils seront utiles pour savoir quelle ligne de l'index correspond à quelle étape.

### Vue

Mise en page > Mise en page par défaut | Applique la mise en page par défaut.
Affichage > Afficher/Masquer la grille | Affiche la grille lorsque celle-ci est invisible, sinon masque la grille.
Affichage > Zoomer | Fait un zoom sur le diagramme. Pour aller plus vite, vous pouvez utiliser Ctrl + molette vers le haut avec votre souris se trouvant dans la zone du diagramme.
Affichage > Dézoomer | Fait un dézoom sur le diagramme. Pour aller plus vite, vous pouvez utiliser Ctrl + molette vers le bas avec votre souris se trouvant dans la zone du diagramme, voir Vue
Affichage > Afficher/Masquer les identifiants d'étapes | Affiche ou masque une étiquette contenant l'identifiant d'une étape workflow.
Vues de plan > Hiérarchie | Si elle est activée, affiche la vue hiérarchique du modèle de workflow.

### 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.

### Edit

Création | Au survol ou à la sélection d'un lien, un bouton '+' apparaît. Ce dernier sert à la création d'une étape.
Suppression | SUPPR Le raccourci clavier "SUPPR'" supprime le noeud sélectionné. NB: cette action est irréversible.
Barre d'outils | Au survol ou à la sélection d'un noeud, une barre d'outils s'affiche. Elle sert à : Éditer une étape. Supprimer une étape. Dupliquer une étape. Ajouter une redirection vers une étape existante. Afficher ou cacher dans la vue d'exécution.
Éditer un noeud | Le double-clic permet d'éditer rapidement une étape.

### Fonctionnalités

La vue graphique offre également des fonctionnalités additionnelles

Annuler l'action précédente | CTRL + Z Les actions ci-dessous ne seront pas affectées par ce raccourci : Création/Suppression/Edition/Duplication d'une étape Déplacement de liens Afficher/Cacher dans la vue d'exécution Recharger
Zoomer/Dezoomer | Bouton du milieu de la souris puis roulette / CTRL puis roulette
Sélection multiple | cliquer 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

Documentation > Guide utilisateur > Modèles de workflow