Lors d’une synchronisation via DataLink, si un champ est vidé à la source (saisie précédente supprimée dans le champ), la valeur null n’est pas prise en compte dans l’environnement cible qui conserve la précédente valeur non null.
Bonjour Bruno,
Il me semble que le cas avait déjà été corrigé/géré suite à un de tes 1er retour sur la fonctionnalité.
Il y a peut être une subtilité qui nous échappe entre null et chaine vide, ou lié à la différence de versions. On va vérifier.
Bonjour François,
merci beaucoup pour ton retour rapide.
En effet, j’ai aussi bien pris soin de forcer le caractère “updatable” pour tous les champs dans contexte. Et de fait, si la valeur change vers une valeur non nulle, elle est bien synchronisée. C’est un cas d’usage un peu particulier car généralement, il est rare d’enlever ce qui y a été inscrit dans un champ (les valeurs changent mais ne sont pas souvent mises à blanc).
Après relecture, les règles métier s’appliquent comme pour une mise à jour API ou UI.
Il n’y a donc pas de raison de ne pas pouvoir faire de RAZ du champ.
ValidateException dans les logs au moment du validate : syncData: validation error ... on object ...Dans l’idéal ou pour simplifier, ce mode de synchro devrait s’affranchir des règles métier, mais le protocole via HTTP/API/REST/JSON ne le permet pas, il faudrait créée un mode d’échange type RAW. Mais on s’était dit que repasser par la couche logique/hooks pouvait avoir un intérêt. Le mode RAW serait le tuple en base / réimporté en pur en SQL (juste les colonnes qui matchent).
Les champs concernés sont aussi bien des simples champs texte court non obligatoires et modifiables (ils le sont tous par forçage dans le code mais celui sur lequel j’ai testé est nativement modifiable) ou des champs de fk qui pointent sur des rowId qui existent préalablement à la synchro par DataLink.
Je ne comprends pas du coup d’où vient le problème…
Dans certains cas où je ne me suis pas posé la question j’imagine qu’il est toujours préférable de respecter les couches logiques du modèle et donc de passer par les hooks métier. Cependant, j’ai dû dans certains cas spécifiquement débrayer certaines logiques (avec un if (!isDataLinkInstance())…) dans des hooks) car les composantes métier impliquées dans la règle ne sont pas disponibles et/ou que le résultat n’est pas utile sur la cible (îlot fonctionnel non concerné par la règle implémentée dans l’objet synchronisé par DataLink).
J’ai pensé à ajouter une couche intermédiaire de définition des objets concernés qui permettrait d’isoler les logiques “internal model” à inclure dans tous les cas pour garantir l’intégrité des objets et une couche au dessus qui implémenté les règles “external model” d’intégration avec le voisinage (qui peut par construction être différent entre le master et le slave). Mais pour aller vite j’ai simplement mis en place un cloisonnement logique à base de if().
Ok c’est bien ce que j’avais en tête sur ta conception.
On va refaire des tests pour y voir plus clair,
le fait que ce soit entre une 5.3 et un 6.2 a peut-être un impact.
Problème reproduit, ce n’était pas le “push” master=>slave mais le “pull” slave=>master de resynchro batch du datalink qui ignore les valeurs null.
Pb de parsing via json.org suite au search GET, la valeur reçue vaut étrangement JSONObject.NULL et non pas null, et du coup n’est pas mappée.
Visiblement ça touche tous les flux REST/POST, pas que les datalinks qui utilise cette méthode commune Parameters.parseJSONBody.
Peut être que les autres flux envoient bien "" et pas null.
On va vérifier et corriger.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.