Wartungsaufgaben in AEM as a Cloud Service maintenance-tasks-in-aem-as-a-cloud-service

Wartungsaufgaben sind Prozesse, die nach einem Zeitplan ausgeführt werden, um das Repository zu optimieren. Bei AEM as a Cloud Service ist der Kundenaufwand der Konfiguration von Betriebseigenschaften für Wartungsaufgaben minimal. Kunden können ihre Ressourcen auf Angelegenheiten in der Anwendungsebene konzentrieren und die Infrastrukturvorgänge Adobe überlassen.

Konfigurieren von Wartungsaufgaben maintenance-tasks-configuring

In früheren Versionen von AEM konnten Sie Wartungsaufgaben mithilfe der Wartungskarte konfigurieren (Tools > Vorgänge > Wartung). Bei AEM as a Cloud Service ist die Wartungskarte nicht mehr vorhanden. Daher sollten Konfigurationen an die Quell-Code-Verwaltung übertragen und mithilfe von Cloud Manager bereitgestellt werden. Adobe verwaltet Wartungsaufgaben, deren Einstellungen von Kundinnen und Kunden nicht konfiguriert werden können (z. B. Datenspeicherbereinigung).  Andere Wartungsaufgaben können kundenseitig konfiguriert werden, wie in der folgenden Tabelle beschrieben.

CAUTION
Adobe behält sich das Recht vor, Konfigurationseinstellungen für Wartungsaufgaben der Kundschaft außer Kraft zu setzen, um Probleme wie Leistungsbeeinträchtigungen zu verhindern.

In der folgenden Tabelle sind die verfügbaren Wartungsaufgaben aufgeführt.

Wartungsaufgabe
Wer ist für die Konfiguration verantwortlich
Konfigurationsweise (optional)
Speicherbereinigung
Adobe
N/A – volle Verantwortung von Adobe
Versionsbereinigung
Kundin/Kunde
Die Versionsbereinigung ist derzeit standardmäßig deaktiviert, die Richtlinie kann jedoch wie unter Wartungsaufgaben für Versionsbereinigung und Audit-Protokollbereinigung beschrieben konfiguriert werden.

Die Bereinigung wird in Kürze standardmäßig aktiviert, wobei diese Werte überschrieben werden können.
Bereinigung der Auditprotokolle
Kundin/Kunde
Die Auditprotokollbereinigung ist derzeit standardmäßig deaktiviert, die Richtlinie kann jedoch wie unter Wartungsaufgaben für Versionsbereinigung und Auditprotokollbereinigung beschrieben konfiguriert werden.

Die Bereinigung wird in Kürze standardmäßig aktiviert, wobei diese Werte überschrieben werden können.
Lucene-Binärdateien-Bereinigung
Adobe
Nicht verwendet und daher von Adobe deaktiviert.
Ad-hoc-Aufgabenbereinigung
Kundin/Kunde

Das muss in Git geschehen. Überschreiben Sie den vorkonfigurierten Konfigurationsknoten des Wartungsfensters unter /libs durch Erstellen von Eigenschaften im Ordner /apps/settings/granite/operations/maintenance/granite_weekly, granite_daily oder granite_monthly.

Weitere Konfigurationsdetails finden Sie in der Tabelle zum Wartungsfenster. Aktivieren Sie die Wartungsaufgabe, indem Sie unter dem obigen Knoten einen weiteren Knoten hinzufügen. Benennen Sie ihn granite_TaskPurgeTask, wobei Sie das Attribut sling:resourceType auf granite/operations/components/maintenance/task und das Attribut granite.maintenance.name auf TaskPurge setzen. Konfigurieren Sie die OSGi-Eigenschaften. Eine Liste der Eigenschaften finden Sie unter com.adobe.granite.taskmanagement.impl.purge.TaskPurgeMaintenanceTask.

Workflow-Bereinigung
Kundin/Kunde

Das muss in Git geschehen. Überschreiben Sie den Standardkonfigurationsknoten des Wartungsfensters unter /libs, indem Sie Eigenschaften im Ordner /apps/settings/granite/operations/maintenance/granite_weekly, granite_daily oder granite_monthly erstellen. Weitere Konfigurationsdetails finden Sie in der Tabelle zum Wartungsfenster.

Aktivieren Sie die Wartungsaufgabe, indem Sie unter dem obigen Knoten einen weiteren Knoten mit den entsprechenden Eigenschaften hinzufügen (nennen Sie ihn granite_WorkflowPurgeTask). Informationen zum Konfigurieren der OSGi-Eigenschaften finden Sie in der AEM 6.5-Dokumentation zu Wartungsaufgaben.

Projektbereinigung
Kundin/Kunde

Das muss in Git geschehen. Überschreiben Sie den Standardkonfigurationsknoten des Wartungsfensters unter /libs, indem Sie Eigenschaften im Ordner /apps/settings/granite/operations/maintenance/granite_weekly, granite_daily oder granite_monthly erstellen. Weitere Konfigurationsdetails finden Sie in der Tabelle zum Wartungsfenster.

Aktivieren Sie die Wartungsaufgabe, indem Sie unter dem obigen Knoten einen weiteren Knoten mit den entsprechenden Eigenschaften hinzufügen (nennen Sie ihn granite_ProjectPurgeTask). Siehe die Liste der OSGi-Eigenschaften unter „Bereinigungskonfiguration von Adobe-Projekten“.

Konfiguration von Wartungsfenstern
Wer ist für die Konfiguration verantwortlich
Konfigurationstyp
Parameter
Täglich
Kundin/Kunde
JCR-Knotendefinition

windowSchedule=daily (dieser Wert sollte nicht geändert werden)

windowStartTime = HH:MM unter Verwendung der 24-Stunden-Zeit. Definiert, wann die Ausführung der mit dem täglichen Wartungsfenster verknüpften Wartungsaufgaben beginnen soll.

windowEndTime = HH:MM unter Verwendung der 24-Stunden-Zeit. Definiert, wann die Ausführung der mit dem täglichen Wartungsfenster verknüpften Wartungsaufgaben beendet werden soll, wenn diese noch nicht abgeschlossen sind.

Eine Wartungsaufgabe kann während dieses Zeitraums nicht mehr als einmal ausgeführt werden.

Wöchentlich
Kundin/Kunde
JCR-Knotendefinition

windowSchedule=weekly (dieser Wert sollte nicht geändert werden)

windowStartTime = HH:MM unter Verwendung der 24-Stunden-Zeit. Definiert, wann die Ausführung der mit dem wöchentlichen Wartungsfenster verknüpften Wartungsaufgaben beginnen soll.

windowEndTime = HH:MM unter Verwendung der 24-Stunden-Zeit. Definiert, wann die Ausführung der mit dem wöchentlichen Wartungsfenster verknüpften Wartungsaufgaben beendet werden soll, wenn diese noch nicht abgeschlossen sind.

Eine Wartungsaufgabe kann während dieses Zeitraums nicht mehr als einmal ausgeführt werden.

windowScheduleWeekdays= Array von zwei Werten von 1–7 (z. B. [5,5]) Der erste Wert des Arrays ist der Starttag, an dem der Auftrag geplant wird, der zweite Wert der Endtag, an dem der Auftrag gestoppt wird. Die genaue Uhrzeit von Anfang und Ende wird durch „windowStartTime“ bzw. „windowEndTime“ angegeben.

Monatlich
Kundin/Kunde
JCR-Knotendefinition

windowSchedule=monthly (dieser Wert sollte nicht geändert werden)

windowStartTime = HH:MM unter Verwendung der 24-Stunden-Zeit. Definiert, wann die Ausführung der mit dem monatlichen Wartungsfenster verknüpften Wartungsaufgaben beginnen soll.

windowEndTime = HH:MM unter Verwendung der 24-Stunden-Zeit. Definiert, wann die Ausführung der mit dem monatlichen Wartungsfenster verknüpften Wartungsaufgaben beendet werden soll, wenn diese noch nicht abgeschlossen sind.

Eine Wartungsaufgabe kann während dieses Zeitraums nicht mehr als einmal ausgeführt werden.

windowScheduleWeekdays=Array von zwei Werten von 1–7 (z. B. [5,5]). Der erste Wert des Arrays ist der Starttag, an dem der Auftrag geplant wird, der zweite Wert der Endtag, an dem der Auftrag gestoppt wird. Die genaue Uhrzeit von Anfang und Ende wird durch „windowStartTime“ bzw. „windowEndTime“ angegeben.

windowFirstLastStartDay= 0/1 0, um in der ersten Woche des Monats zu planen, oder 1, um in der letzten Woche des Monats zu planen. Wird kein Wert angegeben, werden die Aufträge an dem Tag geplant, der durch windowScheduleWeekdays (jeden Monat) festgelegt ist.

Standorte:

  • Täglich – /apps/settings/granite/operations/maintenance/granite_daily
  • Wöchentlich – /apps/settings/granite/operations/maintenance/granite_weekly
  • Monatlich – /apps/settings/granite/operations/maintenance/granite_month

Code-Beispiele

Code-Beispiel 1 (täglich)

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
  xmlns:jcr="http://www.jcp.org/jcr/1.0"
  jcr:primaryType="sling:Folder"
  sling:configCollectionInherit="true"
  sling:configPropertyInherit="true"
  windowSchedule="daily"
  windowStartTime="03:00"
  windowEndTime="05:00"
 />

Code-Beispiel 2 (wöchentlich)

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
   xmlns:jcr="http://www.jcp.org/jcr/1.0"
   jcr:primaryType="sling:Folder"
   sling:configCollectionInherit="true"
   sling:configPropertyInherit="true"
   windowEndTime="15:30"
   windowSchedule="weekly"
   windowScheduleWeekdays="[5,5]"
   windowStartTime="14:30"/>

Code-Beispiel 3 (monatlich)

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
   xmlns:jcr="http://www.jcp.org/jcr/1.0"
   jcr:primaryType="sling:Folder"
   sling:configCollectionInherit="true"
   sling:configPropertyInherit="true"
   windowEndTime="15:30"
   windowSchedule="monthly"
   windowFirstLastStartDay=0
   windowScheduleWeekdays="[5,5]"
   windowStartTime="14:30"/>

Wartungsaufgaben für Versionsbereinigung und Auditprotokollbereinigung purge-tasks

Durch das Bereinigen der Versionen und des Auditprotokolls wird die Größe des Repositorys verringert und in einigen Szenarien kann die Leistung verbessert werden.

NOTE
AEM Guides-Kundinnen und -Kunden sollten keine Versionsbereinigung konfigurieren.

Standardwerte defaults

Derzeit ist die Bereinigung nicht standardmäßig aktiviert, aber dies wird sich in Zukunft ändern. Umgebungen, die vor Aktivierung der standardmäßigen Bereinigung erstellt wurden, haben einen konservativeren Schwellenwert, sodass das Bereinigen nicht unerwartet erfolgt. Weitere Informationen zu den Richtlinien für standardmäßige Bereinigungen finden Sie unten in den Abschnitten „Versionsbereinigung“ und „Auditprotokollbereinigung“.

Die standardmäßigen Bereinigungswerte können überschrieben werden, indem eine Konfigurationsdatei deklariert und wie unten beschrieben bereitgestellt wird.

Anwenden einer Konfiguration configure-purge

Deklarieren Sie eine Konfigurationsdatei und stellen Sie sie wie in den folgenden Schritten beschrieben bereit.

NOTE
Nachdem Sie den Knoten zur Versionsbereinigung in der Konfigurationsdatei bereitgestellt haben, müssen Sie ihn deklarieren und dürfen ihn nicht entfernen. Wenn Sie dies versuchen, schlägt die Konfigurations-Pipeline fehl.
Ebenso müssen Sie den Knoten für die Auditprotokollbereinigung nach der Bereitstellung in der Konfigurationsdatei deklarieren und dürfen ihn nicht entfernen.

1 – Erstellen Sie zunächst den folgenden Ordner und die Dateistruktur des Ordners der obersten Ebene in Ihrem Projekt in Git:

config/
     mt.yaml

2 – Deklarieren Sie Eigenschaften in der Konfigurationsdatei, die Folgendes enthalten:

  • eine Eigenschaft „kind“ mit dem Wert „MaintenanceTasks“.
  • eine Eigenschaft „version“ (derzeit handelt es sich um Version 1).
  • ein optionales Objekt „metadata“ mit der Eigenschaft envTypes mit einer kommagetrennten Liste des Umgebungstyps (dev, stage, prod), für den diese Konfiguration gültig ist. Wenn kein Metadatenobjekt deklariert wird, ist die Konfiguration für alle Umgebungstypen gültig.
  • ein Datenobjekt mit den Objekten versionPurge und auditLogPurge.

Siehe die Definitionen und Syntax der Objekte versionPurge und auditLogPurge unten.

Sie sollten die Konfiguration ähnlich wie im folgenden Beispiel strukturieren:

kind: "MaintenanceTasks"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  versionPurge:
    maximumVersions: 15
    maximumAgeDays: 20
    paths: ["/content"]
    minimumVersions: 1
    retainLabelledVersions: false
  auditLogPurge:
    rules:
      - replication:
          maximumAgeDays: 15
          contentPath: "/content"
          types: ["Activate", "Deactivate", "Delete", "Test", "Reverse", "Internal Poll"]
      - pages:
          maximumAgeDays: 15
          contentPath: "/content"
          types: ["PageCreated", "PageModified", "PageMoved", "PageDeleted", "VersionCreated", "PageRestored", "PageValid", "PageInvalid"]
      - dam:
          maximumAgeDays: 15
          contentPath: "/content"
          types: ["ASSET_EXPIRING", "METADATA_UPDATED", "ASSET_EXPIRED", "ASSET_REMOVED", "RESTORED", "ASSET_MOVED", "ASSET_VIEWED", "PROJECT_VIEWED", "PUBLISHED_EXTERNAL", "COLLECTION_VIEWED", "VERSIONED", "ADDED_COMMENT", "RENDITION_UPDATED", "ACCEPTED", "DOWNLOADED", "SUBASSET_UPDATED", "SUBASSET_REMOVED", "ASSET_CREATED", "ASSET_SHARED", "RENDITION_REMOVED", "ASSET_PUBLISHED", "ORIGINAL_UPDATED", "RENDITION_DOWNLOADED", "REJECTED"]

Beachten Sie Folgendes, damit die Konfiguration gültig ist:

  • Alle Eigenschaften müssen definiert sein. Es gibt keine geerbten Standardwerte.
  • Die in den Eigenschaftstabellen unten aufgeführten Typen (Ganzzahlen, Zeichenfolgen, Boolesche Werte usw.) müssen beachtet werden.
NOTE
Sie können yq verwenden, um die YAML-Formatierung Ihrer Konfigurationsdatei lokal zu überprüfen (z. B. yq mt.yaml).

3 – Konfigurieren Sie die produktionsfremden und die Produktions-Konfigurations-Pipelines.

Schnelle Entwicklungsumgebungen (Rapid Development Environments, RDEs) unterstützen keine Bereinigungen.  Erstellen Sie für andere Umgebungstypen in Produktionsprogrammen (keine Sandbox) eine zielgerichtete Bereitstellungs-Konfigurations-Pipeline in Cloud Manager.

Weitere Informationen finden Sie unter Konfigurieren von Produktions-Pipelines und Konfigurieren von produktionsfremden Pipelines.

Versionsbereinigung version-purge

NOTE
AEM Guides-Kundinnen und -Kunden sollten keine Versionsbereinigung konfigurieren.

Standardwerte für die Versionsbereinigung version-purge-defaults

Derzeit ist die Bereinigung nicht standardmäßig aktiviert, aber dies wird sich in Zukunft ändern.

Umgebungen, die nach Aktivierung der standardmäßigen Bereinigung erstellt wurden, haben die folgenden Standardwerte:

  • Versionen, die älter als 30 Tage sind, werden entfernt.
  • Die letzten fünf Versionen der letzten 30 Tage werden beibehalten.
  • Unabhängig von den obigen Regeln wird die neueste Version (zusätzlich zur aktuellen Datei) beibehalten.

Umgebungen, die vor Aktivierung der standardmäßigen Bereinigung erstellt wurden, haben die unten aufgeführten Standardwerte. Es wird jedoch empfohlen, diese Werte zu verringern, um die Leistung zu optimieren.

  • Versionen, die älter als sieben Jahre sind, werden entfernt.
  • Alle Versionen der letzten sieben Jahre werden beibehalten.
  • Nach sieben Jahren werden andere Versionen als die neueste Version (zusätzlich zur aktuellen Datei) entfernt.

Eigenschaften der Versionsbereinigung version-purge-properties

Die zulässigen Eigenschaften sind im Folgenden aufgeführt.

Die Spalten, die default angeben, geben die Standardwerte für die Zukunft an, wenn Standardwerte angewendet werden. TBD gibt eine Umgebungs-ID an, die noch nicht ermittelt wurde.

Eigenschaften
Zukünftiger Standard für Umgebungen>TBD
Zukünftiger Standard für Umgebungen<=TBD
Erforderlich
Typ
Werte
Pfade
["/content"]
["/content"]
Ja
Zeichenfolgen-Array
Gibt an, unter welchen Pfaden Versionen bereinigt werden sollen, wenn neue Versionen erstellt werden. Diese Eigenschaft muss kundenseitig deklariert werden. Es ist jedoch nur der Wert "/content" zulässig.
maximumAgeDays
30
2557 (7 Jahre + 2 Schalttage)
Ja
Ganzzahl
Jede Version, die älter als der konfigurierte Wert ist, wird entfernt. Lautet der Wert „0“, wird die Bereinigung nicht auf Basis des Alters der Version durchgeführt.
maximumVersions
5
0 (kein Limit)
Ja
Ganzzahl
Jede Version, die älter als die n-te neueste Version ist, wird entfernt. Lautet der Wert „0“, wird die Bereinigung nicht auf Basis der Anzahl der Versionen durchgeführt.
minimumVersions
1
1
Ja
Ganzzahl
Die Mindestanzahl der Versionen, die unabhängig vom Alter beibehalten werden. Es wird immer mindestens eine Version beibehalten. Der Wert muss „1“ oder höher sein.
keepLabeledVersion
false
false
Ja
Boolesch
Bestimmt, ob explizit gekennzeichnete Versionen von der Bereinigung ausgeschlossen werden. Für eine bessere Repository-Optimierung wird empfohlen, diesen Wert auf „false“ festzulegen.

Interaktion von Eigenschaften

Die folgenden Beispiele veranschaulichen, wie kombinierte Eigenschaften miteinander interagieren.

Beispiel:

maximumAgeDays = 30
maximumVersions = 10
minimumVersions = 2

Wenn an Tag 23 elf Versionen vorliegen, wird die älteste Version beim nächsten Ausführen der Bereinigungswartungsaufgabe bereinigt, da die Eigenschaft maximumVersions auf den Wert „10“ eingestellt ist.

Wenn an Tag 31 fünf Versionen vorhanden sind, werden nur drei Versionen bereinigt, da die Eigenschaft minimumVersions auf den Wert „2“ eingestellt ist.

Beispiel:

maximumAgeDays = 30
maximumVersions = 0
minimumVersions = 1

Versionen, die noch keine 30 Tage alt sind, werden nicht bereinigt, da die Eigenschaft maximumVersions auf den Wert „0“ eingestellt ist.

Eine Version, die älter als 30 Tage ist, wird beibehalten.

Bereinigung der Auditprotokolle audit-purge

Standardwerte für die Auditprotokollbereinigung audit-purge-defaults

Derzeit ist die Bereinigung nicht standardmäßig aktiviert, aber dies wird sich in Zukunft ändern.

Umgebungen, die nach Aktivierung der standardmäßigen Bereinigung erstellt wurden, haben die folgenden Standardwerte:

  • Replikations-, DAM-und Seiten-Auditprotokolle, die älter als sieben Tage sind, werden entfernt.
  • Alle möglichen Ereignisse werden protokolliert.

Umgebungen, die vor Aktivierung der standardmäßigen Bereinigung erstellt wurden, haben die unten aufgeführten Standardwerte. Es wird jedoch empfohlen, diese Werte zu verringern, um die Leistung zu optimieren.

  • Replikations-, DAM-und Seiten-Auditprotokolle, die älter als sieben Jahre sind, werden entfernt.
  • Alle möglichen Ereignisse werden protokolliert.
NOTE
Es wird empfohlen, dass Kundinnen und Kunden, die durch gesetzliche Vorschriften verpflichtet sind, nicht bearbeitbare Auditprotokolle zu erstellen, hierfür spezialisierte externe Dienste integrieren.

Eigenschaften der Auditprotokollbereinigung audit-purge-properties

Die zulässigen Eigenschaften sind im Folgenden aufgeführt.

Die Spalten, die default angeben, geben die Standardwerte für die Zukunft an, wenn Standardwerte angewendet werden. TBD gibt eine Umgebungs-ID an, die noch nicht ermittelt wurde.

Eigenschaften
Zukünftiger Standard für Umgebungen>TBD
Zukünftiger Standard für Umgebungen<=TBD
Erforderlich
Typ
Werte
Regeln
-
-
Ja
Objekt
Einer oder mehrere der folgenden Knoten: Replikation, Seiten, DAM. Jeder dieser Knoten definiert Regeln mit den unten aufgeführten Eigenschaften. Alle Eigenschaften müssen deklariert werden.
maximumAgeDays
7 Tage
für alle 2557 (7 Jahre + 2 Schalttage)
Ja
Ganzzahl
Bei Replikation, Seiten oder DAM: die Anzahl der Tage, für die die Auditprotokolle aufbewahrt werden. Auditprotokolle, die älter als der konfigurierte Wert sind, werden gelöscht.
contentPath
"/content"
"/content"
Ja
Zeichenfolge
Der Pfad, unter dem die Auditprotokolle für den zugehörigen Typ gelöscht werden. Muss auf "/content" gesetzt sein.
Typen
Alle Werte
Alle Werte
Ja
Array der Auflistung
Für replication lauten die aufgezählten Werte: Activate, Deactivate, Delete, Test, Reverse, Internal Poll. Für pages lauten die aufgezählten Werte: PageCreated, PageModified, PageMoved, PageDeleted, VersionCreated, PageRestoned, PageRolled Out, PageValid, PageInvalid. Für dam lauten die aufgezählten Werte: ASSET_EXPIRING, METADATA_UPDATED, ASSET_EXPIRED, ASSET_REMOVED, RESTORED, ASSET_MOVED, ASSET_VIEWED, PROJECT_VIEWED, PUBLISHED_EXTERNAL, COLLECTION_VIEWED, VERSIONED, ADDED_COMMENT, RENDITION_UPDATED, ACCEPTED, DOWNLOADED, SUBASSET_UPDATED, SUBASSET_REMOVED, ASSET_CREATED, ASSET_SHARED, RENDITION_REMOVED, ASSET_PUBLISHED, ORIGINAL_UPDATED, RENDITION_DOWNLOADED, REJECTED.
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab