Bonnes pratiques en matière de workflow workflow-best-practices

Les workflows vous permettent d’automatiser les activités d’Adobe Experience Manager (AEM).

Elles représentent souvent une grande partie du traitement qui se produit dans un environnement AEM. Par conséquent, lorsque les étapes de workflow personnalisées ne sont pas écrites selon les bonnes pratiques ou que les workflows d’usine ne sont pas configurés pour s’exécuter aussi efficacement que possible, le système peut en pâtir.

Il est donc vivement conseillé de planifier soigneusement vos implémentations de workflow.

Configuration configuration

Lors de la configuration des processus de workflow (personnalisés et/ou prêts à l’emploi), certains éléments doivent être pris en compte.

Workflows transitoires transient-workflows

Pour optimiser les charges d’ingestion élevées, vous pouvez définir une workflow comme transitoire.

Lorsqu’un workflow est transitoire, les données d’exécution liées aux étapes intermédiaires ne sont pas conservées dans le JCR lors de leur exécution (les rendus de sortie sont bien sûr conservés).

Les avantages peuvent être les suivants :

Optimisation des workflows DAM tuning-dam-workflows

Pour obtenir des instructions relatives à l’optimisation des performances des workflows DAM, reportez-vous à la section Guide d’optimisation des performances d’AEM Assets.

Configuration du nombre maximal de workflows simultanés configure-the-maximum-number-of-concurrent-workflows

AEM peut permettre l’exécution simultanée de plusieurs threads de workflow. Par défaut, le nombre de threads est configuré pour être la moitié du nombre de coeurs de processeur sur le système.

Dans les cas où les workflows en cours d’exécution nécessitent des ressources système, cela peut signifier qu’AEM n’a plus grand chose à utiliser pour d’autres tâches, comme le rendu de l’interface utilisateur de création. Par conséquent, le système peut être lent lors d’activités telles que le téléchargement massif d’images.

Pour résoudre ce problème, Adobe recommande de configurer le nombre de Tâches parallèles maximales soit entre la moitié et les trois quarts du nombre de coeurs de processeur sur le système. Cela devrait laisser suffisamment de capacité de réaction au système lors du traitement de ces workflows.

Pour configurer la valeur Nombre maximal de tâches en parallèle, vous pouvez effectuer l’une des opérations suivantes :

Il existe, en outre, une configuration distincte pour la File d’attente des tâches de processus externes du workflow Granite. Il est utilisé pour les processus de workflow qui lancent des fichiers binaires externes, tels que InDesign Server ou Image Magick.

Configuration de files d’attente de tâches individuelles configure-individual-job-queues

Dans certains cas, il est utile de configurer des files d’attente individuelles pour contrôler les threads simultanés, ou d’autres options de file d’attente, sur une base de tâche individuelle. Vous pouvez ajouter et configurer une file d’attente individuelle à partir de la console web via le Configuration de la file d’attente des tâches Apache Sling fabrique. Pour localiser la rubrique appropriée à répertorier, exécutez le modèle du workflow et recherchez-le dans la console Tâches Sling  ; par exemple, à l’adresse http://localhost:4502/system/console/slingevent.

Des files d’attente individuelles peuvent également être ajoutées pour les workflows transitoires.

Configuration de la purge des workflows configure-workflow-purging

Dans une installation standard, AEM fournit une console de maintenance où les activités de maintenance quotidiennes et hebdomadaires peuvent être planifiées et configurées ; par exemple, à l’adresse :

http://localhost:4502/libs/granite/operations/content/maintenance.html

Par défaut, la variable Période de maintenance hebdomadaire a une Purge du workflow , mais cela doit être configuré avant son exécution. Pour configurer les purges des workflows, une nouvelle Configuration de la purge du workflow Adobe Granite doit être ajouté à la console Web.

Pour plus d’informations sur les tâches de maintenance dans AEM, reportez-vous à la section Tableau de bord des opérations.

Personnalisation customization

Lors de l’écriture de processus de workflow personnalisés, certains éléments doivent être pris en compte.

Emplacements locations

Les définitions de modèles de workflow, lanceurs, scripts et notifications sont conservées dans le référentiel en fonction de leur type ; par exemple, prêt à l’emploi, personnalisé, etc.

Emplacements - Modèles de processus locations-workflow-models

Les modèles de workflow sont stockés dans le référentiel en fonction de leur type :

Emplacements - Lanceurs de workflow locations-workflow-launchers

Les définitions du lanceur de workflow sont également stockées dans le référentiel en fonction de leur type :

Emplacements - Scripts de workflow locations-workflow-scripts

Les scripts de workflow sont également stockés dans le référentiel en fonction de leur type :

Emplacements - Notifications de workflow locations-workflow-notifications

Les notifications de workflow sont également stockées dans le référentiel en fonction de leur type :

Sessions de processus process-sessions

Comme dans tout développement personnalisé, il est toujours recommandé d’utiliser la session d’un utilisateur lorsque cela est possible :

