Historique
Présentation
L'historique est une fonctionnalité permettant de suivre toutes les modifications effectuées sur les données d'une table (création d'enregistrements, mise à jour ou suppression).
Ceci constitue une version améliorée de la piste d'audit XML. La piste d'audit XML est activée par défaut, mais peut être désactivée en toute sécurité si l'historique est mis en place pour les tables concernées.
Configuration de l'historique
Afin d'activer l'historisation d'une table, un profil d'historique doit être défini pour cette table dans le modèle de données. Cette section décrit les profils d'historique et comment ils sont associés aux tables.
Configuration de l'historique dans le référentiel
Un profil d'historique spécifie le moment où l'historisation doit être mise en place. Pour modifier les profils d'historique, sélectionner Administration > Historique et journaux.
Un profil d'historique est identifié par un nom et définit les informations suivantes :
un libellé internationalisé,
une liste d'espaces de données (branches) pour lesquels l'historique est activé. Il est possible de spécifier si seuls les enfants directs ou si tous les descendants sont aussi concernés.
Certains profils sont déjà présents lors de l'installation du référentiel. Ces profils ne peuvent être ni supprimés ni modifiés.
Id profil | Description |
|---|---|
| Ce profil est uniquement activé pour l'espace de données de référence. |
| Ce profil est activé pour tous les espaces de données. |
| Ce profil historise les en-têtes des jeux de données. Cependant, ce profil ne sera paramétrable que dans une future version, étant donné que le modèle de données interne ne définit que les noeuds des jeux de données. |
Configuration de l'historique dans le modèle de données
Activation de l'historique de table
L'historique peut être activé pour une table via l'assistant de modèle de données, ou en éditant le modèle de données sous-jacent.
Pour activer l'historique en éditant le modèle de données, un profil d'historique doit être déclaré pour la table en utilisant l'élément historyProfile.
<osd:table> <primaryKeys>/key</primaryKeys> <historyProfile>historyProfileForProducts</historyProfile></osd:table> |
L'assistant de modèle de données permet de visualiser le profil d'historisation défini dans le référentiel.
L'historisation peut être activée séparément pour chaque table. Voir la documentation de conception du modèle pour plus d'informations.
Désactivation de l'historique d'un champ ou d'un groupe spécifique
Pour une table historisée, la règle par défaut est l'historisation de tous les éléments qu'elle prend en charge, (voir Impacts et limitations du mode historisé).
Il est possible de désactiver l'historique d'un champ ou d'un groupe spécifique, que ce soit via l'assistant du modèle de données ou via la modification du modèle de données sous-jacent.
Pour désactiver l'historique d'un champ ou d'un groupe en éditant le modèle de données, utiliser l'élément osd:history avec l'attribut disable="true".
<xs:element name="longDescription" type="xs:string"> <xs:annotation> <xs:appinfo> <osd:history disable="true" /> </xs:appinfo> </xs:annotation></xs:element> |
Pour désactiver l'historique d'un champ ou d'un groupe via l'assistant du modèle de données, utiliser la propriété History dans les Advanced properties de l'élément.
Quand cette propriété est définie pour un groupe, l'historique est désactivé récursivement pour tous ses descendants. Lorsque l'on désactive l'historique d'un groupe, il est impossible de réactiver spécifiquement l'historique pour un descendant.
Note
Si la table contenant le champ ou le groupe n'est pas historisée, cette propriété n'aura aucun effet.
Il n'est pas possible de désactiver l'historique pour les champs de clé primaire.
Intégrité
Si des problèmes sont détectés lors de la compilation du modèle de données, des messages d'alerte ou d'erreur seront ajoutés au rapport de validation associé à ce modèle de données. En outre, si la moindre erreur est détectée, chaque instance (jeu de données) associée sera inaccessible. Les cas d'erreur les plus répandus sont les suivants :
Une table fait référence à un profil qui n'est pas défini dans le référentiel.
Un profil d'historique qui est référencé dans le modèle de données mentionne un espace de données non défini ou fermé du référentiel courant.
Note
Le déploiement d'un modèle de données dans un référentiel qui ne dispose pas des profils requis nécessitera l'intervention de l'administrateur pour les ajouter.
Affichage d'historique et permissions
Vue historique de table
Lorsque l'historique a été activé pour une table dans un modèle de données, il est possible d'accéder à la vue de l'historique à partir de l'interface utilisateur depuis : un enregistrement, une sélection d'enregistrements, une table et un jeu de données.
La section suivante explique comment les permissions sont déterminées.
Pour plus d'informations, voir la section vue historique de table Pour accéder à la vue historique de table à partir de Java, la méthode AdaptationTable.getHistory doit être invoquée.
Permissions pour historique de table
Les permissions relatives aux données sont aussi appliquées à l'historique des données. Les permissions de l'historique sont définies automatiquement, la permission la plus restrictive parmi les permissions des données et les droit d'accès en lecture seule sera appliquée.
C'est le cas des permissions définies par l'utilisateur et des règles de permission programmatiques.
Lors de la définition d'une règle programmatique, il peut être nécessaire de faire la distinction entre le contexte du jeu de données fonctionnel et le contexte de vue historique. Soit parce que les permissions attendues sont différentes, soit parce que certains champs ne sont pas présents dans la structure de l'historique. C'est le cas en ce qui concerne les champs de jeux de données, les valeurs calculées, ainsi que les champs dont l'historique a été désactivé. Les méthodes Adaptation.isHistory et AdaptationTable.getHistory peuvent alors être utilisées dans la règle programmatique afin d'implémenter un comportement spécifique pour l'historique.
Vue historique des transactions
La vue historique des transactions permet d'accéder aux transactions exécutées, indépendamment d'une table, du jeu de données ou du modèle de données, directement à partir de l'interface utilisateur.
Pour afficher la table 'Historique des transactions', aller dans 'Administration' et sélectionner 'Historique et journaux' à l'aide du menu déroulant symbolisé par une flèche dans le panneau de navigation. On peut aussi accéder à l'historique des transactions à partir des 'Espaces de données' en sélectionnant un espace de données historisé et en utilisant le menu 'Actions' dans l'espace de travail.
Pour plus d'informations, voir vue historique des transactions.
Accès SQL à l'historique
Cette section décrit le moyen d'accéder directement à l'historique grâce à SQL.
Voir aussi
Restrictions d'accès
L'accès aux tables de la base de données n'est autorisé qu'en mode lecture seule. C'est à l'administrateur de la base de données d'en interdire l'accès en écriture, sauf pour l'utilisateur de base de données de TIBCO EBX®, tel qu'indiqué dans la section Rules for the database access and user privileges.
Présentation du schéma relationnel
Voici une description des tables d'historique dans la base de données.
Le schéma de la base de données contient (voir aussi le diagramme dans la section suivante) :
Des tables communes et génériques | La table principale est Ces tables communes ont toutes le préfixe "HV". |
Tables spécifiques générées | Pour chaque table historisée, une table d'historique spécifique est générée. Cette table contient l'historique des modifications de données sur la table. Dans l'interface utilisateur d'EBX®, le nom de cette table en base de données peut être connu en cliquant sur le panneau de documentation de la table (mode avancé). Toutes les tables d'historique spécifiques ont le préfixe "HG". |
Exemple de table d'historique générée
Dans l'exemple suivant, une table nommée product est historisée. Supposons que cette table déclare trois champs dans le modèle de données EBX® :
Produit
productId : int
price : int
beginDate : Date
Le diagramme ci-dessous montre le schéma relationnel qui en résulte :
L'activation de l'historique sur cette table génère la table HG_product affichée dans la structure du schéma de l'historique ci-dessus. Voici la description de ses différents champs :
tx_id: ID de la transaction.instance: ID de l'instance.op: type d'opération - C (créer), U (mettre à jour) ou D (effacer).productId:productIdvaleur de champ.OproductId: champ d'opération pourproductId, voir section suivante.price:pricevaleur de champ.Oprice: champ d'opération pourprice, voir section suivante.beginDate:datevaleur de champ.ObeginDate: champ d'opération pourbeginDate, voir section suivante.
Combinaison doperations
Si plusieurs opérations ont lieu au cours de la même transaction, le champ d'opération est résolu selon la règle suivante :
C + U -> CD + U -> DD + C -> UC + D -> {} (pas d'enregistrement dans l'historique)
Valeurs de champs d'opération
Pour chaque champ fonctionnel, un champ d'opération supplémentaire est défini. Il est composé du nom du champ dont le préfixe est O. Ce champ précise si le champ fonctionnel a été modifié et prend une des valeurs suivantes :
null: si la valeur du champ fonctionnel n'a pas été modifiée (et que sa valeur n'est pas INHERIT).M: si la valeur du champ fonctionnel a été modifiée (mais ne prend pas la valeur INHERIT).D: si l'enregistrement a été effacé.
Si inheritance est activé, le champ d'opération peut avoir trois valeurs supplémentaires :
T: si la valeur du champ fonctionnel n'a pas été modifiée et que sa valeur est INHERIT.I: si la valeur du champ fonctionnel a pris la valeur INHERIT.O: si l'enregistrement a été mis en mode OCCULTING.
Impacts et limitations du mode historisé
La fonctionnalité d'historique a certains impacts et des limitations connues, qui sont décrits dans cette section. Lors de l'utilisation du mode historisé, il est fortement conseillé de lire attentivement ces limitations et de contacter le support de Cloud Software Group, Inc. pour toute question.
Validation
Certaines contraintes du modèle de données d'EBX® deviennent bloquantes quand l'historique de la table est activé. Pour plus d'informations, voir la section Contraintes structurelles.
Restrictions du modèle de données pour les tables historisées
Certaines restrictions s'appliquent aux modèles de données qui contiennent des tables historisées :
Certaines limitations existent pour deux types de listes agrégées : les listes agrégées sous une autre liste agrégée, et les listes agrégées sous un groupe terminal. Les modèles de données contenant ce type de listes agrégées peuvent être utilisés, cependant ces listes seront ignorées (non historisées).
Les valeurs calculées sont ignorées.
La présence d'attributs définis par l'utilisateur sur des tables historisées provoque des erreurs lors de la compilation du modèle de données.
Les évolutions du modèle de données peuvent aussi être restreintes par le SGBDR sous-jacent, en fonction des données déjà présentes dans les tables concernées.
Voir aussi
Autres limitations du mode historisé
Aucune donnée n'est copiée lorsque l'historique est activé sur une table contenant des données existantes.
Les opérations d'ensemble sur les jeux de données ne sont pas historisées (créer et supprimer une instance), même si elles déclarent une table historisée.
Les libellés par défaut référençant un champ non historisé ne sont pas pris en charge pour les tables historisées.
Par conséquent, les libellés par défaut référençant un champ calculé ne sont pas pris en charge pour les tables historisées.
Pour contourner ce problème, il suffit d'implémenter l'interface
UILabelRendereret d'adapter le calcul du libellé pour l'historique.D3 : l'historique peut être activé dans l'espace de données de destination d'un noeud maître. Mais, dans l'espace de données de destination des noeuds esclaves, la fonction historisation est toujours désactivée.
Utilisateur enregistré dans l'historique : pour certaines opérations spécifiques, l'utilisateur réalisant la dernière opération et celui qui est enregistré dans l'historique correspondant peuvent être différents.
Ceci est dû au fait que ces opérations sont un rapport du statut des données à un état antérieur :
Import d'archives : lors de l'import d'archive dans un espace de données, l'heure et le nom de l'utilisateur de la dernière opération réalisée dans l'espace de données sont conservés, alors que le nom de l'utilisateur enregistré dans l'historique est celui qui réalise l'import.
Fusion programmatique : lors de la fusion programmatique d'un espace de données, l'heure et le nom de l'utilisateur de la dernière opération réalisée dans l'espace de données enfant sont conservés, alors que le nom de l'utilisateur enregistré dans l'historique est celui qui réalise la fusion.
D3 : en ce qui concerne la fonctionnalité de "distributed data delivery", lorsqu'une diffusion est réalisée, les données du noeud maître sont reportées dans le noeud esclave. L'heure, ainsi que le nom de l'utilisateur qui a réalisé la dernière opération dans l'espace de données enfant, sont conservés. Le nom de l'utilisateur enregistré dans l'historique est "ebx-systemUser" ; c'est lui qui procède à la déclaration sur le noeud esclave lors de la diffusion.