Tâches de maintenance dans AEM as a Cloud Service maintenance-tasks-in-aem-as-a-cloud-service

Les tâches de maintenance sont des processus qui s’exécutent selon un calendrier afin d’optimiser le référentiel. Avec AEM as a Cloud Service, le besoin des clients de configurer les propriétés opérationnelles des tâches de maintenance est minime. Les clients peuvent concentrer leurs ressources sur des préoccupations de niveau application, laissant les opérations d’infrastructure à Adobe.

Configuration des tâches de maintenance maintenance-tasks-configuring

Dans les versions précédentes d’AEM, vous pouviez configurer les tâches de maintenance à l’aide de la carte de maintenance (Outils > Opérations > Maintenance). Dans AEM as a Cloud Service, la carte de maintenance n’est plus disponible. Les configurations doivent donc être validées pour le contrôle source et déployées à l’aide de Cloud Manager. Adobe gère les tâches de maintenance dont les paramètres ne peuvent pas être configurés par les clients (par exemple, la récupération de l’espace mémoire du magasin de données). D’autres tâches de maintenance peuvent être configurées par les clients, comme décrit dans le tableau ci-dessous.

Le tableau suivant illustre les tâches de maintenance disponibles.

Emplacements  :

Exemples de code  :

Exemple de code 1 (quotidien)

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

Exemple de code 2 (hebdomadaire)

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

Exemple de code 3 (mensuel)

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

Tâches de maintenance de purge de version et de journaux d’audit purge-tasks

La purge des versions et du journal d’audit réduit la taille du référentiel et, dans certains scénarios, peut améliorer les performances.

Paramètres par défaut defaults

Actuellement, la purge n’est pas activée par défaut, mais cela changera à l’avenir. Les environnements créés avant l’activation de la purge par défaut auront un seuil plus prudent afin que la purge ne se produise pas de manière inattendue. Consultez les sections Purge de version et Purge du journal d’audit ci-dessous pour plus d’informations sur la politique de purge par défaut.

Les valeurs de purge par défaut peuvent être remplacées en déclarant un fichier de configuration et en le déployant comme décrit ci-dessous.

Application d’une configuration configure-purge

Déclarez un fichier de configuration et déployez-le comme décrit dans les étapes suivantes.

1 Créez un fichier nommé mt.yaml ou similaire.

2 Placez le fichier quelque part sous un dossier de niveau supérieur nommé config ou similaire, comme décrit sous Utilisation de pipelines de configuration.

3 - Déclarez les propriétés dans le fichier de configuration, parmi lesquelles :

Consultez les définitions et la syntaxe des objets versionPurge et auditLogPurge ci-dessous.

Structurez la configuration comme dans l’exemple suivant :

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

Gardez à l’esprit que pour que la configuration soit valide :

4 - Créez un pipeline de configuration dans Cloud Manager, comme décrit dans l’article pipeline de configuration.

Purge de version version-purge

Valeurs par défaut de la purge de version version-purge-defaults

Actuellement, la purge n’est pas activée par défaut, mais cela changera à l’avenir.

Les environnements créés après l’activation de la purge par défaut ont les valeurs par défaut suivantes :

Les valeurs par défaut des environnements créés avant l’activation de la purge par défaut sont répertoriées ci-dessous. Il est toutefois recommandé de réduire ces valeurs afin d’optimiser les performances.

Propriétés de purge de version version-purge-properties

Les propriétés autorisées sont répertoriées ci-dessous.

Les colonnes indiquant par défaut indiquent les valeurs par défaut dans le futur, lorsque les valeurs par défaut sont appliquées ; à déterminer reflète un identifiant d’environnement qui n’est toujours pas déterminé.

Interactions de propriétés

Les exemples suivants illustrent l’interaction des propriétés lorsqu’elles sont combinées.

Exemple :

maximumAgeDays = 30
maximumVersions = 10
minimumVersions = 2

S’il existe 11 versions au jour 23, la version la plus ancienne sera purgée la prochaine fois que la tâche de maintenance de purge s’exécutera, puisque la propriété maximumVersions est définie sur 10.

S’il existe 5 versions au jour 31, seules 3 seront purgées, car la propriété minimumVersions est définie sur 2.

Exemple :

maximumAgeDays = 30
maximumVersions = 0
minimumVersions = 1

Aucune version de plus de 30 jours ne sera purgée, car la propriété maximumVersions est définie sur 0.

Une version de plus de 30 jours sera conservée.

Purge du journal d’audit audit-purge

Valeurs par défaut de la purge du journal d’audit audit-purge-defaults

Actuellement, la purge n’est pas activée par défaut, mais cela changera à l’avenir.

Les environnements créés après l’activation de la purge par défaut ont les valeurs par défaut suivantes :

Les valeurs par défaut des environnements créés avant l’activation de la purge par défaut sont répertoriées ci-dessous. Il est toutefois recommandé de réduire ces valeurs afin d’optimiser les performances.

Propriétés de purge du journal d’audit audit-purge-properties

Les propriétés autorisées sont répertoriées ci-dessous.

Les colonnes indiquant par défaut indiquent les valeurs par défaut dans le futur, lorsque les valeurs par défaut sont appliquées ; à déterminer reflète un identifiant d’environnement qui n’est toujours pas déterminé.