Continuing the discussion from Besoin de création de redolog lors d'appel API:
Version=5.2.14 BuiltOn=2022-09-09 19:11
La journalisation (redolog) n’est pas prise en compte dans le contexte des appels API alors que LOG_ACTIVITY et LOG_SESSSION sont bien définis dans le grant du user appelant.
Bonjour,
A ma connaissance ce sont 2 paramètres systèmes globaux, on ne peut pas les activer par User.
Le redolog persistant s’appliquera si LOG_ACTIVITY est actif globalement + configuré sur l’objet mis à jour.
On va refaire des tests, mais le redolog est bien appelé dans les services PUT/POST depuis la V4.
Ca fonctionne :
Résultat :
Et les accesseurs vers LOG_ACTIVITY sont bien vers le singleton system. Les journaux n’ont pas à s’activer ou non suivant un profil particulier, sinon ça voudrait dire que certaines personnes pourraient passer sous les radars ? Ce serait une évolution à prévoir.
Merci beaucoup François pour ton retour rapide.
Notre cas d’usage est dans un contexte de PUT/POST via les API mappées (RESTMappedObjectsExternalObject)
Ah ok merci pour la précision, cette couche est sensée passer par les mêmes couches basses, mais comme elle réinvente un peu la roue, on va vérifier quand même.
Effectivement, il y manquait l’appel au redolog car cette couche via ExternalObject n’hérite pas du service REST qui l’implémentait bien.
Explications :
Pour que le Journal du “redolog” soit bien archivé (avec toutes les mises à jour en cascade qui pourraient exister dans les hooks de l’objet), il faut que la méthode appelante arme un stack d’undo/redo = 2 FlowXML qui vont enregistrer les modifs du thread à partir de ce point. Un peu comme un begin transaction et commit/rollback :
Exemple :
try {
// Prepare undo/redo to trace all further changes
UndoRedoPool.prepareUndoRedo(obj);
// ...
obj.getTool().validateAndUpdate();
// ...
// SUCCESS = Confirm undo in pool
if (obj.hasChanged(false))
UndoRedoPool.confirmUndoRedo(obj); // => stored in logs and/or DB
else // not changed
UndoRedoPool.ignoreUndoRedo(obj); // => discard from memory
}
catch (ValidateException | UpdateException e) {
// ERROR : Discard stack
UndoRedoPool.ignoreUndoRedo(obj);
return "functional error";
}
catch (Throwable e) { // Catch any other throwable
// Discard stack
UndoRedoPool.ignoreUndoRedo(obj);
return "technical error";
}
Ensuite dans les hooks enfants (postSave… sont exécutés dans un même thread), il n’est pas nécessaire de faire ce sandwich, les mises à jour vont s’empiler dans la stack déjà armée. Ca ne fonctionne pas si on lance des actions asynchrones (qui iront dans un autre thread).
Ce sera livré au prochain build 5.2.17.
Super merci beaucoup!
[Message prédéfini]
Nous conseillons aux utilisateurs de marquer comme “solution” la réponse résolvant leur problématique pour permettre au support de mieux suivre les sujets non résolus, et à la communauté de trouver plus facilement la bonne réponse.
Vos messages indiquant une résolution du problème, nous avons réalisé cette opération pour vous.