Composants REST, Récupérer les informations du header

Bonjour, c'est le début du week-end et quelque chose me titille
Quand j'utilise Rest Debugger j'ai, entre autres, ces informations

Pièce jointe 619533

quand on suit le processus jusqu'au bout, on obtient ces composants
Pièce jointe 619534
lequel et quelle propriété me permet de récupérer les données de l'en tête (en particulier X-WP-Total et X-WP-TotalPages)

TRESTResponse.Headers je dirais naïvement.
TRESTResponseAdapter contient aussi 'Headers' comme TBindSourceAdapterField<TString> ça c'est du Live-Bindings, je suppose, je crois que tu utilises ça, moi j'ai encore jamais essayé.

Grand naif
Pièce jointe 619535
je suis resté sur les propriétés visibles

J'étais vraiment fatigué hier soir !
Pour la petite histoire, il s'agissait d'obtenir le nombre de commandes WooCommerce enregistrées.

requête : https://xxxxxxxx.xxx/eshop/wp-json/wc/v3/orders avec un paramètre per_page=1

Code:

---

1 2 3 4 5 6 7 8 9 10

procedure TFormTest.Button2Click(Sender: TObject); begin RestRequest1.Execute; if RESTResponse1.Status.Success then begin memo1.Lines.Clear; memo1.Lines.AddStrings(RestResponse1.Headers); ShowMessage(memo1.Lines.Values['X-WP-Total']); end; end;

---

Pièce jointe 619565

NB. X-WP-Total = X-WP-TotalPages puisque le paramètre per_page=1

Mes premiers tests pour l'application que je suis en train d'écrire (récupération des commandes Woocommerce vers notre ERP) utilise Cdata Woocommerce mais j'en suis déçu niveau temps d'exécution.
Ce test va me permettre de vérifier si je peux faire mieux sans (du moins pour la partie récupération de la liste des commandes)

Pour information, j'obtiens quasiment le même temps, en récupérant toutes les informations

Pièce jointe 619571

Conclusion : Si CData est plus "simple", en termes de nombre de composants à déposer (2 au lieu de 5 pour REST) et d'une possibilité de requêtes pour réduire le nombre de colonnes, le prix reste un frein important.

NOTE : Si j'arrive à réduire aux colonnes souhaitées la requête REST (là je suis dépendant de l'API) je pense avoir un gain de temps significatif. Affaire à suivre

L'avantage c'est que tu peux aussi intervenir côté serveur en copiant le programme de l'API qui t'intéresse pour réduire son contenu. Enfin, quand on te laisse faire ce que tu as à faire côté serveur, bien entendu. ;)

Citation:

---

Envoyé par SergioMaster

NOTE : Si j'arrive à réduire aux colonnes souhaitées la requête REST (là je suis dépendant de l'API) je pense avoir un gain de temps significatif. Affaire à suivre

---

Ce n'est pas possible que je sache.

Mais tu peux récupérer les données par bloc de 100, pourquoi les prendre une à une ? Une boucle en définissant per_page=100 et en incrémentant page jusqu'à atteindre X-WP-TotalPages. 6 requêtes à la place de 534, y'a pas photo...

Reste à savoir pourquoi tu dois récupérer toutes les ventes. Le but en production étant plutôt de mettre en place un webhook pour être notifié en quasi temps réel des modifications.

Citation:

---

Envoyé par pprem

Enfin, quand on te laisse faire ce que tu as à faire côté serveur, bien entendu. ;)

---

Ben justement, si on me laissait faire je galèrerais moins.
La société qui a conçu le site m'a laissé sans accès à la base de données lors de la mise en place et ce pendant presque 6 mois "Si vous touchez aux données, nous ne garantissons plus le site" alors que je ne fais que de la lecture !
À mon avis, le site n'était pas prêt, mais de là à m'empêcher de faire des lestures de données !!!

Citation:

---

Envoyé par pprem

En copiant le programme de l'API qui t'intéresse pour réduire son contenu.

---

Oui, ça j'arriverais certainement à le faire, si je savais comment m'y prendre pour accéder au site pour pomper l'API, ajouter un peu de PHP à mon carquois (pour mon arc) langages ne serait pas pour me déplaire c'est même une des pistes que j'envisage pour utiliser mon compte CPF avant mes derniers 400 jours ;)

Citation:

---

Envoyé par Andnotor

Ce n'est pas possible que je sache.

---

Hélas, c'est une demande pendante, comme la possibilité de récupérer à partir d'une id
Mais je suis soufflé par le manque "d'écologie" pourquoi envoyer tout le contenu d'un ordre alors que je n'en veux qu'une infime partie (id, status et quelques autres) c'est de nombreux octets inutiles qui transitent sans réel besoin

Citation:

---

Mais tu peux récupérer les données par bloc de 100, pourquoi les prendre une à une ?

---

le 1 est juste pour récupérer le nombre total
50 est le nombre utilisé par Cdata (50 par défaut) valeur de mon test

pour info, avec 100, je ne "gagne" que quelques secondes
Pièce jointe 619611

Citation:

---

Reste à savoir pourquoi tu dois récupérer toutes les ventes.

---

Uniquement celles non traitées dans l'ERP d'où mon idée pas encore testée d'utiliser le paramètre include

Citation:

---

pour être notifié en quasi temps réel des modifications.

---

ce n'est pas prévu pour être du temps réel, juste un travail 1 à 2 fois jour

Citation:

---

Envoyé par SergioMaster

le 1 est juste pour récupérer le nombre total

---

Ok, j'avais mal lu.

Citation:

---

Envoyé par SergioMaster

Uniquement celles non traitées dans l'ERP d'où mon idée pas encore testée d'utiliser le paramètre include

---

include implique de connaitre les IDs à récupérer et donc logiquement de remplir cette liste par webhook. Un webhook sur une vente ne retourne que deux informations : son ID (évidemment) et son statut (exactement ton screenshot).

Mais il y a un filtre (non documenté) qui devrait certainement te convenir pour un traitement sporadique : modified_after. Exemple /wp-json/wc/v3/orders/?modified_after=2022-05-22T00:00:00Z.


Cela dit, ton test est extrêmement lent. Un essai Postman me permet de récupérer 100 éléments en 2.5s. Tu n'aurais pas un problème de rafraichissement systématique du access token multipliant les requêtes ?

Perso je n'utilise pas les composants REST que je trouvais très lourds et ai préféré faire mes propres routines basées sur TNetHttpClient. Je ne fais également appel qu'aux APIs sans plug-in particulier, mais je tire profit des hooks.

Citation:

---

Envoyé par Andnotor

include implique de connaitre les IDs à récupérer et donc logiquement de remplir cette liste par webhook. Un webhook sur une vente ne retourne que deux informations : son ID (évidemment) et son statut (exactement ton screenshot).

---

j'avais pensé créer ma liste des include par un CTE Recursive(Firebird)

Code:

---

1 2 3 4 5 6 7 8 9 10 11

WITH RECURSIVE nombres AS ( SELECT :MINID nbr FROM rdb$database UNION ALL SELECT nbr + 1 FROM nombres WHERE nbr <= :MAXID)   SELECT list(CAST(nbr AS INTEGER)) FROM nombres n LEFT JOIN CMDE_WOOCOMMERCE w on w.IDWOOCOMMERCE=n.nbr WHERE w.IDWOOCOMMERCE is null

---

Citation:

---

Exemple /wp-json/wc/v3/orders/.

---

c'est la même requête https://xxxxxxxx.xxx/eshop/wp-json/wc/v3/orders les paramètres étant définis par la suite
NB. je ne connaissais pas le tag [ c ] du forum :ccool:, nettement moins long à écrire ;)

Citation:

---

Cela dit, ton test est extrêmement lent. Un essai Postman me permet de récupérer 100 éléments en 2.5s.

---

Je suis d'accord, c'est lent, avec RestDebugger j'ai 2.1 secondes
Je pense que c'est l'interpréteur (RestreponseAdapter) qui est le coupable, je vais tenter de l'éviter pour voir

Citation:

---

Tu n'aurais pas un problème de rafraichissement systématique du access token multipliant les requêtes ?

---

pour l'instant je ne passe pas par un access token (c'est probablement une erreur, que je corrigerai ensuite) c'est une connexion "BASIC"

Citation:

---

Perso je n'utilise pas les composants REST que je trouvais très lourds et ai préféré faire mes propres routines basées sur TNetHttpClient. Je ne fais également appel qu'aux APIs sans plug-in particulier, mais je tire profit des hooks.

---

c'est comment les appeler, ces hooks, qui me serait profitable, parce que là je ne vois pas comment faire
TNetHttpClient est aussi une piste que j'ai négligée

Côté WooCommerce, ça se défini dans : Réglages -> Avancés -> Crochet Web.

Les données sont :

Nom
un nom quelconque.

