Best practice per i flussi di lavoro workflow-best-practices

I flussi di lavoro consentono di automatizzare le attività di Adobe Experience Manager (AEM).

Spesso rappresentano una grande quantità di elaborazione che si verifica in un ambiente AEM, quindi quando i passaggi del flusso di lavoro personalizzati non vengono scritti in base alle best practice o i flussi di lavoro preconfigurati non sono configurati per essere eseguiti nel modo più efficiente possibile, il sistema può risentirne.

Pertanto, si consiglia vivamente di pianificare con attenzione le implementazioni dei flussi di lavoro.

Configurazione configuration

Durante la configurazione dei processi del flusso di lavoro (personalizzati e/o preconfigurati), è necessario tenere presente alcuni aspetti.

Flussi di lavoro transitori transient-workflows

Per ottimizzare i carichi di acquisizione elevati, puoi definire un flusso di lavoro come transitorio.

Quando un flusso di lavoro è transitorio, i dati di runtime relativi ai passaggi di lavoro intermedi non vengono mantenuti in JCR quando vengono eseguiti (le rappresentazioni di output vengono mantenute).

I vantaggi includono:

Ottimizzazione dei flussi di lavoro DAM tuning-dam-workflows

Per le linee guida per l'ottimizzazione delle prestazioni per i flussi di lavoro DAM, consulta la Guida per l'ottimizzazione delle prestazioni di AEM Assets.

Configurare il numero massimo di flussi di lavoro simultanei configure-the-maximum-number-of-concurrent-workflows

L’AEM può consentire l’esecuzione simultanea di più thread di flusso di lavoro. Per impostazione predefinita, il numero di thread è configurato in modo da essere la metà del numero di core del processore presenti sul sistema.

Nei casi in cui i flussi di lavoro in esecuzione richiedono risorse di sistema, questo può significare che l’AEM non può utilizzare molto per altre attività, come il rendering dell’interfaccia utente di authoring. Di conseguenza, il sistema potrebbe risultare lento durante attività quali il caricamento di immagini in massa.

Per risolvere questo problema, l'Adobe consiglia di configurare il numero di Processi paralleli massimi in modo che sia compreso tra la metà e i tre quarti del numero di core del processore presenti nel sistema. Questo dovrebbe consentire al sistema di mantenere una capacità sufficiente per rispondere durante l’elaborazione di questi flussi di lavoro.

Per configurare Processi paralleli massimi, è possibile:

Esiste inoltre una configurazione separata per la coda processi esterni flusso di lavoro Granite. Viene utilizzato per i processi del flusso di lavoro che avviano i file binari esterni, ad esempio InDesign Server o Image Magick.

Configurare singole code di processi configure-individual-job-queues

In alcuni casi è utile configurare singole code di job per controllare thread simultanei o altre opzioni di coda su base di job individuale. È possibile aggiungere e configurare una singola coda dalla console Web tramite la factory Apache Sling Job Queue Configuration. Per trovare l'argomento appropriato da elencare, eseguire il modello del flusso di lavoro e cercarlo nella console Processi Sling, ad esempio in http://localhost:4502/system/console/slingevent.

È possibile aggiungere singole code di processi anche per flussi di lavoro transitori.

Configurare la rimozione dei flussi di lavoro configure-workflow-purging

In un’installazione standard, l’AEM fornisce una console di manutenzione in cui è possibile pianificare e configurare le attività di manutenzione giornaliere e settimanali; ad esempio, all’indirizzo:

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

Per impostazione predefinita, la finestra Manutenzione settimanale dispone di un'attività Rimozione flusso di lavoro, ma è necessario configurarla prima che venga eseguita. Per configurare le eliminazioni del flusso di lavoro, è necessario aggiungere alla console Web una nuova configurazione di eliminazione del flusso di lavoro Granite di Adobe.

Per ulteriori dettagli sulle attività di manutenzione in AEM, vedi Dashboard operazioni.

Personalizzazione customization

Durante la scrittura di processi di flusso di lavoro personalizzati, è necessario tenere presenti alcuni aspetti.

Posizioni locations

Le definizioni di modelli di flusso di lavoro, moduli di avvio, script e notifiche vengono conservate nell’archivio in base al tipo, ovvero, tra gli altri, predefinite, personalizzate.

Posizioni - Modelli di flusso di lavoro locations-workflow-models

I modelli di flusso di lavoro vengono memorizzati nell’archivio in base al tipo:

Posizioni - Moduli di avvio dei flussi di lavoro locations-workflow-launchers

Anche le definizioni del modulo di avvio dei flussi di lavoro vengono memorizzate nell’archivio in base al tipo:

Posizioni - Script del flusso di lavoro locations-workflow-scripts

Anche gli script di flusso di lavoro vengono memorizzati nell’archivio in base al tipo:

Posizioni - Notifiche flusso di lavoro locations-workflow-notifications

Le notifiche del flusso di lavoro vengono memorizzate anche nell’archivio in base al tipo:

Sessioni di elaborazione process-sessions

Come in qualsiasi sviluppo personalizzato, si consiglia sempre di utilizzare la sessione di un utente quando possibile:

Quando si implementa un processo di 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);

Salvataggio di una sessione

Riduci al minimo il numero e l'ambito dei moduli di avvio minimize-the-number-scope-of-launchers

Esiste un listener responsabile di tutti i moduli di avvio del flusso di lavoro registrati:

Se si creano troppi moduli di avvio, il processo di valutazione verrà eseguito più lentamente.

La creazione di un percorso globbing nella directory principale dell’archivio su un singolo modulo di avvio fa in modo che il motore del flusso di lavoro ascolti e valuti gli eventi di creazione/modifica per ogni nodo dell’archivio. Per questo motivo, si consiglia di creare solo i moduli di avvio necessari e di rendere il percorso di globbing il più specifico possibile.

A causa dell’impatto di questi moduli di avvio sul comportamento del flusso di lavoro, può essere utile disabilitare anche tutti i moduli di avvio predefiniti che non sono in uso.

Miglioramenti alla configurazione dei moduli di avvio configuration-enhancements-for-launchers

La configurazione modulo di avvio personalizzata è stata migliorata per supportare quanto segue:

Non avviare flussi di lavoro da altri flussi di lavoro do-not-start-workflows-from-other-workflows

I flussi di lavoro possono comportare un sovraccarico significativo, sia in termini di oggetti creati in memoria che di nodi tracciati nell’archivio. Per questo motivo, è preferibile che un flusso di lavoro esegua l’elaborazione al suo interno, anziché avviare flussi di lavoro aggiuntivi.

Un esempio potrebbe essere un flusso di lavoro che implementa un processo aziendale su un set di contenuti e quindi attiva tali contenuti. È preferibile creare un processo di flusso di lavoro personalizzato che attivi ciascuno di questi nodi, anziché avviare un modello Attiva contenuto per ciascuno dei nodi di contenuto da pubblicare. Questo approccio richiederà un ulteriore lavoro di sviluppo, ma è più efficiente quando viene eseguito rispetto all’avvio di un’istanza di flusso di lavoro separata per ogni attivazione.

Un altro esempio potrebbe essere un flusso di lavoro che elabora diversi nodi, crea un pacchetto di flusso di lavoro e quindi lo attiva. Invece di creare il pacchetto e quindi avviare un flusso di lavoro separato con il pacchetto come payload, puoi modificare il payload del flusso di lavoro nel passaggio che crea il pacchetto e quindi chiamare il passaggio per attivare il pacchetto all’interno dello stesso modello di flusso di lavoro.

Avanzamento gestore handler-advance

Durante la progettazione di un modello di flusso di lavoro, puoi abilitare l’avanzamento del gestore nei passaggi del flusso di lavoro. In alternativa, puoi aggiungere codice al passaggio del flusso di lavoro per determinare quale passaggio deve essere eseguito successivamente, quindi eseguirlo.

Si consiglia di utilizzare l’avanzamento del gestore, in quanto offre prestazioni migliori.

Fasi flusso di lavoro workflow-stages

È possibile definire fasi del flusso di lavoro, quindi assegnare attività/passaggi a una fase specifica del flusso di lavoro.

Queste informazioni vengono utilizzate per visualizzare l'avanzamento di un flusso di lavoro quando si fa clic sulla scheda Informazioni flusso di lavoro di un elemento di lavoro dalla Posta in arrivo. I modelli di flusso di lavoro esistenti possono essere modificati per aggiungere fasi.

Passaggio di attivazione processo pagina activate-page-process-step

Il passaggio Attiva processo pagina attiva automaticamente le pagine, ma non trova e attiva automaticamente le risorse DAM a cui si fa riferimento.

Questo è un aspetto da tenere presente se intendi utilizzare questo passaggio come parte di un modello di flusso di lavoro.

Considerazioni sull’aggiornamento upgrade-considerations

Durante l’aggiornamento dell’istanza:

Strumenti di sistema system-tools

Sono disponibili molti strumenti di sistema per il monitoraggio, la manutenzione e la risoluzione dei problemi dei flussi di lavoro. Tutti gli URL di esempio seguenti utilizzano localhost:4502, ma dovrebbero essere disponibili in qualsiasi istanza di authoring ( <hostname>:<port>).

Console per la gestione dei processi Sling sling-job-handling-console

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

La console Gestione processi Sling mostrerà:

Strumento Report di flusso di lavoro workflow-report-tool

È in corso la rimozione dello strumento di reporting per flussi di lavoro nella versione 6.3 per evitare il deterioramento delle prestazioni.

MBean operazioni manutenzione flusso di lavoro workflow-maintenance-operations-mbean

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

Il MBean di manutenzione del flusso di lavoro espone diverse utili routine di manutenzione, come la rimozione dei flussi di lavoro completati e il recupero delle statistiche del flusso di lavoro.

Ulteriori informazioni further-information

Per ulteriori informazioni, consulta: