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 pratiques de développement AEM et une certaine familiarité avec AEM configuration de 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 d’affectation des noms /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 la propriété 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 sera de type cq:Template. Sur ce noeud, vous pouvez configurer les propriétés jcr:title et jcr:description qui s’afficheront dans l’assistant Créer un projet. Il existe également une propriété appelée wizard 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 il 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éé. Les mosaïques de projet (également appelées gadgets ou capsules) sont des cartes simples qui remplissent 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 existe 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 le noeud workflows , il doit y avoir un noeud models (également nt:unstructured) et des noeuds enfants sous spécifier les modèles de workflow disponibles. La propriété modelId pointe vers le modèle de workflow sous /etc/workflow et la propriété wizard 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 allons principalement copier/configurer des noeuds, nous utiliserons CRXDE Lite. Dans votre instance d’AEM locale, ouvrez CRXDE Lite.

  1. Commencez par créer un dossier sous /apps/&lt;your-app-folder&gt; nommé projects. Créez un autre dossier sous templates.

    /apps/aem-guides/projects-tasks/
                        + projects (nt:folder)
                                 + templates (nt:folder)
    
  2. 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 dossier templates créé à l’étape 1.
    /apps/aem-guides/projects-tasks/
                 + templates (nt:folder)
                      + default (cq:Template)
    
  3. Vous devez maintenant disposer d’un chemin tel que /apps/aem-guides/projects-tasks/projects/templates/authoring-project.

    1. Modifiez les propriétés jcr:title et jcr:description du noeud author-project en valeurs de titre et de description personnalisées.

      1. Laissez la propriété wizard 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"
    
  4. Pour ce modèle de projet, nous voulons utiliser Tâches.

    1. Ajoutez un nouveau noeud nt:unstructured sous authoring-project/gadgets appelé tasks.
    2. 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".

    Désormais, 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"
    
  5. 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 un nouveau noeud nt:unstructured intitulé rôles.
    2. Ajoutez un autre noeud nt:unstructured intitulé approbateurs en tant qu’enfant du noeud rôles .
    3. Ajoutez 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. ​roleclassgre les autorisations appliquées pour ce rôle en fonction des [3 rôles prêts à l’emploi] (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 règle générale, 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, alors la classe de rôles editor devrait suffire. La grande différence entre propriétaire et éditeur réside dans le fait 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"
    
  6. 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)
    
  7. 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 nouveau fichier en tant que frère des noeuds gadgets, rôles et workflows nommés thumbnail.png.
    2. Enregistrez, puis accédez au noeud jcr:content et cliquez deux fois sur la propriété jcr:data (évitez de cliquer sur "afficher").
      1. Cela devrait vous inviter à ouvrir une boîte de dialogue de modification de fichier 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.

  1. Vous devriez voir le modèle personnalisé comme l’une des options de création de projet.

    Choisir un modèle

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

    Approuver

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

    Mosaïque Tâches

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 : permet aux auteurs de gérer facilement leur heure. 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 leurs travaux.
  • Commentaires liés aux threads : en tant qu’auteurs travaillant sur une tâche, ils ont la possibilité de laisser des commentaires augmentant 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 projet : les tâches sont déjà intégrées aux rôles et aux tableaux de bord du projet.

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

