Récupération d'un champs d'objet simplicité importé pour set un identifiant dans un champs

Récupération d’un champs d’objet simplicité importé pour set un identifiant dans un champs

Bonjour,
je vous écris concernant une régression que j’ai pu constater ces derniers jours. Cela concerne la récupération de champs sous forme de métadonnées d’un objet simplicité.

Le besoin

  1. Intégration d’un objet simplicité Site d’une application nommée RFS dans un nouvel objet Site Assignment dans une application nommée RFF
  2. Récupération du champs Identifier
  3. Prendre cette valeur et setFieldValue dans le champs supReaIdentifier de l’objet Site Assignment d’RFF

Voici l’ensemble du code qui était auparavant fonctionnel:

JSONObject linkedPwoRelay = new JSONObject(JSONTool.jsonMetaObject(getGrant(), getFieldValue("supSiaSite"), null));
		
		AppLog.info(getClass(), "SSAA", linkedPwoRelay.toString(), getGrant());

		String site = (String)linkedPwoRelay.get("userkeylabel").toString();
		String[] fullSite = site.split(" ");
		
		String identifiant1 = fullSite[0];
		String identifiant2 = fullSite[1];
		
		Boolean test1 = identifiant1.contains("SIT");
		Boolean test2 = identifiant2.contains("SIT");
		
		if(test1 == true && test2 == true) {
			this.setFieldValue("supReaIdentifier", identifiant2);
			AppLog.info(getClass(), "SSAA", "Y'A 2 SITES", getGrant());
		}
		else {
			this.setFieldValue("supReaIdentifier", identifiant1);
			AppLog.info(getClass(), "SSAA", "Y'A QU'UN SITE", getGrant());
		}
        
        AppLog.info(getClass(), "SSAA", site, getGrant());*/
        
        this.setFieldValue("supReaIdentifier", "test re7");
		this.save();
		AppLog.info(getClass(), "SITE :", this.getFieldValue("supReaIdentifier"), getGrant());

L’ensemble de ce code était positionné dans la méthode preValidate().

Aujourd’hui je n’arrive plus a récupérer les informations de mon jsonMetaObject() dans la méthode preValidate() alors que dans la méthode postSave() cela fonctionne normalement. Du coup, si je déplace mon code dans la méthode postSave(), je ne peux pas réaliser mon setFieldValue puisque je ne le verrai pas ensuite dans mon IHM.

Connaissez-vous une solution de contournement pour continuer à utiliser ma portion de code?
D’avance merci.

AISSANI Said

Bonjour,

Je ne suis pas sûr de bien comprendre votre besoin… je vais essayer de reformuler

Votre objet métier a un lien de type “objet” vers un record d’un objet Site qui est - je pense - un objet remote (“service-simplicité”), vous confirmez ?

Vous souhaitez récupérer des données métier de cet objet remote via ce lien “objet” pour valoriser, de manière persistante, des attributs de votre objet métier ?

Si oui la place de cette récupération est bien à implémenter au niveau du pre/postValidate ou au pire du preSave mais pas plus loin (car ensuite vous êtes au delà de l’enregistrement). Il ne faut pas raisonner UI mais bien record (la UI ne faisant qu’afficher un record)

Quand vous dites “une régression que j’ai pu constater ces derniers jours” que voulez vous dire ? Dans quelle(s) version(s) cela marchait il ? Depuis quelle(s) version(s) cela ne marche plus ? Y-a-t-il eu un changement du coté de l’application source ? etc.

Pour faire appel à notre support il est impératif de nous indiquer, à minima, quelle version x.y.z vous utilisez car pour vous aider nous avons besoin de reproduire le pb que vous décrivez.

Par ailleurs, voyez vous des éléments intéressants à nous communiquer dans les logs ? Ou d’autres informations qui pourraient être d’intérêt dans le contexte ?

PS: Dans le template des demandes de support il y a des rubriques prédéfinies pour ce type d’éléments nécessaires, ils sont justement là pour éviter de devoir vous les demander, merci de respecter ce template pour vos prochaines demandes.

Bonjour,
toutes mes instances sont aujourd’hui en 5.2.33. Je confirme également qu’il s’agit bien d’un service-simplicité. Je dirai que le bout de code fonctionnait encore jusqu’en 5.2.24 et aucun changement côté application source.
Côté logs si je place le code dans le preValidate(), j’ai l’erreur suivante:
Runtime exception: JSONException preValidate (JSONObject[“userkeylabel”] not found.)

Alors que dès qu’il est déplacé dans le postSave(), tout l’objet est bien retourné et je peux y extraire le champs souhaité.
Cordialement

AISSANI Said

La révision actuelle de la 5.2 est la 5.2.37. Nous ne pouvons pas apporter de support sur une révision pas à jour et de toute façon s’il devait y avoir une correction il faudrait vous upgrader.

Pour info il y a eu ~450 commits depuis la 5.2.24 donc il peut effectivement y avoir eu une régression comme il est possible que cette régression ait été corrigée depuis la 5.2.33.

Il est donc nécessaire de commencer par vous mettre à jour avant de solliciter notre support, à fortiori s’il s’agit d’une suspicion d’anomalie.

Je vais tester sur une 5.2 à jour en essayant de reproduire le cas que vous décrivez, je vous dirai ce que je constate.

Pour l’erreur dans les logs, quand vous manipulez des objets JSON mettez vous sous try/catch pour trapper les JSONException et, idéalement, les remonter sous forme d’erreur/warning utilisateur.

Sinon, mettre votre code dans le postSave n’a pas de sens si votre but est de valoriser des attributs persistants de votre objet local, si c’est l’objectif, comme je l’ai dit, le bon emplacement est clairement dans les pre/postValidate ou le preSave.

Si on parle d’attributs non persistants de votre objet local c’est plutôt du coté des postSearch/postSelect qu’il faudrait implémenter cette logique.

Vous n’avez pas expliqué ce que vous voulez faire sur ce point

Effectivement vous avez totalement raison, mon but est bel et bien de valoriser des attributs persistants, d’où le fait que l’extraction du champs de la métadonnée a été fait dans la méthode preValidate(). En suivant vos conseils, je vais mettre à jour mes instances en 5.2.37 et retester de mon côté pour voir s’il y a un quelconque changement.
Merci à vous

OK très bien.

En attendant je vais tester un pattern de ce type sur une instance 5.2 à jour.
Je vous tiens au courant

Il y avait bien un pb avec les attributs “object” sur des objets remote (ainsi que sur d’autres types d’objets “service”) lié un contrôle trop limitatif des foreign keys. Je n’ai pas remonté l’historique pour voir de quand date ce contrôle mais ce n’est pas récent.

En tout cas c’est corrigé dans la 5.2.38 qui a été livrée ce soir.

Je pense que ça devrait résoudre votre pb => upgradez en 5.2.38

PS: Le module suivant, basé sur la démo, a été enrichi pour démontrer ce type de pattern avec lien “object” sur des objets remote : GitHub - simplicitesoftware/module-remotedemo: Remote object examples (based on the Demo module), en particulier cf. ce code de l’objet local “commande” qui utilise 2 attributs “object” vers des objets remote “produit” et “client”: https://github.com/simplicitesoftware/module-remotedemo/blob/master/src/com/simplicite/objects/RemoteDemo/RemoteDemoLocalOrder.java:

Bonjour,
je vais donc upgrader en 5.2.38 et vous tenir au courant.
Je vous remercie.

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