Développement de projets dans AEM

Il s’agit d’un tutoriel de développement qui explique comment développer pour AEM Projects. Dans ce tutoriel, nous allons créer un modèle de projet personnalisé qui pourra être utilisé pour créer des projets dans AEM afin de gérer les processus et les tâches de création de contenu.

Cette vidéo présente une brève démonstration du processus terminé créé dans le tutoriel ci-dessous.

Présentation

AEM Projects est une fonctionnalité d’AEM conçue pour faciliter la gestion et le regroupement de tous les workflows et tâches associés à la création de contenu dans le cadre d’une mise en oeuvre d’AEM Sites ou d’Assets.

AEM Projets est fourni avec plusieurs Modèles de projet prêts à l’emploi. Lors de la création d’un projet, les auteurs peuvent choisir parmi ces modèles disponibles. Les mises en oeuvre d’AEM volumineuses avec des besoins commerciaux uniques voudront créer des modèles de projet personnalisés, adaptés à leurs besoins. En créant un modèle de projet personnalisé, les développeurs peuvent configurer le tableau de bord du projet, se connecter aux workflows personnalisés et créer des rôles professionnels supplémentaires pour un projet. Nous allons examiner la structure d’un modèle de projet et en créer un exemple.

Carte de projet personnalisée

Configuration

Ce tutoriel décrit le code nécessaire à la création d’un modèle de projet personnalisé. Vous pouvez télécharger et installer le package joint dans un environnement local à suivre avec le tutoriel. Vous pouvez également accéder au projet Maven complet hébergé sur GitHub.

Ce tutoriel suppose des connaissances de base sur les Bonnes pratiques de développement AEM et une certaine familiarité avec Configuration AEM projet Maven. Tout le code mentionné est destiné à être utilisé comme référence et ne doit être déployé que sur une instance d’AEM de développement local.

Structure d’un modèle de projet

Les modèles de projet doivent être placés sous contrôle source et doivent se trouver sous votre dossier d’application sous /apps. Idéalement, ils doivent être placés dans un sous-dossier avec la convention de dénomination de */projects/templates/<my-template>. En suivant cette convention d’affectation des noms, les nouveaux modèles personnalisés deviennent automatiquement disponibles pour les auteurs lors de la création d’un projet. La configuration des modèles de projet disponibles est définie à l’emplacement suivant : /content/projects/jcr:content par le noeud cq:allowedTemplates . Par défaut, il s’agit d’une expression régulière : /(apps|libs)/.*/projects/templates/.*

Le noeud racine d’un modèle de projet comporte un jcr:primaryType de cq:Template. Sous le noeud racine, il existe 3 noeuds : gadgets, rôles, et workflows. Ces noeuds sont tous nt:unstructured. Sous le noeud racine peut également se trouver un fichier thumbnail.png qui s’affiche lors de la sélection du modèle dans l’assistant Créer un projet .

La structure de noeud complète :

/apps/<my-app>
    + projects (nt:folder)
         + templates (nt:folder)
              + <project-template-root> (cq:Template)
                   + gadgets (nt:unstructured)
                   + roles (nt:unstructured)
                   + workflows (nt:unstructured)

Racine du modèle de projet

Le noeud racine du modèle de projet est de type cq:Template. Sur ce noeud, vous pouvez configurer des propriétés. jcr:title et jcr:description qui s’affiche dans l’assistant Créer un projet . Il existe également une propriété appelée assistant qui pointe vers un formulaire qui renseigne les propriétés du projet. La valeur par défaut de : /libs/cq/core/content/projects/wizard/steps/defaultproject.html devrait fonctionner normalement dans la plupart des cas, car cela permet à l’utilisateur de renseigner les propriétés de base du projet et d’ajouter des membres au groupe.

*Notez que l’assistant Créer un projet n’utilise pas le servlet du POST Sling. À la place, les valeurs sont publiées sur un servlet personnalisé :com.adobe.cq.projects.impl.servlet.ProjectServlet. Cela doit être pris en compte lors de l’ajout de champs personnalisés.

Vous trouverez un exemple d’assistant personnalisé pour le modèle de projet de traduction : /libs/cq/core/content/projects/wizard/translation/project/defaultproject.

Gadgets

Il n’existe aucune propriété supplémentaire sur ce noeud, à l’exception des enfants du noeud gadgets, qui contrôlent quelles mosaïques de projet renseignent le tableau de bord du projet lorsqu’un nouveau projet est créé. Mosaïques du projet (également appelés gadgets ou capsules) sont des cartes simples qui renseignent le lieu de travail d’un projet. Vous trouverez une liste complète des mosaïques d’usine sous : /libs/cq/gui/components/projects/admin/pod.  Les propriétaires de projet peuvent toujours ajouter/supprimer des mosaïques après la création d’un projet.

Rôles

Il y en a 3 Rôles par défaut pour chaque projet : Observateurs, Éditeurs, et Propriétaires. En ajoutant des noeuds enfants sous le noeud de rôles, vous pouvez ajouter des rôles de projet spécifiques à l’entreprise supplémentaires pour le modèle. Vous pouvez ensuite lier ces rôles à des workflows spécifiques associés au projet.

Workflows

L’une des raisons les plus attrayantes pour créer un modèle de projet personnalisé est qu’il vous donne la possibilité de configurer les workflows disponibles à utiliser avec le projet. Il peut s’agir de workflows prêts à l’emploi ou de workflows personnalisés. Sous la workflows doit être un noeud models Noeud (également nt:unstructured) et les noeuds enfants sous spécifient les modèles de workflow disponibles. La propriété modelId  pointe vers le modèle de workflow sous /etc/workflow et la propriété assistant pointe vers la boîte de dialogue utilisée lors du démarrage du workflow. L’avantage des projets est la possibilité d’ajouter une boîte de dialogue personnalisée (assistant) pour capturer des métadonnées spécifiques à l’entreprise au début du workflow, ce qui peut déclencher d’autres actions dans le workflow.

<projects-template-root> (cq:Template)
    + workflows (nt:unstructured)
         + models (nt:unstructured)
              + <workflow-model> (nt:unstructured)
                   - modelId = points to the workflow model
                   - wizard = dialog used to start the workflow

Création d’un modèle de projet

Puisque nous copions/configurons principalement des noeuds, nous utiliserons CRXDE Lite. Dans votre instance d’AEM locale, ouvrez CRXDE Lite.

Commencez par créer un dossier sous /apps/<your-app-folder> named projects. Créez un autre dossier sous celui nommé templates.
```
/apps/aem-guides/projects-tasks/
                    + projects (nt:folder)
                             + templates (nt:folder)
```
Pour faciliter les choses, nous allons démarrer notre modèle personnalisé à partir du modèle de projet simple existant.
1. Copiez et collez le noeud /libs/cq/core/content/projects/templates/default sous le templates dossier créé à l’étape 1.
```
/apps/aem-guides/projects-tasks/
             + templates (nt:folder)
                  + default (cq:Template)
```

Vous devriez maintenant avoir un chemin comme /apps/aem-guides/projects/projects/templates/authoring-project.

Modifiez la variable jcr:title et jcr:description propriétés du noeud author-project en valeurs de titre et de description personnalisées.
1. Laissez le champ assistant pointant vers les propriétés par défaut du projet.

/apps/aem-guides/projects-tasks/projects/
         + templates (nt:folder)
              + authoring-project (cq:Template)
                   - jcr:title = "Authoring Project"
                   - jcr:description = "A project to manage approval and publish process for AEM Sites or Assets"
                   - wizard = "/libs/cq/core/content/projects/wizard/steps/defaultproject.html"

Pour ce modèle de projet, nous voulons utiliser Tâches.

Ajouter un nouveau nt:unstructured noeud sous authoring-project/gadgets appelé tâches.
Ajoutez des propriétés String au noeud de tâches pour cardWeight = "100", jcr:title="Tâches" et sling:resourceType="cq/gui/components/projects/admin/pod/taskpod".

Maintenant, la Mosaïque Tâches s’affiche par défaut lors de la création d’un projet.

../projects/templates/authoring-project
    + gadgets (nt:unstructured)
         + team (nt:unstructured)
         + asset (nt:unstructured)
         + work (nt:unstructured)
         + experiences (nt:unstructured)
         + projectinfo (nt:unstructured)
         ..
         + tasks (nt:unstructured)
              - cardWeight = "100"
              - jcr:title = "Tasks"
              - sling:resourceType = "cq/gui/components/projects/admin/pod/taskpod"