Le routage push crée également une tâche affectée au groupe Approbateurs 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

  1. 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".

    Boîte de dialogue de création de workflow

    Pour plus d’informations sur la création de workflows, consultez cette page.

  2. Il est recommandé de regrouper les workflows personnalisés dans leur propre dossier sous /etc/workflow/models. Dans CRXDE Lite, créez un '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

    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é. Voir ici pour plus de détails.

    Si vous utilisez AEM version 6.4+, le modèle de workflow sera 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.

    Définition de workflow moderne
    emplacementEmplacement du modèle de workflow dans la version 6.4+

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

    configuration des étapes de workflow

    Configurez les phases de workflow dans la boîte de dialogue Propriétés de la page .

    barre de progression du workflow

    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 qui seront utilisées comme miniature de workflow lorsque les utilisateurs la sélectionnent. Les dimensions de l’image doivent être de 319x319 pixels. L’ajout d’une description aux propriétés de page s’affiche également lorsqu’un utilisateur se rend pour sélectionner le processus.

  4. 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 le sous-en-tête "Projets" 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 seront 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. En fonction des objectifs du workflow, nous allons ajouter trois actions à 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"
    
  5. À 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 "cessignee". La valeur "cessionnaire" sera 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 la valeur "taskPriority" des métadonnées du workflow, ainsi que la valeur "taskdueDate" à définir dynamiquement le moment où la première tâche est attendue.

    À 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/scripts. Créez un nouveau fichier sous ce dossier nommé "start-task-config.ecma". *Remarque : assurez-vous 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);
    
  6. Revenez au processus d’approbation du contenu. Faites glisser et déposez le composant Division OU (situé dans le sidekick sous la catégorie "Processus") sous l’étape Démarrer la tâche . Dans la boîte de dialogue commune, sélectionnez le bouton radio correspondant à 3 branches. La division OU lit la valeur de métadonnées de workflow "lastTaskAction" pour déterminer l’itinéraire du workflow. La propriété "lastTaskAction" sera définie sur l’une des valeurs de l’onglet Routage configuré à l’étape 4. Pour chacun des onglets Branche, remplissez la zone de texte Script 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 faisons 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.

  7. Faites glisser une autre étape "Créer une tâche de projet" vers le modèle à l’extrémité 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 "Envoyer en retour pour révision" s’il existe des problèmes que l’éditeur d’origine doit corriger. 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 la zone de texte Script 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);
  1. Faites glisser une autre étape "Créer une tâche de projet" vers le modèle vers 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 extrait de script que à l’étape 7 pour remplir la zone de texte Script 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);
    
  2. 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."
    

    modèle de workflow OU division

    Le modèle de workflow doit ressembler à ceci une fois que les trois branches de la division OU ont été configurées.

  3. Comme le groupe Approbateurs a la possibilité de renvoyer le workflow à l’éditeur d’origine pour d’autres révisions, nous nous appuyons sur l’étape Atteindre pour lire la dernière action effectuée et router le workflow jusqu’au 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 une fonction 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 l’action "Send Back for Revision" (configurée aux étapes 7 et 8), nous souhaitons renvoyer le workflow à l’étape "Start Task Creation".

    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;
    }
    
  4. Pour publier la payload, nous utiliserons l’étape de processus Activer la page/ressource de l’onglet. 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 l’étape de processus Activer la page/ressource (qui se trouve dans le sidekick sous le processus de gestion de contenu web) sous Atteindre l’étape dans le modèle.

    fin du modèle de workflow

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

  5. 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 propriété lastActionTaken de "Send Back for Revision". 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 travaille l’éditeur. 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.

    Remplacez le script start start-task-config.ecma (créé à l’étape 5) par le script suivant :

    // 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ébut 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.

  1. Dans CRXDE-Lite, nous allons créer un sous-dossier sous le dossier /apps/aem-guides/projects-tasks/projects appelé "assistants". Copiez l’assistant par défaut de : /libs/cq/core/content/projects/workflowwizards/default_workflow sous le dossier des assistants nouvellement créé et renommez-le 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 qui utilise les composants de formulaire d’IU Granite standard pour remplir les champs.

    assistant de workflow de validation du contenu

  2. Nous ajouterons un champ supplémentaire à l’assistant qui sera utilisé pour définir la personne désignée de la première tâche dans le workflow (voir Création du modèle de workflow : Étape 5).

    Sous ../content-approval-start/jcr:content/items/column2/items, créez un noeud de type nt:unstructured nommé "assign". Nous utiliserons le composant Sélecteur d’utilisateur de projets (basé sur le composant 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 du noeud assign :

    <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"/>
    
  3. Nous ajouterons également un champ de sélection des priorités qui déterminera la priorité de la première tâche dans le workflow (voir Création du modèle de workflow : Étape 5).

    Sous /content-approval-start/jcr:content/items/column2/items, créez un noeud de type nt:unstructured nommé priority. Nous utiliserons le composant Sélection de l’IU Granite pour remplir le champ de formulaire.

    Sous le noeud priority , nous ajouterons un noeud items de nt:unstructured. Sous le noeud items , ajoutez 3 noeuds supplémentaires pour renseigner les options de sélection pour Élevé, Moyen et Faible. Chaque noeud est de type nt:unstructured et doit avoir une propriété 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>
    
  4. Nous autoriserons l’initiateur du workflow à définir la date d’échéance de la tâche initiale. Nous utiliserons le champ de formulaire Sélecteur de date de l’IU Granite pour capturer cette entrée. Nous ajouterons également un champ masqué avec une valeur TypeHint pour nous assurer que l’entrée est stockée en tant que propriété de type Date dans le JCR.

    Ajoutez deux noeuds nt:unstructured 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"/>
    
  5. Vous pouvez afficher le code complet de la boîte de dialogue de l’assistant de démarrage ici.

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éé aux é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.

  1. 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 propriété modelId sur l’emplacement du modèle de workflow d’exécution sous /var/workflow/models/aem-guides/content-approval-workflow.

    Voir ici pour plus d’informations sur le changement d’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"
    />
    
  2. 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

Sur cette page