Besoin de création de redolog lors d'appel API

Bonjour

j’ai un objet sur lequel j’ai paramétré le journal des modifications ainsi que l’historisation.
Lorsque je modifie mon objet dans le portail, j’obtiens bien une trace dans les deux éléments.
En revanche, lorsque je passe par une page publique :

$.ajax({
	type: 'PUT',
	url: "/bcsi/functions-architecture/v1/eapmSurvey/" + eapmId,
	contentType: 'application/json',
	data: JSON.stringify({
		"applicationPlannedDisposition" : $("#EAPMApplicationPlannedDisposition").val(),
		"plannedEvolutionDate" : $("#EAPMPlannedEvolutionDate").val(),
		"evolutionType" : $("#EAPMEvolutionType").val(),
	}),
	beforeSend: function (xhr) {
		xhr.setRequestHeader('Authorization', 'Bearer ' + userOidc.access_token);
	} 
})

J’obtiens bien une trace dans l’historisation mais rien de le journal de logs.

image
image

Pouvez-vous me dire la raison de cette différence ?
Cordialement
Amandine T.

On parle de quelle API ? REST au travers d’un mapping ?

Les redologs sont issues du undo/redo d’une session UI.

  • Donc en premier lieu, il faut avoir une session qui s’enregistre dans la table des sessions, pour savoir qui va faire les modifications (un redolog a un lien vers la session, donc non public)
  • Et ensuite que les appels ajax passent par la mécanique d’undo/redo dans la session

A mon avis, ces services n’existent pas et il va falloir faire une petite évolution pour tracer les redolog de cette manière.

En effet, il s’agit d’api rest via le mapping que vous avez fait pour Renault.
Puisque dans les historisations, il y a bien mon user en tant que créateur, cela ne veut-il par dire qu’il y a une session créée ?

Dans ce cas vous avez bien un user qui s’identifie et non pas une page “publique” comme vous l’indiquiez au début.

Vous pouvez voir les sessions dans le menu exploitation :

Et dans chaque session les redologs associés.

Nous allons ajouter la mécanique des undo/redolog côté API avec les 2 méthodes undo/redo (via un GET + paramètre). Il faut nécessairement que tous les appels Ajax se fassent dans la même session web.

Il faudra sûrement le spécifier dans l’appel de service pour ne pas impacter l’existant qui n’a pas cette fonction. Pour les API qui utilisent des pools d’objet uniques ce ne sera pas possible à priori de tracer des redolog, mais ils servent surtout à de la consultation en masse.

Je pense que @Amandine ne parle de la “redo log” uniquement comme piste d’audit des modifications, pas comme le mécanisme de redo/undo au sens de la fonctionnalité qui existe dans la UI.

Le fait de tracer un record dans la “redo log” sur create (POST), update (PUT) ou suppression (DELETE) doit donc se faire de manière transparente pour celui qui appelle l’API.

Pour mémoire, les APIs (y compris les APIs custom mappées) travaillent dans une session “technique” transparente au sein de laquelle des instances objets sont bien associés au user authentifié (par son token API). La mécanique de gestion de session est donc différente de ce qui se passé coté UI mais on sait bien dire quel user a appelé quoi via le getGrant() de l’objet invoqué.

Exactement @david . Mon besoin ici est juste d’avoir le journal à jour. Je ne cherche pas à faire des undo/redo.

Oui j’ai bien compris, la piste d’audit dont vous parlez n’existe pas, on parle de redolog (traduit change log ou journal sur la UI) issues des actions utilisateurs via ses droits, ce n’est pas un log à part.

Lorsqu’un objet/grant travaille, il mémorise ses actions dans un pool de redo/undo (des ObjectXML comme pour un import/export), le fait de serialiser le redolog en base ou dans log4j à chaque retour OK de service n’est qu’une option/conséquence de cette fonctionnalité qui trace N commits (service + tous les update en cascade via les hooks…) dans une seul “redo” en miroir avec son 'undo".

Bref, avec une petite évolution ça peut devenir transparent si le Grant associé à l’objet API a bien le paramètre system LOG_ACTIVITY (comme pour une session UI), et donc je soulignai juste qu’on pourrai aussi rendre les verbes undo/redo accessibles, don’t act.

Je vais pousser ça en 5.2 et on verra pour le backporter si c’est concluant.

Les premiers tests en 5.2 sont concluants :

  • si l’objet a bien l’option d’historisation en redolog
  • et que les paramètres systèmes LOG_ACTIVITY et LOG_SESSION sont actifs pour le user de l’API

La session par token est bien tracée en base avec toutes ses mises à jour par API.

Il faudra surement limiter la profondeur du undo/redo en mémoire dans ce type d’accès si les verbes ne sont pas exposés dans l’API, car rien ne sert de garder les N derniers appels (N=user max/page) de mises à jour en mémoire (y compris les appels d’action spécifique). A débattre mais ça peut être pratique d’exposer ces services pour peu de frais pour revenir en arrière en cas d’erreur depuis le client, en appelant juste un GET/undo.

Voilà l’évolution est barkportée en V4, cela permettra dans un premier temps de tracer les mises à jours au redolog des actions via API REST. Merci de me donner votre feedback au prochain build.

La profondeur du undo/redo est à 1 pour ne pas consommer de mémoire, tant que la méthode undo ne sera pas accessible par API.

Rappel :

Le Redolog n’est que le journal des actions au travers une session utilisateur (UI et maintenant REST).
Il reste donc encore à vous interroger sur les cas non gérés par ce mécanisme si vous en avez :

  1. Des actions planifiées via Cron qui mettent à jour ces objets
  2. Des actions asynchrones, car même lancées depuis une session, elles deviennent comme des taches planifiées
  3. Des mises à jour directe en base via getGrant().update() ou externe

Pour 1 et 2, on pourra surement faire une autre évolution pour créer une “fausse” session technique et lui raccrocher des redolog. On aura l’info d’une mise à jour par le système.

Pour le 3, on ne pourra rien faire de mieux = le SQL direct est donc à utiliser pour les cas de mises à jour techniques, sans redolog nécessaire/exploitable.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.