Nous ajouterons un rôle d’approbateur personnalisé à notre modèle de projet.
1. Sous le noeud de modèle de projet (authoring-project), ajoutez une nouvelle nt:unstructured noeud étiqueté rôles.
2. Ajouter un autre nt:unstructured noeud "approbateurs" étiquetés en tant qu’enfant du noeud rôles.
3. Ajouter des propriétés de chaîne jcr:title = "Approbateurs", roleclass ="propriétaire", roleid="approbateurs".
  1. Le nom du noeud approbateurs, ainsi que jcr:title et roleid peuvent être n’importe quelle valeur de chaîne (tant que roleid est unique).
  2. roleclass détermine les autorisations appliquées à ce rôle en fonction de la variable [3 rôles OTB](https://docs.adobe.com/docs/en/aem/6-3/author/projects.html#User Rôles dans un projet) : propriétaire, éditeur, et observateur.
  3. En général, si le rôle personnalisé est davantage un rôle de gestion, la classe de rôles peut être propriétaire; s’il s’agit d’un rôle de création plus spécifique comme Photographe ou Designer, éditeur roleclass devrait suffire. La grande différence entre propriétaire et éditeur est que les propriétaires de projet peuvent mettre à jour les propriétés du projet et ajouter de nouveaux utilisateurs au projet.
```
../projects/templates/authoring-project
    + gadgets (nt:unstructured)
    + roles (nt:unstructured)
        + approvers (nt:unstructured)
             - jcr:title = "Approvers"
             - roleclass = "owner"
             - roleid = "approver"
```
En copiant le modèle Projet simple , vous obtiendrez 4 workflows prêts à l’emploi configurés. Chaque noeud sous workflows/modèles pointe vers un workflow spécifique et un assistant de démarrage de boîte de dialogue pour ce workflow. Plus loin dans ce tutoriel, nous allons créer un workflow personnalisé pour ce projet. Pour l’instant, supprimez les noeuds sous workflow/models :
```
../projects/templates/authoring-project
    + gadgets (nt:unstructured)
    + roles (nt:unstructured)
    + workflows (nt:unstructured)
         + models (nt:unstructured)
            - (remove ootb models)
```
Afin que les auteurs de contenu puissent facilement identifier le modèle de projet, vous pouvez ajouter une miniature personnalisée. La taille recommandée est de 319 x 319 pixels.
1. Dans CRXDE Lite, créez un fichier en tant que frère de gadgets, de rôles et de noeuds de processus nommés thumbnail.png.
2. Enregistrez, puis accédez au jcr:content et double-cliquez sur le noeud jcr:data (évitez de cliquer sur "afficher").
  1. Cela devrait vous inviter à modifier jcr:data et vous pouvez télécharger une miniature personnalisée.
```
../projects/templates/authoring-project
    + gadgets (nt:unstructured)
    + roles (nt:unstructured)
    + workflows (nt:unstructured)
    + thumbnail.png (nt:file)
```

Représentation XML terminée du modèle de projet :

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
    jcr:description="A project to manage approval and publish process for AEM Sites or Assets"
    jcr:primaryType="cq:Template"
    jcr:title="Authoring Project"
    ranking="{Long}1"
    wizard="/libs/cq/core/content/projects/wizard/steps/defaultproject.html">
    <jcr:content
        jcr:primaryType="nt:unstructured"
        detailsHref="/projects/details.html"/>
    <gadgets jcr:primaryType="nt:unstructured">
        <team
            jcr:primaryType="nt:unstructured"
            jcr:title="Team"
            sling:resourceType="cq/gui/components/projects/admin/pod/teampod"
            cardWeight="60"/>
        <tasks
            jcr:primaryType="nt:unstructured"
            jcr:title="Tasks"
            sling:resourceType="cq/gui/components/projects/admin/pod/taskpod"
            cardWeight="100"/>
        <work
            jcr:primaryType="nt:unstructured"
            jcr:title="Workflows"
            sling:resourceType="cq/gui/components/projects/admin/pod/workpod"
            cardWeight="80"/>
        <experiences
            jcr:primaryType="nt:unstructured"
            jcr:title="Experiences"
            sling:resourceType="cq/gui/components/projects/admin/pod/channelpod"
            cardWeight="90"/>
        <projectinfo
            jcr:primaryType="nt:unstructured"
            jcr:title="Project Info"
            sling:resourceType="cq/gui/components/projects/admin/pod/projectinfopod"
            cardWeight="100"/>
    </gadgets>
    <roles jcr:primaryType="nt:unstructured">
        <approvers
            jcr:primaryType="nt:unstructured"
            jcr:title="Approvers"
            roleclass="owner"
            roleid="approvers"/>
    </roles>
    <workflows
        jcr:primaryType="nt:unstructured"
        tags="[]">
        <models jcr:primaryType="nt:unstructured">
        </models>
    </workflows>
</jcr:root>

Test du modèle de projet personnalisé

Nous pouvons maintenant tester notre modèle de projet en créant un nouveau projet.

Vous devriez voir le modèle personnalisé comme l’une des options de création de projet.
Après avoir sélectionné le modèle personnalisé, cliquez sur "Suivant" et notez que lorsque vous renseignez les membres du projet, vous pouvez les ajouter en tant que rôle d’approbateur.
Cliquez sur "Créer" pour terminer la création du projet à partir du modèle personnalisé. Vous remarquerez sur le tableau de bord du projet que la mosaïque Tâches et les autres mosaïques configurées sous les gadgets apparaissent automatiquement.

Pourquoi un workflow ?

Les processus traditionnellement AEM qui se centrent autour d’un processus d’approbation utilisent les étapes de processus Participant . AEM boîte de réception contient des détails sur les tâches et les workflows et une intégration améliorée avec AEM Projects. Ces fonctionnalités rendent l’utilisation du processus de création de tâche des projets plus attrayante.

Pourquoi les tâches ?

L’utilisation d’une étape de création de tâche par rapport aux étapes Participant traditionnelles offre plusieurs avantages :

Date de début et d’échéance - facilite la gestion du temps par les auteurs. La nouvelle fonction Calendrier utilise ces dates.
Priorité - les priorités intégrées Faible, Normale et Élevée permettent aux auteurs de hiérarchiser les travaux.
Commentaires threads - lorsque les auteurs travaillent sur une tâche, ils ont la possibilité de laisser des commentaires accroissant la collaboration
Visibilité - Les mosaïques de tâches et les vues avec les projets permettent aux gestionnaires de déterminer le temps passé
Intégration de projets - Les tâches sont déjà intégrées aux rôles de projet et aux tableaux de bord

À l’instar des étapes Participant, les tâches peuvent être affectées et acheminées dynamiquement. Les métadonnées de tâche telles que Titre et Priorité peuvent également être définies dynamiquement en fonction des actions précédentes, comme nous le verrons dans le tutoriel suivant.

Bien que les tâches présentent certains avantages par rapport aux étapes du participant, elles comportent des frais supplémentaires et ne sont pas aussi utiles en dehors d’un projet. En outre, tous les comportements dynamiques des tâches doivent être codés à l’aide de scripts ecma ayant leurs propres limites.

Exemples d’exigences de cas d’utilisation

Diagramme de processus de workflow

Le diagramme ci-dessus décrit les exigences de haut niveau pour notre processus d’approbation des exemples.

La première étape consiste à créer une tâche pour terminer la modification d’un élément de contenu. Nous autoriserons l’initiateur du workflow à choisir la personne désignée pour cette première tâche.

Une fois la première tâche terminée, la personne désignée dispose de trois options pour le routage du workflow :

Normale  : le routage normal crée une tâche affectée au groupe Approbateur du projet pour révision et approbation. La priorité de la tâche est Normale et la date d'échéance est fixée à 5 jours à compter de sa création.

Rush - le routage des notifications push crée également une tâche affectée au groupe Approbateur du projet. La priorité de la tâche est Haute et la date d'échéance n'est que d'un jour.

Contournement - dans cet exemple de workflow, le participant initial a la possibilité de contourner le groupe de validation. (oui, cela peut déjouer l’objectif d’un workflow "Validation", mais cela nous permet d’illustrer des fonctionnalités de routage supplémentaires)

Le groupe d’approbateurs peut approuver le contenu ou le renvoyer à la personne désignée initiale pour le retravail. Dans le cas d’un renvoi en vue du retravail, une nouvelle tâche est créée et correctement étiquetée "Envoyé pour le retravail".

La dernière étape du workflow utilise l’étape de processus Activer la page/ressource de l’onglet et réplique la charge utile.

Création du modèle de workflow

Dans le menu AEM Démarrer, accédez à Outils -> Workflow -> Modèles. Cliquez sur "Créer" dans le coin supérieur droit pour créer un modèle de workflow.

Attribuez un titre au nouveau modèle : "Processus d’approbation de contenu" et un nom d’URL : "content-approval-workflow".

Pour plus d’informations sur les création de workflows lire ici.
Il est recommandé de regrouper les workflows personnalisés dans leur propre dossier sous /etc/workflow/models. Dans CRXDE Lite, créez une 'nt:folder' Sous /etc/workflow/models nommé "aem-guides". L’ajout d’un sous-dossier permet de s’assurer que les workflows personnalisés ne sont pas écrasés accidentellement lors des mises à niveau ou des installations du Service Pack.

*Notez qu’il est important de ne jamais placer le dossier ou les workflows personnalisés sous des sous-dossiers d’usine tels que /etc/workflow/models/dam ou /etc/workflow/models/projects, car le sous-dossier entier peut également être remplacé par des mises à niveau ou des Service Packs.

Emplacement du modèle de workflow dans la version 6.3

REMARQUE

Si vous utilisez AEM version 6.4+, l’emplacement du workflow a changé. Pour plus d’informations, rendez-vous ici.

Si vous utilisez AEM version 6.4+, le modèle de workflow est créé sous /conf/global/settings/workflow/models. Répétez les étapes ci-dessus avec le répertoire /conf et ajoutez un sous-dossier nommé aem-guides et déplacez le content-approval-workflow en-dessous.

Emplacement du modèle de workflow dans la version 6.4+
La possibilité d’ajouter des étapes de processus à un workflow donné est introduite dans AEM 6.3. Les étapes s’affichent pour l’utilisateur à partir de la boîte de réception dans l’onglet Informations sur le workflow . Il montre à l'utilisateur l'étape actuelle du workflow ainsi que les étapes qui le précèdent et qui le suivent.

Pour configurer les étapes, ouvrez la boîte de dialogue Propriétés de page dans le SideKick. Le quatrième onglet est intitulé "Phases". Ajoutez les valeurs suivantes pour paramétrer les trois étapes de ce workflow :
1. Modifier le contenu
2. Approbation
3. Publication
Configurez les phases de workflow dans la boîte de dialogue Propriétés de la page .

La barre de progression du workflow tel qu’elle s’affiche dans la boîte de réception AEM.

Vous pouvez éventuellement télécharger une Image dans les Propriétés de page utilisées comme miniature de workflow lorsque les utilisateurs la sélectionnent. Les dimensions de l’image doivent être de 319x319 pixels. Ajouter un Description Les propriétés de page s’affichent également lorsqu’un utilisateur sélectionne le workflow.
Le processus Créer une tâche de projet est conçu pour créer une tâche en tant qu’étape dans le processus. Ce n’est qu’après avoir terminé la tâche que le workflow sera avancé. L’étape Créer une tâche de projet présente un aspect puissant : elle peut lire les valeurs de métadonnées de workflow et les utiliser pour créer la tâche de manière dynamique.

Commencez par supprimer l’étape de participant qui est créée par défaut. Dans le sidekick du menu Composants, développez la variable "Projets" sous-titre et faites glisser et déposez le "Créer une tâche de projet" sur le modèle.

Double-cliquez sur l’étape "Créer une tâche de projet" pour ouvrir la boîte de dialogue du processus. Configurez les propriétés suivantes :

Cet onglet est commun à toutes les étapes du processus de workflow et nous définirons le Titre et la Description (ceux-ci ne seront pas visibles par l’utilisateur final). La propriété importante que nous définirons est l’étape du processus sur "Modifier le contenu" dans le menu déroulant.
```
Common Tab
-----------------
    Title = "Start Task Creation"
    Description = "This the first task in the Workflow"
    Workflow Stage = "Edit Content"
```
Le processus Créer une tâche de projet est conçu pour créer une tâche en tant qu’étape dans le processus. L’onglet Tâche permet de définir toutes les valeurs de la tâche. Dans notre cas, nous voulons que le cessionnaire soit dynamique, de sorte que nous le laisserons vide. Le reste des valeurs de propriété :
```
Task Tab
-----------------
    Name* = "Edit Content"
    Task Priority = "Medium"
    Description = "Edit the content and finalize for approval. Once finished submit for approval."
    Due In - Days = "2"
```
L’onglet Routage est une boîte de dialogue facultative qui peut spécifier les actions disponibles pour l’utilisateur qui effectue la tâche. Ces actions ne sont que des valeurs de chaîne et sont enregistrées dans les métadonnées du workflow. Ces valeurs peuvent être lues par des scripts et/ou des étapes de processus ultérieures du workflow pour "acheminer" dynamiquement le workflow. Selon la variable objectifs du workflow trois actions sont ajoutées à cet onglet :
```
Routing Tab
-----------------
    Actions =
        "Normal Approval"
        "Rush Approval"
        "Bypass Approval"
```
Cet onglet nous permet de configurer un script de création préalable de tâche dans lequel nous pouvons choisir par programmation différentes valeurs de la tâche avant qu’elle ne soit créée. Nous avons la possibilité de pointer le script vers un fichier externe ou d’incorporer un script court directement dans la boîte de dialogue. Dans notre cas, nous pointerons le script de création préalable de tâche vers un fichier externe. À l’étape 5, nous allons créer ce script.
```
Advanced Settings Tab
-----------------
   Pre-Create Task Script = "/apps/aem-guides/projects/scripts/start-task-config.ecma"
```
À l’étape précédente, nous avons référencé un script de précréation de tâche. Nous allons créer ce script dans lequel nous définirons le cessionnaire de la tâche en fonction de la valeur d’une valeur de métadonnées de workflow "cessionnaire". Le "cessionnaire" est définie au déclenchement du workflow. Nous allons également lire les métadonnées de workflow pour choisir dynamiquement la priorité de la tâche en lisant le "taskPriority" valeur des métadonnées du workflow, ainsi que la "taskdueDate"  à définir dynamiquement le moment où la première tâche doit être effectuée.

À des fins d’organisation, nous avons créé un dossier sous notre dossier d’application destiné à contenir tous les scripts liés au projet : /apps/aem-guides/projects-tasks/projects/scripts. Créez un fichier sous ce dossier nommé "start-task-config.ecma". *Notez que le chemin d’accès à votre fichier start-task-config.ecma correspond au chemin d’accès défini dans l’onglet Paramètres avancés de l’étape 4.

Ajoutez les éléments suivants comme contenu du fichier :
```
// start-task-config.ecma
// Populate the task using values stored as workflow metadata originally posted by the start workflow wizard

// set the assignee based on start workflow wizard
var assignee = workflowData.getMetaDataMap().get("assignee", Packages.java.lang.String);
task.setCurrentAssignee(assignee);

//Set the due date for the initial task based on start workflow wizard
var dueDate = workflowData.getMetaDataMap().get("taskDueDate", Packages.java.util.Date);
if (dueDate != null) {
    task.setProperty("taskDueDate", dueDate);
}

//Set the priority based on start workflow wizard
var taskPriority = workflowData.getMetaDataMap().get("taskPriority", "Medium");
task.setProperty("taskPriority", taskPriority);
```
Revenez au processus d’approbation du contenu. Faites glisser et déposez le Division OU composant (situé dans le sidekick sous la catégorie "Workflow") sous la propriété Tâche de début Étape Dans la boîte de dialogue commune, sélectionnez le bouton radio correspondant à 3 branches. La division OU lit la valeur des métadonnées du workflow. "lastTaskAction" pour déterminer l’itinéraire du workflow. Le "lastTaskAction" est définie sur l’une des valeurs de l’onglet Routage configuré à l’étape 4. Pour chacun des onglets Branche, renseignez la variable Script zone de texte avec les valeurs suivantes :
```
function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Normal Approval") {
    return true;
}

return false;
}
```
```
function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Rush Approval") {
    return true;
}

return false;
}
```
```
function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Bypass Approval") {
    return true;
}

return false;
}
```
*Notez que nous effectuons une correspondance de chaîne directe pour déterminer l’itinéraire. Il est donc important que les valeurs définies dans les scripts Branch correspondent aux valeurs d’itinéraire définies à l’étape 4.
Faites glisser et déposez un autre "Créer une tâche de projet" sur le modèle à l’extrême gauche (Branche 1) sous la division OU. Renseignez la boîte de dialogue avec les propriétés suivantes :
```
Common Tab
-----------------
    Title = "Approval Task Creation"
    Description = "Create a an approval task for Project Approvers. Priority is Medium."
    Workflow Stage = "Approval"

Task Tab
------------
    Name* = "Approve Content for Publish"
    Task Priority = "Medium"
    Description = "Approve this content for publication."
    Days = "5"

Routing Tab - Actions
----------------------------
    "Approve and Publish"
    "Send Back for Revision"
```
Puisqu’il s’agit de l’itinéraire de validation normal, la priorité de la tâche est définie sur Moyen. De plus, nous donnons au groupe des approbateurs 5 jours pour terminer la tâche. Le cessionnaire reste vide dans l’onglet Tâche , car nous l’affecterons de manière dynamique dans l’onglet Paramètres avancés . Nous donnons au groupe Approbateurs deux itinéraires possibles lors de l’exécution de cette tâche : "Approuver et publier" s’ils approuvent le contenu et qu’il peut être publié et "Retour en vue de la révision" si des problèmes doivent être corrigés par l’éditeur d’origine. L’approbateur peut laisser des commentaires que l’éditeur d’origine verra si le workflow lui est renvoyé.

Plus tôt dans ce tutoriel, nous avons créé un modèle de projet qui incluait un rôle d’approbateur. Chaque fois qu’un nouveau projet est créé à partir de ce modèle, un groupe spécifique au projet est créé pour le rôle Approbateurs . Tout comme une étape de participant, une tâche ne peut être affectée qu’à un utilisateur ou à un groupe. Nous souhaitons affecter cette tâche au groupe de projets correspondant au groupe Approbateurs . Tous les workflows lancés à partir d’un projet disposeront de métadonnées qui mappent les rôles de projet au groupe spécifique au projet.

Copiez+Collez le code suivant dans le Script zone de texte de l’onglet Paramètres avancés. Ce code lit les métadonnées du workflow et affecte la tâche au groupe Approbateurs du projet. S’il ne trouve pas la valeur du groupe d’approbateurs, il revient à attribuer la tâche au groupe Administrateurs.

var projectApproverGrp = workflowData.getMetaDataMap().get("project.group.approvers","administrators");

task.setCurrentAssignee(projectApproverGrp);

Faites glisser et déposez un autre "Créer une tâche de projet" à la branche centrale (Branche 2) sous la division OU. Renseignez la boîte de dialogue avec les propriétés suivantes :
```
Common Tab
-----------------
    Title = "Rush Approval Task Creation"
    Description = "Create a an approval task for Project Approvers. Priority is High."
    Workflow Stage = "Approval"

Task Tab
------------
    Name* = "Rush Approve Content for Publish"
    Task Priority = "High"
    Description = "Rush approve this content for publication."
    Days = "1"

Routing Tab - Actions
----------------------------
    "Approve and Publish"
    "Send Back for Revision"
```
Puisqu’il s’agit de l’itinéraire de validation push, la priorité de la tâche est définie sur Élevée. De plus, nous ne donnons au groupe Approbateurs qu’un seul jour pour terminer la tâche. Le cessionnaire reste vide dans l’onglet Tâche , car nous l’affecterons de manière dynamique dans l’onglet Paramètres avancés .

Nous pouvons réutiliser le même fragment de code de script que à l’étape 7 pour renseigner la variable Script zone de texte dans l’onglet  Paramètres avancés . Copiez+Collez le code ci-dessous :
```
var projectApproverGrp = workflowData.getMetaDataMap().get("project.group.approvers","administrators");

task.setCurrentAssignee(projectApproverGrp);
```
Faites glisser et déposez un composant  Aucune opération vers la branche d’extrême droite (Branche 3). Le composant Aucune opération n’effectue aucune action et progresse immédiatement, ce qui représente le désir de l’éditeur d’origine de contourner l’étape d’approbation. Techniquement, nous pourrions laisser cette branche sans aucune étape de workflow, mais nous allons ajouter une étape Aucune opération en tant que bonne pratique. Cela permet aux autres développeurs de déterminer l’objectif de la Branche 3.

Double-cliquez sur l’étape du workflow et configurez le Titre et la Description :
```
Common Tab
-----------------
    Title = "Bypass Approval"
    Description = "Placeholder step to indicate that the original editor decided to bypass the approver group."
```
Le modèle de workflow doit ressembler à ceci une fois que les trois branches de la division OU ont été configurées.
Puisque le groupe Approbateurs a la possibilité de renvoyer le workflow à l’éditeur d’origine pour d’autres révisions, nous comptons sur la variable Atteindre pour lire la dernière action effectuée et router le workflow vers le début ou le laisser continuer.

Faites glisser et déposez le composant Atteindre l’étape (situé dans le sidekick sous Processus) sous la division OU où il se joint à nouveau. Double-cliquez et configurez les propriétés suivantes dans la boîte de dialogue :
```
Common Tab
----------------
    Title = "Goto Step"
    Description = "Based on the Approver groups action route the workflow to the beginning or continue and publish the payload."

Process Tab
---------------
    The step to go to. = "Start Task Creation"
```
La dernière étape que nous allons configurer est Script dans le cadre de l’étape de processus Atteindre . La valeur Script peut être incorporée via la boîte de dialogue ou configurée pour pointer vers un fichier externe. Le script Atteindre doit contenir un function check() et renvoyer la valeur true si le workflow doit atteindre l’étape spécifiée. Un renvoi de faux résultats fait avancer le workflow.

Si le groupe d’approbateurs choisit la variable "Retour en vue de la révision" action (configurée aux étapes 7 et 8), nous souhaitons renvoyer le workflow au "Start Task Creation" étape .

Dans l’onglet Processus , ajoutez le fragment de code suivant à la zone de texte Script :
```
function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Send Back for Revision") {
    return true;
}

return false;
}
```
Pour publier la payload, nous utiliserons l’onglet . Activer la page/ressource Étape du processus. Cette étape de processus nécessite peu de configuration et ajoute la charge utile du workflow à la file d’attente de réplication pour activation. Nous allons ajouter l’étape sous l’étape Atteindre , de sorte qu’elle ne peut être atteinte que si le groupe d’approbateurs a approuvé le contenu à publier ou si l’éditeur d’origine a choisi l’itinéraire Contourner l’approbation .

Faites glisser et déposez le Activer la page/ressource Étape du processus (disponible dans le sidekick sous Processus de gestion du contenu web) sous Atteindre l’étape dans le modèle.

À quoi doit ressembler le modèle de workflow après avoir ajouté les étapes Atteindre et Activer la page/ressource .

Si le groupe Approbateur renvoie le contenu pour révision, nous voulons informer l’éditeur d’origine. Pour ce faire, nous pouvons modifier dynamiquement les propriétés de création de tâche. Nous allons déclencher la valeur de la propriété lastActionTaken de "Retour en vue de la révision". Si cette valeur est présente, nous modifierons le titre et la description afin d’indiquer que cette tâche est le résultat du contenu renvoyé pour révision. Nous mettrons également à jour la priorité sur "High" afin qu’il s’agisse du premier élément sur lequel l’éditeur travaille. Enfin, nous définirons la date d’échéance de la tâche à un jour à partir du moment où le workflow a été renvoyé pour révision.

Remplacer le début start-task-config.ecma script (créé à l’étape 5) avec les éléments suivants :

// start-task-config.ecma
// Populate the task using values stored as workflow metadata originally posted by the start workflow wizard

// set the assignee based on start workflow wizard
var assignee = workflowData.getMetaDataMap().get("assignee", Packages.java.lang.String);
task.setCurrentAssignee(assignee);

//Set the due date for the initial task based on start workflow wizard
var dueDate = workflowData.getMetaDataMap().get("taskDueDate", Packages.java.util.Date);
if (dueDate != null) {
    task.setProperty("taskDueDate", dueDate);
}

//Set the priority based on start workflow wizard
var taskPriority = workflowData.getMetaDataMap().get("taskPriority", "Medium");
task.setProperty("taskPriority", taskPriority);

var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

//change the title and priority if the approver group sent back the content
if(lastAction == "Send Back for Revision") {
  var taskName = "Review and Revise Content";

  //since the content was rejected we will set the priority to High for the revison task
  task.setProperty("taskPriority", "High");

  //set the Task name (displayed as the task title in the Inbox)
  task.setProperty("name", taskName);
  task.setProperty("nameHierarchy", taskName);

  //set the due date of this task 1 day from current date
  var calDueDate = Packages.java.util.Calendar.getInstance();
  calDueDate.add(Packages.java.util.Calendar.DATE, 1);
  task.setProperty("taskDueDate", calDueDate.getTime());

}

Créer l'assistant "démarrer le workflow"

Lorsque vous démarrez un workflow à partir d’un projet, vous devez spécifier un assistant pour démarrer le workflow. L’assistant par défaut : /libs/cq/core/content/projects/workflowwizards/default_workflow permet à l’utilisateur de saisir un titre de workflow, un commentaire de démarrage et un chemin de charge utile pour l’exécution du workflow. Vous trouverez également plusieurs autres exemples ci-dessous : /libs/cq/core/content/projects/workflowwizards.

La création d’un assistant personnalisé peut s’avérer très efficace, car vous pouvez collecter des informations essentielles avant le démarrage du workflow. Les données sont stockées dans le cadre des métadonnées du workflow. Les processus du workflow peuvent les lire et modifier dynamiquement le comportement en fonction des valeurs renseignées. Nous allons créer un assistant personnalisé pour affecter dynamiquement la première tâche du workflow à partir d'une valeur de l'assistant de démarrage.

Dans CRXDE-Lite, nous allons créer un sous-dossier sous /apps/aem-guides/projects-tasks/projects dossier appelé "assistants". Copiez l’assistant par défaut de : /libs/cq/core/content/projects/workflowwizards/default_workflow sous le dossier wizards nouvellement créé et renommez-le en content-approval-start. Le chemin complet doit maintenant être : /apps/aem-guides/projects-tasks/projects/wizards/content-approval-start.

L’assistant par défaut est un assistant à 2 colonnes dont la première colonne indique le titre, la description et la miniature du modèle de workflow sélectionné. La deuxième colonne comprend des champs pour le Titre du workflow, Commentaire de démarrage et Chemin d’accès à la charge utile. L’assistant est un formulaire d’IU tactile standard et utilise les Composants de formulaire de l’IU Granite pour renseigner les champs.
Nous ajouterons un champ supplémentaire à l’assistant qui est utilisé pour définir la personne désignée de la première tâche dans le workflow (voir Création d’un modèle de processus: Étape 5).

Sous ../content-approval-start/jcr:content/items/column2/items créer un noeud de type nt:unstructured named "assign". Nous utiliserons le composant Sélecteur d’utilisateur de projets (basé sur l’ Composant de sélecteur d’utilisateur Granite). Ce champ de formulaire permet de restreindre facilement la sélection de l’utilisateur et du groupe à ceux appartenant au projet en cours.

Vous trouverez ci-dessous la représentation XML de la variable affecter node:
```
<assign
    granite:class="js-cq-project-user-picker"
    jcr:primaryType="nt:unstructured"
    sling:resourceType="cq/gui/components/projects/admin/userpicker"
    fieldLabel="Assign To"
    hideServiceUsers="{Boolean}true"
    impersonatesOnly="{Boolean}true"
    showOnlyProjectMembers="{Boolean}true"
    name="assignee"
    projectPath="${param.project}"
    required="{Boolean}true"/>
```
Nous ajouterons également un champ de sélection des priorités qui déterminera la priorité de la première tâche du workflow (voir Création d’un modèle de processus: Étape 5).

Sous /content-approval-start/jcr:content/items/column2/items créer un noeud de type nt:unstructured named priority. Nous utiliserons la variable Composant Sélection de l’IU Granite pour remplir le champ de formulaire.

Sous la priority noeud auquel nous allons ajouter un items noeud de nt:unstructured. Sous la items ajoutez 3 noeuds supplémentaires pour remplir les options de sélection pour Élevé, Moyen et Faible. Chaque noeud est de type nt:unstructured et doit avoir une text et value . Le texte et la valeur doivent être identiques :
1. Élevée
2. Moyenne
3. Faible
Pour le noeud Medium , ajoutez une propriété booléenne supplémentaire nommée "selected" avec une valeur définie sur true. Cela permet de s’assurer que Support est la valeur par défaut dans le champ de sélection.

Vous trouverez ci-dessous une représentation XML de la structure et des propriétés du noeud :
```
<priority
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/select"
    fieldLabel="Task Priority"
    name="taskPriority">
        <items jcr:primaryType="nt:unstructured">
            <high
                jcr:primaryType="nt:unstructured"
                text="High"
                value="High"/>
            <medium
                jcr:primaryType="nt:unstructured"
                selected="{Boolean}true"
                text="Medium"
                value="Medium"/>
            <low
                jcr:primaryType="nt:unstructured"
                text="Low"
                value="Low"/>
            </items>
</priority>
```

Nous autoriserons l’initiateur du workflow à définir la date d’échéance de la tâche initiale. Nous utiliserons la variable Sélecteur de date de l’IU Granite champ de formulaire pour capturer cette entrée. Nous ajouterons également un champ masqué avec une TypeHint pour vous assurer que l’entrée est stockée en tant que propriété de type Date dans le JCR.

Ajouter deux nt:unstructured noeuds avec les propriétés suivantes représentées ci-dessous en XML :

<duedate
    granite:rel="project-duedate"
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/datepicker"
    displayedFormat="YYYY-MM-DD HH:mm"
    fieldLabel="Due Date"
    minDate="today"
    name="taskDueDate"
    type="datetime"/>
<duedatetypehint
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/hidden"
    name="taskDueDate@TypeHint"
    type="datetime"
    value="Calendar"/>

Vous pouvez afficher le code complet de la boîte de dialogue de l’assistant de démarrage. here.

Connexion du workflow et du modèle de projet

La dernière chose que nous devons faire est de nous assurer que le modèle de workflow est disponible pour être lancé depuis l’un des projets. Pour ce faire, nous devons revoir le modèle de projet que nous avons créé dans la partie 1 de cette série.

La configuration de workflow est une zone d’un modèle de projet qui spécifie les workflows disponibles à utiliser avec ce projet. La configuration est également chargée de spécifier l’assistant Démarrer le workflow lors du lancement du workflow (que nous avons créé dans la étapes précédentes). La configuration Workflow d’un modèle de projet est "en ligne", ce qui signifie que la mise à jour de la configuration de workflow aura un effet sur les nouveaux projets créés ainsi que sur les projets existants qui utilisent le modèle.

Dans CRXDE-Lite, accédez au modèle de projet de création créé précédemment à l’adresse /apps/aem-guides/projects-tasks/projects/templates/authoring-project/workflows/models.

Sous le noeud models , ajoutez un nouveau noeud nommé contentapproval avec un type de noeud nt:unstructured. Ajoutez les propriétés suivantes au nœud :
```
<contentapproval
    jcr:primaryType="nt:unstructured"
    modelId="/etc/workflow/models/aem-guides/content-approval-workflow/jcr:content/model"
    wizard="/apps/aem-guides/projects-tasks/projects/wizards/content-approval-start.html"
/>
```
REMARQUE

Si vous utilisez AEM 6.4, l’emplacement du workflow a changé. Pointez la modelId à l’emplacement du modèle de processus d’exécution sous /var/workflow/models/aem-guides/content-approval-workflow

Voir ici pour plus d’informations sur le changement de l’emplacement du workflow.
```
<contentapproval
    jcr:primaryType="nt:unstructured"
    modelId="/var/workflow/models/aem-guides/content-approval-workflow"
    wizard="/apps/aem-guides/projects-tasks/projects/wizards/content-approval-start.html"
/>
```
Une fois que le workflow d’approbation de contenu a été ajouté au modèle de projet, il doit être disponible pour démarrer à partir de la mosaïque Processus du projet. Allez-y, lancez-vous et jouez avec les différents itinéraires que nous avons créés.

Documents annexes

Ressources Business.Adobe.com

Auto Text Summarization Automated Onboarding Auto Form Fill Personalized Experiences Managed Cloud Content As A Service

Développement de projets dans AEM

Présentation

Configuration

Structure d’un modèle de projet

Racine du modèle de projet

Gadgets

Rôles

Workflows

Création d’un modèle de projet

Test du modèle de projet personnalisé

Pourquoi un workflow ?

Pourquoi les tâches ?

Exemples d’exigences de cas d’utilisation

Création du modèle de workflow

Créer l'assistant "démarrer le workflow"

Connexion du workflow et du modèle de projet

Documents annexes

Ressources Business.Adobe.com

Sur cette page

Voir suivant :

Formation

Documentation

Communauté

Assistance

Ressources

Compte Adobe

Adobe