Lors de l’implémentation d’un processus de workflow :

public void execute(WorkItem item, WorkflowSession workflowSession, MetaDataMap args) throws WorkflowException {
        // to obtain a jcr session:
        javax.jcr.Session jcrSession = workflowSession.adaptTo(javax.jcr.Session.class);

        // to obtain a sling resource resolver:
        org.apache.sling.api.resource.ResourceResolver slingResourceResolver = workflowSession.adaptTo(org.apache.sling.api.resource.ResourceResolver.class);

Enregistrement d’une session :

Réduction du nombre/de la portée des lanceurs minimize-the-number-scope-of-launchers

Un écouteur est responsable de tous les lanceurs de workflow qui sont enregistrés :

La création d’un trop grand nombre de lanceurs ralentit l’exécution du processus d’évaluation.

La création d’un chemin d’extension métacaractère à la racine du référentiel sur un seul lanceur obligerait le moteur de workflow à écouter et à évaluer les événements de création/modification sur chaque noeud du référentiel. C’est pourquoi il est recommandé de ne créer que les lanceurs nécessaires et de rendre le chemin d’accès à l’extension métacaractère aussi spécifique que possible.

En raison de l’impact de ces lanceurs sur le comportement du workflow, il peut également s’avérer utile de désactiver les lanceurs prêts à l’emploi qui ne sont pas utilisés.

Améliorations de la configuration pour les lanceurs configuration-enhancements-for-launchers

La configuration de lanceur personnalisée a été améliorée afin de prendre en charge les éléments suivants :

Ne pas démarrer les workflows à partir d’autres workflows do-not-start-workflows-from-other-workflows

Les workflows peuvent entraîner une surcharge importante, à la fois en termes d’objets créés en mémoire et de noeuds suivis dans le référentiel. Pour cette raison, il est préférable qu’un workflow effectue son traitement en lui-même plutôt que de démarrer des workflows supplémentaires.

Par exemple, un workflow implémente un processus d’entreprise sur un ensemble de contenu, puis active ce contenu. Il est préférable de créer un processus de workflow personnalisé qui active chacun de ces noeuds, plutôt que de démarrer une Activer le contenu modèle pour chacun des noeuds de contenu qui doivent être publiés. Cette approche nécessite un travail de développement supplémentaire, mais elle est plus efficace lors de l’exécution que de démarrer une instance de workflow distincte pour chaque activation.

Un autre exemple serait un workflow qui traite un certain nombre de noeuds, crée un module de workflow, puis active ce module. Plutôt que de créer le module, puis de démarrer un workflow distinct avec le module comme charge utile, vous pouvez modifier la charge utile de votre workflow dans l’étape qui crée le module, puis appeler l’étape pour activer le module dans le même modèle de workflow.

Avance du gestionnaire handler-advance

Lors de la conception d’un modèle de workflow, vous avez la possibilité d’activer l’avance du gestionnaire sur les étapes de votre workflow. Vous pouvez également ajouter du code à votre étape de workflow pour déterminer l’étape qui doit être exécutée ensuite, puis l’exécuter.

Il est recommandé d’utiliser l’avance du gestionnaire, car elle offre de meilleures performances.

Étapes de workflow workflow-stages

Vous pouvez définir étapes de workflow, puis attribuez des tâches/étapes à une étape de workflow spécifique.

Ces informations sont utilisées pour afficher la progression d’un workflow lorsque vous cliquez sur l’onglet Informations sur le workflow d’un élément de travail dans la Boîte de réception. Les modèles de workflow existants peuvent être modifiés pour ajouter des phases.

Étape Activer le processus de page activate-page-process-step

Le Activer le processus de page Cette étape active les pages à votre place, mais elle ne recherche pas automatiquement les ressources DAM référencées et les active également.

Gardez à l’esprit que cette étape doit être utilisée dans le cadre d’un modèle de workflow.

Considérations relatives à la mise à niveau upgrade-considerations

Lors de la mise à niveau de votre instance :

Outils système system-tools

De nombreux outils système sont disponibles pour faciliter la surveillance, la maintenance et la résolution des problèmes des workflows. Tous les exemples d’URL ci-dessous utilisent localhost:4502. Cependant, ces URL doivent être disponibles sur toute instance de création (<hostname>:<port>).

Console de gestion des tâches Sling sling-job-handling-console

http://localhost:4502/system/console/slingevent

La console de gestion des tâches Sling affiche :

Outil Rapport de workflow workflow-report-tool

L’outil de reporting de workflow est supprimé dans la version 6.3 afin d’éviter une dégradation des performances.

MBean des opérations de maintenance des workflows workflow-maintenance-operations-mbean

http://localhost:4502/system/console/jmx/com.adobe.granite.workflow:type=Maintenance

Le MBean de maintenance des workflows expose plusieurs routines de maintenance bien utiles, telles que la purge des workflows terminés et la récupération de statistiques sur les workflows.

Informations supplémentaires further-information

Pour plus d’informations, consultez :