Project

General

Profile

Development #3090

gestion asynchrone, retour via trigger

Added by Thomas Noël over 9 years ago. Updated over 9 years ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
17 June 2013
Due date:
% Done:

0%

Estimated time:
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.

History

#1

Updated by Benjamin Dauvergne over 9 years ago

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

Updated by Thomas Noël over 9 years ago

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

Updated by Benjamin Dauvergne over 9 years ago

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.

Also available in: Atom PDF