Paramètres épurations
Cette fonction permet de définir les paramètres liés aux fonctions d'épuration et d'historisation.
Les progiciels en technologie SAFE X3 peuvent gérer, par le biais de la fonction d'épuration / archivage, le transfert vers des archives ou la purge de mouvements qui n'évoluent plus, et qui sont considérés comme suffisamment anciens pour ne plus être consultés fréquemment.
Seules sont épurables ou archivables les données considérées comme soldées (ie. non susceptibles de continuer à évoluer).
L'archivage se fait par transfert des données d'une table du dossier vers une table de même structure (à deux champs près, CREHISDAT et CREHISUSR, qui permettent de connaître les dates et opérateurs ayant archivé la donnée). Cette table est définie dans un dossier dédié, qui utilise par ailleurs le dossier courant comme dossier mère, et dont la création est faite automatiquement lors du premier archivage.
L'intérêt de cette façon de faire réside dans le fait que les fonctions de consultation standard sur les données de l'historique fonctionnent alors par simple connexion sur ce dossier, de la même façon qu'elles fonctionnent sur le dossier en cours.
Lorsqu'on est connecté sur le fichier archive, on ne pourra voir les données archivées que séparément, et pas simultanément avec les données de même type non archivées. Par contre, si une table archive fait référence à des données de base (non susceptibles d'être archivées par définition) ou à des données pour lesquelles aucune table archive n'a été définie, la consultation pourra se faire par zoom sur ces données non archivées.
Le paramétrage des règles d'épuration permet de définir les durées de vie à partir desquelles des mouvements peuvent être épurés ou archivés, en suivant des règles de cohérence par groupe de tables définies par ailleurs.
En fonction du module métier concerné, le traitement peut s'appuyer également sur la valeur de certains paramètres. Leur liste est donnée dans un document annexe.
Si on désire voir en spécifique des mouvements situés pour certains dans le dossier d'exploitation et pour certains dans le dossier archive, il faudra définir des requêtes SQL de type union sur des les deux tables concernées, par exemple par le biais de requêtes SQL ou de vues spécifiques.
Gestion de l'écran
Ecran de saisie
Lorsqu'on entre dans la fonction, on retrouve un tableau contenant des paramètres d'archivage et d'épuration, associés à un groupe de tables identifiés par un code (par exemple ASUPER pour certaines tables du superviseur). Au niveau de l'application, un groupe de tables est défini par une fonction dédiée de développement. Un groupe de tables contient des tables liées entre elles de façon cohérente, et dont l'épuration ou l'archivage n'a de sens que globalement (des données organisées par exemple en en-tête et en lignes doivent être dans le même groupe).
A chaque groupe de table, on associe un ensemble de paramètres caractéristiques des opérations d'épuration et d'historisation lançables sur chaque groupe de tables.
Tableau
| Code (champ COD) |
|
Ce code identifie la formule d'épuration. Le code épuration AUDITASD (table Audit SData) permet d'épurer les enregistrements de la table d'audit ayant été traités par le traitement de synchronisation utilisé pour l'interface CRM. Les enregistrement épurés sont ceux dont le numéro de séquence est strictement inférieur au numéro de la dernière mise à jour de la table de synchronisation.
|
| Intitulé (champ DES) |
| Historisation (champ FLG1) |
|
Si cet indicateur est positionné à Oui, la fonction d’épuration créera la table d’historisation si elle n’existe pas, et y transférera les données à placer en historique |
| Jours (champ TIM1) |
|
Cette champ exprimé en jours, correspond à la durée à partir de laquelle une donnée peut être archivée. |
| Fréquence (champ FRQ1) |
|
Ce délai, exprimé en jours, permet de ne lancer le traitement d’archivage sur un groupe que si la dernière opération d’archivage n’a pas eu lieu depuis ce délai |
| Date (champ DAT1) |
|
Dernière date à laquelle une historisation a effectivement eu lieu |
| Epuration (champ FLG2) |
|
Si cet indicateur est positionné à Oui, la fonction d’épuration supprimera des données épurables lors de son lancement |
| Jours (champ TIM2) |
|
Ce champ, exprimé en jours, correspond à la durée à partir de laquelle une donnée peut être épurée. |
| Fréquence (champ FRQ2) |
|
Ce délai, exprimé en jours, permet de ne lancer le traitement d’épuration sur un groupe que si la dernière opération d’épuration n’a pas eu lieu depuis ce délai. |
| Date (champ DAT2) |
|
Dernière date à laquelle une épuration a effectivement eu lieu |
Autres conditions
Il est important de noter les points suivants :
- Si des données ne sont pas archivées, mais épurées, la durée de vie d'une information soldée est limitée au temps en jours donné dans la durée avant épuration. Par exemple, une donnée soldée avec une durée de vie de 100 jours sera épurée au lancement du traitement d'épuration 100 jours après la date de référence.
- Si des données ne sont archivées, puis épurées, la durée de vie d'une information soldée, est limitée à la somme des temps en jours donnés dans la durée avant archivage, puis dans la durée avant épuration. Par exemple, une donnée soldée avec une durée de vie de 100 jours en archive en 200 jours en épuration sera archivée au lancement du traitement d'épuration 100 jours après la date de référence. Elle restera ensuite au minimum 200 jours dans la table archive avant d'être épurée (elle aura donc une durée de vie réelle de 300 jours minimum).
La durée maximale d'épuration ou d'archivage peut être saisie sur 4 chiffres, ce qui correspond à 27 ans (on peut aussi déclarer simultanément Non à l'archivage et à l'épuration).
Reportez-vous à la documentation de