Comment "aplatir" une api sur plusieurs niveau

Bonjour,
j’ai un objet Product qui appartient à une Structural Unit. Une Structural Unit peut avoir un parent qui lui même peut avoir un parent.

Mon besoin est de remonter les 3 niveaux de structural unit lorsque je fais un appel à produit.
Résultat attendu

{
      idProduct : xx,
      nomProduct: xxx,
      structuralUnitId : xxx,
      structuralUnitParentId : xxx,
      structuralUnitGranParentId : xxx
}

Grâce au addRefField j’ai réussi à aplatir Product et Structural Unit.

	addRefField("products", "structuralUnitId", "structuralUnitId", "it4itStructuralUnitId");
	addField("products", "structuralUnitIdentifier", "it4itStructuralUnitId.it4itGenIdentifier");

Existe t-il une façon de récupérer le parent du Structural Unit svp ?
J’ai essayé ceci sans résultat.

	addRefField("products", "structuralUnitStructuralUnitParentId", "structuralUnitStructuralUnitParentId", "it4itStructuralUnitId.it4itStructuralUnitParentId");

Object field de l’objet Product

Object field de l’objet Structural Unit

Merci d’avance

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-02-05 10:36 (revision 4271ab3e8ebfa613335f5cb919c3f3d2077b7a28)
Encoding=UTF-8
EndpointIP=172.17.0.5
EndpointURL=http://1271acf15d72:8080
TimeZone=Europe/Paris
SystemDate=2020-02-06 11:47:52!

Bonjour David,
je vois ça avec Amandine et nous revenons vers toi si besoin.
Bruno

Bonjour @david
vu avec @bmo, j’ai réussi à faire figurer son mon objet Structural Unit , le père et le grand père de l’objet. Cela fonctionne mais l’affichage prête un peu à confusion.
Dans la PJ, on a les champs

  • 10,20 et 100 sont des champs de mon objet.
  • 110, 120 et 140 sont des champs de mon objet parent.
  • 150 et 160 sont des champs de mon objet grand-parent.

Au niveau de l’affichage, on ne voit pas qu’il y a un niveau sur l’objet référencé.
Cela dit cela fonctionne.

Sachant qu’il s’agit d’un besoin très spécifique, je vous laisse voir si vous faites quelque chose sur ce point.

Cordialement

Je ne suis pas sûr de comprendre ce qui prete à confusion.

Si on parle des libellés affichés, les attributs d’objets peuvent porter des traductions propres qui permettent d’être plus explicites que traduction par défaut obtenue par concaténation d’autres traductions

Ex: dans la démo l’attribut “Name” du “Supplier” ramené à 2 niveaux dans l’objet “Order” est libellé “Supplier name” mais sans traduction de l’attribut d’objet il serait libellé par défaut “Product Supplier Name”

Bonjour

ce qui prête à confusion c’est que l’on a l’impression que les champs 110 et 150, 120 et 160 sont identiques alors qu’ils ont un niveau de profondeur plus important.
Pour les champs 140,150 et 160, la foreign key devrait être it4itStructuralUnitParentId.it4itStructuralUnitParentId

Cela dit que je l’ai dit cette “confusion” vient d’un besoin vraiment très spécifique, donc je ne suis pas sûre qu’il y ait des raisons de faire ce développement.

Cordialement

Il n’y a jamais d’ambiguïté au niveau technique car le nom technique (le “full input name”) empile les noms de foreign keys, ex: myFK1.myFK2.(...).myField

Là on parle de la traduction “best effort” que la plateforme génère par défaut à un attribut pour lequel on a pas traduit explicitement l’attribut d’objet.

Cela n’a, en général, pas trop de sens de laisser cette traduction par défaut sur les attributs ramenés, il vaut toujours mieux leur donner une traduction contextualisée à l’objet dans lequel ils sont ramenés

Ex: dans la démo l’attribut code du fournisseur est traduit simplement “Code” au niveau du fournisseur, il peut être traduit “Code du fournisseur” quand il est ramené dans le produit et “Code du fournisseur du produit” quand il est ramené dans la commande. Etc.

Je ne comprends pas pourquoi vous me parlez des traductions.
Mon point n’était pas sur l’affichage dans l’IHM de restitution de mon objet Structural Unit. La capture avait été faite uniquement pour montrer que cela fonctionnait bien.
Mon point était que dans la vue technique de l’objet (dans la description de ces champs), on différenciait “mal”, les champs du grand parent (150, 160) et ceux du parent (110, 120) car dans la colonne “Foreign key”, on a l’impression qu’il s’agit de la même valeur car il est juste écrit “it4itStructuralUnitParentId”. D’où ma suggestion d’afficher dans cette colonne pour le grand parent it4itStructuralUnitParentId.it4itStructuralUnitParentId.

Comme dit précédent, il s’agit ici d’un besoin vraiment très spécifique, et n’empêche aucunement le développement.

Il y a peut être une ambiguité visuelle mais techniquement il n’y en a pas.

Ex:
it4itStructuralUnitParentId.it5itGenIdentifier vs it4itStructuralUnitParentId.it4itStructuralUnitParentId.it5itGenIdentifier