Stratégie de repli / nouvelle tentative

Cette rubrique explique la nécessité d'une stratégie de repli / réessai pour les demandes d'acquisition dynamique et fournit une description de haut niveau de la façon d'en implémenter une.

Contexte

Dynamic Ingest impose une limitation de débit (par compte) de deux manières:

Pas plus que les requêtes 20 (CMS API et / ou demandes d'API d'ingestion) par seconde sont autorisées
Pas plus de travaux de priorité normale simultanés 100 autorisés

Le premier n'est pas difficile à gérer dans votre application - vous pouvez simplement imposer un délai de 3 secondes ou plus entre les demandes. La seconde est plus compliquée, car il n'y a aucun moyen d'interroger directement le système pour déterminer le nombre de tâches en cours de traitement. Vous pouvez également utiliser le File d'attente basse priorité ce qui vous permettra de mettre en file d'attente plus de travaux 100.

Vous pouvez simplement attendre pendant un certain temps et réessayer les requêtes jusqu'à ce qu'elles réussissent, mais vous pouvez implémenter un système de repli / réessai plus rationnel en écoutant notifications à partir du système Dynamic Ingest et en utilisant les informations pour suivre les travaux en vol vous-même.

Une façon d'implémenter ceci serait de construire une application d'émetteur-récepteur qui soumet les requêtes d'entrée et écoute les notifications. Le diagramme ci-dessous montre la logique de haut niveau d'une telle application.

Exemple d'application

Vous pouvez trouver la source pour un échantillon Node-Express application dans ce Github repo