Projet

Général

Profil

Development #3090

gestion asynchrone, retour via trigger

Ajouté par Thomas Noël il y a presque 11 ans. Mis à jour il y a presque 11 ans.

Statut:
Nouveau
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
17 juin 2013
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Planning:

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

Cas d'usage w.c.s./passerelle :
  1. 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)
  2. Passerelle utilise celery (ou équivalent) pour programmer l'appel webservice
  3. Quand l'appel webservice est fait, passerelle déclenche le trigger sur w.c.s.
Le code à faire :
  • 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

#1

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.

#2

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.

#3

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.

Formats disponibles : Atom PDF