Les modèles de workflow se composent d’une série d’étapes de différents types. En fonction de leur type, ces étapes peuvent être configurées et étendues avec des paramètres et des scripts pour fournir les fonctionnalités et le contrôle dont vous avez besoin.
Cette section présente les étapes de workflow standard.
Pour les étapes spécifiques aux modules, voir également :
Chaque composant d’étape comporte une Propriétés de l’étape qui vous permet de définir et de modifier les propriétés requises.
Une combinaison des propriétés suivantes est disponible pour la plupart des composants d’étape de workflow, sous l’onglet Commun de la boîte de dialogue Propriétés :
Titre
Titre de l’étape.
Description
Description de l’étape.
Étape du workflow
Sélecteur de liste déroulante auquel appliquer une Évaluation à l’étape .
Délai dépassé
Délai au bout duquel l’étape expire.
Vous avez le choix entre : Désactivé, Immédiat, 1 h, 6 h, 12 h et 24 h.
Gestionnaire de dépassement de délai
Gestionnaire qui contrôle le workflow lorsque l’étape expire, par exemple :
Auto Advancer
Avance du gestionnaire
Sélectionnez cette option pour avancer automatiquement le workflow à l’étape suivante après l’exécution. Si cette option n’est pas sélectionnée, le script de mise en œuvre doit gérer l’avancement du workflow.
Les propriétés suivantes sont disponibles pour de nombreux composants d’étape de workflow, sous l’onglet Utilisateur/Groupe de la boîte de dialogue Propriétés :
Avertir l’utilisateur par courrier électronique
Utilisateur/Groupe
La division ET crée une division dans le workflow, après quoi les deux branches sont actives. Vous ajoutez des étapes de workflow à chaque branche selon vos besoins. Cette étape vous permet d’ajouter plusieurs chemins de traitement dans le workflow. Par exemple, vous pouvez autoriser l’exécution de certaines étapes de révision en parallèle, ce qui représente un réel gain de temps.
Modifiez la variable Division ET properties:
Ajoutez des étapes de workflow aux branches selon vos besoins.
A Conteneur Cette étape lance un autre modèle de workflow qui s’exécute en tant que workflow enfant.
Ceci Conteneur permet de réutiliser des modèles de workflow pour implémenter des séquences d’étapes courantes. Par exemple, un modèle de workflow de traduction peut être utilisé dans plusieurs workflows de modification.
Pour configurer l’étape, modifiez et utilisez les onglets suivants :
Conteneur
Atteindre l’étape permet de spécifier la prochaine étape du modèle de workflow à exécuter, selon le résultat d’un ECMAScript :
true
: Atteindre l’étape se termine et le moteur de workflow exécute l’étape spécifiée.
false
: Atteindre l’étape se termine et la logique de routage normale détermine la prochaine étape à exécuter.
L’Étape Goto vous permet de mettre en œuvre des structures de routage avancées dans vos modèles de workflow. Par exemple, pour mettre en oeuvre une boucle, l’événement Atteindre l’étape peut être défini pour exécuter une étape précédente du workflow, avec le script évaluant une condition de boucle.
Pour configurer l’étape, modifiez et utilisez les onglets suivants :
Processus
Spécifiez le chemin du script ou le script. Les deux options ne peuvent pas être utilisées simultanément. Si vous spécifiez des valeurs dans les deux propriétés, l’étape utilise le chemin du script.
La simulation d’une boucle for requiert que vous comptiez le nombre d’itérations de boucle qui se sont produites :
Par exemple, pour mettre en œuvre un workflow qui effectue une action sur plusieurs nœuds JCR, vous pouvez utiliser un compteur de boucles en tant qu’index pour les nœuds. Pour rendre le compte persistant, stockez une valeur integer
dans le mappage de données de l’instance de workflow. Utilisez le script de l’Étape Goto pour incrémenter le nombre, ainsi que pour comparer le nombre au critère de sortie.
function check(){
var count=0;
var keyname="loopcount"
try{
if (workflowData.getMetaDataMap().containsKey(keyname)){
log.info("goto script: found loopcount key");
count= parseInt(workflowData.getMetaDataMap().get(keyname))+1;
}
workflowData.getMetaDataMap().put(keyname,count);
}catch(err) {
log.info(err.message);
return false;
}
if (parseInt(count) <7){
return true;
} else {
return false;
}
}
La division OU crée une division dans le workflow, après quoi seule une branche est active. Cette étape permet d’ajouter des chemins de traitement conditionnels dans le processus. Vous ajoutez des étapes de processus à chaque branche selon vos besoins.
Pour plus d’informations sur la création d’une Division OU, consultez : https://helpx.adobe.com/experience-manager/using/aem64_workflow_servlet.html.
Modifiez la variable Division OU properties:
Commun
Branche : x>
Il existe un onglet distinct pour chaque branche :
Spécifiez le chemin du script ou le script. Les deux options ne peuvent pas être utilisées simultanément. Si vous spécifiez des valeurs dans les deux propriétés, l’étape utilise le chemin du script.
Ajoutez des étapes de workflow aux branches selon vos besoins.
Une étape du participant vous permet d’attribuer la possession d’une action particulière. Le workflow s’exécute uniquement lorsque l’utilisateur a manuellement reconnu l’étape. Cette fonction est utile lorsque vous souhaitez que quelqu’un d’autre agisse sur le workflow, par exemple, lors d’une étape de révision.
Bien que ceci ne soit pas directement associé, l’autorisation de l’utilisateur doit être prise en compte lors de l’attribution d’une action ; l’utilisateur doit avoir accès à la page qui est la charge utile du workflow.
Pour configurer l’étape, modifiez et utilisez les onglets suivants :
L’initiateur du workflow est toujours averti lorsque :
Certaines propriétés doivent être configurées pour activer les notifications électroniques. Vous pouvez également personnaliser le modèle de courrier électronique ou en ajouter un pour une nouvelle langue. Pour configurer des notifications par e-mail dans AEM, consultez la section Configuration des notifications par e-mail.
Utilisez une étape de participant de boîte de dialogue pour collecter des informations provenant de l’utilisateur qui se voit attribuer l’élément de travail. Cette étape est utile pour collecter de petites quantités de données utilisées ultérieurement dans le workflow.
Lors de chaque étape, la boîte de dialogue Terminer l’élément de travail contient des champs que vous définissez dans la boîte de dialogue. Les données collectées dans les champs sont stockées dans les nœuds de la charge utile du workflow. Les étapes de workflow suivantes peuvent ensuite lire la valeur à partir du référentiel.
Pour configurer l’étape, vous spécifiez le groupe ou l’utilisateur auquel attribuer l’élément de travail et le chemin de la boîte de dialogue.
Pour configurer l’étape, modifiez et utilisez les onglets suivants :
Boîte de dialogue
Pour créer une boîte de dialogue :
Vous pouvez stocker des données de widget dans la charge utile de workflow ou dans les métadonnées d’élément de travail. Le format de la propriété name
du nœud de widget détermine l’endroit où les données sont stockées.
Stockage des données avec le payload
Pour stocker des données de widget en tant que propriété du payload de workflow, utilisez le format suivant pour la propriété de nom du nœud de widget :
./jcr:content/nodename
Les données sont stockées dans la propriété nodename
du nœud de payload. Si le nœud ne contient pas cette propriété, elle est créée.
Une fois les données stockées avec la charge utile, les utilisations suivantes de la boîte de dialogue avec la même charge utile remplacent la valeur de la propriété.
Stockage des données avec l’élément de travail
Pour stocker des données de widget en tant que propriété de métadonnées d’élément de travail, utilisez le format suivant pour la valeur de la propriété de nom :
nodename
Les données sont stockées dans la propriété nodename
des metadata
de l’élément de travail. Les données sont conservées si la boîte de dialogue utilisée ultérieurement présente la même charge utile.
Structure de boîte de dialogue
Les boîtes de dialogue des étapes de participant de boîte de dialogue sont similaires aux boîtes de dialogue que vous créez pour les composants de création. Elles sont stockées sous :
/apps/myapp/workflow/dialogs
Les boîtes de dialogue de l’IU standard compatible avec les écrans tactiles présentent la structure de nœud suivante :
newComponent (cq:Component)
|- cq:dialog (nt:unstructured)
|- content
|- layout
|- items
|- column
|- items
|- component0
|- component1
|- ...
Pour plus d’informations, voir Création et configuration d’une boîte de dialogue.
Propriété Chemin de la boîte de dialogue
L’étape de participant de la boîte de dialogue possède la propriété Chemin de la boîte de dialogue (ainsi que les propriétés d’une étape de participant). La valeur de la propriété Chemin de la boîte de dialogue est le chemin du nœud dialog
de la boîte de dialogue.
Par exemple, la boîte de dialogue se trouve dans un composant nommé EmailWatch
qui est stocké dans le nœud :
/apps/myapp/workflows/dialogs
Pour l’IU compatible avec les écrans tactiles, la valeur suivante est utilisée pour la propriété Chemin de la boîte de dialogue :
/apps/myapp/workflow/dialogs/EmailWatch/cq:dialog
Exemple de définition de boîte de dialogue
Le fragment de code XML ci-après représente une boîte de dialogue qui stocke une valeur de String
chaîne dans le nœud watchEmail
du contenu du payload. Le nœud de titre représente le composant textfield :
jcr:primaryType="nt:unstructured"
jcr:title="Watcher Email Address Dialog"
sling:resourceType="cq/gui/components/authoring/dialog">
<content jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/foundation/container">
<layout jcr:primaryType="nt:unstructured"
margin="false"
sling:resourceType="granite/ui/components/foundation/layouts/fixedcolumns"
/>
<items jcr:primaryType="nt:unstructured">
<column jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/foundation/container">
<items jcr:primaryType="nt:unstructured">
<title jcr:primaryType="nt:unstructured"
fieldLabel="Notification Email Address"
name="./jcr:content/watchEmails"
sling:resourceType="granite/ui/components/foundation/form/textfield"
/>
</items>
</column>
</items>
</content>
</cq:dialog>
Dans le cas de l’IU compatible avec les écrans tactiles, cet exemple produit une boîte de dialogue similaire à la suivante :
Le composant Étape choix dynamique de participant est semblable à l’étape du participant à la différence que le participant est choisi automatiquement à l’exécution.
Pour configurer l’étape, vous sélectionnez un programme de sélection des participants qui identifie le participant auquel attribuer l’élément de travail, ainsi qu’une boîte de dialogue.
Pour configurer l’étape, modifiez et utilisez les onglets suivants :
Programme de sélection des participants
Boîte de dialogue
Vous créez le programme de sélection des participants. Par conséquent, vous pouvez utiliser toute logique ou tout critère de sélection. Par exemple, le programme de sélection des participants peut sélectionner l’utilisateur (dans un groupe) qui a le moins d’éléments de travail. Vous pouvez créer un nombre illimité de programmes de sélection des participants à utiliser avec des instances différentes du composant Étape choix dynamique de participant dans vos modèles de workflow.
Créez un service OSGi ou un ECMAScript qui sélectionne un utilisateur auquel attribuer l’élément de travail.
ECMAscript
Les scripts doivent intégrer une fonction nommée getParticipant qui renvoie un ID utilisateur comme valeur de String
. Stockez vos scripts personnalisés, par exemple, dans le dossier /apps/myapp/workflow/scripts
ou dans un sous-dossier.
Un exemple de script est inclus dans une instance AEM standard :
/libs/workflow/scripts/initiator-participant-chooser.ecma
Vous ne devez rien modifier dans le chemin /libs
.
Cela est dû au fait que le contenu de /libs
sera écrasé la prochaine fois que vous mettrez à niveau votre instance (et éventuellement lors de l’application d’un correctif logiciel ou d’un pack de fonctionnalités).
Ce script choisit l’initiateur de workflow en tant que participant :
function getParticipant() {
return workItem.getWorkflow().getInitiator();
}
Le composant Programme de sélection des participants de l’initiateur de workflow étend l’étape de participant dynamique et utilise ce script comme mise en œuvre de l’étape.
Service OSGi
Les services doivent mettre en œuvre l’interface com.day.cq.workflow.exec.ParticipantStepChooser. L’interface définit les membres suivants :
SERVICE_PROPERTY_LABEL
: utilisez-le pour spécifier le nom du programme de sélection des participants. Le nom s’affiche dans la liste des programmes de sélection des participants disponibles dans les propriétés d’Étape de participant dynamique.getParticipant
: renvoie l’ID d’entité de sécurité résolue dynamiquement en tant que valeur de String
.La méthode getParticipant
renvoie l’ID d’entité de sécurité résolue dynamiquement. Il peut s’agir d’un ID de groupe ou d’utilisateur.
Toutefois, un ID de groupe ne peut être utilisé pour une étape de participant, lorsqu’une liste de participants est renvoyée. Pour une étape de participant dynamique, une liste vide est renvoyée et elle ne peut pas être utilisée pour la délégation.
Pour rendre votre mise en œuvre disponible pour les composants d’Étape de participant dynamique, ajoutez votre classe Java à un lot OSGi qui exporte le service et déployez le lot vers le serveur AEM.
Le programme de sélection aléatoire des participants est un exemple de service qui sélectionne un utilisateur aléatoire (com.day.cq.workflow.impl.process.RandomParticipantChooser
). Le Programme de sélection aléatoire des participants exemple de composant d’étape étend Étape choix dynamique de participant et utilise ce service comme implémentation de l’étape.
La classe Java suivante met en œuvre l’interface ParticipantStepChooser
. La classe renvoie le nom du participant qui a initié le workflow. Le code utilise la même logique que l’exemple de script (initator-participant-chooser.ecma
).
L’annotation @Property
définit la valeur du champ SERVICE_PROPERTY_LABEL
sur Workflow Initiator Participant Chooser
.
package com.adobe.example;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Properties;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;
import org.osgi.framework.Constants;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.adobe.granite.workflow.WorkflowException;
import com.adobe.granite.workflow.WorkflowSession;
import com.adobe.granite.workflow.exec.ParticipantStepChooser;
import com.adobe.granite.workflow.exec.WorkItem;
import com.adobe.granite.workflow.metadata.MetaDataMap;
@Component
@Service
@Properties({
@Property(name = Constants.SERVICE_DESCRIPTION, value = "An example implementation of a dynamic participant chooser."),
@Property(name = ParticipantStepChooser.SERVICE_PROPERTY_LABEL, value = "Workflow Initiator Participant Chooser (service)") })
public class InitiatorParticipantChooser implements ParticipantStepChooser {
private Logger logger = LoggerFactory.getLogger(this.getClass());
public String getParticipant(WorkItem arg0, WorkflowSession arg1,
MetaDataMap arg2) throws WorkflowException {
String initiator = arg0.getWorkflow().getInitiator();
logger.info("Assigning Dynamic Participant Step work item to {}",initiator);
return initiator;
}
}
Dans la boîte de dialogue des propriétés d’Étape de participant dynamique, la liste Programme de sélection des participants inclut l’élément Workflow Initiator Participant Chooser (script)
, qui représente ce service.
``Lorsque le modèle de workflow est démarré, le journal indique l’ID de l’utilisateur qui a initié le workflow et qui se voit attribuer l’élément de travail. Dans cet exemple, l’utilisateur admin
a lancé le workflow.
13.09.2015 15:48:53.037 *INFO* [10.176.129.223 [1347565733037] POST /etc/workflow/instances HTTP/1.1] com.adobe.example.InitiatorParticipantChooser Assigning Dynamic Participant Step work item to admin
L’étape de participant du formulaire présente un formulaire lorsque l’élément de travail est ouvert. Lorsque l’utilisateur remplit et envoie le formulaire, les données de champs sont stockées dans les nœuds de la charge utile du workflow.
Pour configurer l’étape, vous spécifiez le groupe ou l’utilisateur auquel attribuer l’élément de travail et le chemin du formulaire.
Cette section traite de la section Formulaires des composants de base pour la création de pages.
Pour configurer l’étape, modifiez et utilisez les onglets suivants :
Formulaire
Créez un formulaire à utiliser avec une étape de participant du formulaire de façon normale. Toutefois, les formulaires d’une étape de participant du formulaire doivent avoir les configurations suivantes :
Le composant Début de formulaire doit avoir la propriété Type d’action définie sur Edit Workflow Controlled Resource(s)
.
Le composant Début de formulaire doit présenter une valeur pour la propriété Form Identifier
.
Les composants de formulaire doivent présenter la propriété Nom de l’élément définie sur le chemin du nœud dans lequel les données de champs sont stockées. Le chemin doit pouvoir localiser un nœud dans le contenu de la charge utile du workflow. La valeur utilise le format suivant :
./jcr:content/path_to_node
Le formulaire doit inclure un composant Bouton(s) d’envoi du workflow. Vous ne configurez pas de propriétés du composant.
Les exigences de votre workflow indiquent où vous devez stocker les données de champs. Par exemple, les données de champs peuvent être utilisées pour configurer les propriétés du contenu de la page. La valeur suivante d’une propriété Nom de l’élément stocke les données de champs comme valeur de la propriété redirectTarget
du nœud jcr:content
:
./jcr:content/redirectTarget
Dans l’exemple suivant, les données de champs sont utilisées en tant que contenu d’un composant Texte sur la page du payload :
./jcr:content/par/text_3/text
"Le premier exemple peut être utilisé pour n’importe quelle page qui cq:Page
effectue le rendu du composant. Le second exemple peut uniquement être utilisé lorsque la page du payload inclut un composant Texte possédant l’ID text_3
.
Le formulaire peut se trouver n’importe où dans le référentiel, toutefois les utilisateurs du workflow doivent être autorisés à lire le formulaire.
L’étape Programme de sélection aléatoire des participants est un programme de sélection des participants qui attribue l’élément de travail généré à un utilisateur qui est choisi de manière aléatoire à partir d’une liste.
Pour configurer l’étape, modifiez et utilisez les onglets suivants :
Arguments
L’étape Programme de sélection des participants de l’initiateur de workflow est un programme de sélection des participants qui attribue l’élément de travail généré à l’utilisateur qui a démarré le workflow. Il n’y a aucune propriété à configurer à part les propriétés de l’onglet Courant.
Pour configurer l’étape, modifiez-la à l’aide des onglets suivants :
A Étape du processus exécute un ECMAScript ou appelle un service OSGi pour effectuer un traitement automatique.
Pour configurer l’étape, modifiez et utilisez les onglets suivants :
Processus
Processus : mise en œuvre de processus à exécuter. Utilisez le menu déroulant pour sélectionner ECMAScript ou Service OSGi. Pour obtenir des informations sur :
Avance du gestionnaire : sélectionnez cette option pour avancer automatiquement le workflow à l’étape suivante après l’exécution. Si cette option n’est pas sélectionnée, le script de mise en œuvre doit gérer l’avancement du workflow.
Arguments : arguments à transmettre au processus.