La maintenance de la base de données est une tâche que tout administrateur Automic sait qu’il devrait effectuer régulièrement, mais qu’il repousse sans cesse — jusqu’à ce que les données d’exécution, les anciens rapports et les messages système aient surchargé la base de données AE. Pendant des années, la maintenance de la base de données Automic impliquait d'utiliser les utilitaires AE DB locaux ou d'accéder directement à la base de données, ce qui explique précisément pourquoi cette tâche a été reléguée au bas de la liste des priorités. Dans Automic V26, ce problème a disparu : vous pouvez archiver, réorganiser, supprimer et nettoyer les données opérationnelles directement depuis l'interface d'administration AWI et l'API REST AE. Cet article fait partie de notre série consacrée à la mise en œuvre de Automic V26 et se concentre sur l'approche via l'API REST — la vidéo explicative ci-dessous présente ces mêmes opérations de A à Z.
Quels sont les changements apportés à la maintenance de la base de données Automic dans la version 26 ?
Dans les versions précédentes, l'archivage, la réorganisation et le déchargement de la base de données AE étaient gérés par les utilitaires autonomes AE DB ou en intervenant directement sur la base de données. La version Automic V26 place ces activités sous un contrôle régulé et piloté par API : les mêmes tâches de maintenance sont désormais accessibles via l'API REST AE et la perspective d'administration AWI, vous n'avez donc plus besoin des binaires des utilitaires locaux ni des identifiants de connexion directs à la base de données pour les exécuter.
Dans l'ensemble, les données que vous gérez correspondent à ce que Automic appelle les données opérationnelles : messages système, données d'exécution (anciennement appelées statistiques), rapports et commentaires. De manière générale, l'API REST AE couvre cinq opérations : l'archivage des données opérationnelles, la création de rapports de révision, la réorganisation des données opérationnelles, la suppression des données opérationnelles et le vidage de la corbeille.
L'avantage concret réside dans la gouvernance. Le fait de gérer la maintenance via l'API REST AE signifie que chaque opération d'archivage, de réorganisation et de suppression constitue un appel vérifiable et reproductible, plutôt qu'une exécution ponctuelle d'un utilitaire sur le poste de travail d'un utilisateur — et cela peut être autorisé par un seul privilège, au lieu d'un accès au niveau de la base de données. Pour les environnements Automic réglementés, cette traçabilité est tout aussi importante que l'espace libéré dans la base de données.
Privileges et configuration à définir en premier
Avant d'effectuer toute opération de maintenance de la base de données Automic via l'API REST, deux éléments doivent être en place : les droits d'utilisateur appropriés et les variables qui contrôlent chaque opération.
- Privilèges. Le
DB_MAINTENANCEprivilège lance les processus d’archivage, de réorganisation et de suppression. Pour télécharger les paquets d’archives et les rapports de révision, vous devez égalementACCESS_METRICS_ENDPOINT, et pour consulter ou vider la corbeille, vous avez besoin deRECYCLE_BIN. - Variables de configuration dans le client 0. Les paramètres d'archivage se trouvent dans
UC_UTILITY_ARCHIVE, les paramètres de réorganisation dansUC_UTILITY_REORG, et les paramètres de suppression dansUC_UTILITY_DB_UNLOAD. Pour les rapports de révision, la journalisation des objets (OBJECT_AUDIT) doit être activée dansUC_CLIENT_SETTINGS. - Emplacement de sortie. L'archive ou le paquet de rapports est automatiquement enregistré dans le répertoire que vous définissez dans le fichier INI d'Automation Engine pour les systèmes sur site, ou dans le
values.yamlfichier pour les environnements AAKE (containerisés). De là, vous pouvez le transférer là où vous en avez besoin.
Avec les privilèges accordés et les variables configurées une fois, chaque exécution ultérieure est un simple appel d'API. La présentation ci-dessous montre ces opérations dans l'AWI et via l'API REST AE — suivez-la, puis utilisez les appels de référence dans la seconde moitié de ce guide.
Les opérations de maintenance via l'API REST AE
Chaque opération est déclenchée dans le client 0 et peut cibler un seul client (target_client=100) ou tous les clients (target_client=ALL) — vous ne pouvez pas sélectionner un sous-ensemble arbitraire. La plupart des processus renvoient un run_id que vous utilisez pour récupérer le paquet résultant.
Archivage des données opérationnelles
L'archivage permet de collecter les messages système, les données d'exécution, les rapports et les commentaires dans une archive ZIP téléchargeable. Vous l'activez avec une requête POST, puis téléchargez le package avec l'ID d'exécution renvoyé :
POST /ae/api/v1/0/system/clients/archive?target_client=100
→ { "run_id": 1007001 }
GET /ae/api/v1/0/system/clients/archive/1007001
→ (télécharge le paquet d'archives)Avec un client REST tel que Postman, utilisez l'option « Envoyer et télécharger » ; avec cURL, ajoutez -o pour enregistrer le fichier sur le disque. Le même point de terminaison, appelé avec la méthode « reset », désactive le drapeau d'archivage.
Création de rapports de révision
Les rapports de révision vous donnent un enregistrement chronologique, prêt pour un audit, des modifications apportées à un client — objets créés, suppressions, transports, connexions utilisateur et plus encore — ce qui maintient un environnement réglementé en conformité. Vous pouvez définir la portée d'un rapport par plage de dates et par type de modification :
POST /ae/api/v1/0/system/clients/revisionreport?target_client=ALL
{
"from": "2026-01-01T00:00:00Z",
"to": "2026-03-31T00:00:00Z",
"types": ["CREATE", "DELETE", "OBJ_MOD", "USER", "TRNSPRT"]
}Si types est omis, toutes les catégories de modification sont incluses. Le rapport est téléchargé avec ses run_id, exactement comme un fichier d'archive.
Réorganisation des données opérationnelles
La réorganisation des données opérationnelles marque les enregistrements anciens pour suppression sans les supprimer pour l'instant. La logique de conservation combine deux paramètres : une réorganisation des enregistrements plus anciens qu'un certain nombre de jours et la conservation du dernier décompte. Par exemple, si le paramètre « réorganiser les enregistrements plus anciens que » est défini sur 30 et le paramètre « conserver le dernier » sur 5, le processus conserve tous les enregistrements des 30 derniers jours ainsi que les cinq enregistrements les plus anciens par objet.
POST /ae/api/v1/0/system/clients/reorg?target_client=ALLSuppression des données opérationnelles
Une fois les enregistrements marqués, la suppression des données opérationnelles les retire définitivement de la base de données AE. C'est un déclencheur unique par client ou pour tous les clients :
POST /ae/api/v1/0/system/clients/deletedata?target_client=ALLVider la corbeille
Les objets supprimés sont déplacés vers la Corbeille au lieu de disparaître immédiatement. À partir du client 0, vous pouvez lister le contenu de la corbeille d'un client, puis la vider :
GET /ae/api/v1/0/recyclebin?target_client=100
DELETE /ae/api/v1/0/recyclebin?target_client=TOUTLes objets contenant encore des données opérationnelles non archivées ne sont pas supprimés ; ils sont renvoyés dans la réponse sous failedObjects. La règle d'or est simple : archiver d'abord, vider ensuite.
Réinitialiser les indicateurs d'archivage et de réorganisation
Si vous avez besoin de relancer un cycle — par exemple, pour archiver des enregistrements qui ont déjà été marqués — les points de terminaison d'archivage et de réorganisation acceptent une méthode de réinitialisation qui efface le drapeau correspondant. Cela vous permet de corriger une exécution mal programmée sans toucher à la base de données, en gardant l'ensemble du cycle de maintenance à l'intérieur de l'API REST AE.
Faites de la maintenance de la base de données Automic une tâche planifiée, et non une corvée
Comme chaque opération est désormais un simple appel REST, la suite logique consiste à ne plus les exécuter manuellement. Intégrez la séquence " archivage → réorganisation → suppression " dans un workflow Automic planifié afin que la base de données AE soit mise à jour à une fréquence prévisible — et n’oubliez pas d’inclure le Client 0, qui stocke les journaux du serveur et des agents et que l’on a tendance à oublier. Si vous préférez appeler les points de terminaison à partir d'un script, la nouvelle intégration Python de Automic V26 vous permet de les invoquer depuis une tâche Python native parallèlement à votre logique d'automatisation existante. La maintenance fiable de la base de données Automic est l'un des aspects les moins prestigieux, mais les plus lourds, d'une bonne exploitation de la version V26.
Une approche judicieuse consiste à réorganiser selon un calendrier régulier, à archiver avant de supprimer, et à vider la corbeille une fois qu'il est confirmé que rien n'est resté non archivé. L'ajustement des seuils de rétention en fonction de votre volume de données est là où réside la majeure partie de la valeur : suffisamment agressif pour maintenir une base de données légère, suffisamment conservateur pour satisfaire votre fenêtre d'audit.
Ce guide fait partie de notre série de ressources consacrée à la mise en œuvre de la version Automic V26. Si SAP occupe une place centrale dans votre environnement, le document complémentaire sur la prise en charge de plusieurs systèmes par l'agent SAP aborde une autre modification de la version V26 qu'il convient d'examiner avant de procéder à la mise à niveau. Pour les spécifications officielles, consultez la présentation de la version Automic V26 de Broadcom et la documentation relative à la maintenance de la base de données de l'API REST 26.0 AE.
Questions fréquemment posées
De quels privilèges ai-je besoin pour effectuer la maintenance de la base de données Automic via l'API REST ?
Vous avez besoin du privilège DB_MAINTENANCE pour démarrer l'archivage, la réorganisation et la suppression. Pour télécharger les packages d'archive et les rapports de révision, vous avez également besoin d'ACCESS_METRICS_ENDPOINT, et pour lire ou vider la corbeille, vous avez besoin du privilège RECYCLE_BIN.
Cela fonctionne-t-il sur site ainsi que dans les environnements AAKE conteneurisés ?
Oui. Les opérations sont identiques ; seul l'emplacement de sortie diffère. Sur site, vous définissez le répertoire du package dans le fichier INI d'Automation Engine, et dans les environnements AAKE (conteneur), vous le définissez dans le fichier values.yaml.
Quels types de données opérationnelles sont pris en compte par le code Automic ?
Les données opérationnelles comprennent les messages système, les données d'exécution (anciennement appelées statistiques), les rapports et les commentaires. Ce sont les enregistrements qui s'accumulent pendant le fonctionnement quotidien et que la maintenance est conçue pour archiver, réorganiser et supprimer.
Puis-je exécuter la maintenance pour tous les clients en même temps ?
Oui. Du Client 0, vous pouvez cibler un seul client avec target_client=100 ou tous les clients avec target_client=ALL. Vous ne pouvez pas sélectionner un sous-ensemble arbitraire de clients en un seul appel.
Comment télécharger un paquet d'archives ou un rapport de révision ?
Utilisez le run_id renvoyé lors du déclenchement du processus dans une requête GET ultérieure. Dans Postman, utilisez l'option Enregistrer et télécharger ; avec cURL, ajoutez le drapeau -o pour écrire le fichier sur le disque.
Quelle est la différence entre réorganiser et supprimer ?
La réorganisation marque les données opérationnelles obsolètes pour suppression en fonction de vos paramètres de rétention, mais les laisse dans la base de données. La suppression supprime ensuite définitivement les enregistrements marqués. L'exécution de la réorganisation d'abord, puis de la suppression, vous permet de contrôler ce qui quitte réellement la base de données.
Où le package d'archives ou de rapports est-il stocké ?
Lorsque vous déclenchez le processus, une tâche d'arrière-plan collecte les données dans un fichier ZIP et les écrit dans le répertoire défini dans le fichier INI d'Automation Engine (sur site) ou dans le fichier values.yaml (AAKE). Vous le téléchargez ou le transférez ensuite à partir de là.
Planifiez votre configuration de maintenance V26
Le transfert de la maintenance de la base de données vers l'API REST est un changement mineur qui apporte des avantages considérables en termes de conformité aux audits et de santé de la base de données — mais il est important de définir correctement les privilèges, les seuils de conservation et le calendrier en fonction de votre environnement spécifique. Si vous souhaitez bénéficier d'un deuxième avis sur votre configuration V26, réservez une consultation gratuite avec l'équipe Tricise Automic.
