Bonjour,
Je cherche une méthode pour récupérer un query parameter dans un hook.
Ce paramètre venant d’un appel REST GET sur la resource contenant ce hook.
Savez-vous si c’est possible, si oui, quell méthode faut-il utiliser?
Merci d’avance
Merci de préciser le contexte de cette question…
De quelle “resource” parle-t-on précisément ?
Comment se fait l’appel GET REST en question ?
Etc.
En fait quel est le besoin (car je sens que le pb n’est pas abordé de la bonne manière) ?
Le besoin de base consisterai à pouvoir retourner le résultat d’une requête SQL customisée pour ne récupérer que certains résultats filtrés suivant un critère et limités en nombre.
Cette requête doit s’exécuter sur un table de la BDD ce qui revient à récupérer le contenu du Business Object qui la représente au niveau logique.
L’appel se fait via le mapping sur la ressource qui mappe le Business Object en question.
Cette description est loin des concepts Simplicité… quand on parle de “requêtes SQL” et de “BDD” je suis toujours inquiet car j’ai l’impression qu’on est en train de passer à coté des mécanismes de la plateforme et c’est en général le signe d’une mauvaise approche.
Bref merci de m’expliquer de manière détaillée le quel est le besoin métier auquel vous essayez de répondre ?
Donnez moi des exemples de ce que vous voudriez faire comme appels d’API et ce que vous voudriez avoir comme réponse, et dites moi en quoi ce n’est pas faisable avec les mécanismes standard et APIs standard ou mappées de la plateforme.
Vous parlez de “hook”, OK je comprend qu’on parle d’un hook d’un de vos objets métier (je pense), de quel hook parle-t-on, que fait-il ?
Etc. La manière dont vous posez la question est trop vague pour vous guider vers la bonne approche.
Pour faire simple je veux faire cet appel :
GET https://mon.url.com/mapping/resource?p=test
Et je voudrais récupérer dans un hook, si possible avant l’appel à la BDD par le socle pour filtrer la recherche/faire divers traitements.
Sachant que p n’est absolument pas un champ de la ressource mappée mais juste une valeur à laquelle je voudrais avoir accès dans le code.
Merci de me répondre sur le hook car tant que je n’aurai pas compris ce que vous y faites je ne pourrai pas vous répondre de manière pertinente
Bonjour,
Je souhaite y effectuer cette requête : SELECT * FROM table WHERE field LIKE p% (à la syntaxe près bien sûr) afin de récupérer toutes les occurrences commençant par p.
On ne se comprends pas, dans Simplicité vous ne devriez pas avoir à faire du SQL, si vous le faites c’est peut être que votre approche n’est pas la bonne et que du coup votre demande initiale est à challenger.
Ce que je veut comprendre c’est le besoin qui vous a amené à mettre en oeuvre cette approche qui n’est peut être pas la bonne
Par exemple peut être que la bonne solution c’est plutôt un lien virtuel, peut être filtré par la valeur d’un attribut non persistant, avec embedding des records liés, etc. auquel cas on resterait à 100% dans des mécanismes standards sans devoir “bricoler” le passage de paramètre atypique qui est l’objet de votre demande initale.
Bref copiez/collez moi le code de votre hook pour que je comprenne à quel moment du cycle de vie de votre objet vous faites cette requête et quel est la logique métier de cette requête.
Pour rappel, dans Simplicité la couche de publication API est une couche de mise en forme sans intelligence, elle ne fait qu’exposer l’intelligence des objets métier, et ce pour la simple et bonne raison qu’un objet métier peut certes être accédé via une API mais aussi via une UI ou via un import/export en masse, bref il doit offrir la même logique quel que soit le mode d’accès.
Mon besoin consiste à récupérer de la BDD d’une manière ou d’une autre toutes les lignes/occurences (dans mon cas spécifique, les fournisseurs) dont l’un des champs, ici son nom, commence par une certaine chaîne de caractères fournies par l’appelant de l’API.
Je n’ai pas encore de code dans un hook puisque je voulais voir avec vous comment récupérer de l’API le QueryParam contenant la chaîne de caractères.
Je continue à ne pas comprendre votre besoin…
Les APIs GET (search) des objets métier permettent nativement de passer des paramètres pour faire des recherches en filtrant sur les attributs de l’objet. ex: /api/rest/MonObjet?monAttribut=A%25 (le %25 étant ‘%’ en URl-encodé), cf. https://docs.simplicite.io/documentation/02-integration/rest-services.md#searching
Est-ce que c’était ça votre question ? Vu la manière dont vous avez formulé votre demande initiale (en parlant de “hook”) je pensais qu’on parlait d’un besoin plus complexe…
Je vais proposer ça aux consommateurs et je reviens vers vous.
Merci!
Franchement cet échange n’est pas normal ! Après de nombreux échanges, je n’arrive pas à comprendre de quoi vous parlez. Est-ce que vous parlez d’une simple recherche avec filtre qui est le B-A-BA de l’usage des APIs génériques ou mappées ou si on parle d’une chose plus subtile/spécifique que je n’arrive pas à cerner à la lumière de nos échanges.
Je sais que vous êtes chez Renault, donc que vous utilisez les APIs mappées, or l’exemple que je vous ai donné ci-dessus correspond aux APIs génériques. vous devriez avoir réagit avant de dire que vous alliez “proposer” je ne sais quoi à je ne sais qui !!!
Pour mémoire les APIs mappées fournissent les mêmes services CRUD (ou “R” inclus bien évidemment la recherche multicritères avec ou sans wildcards et avec ou sans pagination) que les APIs génériques mais, comme vous le savez, selon une hiérarchie et une syntaxe conforme à vos normes internes, il est donc possible de faire une recherche en utilisant un GET sur /<là où vous avez exposé vos APIs mappées>/<mon nom d'objet mappé>?<mon nom d'attribut mappé>=<mon filtre (où le wildcard peut être * = %2A en URl-encodé)>
Referez vous au schema OpenAPI de vos APIs mappées pour avoir le détail des requêtes GET de recherche.
PS: désolé d’être un peu désagréable mais cet échange est infiniment trop chronophage, surtout si on parle de simples recherches multicritères…
Bonjour,
Désolé pour votre temps, pour aller au plus simple, j’ai “fortement” suggéré (au cours de cet échange) d’utiliser les mécanismes standards de filtrage (ce qui n’était pas gagné…).
Finalement, ils ont accepté donc ils peuvent eux-même s’occuper du filtrage des données.
Encore désolé pour votre temps.
De ce que j’ai compris de votre demande ce que vous vouliez était exactement la même chose que le mécanisme standard => vous vouliez passer un parametre d’URL avec un filtre, c’est exactement ce que l’on fait avec le filtrage standard:
<mon URL>?<un faux nom d'attribut>=<mon filtre>
vs
<mon URL>?<le vrai nom d'attribut>=<mon filtre>
Je ne vois fondamentalement pas la différence dans l’usage… Et donc je ne vois vraiment pas pourquoi il pouvait y avoir un quelconque débat chez vos consommateurs !?!
Surtout que si Renault a mis en place des normes de structurations et de nommage des APIs c’est pas pour les utiliser de manière non standard pour se conformer à un “caprice” de tel ou tel consommateur ! Ce serait totalement antinomique avec votre approche de normalisation “5 étoiles” de vos échanges inter-applications !
Bref vous m’avez perdu car je pensais qu’on parlait de quelque chose de plus subtil (pour lequel on aurait forcément trouvé une approche sur la base des mécanismes standards ou, au pire, fait évoluer le composant de mapping pour rester dans le standard “5 étoiles”).