Workflows ermöglichen die Automatisierung von Aktivitäten in Adobe Experience Manager (AEM).
Sie stellen oft einen großen Teil der Verarbeitung dar, die in einer AEM-Umgebung stattfindet. Wenn also benutzerdefinierte Workflow-Schritte nicht gemäß Best Practices geschrieben werden oder native Workflows nicht so konfiguriert sind, dass sie so effizient wie möglich ausgeführt werden, kann dies Auswirkungen auf das System haben.
Wir empfehlen daher dringend, Workflow-Implementierungen sorgfältig zu planen.
Beim Konfigurieren von Workflow-Prozessen (angepasst und/oder vorkonfiguriert) sollten einige Aspekte beachtet werden.
Um die Ladevorgänge mit hoher Aufnahme zu optimieren, können Sie eine Workflow als transient.
Wenn ein Workflow vorübergehend ist, werden die Laufzeitdaten, die sich auf die Zwischenarbeitsschritte beziehen, bei ihrer Ausführung nicht im JCR persistiert (die Ausgabedarstellungen werden beibehalten).
Zu den Vorteilen zählen:
Falls Ihr Unternehmen Workflow-Laufzeitdaten zu Auditzwecken aufbewahren muss, aktivieren Sie diese Funktion nicht.
Richtlinien zur Leistungsoptimierung von DAM-Workflows finden Sie im Abschnitt Handbuch zur Leistungsoptimierung von AEM Assets.
AEM können die gleichzeitige Ausführung mehrerer Workflow-Threads zulassen. Standardmäßig ist die Anzahl der Threads so konfiguriert, dass die Anzahl der Prozessorkerne auf dem System halbiert wird.
In Fällen, in denen die ausgeführten Workflows Systemressourcen erfordern, kann dies bedeuten, dass AEM für andere Aufgaben wie das Rendern der Authoring-Benutzeroberfläche wenig übrig haben. Daher kann das System bei Aktivitäten wie dem Massen-Bild-Upload zu langsam sein.
Um dieses Problem zu beheben, empfiehlt Adobe, die Anzahl der Maximale Anzahl paralleler Aufträge zwischen der Hälfte und drei Viertel der Anzahl der Prozessorkerne auf dem System. 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. Dies wird für Workflow-Prozesse verwendet, die externe Binärdateien starten, z. B. InDesign Server oder Image Magick.
In einigen Fällen ist es nützlich, einzelne Auftragswarteschlangen zu konfigurieren, um gleichzeitige Threads oder andere Warteschlangenoptionen auf Basis einzelner Aufträge zu steuern. Sie können eine einzelne Warteschlange über die Web-Konsole hinzufügen und konfigurieren. Apache Sling Job Queue-Konfiguration Fabrik. Um das entsprechende Thema aufzulisten, führen Sie das Modell Ihres Workflows aus und suchen Sie im Sling-Aufträge console, z. B. at http://localhost:4502/system/console/slingevent
.
Individuelle Auftragswarteschlangen können auch für Verlaufs-Workflows hinzugefügt werden.
In einer standardmäßigen AEM bietet eine Wartungskonsole, in der tägliche und wöchentliche Wartungsaktivitäten geplant und konfiguriert werden können, z. B. unter:
http://localhost:4502/libs/granite/operations/content/maintenance.html
Standardmäßig wird die Variable Wöchentliches Wartungsfenster hat eine Workflow-Bereinigung -Aufgabe, dies muss jedoch konfiguriert werden, bevor sie ausgeführt werden kann. Um die Workflow-Bereinigung zu konfigurieren, wird eine neue Adobe Granite-Workflow-Bereinigungskonfiguration muss in der Webkonsole hinzugefügt werden.
Weitere Informationen zu Wartungsaufgaben in AEM finden Sie im Vorgangs-Dashboard.
Beim Schreiben benutzerdefinierter Workflow-Prozesse sollten einige Aspekte beachtet werden.
Definitionen von Workflow-Modellen, Startern, Skripten und Benachrichtigungen werden im Repository nach Typ gespeichert, d. h. standardmäßig benutzerdefinierte Definitionen, unter anderem.
Weitere Informationen finden Sie unter Neue Repositorystruktur in AEM 6.5.
Workflow-Modelle werden im Repository nach Typ gespeichert:
Vordefinierte Workflow-Designs werden unter folgendem Pfad gespeichert:
/libs/settings/workflow/models/
Nicht beachten:
/libs
unverändert.Da alle Änderungen beim Upgrade oder bei der Installation von Hotfixes, Cumulative Fix Packs oder Service Packs überschrieben werden können.
Benutzerdefinierte Workflow-Designs befinden sich unter:
/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 bearbeitet werden Verwenden der AEM-Benutzeroberfläche, werden die Details an die neuen Speicherorte kopiert.
Workflow-Starter-Definitionen werden auch im Repository nach Typ gespeichert:
Vordefinierte Workflow-Starter befinden sich unter folgendem Pfad:
/libs/settings/workflow/launcher/
Nicht beachten:
/libs
unverändert.Da alle Änderungen beim Upgrade oder bei der Installation von Hotfixes, Cumulative Fix Packs oder Service Packs überschrieben werden können.
Benutzerdefinierte Workflow-Starter befinden sich unter:
/conf/global/settings/workflow/launcher/...
Pfad für ältere Workflow-Starter:
/etc/workflow/launcher/
Wenn diese Definitionen bearbeitet werden Verwenden der AEM-Benutzeroberfläche, werden die Details an die neuen Speicherorte kopiert.
Workflow-Skripte werden auch im Repository nach Typ gespeichert:
Vordefinierte Workflow-Skripte werden unter folgendem Pfad gespeichert:
/libs/workflow/scripts/
Nicht beachten:
/libs
unverändert.Da alle Änderungen beim Upgrade oder bei der Installation von Hotfixes, Cumulative Fix Packs oder Service Packs überschrieben werden können.
Benutzerdefinierte Workflow-Skripte befinden sich unter:
/apps/workflow/scripts/...
Pfad für ältere Workflow-Skripte:
/etc/workflow/scripts/
Workflow-Benachrichtigungen werden auch im Repository nach Typ gespeichert:
Vordefinierte Workflow-Benachrichtigungsdefinitionen werden unter folgendem Pfad gespeichert:
/libs/settings/workflow/notification/
Nicht beachten:
/libs
unverändert.Da alle Änderungen beim Upgrade oder bei der Installation von Hotfixes, Cumulative Fix Packs oder Service Packs überschrieben werden können.
Benutzerdefinierte Workflow-Benachrichtigungsdefinitionen befinden sich unter:
/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 benutzerdefinierten Entwicklung wird immer empfohlen, nach Möglichkeit eine Benutzersitzung zu verwenden:
Bei der Implementierung eines Workflow-Prozesses:
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.Durch die Vermeidung unnötiger Speichervorgänge können Sie den Verwaltungsaufwand reduzieren und die Workflows effizienter gestalten.
Wenn Sie trotz der Empfehlungen hier Ihre eigene JCR-Sitzung erstellen, muss sie gespeichert werden.
Es gibt einen Listener, der für alle Workflow-Starter registriert sind:
Das Erstellen zu vieler Starter führt dazu, dass der Evaluierungsprozess langsamer ausgeführt wird.
Wenn Sie einen Globbing-Pfad im Stammverzeichnis des Repositorys in einem einzelnen Starter erstellen, überwacht die Workflow-Engine die Ereignisse zum Erstellen/Ändern jedes Knotens im Repository und wertet sie aus. Daher wird empfohlen, nur erforderliche Starter zu erstellen und den Globbing-Pfad so spezifisch wie möglich zu gestalten.
Aufgrund der Auswirkungen dieser Starter auf das Workflow-Verhalten kann es auch hilfreich sein, vordefinierte Starter zu deaktivieren, die nicht verwendet werden.
Die benutzerdefinierte Starter-Konfiguration wurde erweitert, um Folgendes zu unterstützen:
Workflows können einen erheblichen Mehraufwand verursachen, sowohl im Hinblick auf im Speicher erstellte Objekte als auch auf im Repository nachverfolgte Knoten. Aus diesem Grund ist es besser, einen Workflow seine Verarbeitung selbst durchführen zu lassen, anstatt zusätzliche Workflows zu starten.
Ein Beispiel hierfür wäre ein Workflow, der einen Geschäftsprozess für einen Satz von Inhalten implementiert und diesen Inhalt dann aktiviert. Es ist besser, einen benutzerdefinierten Workflow-Prozess zu erstellen, der jeden dieser Knoten aktiviert, anstatt einen Inhalt aktivieren -Modell für die einzelnen Inhaltsknoten erstellen, die veröffentlicht werden müssen. Dieser Ansatz erfordert zusätzliche Entwicklungsarbeiten, ist jedoch bei der Ausführung effizienter als beim Starten einer separaten Workflow-Instanz für jede Aktivierung.
Ein weiteres Beispiel wäre ein Workflow, der mehrere Knoten verarbeitet, ein Workflow-Paket erstellt und dann dieses Paket 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 zu bestimmen, welcher Schritt als Nächstes ausgeführt werden soll, und ihn dann ausführen.
Es wird empfohlen, den Handler-Fortschritt zu verwenden, da sich dadurch die Leistung verbessert.
Sie können Workflow-Phasen, und weisen Sie dann einer bestimmten Workflow-Phase Aufgaben/Schritte zu.
Diese Informationen werden verwendet, um den Fortschritt eines Workflows anzuzeigen, wenn Sie auf die Workflow-Info Registerkarte eines Arbeitselements aus dem Posteingang. Vorhandene Workflow-Modelle können bearbeitet werden, um Statuswerte hinzuzufügen.
Die Seitenprozess aktivieren -Schritt aktiviert Seiten für Sie, aber es werden keine referenzierten DAM-Assets gefunden und auch diese aktiviert.
Dies ist bei der Verwendung dieses Schritts als Teil eines Workflow-Modells zu beachten.
Beim Aktualisieren Ihrer Instanz:
Stellen Sie sicher, dass alle benutzerdefinierten Workflow-Modelle gesichert werden, bevor eine Instanz aktualisiert wird.
Vergewissern Sie sich, dass keiner Ihrer benutzerdefinierten Workflows unter dem location:
/libs/settings/workflow/models/projects
Weitere Informationen finden Sie unter Neue Repositorystruktur in AEM 6.5.
Es stehen viele Systemwerkzeuge zur Verfügung, die bei der Überwachung, Wartung und Fehlerbehebung von Workflows helfen. 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
Die Konsole "Sling Job Handling"zeigt Folgendes an:
Das Workflow-Reporting-Tool wurde in Version 6.3 entfernt, um eine Leistungsbeeinträchtigung zu verhindern.
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: