Show Menu
ARGOMENTI×

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 flusso di lavoro personalizzati non vengono scritti in base alle best practice, o i flussi di lavoro out-of-the-box non sono configurati per essere eseguiti nel modo più efficiente possibile, il sistema può risentirne.
È quindi vivamente consigliato pianificare con attenzione le implementazioni dei flussi di lavoro.

Configurazione

Per la configurazione dei processi di workflow (personalizzati e/o out-of-the-box), è necessario tenere presenti alcuni aspetti.

Flussi di lavoro transitori

Per ottimizzare i carichi di caricamento elevati, potete 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 memorizzati nel JCR quando vengono eseguiti (le rappresentazioni di output sono ovviamente persistenti).
I vantaggi possono includere:
  • Una riduzione del tempo di elaborazione del flusso di lavoro; fino al 10%.
  • Riduzione significativa della crescita del repository.
  • Per eliminare i flussi di lavoro CRUD non sono necessari più.
  • Inoltre, riduce il numero di file TAR a dimensioni compatte.
Se l'azienda specifica di mantenere/archiviare i dati di runtime del flusso di lavoro a scopo di controllo, non attivare questa funzione.

Ottimizzazione dei flussi di lavoro DAM

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

Configurare il numero massimo di flussi di lavoro simultanei

AEM consente l’esecuzione simultanea di più thread di flusso di lavoro. Per impostazione predefinita, il numero di thread è configurato per la metà del numero di core del processore sul sistema.
Nei casi in cui i flussi di lavoro in esecuzione richiedono risorse di sistema, AEM non può fare 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, Adobe consiglia di configurare il numero massimo di processi paralleli in modo che sia compreso tra la metà e i tre quarti del numero di core del processore presenti nel sistema. Ciò dovrebbe consentire al sistema di rimanere reattivo durante l'elaborazione di tali flussi di lavoro.
Per configurare il numero massimo di processi paralleli, potete:
  • Configurare la configurazione Configurazione di OSGi ​OSGi dalla console Web di AEM; per coda: Coda flusso di lavoro Granite (una configurazione della coda di lavoro Sling Apache).
  • Configurate la coda mediante l’opzione Processi Sling della console Web AEM; per la configurazione della coda di processo: Coda flusso di lavoro Granite, in http://localhost:4502/system/console/slingevent .
È inoltre disponibile una configurazione separata per la coda di processi esterni del flusso di lavoro Granite. Viene utilizzato per i processi di workflow che avviano file binari esterni, come InDesign Server o Image Magick .

Configurare le singole code di processo

In alcuni casi, è utile configurare le singole code di processo per controllare i thread simultanei o altre opzioni di coda, su base individuale. È possibile aggiungere e configurare una singola coda dalla console Web tramite il modulo di configurazione Coda di lavoro Apache Sling. Per trovare l’argomento appropriato da elencare, eseguite il modello del flusso di lavoro e cercatelo nella console Processi Sling; ad esempio, at http://localhost:4502/system/console/slingevent .
È possibile aggiungere code di lavoro individuali anche per flussi di lavoro transitori.

Configurare lo svuotamento del flusso di lavoro

In un’installazione standard, AEM offre una console di manutenzione in cui è possibile pianificare e configurare attività di manutenzione giornaliere e settimanali. ad esempio, in:
http://localhost:4502/libs/granite/operations/content/maintenance.html
Per impostazione predefinita, la finestra Manutenzione settimanale dispone di un’attività di rimozione del flusso di lavoro, che deve essere configurata prima di essere eseguita. Per configurare le eliminazioni dei flussi di lavoro, nella console Web è necessario aggiungere una nuova configurazione di rimozione dei flussi di lavoro Adobe Granite.
Per ulteriori dettagli sulle attività di manutenzione in AEM, consultate Pannello operazioni.

Personalizzazione

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

Posizioni

Le definizioni di modelli di flusso di lavoro, avviatori, script e notifiche sono memorizzate nel repository in base al tipo; ovvero out-of-the-box, personalizzata, tra gli altri.
Consultate anche Ristrutturazione repository in AEM 6.5 .

Posizioni - Modelli di workflow

I modelli di flussi di lavoro vengono memorizzati nella directory archivio in base al tipo:
  • Le progettazioni del flusso di lavoro pronte all'uso si trovano nel seguente percorso:
    /libs/settings/workflow/models/
    Non eseguire:
    • inserire un modello di flusso di lavoro personalizzato in questa cartella
    • modifica qualsiasi elemento /libs
    Eventuali modifiche possono essere sovrascritte al momento dell'aggiornamento o dell'installazione di hotfix, pacchetti di correzione o Service Pack cumulativi.
  • 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 percorso seguente:
    /var/workflow/models/
  • Le progettazioni di flussi di lavoro precedenti (sia in fase di progettazione che di runtime) si trovano nel seguente percorso:
    /etc/workflow/models/
    Se queste progettazioni vengono modificate mediante l’interfaccia di AEM, i dettagli verranno copiati nelle nuove posizioni.

Posizioni - Avviatori flussi di lavoro

Le definizioni del modulo di avvio del flusso di lavoro vengono memorizzate anche nella directory archivio in base al tipo:
  • Gli avviatori di workflow integrati si trovano nel seguente percorso:
    /libs/settings/workflow/launcher/
    Non eseguire:
    • inserite in questa cartella eventuali avviatori di flussi di lavoro personalizzati
    • modifica qualsiasi elemento /libs
    Eventuali modifiche possono essere sovrascritte al momento dell'aggiornamento o dell'installazione di hotfix, pacchetti di correzione o Service Pack cumulativi.
  • Gli avviatori di flussi di lavoro personalizzati si trovano in:
    /conf/global/settings/workflow/launcher/...
    
    
  • I precedenti avviatori di flussi di lavoro si trovano nel seguente percorso:
    /etc/workflow/launcher/
    Se queste definizioni vengono modificate utilizzando l’interfaccia di AEM, i dettagli verranno copiati nelle nuove posizioni.

Posizioni - Script flusso di lavoro

Gli script del flusso di lavoro vengono inoltre memorizzati nell'archivio in base al tipo:
  • Gli script del flusso di lavoro forniti dall'utente si trovano nel percorso seguente:
    /libs/workflow/scripts/
    Non eseguire:
    • inserire uno script di flusso di lavoro personalizzato in questa cartella
    • modifica qualsiasi elemento /libs
    Eventuali modifiche possono essere sovrascritte al momento dell'aggiornamento o dell'installazione di hotfix, pacchetti di correzione o Service Pack cumulativi.
  • Gli script di flusso di lavoro personalizzati si trovano in:
    /apps/workflow/scripts/...
    
    
  • Gli script di flusso di lavoro legacy si trovano nel percorso seguente:
    /etc/workflow/scripts/

Posizioni - Notifiche flusso di lavoro

Le notifiche del flusso di lavoro vengono memorizzate anche nella directory archivio in base al tipo:
  • Le definizioni delle notifiche del flusso di lavoro pronte all'uso si trovano nel percorso seguente:
    /libs/settings/workflow/notification/
    Non eseguire:
    • inserire una delle definizioni di notifica del flusso di lavoro personalizzate in questa cartella
    • modifica qualsiasi elemento /libs
    Eventuali modifiche possono essere sovrascritte al momento dell'aggiornamento o dell'installazione di hotfix, pacchetti di correzione o Service Pack cumulativi.
  • Le definizioni delle notifiche dei flussi di lavoro personalizzate sono memorizzate in:
    /conf/global/settings/workflow/notification/...
    
    
    Per sovrascrivere un testo di notifica di un flusso di lavoro, create un percorso sovrapposto in:
    /conf/global/settings/workflow/notification/<path-under-libs>
  • Le definizioni delle notifiche del flusso di lavoro legacy si trovano nel percorso seguente:
    /etc/workflow/notification/

Sessioni di processo

Come in qualsiasi sviluppo personalizzato, si consiglia sempre di utilizzare una sessione utente quando possibile:
  • per una migliore conformità alle linee guida sulla sicurezza
  • per consentire al sistema di gestire l'apertura e la chiusura della sessione
Durante l'implementazione di un processo di workflow:
  • 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 acquisire una nuova sessione JCR da un passaggio di 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 workflow, se WorkflowSession viene utilizzato per modificare l’archivio, non salvate in modo esplicito la sessione. Al termine, il flusso di lavoro salverà la sessione.
  • Session.Save non devono essere richiamati da un passaggio di workflow:
    • si consiglia di adattare la sessione del flusso di lavoro jcr; quindi non save è 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 una propria sessione jcr.
  • Eliminando i risparmi non necessari, puoi ridurre il sovraccarico e rendere i flussi di lavoro più efficienti.
Se, nonostante le raccomandazioni qui, crei la tua sessione jcr, allora dovrà essere salvata.

Riduci al minimo il numero e l'ambito di avvio

Esiste un listener responsabile per tutti i workflow avviatori 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 valuterà ciascun avvio per determinare se deve essere eseguito.
La creazione di troppi avviatori causa un rallentamento del processo di valutazione.
La creazione di un percorso globbing alla radice del repository su un singolo avviatore causerebbe l'ascolto e la valutazione degli eventi create/modified per ogni nodo del repository. Per questo motivo, si consiglia di creare solo i lanciatori necessari e di rendere il percorso globbing il più specifico possibile.
A causa dell'impatto di questi avviatori sul comportamento del flusso di lavoro, può essere utile disattivare eventuali avviatori out-of-the-box non in uso.

Miglioramenti della configurazione per gli avviatori

La configurazione di avvio personalizzato è stata migliorata per supportare quanto segue:
  • Avere più condizioni "AND" insieme.
  • Avere condizioni OR in un'unica condizione.
  • Disattiva/abilita gli avviatori in base all'attivazione o meno di un flag di funzione.
  • Supporto del regex nelle condizioni di avvio.

Non avviare flussi di lavoro da altri flussi di lavoro

I flussi di lavoro possono avere un notevole carico di lavoro, sia in termini di oggetti creati nella memoria che di nodi tracciati nella directory archivio. Per questo motivo, è meglio che un flusso di lavoro esegua l'elaborazione all'interno di se stesso 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 tale contenuto. È meglio creare un processo di flusso di lavoro personalizzato che attivi ciascuno di questi nodi, anziché avviare un modello di contenuto Attiva per ciascuno dei nodi di contenuto da pubblicare. Questo approccio richiede un ulteriore lavoro di sviluppo, ma è più efficiente se 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 un certo numero di nodi, crea un pacchetto di workflow e quindi attiva il pacchetto specificato. Invece di creare il pacchetto e avviare un flusso di lavoro separato con il pacchetto come payload, potete 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

Durante la progettazione di un modello di workflow è possibile abilitare l'avanzamento del gestore nei passaggi del flusso di lavoro. In alternativa, puoi aggiungere del codice al passaggio del flusso di lavoro per determinare quale passaggio eseguire e quindi eseguirlo.
Si consiglia di utilizzare l'avanzamento del gestore per ottenere prestazioni migliori.

Fasi del flusso di lavoro

Potete definire le fasi del flusso di lavoro e 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 **sul . I modelli di workflow esistenti possono essere modificati per aggiungere fasi.

Attiva passo processo pagina

Il passaggio Attiva processo pagina attiverà le pagine, ma non troverà automaticamente le risorse DAM di riferimento e non le attiverà.
Questo è qualcosa da tenere presente se prevedete di utilizzare questo passaggio come parte di un modello di workflow.

Considerazioni sull'aggiornamento

Durante l'aggiornamento dell'istanza:
  • prima di aggiornare un'istanza, verificate che venga eseguito il backup di eventuali modelli di flusso di lavoro personalizzati.
  • verificate che nessuno dei flussi di lavoro personalizzati sia memorizzato nel percorso :
    • /libs/settings/workflow/models/projects
Consultate anche Ristrutturazione repository in AEM 6.5 .

Strumenti di sistema

Sono disponibili numerosi strumenti di sistema per il monitoraggio, la manutenzione e la risoluzione dei problemi. Tutti gli URL di esempio riportati di seguito 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 mostrerà:
  • Statistiche sullo stato dei processi nel sistema dall’ultimo riavvio.
  • Vengono inoltre visualizzate le configurazioni per tutte le code di processo e viene fornito un collegamento per modificarle in Gestione configurazione.

Strumento Rapporto flusso di lavoro

Lo strumento di reporting del flusso di lavoro viene rimosso in 6.3 per evitare il deterioramento delle prestazioni.

Operazioni di manutenzione del flusso di lavoro MBean

http://localhost:4502/system/console/jmx/com.adobe.granite.workflow:type=Maintenance
MBean di manutenzione del flusso di lavoro espone diverse utili procedure di manutenzione, come l'eliminazione dei flussi di lavoro completati e il recupero delle statistiche del flusso di lavoro.