Development #3090
gestion asynchrone, retour via trigger
0%
Description
Pour gérer les problèmes avec les webservices tiers qui répondent trop lentement, on peut imaginer le scénario suivant:
1. le système appelant accède à la ressource passerelle nommée /queue/<slug>. Passerelle reçoit :
a. les données de la requête elle-même (variables) à transférer au ws tiers
b. une URL de retour ou de quoi la fabriquer
2. passerelle génère un ticket et le renvoie à l'appelant
3. passerelle effectue la requête vers le webservice tiers (qui peut prendre du temps...)
4. quand la réponse est disponible, elle est renvoyée à l'appelant sur l'URL de retour, accompagnée du ticket correspondant
- Dans w.c.s. l'appel webservice envoie le formdata. Passerelle peut déjà générer l'URL de retour, qui sera un déclenchement d'un trigger-jump sur le formdata (nom du trigger configuré dans la ressource passerelle)
- Passerelle utilise celery (ou équivalent) pour programmer l'appel webservice
- Quand l'appel webservice est fait, passerelle déclenche le trigger sur w.c.s.
- l'appel celerisé
- authentification de part et d'autre.
Reflexion annexe: faire en sorte que le système soit générique et puisse se mettre en frontal de n'importe quelle ressource déjà existante dans passerelle.
Historique
Mis à jour par Benjamin Dauvergne il y a presque 11 ans
Je trouve ça bien mais je me sens obliger de rajouter que ça ne remplacera pas la gestion correcte des erreurs réseaux (gérer plusieurs essais avec temps d'attente exponentiel, fournir un statut d'échec, etc...) dans w.c.s. C'est chiant mais dans un système distribué c'est chaque élément qui doit gérer les défauts des autres on peut pas déporter.
Mis à jour par Thomas Noël il y a presque 11 ans
Benjamin Dauvergne a écrit :
Je trouve ça bien mais je me sens obliger de rajouter que ça ne remplacera pas la gestion correcte des erreurs réseaux (gérer plusieurs essais avec temps d'attente exponentiel, fournir un statut d'échec, etc...) dans w.c.s. C'est chiant mais dans un système distribué c'est chaque élément qui doit gérer les défauts des autres on peut pas déporter.
Yep. Dans wcs on pourrait déjà faire quasiment tout le nécessaire avec la gestion des sauts conditionnels & à expiration. Mais ça rendrait les workflow très lourds, trop lourds ; sans doute faudrait-il reprendre la discussion sur les sous-workflows.
Mis à jour par Benjamin Dauvergne il y a presque 11 ans
Pour moi ça devrait être invisible et géré par le status item concerné. Il ne faut pas exposer ce genre de tambouille dans les workflows; ça doit juste marcher par défaut. Les sous-workflow il faut garder ça pour d'autres besoins.