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.
Per la configurazione dei processi di workflow (personalizzati e/o out-of-the-box), è necessario tenere presenti alcuni aspetti.
Per ottimizzare i carichi di caricamento elevati, è possibile definire un flusso di lavoro 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:
Se l'azienda specifica di mantenere/archiviare i dati di runtime del flusso di lavoro a scopo di controllo, non attivare questa funzione.
Per le linee guida per l'ottimizzazione delle prestazioni per i flussi di lavoro DAM, vedere la AEM Assets Performance Tuning Guide.
AEM consentire l'esecuzione simultanea di più thread del 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, può essere necessario AEM utilizzare poco 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 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. Ciò dovrebbe consentire al sistema di rimanere reattivo durante l'elaborazione di tali flussi di lavoro.
Per configurare Processi paralleli massimi, potete:
Configurare la configurazione OSGi dalla console Web AEM; per Coda: Coda flusso di lavoro Granite (una configurazione della coda di lavoro Apache Sling).
Configurare la coda può essere dall'opzione Processi Sling della console Web AEM; per Configurazione coda di lavoro: Granite Workflow Queue, in http://localhost:4502/system/console/slingevent
.
È inoltre disponibile una configurazione separata per la coda processi esterni del flusso di lavoro Granite. Viene utilizzato per i processi di workflow che avviano file binari esterni, ad esempio InDesign Server o Image Magick.
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 la fabbrica Apache Sling Job Queue Configuration. Per trovare l'argomento appropriato da elencare, eseguite il modello del flusso di lavoro e cercatelo nella console Sling Jobs; ad esempio, in http://localhost:4502/system/console/slingevent
.
È possibile aggiungere code di lavoro individuali anche per flussi di lavoro transitori.
In un'installazione standard AEM una console di manutenzione in cui è possibile pianificare e configurare le attività di manutenzione giornaliere e settimanali; ad esempio, in:
http://localhost:4502/libs/granite/operations/content/maintenance.html
Per impostazione predefinita, la Finestra di manutenzione settimanale ha un'attività Rimozione flusso di lavoro, ma questo deve essere configurato prima che venga eseguita. Per configurare le epurazioni del flusso di lavoro, nella console Web è necessario aggiungere una nuova Adobe Granite Workflow Purge Configuration.
Per ulteriori dettagli sulle attività di manutenzione in AEM, vedere il Pannello operazioni.
Quando si scrivono processi di flusso di lavoro personalizzati, è necessario tenere presenti alcuni aspetti.
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.
Vedere anche Ristrutturazione repository in AEM 6.5.
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:
/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 utilizzando l'interfaccia AEM, i dettagli verranno copiati nelle nuove posizioni.
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:
/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 AEM, i dettagli verranno copiati nelle nuove posizioni.
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:
/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/
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:
/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/
Come in qualsiasi sviluppo personalizzato, si consiglia sempre di utilizzare una sessione utente quando possibile:
Durante l'implementazione di 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:
All'interno di un processo di workflow, se la WorkflowSession
viene utilizzata 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:
save
non è necessario in quanto il motore del flusso di lavoro salva automaticamente la sessione al termine dell'esecuzione del flusso di lavoro.Eliminando i risparmi non necessari, puoi ridurre il sovraccarico e rendere quindi i flussi di lavoro più efficienti.
Se, nonostante le raccomandazioni qui, crei la tua sessione jcr, allora dovrà essere salvata.
Esiste un listener responsabile per tutti i avviatori di workflow registrati:
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.
La configurazione di avvio personalizzata è stata migliorata per supportare quanto segue:
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 Activate Content 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.
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.
È possibile definire fasi del flusso di lavoro, quindi assegnare attività/passaggi a una fase del flusso di lavoro specifica.
Queste informazioni vengono utilizzate per visualizzare l'avanzamento di un flusso di lavoro quando si fa clic sulla scheda Informazioni sul flusso di lavoro di un elemento di lavoro dalla Casella in entrata. I modelli di workflow esistenti possono essere modificati per aggiungere fasi.
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 a mente se prevedete di utilizzare questo passaggio come parte di un modello di workflow.
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 nella cartella location:
/libs/settings/workflow/models/projects
Vedere anche Ristrutturazione repository in AEM 6.5.
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 creazione ( <hostname>:<port>
).
http://localhost:4502/system/console/slingevent
La console Sling Job Handling mostra:
Lo strumento di reporting del flusso di lavoro viene rimosso in 6.3 per evitare il deterioramento delle prestazioni.
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.
Per ulteriori informazioni, consulta: