Show Menu
THEMEN×

Maintenance-Aufgaben in AEM als Cloud Service

Aufgaben zur Wartung sind Prozesse, die planmäßig ausgeführt werden, um das Repository zu optimieren. Mit AEM als Cloud Service müssen die Kunden die betrieblichen Eigenschaften von Maintenance-Aufgaben nur minimal konfigurieren. Kunden können ihre Ressourcen auf Probleme auf Anwendungsebene konzentrieren, wobei die Infrastrukturvorgänge Adobe überlassen bleiben.
Weitere Informationen zu Aufgaben der Wartung finden Sie auf den folgenden Seiten:

Aufgaben zur Wartung konfigurieren

In früheren Versionen von AEM können Sie die Maintenance-Aufgaben mithilfe der Maintenance-Karte konfigurieren (Tools > Vorgänge > Wartung). Für AEM als Cloud Service ist die Maintenance-Karte nicht mehr verfügbar. Daher sollten Konfigurationen der Quellcodeverwaltung unterliegen und mithilfe des Cloud-Managers bereitgestellt werden. Adobe verwaltet Wartungs-Aufgaben, für die keine Kundenentscheidung erforderlich ist (z. B. Datastore Garbage Collection), während andere Wartungs-Aufgaben vom Kunden konfiguriert werden können (siehe folgende Tabelle).
Adobe behält sich das Recht vor, die Konfigurationseinstellungen der Aufgabe für die Wartung außer Kraft zu setzen, um Probleme wie Leistungsbeeinträchtigung zu vermeiden.
Die folgende Tabelle zeigt die Aufgaben zur Wartung, die zum Zeitpunkt der Veröffentlichung von AEM als Cloud Service verfügbar sind.
Aufgabe der Wartung
Wem gehört die Konfiguration
Konfigurieren (optional)
Datastore-Müllsammlung
Adobe
Nicht zutreffend - vollständig im Besitz von Adobe
Versionsbereinigung
Adobe
Adobe ist vollständig im Besitz, aber in Zukunft können Kunden bestimmte Parameter konfigurieren.
Bereinigung des Prüfprotokolls
Adobe
Adobe ist vollständig im Besitz, aber in Zukunft können Kunden bestimmte Parameter konfigurieren.
Lucene-Binärdateien-Bereinigung
Adobe
Nicht verwendet und daher von Adobe deaktiviert.
Ad-hoc-Aufgaben-Bereinigung
Kunde
Muss in github gemacht werden.
Überschreiben Sie den Konfigurationsknoten im vordefinierten Wartungsfenster /libs durch Erstellen von Eigenschaften im Ordner /apps/settings/granite/operations/maintenance/granite_weekly oder granite_daily . Weitere Konfigurationsdetails finden Sie in der Tabelle des Wartungsfensters.
Aktivieren Sie die Maintenance-Aufgabe, indem Sie unter dem Knoten oben einen weiteren Knoten mit den entsprechenden Eigenschaften hinzufügen (nennen Sie ihn granite_TaskPurgeTask ).
Informationen zum Konfigurieren der OSGI-Eigenschaften finden Sie in der Dokumentation zur AEM 6.5 Maintenance Aufgabe
Workflow-Bereinigung
Kunde
Muss in github gemacht werden.
Überschreiben Sie den Konfigurationsknoten im vordefinierten Wartungsfenster, /libs indem Sie Eigenschaften im Ordner /apps/settings/granite/operations/maintenance/granite_weekly oder granite_daily erstellen. Weitere Konfigurationsdetails finden Sie in der Tabelle des Wartungsfensters.
Aktivieren Sie die Maintenance-Aufgabe, indem Sie unter dem Knoten oben einen weiteren Knoten mit den entsprechenden Eigenschaften hinzufügen (nennen Sie ihn granite_WorkflowPurgeTask ).
Konfigurieren der OSGI-Eigenschaften siehe Dokumentation zur AEM 6.5 Maintenance Aufgabe
Projekt-Bereinigung
Kunde
Muss in github gemacht werden.
Überschreiben Sie den Konfigurationsknoten im vordefinierten Wartungsfenster /libs durch Erstellen von Eigenschaften im Ordner /apps/settings/granite/operations/maintenance/granite_weekly oder granite_daily . Weitere Konfigurationsdetails finden Sie in der Tabelle des Wartungsfensters.
Aktivieren Sie die Maintenance-Aufgabe, indem Sie einen Knoten unter dem oben stehenden Knoten (Name) mit den entsprechenden Eigenschaften hinzufügen granite_ProjectPurgeTask .
Konfigurieren von OSGI-Eigenschaften siehe Dokumentation zur AEM 6.5 Maintenance Aufgabe
Die Kunden können die Ausführung der einzelnen Aufgaben für Workflow-Bereinigung, Ad-hoc-Aufgaben-Bereinigung und Projektbereinigung während des täglichen, wöchentlichen oder monatlichen Wartungsfensters planen. Diese Konfigurationen sollten direkt in der Quellcodeverwaltung bearbeitet werden. Die folgende Tabelle beschreibt die für jedes Fenster verfügbaren Konfigurationsparameter.
Konfiguration des Wartungsfensters Wem gehört die Konfiguration Konfigurationstyp Ort Beispiel Parameter
Täglich Kunde JCR-Knotendefinition /apps/settings/granite/operations/maintenance/granite_daily Siehe Codebeispiel 1 unten
  • windowSchedule = daily (dieser Wert sollte nicht geändert werden)
  • windowStartTime = HH:MM unter Verwendung als 24-Stunden-Uhr. Definiert, wann die mit dem täglichen Wartungsfenster verknüpften Aufgaben mit der Ausführung beginnen sollen.
  • windowEndTime = HH:MM unter Verwendung als 24-Stunden-Uhr. Definiert, wann die mit dem täglichen Wartungsfenster verknüpften Maintenance-Aufgaben die Ausführung beenden sollen, wenn sie noch nicht abgeschlossen sind.
Wöchentlich Kunde JCR-Knotendefinition /apps/settings/granite/operations/maintenance/granite_weekly Siehe Codebeispiel 2 unten
  • windowSchedule = weekly (dieser Wert sollte nicht geändert werden)
  • windowStartTime = HH:MM unter Verwendung als 24-Stunden-Uhr. Definiert, wann die mit dem wöchentlichen Wartungsfenster verknüpften Maintenance-Aufgaben mit der Ausführung beginnen sollen.
  • windowEndTime = HH:MM unter Verwendung als 24-Stunden-Uhr. Definiert, wann die mit dem wöchentlichen Wartungsfenster verknüpften Maintenance-Aufgaben die Ausführung beenden sollen, wenn sie noch nicht abgeschlossen sind.
  • windowScheduleWeekdays = Array mit 2 Werten von 1-7. z. B. [5,5]. Der erste Wert des Arrays ist der Tag des Beginns, an dem der Auftrag geplant wird, und der zweite Wert ist der Endtag, an dem der Auftrag beendet wird. Die genaue Uhrzeit des Beginns und des Endes wird durch windowStartTime bzw. windowEndTime bestimmt.
Monatlich Kunde JCR-Knotendefinition /apps/settings/granite/operations/maintenance/granite_monthly Siehe Codebeispiel 3 unten
  • windowSchedule = daily (dieser Wert sollte nicht geändert werden)
  • windowStartTime = HH:MM unter Verwendung als 24-Stunden-Uhr. Definiert, wann die mit dem monatlichen Wartungsfenster verknüpften Aufgaben mit der Ausführung beginnen sollen.
  • windowEndTime = HH:MM unter Verwendung als 24-Stunden-Uhr. Definiert, wann die mit dem monatlichen Wartungsfenster verknüpften Aufgaben nicht mehr ausgeführt werden sollten, wenn sie noch nicht abgeschlossen sind.
  • windowScheduleWeekdays = Array mit 2 Werten von 1-7. z. B. [5,5]. Der erste Wert des Arrays ist der Tag des Beginns, an dem der Auftrag geplant wird, und der zweite Wert ist der Endtag, an dem der Auftrag beendet wird. Die genaue Uhrzeit des Beginns und des Endes wird durch windowStartTime bzw. windowEndTime bestimmt.
  • windowFirstLastStartDay - 0/1 0, um die erste Woche des Monats zu planen, oder 1, um die letzte Woche des Monats zu planen. Wenn kein Wert vorhanden ist, werden Aufträge praktisch jeden Tag gemäß den Regeln von windowScheduleWeekdays jeden Monat terminiert.
Codebeispiel 1
<?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"
 />

Codebeispiel 2
<?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"/>

Codebeispiel 2
<?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"/>