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, le nettoyage de la mémoire d’entrepôt 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 purge du journal d’audit purge-tasks

La purge des versions et le journal d’audit réduit la taille du référentiel et, dans certains cas, 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 conservateur, de sorte que la purge ne se produise pas de manière inattendue. Pour plus d’informations sur la stratégie de purge par défaut, reportez-vous aux sections Purge de version et Purge du journal d’audit ci-dessous.

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 la structure de dossiers et de fichiers suivante dans le dossier de niveau supérieur de votre projet dans Git :

config/
     mt.yaml

2 - Déclarez les propriétés dans le fichier de configuration, notamment :

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

Vous devez structurer 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 :

3 - Configurez les pipelines de configuration hors production et en production.

Les environnements de développement rapide ne prennent pas en charge la purge. Pour les autres types d’environnements dans les programmes de production (non Sandbox), créez un pipeline de configuration de déploiement ciblé dans Cloud Manager.

Voir configuration des pipelines de production et configuration des pipelines hors production pour plus d’informations.

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 auront 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, mais il est recommandé de les réduire 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 default indiquent les valeurs par défaut à l’avenir, lorsque les valeurs par défaut sont appliquées ; TBD reflète un ID d’environnement qui n’est toujours pas déterminé.

Interactions de propriété

Les exemples suivants illustrent la manière dont les propriétés interagissent lorsqu’elles sont combinées.

Exemple :

maximumAgeDays = 30
maximumVersions = 10
minimumVersions = 2

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

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

Exemple :

maximumAgeDays = 30
maximumVersions = 0
minimumVersions = 1

Aucune version ultérieure à 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 auront 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, mais il est recommandé de les réduire 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 default indiquent les valeurs par défaut à l’avenir, lorsque les valeurs par défaut sont appliquées ; TBD reflète un ID d’environnement qui n’est toujours pas déterminé.