Od wersji Comarch BI Point 2025, w celu zwiększenia bezpieczeństwa i stabilności aplikacji BI Point, wprowadzony został mechanizm limitowania liczby zapytań (tzw. rate limiting).
Wszystkie limity mogą być w pełni konfigurowane z poziomu pliku config.json, w nowo dodanej sekcji RateLimitingConfiguration. Umożliwia to dostosowanie wartości progowych do specyfiki konkretnej instalacji. W ramach tej sekcji możliwe jest zdefiniowanie m.in.: maksymalnej liczby jednoczesnych zapytań w skali globalnej, limitu zapytań przypadających na pojedynczego użytkownika wraz z okresem odniesienia (np. na minutę), zapasowego limitu zapytań dla adresów IP oraz odpowiadającego mu okna czasowego.
1. EnableMetricsCollection
Włącza (true) lub wyłącza (false) zapisywanie w logach aplikacyjnych szczegółowych statystyk dotyczących działania limiterów. Jest to przydatne do diagnostyki i monitorowania obciążenia aplikacji.
2. AuthenticatedOptions
Definiuje, jak działa limit zapytań dla każdego zalogowanego użytkownika z osobna.
- WindowSegments
Parametr techniczny określający, na ile „kawałków” dzielone jest główne okno czasowe (TimeWindowMilliseconds) w celu płynniejszego przeliczania limitu. Zmiana tej wartości jest rzadko potrzebna i zalecana dla zaawansowanych użytkowników.
- QueueLimit
Określa, ile zapytań od jednego użytkownika może maksymalnie czekać w kolejce na przetworzenie, gdy RequestLimit zostanie osiągnięty. Dopiero po zapełnieniu tej kolejki system zacznie odrzucać nowe zapytania i zwracać błąd HTTP 429 (Too Many Requests).
- RequestLimit
Główny limit zapytań dla jednego użytkownika w zdefiniowanym „oknie czasowym” (TimeWindowMilliseconds). Po przekroczeniu tej liczby, kolejne zapytania od tego użytkownika nie są od razu odrzucane, lecz trafiają do specjalnej kolejki.
- TimeWindowMilliseconds
Określa, jak długie jest „okno czasowe”, w którym liczony jest limit zapytań. Wartość podawana jest w milisekundach. Po upływie tego czasu limit się „odświeża”.
Przykład
Wartość 60000 oznacza, że limit jest liczony w oknie 1-minutowym.
- QueueProcessingOrder
Definiuje, w jakiej kolejności będą przetwarzane zapytania czekające w kolejce:
0 – Od najstarszych: Standardowe zachowanie, zapytania są przetwarzane w takiej kolejności, w jakiej przyszły.
1 – Od najnowszych: Najnowsze zapytanie z kolejki jest brane do przetworzenia jako pierwsze.
Gdy użytkownik lub system przekroczy zdefiniowany limit, jego kolejne zapytania zostaną tymczasowo zablokowane. Aplikacja zwróci błąd HTTP 429 (Too Many Requests). Po stronie interfejsu użytkownika powinien pojawić się komunikat informujący o konieczności odczekania chwili przed ponowną próbą połączenia.