J’essaie d’accéder, depuis mon environnement, au contenu d’un objet métier présent sur un autre environnement Simplicité.
J’utilise pour cela un paramètre système contenant l’url et les credentials de cet environnement et j’ai ensuite un objet métier configuré en “service-simplicite” qui permet de recevoir et d’afficher les données.
Jusque là rien de nouveau et ça fonctionne, je reçois bien le contenu de l’environnement que je souhaite interroger dans mon objet “service-simplicite”.
Le problème arrive lorsque j’essaye d’utiliser ce fameux objet “service-simplicite” comme champ de type “object” d’un autre business object (disons A) de mon environnement.
Je sais que c’est faisable car j’ai déjà 3 ou 4 exemples de ce mécanisme qui fonctionnent.
Dans le cas présent, tout se passe normalement jusqu’à ce que j’essaie de choisir via l’écran de A un record de l’objet “service-simplicite”. Rien ne s’affiche et dans les logs, j’obtiens l’erreur suivante :
Pourtant dans ce fameux objet “service-simplicite” j’ai mis exactement la même configuration (dans les onglets “Interface”, “Options”, “Buttons”) ainsi que les mêmes grant.
Je suis un peu à cours d’idées, je ne sais pas si cette erreur vous parle ou si il y a une action spécifique à réaliser que je ne connais pas.
Il doit y avoir un stack trace plus explicite côté serveur dans simplicité ou catalina.
On pourra peut être mieux cerner ce qui n’est pas valorisé dans le service.
Sinon un meta-objet est stocké physiquement comme "<nom de l'objet>:<row_id>" où le row_id est celui de votre table distante. Il se peut donc qu’un lien mort existe si vous supprimez un record distant, il n’y a pas d’update cascade dans votre base. Il faudra prévoir un mécanisme d’auto-correction de références mortes.
On peut également faire un Datamap qui permet de ramener/copier les champs par valeur (et non la référence). C’est une autre forme de dénormalisation locale qui s’affranchit du row_id, et qui permet de faire des requêtes locales sur les champs copiés.
