Passer au contenu principal

Inbox

Comment ça marche

Sur la plateforme, chaque projet dispose de son propre inbox URL, ressemblant à https://www.openfn.org/inbox/54804f1a-4a70-4392-97cb-1f350e98e9c8. Cette grande chaîne de nombres et de lettres s'appelle un UUID. C'est votre adresse, et l'« endroit » sur le web où vous enverrez les données pour le traitement par OpenFn si vous faites une intégration en temps réel ou « basée sur des événements ».

Votre projet sera toujours à l'écoute, et chaque fois qu'une requête HTTP est reçue à cette URL, nous répondrons avec un 202/Accepted et commençons à traiter les données envoyées soit dans le body (corps) ou les parameters (paramètres) de cette requête.

202/Accepted par rapport à 201/Created

Vous avez probablement entendu parler de 200/OK ou d'autres « codes d'état » courants, mais la différence entre un 201 et un 202 est très intéressante d'un point de vue perspective d'intégration. .

Le 201/Created signifie que nous avons terminé le traitement des données qui nous ont été envoyées par le demandeur. Habituellement, cette réponse est accompagnée d'une charge utile avec un nouvel id pour la ressource créée. Ce n'est pas ce que fait OpenFn, par contre nous envoyons un 202/Accepted indiquant que votre requête était acceptable et nous nous mettrons au travail.

:::astuce

OpenFn envoie un 202/Accepted indiquant que votre requête a passé notre validation initiale (c.à.d. que les données sont du JSON valide ou du XML analysable et que l'URL de l'inbox existe) et que nous l'avons mise en file d'attente pour traitement.

:::

En coulisses, nous avons mis en place un système de files d'attente simple et durable qui nous empêche de « laisser tomber » cet événement à quelque moment que ce soit à partir de maintenant.

  1. Nous le chargerons dans la base de données et bientôt il apparaîtra comme un nouveau « message » enregistré dans votre page « Inbox ».
  2. Nous vérifierons les triggers de tous les jobs actifs dans votre projet et si il correspond à l'un de ces triggers, nous l'enverrons dans une autre file d'attente pour le job en cours.
  3. Nous nous assurerons que votre projet est configuré correctement et que vous n'avez pas dépassé vos limites d'utilisation.
  4. Nous allons commencer à exécuter un job, qui peut lui-même faire des centaines de requêtes HTTP uniques vers d'autres points de terminaison.
  5. Et finalement, nous vous ferons un rapport sur l'état de cette exécution et bientôt elle apparaîtra comme un nouveau "run" dans votre page "Activity History".

Selon le nombre de requêtes de votre job, la quantité de données à traiter et le temps de réponse de vos autres systèmes, tout cela peut prendre un certain temps : de 200ms à 20 minutes !

Si le système qui envoie les données à OpenFn a besoin de savoir si toutes les opérations à l'étape 4 se sont terminées avec succès (qu'est-ce que vous comptez comme un succès avec ces différentes actions personnalisées, au fait?), vous devriez envisager de mettre en œuvre un modèle SAGA, par lequel, une fois tout ce traitement terminé, vous déclenchez une autre requête de retour au système initial pour rendre compte sur les tâches en aval. Cela peut être fait dans OpenFn avec Flow Triggers.

Traitement synchrone par rapport au traitement asynchrone

Sur OpenFn/platform, le traitement est asynchrone par défaut. Plusieurs flux de travaux complexes peuvent être lancés, la gestion des erreurs et les notifications se font en aval.

  1. Si vous envoyez des données à l'inbox OpenFn, vous recevrez un 202 en cas de succès (et 502 si nous n'avons pas reçu vos données/mauvaise demande).
  2. Nous le chargerons ensuite dans la base de données et bientôt il apparaîtra comme un nouveau « message » enregistré dans votre page « Inbox ».
  3. Nous vérifierons les triggers de tous les jobs actifs dans votre projet et si il correspond à l'un de ces triggers, nous l'enverrons dans une autre file d'attente pour le job en cours.
  4. Nous nous assurerons que votre projet est configuré correctement et que vous n'avez pas dépassé vos limites d'utilisation.
  5. Nous allons commencer à exécuter un job, qui peut lui-même faire des centaines de requêtes HTTP uniques vers d'autres points de terminaison.
  6. Si vous voulez ensuite renvoyer une mise à jour au système source... vous pouvez configurer un autre job pour renvoyer les requêtes et les mises à jour au système source déclencheur.

Dans OpenFn/microservice ou en utilisant des outils open-source, vous pouvez créer un système synchrone. Nous avons créé un moyen de configurer les points de terminaison des inbox comme « synchrone », ce qui signifie qu'ils garderont une connexion ouverte jusqu'à ce que la totalité du traitement ci-dessus soit terminée, puis répondent avec un 2XX, 4xx, ou 5XX. Ceci n'est pas recommandé pour les systèmes à volume élevé, mais peut être une exigence pour certaines implémentations ; l'esprit de OpenFn/microservice est de donner autant de de contrôle que possible à quiconque le déploie sur ses serveurs.