Bonjour
tout d’abord bonne année 2021.
J’ai un objet Application contenant des nombreux champs.
Lorsque je clique sur le détail d’une application, je souhaiterai ajouter une zone qui afficherait le résultat d’une requête API. Par exemple, nous requêterions JIRA pour savoir le nombre de tickets sont associés à cette application.
J’étais partie sur la création d’une zone dans laquelle je faisais un appel AJAX puis mettait en forme le résultat mais je ne suis pas sûre que ce soit la meilleure approche.
Déjà il faudrait savoir si vous souhaitez/pouvez faire l’appel coté client ou coté serveur.
Coté client ça semble plus simple (car Ajax/Javascript) mais vous risquez tomber dans l’enfer des configs CORS et certains modes d’authent ne sont pas forcément possible, etc. mais si on est dans un cas simple pourquoi pas
Coté serveur c’est plus flexible car on est dans un monde Java
Dans tous les cas il faudra ajouter un attribut non persistant (ou une simple div si on est coté client) pour afficher le résultat de l’appel.
PS: si vous avez bessoin de persister ces données et/ou de les rendre accessibles sur d’autres interfaces que la UI (= API ou I/O) alors clairement il faut implémenter coté serveur
Merci pour votre retour.
Je trouve plus simple d’utiliser le java car avant de pouvoir requêter notre API Apigee, il y a une phase d’authentification et nous avons déjà développé des méthodes génériques.
Nous avons 2 requêtes à faire :
Récupération d’un statut -> on utiliserai un champ text non persistant comme vous l’avez indiqué
Récupération d’une liste de tickets à afficher sous forme de tableau -> dans ce cas aussi vous préconisez de faire de même ? Un champ HTML et construire nous même la div. Est-ce bien cela ?
Si l’appel est rapide / synchrone, il faut effectivement passer par des champs à valoriser lors du postSelect (avec un timeout de qq secondes si le service ne répond pas pour répondre à la UI).
Limiter ce calcul à l’instance Main, pas besoin a priori de faire ces appels pour des objets tmp ou batch…
Si le service met du temps (>500ms) il faut plutôt passer par un appel asynchrone = créer une zone dans votre formulaire qui charge un objet externe HTML avec ce contenu externe récupéré en Java.
Si la liste des tickets est juste informative, un champ HTML avec des <ul><li> peut être suffisant, mais si vous devez l’afficher avec une liste standard, des filtres… il faudra plutôt créer un objet métier “service” qui implémente le getCount + search et lié à votre objet Application via une FK.
Bonjour
merci @Francois pour ces réponses. Je pense qu’il est préférable de passe par un appel asynchrone et un objet externe. Avez-vous un démo sur laquelle je pourrais m’appuyer ?
Par curiosité, avez-vous aussi des exemples d’objet métier “service” ? Nous en utilisons déjà mais uniquement entre des instances simplicités.
Un objet service est un objet pour lequel on implémente le CRUD de manière specifique
Les objets “service-simplicite” sont un cas particulier où le CRUD est implémenté en appelant les APIs d’une instance Simplicité distante. Il y a d’autres types d’objets service fournis : LDAP, OpenDataSoft, SalesForce, …
Je ne pense pas qu’il y ait de la doc sur les objets service custom, ça va être l’occasion de l’écrire, en attendant ou peut fournir des exemples.