Emixa blog

Beperking van het aantal calls in Mendix (meestal REST)

Geschreven door Minke van Dooremalen | Marketing Manager | Dec 29, 2023 2:50:22 PM

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.

Incrementeel opnieuw proberen met een wachtrijmechanisme is een van de oplossingen voor dit probleem, maar je zult het probleem nog steeds niet kunnen oplossen: je weet nog steeds niet hoeveel verzoeken je naar het eindpunt per tijdsperiode verstuurt.

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 rate-limited integratie, maar ook voor meerdere integraties met verschillende rate limits.

Hier downloaden

Voorbeeld

Je hebt een app met 2 rate-limited integraties:

  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 limieten zullen de integraties je 429-reacties geven.

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

De java actie accepteert de volgende parameters:

Microflow om uit te voeren
De microflow die wordt uitgevoerd nadat deze is verwerkt door de Java-wachtrij, gebaseerd op de gespecificeerde limiet.
 
Microflow parameter
Een parameter die je kunt doorgeven aan de microflow. Als je meerdere parameters aan je microflows moet doorgeven, kun je dit herwerken om een tijdelijk object te gebruiken dat de verschillende object-ID's en noodzakelijke parameters voor je microflow bevat.
 
Limit size
De limiet per seconde waarin de microflows in de wachtrij worden uitgevoerd. Het instellen van deze limiet op 1 zal 1 microflow per seconde uitvoeren. Als je geen limiet specificeert, zal de actie terugvallen op de standaardlimiet, gespecificeerd in de constante 'RateLimit'. Het gebruik van constanten wordt aanbevolen omdat je per integratie één limiet zou gebruiken.
 
Ratelimit wachtrij
De naam van de ratelimit wachtrij waar de oproepen aan toegevoegd zullen worden.

De Java-actie zal microflows uitvoeren binnen de gespecificeerde rate limit. Het gebruikt een intern wachtrijmechanisme waarbij het eerste item in de wachtrij wordt uitgevoerd, vervolgens wacht op de gespecificeerde tijd (gebaseerd op de limiet), en daarna het tweede item in de wachtrij uitvoert. De Java-wachtrij is agnostisch ten opzichte van welke microflows moeten worden uitgevoerd, daarom moeten alle microflows voor één integratie dezelfde wachtrij gebruiken.

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 oplossingen die uw digitale transformatie versnellen en uw bedrijf naar een hoger niveau tillen. Aarzelniet om contact met ons op te nemen. Wij ontmoeten u graag!