Cette rubrique explique comment créer des composants d’étape personnalisée pour des processus et interagir avec eux par programmation.
La création d’une étape personnalisée de processus implique les tâches suivantes :
Vous pouvez également interagir avec vos processus à partir de vos programmes et scripts.
Un composant d’étape de processus définit l’apparence et le comportement de l’étape lors de la création de modèles de processus :
Comme avec tous les composants, les composants de l’étape de processus héritent du composant indiqué pour la propriété sling:resourceSuperType
. Le diagramme suivant présente la hiérarchie des nœuds cq:component
qui constituent la base de tous les composants des étapes de processus. Le diagramme comprend également la variable Étape du processus, Étape du participant, et Étape choix dynamique de participant , car il s’agit des points de départ les plus courants (et les plus basiques) pour le développement de composants d’étape personnalisés.
Vous ne devez rien modifier dans le chemin /libs
.
En effet, le contenu de /libs
est remplacé dès que vous mettez à niveau votre instance (et risque de l’être si vous appliquez un correctif ou un Feature Pack).
La méthode recommandée pour la configuration et d’autres modifications est la suivante :
/libs
under /apps
/apps
Le /libs/cq/workflow/components/model/step
est l’ancêtre commun le plus proche de Étape du processus, Étape du participant, et Étape choix dynamique de participant, qui héritent toutes des éléments suivants :
step.jsp
Le step.jsp
Le script effectue le rendu du titre du composant step lorsqu’il est ajouté à un modèle.
Une boîte de dialogue avec les onglets suivants :
Lorsque les onglets de la boîte de dialogue de modification d’un composant d’étape ne correspondent pas à cette apparence par défaut, le composant d’étape a défini des scripts, des propriétés de nœud ou des onglets de dialogue qui remplacent ces onglets hérités.
Les objets suivants sont disponibles (selon le type d’étape) dans les scripts ECMA :
WorkItem workItem
WorkflowSession workflowSession
WorkflowData workflowData
args
: matrice contenant les arguments du processus.
sling
: pour accéder à d’autres services osgi.
jcrSession
Vous pouvez utiliser les métadonnées de processus pour conserver les informations requises pendant la durée de vie du processus. De manière générale, avec les étapes de processus, il faut conserver les données pour les utiliser ultérieurement dans le processus ou récupérer les données persistantes.
Il existe trois types d’objets MetaDataMap : pour Workflow
, WorkflowData
et WorkItem
objets. Ils ont tous le même objectif prévu : stocker les métadonnées.
Un objet WorkItem possède son propre objet MetaDataMap qui peut être utilisé uniquement pendant l’exécution de cet élément de travail (par exemple, l’étape).
Les Workflow
et WorkflowData
les métadonnées sont partagées sur l’ensemble du workflow. Pour ces cas, il est recommandé d’utiliser uniquement l’objet MetaDataMap WorkflowData
.
Les composants d’étape de processus se créent comme tout autre composant.
Pour hériter de l’un des composants de l’étape de base (existante), ajoutez la propriété suivante au nœud cq:Component
:
Nom : sling:resourceSuperType
Type : String
Valeur : l’un des chemins suivants qui se résout en un composant de base :
cq/workflow/components/model/process
cq/workflow/components/model/participant
cq/workflow/components/model/dynamic_participant
Utilisez la procédure suivante pour spécifier les valeurs par défaut des champs Titre et Description dans l’onglet Courant.
Les valeurs de champ apparaissent sur l’instance d’étape lorsque les deux conditions suivantes sont remplies :
La boîte de dialogue de modification de l’étape stocke le titre et la description dans les emplacements suivants : >
./jcr:title
./jcr:description
emplacements
Cette exigence est satisfaite lorsque la boîte de dialogue de modification utilise l’onglet Commun , qui indique que la variable /libs/cq/flow/components/step/step
met en oeuvre le composant .
Le composant d’étape ou un ancêtre du composant ne remplace pas la propriété step.jsp
qui /libs/cq/flow/components/step/step
met en oeuvre le composant .
Sous la section cq:Component
, ajoutez le noeud suivant :
cq:editConfig
cq:EditConfig
Pour plus d’informations sur le noeud cq:editConfig , voir Configuration du comportement de modification d’un composant.
Sous la section cq:EditConfig
, ajoutez le noeud suivant :
cq:formParameters
nt:unstructured
Ajouter String
des noms suivants à la propriété cq:formParameters
node:
jcr:title
: la valeur remplit le champ Titre de l’onglet Courant.jcr:description
: la valeur remplit le champ Description de l’onglet Courant.Voir Persistance et accès aux données. En particulier, pour plus d’informations sur l’accès à la valeur de la propriété lors de l’exécution, reportez-vous à la section Accès aux valeurs des propriétés de boîte de dialogue au moment de l’exécution.
La propriété name des éléments cq:Widget
spécifie le nœud JCR qui stocke la valeur du widget. Lorsque des widgets dans la boîte de dialogue de l’étape du processus, les composants stockent des valeurs sous la balise ./metaData
, la valeur est ajoutée au workflow. MetaDataMap
.
Par exemple, un champ de texte dans une boîte de dialogue est un nœud cq:Widget
qui possède les propriétés suivantes :
Nom | Type | Valeur |
---|---|---|
xtype |
String |
textarea |
name |
String |
./metaData/subject |
fieldLabel |
String |
Email Subject |
La valeur spécifiée dans ce champ de texte est ajoutée à la variable [MetaDataMap](#metadatamaps)
et est associé à l’objet subject
clé.
Lorsque la clé est PROCESS_ARGS
, la valeur est immédiatement disponible dans les implémentations de script ECMA via la variable args
. Dans ce cas, la valeur de la propriété name est ./metaData/PROCESS_ARGS.
Chaque composant d’étape de base permet aux développeurs de modèles de workflow de configurer les fonctionnalités clés suivantes au moment de la conception :
Pour utiliser le composant dans un scénario de processus spécifique, configurez la fonctionnalité clé au moment de la conception et empêchez les développeurs de modèles de la modifier.
Sous le nœud cq:component, ajoutez le nœud suivant :
cq:editConfig
cq:EditConfig
Pour plus d’informations sur le nœud cq:editConfig, voir Configuration du comportement de modification d’un composant.
Sous le nœud cq:EditConfig, ajoutez le nœud suivant :
cq:formParameters
nt:unstructured
Ajouter un String
à la propriété cq:formParameters
noeud . Le supertype de composant détermine le nom de la propriété :
PROCESS
PARTICIPANT
DYNAMIC_PARTICIPANT
Définissez la valeur de la propriété :
PROCESS
: chemin d’accès au script ECMA ou au PID du service qui implémente le comportement de l’étape.PARTICIPANT
: ID de l’utilisateur à qui l’élément de travail a été affecté.DYNAMIC_PARTICIPANT
: Le chemin d’accès au script ECMA ou au PID du service qui sélectionne l’utilisateur pour affecter l’élément de travail.Pour empêcher les développeurs de modèles de modifier vos valeurs de propriété, remplacez la boîte de dialogue du supertype de composant.
Personnalisez votre composant d’étape de participant afin de fournir les fonctionnalités disponibles dans la section Étape de participant du formulaire et Étape de participant de la boîte de dialogue composants :
Procédez comme suit sur votre nouveau composant (voir Création de composants d’étape de processus personnalisés) :
Sous la section cq:Component
, ajoutez le noeud suivant :
cq:editConfig
cq:EditConfig
Pour plus d’informations sur le noeud cq:editConfig , voir Configuration du comportement de modification d’un composant.
Sous le nœud cq:EditConfig, ajoutez le nœud suivant :
cq:formParameters
nt:unstructured
Pour présenter un formulaire lorsque l’utilisateur ouvre l’élément de travail, ajoutez la propriété suivante au nœud cq:formParameters
:
FORM_PATH
String
Pour présenter une boîte de dialogue personnalisée lorsque l’utilisateur effectue l’élément de travail, ajoutez la propriété suivante au nœud cq:formParameters
DIALOG_PATH
String
Sous la section cq:Component
noeud, ajoutez une cq:EditConfig
noeud . Sous , ajoutez une nt:unstructured
noeud (doit être nommé cq:formParameters
) et à ce noeud, ajoutez les propriétés suivantes :
Nom : PROCESS_AUTO_ADVANCE
Type : Boolean
Valeur:
true
Le workflow exécute cette étape et continue : cette étape est par défaut et elle est également recommandée.false
, le processus s’exécute et s’arrête. Ceci nécessite une manipulation supplémentaire, donc la valeur true
est recommandéeNom : DO_NOTIFY
Boolean
Vous pouvez utiliser les métadonnées de processus pour conserver les informations requises pendant la durée de vie du processus et entre les étapes. De manière générale, avec les étapes de processus, il faut rendre les données persistantes pour les utiliser ultérieurement ou récupérer les données persistantes à partir d’étapes précédentes.
Les métadonnées de processus sont stockées dans un objet MetaDataMap
. L’API Java fournit la variable Workflow.getWorkflowData
pour renvoyer une méthode WorkflowData
qui fournit les MetaDataMap
. Ceci WorkflowData
MetaDataMap
est disponible pour le service OSGi ou le script ECMA d’un composant d’étape.
La méthode execute de l’implémentation WorkflowProcess
est transmise à l’objet WorkItem
. Utilisez cet objet afin d’obtenir l’objet WorkflowData
pour l’instance de processus active. L’exemple suivant ajoute un élément à l’objet processus MetaDataMap
, puis enregistre chaque élément. L’élément ("mykey", "My Step Value") est disponible pour les étapes suivantes du processus.
public void execute(WorkItem item, WorkflowSession session, MetaDataMap args) throws WorkflowException {
MetaDataMap wfd = item.getWorkflow().getWorkflowData().getMetaDataMap();
wfd.put("mykey", "My Step Value");
Set<String> keyset = wfd.keySet();
Iterator<String> i = keyset.iterator();
while (i.hasNext()){
Object key = i.next();
log.info("The workflow medata includes key {} and value {}",key.toString(),wfd.get(key).toString());
}
}
La variable graniteWorkItem
est la représentation de script ECMA de l’objet Java WorkItem
actif. Par conséquent, vous pouvez utiliser la variable graniteWorkItem
pour obtenir les métadonnées de processus. Le script ECMA suivant peut être utilisé pour implémenter un composant Étape du processus afin d’ajouter un élément à l’objet de processus MetaDataMap
, puis consigner chaque élément. Ces éléments sont ensuite disponibles pour les étapes suivantes du processus.
La variable metaData
immédiatement disponible pour le script de l’étape est la métadonnée de l’étape. Les métadonnées d’étape sont différentes des métadonnées de processus.
var currentDateInMillis = new Date().getTime();
graniteWorkItem.getWorkflowData().getMetaDataMap().put("hardcodedKey","theKey");
graniteWorkItem.getWorkflowData().getMetaDataMap().put("currentDateInMillisKey",currentDateInMillis);
var iterator = graniteWorkItem.getWorkflowData().getMetaDataMap().keySet().iterator();
while (iterator.hasNext()){
var key = iterator.next();
log.info("Workflow metadata key, value = " + key.toString() + ", " + graniteWorkItem.getWorkflowData().getMetaDataMap().get(key));
}
L’objet MetaDataMap
des instances de processus est utile pour stocker et récupérer des données tout au long de la durée de vie du processus. Dans le cas d’implémentations de composants d’étape de processus, l’objet MetaDataMap
est particulièrement utile pour récupérer les valeurs de propriété de composant au moment de l’exécution.
Pour plus d’informations sur la configuration de la boîte de dialogue de composant dans le but de stocker les propriétés en tant que métadonnées de processus, voir Enregistrement des valeurs de propriété dans les métadonnées de processus.
Le processus MetaDataMap
est disponible pour les implémentations de processus de script Java et ECMA :
Dans les implémentations Java de l’interface WorkflowProcess, la variable args
est le paramètre MetaDataMap
pour le workflow.
Dans les implémentations de script ECMA, la valeur est disponible à l’aide de la propriété args
et metadata
.
La boîte de dialogue de modification du composant Étape du processus inclut la propriété Arguments. La valeur de la variable Arguments est stockée dans les métadonnées du workflow et est associée à la propriété PROCESS_ARGS
clé.
Dans le diagramme suivant, la valeur de la variable Arguments est argument1, argument2
:
Le code Java suivant est la méthode execute
pour une implémentation WorkflowProcess
. La méthode consigne la valeur dans la variable args
MetaDataMap
qui est associé à la variable PROCESS_ARGS
clé.
public void execute(WorkItem item, WorkflowSession session, MetaDataMap args) throws WorkflowException {
if (args.containsKey("PROCESS_ARGS")){
log.info("workflow metadata for key PROCESS_ARGS and value {}",args.get("PROCESS_ARGS","string").toString());
}
}
Lorsqu’une étape de processus qui utilise cette implémentation Java s’exécute, le journal contient l’entrée suivante :
16.02.2018 12:07:39.566 *INFO* [JobHandler: /var/workflow/instances/server0/2018-02-16/model_855140139900189:/content/we-retail/de] com.adobe.example.workflow.impl.process.LogArguments workflow metadata for key PROCESS_ARGS and value argument1, argument2
Le script ECMA suivant est utilisé comme processus pour Étape du processus. Il consigne le nombre d’arguments et les valeurs des arguments :
var iterator = graniteWorkItem.getWorkflowData().getMetaDataMap().keySet().iterator();
while (iterator.hasNext()){
var key = iterator.next();
log.info("Workflow metadata key, value = " + key.toString() + ", " + graniteWorkItem.getWorkflowData().getMetaDataMap().get(key));
}
log.info("hardcodedKey "+ graniteWorkItem.getWorkflowData().getMetaDataMap().get("hardcodedKey"));
log.info("currentDateInMillisKey "+ graniteWorkItem.getWorkflowData().getMetaDataMap().get("currentDateInMillisKey"));
Cette section explique comment utiliser les arguments pour les étapes de processus. L’information s’applique également aux programmes de sélection des participants.
Pour un autre exemple de stockage des propriétés de composant dans les métadonnées de processus, voir Exemple : Créer une étape de processus de logger. Cet exemple comporte un journal qui associe la valeur des métadonnées à une clé autre que PROCESS_ARGS.
Dans un script pour un composant Étape du processus, les arguments sont disponibles via l’objet args
.
Lors de la création d’un composant d’étape personnalisé, l’objet metaData
est disponible dans un script. Cet objet est limité à un seul argument de chaîne.
Lorsque les étapes de processus sont lancées au cours du traitement d’un processus, les étapes envoient une requête à un service OSGi ou exécutent un script ECMA. Développez le service ou le script ECMA qui effectue les actions requises par votre processus.
Pour plus d’informations sur l’association de votre composant Étape du processus avec le service ou le script, reportez-vous à Étape du processus ou Remplacement de la mise en œuvre de l’étape.
Pour définir une étape de processus en tant que composant de service OSGI (bundle Java) :
Créez le bundle et déployez-le dans le conteneur OSGI. Reportez-vous à la documentation sur la création d’un lot avec CRXDE Lite ou Eclipse.
Le composant OSGI doit mettre en oeuvre la variable WorkflowProcess
son interface execute()
. Voir l’exemple de code ci-dessous.
Le nom du module doit être ajouté à la variable <*Private-Package*>
de la section maven-bundle-plugin
configuration.
Ajout de la propriété SCR process.label
et définissez la valeur selon vos besoins. Il s’agit du nom sous lequel votre étape de processus est répertoriée lors de l’utilisation du générique Étape du processus composant. Voir l’exemple ci-dessous.
Dans le Modèles éditeur, ajoutez l’étape de processus au workflow à l’aide du générique Étape du processus composant.
Dans la boîte de dialogue de modification (de la Étape du processus), accédez au Processus et sélectionnez votre implémentation de processus.
Si vous utilisez des arguments dans votre code, définissez la variable Arguments de processus. Par exemple : false.
Enregistrez les modifications, à la fois pour l’étape et le modèle de processus (angle supérieur gauche de l’éditeur de modèle).
Les méthodes java, respectivement les classes implémentant la méthode Java exécutable, sont enregistrées en tant que services OSGI, ce qui vous permet d’ajouter des méthodes à tout moment pendant l’exécution.
Le composant OSGI suivant ajoute la propriété approved
au nœud de contenu de page lorsque la charge est une page :
package com.adobe.example.workflow.impl.process;
import com.adobe.granite.workflow.WorkflowException;
import com.adobe.granite.workflow.WorkflowSession;
import com.adobe.granite.workflow.exec.WorkItem;
import com.adobe.granite.workflow.exec.WorkflowData;
import com.adobe.granite.workflow.exec.WorkflowProcess;
import com.adobe.granite.workflow.metadata.MetaDataMap;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;
import org.osgi.framework.Constants;
import javax.jcr.Node;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
/**
* Sample workflow process that sets an <code>approve</code> property to the payload based on the process argument value.
*/
@Component
@Service
public class MyProcess implements WorkflowProcess {
@Property(value = "An example workflow process implementation.")
static final String DESCRIPTION = Constants.SERVICE_DESCRIPTION;
@Property(value = "Adobe")
static final String VENDOR = Constants.SERVICE_VENDOR;
@Property(value = "My Sample Workflow Process")
static final String LABEL="process.label";
private static final String TYPE_JCR_PATH = "JCR_PATH";
public void execute(WorkItem item, WorkflowSession session, MetaDataMap args) throws WorkflowException {
WorkflowData workflowData = item.getWorkflowData();
if (workflowData.getPayloadType().equals(TYPE_JCR_PATH)) {
String path = workflowData.getPayload().toString() + "/jcr:content";
try {
Session jcrSession = session.adaptTo(Session.class);
Node node = (Node) jcrSession.getItem(path);
if (node != null) {
node.setProperty("approved", readArgument(args));
jcrSession.save();
}
} catch (RepositoryException e) {
throw new WorkflowException(e.getMessage(), e);
}
}
}
private boolean readArgument(MetaDataMap args) {
String argument = args.get("PROCESS_ARGS", "false");
return argument.equalsIgnoreCase("true");
}
}
Si le processus échoue trois fois de suite, un élément est placé dans la boîte de réception de l’administrateur de processus.
Les scripts ECMA permettent aux développeurs de scripts d’implémenter des étapes de processus. Les scripts sont situés dans le référentiel JCR et exécutés à partir de cet endroit.
Le tableau suivant répertorie les variables qui sont immédiatement disponibles pour traiter les scripts, en fournissant l’accès aux objets de l’API Java de processus.
Classe Java | Nom de variable de script | Description |
---|---|---|
com.adobe.granite.workflow.exec.WorkItem |
graniteWorkItem |
Instance de l’étape en cours. |
com.adobe.granite.workflow.WorkflowSession |
graniteWorkflowSession |
Session de workflow de l’instance d’étape actuelle. |
String[] (contient des arguments de processus) |
args |
Arguments de l’étape. |
com.adobe.granite.workflow.metadata.MetaDataMap |
metaData |
Métadonnées de l’instance d’étape actuelle. |
org.apache.sling.scripting.core.impl.InternalScriptHelper |
sling |
Permet d’accéder à l’environnement d’exécution Sling. |
L’exemple de script suivant montre comment accéder au nœud JCR qui représente la charge utile du processus. La variable graniteWorkflowSession
est adaptée à une variable de session JCR, utilisée pour obtenir le nœud à partir du chemin d’accès de la charge utile.
var workflowData = graniteWorkItem.getWorkflowData();
if (workflowData.getPayloadType() == "JCR_PATH") {
var path = workflowData.getPayload().toString();
var jcrsession = graniteWorkflowSession.adaptTo(Packages.javax.jcr.Session);
var node = jcrsession.getNode(path);
if (node.hasProperty("approved")){
node.setProperty("approved", args[0] == "true" ? true : false);
node.save();
}
}
Le script suivant vérifie si la payload est une image ( .png
), crée une image en noir et blanc et l’enregistre en tant que noeud frère.
var workflowData = graniteWorkItem.getWorkflowData();
if (workflowData.getPayloadType() == "JCR_PATH") {
var path = workflowData.getPayload().toString();
var jcrsession = graniteWorkflowSession.adaptTo(Packages.javax.jcr.Session);
var node = jcrsession.getRootNode().getNode(path.substring(1));
if (node.isNodeType("nt:file") && node.getProperty("jcr:content/jcr:mimeType").getString().indexOf("image/") == 0) {
var is = node.getProperty("jcr:content/jcr:data").getStream();
var layer = new Packages.com.day.image.Layer(is);
layer.grayscale();
var parent = node.getParent();
var gn = parent.addNode("grey" + node.getName(), "nt:file");
var content = gn.addNode("jcr:content", "nt:resource");
content.setProperty("jcr:mimeType","image/png");
var cal = Packages.java.util.Calendar.getInstance();
content.setProperty("jcr:lastModified",cal);
var f = Packages.java.io.File.createTempFile("test",".png");
var tout = new Packages.java.io.FileOutputStream(f);
layer.write("image/png", 1.0, tout);
var fis = new Packages.java.io.FileInputStream(f);
content.setProperty("jcr:data", fis);
parent.save();
tout.close();
fis.close();
is.close();
f.deleteOnExit();
}
}
Pour utiliser le script :
Créez le script (par exemple avec CRXDE Lite) et enregistrez-le dans le référentiel ci-dessous. /apps/myapp/workflow/scripts
Pour spécifier un titre qui identifie le script dans la boîte de dialogue de modification Étape du processus, ajoutez les propriétés suivantes au nœud jcr:content
de votre script :
Nom | Type | Valeur |
---|---|---|
jcr:mixinTypes |
Name[] |
mix:title |
jcr:title |
String |
Nom à afficher dans la boîte de dialogue de modification. |
Modifiez l’instance Étape du processus et spécifiez le script à utiliser.
Vous pouvez développer des programmes de sélection de participant pour les composants Étape choix dynamique de participant.
Lorsqu’une Étape choix dynamique de participant est démarré pendant un workflow, l’étape doit déterminer le participant auquel l’élément de travail généré peut être affecté. Pour ce faire, l’étape :
Vous pouvez développer un service ou un script ECMA qui sélectionne le participant en fonction des exigences de votre processus.
Pour plus d’informations sur l’association de votre composant Étape choix dynamique de participant au service ou au script, voir Étape choix dynamique de participant ou Remplacement de la mise en œuvre de l’étape.
Pour définir une étape de participant en tant que composant de service OSGI (classe Java) :
Le composant OSGI doit mettre en oeuvre la variable ParticipantStepChooser
son interface getParticipant()
. Voir l’exemple de code ci-dessous.
Créez le bundle et déployez-le dans le conteneur OSGI.
Ajout de la propriété SCR chooser.label
et définissez la valeur selon les besoins. Il s’agit du nom sous lequel votre programme de sélection des participants est répertorié, à l’aide de la variable Étape choix dynamique de participant composant. Voir l’exemple :
package com.adobe.example.workflow.impl.process;
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.exec.WorkflowData;
import com.adobe.granite.workflow.metadata.MetaDataMap;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;
import org.osgi.framework.Constants;
/**
* Sample dynamic participant step that determines the participant based on a path given as argument.
*/
@Component
@Service
public class MyDynamicParticipant implements ParticipantStepChooser {
@Property(value = "An example implementation of a dynamic participant chooser.")
static final String DESCRIPTION = Constants.SERVICE_DESCRIPTION;
@Property(value = "Adobe")
static final String VENDOR = Constants.SERVICE_VENDOR;
@Property(value = "Dynamic Participant Chooser Process")
static final String LABEL=ParticipantStepChooser.SERVICE_PROPERTY_LABEL;
private static final String TYPE_JCR_PATH = "JCR_PATH";
public String getParticipant(WorkItem workItem, WorkflowSession workflowSession, MetaDataMap args) throws WorkflowException {
WorkflowData workflowData = workItem.getWorkflowData();
if (workflowData.getPayloadType().equals(TYPE_JCR_PATH)) {
String path = workflowData.getPayload().toString();
String pathFromArgument = args.get("PROCESS_ARGS", String.class);
if (pathFromArgument != null && path.startsWith(pathFromArgument)) {
return "admin";
}
}
return "administrators";
}
}
Dans le Modèles , ajoutez l’étape participant dynamique au workflow à l’aide de l’éditeur générique Étape choix dynamique de participant composant.
Dans la boîte de dialogue de modification, sélectionnez l’option Programme de sélection des participants et sélectionnez l’implémentation de votre programme de sélection.
Si vous utilisez des arguments dans votre code, définissez la variable Arguments de processus. Pour cet exemple : /content/we-retail/de
.
Enregistrez les modifications, à la fois pour l’étape et le modèle de processus.
Vous pouvez créer un script ECMA qui sélectionne l’utilisateur auquel est affecté l’élément de travail généré par Étape du participant. Le script doit inclure une fonction nommée getParticipant
qui ne nécessite aucun argument et renvoie une String
qui contient l’identifiant d’un utilisateur ou d’un groupe.
Les scripts sont situés dans le référentiel JCR et exécutés à partir de cet endroit.
Le tableau suivant répertorie les variables qui fournissent un accès immédiat aux objets Java de processus dans vos scripts.
Classe Java | Nom de variable de script |
---|---|
com.adobe.granite.workflow.exec.WorkItem |
graniteWorkItem |
com.adobe.granite.workflow.WorkflowSession |
graniteWorkflowSession |
String[] (contient des arguments de processus) |
args |
com.adobe.granite.workflow.metadata.MetaDataMap |
metaData |
org.apache.sling.scripting.core.impl.InternalScriptHelper |
sling |
function getParticipant() {
var workflowData = graniteWorkItem.getWorkflowData();
if (workflowData.getPayloadType() == "JCR_PATH") {
var path = workflowData.getPayload().toString();
if (path.indexOf("/content/we-retail/de") == 0) {
return "admin";
} else {
return "administrators";
}
}
}
Créez le script (par exemple avec CRXDE Lite) et enregistrez-le dans le référentiel ci-dessous. /apps/myapp/workflow/scripts
Pour spécifier un titre qui identifie le script dans la boîte de dialogue de modification Étape du processus, ajoutez les propriétés suivantes au nœud jcr:content
de votre script :
Nom | Type | Valeur |
---|---|---|
jcr:mixinTypes |
Name[] |
mix:title |
jcr:title |
String |
Nom à afficher dans la boîte de dialogue de modification. |
Modifiez la variable Étape choix dynamique de participant et indiquez le script à utiliser.
Les modules de processus peuvent être transmis à un processus pour traitement. Les modules de processus contiennent des références à des ressources telles que des pages et des éléments.
Les étapes de traitement de processus suivantes acceptent les modules de processus pour l’activation de page en masse :
Vous pouvez développer des étapes de processus qui obtiennent les ressources de module et les traitent. Les membres suivants du module com.day.cq.workflow.collection
donnent accès aux modules de processus :
ResourceCollection
: Classe de module de processus.ResourceCollectionUtil
: permet de récupérer des objets ResourceCollection.ResourceCollectionManager
: Crée et récupère des collections. Une implémentation est déployée en tant que service OSGi.L’exemple de classe Java suivant montre comment obtenir des ressources de module :
package com.adobe.example;
import java.util.ArrayList;
import java.util.List;
import com.day.cq.workflow.WorkflowException;
import com.day.cq.workflow.WorkflowSession;
import com.day.cq.workflow.collection.ResourceCollection;
import com.day.cq.workflow.collection.ResourceCollectionManager;
import com.day.cq.workflow.collection.ResourceCollectionUtil;
import com.day.cq.workflow.exec.WorkItem;
import com.day.cq.workflow.exec.WorkflowData;
import com.day.cq.workflow.exec.WorkflowProcess;
import com.day.cq.workflow.metadata.MetaDataMap;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;
import org.apache.felix.scr.annotations.Reference;
import org.osgi.framework.Constants;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import javax.jcr.Node;
import javax.jcr.PathNotFoundException;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
@Component
@Service
public class LaunchBulkActivate implements WorkflowProcess {
private static final Logger log = LoggerFactory.getLogger(LaunchBulkActivate.class);
@Property(value="Bulk Activate for Launches")
static final String PROCESS_NAME ="process.label";
@Property(value="A sample workflow process step to support Launches bulk activation of pages")
static final String SERVICE_DESCRIPTION = Constants.SERVICE_DESCRIPTION;
@Reference
private ResourceCollectionManager rcManager;
public void execute(WorkItem workItem, WorkflowSession workflowSession) throws Exception {
Session session = workflowSession.getSession();
WorkflowData data = workItem.getWorkflowData();
String path = null;
String type = data.getPayloadType();
if (type.equals(TYPE_JCR_PATH) && data.getPayload() != null) {
String payloadData = (String) data.getPayload();
if (session.itemExists(payloadData)) {
path = payloadData;
}
} else if (data.getPayload() != null && type.equals(TYPE_JCR_UUID)) {
Node node = session.getNodeByUUID((String) data.getPayload());
path = node.getPath();
}
// CUSTOMIZED CODE IF REQUIRED....
if (path != null) {
// check for resource collection
ResourceCollection rcCollection = ResourceCollectionUtil.getResourceCollection((Node)session.getItem(path), rcManager);
// get list of paths to replicate (no resource collection: size == 1
// otherwise size >= 1
List<String> paths = getPaths(path, rcCollection);
for (String aPath: paths) {
// CUSTOMIZED CODE....
}
} else {
log.warn("Cannot process because path is null for this " + "workitem: " + workItem.toString());
}
}
/**
* helper
*/
private List<String> getPaths(String path, ResourceCollection rcCollection) {
List<String> paths = new ArrayList<String>();
if (rcCollection == null) {
paths.add(path);
} else {
log.debug("ResourceCollection detected " + rcCollection.getPath());
// this is a resource collection. the collection itself is not
// replicated. only its members
try {
List<Node> members = rcCollection.list(new String[]{"cq:Page", "dam:Asset"});
for (Node member: members) {
String mPath = member.getPath();
paths.add(mPath);
}
} catch(RepositoryException re) {
log.error("Cannot build path list out of the resource collection " + rcCollection.getPath());
}
}
return paths;
}
}
Pour commencer facilement à créer votre propre étape personnalisée, copiez une étape existante à partir de :
/libs/cq/workflow/components/model
Recréez le chemin sous /apps, par exemple :
/apps/cq/workflow/components/model
Les nouveaux dossiers sont de type nt:folder
:
- apps
- cq
- workflow (nt:folder)
- components (nt:folder)
- model (nt:folder)
Cette étape ne s’applique pas à l’éditeur de modèle de l’IU classique.
Placez ensuite l’étape copiée dans votre dossier /apps, par exemple comme :
/apps/cq/workflow/components/model/myCustomStep
Voici le résultat de notre exemple d’étape personnalisée :
Puisque dans l’IU standard, seul le titre, et non les détails, est affiché sur la carte, details.jsp
n’est pas nécessaire (comme c’était le cas avec l’éditeur de l’IU classique).
Appliquez les propriétés suivantes au nœud :
/apps/cq/workflow/components/model/myCustomStep
Propriétés d’intérêt :
sling:resourceSuperType
Doit hériter d’une étape existante.
Dans cet exemple, nous héritons de l’étape de base à l’adresse cq/workflow/components/model/step
, mais vous pouvez utiliser d’autres super types comme participant
, process
, etc.
jcr:title
Le titre est-il affiché lorsque le composant est répertorié dans le navigateur d’étapes (panneau de gauche de l’éditeur de modèle de processus).
cq:icon
Utilisé pour spécifier une Icône Coral pour l’étape .
componentGroup
Doit être l’un des suivants :
Vous pouvez désormais ouvrir un modèle de processus pour le modifier. Dans le navigateur d’étapes, vous pouvez filtrer pour voir Mon étape personnalisée :
Si vous faites glisser Mon étape personnalisée sur le modèle, la carte s’affiche :
Si la propriété cq:icon
n’a pas été définie pour l’étape, une icône par défaut est rendue d’après les deux premières lettres du titre. Par exemple :
Après avoir suivi la procédure Création de l’étape de base, définissez la boîte de dialogue Configurer comme suit :
Configuration des propriétés sur le noeud cq:editConfig
comme suit :
Propriétés d’intérêt :
cq:inherit
Lorsque la variable est définie sur true
, alors votre composant d’étape héritera des propriétés de l’étape que vous avez spécifiée dans sling:resourceSuperType
.
cq:disableTargeting
Définissez le paramètre selon vos besoins.
Configuration des propriétés sur le noeud cq:formsParameter
comme suit :
Propriétés d’intérêt :
jcr:title
Définit le titre par défaut sur la carte étape dans la carte modèle et dans le champ Titre de la boîte de dialogue de configuration Mes propriétés d’étape personnalisées.
Vous pouvez également définir vos propres propriétés personnalisées.
Configuration des propriétés sur le noeud cq:listeners
.
Le nœud cq:listener
et ses propriétés vous permettent de définir des gestionnaires d’événements réagissant aux événements dans l’éditeur de modèles de l’IU tactile, le glisser d’une étape sur une page de modèle ou la modification des propriétés d’une étape.
Propriétés d’intérêt :
afterMove: REFRESH_PAGE
afterdelete: CQ.workflow.flow.Step.afterDelete
afteredit: CQ.workflow.flow.Step.afterEdit
afterinsert: CQ.workflow.flow.Step.afterInsert
Cette configuration est essentielle au bon fonctionnement de l’éditeur. Dans la plupart des cas, cette configuration ne doit pas être modifiée.
Toutefois, la définition de cq:inherit
sur true (sur la cq:editConfig
, voir ci-dessus) vous permet d’hériter de cette configuration, sans avoir à l’inclure explicitement dans votre définition d’étape. Si aucun héritage n’est en place, vous devez ajouter ce noeud avec les propriétés et valeurs suivantes.
Dans cet exemple, l’héritage a été activé pour pouvoir supprimer le nœud cq:listeners
et permettre à l’étape de fonctionner correctement.
Vous pouvez désormais ajouter une instance de votre étape à un modèle de processus. Lorsque vous configurez l’étape vous voyez s’afficher la boîte de dialogue :
Le balisage d’une étape personnalisée est représenté dans la variable .content.xml
du noeud racine du composant. L’exemple .content.xml
utilisé pour cet exemple :
/apps/cq/workflow/components/model/myCustomStep/.content.xml
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="https://sling.apache.org/jcr/sling/1.0" xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
cq:icon="bell"
jcr:primaryType="cq:Component"
jcr:title="My Custom Step"
sling:resourceSuperType="cq/workflow/components/model/process"
allowedParents="[*/parsys]"
componentGroup="Workflow"/>
Le _cq_editConfig.xml
exemple utilisé dans cet exemple :
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:nt="https://www.jcp.org/jcr/nt/1.0"
cq:disableTargeting="{Boolean}true"
cq:inherit="{Boolean}true"
jcr:primaryType="cq:EditConfig">
<cq:formParameters
jcr:primaryType="nt:unstructured"
jcr:title="My Custom Step Card"
SAMPLE_PROPERY="sample value"/>
<cq:listeners
jcr:primaryType="cq:EditListenersConfig"
afterdelete="CQ.workflow.flow.Step.afterDelete"
afteredit="CQ.workflow.flow.Step.afterEdit"
afterinsert="CQ.workflow.flow.Step.afterInsert"
afterMove="REFRESH_PAGE"/>
</jcr:root>
Le _cq_dialog/.content.xml
exemple utilisé dans cet exemple :
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="https://sling.apache.org/jcr/sling/1.0" xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:nt="https://www.jcp.org/jcr/nt/1.0"
jcr:primaryType="nt:unstructured"
jcr:title="My Custom - Step Properties"
sling:resourceType="cq/gui/components/authoring/dialog">
<content
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/tabs">
<items jcr:primaryType="nt:unstructured">
<common
cq:hideOnEdit="true"
jcr:primaryType="nt:unstructured"
jcr:title="Common"
sling:resourceType="granite/ui/components/coral/foundation/fixedcolumns"/>
<process
cq:hideOnEdit="true"
jcr:primaryType="nt:unstructured"
jcr:title="Process"
sling:resourceType="granite/ui/components/coral/foundation/fixedcolumns"/>
<mycommon
jcr:primaryType="nt:unstructured"
jcr:title="Common"
sling:resourceType="granite/ui/components/coral/foundation/fixedcolumns">
<items jcr:primaryType="nt:unstructured">
<columns
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/container">
<items jcr:primaryType="nt:unstructured">
<title
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/form/textfield"
fieldLabel="Title"
name="./jcr:title"/>
<description
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/form/textarea"
fieldLabel="Description"
name="./jcr:description"/>
</items>
</columns>
</items>
</mycommon>
<advanced
jcr:primaryType="nt:unstructured"
jcr:title="Advanced"
sling:resourceType="granite/ui/components/coral/foundation/fixedcolumns">
<items jcr:primaryType="nt:unstructured">
<columns
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/container">
<items jcr:primaryType="nt:unstructured">
<email
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/form/checkbox"
fieldDescription="Notify user via email."
fieldLabel="Email"
name="./metaData/PROCESS_AUTO_ADVANCE"
text="Notify user via email."
value="true"/>
</items>
</columns>
</items>
</advanced>
</items>
</content>
</jcr:root>
Notez les nœuds communs et de processus dans la définition de la boîte de dialogue. Ils sont hérités de l’étape de processus que nous avons utilisée comme supertype pour notre étape personnalisée :
sling:resourceSuperType : cq/workflow/components/model/process
Les boîtes de dialogue classiques de l’éditeur de modèle de l’IU classique continuent de fonctionner avec celui de l’IU standard tactile.
AEM a outils de modernisation si vous souhaitez mettre à niveau vos boîtes de dialogue d’étape de l’IU classique vers des boîtes de dialogue d’interface utilisateur standard. Une fois la conversion terminée, vous devez apporter quelques améliorations manuelles à la boîte de dialogue pour certains cas.
Si une boîte de dialogue mise à niveau est vide, vous pouvez consulter les boîtes de dialogue dans /libs
qui présentent des fonctionnalités similaires comme des exemples de comment fournir une solution. Par exemple :
/libs/cq/workflow/components/model
/libs/cq/workflow/components/workflow
/libs/dam/components
/libs/wcm/workflow/components/autoassign
/libs/cq/projects
Vous ne devez rien modifier dans /libs
, utilisez-les simplement comme exemples. Si vous souhaitez utiliser l’une des étapes existantes, copiez-les dans /apps
et modifiez-les ici.