Expressions calculées dans un impact de contrainte

[Hamza]

Bonjour,

Je rencontre deux problèmes liés à l’écriture d’expressions calculées dans un impact.

Dans la documentation, une expression calculée peut se terminer par un point-virgule (;).

Cependant, lorsque je termine mon expression par un point-virgule, elle n’est pas compilée et provoque des erreurs dans l’interface. Après l’avoir retirer plus de soucis,( peut etre lié à une évolution, je n’avais pas ce soucis il y a quelques mois mais détecté cette anomalie il y a quelques semaines).

Le second problème que je rencontre est lié à l’utilisation d’un paramètre système [SYSPARAM:LBC_PRODUCT_DESC_FR], celui-ci contient un JSON.

Je tente de récupérer une valeur spécifique du JSON en fonction d’un autre attribut de mon objet (ici LegalTextProduct). Voici mon expression calculée, le code suivant compile, marche super bien,

(function() {
	var product = [VALUE:LegalTextProduct];
	var param = JSON.parse([SYSPARAM:LBC_PRODUCT_DESC_FR])
	return param[product];
})()

mais me dégrade l’UI ( des attributs dans la liste qui affiche le code est non le displayvalue des affichage qui saute etc…):

Quand je mets directement le JSON en dur dans l’expression, tout fonctionne correctement et je n’ai aucun problème dans l’UI. Exemple fonctionnel :

(function() {
    var product = [VALUE:LegalTextProduct];
    var param = {
        "RPASSR4": "RPASS R4 DESCRIPT",
        "RPASSR5RG": "RPASS R5 Roland TEST",
        "MyDaciaWeb": "MyDacia Web",
        "IDConnectRG": "Description ID Connect Renault Group",
        "MyRenaultWeb": "MyRenault Web",
        "RPASS": "RPASS"
    };
    return param[product];
})()

J’ai inspecté les contraintes via le navigateur et j’ai constaté que lorsque j’utilise le paramètre système ([SYSPARAM:LBC_PRODUCT_DESC_FR]), il y a un comportement inattendu dans l’UI (notamment des erreurs dans la liste des objets).
Lorsque je remplace ce paramètre système par un JSON directement intégré dans l’expression, tout est bien interprété et fonctionne comme prévu.

Voici les Ressources contraintes dans le cas du paramètre system :

et en JSON dur:

En synthèse , peut-on utiliser [SYSPARAM:<name>]ou Y a-t-il une manière recommandée pour manipuler un JSON provenant d’un paramètre système dans une expression calculée ?

Merci pour votre aide et vos suggestions !

Technical information

Instance /health

---paste the content of your-instance.com/health---

Simplicité logs

---paste the content of the **relevant** server-side logs---

Browser logs

---paste content of the **relevant** browser-side logs---

Other relevant information

----E.g. type of deployment, browser vendor and version, etc.----

[Candice (Candice BIMONT)]

Bonjour,

[SYSPARAM:<name>] effectue un appel Ajax asynchrone et ne peut être utilisé que dans des contraintes back-end.
Nous allons faire en sorte que l’utilisation d’expressions asynchrones (comme SYSPARAM) génère une erreur en cas d’utilisation dans une contrainte UI.

Afin que je puisse vous proposer une méthode plus adaptée à votre besoin, pourriez-vous me fournir plus de détails sur votre usage ?
La valeur de LBC_PRODUCT_DESC_FR est-elle susceptible d’être modifiée par le code ou est-elle statique (toute modification est suivie d’un clear cache) ?

[Hamza]

Bonjour Candice,merci pour ton retour concernant l’utilisation de [SYSPARAM:<name>].

Notre usage est le suivant, la valeur du paramètre système LBC_PRODUCT_DESC_FR est mise à jour dynamiquement via un hook postSave dans un objet nommé Tags. Voici le processus :

1. Dans le hook postSave de l’objet Tags, nous mettons à jour le paramètre système LBC_PRODUCT_DESC_FR en fonction du nom et de la description des produits.
2. Ce paramètre système est ensuite utilisé dans la contrainte UI (calcul de la valeur d’un champ) pour afficher directement la description du produit, basée sur l’attribut LegalTextProduct de l’objet LegalText.

Cette logique a permis d’avoir une description dynamique du produit dans le 1ere objet qui s’adapte automatiquement aux changements effectués sur l’objet Tags, et dans l’idée,sans nécessiter de modifications manuelles ou de clear cache.

[Candice (Candice BIMONT)]

Bonjour,

Merci pour votre retour.

D’après ce que je comprends, le paramètre système est actuellement utilisé pour un traitement contextuel.

• Pourquoi utiliser un paramètre système (persistant) pour ce traitement ?
• L’objet concerné est-il lié aux tags?

Une alternative pourrait être d’utiliser un attribut masqué directement sur l’objet concerné ou son parent. Cet attribut pourrait être valorisé automatiquement via les hooks initList ou initUpdate de l’objet, en fonction du contexte ou en y injectant la valeur du paramètre système.

Cette approche présenterait l’avantage de simplifier le traitement et d’améliorer les performances en évitant des appels fréquents au back-end pour récupérer la valeur du paramètre système.

Faire un appel au back-end pour obtenir la valeur d’un paramètre système à chaque application de contrainte peut être particulièrement coûteux, surtout dans des contextes front appelé, entre autres, par des événements change.

Cordialement,

[Hamza]

Bonjour Candice,

Merci pour vos suggestions. Nous allons explorer la piste de l’attribut masqué, mais le paramètre système persistant reste important dans notre cas je pense afin de mettre à jour dynamiquement le JSON via le postSave de l’objet Tags. Cela évite des recalculs à chaque initialisation.(Seulement si on ajoute des description sans ClearCache mais l’ajout des descriptions et produits dans tag est à la main des ADMINS). La relation entre les 2 objets est une N:N.

Nous avons trouvé une solution fonctionnelle sans [SYSPARAM], compatible avec l’UI et respectant le besoin de mise à jour dynamique de la description produit. Voici le code utilisé :

(function() {
    var product = [VALUE:LegalTextProduct];
    var lang = this.$ui.getGrant().getLang();
    var paramKey = (lang === "FRA") ? "LBC_PRODUCT_DESC_FR" : "LBC_PRODUCT_DESC_EN";
    var productJson = this.$ui.getAjax().sysparams[paramKey];

    try {
        var param = JSON.parse(productJson);
        return param[product] || "Produit non trouvé pour " + product;
    } catch (error) {
        return "Erreur d'analyse JSON : " + error.message;
    }
})()

En espérant que cette approche soit pérenne, ( toujours sans le ; à la fin de la fonction).

Merci encore pour votre aide
Cordialement,

[Candice (Candice BIMONT)]

Bonjour Hamza,
this.$ui.getAjax().sysparams[paramKey] va chercher la donnée chargée dans la session de l’utilisateur à l’ouverture de la session.
Sans F5 ou reconnexion, la donnée risque de ne pas être à jour pour l’utilisateur.

Si j’ai bien compris votre besoin, sans ClearCache et ‘instantané’, cette solution risque donc de provoquer un délai de propagations des descriptions en session utilisateur.
De plus,

@Francois

il serait plus optimum de factoriser le JSON.parse pour éviter de le faire à chaque fois. Donc, à l’ouverture de la UI, dans le ui.ready, remplacer la valeur textuelle par le JSON.
$app.sysparams[paramKey] = JSON.parse($app.sysparams[paramKey]);

Pour réduire le délai de mise à jour, vous pouvez envisager un mécanisme de recharge du paramètre dans la session des utilisateurs, dans la ressource SCRIPT de la disposition :

@Francois

$(document).on("ui.ready", _ => {
  setInterval(_=> {
     let param = $grant.getLang()=="FRA" ? "LBC_PRODUCT_DESC_FR" : "LBC_PRODUCT_DESC_EN";
     $app.getSysParam(param).then(v => {
        console.log("reload " + param + " = " + v);
        $app.sysparams[param] = JSON.parse(v);
     });
  }, 300000) // 5 min
});

Ici, $app.getSysParam(param) équivaut à l’expression [SYSPARAM] dans une contrainte. Cela va provoquer un appel back-end, un mécanisme de recharge trop fréquent pourrait provoquer des problèmes de performance.
cordialement,
Candice