Emixa Blog

Begrenzung der Anzahl von Aufrufen in Mendix (meist REST)

Geschrieben von: Minke van Dooremalen | Marketing Manager | Dec 29, 2023 2:50:22 PM

Problem

Haben Sie jemals eine Integration erstellt und als Antwort HTTP-Code 429 erhalten? Oder beschwert sich der Anbieter, dass Sie zu viele Aufrufe an sein System tätigen?

Der Antwortstatus HTTP 429 Too Many Requests zeigt an, dass der Benutzer zu viele Anfragen in einer bestimmten Zeitspanne gesendet hat ("Ratenbegrenzung").

In diesem Fall senden Sie innerhalb eines bestimmten Zeitrahmens zu viele Anrufe an den Server, und der Server verhindert, dass Sie zu diesem Zeitpunkt darauf zugreifen können. Dies geschieht hauptsächlich, um eine Überlastung der Endpunktserver zu verhindern.

Die inkrementelle Wiederholung mit einem WarteschEN-Mechanismus ist eine der Lösungen für dieses Problem, allerdings können Sie das Problem immer noch nicht in den Griff bekommen: Sie wissen immer noch nicht, wie viele Anrufe Sie pro Zeitrahmen an den Endpunkt senden.

Lösung

Manchmal hat der Anbieter die Ratenbeschränkungen für die spezifischen Endpunkte dokumentiert. In diesem Fall sollten Sie diese Grenze zu keinem Zeitpunkt überschreiten (sonst erhalten Sie wieder einen 429-Fehler).

Auf Emixa haben wir ein Modul zur Ratenbegrenzung entwickelt, mit dem Sie Mikroflüsse mit einer von Ihnen kontrollierten Ratenbegrenzung ausführen können! Der angegebene Mikrofluss wird von einer Java-Aktion mit einer internen Warteschlange zur Ratenbegrenzung ausgeführt.

Das Modul bietet nicht nur eine Lösung für eine einzelne ratenbegrenzte Integration, sondern auch für mehrere Integrationen mit unterschiedlichen Ratenbegrenzungen.

Hier herunterladen

Vereinfachtes Beispiel

Sie haben eine App, die 2 tariflich begrenzte Integrationen hat:

  1. Integration in ERP ermöglicht 30 Anrufe pro Minute = 0,5 pro Sekunde
  2. Die Integration in CRM ermöglicht 1 Anruf pro Sekunde = 1

Jenseits dieser Zahlen gibt die Website integrations ab 429 Antworten.

In diesem Fall müssen Sie alle Mikroflüsse, die einen Aufruf zur Integration ERP ausführen, und diejenigen, die zur Integration CRM aufrufen, von der Java-Aktion in dem Modul ausführen, in dem Sie den Mikrofluss ausführen möchten.

Alle Microflows, die die Integration ERP aufrufen, müssen mindestens die folgenden Einstellungen aufweisen:

  • Höchstsatz: 0,5
  • RatelimitQueue: "integrationERP" (Hier wird festgelegt, in welcher Warteschlange (und damit ratelimiting) der Mikroablauf ausgeführt wird.

Alle Mikroflüsse, die die Integration von CRM aufrufen, haben mindestens die folgenden Einstellungen:

  • Satzgrenze 1
  • RatelimitWarteschlange: "intergrationCRM"

Ratenbegrenzung

Die Aktion java akzeptiert die folgenden Parameter:

Microflow zur Ausführung
Der Microflow, der ausgeführt wird, sobald er von der Java-Warteschlange verarbeitet wurde, basierend auf dem angegebenen Limit.
 
Microflow-Parameter
Ein Parameter, den Sie an den Mikroablauf übergeben können. Wenn Sie mehrere Parameter an Ihre Mikroabläufe übergeben müssen, können Sie dies überarbeiten, um ein temporäres Objekt zu verwenden, das die verschiedenen Objekt-IDs und die erforderlichen Parameter für Ihren Mikroablauf enthält.
 
Größe begrenzen
Das Limit pro Sekunde, in dem die Mikroflüsse in der Warteschlange ausgeführt werden. Wird dieser Wert auf 1 gesetzt, wird 1 Mikrofluss pro Sekunde ausgeführt. Wird kein Grenzwert angegeben, greift die Aktion auf den Standardgrenzwert zurück, der in der Konstante "RateLimit" festgelegt ist. Die Verwendung von Konstanten ist ratsam, da Sie 1 Limit pro Integration verwenden würden.
 
Ratelimit-Warteschlange
Der Name der Warteschlange, in die die Anrufe eingefügt werden sollen.

Die Java-Aktion führt Mikroflüsse innerhalb der angegebenen Ratengrenze aus. Sie verwendet einen internen WarteschENmechanismus, bei dem das erste Element in der Warteschlange ausgeführt wird, dann wird die angegebene Zeit gewartet (basierend auf dem Limit) und das zweite Element in der Warteschlange ausgeführt. Die Java-Warteschlange ist unabhängig davon, welche Mikroabläufe ausgeführt werden sollen, so dass alle Mikroabläufe für eine Integration dieselbe Warteschlange verwenden sollten.

Dynamisches Ratelimit

Das Modul verwaltet das Ratenlimit nicht automatisch für Sie. Wenn die von Ihnen aufgerufene Integration dynamische Ratenbegrenzungen hat (wie Spotify), legen Sie eine niedrige Ratenbegrenzung fest, um HTTP-Fehler wie 429 (Zu viele Anfragen) zu vermeiden.

Eine Integration antwortet oft mit einem HTTP-Statuscode 429 und einem Retry-After-Header in dieser Antwort, der angibt, wie lange man warten muss, bevor man eine neue Anfrage stellen kann. Passen Sie Ihr Ratenlimit entsprechend dieser Meldungen an.

Beispiel

In unserem Beispiel integrieren wir zwei externe Musikplattformen mit jeweils unterschiedlichen Ratenbeschränkungen. Der Spotify-API-Dienst hat ein dynamisches Ratenlimit, das auf der Anzahl der Aufrufe innerhalb eines rollierenden 30-Sekunden-Zeitrahmens basiert. Bei unseren Tests haben wir festgestellt, dass Spotify ca. 180 Anfragen pro Minute zulässt, ohne dass der Fehler 429 auftritt. Der Discogs-API-Dienst erlaubt 60 Anfragen pro Minute.

Spotify
Unsere Künstlerdatenbank wird täglich mit neuen Informationen aktualisiert. In diesem Beispiel rufen wir einfach die grundlegenden Informationen zu den Künstlern ab:

Discogs

Nachdem wir unsere Künstlerobjekte aktualisiert haben, wollen wir die Discogs-Datenbank anhand des gefundenen Namens abfragen.

Möchten Sie mehr erfahren?

In der Technologiebranche gibt es zahlreiche Möglichkeiten, den digitalen Wandel voranzutreiben. Möchten Sie die digitale Situation Ihres Unternehmens verbessern? Und suchen Sie einen Partner, der Sie bei der Erreichung dieses Ziels unterstützen kann? Dann ist Emixa der richtige Partner für Sie. Wir übersetzen komplexe Sachverhalte in einfache, benutzerfreundliche IT-Lösungen , die Ihre digitale Transformation beschleunigen und Ihr Unternehmen auf ein höheres Niveau bringen.Zögern Sienicht, uns zu kontaktieren. Wir würden uns freuen, Sie kennenzulernen!