Nous souhaitons pouvoir afficher les modifications (via le journal de l’objet) sur un objets créé dans un postSave.
Le cas d’usage est le suivant :
Nous recherchons une donnée
La donnée n’est pas présente. Nous déclenchons alors un appel API
L’API nous renvoie un résultat.
Dans le postSearch, nous construisons un objetTmp et le valorisons des données renvoyées de l’API
Nous persistons l’objet
Sur ce cas d’usage, le journal des modifications n’est pas alimenté. Doit on utiliser une instance spécifique ? Y-a t’il un paramétrage complémentaire à réaliser ?
Un « search » ne lancera pas la journalisation interne. Il faut passer par une mise à jour (create/update/delete) qui va journaliser (tout) le redolog. Essayez de faire la création avec l’instance main (getMainObject) mais pas sûr que ça fonctionne.
Sinon, il faudra passer ce besoin en feature request pour journaliser les mises à jour éventuelles d’un search. A mon avis pas faisable dans un cas général (armer un redolog pour chaque search puis persister si non vide à la fin) car impactera les performances globales de toutes les recherches pour des cas très rares à gérer.
Il faudra plutôt ajouter un verbe ou paramètre au BusinessObjectTools pour créer/modifier/supprimer un objet avec son redolog/historique ou pas. L’appelant aura le choix pour dire si la mise à jour par code a un « sens métier » ou pas.
Voici les verbes à appeler pour forcer la journalisation des mises à jour en base :
UndoRedoPool.prepareUndoRedo(obj) = arme un espace pour tracer les mises à jour de ce thread à partir de maintenant (i.e. création d’un FlowXML des créations/mises à jour/suppressions à venir en mémoire sur tous les objets/hooks manipulés dans ce thread, donc attention cela exclura les mises à jour via action asynchrone car dans un thread à part, il faut des mises à jours synchrones)
UndoRedoPool.confirmUndoRedo(obj) = valide le Undo/Redo dans la session utilisateur (dans le Grant qui a instancié l’objet) et enregistre le redolog en base (si l’objet principal est journalisable)
UndoRedoPool.ignoreUndoRedo(obj) = en cas d’erreur, ignore le undo/redo (vide la mémoire), pas de journalisation
Le pattern est en général le suivant :
ObjectDB obj = getGrant().getTmpObject("MyObject");
synchronized (obj) {
// Prepare undo/redo to trace all further changes
UndoRedoPool.prepareUndoRedo(obj);
// TODO updates
String msg = obj.save();
// Confirm undo in pool + save the Redolog
if (!Message.isError(msg) && obj.hasChanged(false))
UndoRedoPool.confirmUndoRedo(obj);
else // Discard the Redolog
UndoRedoPool.ignoreUndoRedo(obj);
}
On va ajouter ce pattern dans le helper BusinessObjectTool.validateAndSave et consorts en V5.