Med arbetsflöden kan du automatisera Adobe Experience Manager-aktiviteter (AEM).
De representerar ofta en stor del av den bearbetning som sker i en AEM miljö, så när anpassade arbetsflödessteg inte skrivs enligt bästa praxis, eller när färdiga arbetsflöden inte är konfigurerade att köras så effektivt som möjligt, kan systemet drabbas av detta.
Vi rekommenderar därför att du noga planerar implementeringarna av arbetsflödena.
När du konfigurerar arbetsflödesprocesser (anpassade och/eller färdiga) finns det några saker som du bör tänka på.
För att optimera stora mängder inmatningsmaterial kan du definiera en arbetsflöde som tillfälligt.
När ett arbetsflöde är övergående bevaras inte körningsdata som relaterar till de mellanliggande arbetsstegen i JCR när de körs (utdatarenderingarna behålls förstås).
Fördelarna kan vara:
Aktivera inte den här funktionen om ditt företag kräver att du ska spara/arkivera arbetsflödets körningsdata för granskning.
Riktlinjer för prestandajustering för DAM-arbetsflöden finns i AEM Assets Performance Tuning Guide.
AEM kan tillåta att flera arbetsflödestrådar körs samtidigt. Som standard är antalet trådar konfigurerat till halva antalet processorkärnor i systemet.
I de fall där arbetsflödena som körs kräver systemresurser, kan detta innebära att det inte finns mycket kvar AEM att använda för andra åtgärder, som att återge redigeringsgränssnittet. Det kan leda till att systemet blir trögt under aktiviteter som massöverföring av bilder.
Adobe rekommenderar att man konfigurerar antalet Maximalt antal parallella jobb ska vara mellan hälften och tre fjärdedelar av antalet processorkärnor i systemet. Detta bör ge tillräcklig kapacitet för att systemet ska kunna vara responsivt när dessa arbetsflöden bearbetas.
Konfigurera Maximalt antal parallella jobb kan du antingen:
Konfigurera OSGi-konfiguration från AEM webbkonsol, for Kö: Begränsa arbetsflödeskö (an Konfiguration av Apache Sling-jobbkö).
Konfigurera kön från Försäljningsjobb alternativ för AEM webbkonsol, for Konfiguration av jobbkö: Begränsa arbetsflödeskö, på http://localhost:4502/system/console/slingevent
.
Dessutom finns det en separat konfiguration för Begränsa arbetsflöde för extern processjobbkö. Detta används för arbetsflödesprocesser som startar externa binärfiler, som InDesign Server eller Bildmagasin.
I vissa fall kan det vara användbart att konfigurera enskilda jobbköer för att styra samtidiga trådar eller andra köalternativ, på individuell jobbbasis. Du kan lägga till och konfigurera en enskild kö från webbkonsolen via Konfiguration av Apache Sling-jobbkö fabrik. Om du vill hitta rätt ämne att lista kör du arbetsflödets modell och letar efter det i Försäljningsjobb konsol, till exempel http://localhost:4502/system/console/slingevent
.
Enskilda jobbköer kan även läggas till för tillfälliga arbetsflöden.
I en standardinstallation AEM en underhållskonsol där underhållsaktiviteter per dag och vecka kan schemaläggas och konfigureras. till exempel:
http://localhost:4502/libs/granite/operations/content/maintenance.html
Som standard är Underhållsfönster varje vecka har en Rensa arbetsflöde -aktiviteten, men den måste konfigureras innan den kan köras. Om du vill konfigurera rensning av arbetsflöde, en ny Rensa arbetsflöde för Adobe Granite måste läggas till i webbkonsolen.
Mer information om underhållsåtgärder i AEM finns i Instrumentpanel för åtgärder.
När du skriver anpassade arbetsflödesprocesser finns det vissa saker som du bör tänka på.
Definitioner av arbetsflödesmodeller, startverktyg, skript och meddelanden lagras i databasen efter typ. dvs. färdiga, anpassade, bland annat.
Se även Omstrukturering av lager i AEM 6.5.
Arbetsflödesmodeller lagras i databasen enligt typ:
Färdiga arbetsflöden finns under följande sökväg:
/libs/settings/workflow/models/
Gör inte:
/libs
Alla ändringar kan skrivas över vid uppgradering eller vid installation av snabbkorrigeringar, kumulativa korrigeringspaket eller servicepaket.
Anpassade arbetsflödesdesigner finns under:
/conf/global/settings/workflow/models/...
Arbetsflödesdesign vid körning (både färdiga och anpassade) finns på följande sökväg:
/var/workflow/models/
Äldre arbetsflödesdesign (både designtid och körningsmiljö) finns under följande sökväg:
/etc/workflow/models/
Om dessa designer redigeras med AEM användargränssnitt, kopieras informationen till de nya platserna.
Definitioner av arbetsflödets startprogram lagras också i databasen enligt typ:
Körklara startprogram för arbetsflöden finns under följande sökväg:
/libs/settings/workflow/launcher/
Gör inte:
/libs
Alla ändringar kan skrivas över vid uppgradering eller vid installation av snabbkorrigeringar, kumulativa korrigeringspaket eller servicepaket.
Skräddarsydda arbetsflödesstarter finns under:
/conf/global/settings/workflow/launcher/...
Inledande arbetsflöden finns på följande sökväg:
/etc/workflow/launcher/
Om dessa definitioner redigeras med AEM användargränssnitt, kopieras informationen till de nya platserna.
Arbetsflödesskript lagras också i databasen enligt typ:
Skript för färdiga arbetsflöden finns under följande sökväg:
/libs/workflow/scripts/
Gör inte:
/libs
Alla ändringar kan skrivas över vid uppgradering eller vid installation av snabbkorrigeringar, kumulativa korrigeringspaket eller servicepaket.
Skript för anpassade arbetsflöden finns under:
/apps/workflow/scripts/...
Äldre arbetsflödesskript sparas under följande sökväg:
/etc/workflow/scripts/
Arbetsflödesmeddelanden lagras också i databasen enligt typ:
Meddelandedefinitioner för färdiga arbetsflöden finns under följande sökväg:
/libs/settings/workflow/notification/
Gör inte:
/libs
Alla ändringar kan skrivas över vid uppgradering eller vid installation av snabbkorrigeringar, kumulativa korrigeringspaket eller servicepaket.
Definitioner för anpassade arbetsflödesmeddelanden finns under:
/conf/global/settings/workflow/notification/...
Om du vill åsidosätta en meddelandetext i arbetsflödet skapar du en åsidosatt sökväg under:
/conf/global/settings/workflow/notification/<path-under-libs>
De äldre definitionerna för arbetsflödesmeddelanden finns under följande sökväg:
/etc/workflow/notification/
Som vid all anpassad utveckling bör du alltid använda en användarsession när det är möjligt:
När en arbetsflödesprocess implementeras:
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);
Spara en session:
I en arbetsflödesprocess, om WorkflowSession
används för att ändra databasen och sedan inte explicit spara sessionen. Arbetsflödet sparar sessionen när den är klar.
Session.Save
ska inte anropas inifrån ett arbetsflödessteg:
save
är inte nödvändigt eftersom arbetsflödesmotorn sparar sessionen automatiskt när arbetsflödet har slutförts.Genom att eliminera onödiga besparingar kan du minska omkostnaderna och på så sätt effektivisera arbetsflödena.
Om du skapar en egen jcr-session, trots rekommendationerna här, måste den sparas.
Det finns en avlyssnare som ansvarar för alla starter av arbetsflöden som är registrerade:
Om du skapar för många startprogram kommer utvärderingsprocessen att gå långsammare.
Om du skapar en globbningssökväg i roten av databasen för en enskild startfunktion kan arbetsflödesmotorn avlyssna och utvärdera händelserna create/modify för alla noder i databasen. Därför rekommenderar vi att du bara skapar startprogram som behövs och att du gör ordlistan så specifik som möjligt.
På grund av hur de här startverktygen påverkar arbetsflödets beteende kan det även vara bra att inaktivera användningsklara startprogram som inte används.
Den anpassade startkonfiguration har förbättrats med stöd för följande:
Arbetsflöden kan medföra en avsevärd mängd overheadkostnader, både när det gäller objekt som skapas i minnet och noder som spåras i databasen. Därför är det bättre att ha ett arbetsflöde som hanterar själva arbetsflödet i stället för att starta ytterligare arbetsflöden.
Ett exempel på detta är ett arbetsflöde som implementerar en affärsprocess för en uppsättning innehåll och sedan aktiverar innehållet. Det är bättre att skapa en anpassad arbetsflödesprocess som aktiverar var och en av dessa noder, i stället för att starta en Aktivera innehåll modell för var och en av innehållsnoderna som behöver publiceras. Det här arbetssättet kräver ytterligare utvecklingsarbete, men är mer effektivt när det körs än att starta en separat arbetsflödesinstans för varje aktivering.
Ett annat exempel är ett arbetsflöde som bearbetar ett antal noder, skapar ett arbetsflödespaket och sedan aktiverar det paketet. I stället för att skapa paketet och sedan starta ett separat arbetsflöde med paketet som nyttolast, kan du ändra arbetsflödets nyttolast i det steg som skapar paketet och sedan anropa steget för att aktivera paketet i samma arbetsflödesmodell.
När du utformar en arbetsflödesmodell kan du aktivera hanterare i dina arbetsflödessteg. Du kan också lägga till kod i arbetsflödessteget för att avgöra vilket steg som ska köras härnäst och sedan köra det.
Vi rekommenderar att du använder hanterarframsteg eftersom de ger bättre prestanda.
Du kan definiera arbetsflödesfaseroch sedan tilldela uppgifter/steg till en viss arbetsflödesfas.
Den här informationen används för att visa förloppet för ett arbetsflöde när du klickar på Information om arbetsflöde -fliken i ett arbetsobjekt från Inkorg. Befintliga arbetsflödesmodeller kan redigeras för att lägga till faser.
The Aktivera sidprocess aktiverar sidor åt dig, men inga refererade DAM-resurser hittas automatiskt och de aktiveras också.
Detta är något att tänka på om du tänker använda det här steget som en del av en arbetsflödesmodell.
När du uppgraderar din instans:
Kontrollera att alla anpassade arbetsflödesmodeller säkerhetskopieras innan en instans uppgraderas.
bekräfta att inga av dina anpassade arbetsflöden lagras under plats:
/libs/settings/workflow/models/projects
Se även Omstrukturering av lager i AEM 6.5.
Det finns många systemverktyg som kan användas för att övervaka, underhålla och felsöka arbetsflöden. Alla exempel-URL:er nedan använder localhost:4502
, men bör vara tillgängligt på alla författarinstanser ( <hostname>:<port>
).
http://localhost:4502/system/console/slingevent
Sling Job Handling-konsolen visar:
Arbetsflödesrapportverktyget tas bort i 6.3 för att förhindra prestandaförsämring.
http://localhost:4502/system/console/jmx/com.adobe.granite.workflow:type=Maintenance
MBean för arbetsflödesunderhåll visar flera praktiska underhållsrutiner, som att tömma slutförda arbetsflöden och hämta arbetsflödesstatistik.
Mer information finns i: