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.

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

Standorte:

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.

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.

1 Erstellen Sie eine Datei mit dem Namen mt.yaml oder ähnlich.

2 Platzieren Sie die Datei unter einem Ordner der obersten Ebene mit dem Namen config oder ähnlich, wie unter Verwenden von Konfigurations-Pipelines beschrieben.

3 Deklarieren Sie Eigenschaften in der Konfigurationsdatei, die Folgendes enthalten:

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

Strukturieren Sie die Konfiguration ähnlich wie im folgenden Beispiel:

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:

4 Erstellen Sie in Cloud Manager eine Konfigurations-Pipeline. Folgen Sie dabei den Anweisungen im Artikel zu Konfigurations-Pipelines. Sandboxes und schnelle Entwicklungsumgebungen (Rapid Development Environments, RDEs) unterstützen keine Bereinigungen.

Versionsbereinigung version-purge

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:

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.

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.

Interaktion von Eigenschaften

Die folgenden Beispiele veranschaulichen, wie kombinierte Eigenschaften miteinander interagieren.

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

Zum 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:

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.

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.