AEM 6.4 ha raggiunto la fine del supporto esteso e questa documentazione non viene più aggiornata. Per maggiori dettagli, consulta la nostra periodi di assistenza tecnica. Trova le versioni supportate qui.
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.
Durante la configurazione dei processi del flusso di lavoro (personalizzati e/o preconfigurati), è necessario tenere presenti alcuni aspetti.
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:
Se la tua azienda richiede la persistenza/archiviazione dei dati di runtime del flusso di lavoro a scopo di controllo, non abilitare questa funzione.
Per le linee guida per l’ottimizzazione delle prestazioni per i flussi di lavoro DAM, consulta Guida all’ottimizzazione delle prestazioni di AEM Assets.
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:
Configura le Configurazione OSGi dalla console Web AEM; per Coda: Coda flusso di lavoro Granite (2) Configurazione della coda dei processi Sling Apache).
Configura la coda da Processi Sling opzione della console Web AEM; per Configurazione coda processi: Coda flusso di lavoro Granite, a http://localhost:4502/system/console/slingevent
.
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.
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.
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.
Quando si scrivono processi di flusso di lavoro personalizzati, è necessario tenere presenti alcuni aspetti.
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.
Vedi anche Ristrutturazione dell’archivio in AEM 6.4.
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/
Non eseguire:
/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/
Se le progettazioni vengono modificate utilizzo dell’interfaccia AEM, i dettagli verranno copiati nelle nuove posizioni.
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/
Non eseguire:
/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/
Se queste definizioni vengono modificate utilizzo dell’interfaccia AEM, i dettagli verranno copiati nelle nuove posizioni.
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/
Non eseguire:
/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/
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/
Non eseguire:
/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/...
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/
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:
All’interno di un processo di flusso di lavoro, se WorkflowSession
viene utilizzato per modificare l'archivio e 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:
save
non è necessario in quanto il motore del flusso di lavoro salva automaticamente la sessione una volta completata l’esecuzione del flusso di lavoro.Eliminando i risparmi non necessari, è possibile ridurre il sovraccarico e rendere quindi i flussi di lavoro più efficienti.
Se, nonostante i consigli qui, crei una tua sessione jcr, allora dovrà essere salvato.
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.
L'utente personalizzato configurazione del modulo di avvio è stato migliorato per supportare i seguenti elementi:
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.
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.
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.
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.
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 posizione:
/libs/settings/workflow/models/projects
Vedi anche Ristrutturazione dell’archivio in AEM 6.4.
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>
).
http://localhost:4502/system/console/slingevent
La console Sling Job Handling mostra:
Lo strumento di reporting del flusso di lavoro viene rimosso nella versione 6.3 per evitare il degrado delle prestazioni.
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.
Per ulteriori informazioni, consulta: