Custom API - Gestion des relations NN

Bonjour,

Je travaille actuellement sur la mise en place d’API sur mon projet Simplicité.
J’utilise un objet externe pour pouvoir mapper les services de manière spécifique, pour que cela corresponde aux normes de mon entreprise.
J’ai un objet “company” qui a une relation NN avec un objet “group”.
Lorsque j’appelle l’API GET qui doit me renvoyer des informations sur une company, je souhaiterais qu’elle me renvoie, en plus des informations de base sur la company, une liste avec les groups qui lui sont liés.
Comment puis-je intégrer ces objets dans mes services?

Merci,

La question est plus large que ce cas particulier…

Que disent les normes de votre entreprise quant à la possibilité d’embedder des listes liées en 1-N au sein d’une réponse GET d’un record ? Il me semble que quand j’avais posé la question il y a des mois le sujet n’était pas abordé clairement dans vos normes.

En attendant d’avoir des directives claires sur ce genre de choses dans le cas général on peut toujours aborder ce cas particulier en mode “bricolage”, genre on ajoute un attribut texte long (de type JSON) non persistant sur mon objet qu’on valorise dans le postSelect avec la liste des codes de groupes liés via la N-N.

NB: Pour info nos APIs génériques “treeview” savent gérer ce genre de choses en standard, c’est dommage de devoir, là aussi, se passer de la richesse et de la flexibilité de nos APIs standards pour une question de normes maison contraignantes…

PS:

En relisant le code du RESTMappedObjectsExternalObject je vois qu’on avait commencé à prendre en compte ce besoin d’embedding de listes liées Mais c’était resté en friche en attendant d’avoir plus d’infos vis à vis de vos normes et un cas concret à traiter à titre d’exemple.

Bref à remettre à l’ordre du jour des évolutions demandées par @bmo sur cette classe RESTMappedObjectsExternalObject

Comme dit dans le message suivant, les normes autorisent en effet cela.
Je suis donc en train de mettre en place la solution “bricolage”.
Cependant, j’ai des problèmes de droits dans le postSelect au moment de valoriser l’objet. En effet, mon objet pour certains utilisateurs est simplement disponible en mode “Read”, et lorsque je le sélectionne, je modifie le champ.
Est-ce que j’emploie la bonne méthode, ou il y a-t-il des paramètres que je peux modifier dans l’objet de façon à n’avoir une modification que sur celui-ci?

Valoriser en mémoire un attribut non persistant de votre objet n’a strictement rien à voir avec les droits CRUD sur l’objet (qui concernent le fait d’enregistrer le record)

Copiez/collez moi votre code pour que je comprenne ce que vous faites.

J’avais mal interprété votre réponse.
J’essayais en effet d’enregistrer dans un champ la valeur de mon JSON. Je ne vois pas cependant comment faire pour valoriser en mémoire un attribut non persistant.
Voici la partie de mon code correspondant:


@Override
	public void postSelect(String rowId, boolean copy) {
		
		cpy = (SupCompany)getGrant().getTmpObject("SupCompany");
		cpyTool = new BusinessObjectTool(cpy);

		try {
			List<String[]> listCurrentCpy = cpyTool.search(new JSONObject().put("row_id", rowId));

			JSONArray elementToPutInJSON = new JSONArray();

			// Rempli le elementToPutInJSON avec les bonnes valeurs

			cpy.setValues(listCurrentCpy.get(0), true);
			cpy.setFieldValue("supCpyLinkedElements", elementToPutInJSON);
			
			cpyTool.validateAndSave();
		} 
...

Le validateAndSave n’a rien à faire là.

On parle ici de valoriser en mémoire un attribut non persistant (sans nom de colonne).

J’ai bien compris que le validateAndSave n’avait rien à faire ici, j’avais mal interprété votre toute première réponse, mais je comprends bien qu’il ne faut pas enregistrer la valeur directement dans l’objet.
Je vais reformuler ce que je disais dans le message précédent, à savoir, comment peut-on valoriser un attribut en mémoire dans Simplicité?

Ben par un simple setFieldValue("myField", "myValue") un attribut non persistant est un attribut comme les autres.

Il est juste zappé au save (mais de toute façon ici pas question de save).

NB: en passant un JSONArray en tant que valeur, le setFieldValue va forcer un toString().

Cela dit cette solution “bricolo” à base d’attribut non persistant JSON reste très peu satisfaisante.

Je préférerais qu’on profite de ce cas particulier pour améliorer la classe RESTMappedObjectsExternalObject pour gérer ça de manière générique (d’autant que ce besoin avait déjà initié dans cette classe mais laissé en l’état faute de specifications)

J’ai donc juste besoin de savoir quel format vos normes souhaitent s’agissant d’embedder des liste d’objet liés en 1-N, sur ce point je n’ai jamais eu de spécifications claires. Pour mémoire ce composant a été développé pour répondre spécifiquement à vos besoins/normes/contraintes, ce n’est pas à moi d’en inventer les spécifications…

@bmo peut être as tu des exemples à me fournir vu que la réflexion/validation des APIs spécifiques semble avoir été plus poussée dans le cadre de BCSI.

Je suis d’accord sur le fait que l’amélioration de la classe RESTMappedObjectsExternalObject est la meilleure solution, je vais voir avec @bmo comment nous pouvons avancer sur le sujet.
Malgré tout, cela prendra plus de temps et j’en ai malheureusement très peu pour terminer les API, c’est pour cela que je souhaitais avoir plus d’informations sur la deuxième méthode.

J’ai donc fait la valorisation de l’attribut en mémoire comme vous l’avez indiqué. L’attribut est en effet mis à jour juste après quand j’affiche des logs pour vérifier, mais il n’est pas renvoyé lors de l’appel de l’API.

Il faut le mapper dans votre classe qui hérite de RESTMappedObjectsExternalObject comme n’importe quel attribut que vous souhaitez exposer sur ces APIs custom