Visualisation de la volumétrie des tables
Avant de déployer une politique de rétention, il est essentiel d'identifier avec précision les tables qui saturent l'espace de stockage. Business Central propose un outil d'audit natif accessible directement depuis l'interface utilisateur.
Accès à la page “Informations table”: en recherchant la page "Informations table" (Table Information), l'administrateur accède à une vue d'ensemble en temps réel de la base de données.
Les indicateurs clés de l'analyse volumétrique
Nom de la société: cette colonne indique à quelle entité juridique (tenant ou société) appartiennent les données. Certaines tables sont partagées au niveau global du système (laissant la colonne vide), tandis que d'autres, comme les écritures comptables, sont cloisonnées par société.
Nom de la table et N° table: ces champs affichent l'identifiant technique de l'objet et son libellé standard ou spécifique (par exemple, la table 17 pour les écritures comptables "G/L Entry").
Nombre d'enregistrements: il s'agit du nombre total de lignes présentes dans la table. Un nombre élevé n'indique pas forcément une taille critique en Ko, mais cela permet de détecter les tables générant un fort trafic de transactions.
Taille enregistrement: cet indicateur exprime la taille moyenne, en octets, d'une seule ligne de la table. Une table contenant des champs de type BLOB (comme des images ou des gros fichiers textes) présentera une taille d'enregistrement particulièrement élevée.
Taille (Ko): cette colonne représente la taille totale occupée par la table dans la base de données SQL. Elle correspond à l'addition de la taille des données brutes et de la taille des index. C'est la colonne prioritaire pour le tri lors d'une recherche d'optimisation de l'espace.
Taille des données (Ko): cet indicateur isole l'espace mémoire uniquement consommé par les données réelles stockées dans les champs de la table, en excluant les structures d'indexation.
Taille de l'index (Ko): cette valeur indique l'espace requis pour maintenir les clés et les index SQL nécessaires à la rapidité des recherches. Dans certains cas de tables d'historiques fortement indexées, la taille des index peut s'avérer supérieure à celle des données elles-mêmes.
Compression: cette colonne mentionne le type de compression appliqué par l'infrastructure cloud de Microsoft sur la table SQL (généralement le niveau "Page"). Cela permet de réduire l'empreinte physique sur le disque sans altérer la disponibilité des données.
Les politiques de rétention natives (Retention policies)
Le standard de Business Central intègre un outil puissant nommé "Politiques de rétention". Cet outil permet de définir la durée de conservation des données dans des tables spécifiques contenant des données de journalisation ou des fichiers temporaires.
- Rôle de la fonctionnalité: des règles automatiques sont configurées pour spécifier la fréquence à laquelle les données obsolètes doivent être supprimées.
- Tables concernées: cette fonctionnalité s'applique principalement aux tables de registres, aux journaux d'intégration, aux historiques des flux de travaux (workflows) et aux entrées de journal de modifications. Les tables de données financières maîtresses ne sont pas impactées par cet outil direct.
- Processus d'exécution: une fois la politique définie, une écriture dans la file d'attente des travaux (Job Queue) est créée. Les suppressions sont exécutées en arrière-plan sans interruption pour les utilisateurs.
Voici la description technique de la fiche de configuration, rédigée selon la même structure pour ton article:
Configuration d'une fiche de stratégie de rétention
La fiche de stratégie de rétention renferme les champs qui définissent la politique de rétention, permettant de paramétrer précisément le cycle de vie des données pour chaque table sélectionnée. L'écran est structuré en plusieurs sections complémentaires.
Fiche stratégie de rétention
Section Général et Stratégie de rétention
Cette partie supérieure détermine le périmètre global du nettoyage pour la table ciblée:
- ID table et Légende table: ces champs identifient l'objet technique sur lequel s'applique la règle (par exemple, la table 405 représentant les écritures du journal des modifications "Change Log Entry").
- Période de rétention: ce paramètre définit la durée de conservation par défaut avant que les données ne soient considérées comme obsolètes (par exemple, 1 AN, 28 JOURS ou Jamais).
- Activée: ce commutateur permet de mettre en fonction ou de suspendre la politique de rétention. Tant que ce bouton n'est pas activé, aucun traitement automatique de suppression n'est exécuté par la file d'attente des travaux.
- Appliquer à tous les enregistrements: lorsque cette option est cochée, la politique de rétention s'applique uniformément à l'intégralité des lignes de la table sans distinction.
Section Stratégie de rétention d'enregistrement
Lorsque l'option globale n'est pas cochée, ce tableau permet d'affiner le comportement du système en définissant des règles de filtrage avancées:
- Texte filtre table: ce champ permet d'isoler des sous-ensembles de données basés sur des critères précis. L'image illustre un cloisonnement selon le statut des données (Protégé: Oui ou Protégé: Non) ou selon des fonctionnalités spécifiques comme la surveillance des champs sensibles.
- Période de rétention (ligne): une durée de conservation distincte peut être attribuée à chaque filtre. Les données non protégées peuvent ainsi être supprimées après un an, tandis que les journaux de modifications de champs critiques peuvent être nettoyés après 28 jours.
- Conserver dernière version du document: cette option garantit que, même si la période de validité est dépassée, la toute dernière modification enregistrée pour un enregistrement donné n'est pas supprimée afin de maintenir une piste d'audit minimale.
- Activée et Verrouillée: ces cases à cocher indiquent si la ligne de filtre spécifique est active. Le statut "Verrouillé" signale une règle système prédéfinie ou obligatoire qui ne peut pas être modifiée de façon arbitraire par l'utilisateur.
Exécution du nettoyage
Le processus de suppression des données obsolètes peut être déclenché immédiatement par une action de l'utilisateur au travers du bouton "Appliquer manuellement" sur la fiche concernée.
Il peut aussi être automatisé de manière périodique en planifiant l'exécution du codeunit 3997 au sein de la file d'attente des travaux (Job Queue).
Implémentation technique du framework de rétention
L'intégration d'une table personnalisée au framework natif repose sur l'utilisation d'interfaces et d'événements mis à disposition par l'application système de Microsoft.
La logique de configuration est centralisée dans le codeunit "Retention Policy Setup" (ID 3900). C'est ce codeunit qui lève l'événement permettant d'enregistrer de nouvelles tables.
Exemple de code AL
Un codeunit spécifique doit être créé pour encapsuler cette logique. Le code suivant illustre comment inscrire une table personnalisée (nommée ici "Custom Log Entry"):
Extrait de code
codeunit 50100 "Custom Retention Subscriber"
{
Access = Internal;
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Retention Policy Setup", 'OnRegisterExtensionTableFilterList', '', false, false)]
local procedure OnRegisterExtensionTableFilterList(IDataClassificationMgt: Codeunit "Data Classification Mgt."; var TableFilterList: List of [Integer])
var
CustomLogTable: Record "Custom Log Entry";
{
// Ajout de la table spécifique à la liste des tables autorisées
if not TableFilterList.Contains(Database::"Custom Log Entry") then
TableFilterList.Add(Database::"Custom Log Entry");
// Définition obligatoire de la classification des données pour les champs de la table
IDataClassificationMgt.SetTableFieldsToNormal(Database::"Custom Log Entry");
}
}
Fonctionnement lors de l'installation de l'application
Le framework de rétention nécessite que les règles soient initialisées dès que l'extension est déployée sur l'environnement.
- Initialisation par un codeunit d'installation: un codeunit de type Install doit être configuré pour appeler automatiquement le framework lors du premier démarrage ou lors des mises à jour de l'application.
- Utilisation du codeunit "Reten. Pol. Allowed Tables": le codeunit "Reten. Pol. Allowed Tables" (ID 3905) est utilisé durant l'installation pour forcer l'enregistrement immédiat de la table sans attendre qu'un utilisateur ouvre la page de configuration. Cela garantit que la table est prête à recevoir une politique de rétention dès la fin du déploiement.
- Comportement dans l'interface: une fois le traitement d'installation exécuté, la table apparaît instantanément dans la liste des tables disponibles de la page "Politiques de rétention". L'administrateur fonctionnel peut alors configurer les filtres et les critères de date pour planifier le nettoyage automatique.
L'externalisation des pièces jointes et le stockage cloud
Une grande partie de la saturation de la base de données provient des documents annexes (factures fournisseurs PDF, photos d'articles, fiches techniques) stockés directement dans l'ERP.
- Intégration avec SharePoint: le stockage des pièces jointes peut être déporté vers SharePoint Online. Cette stratégie permet de réduire drastiquement la taille de la base de données SQL tout en maintenant un accès direct aux documents depuis la fiche Business Central grâce à des liens sécurisés.
- Utilisation d'Azure Blob Storage: pour les volumes industriels de documents ou les journaux techniques externes, l'utilisation d'Azure Blob Storage est recommandée. Les coûts de stockage y sont nettement inférieurs à ceux de l'espace de base de données Business Central.
Les bonnes pratiques pour la mise en œuvre
Une stratégie de rétention ne doit pas être déployée sans validation préalable. Plusieurs étapes clés sont à respecter:
- Analyse de la capacité: l'examen de la page "Informations sur la capacité de stockage" (Storage Capacity) dans le centre d'administration Business Central permet d'identifier les tables les plus volumineuses.
- Alignement légal: la législation fiscale et comptable de chaque pays doit être vérifiée avant toute compression ou suppression définitive. Les données comptables doivent souvent être conservées dix ans.
- Tests en environnement de bac à sable: toute stratégie de suppression massive ou de compression doit impérativement être validée dans un environnement de Sandbox. Les impacts sur les rapports financiers et les performances du système doivent être mesurés avant le déploiement en production.