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, pertanto, quando i passaggi di un flusso di lavoro personalizzato non vengono scritti in base alle best practice, o i flussi di lavoro preconfigurati non sono configurati in modo da funzionare nel modo più efficiente possibile, il sistema può risentirne.

È quindi vivamente consigliato 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 presenti alcuni aspetti.

Flussi di lavoro transitori transient-workflows

Per ottimizzare i carichi di ingestione 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 nel JCR quando vengono eseguiti (le rappresentazioni di output vengono ovviamente mantenute).

I vantaggi possono comprendere:

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 Guida all’ottimizzazione delle prestazioni di AEM Assets.

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

AEM 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 sul sistema.

Nei casi in cui i flussi di lavoro in esecuzione richiedono risorse di sistema, ciò può significare che rimane poco AEM da utilizzare per altre attività, ad esempio per il rendering dell’interfaccia utente di authoring. Di conseguenza, il sistema potrebbe risultare lento durante attività come il caricamento collettivo delle immagini.

Per risolvere questo problema, l'Adobe consiglia di configurare il numero di Processi paralleli massimi essere 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 rimanere reattivo durante l’elaborazione di questi flussi di lavoro.

Per configurare Processi paralleli massimi, puoi effettuare le seguenti operazioni:

Inoltre, è disponibile una configurazione separata per il Coda processi esterni flusso di lavoro Granite. Viene utilizzato per i processi del flusso di lavoro che avviano binari esterni, ad esempio InDesign Server o Immagine Magick.

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

In alcuni casi è utile configurare singole code di lavoro per controllare i thread simultanei o altre opzioni di coda, in base a un singolo processo. Puoi aggiungere e configurare una singola coda dalla console Web tramite la Configurazione della coda dei processi Sling Apache fabbrica. Per trovare l’argomento appropriato da elencare, esegui il modello del flusso di lavoro e cercarlo nella Processi Sling console; ad esempio, in http://localhost:4502/system/console/slingevent.

È possibile aggiungere code di lavoro individuali anche per i flussi di lavoro transitori.

Configurare la pulizia del flusso di lavoro configure-workflow-purging

In un'installazione standard AEM fornisce una console di manutenzione che consente di pianificare e configurare le attività di manutenzione quotidiane e settimanali; ad esempio, in:

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

Per impostazione predefinita, la Finestra Manutenzione settimanale ha Eliminazione del flusso di lavoro ma questo deve essere configurato prima che venga eseguito. Per configurare le pulizie del flusso di lavoro, una nuova Configurazione di eliminazione del flusso di lavoro di Adobe Granite devono essere aggiunti nella console Web.

Per ulteriori dettagli sulle attività di manutenzione in AEM, consulta la sezione Dashboard delle operazioni.

Personalizzazione customization

Quando si scrivono processi di flusso di lavoro personalizzati, è necessario tenere presenti alcuni aspetti.

Posizioni locations

Le definizioni dei modelli di flusso di lavoro, dei moduli di avvio, degli script e delle notifiche vengono conservate nel repository in base al tipo; ovvero preconfigurato, personalizzato, tra gli altri.

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

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

Posizioni - Workflow Launcher locations-workflow-launchers

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

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

Gli script di flusso di lavoro vengono inoltre 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 processo process-sessions

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

Quando si implementa un processo di flusso di lavoro:

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:

Ridurre al minimo il numero/ambito dei moduli di avvio minimize-the-number-scope-of-launchers

C'è un ascoltatore che è responsabile di tutti lanciatori di flussi di lavoro registrati:

La creazione di un numero eccessivo di moduli di avvio rallenta il processo di valutazione.

La creazione di un percorso globbing nella directory principale dell’archivio su un singolo modulo di avvio causerebbe al motore del flusso di lavoro l’ascolto e la valutazione degli eventi di creazione/modifica per ogni nodo dell’archivio. Per questo motivo, si consiglia di creare solo lanciatori che sono necessari e di rendere il percorso globbing il più specifico possibile.

A causa dell’impatto di questi moduli di avvio sul comportamento del flusso di lavoro, può essere utile disattivare eventuali moduli di avvio pronti all’uso non in uso.

Miglioramenti alla configurazione per i moduli di avvio configuration-enhancements-for-launchers

L'utente personalizzato configurazione del modulo di avvio è stato migliorato per supportare i seguenti elementi:

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

I flussi di lavoro possono avere una notevole quantità di overhead, sia in termini di oggetti creati nella memoria che di nodi tracciati nel repository. Per questo motivo, è meglio che un flusso di lavoro esegua l’elaborazione all’interno di sé anziché avviare flussi di lavoro aggiuntivi.

Un esempio di questo potrebbe essere un flusso di lavoro che implementa un processo aziendale su un set di contenuti e poi lo attiva. È meglio creare un processo di flusso di lavoro personalizzato che attivi ciascuno di questi nodi, anziché avviare un Attiva contenuto modello per ciascuno dei nodi di contenuto da pubblicare. Questo approccio richiede un ulteriore lavoro di sviluppo, ma è più efficiente quando viene eseguito che avviare un'istanza di flusso di lavoro separata per ogni attivazione.

Un altro esempio potrebbe essere un flusso di lavoro che elabora un certo numero di nodi, crea un pacchetto di flusso di lavoro, quindi attiva tale pacchetto. 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

Quando si progetta un modello di flusso di lavoro è possibile 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 e quindi eseguirlo.

Si consiglia di utilizzare l'avanzamento del gestore in quanto fornisce prestazioni migliori.

Fasi del flusso di lavoro workflow-stages

Puoi definire fasi del flusso di lavoro, quindi assegna attività/passaggi a una specifica fase del flusso di lavoro.

Queste informazioni vengono utilizzate per visualizzare l'avanzamento di un flusso di lavoro quando fai clic sul pulsante Informazioni sul flusso di lavoro scheda di un elemento di lavoro Inbox. È possibile modificare i modelli di flusso di lavoro esistenti per aggiungere aree di visualizzazione.

Attiva passaggio del processo della pagina activate-page-process-step

La Attiva processo pagina Il passaggio ti attiverà le pagine, ma non troverà automaticamente le risorse DAM di riferimento e le attiverà anche.

Tieni presente questo aspetto se intendi utilizzare questo passaggio come parte di un modello di flusso di lavoro.

Considerazioni sull’aggiornamento upgrade-considerations

Quando aggiorni l’istanza:

Strumenti di sistema system-tools

Sono disponibili numerosi strumenti di sistema per il monitoraggio, la manutenzione e la risoluzione dei problemi dei flussi di lavoro. Tutti gli URL di esempio utilizzati di seguito localhost:4502, ma dovrebbe essere disponibile su qualsiasi istanza di authoring ( <hostname>:<port>).

Console Sling Job Handling sling-job-handling-console

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

La console Sling Job Handling mostra:

Strumento per il rapporto sui flussi di lavoro workflow-report-tool

Lo strumento di reporting del flusso di lavoro viene rimosso nella versione 6.3 per evitare il degrado delle prestazioni.

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

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

La MBean di manutenzione del flusso di lavoro espone diverse utili routine di manutenzione, come l'eliminazione dei flussi di lavoro completati e il recupero delle statistiche del flusso di lavoro.

Ulteriori informazioni further-information

Per ulteriori informazioni, consulta: