Rodzaje limitów czasowych w WEBCON BPS

WEBCON Redaktor Bez kategorii
Facebooktwitterpinterestlinkedinmail
Dotyczy wersji: 2022 R1 i powyżej; autor: Konrad Keppert

Dokumentacja powiązana

Szczegółowy opis funkcjonalności wymienionych w niniejszym artykule oraz ich konfiguracji można znaleźć w następujących sekcjach Pomocy WEBCON BPS:

 

Wstęp

Wydajność i responsywność są kluczowymi aspektami każdego systemu informatycznego. Ich celem jest zapewnienie użytkownikom końcowym komfortowej pracy. Zdarzają się jednak operacje trwające zbyt długo, aby spełnić to wymaganie. Może to wynikać z nieoptymalnej konfiguracji, zbyt dużej ilości danych do przetworzenia, niewystarczającej infrastruktury lub rzadziej z powodu anomalii w systemie. Z tego powodu stosowane są odgórne limity czasu wykonania poszczególnych operacji (timeout). Przynosi to kilka korzyści:

  • poinformowanie użytkownika o zbyt długim czasie trwania operacji i zakończenie czekania,
  • zwolnienie zasobów serwera,
  • zabezpieczenie przed zawieszeniem się modułu systemu.

 

WEBCON BPS nie jest wyjątkiem w tej kwestii. Niniejszy artykuł ma na celu przedstawienie tych limitów na podstawie przykładowych scenariuszy obejmujących następujące obszary:

  • automatyzacje,
  • operacje wykonywane przez serwis,
  • żądania http,
  • transakcje T-SQL,

z wyróżnieniem tych, które są konfigurowalne, a także wynikają z infrastruktury.

W artykule pominięto limity, które mogą wpływać na działanie WEBCON BPS, ale wynikają z infrastruktury rozwiązania (np. serwery proxy).

 

Akcje

Zapytania SQL

Stanowią one podstawę zdecydowanej większości operacji wykonywanych w platformie WEBCON BPS. Poza niemodyfikowalnymi zapytaniami systemowymi (przykładem może być wyszukanie danych bieżącego użytkownika czy aktualizacja liczników zadań) w wielu miejscach w WEBCON BPS Designer Studio można umieścić zapytania definiowane przez użytkowników. Te drugie mają niekonfigurowalny limit wynoszący 30 sekund.

Bez względu na to czy zapytanie zostanie umieszczone w akcji Zmień wartość pola, Aktualizuj wartości listy pozycji czy Dodaj załącznik, jeśli zapytanie SQL nie wykona się w żądanym czasie, użytkownik otrzyma komunikat błędu „The wait operation timed out”, a automatyzacja zostanie wycofana.

Łatwym do odwzorowania scenariuszem jest umieszczenie na ścieżce przejścia akcji Zmień wartość pola, w którym reguła SQL COMMAND będzie wykonywać się powyżej 30 sekund. Na potrzeby testu można wykorzystać polecenie 'WAITFOR DELAY'  jak na poniższym zrzucie.

 

Rys. 1. Konfiguracja akcji, która nie wykona się w odgórnym limicie czasu

 

W momencie, gdy użytkownik zakończy zadanie na ścieżce zawierającej tak skonfigurowaną akcję, otrzyma poniższy komunikat, przejście ścieżką zostanie przerwane, a pozostałe akcje w automatyzacji, nawet jeśli poprawnie wykonane, zostaną wycofane.

Uwaga! Wycofanie akcji w automatyzacji nie spowoduje cofnięcia zmian wprowadzonych do zewnętrznych systemów w wyniku integracji (np. wpis do SAP akcją Wywołaj REST web service).

 

Rys. 2. Komunikat informujący o przekroczeniu limitu czasowego zapytania SQL w akcji

 

Żądania http

Można je podzielić na żądania zdefiniowane przez użytkownika w akcji Wywołaj REST web service oraz na systemowe, które nie są konfigurowalne, ale są wysyłane w zależności od używanych funkcjonalności.

Wykonanie akcji Wywołaj REST web service zostanie przerwane po 100 sekundach. Operacje zakończone w taki sposób zwrócą komunikat błędu „A task was canceled”. Wszystkie limity z tej grupy są niekonfigurowalne.

Do drugiej grupy można zaliczyć integracje oparte o MS Graph, a zatem akcje OneDrive, Exchange, pobieranie danych ze skrzynek HotMailBox/MailApproval czy synchronizację użytkowników z Entra ID. Takie żądania mają limit 100 sekund. Wyjątkiem jest żądanie wysyłane do MS Graph celem uzyskania tokenu uwierzytelniającego, którego limit wykonania wynosi 120 sekund. Takie żądanie wysyłane jest do MS Graph przed nawiązaniem połączenia, np. w momencie rozpoczęcia synchronizacji użytkowników z Entra ID.

 

Automatyzacje

W konfiguracji automatyzacji znajduje się parametr Limit czasu wykonania, a w jego pomocy kontekstowej umieszczono poniższą informację:

Parametr pozwala określić czas w sekundach, po przekroczeniu którego wykonywanie automatyzacji zostanie przerwane z błędem „Execution time exceeded”.
Czas trwania automatyzacji liczony jest od rozpoczęcia jej wykonywania i jest sprawdzany przed wejściem do każdego bloczka automatyzacji (bloczka akcji lub bloczka automatyzacji procesowej).

 

Kluczowa jest informacja, że czas trwania automatyzacji sprawdzany jest przed wejściem do każdego „bloczka”. Aby przedstawić to na przykładzie, utworzono automatyzację z trzema akcjami typu Zmień wartość pola wykonującymi się 6 sekund każda, a limit czasu wykonania automatyzacji ustawiono na 10 sekund.

 

Rys. 3. Przykład automatyzacji z kilkoma akcjami i krótkim limitem czasu wykonania

 

Czasy wykonania akcji i automatyzacji sprawdzane są w następujący sposób:

  1. Przed rozpoczęciem „Akcji 1” sprawdzany jest czas trwania automatyzacji i wynosi on 0 sekund.
  2. „Akcja 1” wykonuje się w 6 sekund.
  3. Przed rozpoczęciem „Akcji 2” sprawdzany jest czas trwania automatyzacji i wynosi on 6 sekund.
  4. „Akcja 2” wykonuje się w 6 sekund.
  5. Przed rozpoczęciem „Akcji 3” sprawdzany jest czas trwania automatyzacji i wynosi on 12 sekund.
  6. Skonfigurowany limit czasu (10 sekund) został przekroczony, automatyzacja zostaje przerwana, a użytkownikowi wyświetlony zostaje komunikat błędu.

 

Rys. 4. Komunikat informujący o przekroczeniu limitu czasu wykonania automatyzacji

 

W Historii elementu widnieje informacja, że w automatyzacji na przejściu ścieżką wykonano poprawnie dwie akcje, ale trzecia zakończyła się błędem, co spowodowało rollback i uniemożliwiło zapis elementu.

 

Rys. 5. Logi przerwanej automatyzacji w historii elementu

 

Z kolei w logach „Akcji 3” znajduje się powód wystąpienia błędu: „Execution time exceeded”.

 

Rys. 6. Logi akcji przerwanej przez przekroczenie limitu automatyzacji

 

Co stałoby się, gdyby w powyższym przykładzie limit czasu wykonania automatyzacji ustawiono na 15 sekund? W momencie rozpoczęcia „Akcji 3” czas trwania automatyzacji wynosił 12 sekund, a więc mniej niż wprowadzony limit, dlatego „Akcja 3” wykonałaby się poprawnie. Oznacza to, że mimo iż wykonanie wszystkich akcji zajęłoby łącznie 18 sekund, a limit czasu wykonania automatyzacji ustawiono na 15 sekund, automatyzacja zakończyłaby się bezbłędnie.

Uwaga: limity czasu wykonania automatyzacji i akcji (opisane rozdział wcześniej) obowiązują równocześnie. Oznacza to, że przekroczenie limitu czasowego przez akcję (np. spowodowane zapytaniem SQL trwającym ponad 30 sekund) spowoduje przerwanie i wycofanie automatyzacji, nawet jeśli ta miała skonfigurowany limit, który nie został przekroczony.

 

Workflow Service

Liczba sekund na operacje wykonywane przez serwis

Parametr ten określa maksymalną liczbę sekund przeznaczoną na operacje wykonywane przez Workflow Service, czyli przede wszystkim:

  • akcje na timer,
  • akcje cykliczne,
  • obsługa HotFolderów czy HotMailBoxów (monitorowanie, startowanie elementów, dołączanie do elementu na podstawie kodów kreskowych),
  • przejście ścieżką domyślną z kroków oczekiwania na Warstwę tekstową, OCR AI i OCR AI Learn,
  • przejścia ścieżką z wykorzystaniem funkcjonalności MailApproval.

Domyślnie wynosi on 120 sekund, ale wartość można zmienić w Konfiguracji serwisu w Designer Studio. Szczegółowy zakres funkcjonalności objętych tym limitem można znaleźć w pomocy kontekstowej.

Aby przedstawić zasadę działania tego limitu, dokonano następującej konfiguracji:

  • ustawiono liczbę sekund na operacje wykonywane przez serwis na 60 sekund,
  • dodano akcję cykliczną, włączono wykonywanie w transakcji,
  • w automatyzacji umieszczono akcję Przesuń obieg (SQL),
  • akcja ma przesunąć 4 elementy, do każdego dopisując komentarz,
  • przejście ścieżką każdego elementu z osobna trwa 18 sekund.

 

Rys. 7. Przykład konfiguracji akcji wykonywanej cyklicznie

 

Łączny czas wykonania akcji to ok. 72 sekundy (4 przejścia * 18 sekund). Limit ustawiono na 60 sekund. Mimo, iż każde osobne przejście ścieżką wykonałoby się poprawnie, serwis przekroczył przydzielony mu limit i wykonywanie operacji zostało przerwane.

W logach wykonania akcji cyklicznej odkłada się informacja:

Operation was withdrawn

Zadanie zostało anulowane.

 

W tym samym miejscu, analizując pełny komunikat błędu, można znaleźć informację, że trzy z czterech przejść ścieżką zakończyły się powodzeniem, jednak limit czasu na operację został przekroczony:

Number of instances to move: 4.

Instance with an ID 220 and a number Main/2025/02/00001: moving status: Workflow instance has been updated.

Instance with an ID 206 and a number Main/2024/11/00003: moving status: Workflow instance has been updated.

Instance with an ID 205 and a number Main/2024/11/00002: moving status: Workflow instance has been updated.

The operation has timed out or the operation was canceled by an administrator or WEBCON WorkFlow Service due to a configuration change or failover.

Operation was withdrawn

 

Ze względu na wykonanie w transakcji, nastąpił rollback, a więc ostatecznie żaden element nie został zaktualizowany. Na potwierdzenie zweryfikowano, że żaden z przesuwanych elementów nie zawiera uzupełnionego komentarza.

 

Rys. 8. Efekt wycofania transakcji po przekroczeniu limitu czasu dla operacji serwisu

 

Liczba sekund na wykonanie zapytania OLAP

Zapytania OLAP (Online Analytical Processing) uruchamiane są zgodnie z harmonogramem Godzina uruchomienia aktualizacji analiz, a ich wykonanie jest potrzebne do uzyskania statystyk z kroków i obliczenia wskaźników KPI zdefiniowanych w konfiguracji procesów. Limit jest ustalony na 7200 sekund i nie jest konfigurowalny.

 

Rys. 9. Wartość parametru w Designer Studio

 

Liczba sekund na wykonanie polecenia akcji PowerShell

Jest to maksymalny czas, w jakim może być wykonana akcja Uruchom skrypt PowerShell. Limit wynosi w tym przypadku 60 sekund i nie jest konfigurowalny.

 

Rys. 10. Wartość parametru w Designer Studio

 

Po przekroczeniu tego limitu użytkownikowi zostanie wyświetlony poniższy komunikat (taki sam odłoży się w logach akcji):

Wystąpił błąd wykonania akcji Uruchom skrypt PowerShell na ścieżce. (Krok: Start, ścieżka: Wymuś timeout)

„Kanał żądania przekroczył limit czasu, próbując wysłać po 00:01:00. Zwiększ wartość limitu czasu podawaną do wywołania elementu Request lub zwiększ wartość właściwości SendTimeout w powiązaniu. Czas przeznaczony na tę operację może być częścią większego limitu czasu.

Żądanie HTTP skierowane do obiektu „http://kt01:8002/WorkFlow/WCFService” przekroczyło przydzielony limit czasu 00:01:00. Czas przydzielony tej operacji mógł być częścią dłuższego limitu czasu.”

 

Charakterystyczny komunikat błędu wynika z tego, że żądanie http zostało przekazane z WEBCON BPS Portal do WEBCON Workflow Service (który jest odpowiedzialny za wykonywanie skryptów PowerShell). Podobny komunikat można zobaczyć w przypadku przekroczenia limitu innych żądań, które Portal przekazuje do Workflow Service, np. dotyczących pobrania danych z serwisu licencji.

Uwaga! Przekroczenie limitu akcji PowerShell, mimo przerwania automatyzacji, nie powoduje przerwania działania tego skryptu na serwerze. Mimo wyświetlenia komunikatu, skrypt nadal wykonuje się w tle. Przykładem może być scenariusz, w którym skrypt dodaje w pętli kolejne wiersze do tabeli SQL i cała operacja trwa dłużej niż 60 sekund. Mimo wystąpienia błędu w WEBCON BPS po 60. sekundach, skrypt nadal będzie dodawać kolejne wiersze do tabeli.

 

Liczba sekund dla operacji SQL podczas indeksacji SOLR

Kiedy Workflow Service otrzymuje zadanie zindeksowania elementu obiegu w bazie wyszukiwania SOLR, pierwszym krokiem jest wykonanie zapytania SQL, które pobierze dane elementu (dane formularza, Listy pozycji, uprawnienia, dane załączników) z bazy danych. Następnie zaś zbuduje na ich podstawie plik XML celem wysłania go do SOLR. Parametr ten określa limit czasu na wykonanie tego zapytania SQL i domyślnie jest ustawiony na 300 sekund. Wartość można jednak zmienić.

 

Liczba sekund dla operacji podczas połączenia do serwera SOLR

Po przygotowaniu dla SOLR wymienionego wyżej pliku XML (lub plików w przypadku reindeksacji procesu lub bazy danych) usługa Workflow Service wysyła żądanie http do API SOLR, czeka na przetworzenie dokumentów (zindeksowanie) i odpowiedź z serwera SOLR. Parametr ten określa czas, jaki Workflow Service będzie czekać na odpowiedź z serwera SOLR dotyczącą poprawnego przetworzenia żądania. Domyślnie jest on ustawiony na 300 sekund. Wartość tę można zmienić.

 

Liczba sekund na wyodrębnienie tekstu z pliku załącznika (dot. wersji 2024 R1 i powyżej)

Jeśli w konfiguracji procesu zaznaczona jest opcja Indeksuj zawartość załączników w bazie wyszukiwania SOLR, oprócz danych formularza, do SOLR wysyłana jest też zawartość załącznika w formie tekstowej na potrzeby wyszukiwania. Aby było to możliwe, Workflow Service musi wyodrębnić warstwę tekstową (analogicznie jak w przypadku akcji Dodaj warstwę tekstową) z pliku załączonego do elementu obiegu. Ten parametr określa maksymalny czas na wyodrębnienie warstwy tekstowej dla jednego pliku. Jest to wartość niekonfigurowalna i wynosi 60 sekund.

W przypadku przekroczenia tego limitu w logach usługi Workflow Service oraz w kolejce indeksowania SOLR znajdzie się komunikat „Text extract timed out after 60 seconds”.

Od wersji 2024 R1 zawartość załączników indeksowana jest niezależnie od poszczególnych elementów obiegów, dlatego otrzymanie powyższego błędu nie jest jednoznaczne z tym, że dane elementu nie zostaną zaktualizowane w bazie wyszukiwania.

 

Raporty

Ładowanie danych do raportów dostępnych w aplikacjach ma niekonfigurowalny limit ustawiony na 60 sekund. Jeśli zapytanie pobierające dane nie wykona się w tym czasie, użytkownik zobaczy następujący komunikat:

 

Rys. 11. Komunikat wyświetlony użytkownikowi w przypadku błędu pobierania danych raportu

 

Zgodnie z sugestią w komunikacie, za długi czas ładowania danych odpowiedzialne mogą być nieoptymalne kolumny wyliczane, ale często problem wynika z niewydajnego SQL Servera (nieaktualne statystyki) lub zbyt dużej liczby danych do wyświetlenia.

Zapytanie SQL, które przekroczyło limit, można przechwycić w sesji diagnostycznej. Po zarejestrowaniu błędu w sesji pojawi się węzeł o nazwie „Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.”. Zawarte będą również zapytania SQL wraz z czasem ich wykonania.

 

Rys. 12. Przykład przekroczonego limitu ładowania raportu w sesji diagnostycznej wraz z zapytaniem SQL oraz czasem jego wykonania

 

Tak przechwycone zapytanie można następnie wykonać w SQL Server Management Studio i przeanalizować jego aktualny plan wykonania pod kątem wykorzystania indeksów czy aktualności statystyk. Można również poszukać optymalizacji przez usunięcie/modyfikację kolumn wyliczanych.

 

IIS

Podczas pracy w BPS Portalu przeglądarka użytkownika wysyła żądania http do serwera IIS, który jest hostem aplikacji WEBCON BPS. Serwer odpowiedzialny jest za przetwarzanie żądań i wysyłanie odpowiedzi do klienta (przeglądarki użytkownika). IIS ma swój własny, konfigurowalny limit na przetworzenie pojedynczego żądania i wynosi on 120 sekund. Jeśli przetworzenie żądania przekroczy limit, odpowiedzią serwera będzie błąd „Bad Gateway” wyświetlony użytkownikowi w przeglądarce.

Co ważne, wystąpienie błędu nie powoduje przerwania transakcji w SQL Server, jeśli została rozpoczęta przez serwer IIS. Oznacza to, że po wyświetleniu użytkownikowi komunikatu błędu, operacja nadal może wykonywać się w tle, a po odświeżeniu widoku będzie można zaobserwować wynik poprawnie zakończonej transakcji.

Aby przedstawić to na przykładzie, na ścieżce przejścia skonfigurowano 6 akcji Zmień wartość pola, każda wykonująca się 25 sekund, a limit czasu wykonania automatyzacji ustawiono na 240 sekund.

Zgodnie z informacjami z poprzednich rozdziałów:

  • wszystkie akcje wykonają się poprawnie (odgórny limit dla SQL COMMAND to 30 sekund),
  • wykonanie automatyzacji potrwa 150 sekund (6 akcji * 25 sekund) i również zakończy się powodzeniem (limit na 240 sekund).

Zatem po stronie aplikacji nie zostanie przekroczony żaden limit, który uniemożliwiłby przejście ścieżką, natomiast ze względu na limit ustawiony w IIS użytkownik otrzyma błąd „Bad Gateway” po 120 sekundach.

 

Rys. 13. Komunikat "Bad Gateway" wyświetlony użytkownikowi w przypadku przekroczenia limitu czasu żądania w IIS

 

W przypadku tego błędu w Podglądzie zdarzeń nie uda się znaleźć dodatkowych informacji. Jest to generyczny komunikat pochodzący z serwera IIS.

 

Rys. 14. "Bad Gateway" w Podglądzie zdarzeń

 

Jak wspomniano wcześniej, timeout z IIS nie powoduje przerwania transakcji SQL Server. Po zakończeniu transakcji i odświeżeniu elementu obiegu, można zaobserwować, że przejście ścieżką zakończyło się powodzeniem po ok. 150 sekundach. W Historii elementu można znaleźć informację o pomyślnym zakończeniu wszystkich operacji.

 

Rys. 15. Pomyślny zapis elementu w Historii mimo wystąpienia przekroczonego limitu przeglądarki

 

Choć „Bad Gateway” może wystąpić przy dowolnym żądaniu, które nie jest przedwcześnie przerwane przez aplikację, często obserwowanymi przypadkami wystąpienia są:

  • Eksport raportu do Excela,
  • Usuwanie obiegu/procesu w Designer Studio (mimo otrzymania błędu obiekt będzie nadal usuwany przez działającą w tle transakcję).

 

Podsumowanie

Limity czasu wykonania są przydatną funkcjonalnością, dzięki której praca użytkowników oraz usług nie jest blokowana z powodu zbyt długo trwających operacji. Odpowiednie zarządzanie limitami pozwala zwiększać responsywność aplikacji, przyspieszać przetwarzanie kolejek (przerywanie zbyt długich zadań), obsługiwać bardziej wymagające zadania (zwiększanie limitów), a znajomość i zrozumienie różnych rodzajów limitów pozwala na lepszą diagnostykę problemów.

 

Lista limitów wymienionych w artykule:

Operacja Domyślna wartość limitu w sekundach Konfigurowalność
Zapytania SQL (w akcjach) 30 Nie
Żądania http 100 Nie
Żądanie http uwierzytelniające w MS Graph 120 Nie
Akcja Wywołaj REST web service 100 Nie
Automatyzacje 30 Tak (w konfiguracji automatyzacji)
Operacje wykonywane przez serwis 120 Tak (w konfiguracji serwisu)
Wykonanie zapytania OLAP 7200 Nie
Wykonanie polecenia akcji PowerShell 60 Nie
Operacje SQL podczas indeksacji SOLR 300 Tak (w konfiguracji serwisu)
Operacje podczas połączenia do serwera SOLR 300 Tak (w konfiguracji serwisu)
Wyodrębnienie tekstu z pliku załącznika 60 Nie
Ładowanie danych raportów 60 Nie
Żądanie http do serwera IIS 120 Tak (w IIS)