J’ai un business object auquel j’ai ajouté une history table via Simplicité
Dans mon business object, il y a des attributs qui sont des foreign key vers d’autres business object
Dans un formulaire, lorsque je change n’importe quel attribut, j’obtiens une ligne dans mon historique, cependant quand je change la valeur de ma foreign key, l’historique n’obtient pas de nouvelle ligne
En voyant, je remarque que dans l’historique, il n’y a la liaison vers la foreign key
Ma question est donc, comment est-ce que je pourrais rajouter ma foreign key dans mon historique pour qu’une nouvelle ligne se créé a chaque fois que je change la foreign key
Et plus en encore, est-il possible de mémoriser la foreign key et en plus un des champs de l’objet lié ?
Si la FK est bien au niveau de l’objet historique tout changement de FK est sensé être historisé. Je vais quand même vérifier si c’est bien le cas
Pour ce qui est d’historiser la valeur d’attributs ramenés via cette FK avec leur valeur courante au moment de l’historisation, c’est un autre sujet, une approche c’est de créer ces attributs (physiques, pas ramenés) au niveau de l’objet historique et d’implémenter leur valorisation dans le preValidate (ou via une valeur par défaut) sur votre objet historique
Merci pour la réponse,
J’ai bien ma FK présent dans les attributs de mon business objet, cependant je ne l’ai pas dans mon history table, serait-il possible que ca soit dû au fait que j’ai peut-etre coché l’history table et généré la table historique avant d’avoir créé ma FK ?
Dans la meme lignée, est-il possible de regénéré l’historique meme s’il a déjà été généré ?
Très bien, du coup quelle est configuration qu’il faut mettre pour lier un champ historique à un champ du business object (pour que a chaque fois que le champs du business object est modifié, la modification ajoute une ligne dans l’historique) ?
Le fait qu’il y ait un attribut dans l’objet historique et le même attribut dans l’objet déclenche une historisation si cet attribut est modifié sur l’objet. Il faut donc mettre sur l’objet historique un sous ensemble des attributs de l’objet (et, si besoin, des attributs spécifiques à l’objet historique comme dans le cas de ma 1ère réponse).
Vous pouvez aussi surcharger cette logique de déclenchement de l’historisation en implémentant le hook isHistoric.
En général il n’est pas pertinent d’avoir tous les attributs de l’objet dupliqués dans l’objet historique, la plupart du temps seuls quelques attributs importants doivent être historisés (ex: le statut dans un objet à état, et/ou les éléments de la clé fonctionnelle, etc., cf. l’objet historique de la commande dans la démo).
PS: A noter qu’en termes d’historisation vous avez aussi le mécanisme du “journal des modifications” qui centralise les modifications sur tous les objets concernés objets:
L’objet Historique se génère une seule fois, ensuite vous devez lui ajouter les nouveaux attributs éventuels, les champs liés, etc.
Donc en général :
on attend d’avoir terminé le paramétrage de l’objet pour générer son historique.
ou alors il faut supprimer l’objet historique, et repasser l’objet en “historique” pour forcer une nouvelle génération avec tous les champs
puis on maintient manuellement l’objet historique en lui ajoutant/retirant des champs comme n’importe quel objet métier : tous ceux qui matchent avec l’objet père seront copiés à chaque modification d’un champ historisé (et si le hook isHistoric retourne true pour traiter les cas particuliers et eliminier des historiques superflus en fonction des données)
il est inutile de mettre un champ en lecture seule / non modifiable dans l’historique, ça copierait pour rien toujours la même valeur
