L'historique des modifications

Chaque création, modification et suppression sur une table journalisée écrit des entrées dans la table BSPK_HISTORY. Ce journal sert l'annuler/rétablir du dev-panel, dit « quand et qui » à la réconciliation du contenu, et permet de retrouver et de restaurer un enregistrement supprimé. Une tâche quotidienne archive les entrées anciennes.

Ce qui est journalisé

Le journal est écrit par les événements ORDA des classes d'entité (enregistrement, suppression). Le composant injecte ces événements, entre les balises /*** START BSPKENTITY ***/ et /*** END BSPKENTITY ***/ :

dans les classes des tables BSPK_*, toujours ;
dans les classes de vos tables seulement si le paramètre vo_Param.vb_AddBSPKDataClass vaut vrai (voir Les fichiers de paramètres).

Ne sont jamais journalisés : les tables BSPK_ERROR et BSPK_TASK_MANAGER, et les champs ID, uuidKey, createdOn, createdBy, modifiedOn, modifiedBy.

Retirer une de vos tables du journal : déclarez dans sa classe d'entité, après la balise END BSPKENTITY (ce qui la précède est réécrit à chaque injection) :

Function bspkIsHistorized->$vb : Boolean
	return False

Seul le journal est coupé : l'horodatage et la notification des clients connectés continuent.

Si vous déclarez vous-même un événement (event validateSave…) dans une classe d'entité journalisée, celui du composant est désactivé, et le journal avec. Passez par les points d'extension bspkOnXxx.

Une entrée

Champ	Contenu
`codeAction`	`1CREATE`, `5UPDATE` ou `9DELETE`
`recordInfos`	la table et la clé primaire de l'enregistrement
`newValues`, `oldValues`	création : tous les champs renseignés ; modification : une entrée par champ modifié (`fieldName`), ancienne et nouvelle valeur ; suppression : l'enregistrement complet
`createdOn`, `createdBy`, `userUuid`	quand, et qui (l'utilisateur connecté)
`groupUuid`	toutes les entrées d'une même action de l'utilisateur, pour l'annuler/rétablir
`infos.origin`	la provenance : import d'un échange, API Claude, mise à jour de version…

Consulter l'historique

Dans une liste de l'ATL, clic droit sur la colonne de la clé primaire → Chercher dans l'historique. L'écran filtre par période, table, champ et valeur, avec ou sans les enregistrements liés, et exporte en CSV. Un double-clic sur une clé ouvre l'enregistrement dans l'ATL.

Restaurer : sur une ligne de suppression, quand l'enregistrement n'existe plus, la restauration le recrée à partir de l'entrée. Les enregistrements liés ne sont pas restaurés, et la date et l'auteur de création deviennent ceux de la restauration.

Quand la période commence avant la plus ancienne entrée encore en base, la recherche lit aussi les archives.

L'archivage

La tâche planifiée CRON_EXPORT_BSPK_HISTORY tourne tous les jours à 03:05. Elle est recréée ou réparée à chaque démarrage : toutes les bases archivent. Pour garder plus d'historique, augmentez la durée de conservation ; désactiver la tâche ne survivrait pas au redémarrage.

Les entrées plus anciennes que la durée de conservation sont regroupées par jour.
Chaque jour part dans un zip, <dossier>/AAAA-MM-JJT.zip (un zip existant pour ce jour est complété).
Les entrées archivées sont supprimées de la table.

Une vérification préalable est faite sur la mémoire des dates de la réconciliation : si elle échoue, rien n'est archivé et un mail d'alerte part.

Paramètre (`vo_Param` dans `APP_PARAMETERS`)	Par défaut
`vl_BspkHistoryRetentionDays`	30 jours
`vt_BspkHistoryArchiveFolder`	`Logs/Archive` du dossier de données

Les deux clés sont ajoutées automatiquement si elles manquent. Au démarrage d'un serveur (ou en monoposte), si le dossier d'archive n'est pas défini, n'existe pas ou n'est pas accessible en écriture, un dialogue propose un dossier à côté de l'installation : Changer… / Utiliser ce dossier / Plus tard (« Plus tard » au bout de 60 secondes). Garder les archives hors du dossier de données leur évite de grossir chaque sauvegarde.

BSPK_HISTORY_ARCHIVE_SET($dossier) change le dossier d'archive par code : il vérifie qu'on peut y écrire, enregistre le chemin et y déplace les archives existantes.

BSPK_HISTORY_PURGE supprime sans archiver : l'annuler/rétablir n'a plus rien à rejouer. À réserver à un nouveau départ, par exemple après le passage de la version 20 à la version 21.

Bon à savoir