Best Practices für Workflows workflow-best-practices

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.

Konfiguration configuration

Beim Konfigurieren von Workflow-Prozessen (angepasst und/oder vorkonfiguriert) sollten einige Aspekte beachtet werden.

Übergangs-Workflows transient-workflows

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 bleiben natürlich erhalten).

Zu den Vorteilen zählen:

Anpassen von DAM-Workflows tuning-dam-workflows

Richtlinien zur Leistungsoptimierung von DAM-Workflows finden Sie im Abschnitt Handbuch zur Leistungsoptimierung von AEM Assets.

Konfigurieren der maximalen Anzahl gleichzeitiger Workflows configure-the-maximum-number-of-concurrent-workflows

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:

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.

Konfigurieren einzelner Auftragswarteschlangen configure-individual-job-queues

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. 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 configure-workflow-purging

In einer standardmäßigen AEM wird eine Wartungskonsole bereitgestellt, in der tägliche und wöchentliche Wartungsaktivitäten geplant und konfiguriert werden können. Beispiel: unter:

http://localhost:4502/libs/granite/operations/content/maintenance.html

Standardmäßig wird die Wöchentliches Wartungsfenster hat eine Workflow-Bereinigung -Aufgabe, aber dies muss konfiguriert werden, bevor sie ausgeführt wird. 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.

Anpassung customization

Beim Schreiben benutzerdefinierter Workflow-Prozesse sollten einige Aspekte beachtet werden.

Speicherorte locations

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

Standorte - Workflow-Modelle locations-workflow-models

Workflow-Modelle werden im Repository nach Typ gespeichert:

Standorte - Workflow-Starter locations-workflow-launchers

Workflow-Starter-Definitionen werden auch im Repository nach Typ gespeichert:

Speicherorte - Workflow-Skripte locations-workflow-scripts

Workflow-Skripte werden auch im Repository nach Typ gespeichert:

Standorte - Workflow-Benachrichtigungen locations-workflow-notifications

Workflow-Benachrichtigungen werden auch im Repository nach Typ gespeichert:

Prozesssitzungen process-sessions

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:

Anzahl/Umfang der Starter minimieren minimize-the-number-scope-of-launchers

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.

Konfigurationserweiterungen für Starter configuration-enhancements-for-launchers

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

Workflows nicht aus anderen Workflows starten do-not-start-workflows-from-other-workflows

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 eine Reihe von 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.

Handler-Fortschritt handler-advance

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.

Phasen eines Workflows workflow-stages

Sie können Workflow-Phasen, und weisen Sie dann einer bestimmten Workflow-Phase Aufgaben/Schritte zu.

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.

Schritt "Seitenprozess aktivieren" activate-page-process-step

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.

Überlegungen zum Upgrade upgrade-considerations

Beim Aktualisieren Ihrer Instanz:

Systemwerkzeuge system-tools

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.

Konsole zur Behandlung von Sling-Aufträgen sling-job-handling-console

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

Die Konsole "Sling Job Handling"zeigt Folgendes an:

Workflow-Berichtswerkzeug workflow-report-tool

Das Workflow-Reporting-Tool wurde in Version 6.3 entfernt, um eine Leistungsbeeinträchtigung zu verhindern.

MBean für Workflow-Wartungsvorgänge workflow-maintenance-operations-mbean

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 further-information

Weitere Informationen finden Sie unter: