Best practice per i flussi di lavoro

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

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

Flussi di lavoro transitori

Per ottimizzare i carichi ad alto inserimento, 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:

  • Una riduzione del tempo di elaborazione del flusso di lavoro; fino al 10%.
  • Riduzione significativa della crescita dell'archivio.
  • Per eliminare non sono necessari più flussi di lavoro CRUD.
  • Inoltre, riduce il numero di file TAR da compattare.
ATTENZIONE

Se la tua azienda richiede la persistenza/archiviazione dei dati di runtime del flusso di lavoro a scopo di controllo, non abilitare questa funzione.

Ottimizzazione dei flussi di lavoro DAM

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

Configura il numero massimo di flussi di lavoro simultanei

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 in modo che sia compreso tra la metà e i tre quarti del numero di core del processore sul 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:

  • Configura la configurazione OSGi dalla console Web AEM; per Coda: Coda flusso di lavoro Granite (una Configurazione coda processi Sling Apache).

  • Configura la coda dall'opzione Processi Sling della console Web AEM; per Configurazione coda processi: Coda flusso di lavoro Granite, all'indirizzo http://localhost:4502/system/console/slingevent.

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

Configurare le singole code di lavoro

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. È possibile aggiungere e configurare una singola coda dalla console Web tramite la configurazione della coda di lavoro Apache Sling factory. Per trovare l’argomento appropriato da elencare, esegui il modello del flusso di lavoro e cercarlo nella console Sling Jobs; ad esempio, in http://localhost:4502/system/console/slingevent.

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

Configurare l'eliminazione dei flussi di lavoro

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 di manutenzione settimanale dispone di un'attività Pulizia del flusso di lavoro, ma questo deve essere configurato prima di essere eseguito. Per configurare le pulizie del flusso di lavoro, è necessario aggiungere nella console Web un nuovo Adobe Configurazione di eliminazione del flusso di lavoro Granite .

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

Personalizzazione

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

Posizioni

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

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

  • Le progettazioni di flussi di lavoro preconfigurate si trovano nel seguente percorso:

    /libs/settings/workflow/models/

    ATTENZIONE

    Non eseguire:

    • inserisci uno dei modelli di flusso di lavoro personalizzati in questa cartella
    • modifica qualsiasi elemento in /libs

    Come qualsiasi modifica può essere sovrascritta al momento dell'aggiornamento o durante l'installazione di hotfix, cumulative fix pack o service pack.

  • Le progettazioni di flussi di lavoro personalizzate si trovano in:

    /conf/global/settings/workflow/models/...
    
  • Le progettazioni del flusso di lavoro runtime (sia predefinite che personalizzate) si trovano nel seguente percorso:

    /var/workflow/models/

  • Le progettazioni di flussi di lavoro legacy (sia in fase di progettazione che di runtime) si trovano nel seguente percorso:

    /etc/workflow/models/

    NOTA

    Se queste progettazioni vengono modificate utilizzando l'interfaccia utente AEM, i dettagli verranno copiati nelle nuove posizioni.

Posizioni - Moduli di avvio del flusso di lavoro

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

  • I moduli di avvio dei flussi di lavoro preconfigurati si trovano nel seguente percorso:

    /libs/settings/workflow/launcher/

    ATTENZIONE

    Non eseguire:

    • inserisci uno dei moduli di avvio del flusso di lavoro personalizzati in questa cartella
    • modifica qualsiasi elemento in /libs

    Come qualsiasi modifica può essere sovrascritta al momento dell'aggiornamento o durante l'installazione di hotfix, cumulative fix pack o service pack.

  • I moduli di avvio dei flussi di lavoro personalizzati si trovano in:

    /conf/global/settings/workflow/launcher/... 
    
  • I moduli di avvio dei flussi di lavoro legacy si trovano nel seguente percorso:

    /etc/workflow/launcher/

    NOTA

    Se queste definizioni vengono modificate utilizzando l'interfaccia utente AEM, i dettagli verranno copiati nelle nuove posizioni.

Posizioni - Script del flusso di lavoro

Gli script di flusso di lavoro vengono inoltre memorizzati nell’archivio in base al tipo:

  • Gli script di flusso di lavoro preconfigurati vengono mantenuti nel seguente percorso:

    /libs/workflow/scripts/

    ATTENZIONE

    Non eseguire:

    • inserisci uno degli script di flusso di lavoro personalizzati in questa cartella
    • modifica qualsiasi elemento in /libs

    Come qualsiasi modifica può essere sovrascritta al momento dell'aggiornamento o durante l'installazione di hotfix, cumulative fix pack o service pack.

  • Gli script di flusso di lavoro personalizzati si trovano in:

    /apps/workflow/scripts/... 
    
  • Gli script di flusso di lavoro legacy vengono memorizzati nel seguente percorso:

    /etc/workflow/scripts/

Posizioni - Notifiche flusso di lavoro

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

  • Le definizioni delle notifiche del flusso di lavoro preconfigurate vengono mantenute nel seguente percorso:

    /libs/settings/workflow/notification/

    ATTENZIONE

    Non eseguire:

    • inserisci una delle definizioni di notifica del flusso di lavoro personalizzato in questa cartella
    • modifica qualsiasi elemento in /libs

    Come qualsiasi modifica può essere sovrascritta al momento dell'aggiornamento o durante l'installazione di hotfix, cumulative fix pack o service pack.

  • Le definizioni di notifiche di flusso di lavoro personalizzate sono disponibili in:

    /conf/global/settings/workflow/notification/... 
    
    NOTA

    Se desideri sovrascrivere un testo di notifica di un flusso di lavoro, crea un percorso sovrapposto in:

    /conf/global/settings/workflow/notification/<path-under-libs>

  • Le definizioni delle notifiche del flusso di lavoro legacy vengono mantenute nel seguente percorso:

    /etc/workflow/notification/

Sessioni di processo

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

  • per rispettare al meglio le linee guida sulla sicurezza
  • per consentire al sistema di gestire l'apertura e la chiusura della sessione

Quando si implementa un processo di flusso di lavoro:

  • Viene fornita una sessione del flusso di lavoro che deve essere utilizzata a meno che non vi sia un motivo convincente per non farlo.
  • Le nuove sessioni non devono essere create dai passaggi del flusso di lavoro, in quanto ciò causa incoerenze negli stati e possibili problemi di concorrenza nel motore del flusso di lavoro.
  • Non devi acquisire una nuova sessione JCR dall'interno di una fase del processo in un flusso di lavoro; devi adattare la sessione del flusso di lavoro fornita dall’API Process Step a una sessione jcr. Esempio:
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:

  • All’interno di un processo di flusso di lavoro, se il WorkflowSession viene utilizzato per modificare l’archivio, non salvare esplicitamente la sessione - il flusso di lavoro salverà la sessione al termine.

  • Session.Save non deve essere invocato dall’interno di un passaggio di flusso di lavoro:

    • si consiglia di adattare la sessione jcr del flusso di lavoro; quindi save non è necessario in quanto il motore del flusso di lavoro salva automaticamente la sessione una volta completata l’esecuzione del flusso di lavoro.
    • non è consigliato per un passaggio del processo creare la propria sessione jcr.
  • Eliminando i risparmi non necessari, è possibile ridurre il sovraccarico e rendere quindi i flussi di lavoro più efficienti.

ATTENZIONE

Se, nonostante i consigli qui, crei una tua sessione jcr, allora dovrà essere salvato.

Ridurre al minimo il numero/ambito dei moduli di avvio

Esiste un listener responsabile di tutti i lanciatori di flusso di lavoro registrati:

  • Ascolterà i cambiamenti in tutti i percorsi specificati nelle proprietà globbing degli altri lanciatori.
  • Quando un evento viene inviato, il motore del flusso di lavoro valuta ogni modulo di avvio per determinare se deve essere eseguito.

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

La configurazione launcher personalizzata è stata migliorata per supportare quanto segue:

  • Hanno più condizioni "AND" insieme.
  • Avere condizioni OR in un’unica condizione.
  • Disabilita/abilita i moduli di avvio in base all’abilitazione o meno di un flag di funzione.
  • Supporta regex nelle condizioni di avvio.

Non avviare flussi di lavoro da altri flussi di lavoro

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, invece di avviare un modello Attiva contenuto per ciascuno dei nodi di contenuto che devono essere pubblicati. 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

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

Puoi definire le fasi del flusso di lavoro, quindi assegnare attività/passaggi a una specifica fase 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 Casella in entrata. È possibile modificare i modelli di flusso di lavoro esistenti per aggiungere aree di visualizzazione.

Attiva il passaggio del processo della pagina

Il passaggio Attiva processo pagina attiverà le pagine per tuo conto, 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

Quando aggiorni l’istanza:

  • prima di aggiornare un’istanza, assicurati che venga eseguito il backup di eventuali modelli di flusso di lavoro personalizzati.

  • conferma che nessuno dei flussi di lavoro personalizzati è memorizzato in location:

    • /libs/settings/workflow/models/projects

Strumenti di sistema

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 sotto utilizzano localhost:4502, ma devono essere disponibili in qualsiasi istanza di authoring ( <hostname>:<port>).

Console Sling Job Handling

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

La console Sling Job Handling mostra:

  • Statistiche sullo stato dei lavori nel sistema dall'ultimo riavvio.
  • Inoltre, mostrerà le configurazioni per tutte le code di lavoro e fornirà un collegamento per modificarle nel gestore della configurazione.

Strumento per il rapporto sui flussi di lavoro

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

MBean per le operazioni di manutenzione del flusso di lavoro

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

Per ulteriori informazioni, consulta:

In questa pagina

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now