Best Practices für Workflows

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.

Konfiguration

Beim Konfigurieren von angepassten und/oder vorgefertigten Workflow-Prozessen müssen ein paar Dinge berücksichtigt werden.

Übergangs-Workflows

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:

• Verringerung der Workflow-Verarbeitungsdauer um bis zu zehn Prozent
• Erheblich geringeres Repositorywachstum
• Keine CRUD-Workflows für die Bereinigung mehr erforderlich
• Weniger zu komprimierende TAR-Dateien

Optimieren von DAM-Workflows

Richtlinien für die Optimierung der Leistung von DAM-Workflows finden Sie im Leistungsoptimierungshandbuch für AEM Assets.

Konfigurieren der maximalen Anzahl paralleler Workflows

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).

Konfigurieren individueller Auftragswarteschlangen

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.

Konfigurieren der Workflow-Bereinigung

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.

Anpassung

Beim Erstellen benutzerdefinierter Workflow-Prozesse sind einige Punkte zu beachten.

Speicherorte

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“).

Speicherorte: Workflow-Modelle

Workflow-Modelle werden im Repository auf der Grundlage ihres Typs gespeichert:

• Pfad für vorgefertigte Workflow-Designs:

  /libs/settings/workflow/models/

  VORSICHT

  Beachten Sie Folgendes:

  • Platzieren Sie in diesem Ordner keine benutzerdefinierten Workflow-Modelle.
  • Lassen Sie alles in /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/

  HINWEIS

  Wenn diese Designs mithilfe der AEM-Benutzeroberfläche bearbeitet werden, werden die Details an die neuen Speicherorte kopiert.

Speicherorte: Workflow-Starter

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/

  VORSICHT

  Beachten Sie Folgendes:

  • Platzieren Sie in diesem Ordner keine benutzerdefinierten Workflow-Starter.
  • Lassen Sie alles in /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/

  HINWEIS

  Wenn diese Definitionen mithilfe der AEM-Benutzeroberfläche bearbeitet werden, werden die Details an die neuen Speicherorte kopiert.

Speicherorte: Workflow-Skripte

Workflow-Skripte werden im Repository ebenfalls auf der Grundlage ihres Typs gespeichert:

• Pfad für vorgefertigte Workflow-Skripte:

  /libs/workflow/scripts/

  VORSICHT

  Beachten Sie Folgendes:

  • Platzieren Sie in diesem Ordner keine benutzerdefinierten Workflow-Skripte.
  • Lassen Sie alles in /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/

Speicherorte: Workflow-Benachrichtigungen

Workflow-Benachrichtigungen werden im Repository ebenfalls auf der Grundlage ihres Typs gespeichert:

• Pfad für vorgefertigte Workflow-Benachrichtigungsdefinitionen:

  /libs/settings/workflow/notification/

  VORSICHT

  Beachten Sie Folgendes:

  • Platzieren Sie in diesem Ordner keine benutzerdefinierten Workflow-Benachrichtigungsdefinitionen.
  • Lassen Sie alles in /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/...
  

  HINWEIS

  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/

Prozesssitzungen

Wie bei jeder angepassten Entwicklung empfiehlt es sich, nach Möglichkeit die Sitzung eines Benutzers zu verwenden. Dies hat folgende Vorteile:

• Optimale Einhaltung der Sicherheitsrichtlinien
• Verwaltung des Öffnens/Schließens der Sitzung durch das System

Wenn Sie einen Workflow-Prozess implementieren, gilt Folgendes:

• Eine Workflow-Sitzung wird bereitgestellt und sollte verwendet werden, solange kein zwingender Grund dagegenspricht.
• Auf der Grundlage von Workflow-Schritten sollten keine neuen Sitzungen erstellt werden, da dies zu Inkonsistenzen beim Zustand sowie zu möglichen Parallelitätsproblemen in der Workflow-Engine führt.
• Über einen Prozessschritt in einem Workflow sollte keine neue JCR-Sitzung initiiert werden. Passen Sie die von der Prozessschritt-API bereitgestellte Workflow-Sitzung an eine JCR-Sitzung an. Beispiel:

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:

  • Es wird empfohlen, die Workflow-JCR-Sitzung anzupassen. In diesem Fall wird save nicht benötigt, da die Workflow-Engine die Sitzung nach Abschluss der Workflow-Ausführung automatisch speichert.
  • Ein Prozessschritt sollte keine eigene JCR-Sitzung erstellen.

• Die Vermeidung unnötiger Speichervorgänge führt zu weniger Mehraufwand und somit zu einer höheren Workflow-Effizienz.

Verringern von Anzahl/Umfang der Starter

Es gibt einen Listener, der für alle registrierten Workflow-Starter zuständig ist:

• Er lauscht auf Änderungen an allen Pfaden, die in den Globbing-Eigenschaften der anderen Starter angegeben sind.
• Wenn ein Ereignis übermittelt wird, wertet die Workflow-Engine die einzelnen Starter aus, um zu ermitteln, ob sie ausgeführt werden sollen.

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.

Konfigurationserweiterungen für Starter

Die benutzerdefinierte Starter-Konfiguration wurde erweitert, um Folgendes zu unterstützen:

• Verknüpfung mehrerer Bedingungen mit „UND“
• Verwendung von ODER-Bedingungen innerhalb einer einzelnen Bedingung
• Deaktivierung/Aktivierung von Startern auf der Grundlage des Aktivierungsstatus eines Funktions-Flags
• Unterstützung regulärer Ausdrücke in Starter-Bedingungen

Kein Start von Workflows über andere Workflows

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.

Handler-Fortschritt

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.

Workflow-Phasen

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.

Prozessschritt „Seite aktivieren“

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.

Überlegungen zu Upgrades

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

Systemtools

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.

Konsole zur Behandlung von Sling-Aufträgen

http://localhost:4502/system/console/slingevent

In der Konsole zur Behandlung von Sling-Aufträgen wird Folgendes angezeigt:

• Statistik zum Zustand von Aufträgen im System seit dem letzten Neustart
• Konfigurationen für alle Auftragswarteschlangen sowie ein Tastaturbefehl für die Bearbeitung im Konfigurations-Manager

Workflow-Berichtstool

Das Workflow-Berichtstool wird in Version 6.3 entfernt, um die Leistung nicht zu beeinträchtigen.

MBean für Workflow-Wartungsvorgänge

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.

Weiterführende Informationen

Weitere Informationen finden Sie unter:

• Arbeiten mit Workflows
• Verwalten von Workflows
• Entwickeln und Erweitern von Workflows
• Leistungsoptimierung

Ressourcen für Business.Adobe.com

Style System Responsive Forms Content As A Service Customer Experience Management Digital Rights Management Headless Cms