Etat
A mettre sur activé évidemment.
Ce qu'il faut savoir ici est que si l'envoi échoue toujours après plusieurs tentatives (je n'ai plus en tête le nombre par défaut), l'état va passer automatiquement en pause et tu ne recevras plus rien jusqu'à réactivation manuelle !
Pour palier à ce problème, je te conseille vivement de créer un thème WordPress enfant et d'augmenter la limite. Ca se fait à l'aide d'un filtre dans functions.php :

Code:

---

1 2 3 4 5

// Ne désactive jamais les webhooks add_filter('woocommerce_max_webhook_delivery_failures', 'andnotor_woocommerce_max_webhook_delivery_failures'); function andnotor_woocommerce_max_webhook_delivery_failures($number) { return 999999999; }

---

Sujet
C'est ce que tu veux surveiller, par exemple Commande créée. Perso je préfère passer par des Action qui permettent plus de finesse.

Evénement action
Si tu as choisi Action précédemment.
Il y en a pléthore et perso j'en utilise 4 : woocommerce_order_status_processing, woocommerce_order_status_completed, woocommerce_order_status_refunded et woocommerce_order_partially_refunded.

URL de livraison
Le script php sur ton serveur.
Pour tes premiers essais, tu peux passer par ce site https://webhook.site. Tu verras ainsi ce qui transit sans te fatiguer.

Secret
Une suite de caractères quelconque. Le message de notification est haché et et ce hash est retourné dans HTTP_X_WC_WEBHOOK_SIGNATURE en base64. Dans ton script php, tu feras la même chose pour valider la notification $signature = base64_encode(hash_hmac('sha256', $body, $secret, true)); et if ($signature == $_SERVER['HTTP_X_WC_WEBHOOK_SIGNATURE']) {traitement}.

Version de l'API
A laisser sur v3.


Voilà c'est pas plus compliqué que ça !


Pour les tests, c'est pas mal aussi d'activer les notifications instantanées histoire de ne pas perdre de temps, sinon ça passe par une tâche CRON et il faut patienter quelques secondes ou minutes. Toujours dans functions.php :

Code:

---

1 2	// DEBUG : Webhook immédiat (sans CRON) add_filter( 'woocommerce_webhook_deliver_async', '__return_false');

---

Dans le script php et puisque tu ne veux pas gérer immédiatement les données, tu peux simplement insérer dans une table l'ID et statut après contrôle de la signature, table que tu videras quand tu veux. Juste quelques lignes de code ;)

Citation:

---

Envoyé par SergioMaster

NB. je ne connaissais pas le tag [ c ] du forum :ccool:, nettement moins long à écrire ;)

---

Et très peu connaissent le tag [noparse] qui te permet d'écrire [c] à la place de [ c ] :mouarf:

Merci pour ces explications. J'ai effectivement vu la page Woocommerce/Réglages/Avancé/Crochets Web, mais étais bloqué sur l'URL de livraison.

Citation:

---

Toujours dans functions.php :
Dans le script php et puisque tu ne veux pas gérer immédiatement les données.
Juste quelques lignes de code

---

Voilà le point noir, je suis obligé de passer par le prestataire gérant le site et, le connaissant, il va facturer honteusement un boulot que j'aurais pratiquement fait à sa place ! (ça m'est déjà arrivé)
Je n'ai que des relations épisodiques avec eux, car la moutarde me monte vite au nez (cf ma réponse à Patrick post #8).

et merci pour ce nouveau tag ;)

Citation:

---

Envoyé par SergioMaster

Voilà le point noir, je suis obligé de passer par le prestataire gérant le site

---

Ca c'est pour functions.php uniquement (le thème enfant) mais ce n'est pas obligatoire dans un premier temps. Cela dit, ce thème dérivé existe peut-être déjà. Difficile de personnalisé un site WordPress sans lui (à moins de créer des plugin-ins de A à Z).

Mais lorsque je parle de "script php" c'est bien de ton côté ; un serveur http ayant accès à la base de données de ton ERP.



ps : on est plus trop dans Delphi là. J'espère ne pas soûler les lecteurs ;)

Pour le nombre de colonne, voir si le Service REST supporte un modèle de protocole type ODATA avec l'opérateur $select=id,status,... soit https://xxxxxxxx.xxx/eshop/wp-json/wc/v3/orders/?$select=id,status,...&Autre=Param&...

Si CData permet de faire des requêtes pour réduire le nombre de colonne, faut espérer que c'est un vrai filtre envoyé au serveur et pas juste un masquage des données inutilisées.

Citation:

---

Envoyé par ShaiLeTroll

Pour le nombre de colonnes, voir si le Service REST supporte un modèle de protocole type ODATA avec l'opérateur

---

Pas de ça chez woocommerce ou alors bien caché

Citation:

---

Si CData permet de faire des requêtes pour réduire le nombre de colonnes, faut espérer que c'est un vrai filtre envoyé au serveur et pas juste un masquage des données inutilisées.

---

vu mes tests, c'est juste un masquage de données donc je suis en train d'abandonner son utilisation

Avec ma méthode utilisant le parametre include je "tombe" à 4 secondes donc je garde ;)

Désormais j'ai un autre problème (rien à voir avec REST) je n'arrive plus à retrouver ma table pour la lier visuellement, dès fois, c'est galère Livebindings !

Citation:

---

Envoyé par SergioMaster

Désormais j'ai un autre problème (rien à voir avec REST) je n'arrive plus à retrouver ma table pour la lier visuellement, dès fois, c'est galère Livebindings !

---

ça, c'est résolu, la table était cachée dans le concepteur. Un clic droit et une sélection de la table ont suffit