蜜豆视频

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

Maintenance Tasks are processes that run on a schedule to optimize the repository. With AEM as a Cloud Service, the need for customers to configure the operational properties of maintenance tasks is minimal. Customers can focus their resources on application-level concerns, leaving the infrastructure operations to 蜜豆视频.

Configuring maintenance tasks maintenance-tasks-configuring

In previous versions of AEM, you could configure maintenance tasks by using the Maintenance Card (Tools > Operations > Maintenance). For AEM as a Cloud Service, the Maintenance Card is no longer available so configurations should be committed to source control and deployed by using the Cloud Manager. 蜜豆视频 manages those maintenance tasks which have settings that are not configurable by customers (for example, Datastore Garbage Collection). Other maintenance tasks can be configured by customers, as described in the table below.

The following table illustrates the maintenance tasks that are available.

Locations:

Code samples:

Code sample 1 (daily)

<?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 sample 2 (weekly)

<?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 sample 3 (monthly)

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

Version Purge and Audit Log Purge Maintenance Tasks purge-tasks

Purging versions and the audit log reduces the size of the repository, and in some scenarios, can improve performance.

Defaults defaults

Currently, purging is not enabled by default, but this will change in the future. Environments that were created before the default purging is enabled will have a more conservative threshold so that purging does not occur unexpectedly. See the Version Purge and Audit Log Purge sections below for more details about the default purging policy.

The default purge values can be overridden by declaring a configuration file and deploying it as described below.

Applying a configuration configure-purge

Declare a configuration file and deploy it as described in the following steps.

1 Create a file named mt.yaml or similar.

2 Place the file somewhere under a top level folder named config or similar, as described under Using Config Pipelines.

3 - Declare properties in the configuration file, which include:

See the definitions and syntax of the versionPurge and auditLogPurge objects below.

Structure the configuration similar to the following example:

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"]

Keep in mind that in order for the configuration to be valid:

4 - Create a config pipeline in Cloud Manager, as described in the config pipeline article. Sandboxes and rapid development environments (RDEs) do not support purging.

Version Purge version-purge

Version Purge Defaults version-purge-defaults

Currently, purging is not enabled by default, but this will change in the future.

Environments that were created after the default purging is enabled will have the following default values:

Environments that were created before the default purging is enabled will have the default values listed below, however it is recommended to lower those values in order to optimize performance.

Version Purge Properties version-purge-properties

The allowed properties are listed below.

The columns indicating default indicate the default values in the future, when defaults are applied; TBD reflects an environment id that is still not determined.

Property interactions

The following examples illustrate how properties interact when combined.

Example:

maximumAgeDays = 30
maximumVersions = 10
minimumVersions = 2

If there are 11 versions on day 23, the oldest version will be purged next time the purge maintenance task runs, since the maximumVersions property is set to 10.

If there are 5 versions on day 31, only 3 will be purged since the minimumVersions property is set to 2.

Example:

maximumAgeDays = 30
maximumVersions = 0
minimumVersions = 1

No versions newer than 30 days will be purged since the maximumVersions property is set to 0.

One version older than 30 days will be kept.

Audit Log Purge audit-purge

Audit Log Purge Defaults audit-purge-defaults

Currently, purging is not enabled by default, but this will change in the future.

Environments that were created after the default purging is enabled will have the following default values:

Environments that were created before the default purging is enabled will have the default values listed below, however it is recommended to lower those values in order to optimize performance.

Audit Log Purge Properties audit-purge-properties

The allowed properties are listed below.

The columns indicating default indicate the default values in the future, when defaults are applied; TBD reflects an environment id that is still not determined.