Unboxing Consumed REST Services

Nous parlions, le mois dernier, du nouveau “Consumed REST Services Connector” qui a profité de la sortie de la 10.6 pour passer en bêta publique. Je vous propose un billet de découverte de cette nouvelle façon de configurer l’exécution de services REST au sein de vos applications Mendix.

Il vient en supplément de l’activité “Call REST Service” qui propose aujourd’hui plus de possibilités mais qui est également plus technique à utiliser. Avec ce nouveau connecteur, le concepteur a beaucoup moins de travail à faire et est plus assisté, le connecteur est donc plus simple à utiliser et découvre automatiquement le schéma du service… en résulte un gain manifeste de temps et forcément moins d’erreurs 😎.

Introduction

Quelques mots sur le connecteur avant de se lancer dans son utilisation.

Il nécessite l’utilisation de la version 10.6 (minimum) de Mendix.

Au moment de l’écriture de ce billet, seules les requêtes de types Get et Post sont prises en compte et la réponse du service doit être dans un format JSON. Bien évidemment, cela va évoluer dans les semaines à venir, n’oublions pas que pour le moment le connecteur est en version bêta. (NDLR : le support des requêtes de type Patch a été ajouté avec la version 10.7, celui des requêtes de type PUT avec la version 10.8).

Dans tous les autres cas (par exemple utilisation d’une version 9 de Mendix ou si vous souhaitez vous exécuter d’autres types de requêtes ou exploiter d’autres format de réponse) cela reste toujours possible en utilisant l’activité Call REST Service et en créant les objets adéquates dans votre projet. Cela nécessitera seulement un peu plus de travail (quelques minutes au lieu de quelques secondes 😉).

Vous retrouverez la documentation complète du connecteur dans la documentation Mendix.

Utilisation

Pour le billet, je vais créer un simple projet Mendix en partant d’une Blank Web App (et utilisant la version 10.6.1), histoire qu’il n’y ait aucune fioriture 😉.

Et l’idée sera de requêter un service publique qui fournit par pays le nom des villes correspondant à un code postal. Le service est disponible sur www.zippopotam.us.

Etape 1 – Connexion au service

Depuis un clic-droit sur mon module applicatif, j’ajoute un élément de type Consumed REST service (beta). Cela rajoute, dans mon explorateur de projet, un nouvel élément dont j’ai choisi le nom et ouvre une nouvelle fenêtre au sein de laquelle je vais pouvoir saisir les informations d’accès au service.

Au niveau de l’objet créé, je peux cliquer sur l’onglet Configuration & authentification afin de définir les informations de base d’accès à mon service : l’URL de base (https://api.zippopotam.us en ce qui me concerne – NB : ce paramètre sera automatiquement transformé en constante de votre projet dans une prochaine version) ainsi que le mode d’authentification si cela est nécessaire (dans mon cas, pas besoin, mais cela peut permettre de faire référence à un identifiant et un mot de passes stockés dans des constantes Mendix dans le cas d’une authentification basique). Dans le cas d’un autre type d’authentification, il sera possible de passer par la configuration d’entêtes HTTP spécifiques comme on le verra ci-après.

Ensuite je saisis les informations relatives à mon service dans la fenêtre de gauche :

• Request name : je donne un nom à ma requête et ce nom sera réutilisé lorsque je paramétrerai ma logique applicative.
• Method & URL : je choisis la méthode de la fonction appelée et je saisis son URL (dans mon cas : FR/{CodePostal})
• Onglet Parameters : je peux rendre paramétrables certains arguments de ma requête, ce que j’ai fait ici pour le paramètre que j’ai appelé CodePostal et que j’utilise entre accolades dans l’URL.
• Onglet Headers : je peux ici définir les entêtes de mon choix et je dispose d’un ensemble de clés/valeurs conventionnelles ou de la possibilité d’utiliser des entrées complètement personnalisées, ce qui pourra être utile pour certains services.

Voici la configuration du service que je souhaite utiliser :

Lorsque je clique sur le bouton Send, la requête est exécutée et je retrouve la réponse dans l’onglet Response Data de la fenêtre de droite. Puis dans l’onglet Response Structure, je retrouve l’entité non-persistante que Mendix se propose de créer pour pouvoir manipuler le service lors du Runtime 👍. Pour ceux d’entres vous qui ont l’habitude d’utiliser l’ancienne méthode, vous devez comprendre tout le travail que Mendix vous pré-mâche (création d’une structure JSON, d’un export mapping etc.). N’est-ce pas excellent ??

Il ne reste plus qu’à cliquer sur Create Entity pour créer les entités dans le Domain Model de mon module.

Etape 2 – Préparation du microflow de récupération des villes

Je crée un simple microflow qui, à partir, d’une entité Root (qui contiendra le code postal de recherche) va exécuter l’appel au webservice paramétré en étape 1 et me renvoyer cette liste d’entité Place.

Donc dans un 1er temps je définis le type d’objet en entrée (ma NPE Root), puis j’utilise l’activité Send REST request (beta) pour laquelle la REST request sera le service configurée à l’étape 1, le champ CodePostal correspondra à l’argument Post_Code de mon paramètre d’entrée et je stocke le résultat dans un objet de type Root que j’appelle Root_Out.

Là, on a fini tout ce qui était spécifique à l’utilisation du nouveau connecteur REST… à l’exécution, dans notre objet Root_Out, on doit avoir autant d’entrées qu’il y a de villes à avoir le code postal passé en paramètre, le reste est donc du cosmétique et les manipulations nécessaires sont dépendantes de la structure de la réponse du webservice.

Afin qu’on puisse voir le résultat d’un point de vue utilisateur final, je finis rapidement mon microflow en ajoutant une activité Retrieve From Association pour récupérer la liste des Place (des villes) et je vais passer cet objet en sortie de mon microflow. J’en profite aussi pour mettre une condition et n’exécuter ce GetCity que si un code postal est saisi afin d’éviter un message d’erreur. Voici ce que ça donne :

Etape 3 – Résultat

Je ne vais pas tout détailler par écrit ici car il ne s’agit plus de l’usage du connecteur, mais voici un GIF (dans une qualité médiocre 🤨) qui reprend l’ensemble des étapes restantes afin d’avoir une UI qui utilise ce service et ce microflow (navigation vers une page qui crée un objet Root, puis utilisation d’une Data grid 2 dont la source est le microflow créé à l’étape précédente et qui prend en paramètre l’objet Root sauvegardé).

Ce qui permet d’obtenir le résultat suivant :

Conclusion

L’utilisation de ce connecteur (pour le moment en bêta) est très intuitive et permet aux concepteurs qui débutent avec Mendix de prendre en main cette partie intégration beaucoup plus facilement qu’avec le connecteur usuel. Autre avantage, la configuration ne se compose que d’un seul objet Mendix ce qui permet d’organiser plus proprement son travail.

Comme pour l’ensemble des évolutions Mendix, on peut affirmer que l’on tend vers de la simplification de conception grâce à une assistance plus forte, et ce, afin de gagner en rapidité, mais sans pour autant retirer la flexibilité disponible 💪.

Pendant la préparation de ce billet, Ryan a sorti le sien… alors même s’il y a beaucoup d’informations qui se recoupent, voici un lien vers son billet qui traite d’une intégration de type POST avec un webservice Asana.

🔥🔥🔥 Happy Low Coding 🔥🔥🔥