Beperking van het aantal calls in Mendix (meestal REST)

Probleem

Heb je ooit een integratie gebouwd en HTTP 429 Too Many Requests code ontvangen? Of klaagt de leverancier dat je te veel calls naar hun systeem doet?

De HTTP 429 Too Many Requests status code geeft aan dat de gebruiker te veel verzoeken in een bepaalde tijdsperiode heeft verstuurd ("rate limiting")

In dat geval stuur je te veel oproepen naar de server binnen een specifieke tijdsperiode en de server zal je op dat moment verhinderen om toegang te krijgen. Dit wordt voornamelijk gedaan om te voorkomen dat de eindpuntservers overbelast raken.

Incremental retrying met een wachtrijmechanisme is een van de solutions oplossingen voor dit probleem, maar dan nog kunt u het probleem niet aanpakken: u weet nog steeds niet hoeveel calls u per tijdsbestek naar het eindpunt stuurt.

Oplossing

Soms zal de leverancier de rate limits documenteren voor de specifieke eindpunten. In dat geval wil je die limiet op geen enkel moment overschrijden (anders krijg je opnieuw een 429-foutmelding).

Bij Emixa hebben we een rate limiting module gebouwd waarmee je microflows kunt uitvoeren met een rate limit die je zelf kunt beheren! De gespecificeerde microflow wordt uitgevoerd door een Java-actie met een interne rate limiting wachtrij

De module biedt niet alleen een oplossing voor een enkele integratie met snelheidsbeperking, maar ook voor meerdere integrations met verschillende snelheidsbeperkingen.

Hier downloaden

Voorbeeld

Je hebt een app met 2 tariefbeperkingen integrations:

1. Integratie met ERP staat 30 oproepen per minuut toe = 0,5 per seconde
2. Integratie met CRM staat 1 oproep per seconde toe = 1

Boven deze getallen geeft integrations je 429 antwoorden.

In dit geval moet je alle microflows die een oproep naar integratie ERP doen, en die naar integratie CRM, uitvoeren vanuit de Java-actie in de module waarin je de microflow wilt uitvoeren.

Alle Microflows die de integratie ERP aanroepen, hebben ten minste de volgende instellingen:

• Rate limit: 0,5
• RatelimitQueue: "integrationERP" (Dit definieert in welke wachtrij en dus ratelimiting de microflow zal worden uitgevoerd)

Alle microflows die de integratie CRM aanroepen, zullen ten minste de volgende instellingen hebben:

• Rate limit: 1
• RatelimitQueue: "integrationCRM"

Snelheidsbeperking

Dynamische ratelimiet

De module beheert de ratelimiet niet automatisch voor je. Als de integratie die je aanroept dynamische ratelimieten heeft (zoals Spotify), bepaal dan een lage ratelimiet om HTTP-fouten zoals 429 (Te veel verzoeken) te voorkomen.

Een integratie zal vaak reageren met een HTTP-statuscode 429 en een Retry-After-header in deze reactie, waarin wordt aangegeven hoe lang je moet wachten voordat je een nieuw verzoek indient. Pas je ratelimiet aan op basis van deze berichten.

Voorbeeld

In ons voorbeeld integreren we met twee externe muziekplatforms, elk met verschillende ratelimieten. De Spotify API-service heeft een dynamische ratelimiet gebaseerd op het aantal oproepen binnen een rollende periode van 30 seconden. Op basis van testen hebben we ontdekt dat Spotify ongeveer 180 verzoeken per minuut toestaat zonder de fout 429 te retourneren. De Discogs API-service staat 60 verzoeken per minuut toe.

Spotify
Onze database van artiesten wordt dagelijks bijgewerkt met nieuwe informatie. In het voorbeeld halen we eenvoudig de basisinformatie van de artiesten op:

Discogs

Nadat we onze artiestobjecten hebben bijgewerkt, willen we de Discogs-database raadplegen op basis van de gevonden naam.

Wil je meer weten?

Er zijn volop mogelijkheden om de digitale transformatie in de technologiesector te stimuleren. Wilt u de digitale staat van uw organisatie verbeteren? En bent u op zoek naar een partner die u kan helpen dit doel te bereiken? In dat geval is Emixa de juiste partner voor u. Wij vertalen complexe vraagstukken in eenvoudige, gebruiksvriendelijke IT solutions die uw digitale transformatie versnellen en uw bedrijf naar een hoger niveau tillen. Aarzelniet om contact met ons op te nemen. We ontmoeten u graag!