Workflows ermöglichen die Automatisierung von Adobe Experience Manager (AEM)-Aktivitäten.
Da sie häufig einen Großteil der Verarbeitung in einer AEM-Umgebung ausmachen, kann es sich negativ auf das System auswirken, wenn benutzerdefinierte Workflow-Schritte nicht unter Berücksichtigung der Best Practices erstellt oder vorgefertigte Workflows nicht so konfiguriert werden, dass eine möglichst effiziente Ausführung gewährleistet ist.
Wir empfehlen daher dringend, Workflow-Implementierungen sorgfältig zu planen.
Beim Konfigurieren von angepassten und/oder vorgefertigten Workflow-Prozessen müssen ein paar Dinge berücksichtigt werden.
Zur Optimierung hoher Erfassungslasten können Sie einen Workflow als Verlaufs-Workflow definieren.
Im Falle eines Verlaufs-Workflows werden die Laufzeitdaten der Zwischenarbeitsschritte bei ihrer Ausführung nicht im JCR beibehalten. (Die Ausgabeformate werden aber natürlich beibehalten.)
Mögliche Vorteile:
Falls Ihr Unternehmen Workflow-Laufzeitdaten zu Auditzwecken aufbewahren muss, aktivieren Sie diese Funktion nicht.
Richtlinien für die Optimierung der Leistung von DAM-Workflows finden Sie im Leistungsoptimierungshandbuch für AEM Assets.
AEM ermöglicht die gleichzeitige Ausführung mehrerer Workflow-Threads. Standardmäßig ist die Anzahl der Threads auf die Hälfte der Prozessorkerne des Systems festgelegt.
Wenn die Systemressourcen durch die ausgeführten Workflows stark beansprucht werden, stehen AEM unter Umständen nicht mehr genügend Ressourcen für andere Aufgaben zur Verfügung (beispielsweise für das Rendern der Benutzeroberfläche für Autoren). Dies kann dazu führen, dass das System bei Aktivitäten wie etwa dem Massenhochladen von Bildern nur noch langsam reagiert.
Zur Behandlung dieses Problems empfiehlt Adobe, die **** maximale Anzahl paralleler Aufträge auf einen Wert festzulegen, der zwischen der Hälfte und drei Vierteln der Anzahl der Prozessorkerne des Systems liegt. Dadurch sollte dem System genügend Kapazität zur Verfügung stehen, damit solche Workflows ohne Beeinträchtigung der Reaktionsfähigkeit verarbeitet werden können.
Die maximale Anzahl paralleler Aufträge kann wie folgt konfiguriert werden:
Konfigurieren Sie die OSGi-Konfiguration über die AEM-Web-Konsole für Warteschlange: Granite Workflow-Warteschlange (eine Warteschlangenkonfiguration für Apache Sling-Aufträge).
Konfigurieren Sie die Warteschlange über die Option Sling-Aufträge der AEM-Web-Konsole für Auftragswarteschlange-Konfiguration: Granite Workflow-Warteschlange unter http://localhost:4502/system/console/slingevent
.
Darüber hinaus gibt es eine separate Konfiguration für die Granite-Workflow-Warteschlange für externe Verarbeitungsaufträge. Diese Konfiguration wird für Workflow-Prozesse verwendet, die externe Binärdateien starten (beispielsweise InDesign Server oder Image Magick).
Manchmal ist es hilfreich, individuelle Auftragswarteschlangen zur Steuerung paralleler Threads oder andere Warteschlangenoptionen für individuelle Aufträge zu konfigurieren. Über die Web-Konsole können Sie eine individuelle Warteschlange über die Factory Warteschlangenkonfiguration für Apache Sling-Aufträge hinzufügen und konfigurieren. Führen Sie zum Ermitteln des aufzulistenden Themas das Modell Ihres Workflows aus und suchen Sie in der Konsole Sling-Aufträge danach (beispielsweise unter http://localhost:4502/system/console/slingevent
).
Individuelle Auftragswarteschlangen können auch für Verlaufs-Workflows hinzugefügt werden.
Bei einer Standardinstallation bietet AEM eine Wartungskonsole, über die tägliche und wöchentliche Wartungsaktivitäten geplant und konfiguriert werden können – beispielsweise hier:
http://localhost:4502/libs/granite/operations/content/maintenance.html
Wöchentliches Wartungsfenster verfügt standardmäßig über eine Aufgabe vom Typ Workflow-Bereinigung, diese muss jedoch erst konfiguriert werden, damit sie ausgeführt wird. Zum Konfigurieren von Workflow-Bereinigungen muss in der Web-Konsole eine neue Adobe Granite-Workflow-Bereinigungskonfiguration hinzugefügt werden.
Ausführlichere Informationen zu Wartungsaufgaben in AEM finden Sie im Vorgangs-Dashboard.
Beim Erstellen benutzerdefinierter Workflow-Prozesse sind einige Punkte zu beachten.
Definitionen von Workflow-Modellen, -Startern, -Skripten und -Benachrichtigungen werden im entsprechenden Repository für den jeweiligen Typ gespeichert (also beispielsweise in „out-of-the-box“ oder in „custom“).
Weitere Informationen finden Sie unter Neue Repositorystruktur in AEM 6.5.
Workflow-Modelle werden im Repository auf der Grundlage ihres Typs gespeichert:
Pfad für vorgefertigte Workflow-Designs:
/libs/settings/workflow/models/
Beachten Sie Folgendes:
/libs
unverändert.Vorgenommene Änderungen werden unter Umständen bei einem Upgrade oder beim Installieren von Hotfixes, Cumulative Fix Packs oder Service Packs überschrieben.
Pfad für benutzerdefinierte Workflow-Designs:
/conf/global/settings/workflow/models/...
Pfad für vordefinierte und benutzerdefinierte Laufzeit-Workflow-Designs:
/var/workflow/models/
Pfad für ältere Workflow-Designs (sowohl Entwurfszeit als auch Laufzeit):
/etc/workflow/models/
Wenn diese Designs mithilfe der AEM-Benutzeroberfläche bearbeitet werden, werden die Details an die neuen Speicherorte kopiert.
Definitionen für Workflow-Starter werden im Repository ebenfalls auf der Grundlage ihres Typs gespeichert:
Pfad für vorgefertigte Workflow-Starter:
/libs/settings/workflow/launcher/
Beachten Sie Folgendes:
/libs
unverändert.Vorgenommene Änderungen werden unter Umständen bei einem Upgrade oder beim Installieren von Hotfixes, Cumulative Fix Packs oder Service Packs überschrieben.
Pfad für benutzerdefinierte Workflow-Starter:
/conf/global/settings/workflow/launcher/...
Pfad für ältere Workflow-Starter:
/etc/workflow/launcher/
Wenn diese Definitionen mithilfe der AEM-Benutzeroberfläche bearbeitet werden, werden die Details an die neuen Speicherorte kopiert.
Workflow-Skripte werden im Repository ebenfalls auf der Grundlage ihres Typs gespeichert:
Pfad für vorgefertigte Workflow-Skripte:
/libs/workflow/scripts/
Beachten Sie Folgendes:
/libs
unverändert.Vorgenommene Änderungen werden unter Umständen bei einem Upgrade oder beim Installieren von Hotfixes, Cumulative Fix Packs oder Service Packs überschrieben.
Pfad für benutzerdefinierte Workflow-Skripte:
/apps/workflow/scripts/...
Pfad für ältere Workflow-Skripte:
/etc/workflow/scripts/
Workflow-Benachrichtigungen werden im Repository ebenfalls auf der Grundlage ihres Typs gespeichert:
Pfad für vorgefertigte Workflow-Benachrichtigungsdefinitionen:
/libs/settings/workflow/notification/
Beachten Sie Folgendes:
/libs
unverändert.Vorgenommene Änderungen werden unter Umständen bei einem Upgrade oder beim Installieren von Hotfixes, Cumulative Fix Packs oder Service Packs überschrieben.
Pfad für benutzerdefinierte Workflow-Benachrichtigungsdefinitionen:
/conf/global/settings/workflow/notification/...
Wenn Sie einen Workflow-Benachrichtigungstext überschreiben möchten, erstellen Sie einen überlagerten Pfad unter:
/conf/global/settings/workflow/notification/<path-under-libs>
Pfad für ältere Workflow-Benachrichtigungsdefinitionen:
/etc/workflow/notification/
Wie bei jeder angepassten Entwicklung empfiehlt es sich, nach Möglichkeit die Sitzung eines Benutzers zu verwenden. Dies hat folgende Vorteile:
Wenn Sie einen Workflow-Prozess implementieren, gilt Folgendes:
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);
Speichern einer Sitzung:
Wenn innerhalb eines Workflow-Prozesses WorkflowSession
verwendet wird, um das Repository zu ändern, führen Sie keine explizite Speicherung der Sitzung durch. Die Sitzung wird nach Abschluss des Workflows gespeichert.
Session.Save
darf nicht innerhalb eines Workflow-Schritts aufgerufen werden:
save
nicht benötigt, da die Workflow-Engine die Sitzung nach Abschluss der Workflow-Ausführung automatisch speichert.Die Vermeidung unnötiger Speichervorgänge führt zu weniger Mehraufwand und somit zu einer höheren Workflow-Effizienz.
Sollten Sie entgegen den hier angegebenen Empfehlungen eine eigene JCR-Sitzung erstellen, muss diese gespeichert werden.
Es gibt einen Listener, der für alle registrierten Workflow-Starter zuständig ist:
Eine zu hohe Anzahl von Startern verlangsamt diese Auswertung.
Die Erstellung eines Globbing-Pfads am Stamm des Repositorys für einen einzelnen Starter führt dazu, dass die Workflow-Engine auf Erstellungs-/Änderungsereignisse für jeden Knoten im Repository lauscht und diese auswertet. Es empfiehlt sich daher, nur Starter zu erstellen, die wirklich benötigt werden, und den Globbing-Pfad so spezifisch wie möglich zu machen.
Angesichts der Auswirkungen, die diese Starter auf das Workflow-Verhalten haben, kann es hilfreich sein, alle ungenutzten vorgefertigten Starter zu deaktivieren.
Die benutzerdefinierte Starter-Konfiguration wurde erweitert, um Folgendes zu unterstützen:
Durch die Objekterstellung im Speicher sowie durch die Knotenüberwachung im Repository können Workflows zu erheblichem Mehraufwand führen. Es empfiehlt sich daher, die Verarbeitung eines Workflows innerhalb dieses Workflows abzuwickeln, anstatt weitere Workflows zu starten.
Ein Beispiel wäre etwa ein Workflow, der einen Geschäftsprozess für eine Gruppe von Inhalten implementiert und die Inhalte anschließend aktiviert. Es ist besser, einen benutzerdefinierten Workflow-Prozess zu erstellen, der jeden dieser Knoten aktiviert, anstatt für jeden der zu veröffentlichenden Inhaltsknoten ein Modell vom Typ Inhalt aktivieren zu starten. Dieser Ansatz führt zwar zu einem höheren Entwicklungsaufwand, ist aber effizienter als für jede Aktivierung eine separate Workflow-Instanz zu starten.
Ein weiteres Beispiel wäre ein Workflow, der eine Reihe von Knoten verarbeitet, ein Workflow-Paket erstellt und dieses Paket anschließend aktiviert. Anstatt das Paket zu erstellen und anschließend einen separaten Workflow mit dem Paket als Payload zu erstellen, können Sie im Paketerstellungsschritt die Payload Ihres Workflows ändern und dann den Paketaktivierungsschritt innerhalb desselben Workflow-Modells aufrufen.
Wenn Sie ein Workflow-Modell entwerfen, können Sie den Handler-Fortschritt für Ihre Workflow-Schritte aktivieren. Alternativ können Sie Ihrem Workflow-Schritt Code hinzufügen, um den als Nächstes auszuführenden Schritt zu bestimmen und auszuführen.
Es wird empfohlen, den Handler-Fortschritt zu verwenden, da sich dadurch die Leistung verbessert.
Sie können Workflow-Statuswerte definieren und Aufgaben/Schritte einem bestimmten Workflow-Status zuweisen.
Diese Information wird zum Anzeigen des Fortschritts eines Workflows verwendet, wenn Sie auf die Registerkarte Workflow-Informationen eines Arbeitselements aus dem Posteingang klicken. Vorhandene Workflow-Modelle können bearbeitet werden, um Statuswerte hinzuzufügen.
Der Prozessschritt Seite aktivieren aktiviert zwar Seiten für Sie, referenzierte DAM-Assets werden durch diesen Schritt aber nicht automatisch gesucht und aktiviert.
Berücksichtigen Sie dies, wenn Sie den Schritt im Rahmen eines Workflow-Modells verwenden möchten.
Wichtige Punkte bei Upgrades für Ihre Instanz:
Sichern Sie alle benutzerdefinierten Workflow-Modelle, bevor Sie ein Upgrade für eine Instanz durchführen.
Vergewissern Sie sich, dass keiner Ihrer benutzerdefinierten Workflows am folgenden Speicherort gespeichert ist:
/libs/settings/workflow/models/projects
Weitere Informationen finden Sie unter Neue Repositorystruktur in AEM 6.5.
Für die Workflow-Überwachung, -Verwaltung und -Problembehandlung stehen zahlreiche Systemtools zur Verfügung. In den folgenden Beispiel-URLs wird zwar localhost:4502
verwendet, sie sollten aber in jeder Autoreninstanz (<hostname>:<port>
) verfügbar sein.
http://localhost:4502/system/console/slingevent
In der Konsole zur Behandlung von Sling-Aufträgen wird Folgendes angezeigt:
Das Workflow-Berichtstool wird in Version 6.3 entfernt, um die Leistung nicht zu beeinträchtigen.
http://localhost:4502/system/console/jmx/com.adobe.granite.workflow:type=Maintenance
Das MBean für die Workflow-Wartung macht eine Reihe praktischer Wartungsroutinen verfügbar – etwa zum Bereinigen abgeschlossener Workflows oder zum Abrufen der Workflow-Statistik.
Weitere Informationen finden Sie unter: