Serwis – logika i zasady działania

WEBCON Redaktor Ogólne
Facebooktwitterpinterestlinkedinmail
Dotyczy wersji 2023 R1 i powyżej, autor: Łukasz Maciaszkiewicz

 

Wprowadzenie

Logika wykonywania zadań przez serwis jest kwestią wieloaspektową i złożoną. Niejednokrotnie, planując zadania, projektanci aplikacji nie posiadają wiedzy na temat mechanizmów i reguł, według których działa serwis. Aby uzupełnić wiedzę w tej kwestii, w niniejszym artykule opisano, jakie elementy wpływają na kolejność, w jakiej serwis wykonuje powierzone mu zadania.

 

Bazy zawartości

Bazy danych, w których zapisywane są informacje na temat zadań do wykonania, określa się w polu „Powiązane bazy procesów” (sekcja „Konfiguracja systemu” → węzeł „Konfiguracja serwisów” na drzewie wyboru po lewej stronie → pozycja „Serwisy” → nazwa serwisu → zakładka „Serwis”). Wskazane w tym miejscu bazy będą następnie przetwarzane przez serwis w jeden z opisanych poniżej sposobów.

Pole „Powiązane bazy procesów” pozwala określić bazy zawartości przetwarzane przez serwis

 

Kolejność wykonywania zadań przez serwis

Zadania, jakie wykonuje serwis, są zasadniczo porządkowane ze względu na sposób ich uruchamiania. Mogą być one wyzwalane trojako:

  • za pomocą kolejek,
  • z zastosowaniem interwału/harmonogramu,
  • poprzez polecenie wyzwolenia przesłane do serwisu z komunikującego się z nim środowiska zewnętrznego.

Wszystkie wymienione trzy sposoby uruchamiania działają równolegle względem siebie. Szczegółowy opis każdego ze sposobów uruchamiania zadań zawarto w dalszej części artykułu.

 

Kolejki

Istnieje kilka rodzajów kolejek, a każdy z nich posiada własne wątki, które w większości przypadków mogą być konfigurowane. Oznacza to, że liczba wspomnianych wątków dla każdej kolejki może zostać ustawiona w konfiguracji serwisu, o ile nie jest niekonfigurowalna, jak w przypadku akcji na timeout (1 wątek) bądź akcji cyklicznych (4 wątki). Co istotne każdy z wątków działa niezależnie, tj. jeżeli włączono role odpowiadające za różne kolejki w serwisie, a każda z nich posiada cztery wątki, wówczas wątki te działają równolegle.

Warto w tym miejscu nadmienić, że w sytuacji, gdy system dysponuje procesorem o liczbie rdzeni mniejszej niż liczba wspomnianych wątków, system operacyjny będzie przełączał zadania, starając się wykonać je wszystkie jednocześnie. Odbywa się to na tyle wydajnie, że żadne z zadań nie jest „zaniedbywane”.

Równoległe działanie wątków oznacza, że nie ma w tym przypadku mowy o kolejności jako takiej.

 

  • Przetwarzanie baz danych

W przypadku baz danych zastosowanie ma tzw. główna kolejka, czyli pojedyncze zapytanie dotyczące wszystkich kolejek jednocześnie wykonywane po stronie serwera SQL. [Obecnie istnieje możliwość podejrzenia części zapytań przesyłanych do bazy zawartości, o ile włączono tryb „Debug” („Konfiguracja systemu” → węzeł „Parametry globalne” → „Tryb logowania diagnostycznego” → „Debug”). System nie loguje przy tym zapytań przesyłanych do bazy konfiguracyjnej]. Od momentu uruchomienia serwisu zapytanie takie przesyłane jest do wszystkich baz zawartości w skonfigurowanym interwale (domyślnie co 10 s), aby ustalić, które kolejki mogą wykonywać zadania. Ponieważ zapytanie to dotyczy wszystkich baz, zwraca ono dostępne elementy do przetworzenia we wszystkich kolejkach z wszystkich baz danych. Następnie główna kolejka informuje poszczególne wątki kolejek, w których są zadania do wykonania, o możliwości wykonania zapytań przydzielających wiersze kolejki bezpośrednio do wątku konkretnej kolejki serwisu. (Należy mieć na uwadze, że wątki oznaczają w tym przypadku wątki aplikacyjne nie zaś wątki procesora). Podrzędne kolejki wykonują zapytanie przydzielające zadanie, a następnie je pobierają.

Schemat działania głównej kolejki

 

Aktywność głównej kolejki zapisywana jest w raporcie „Aktywność serwisów” (sekcja „Raporty” → węzeł „Serwis BPS WorkFlow” →  pozycja „Aktywność serwisów”). (Na przedstawionym poniżej zrzucie ekranu dostępne są dwie bazy danych: „JJ_BPS_Content_Main Roles” oraz „JJ_BPS_Content_Main2 Roles”).

Raport „Aktywność serwisów” prezentuje aktywność głównej kolejki z podziałem na obsługiwane bazy danych

 

Warto zwrócić uwagę, że dla każdego z wątków kolejek przy uruchamianiu serwisu bądź modułu losowana jest kolejność przetwarzania baz zawartości – wylosowana kolejność nie zmienia się, aż do restartu modułu kolejki. (Wylosowaną kolejność można wydedukować, śledząc operacje wykonywane w raporcie „Aktywność serwisów”). Wątek kolejki przesyła zapytanie do pierwszej w kolejności bazy zawartości i, jeżeli znajduje się w niej zadanie do wykonania, wykonuje je, a następnie przesyła kolejne zapytanie do następnej bazy danych. Po obsłużeniu wszystkich baz danych wątek od razu ponownie przesyła zapytania do baz danych o ewentualne kolejne zadania. Jeżeli jednak zapytanie nie zwróciło żadnego zadania, wówczas wątek oczekuje na główną kolejkę (interwał 10 s) i jeśli przydzieli ona jakieś zadanie kolejkom, wówczas wątek w ciągu sekundy przystępuje do przesyłania zapytań do baz danych w sposób opisany powyżej.

Wątki losują kolejność, w jakiej przeszukują bazy danych (w tym przypadku dostępne są trzy bazy danych: A, B oraz C)

 

Podsumowując, funkcją głównej kolejki jest informowanie kolejek o zadaniach znajdujących się w bazach zawartości oraz optymalizacja liczby zapytań do bazy danych.

 

  • Liczba wątków a kolejność wykonywania zadań w kolejkach

Liczba wątków to jeden z czynników, który może wpływać na moment wykonywania zadań w przypadku kolejek. Sytuacja taka może mieć miejsce, jeżeli wykonanie pewnych zadań trwa długo, a liczba dostępnych wątków jest mniejsza niż na przykład liczba akcji cyklicznych (np. 4 wątki i 5 akcji). W takim przypadku, jeżeli 4 dostępne wątki są jednocześnie zajęte przetwarzaniem 4 akcji cyklicznych, zadania przewidziane w ramach 5. akcji nie są wykonywane, dopóki jeden z wątków nie zostanie zwolniony (nie zakończy wykonywania zadań).

Kwestia ta uwydatnia się w szczególności w odniesieniu do akcji na timeout (wykonywanych przez serwis z włączoną rolą „Podstawowa funkcjonalność”), w przypadku których dostępny jest tylko 1 wątek. Wątek ten musi obsłużyć wszystkie dostępne bazy zawartości, dlatego ewentualne dłuższe wykonywanie jednej akcji na timeout skutkuje odroczeniem o odpowiedni czas wykonania innej akcji.

Mając powyższe na uwadze, należy również dodać, że zasadniczo w kolejce wykonywane są akcje bądź zadania w kolejności od najstarszej do najmłodszej w danej bazie zawartości, jeżeli nie określono ewentualnych priorytetów (co jest możliwe w przypadku niektórych akcji lub zadań, np. zadań dotyczących warstwy tekstowej, które realizowane są w kolejności: priorytet → czas utworzenia [najpierw najstarsze] → najmniejsza liczba prób wykonania).

 

Interwał

Interwał określa czas, po upływie którego wykonywane są zadania w ramach modułu niebędącego kolejką. Czas ten domyślnie wynosi 60 s, a wartość tę można zmienić, korzystając z opcji „Interwał (w sekundach)” (sekcja „Konfiguracja systemu” → węzeł „Konfiguracja serwisów” na drzewie wyboru po prawej stronie → pole „Konfiguracja” → „Interwał (w sekundach)”).

Opcja „Interwał (w sekundach)” pozwala określić interwał dla serwisu

 

Interwał ma zastosowanie do następujących modułów:

  • Wysyłka e-maili
  • Monitorowanie folderów: import plików skanera
  • Monitorowanie skrzynki e-mail/MailApproval

Specjalnym przypadkiem jest odświeżanie liczników zadań – moduł ten posiada własny niekonfigurowalny 30-minutowy interwał.

Ponadto w przypadku poniższych modułów sprawdzane jest, czy nadszedł czas uruchomienia zgodnie z ustalonym harmonogramem:

  • Powiadomienia masowe
  • Aktualizacja zastępstw
  • Pobieranie kursów walut
  • LogCleaner
  • Aktualizacje analiz OLAP
  • Indeksacja SOLR
  • Synchronizacja użytkowników
  • Oczekiwanie na warstwę tekstową, Oczekiwanie na rozpoznanie i Oczekiwanie na naukę.

Interwał serwisu jest ponadto uwzględniany przy przenoszeniu do następnego kroku dokumentów przetworzonych przez kolejkę. Sytuację tę najlepiej zobrazować przykładem, w którym w ramach kolejki tworzona jest warstwa tekstowa. W tym przypadku warstwa tekstowa generowana jest z interwałem ustalonym dla kolejki, niemniej przy przenoszeniu dokumentu zawierającego taką warstwę tekstową ścieżką do następnego kroku, np. w celu zatwierdzenia przez określoną osobę, uwzględniany będzie interwał serwisu (warstwa tekstowa nie jest tworzona ponownie).

 

  • Zasada działania interwału

Co interwał moduły uruchamiane są równolegle, a każdy z modułów posiada własny wątek (tj. jeden wątek przetwarza dany moduł – po interwale system tworzy wątek aplikacyjny dla danego modułu). W ramach wspomnianych modułów mogą działać podmoduły obsługujące konkretne bazy danych. Kolejność, w jakiej uruchamiane są wspomniane podmoduły, jest losowana podczas uruchamiania modułu. W rezultacie bazy danych przetwarzane są kolejno i po zakończeniu wszystkich zadań i upływie czasu interwału uruchamiane są ponownie w tej samej kolejności.

Jeżeli jednak wykonanie zadania przez dany podmoduł trwa dłużej niż określony interwał, podmoduł taki (na potrzeby opisu nazywany „B”) wstrzymuje wykonywanie zadań przez następny w kolejności, ewentualny podmoduł (na potrzeby opisu nazywany „C”) do momentu, aż sam zakończy zadanie.

W takiej sytuacji kolejny interwał nie jest uruchamiany do momentu zakończenia zadania przez podmoduł „B”, a następnie „C”. Po zakończeniu zadań przez wszystkie podmoduły w kolejnym interwale zostaną one uruchomione już w wylosowanej kolejności.

Skomplikowaną logikę kierującą interwałem przedstawiono na poniższym schemacie wraz z opisem.

Schemat logiki stosowanej w przypadku interwału serwisu

 

W poniższym opisie uwzględniono wyłącznie przypadek modułu 1. Moduł 2 wykonuje zadania analogicznie.

  1. W pierwszym interwale uruchamiane są dwa moduły („Moduł 1” i „Moduł 2”) zawierające po trzy podmoduły obsługujące trzy bazy danych A, B i C. W obu przypadkach kolejność przetwarzania baz danych wylosowana przy uruchomieniu modułu to A, B i C.
    1. W module 1 uruchamiany jest najpierw podmoduł dla bazy A. Wykonuje on wszystkie zadania.
    2. Uruchamiany jest następny w kolejności podmoduły dla bazy B, jednak nie jest w stanie zakończyć zadań przed upływem interwału.
    3. Podmoduł dla bazy C zostaje wstrzymany i nie jest uruchamiany w tym interwale.
  2. Rozpoczyna się drugi interwał.
    1. Uruchamiany jest podmoduł dla bazy A. Wykonuje wszystkie zadania.
    2. Podmoduł dla bazy B nie jest uruchamiany i jest pomijany.
    3. Podmoduł dla bazy C jest uruchamiany.

= równolegle podmoduł dla bazy B wykonuje zadania rozpoczęte w poprzednim interwale. Po ich zakończeniu podmoduł dla bazy C, który nie wykonał zadań w poprzednim interwale, również równolegle wykonuje swoje zadania. (Może tutaj dojść do sytuacji, w której działają dwie instancje podmodułu obsługującego bazę C). Zadania zostają zakończone.

  1. W trzecim interwale podmoduły po zakończeniu wszystkich zadań uruchamiają się zgodnie z wylosowaną kolejnością baz danych, tj. A, B i C.

 

  • Hotfoldery i hotmailboxy

Hotfoldery oraz hotmailboxy to moduły, które wykonują zadania w oparciu o interwał serwisu. Oznacza to, że pomimo, iż w obrębie zarówno hotfolderów, jak i hotmailboxów, możliwe jest ustalanie priorytetów dla poszczególnych zadań, to mają one zastosowanie wyłącznie w obrębie bazy zawartości, a zasadniczą kolejność narzuca logika interwału serwisu.

Przykładowa kolejność wykonywania zadań przez moduł „Przetwarzanie hotfolderów” obsługujący dwie bazy zawartości wygląda następująco:

  1. zdefiniowano następujące hotfoldery:
    1. baza BPS_Content_Main:
      1. HotfolderBPS_a – priorytet 2 – liczba plików w folderze: 20;
      2. HotfolderBPS_b – priorytet 1 – liczba plików w folderze: 3;
      3. HotfolderBPS_c – priorytet 3 – liczba plików w folderze: 5;
    2. baza BPS_Content_Main2:
      1. Folder_mail_a – priorytet 10 – liczba plików w folderze: 5;
      2. Folder_mail_b – priorytet 3 – liczba plików w folderze: 42
      3. Folder_mail_c – priorytet 5 – liczba plików w folderze: 8;
  1. w module „Przetwarzanie hotfolderów” dostępne są dwa podmoduły obsługujące osobne bazy zawartości: BPS_Content_Main oraz BPS_Content_Main2. Podmoduły te będą uruchamiane w kolejności wylosowanej przy uruchamianiu serwisu – na potrzeby artykułu będzie to najpierw BPS_Content_Main2 a następnie BPS_Content_Main;
  2. po upływie interwału serwisu (domyślnie 60 s) uruchamiany jest podmoduł BPS_Content_Main2:
    1. przetwarzane są 42 pliki w hotfolderze Folder_mail_b (priorytet 3);
    2. przetwarzane jest 8 plików w hotfolderze Folder_mail_c (priorytet 5);
    3. przetwarzane jest 5 plików w Folder_mail_a (priorytet 10);
  3. po zakończeniu wszystkich zadań w bazie zawartości BPS_Content_Main2 uruchamiany jest podmoduł obsługujący bazę zawartości BPS_Content_Main:
    1. przetwarzane są 3 pliki w hotfolderze HotfolderBPS_b (priorytet 1);
    2. przetwarzane jest 20 plików w hotfolderze HotfolderBPS_a (priorytet 2);
    3. przetwarzane jest 5 plików w hotfolderze HotfolderBPS_c (priorytet 3);
  4. wszystkie zadania w obu bazach zawartości zostały zakończone. Podmoduły zostaną ponownie uruchomione po upływie kolejnego interwału.

W przykładzie zwrócono uwagę na liczbę plików znajdujących się w poszczególnych hotfolderach, które są przetwarzane. Pliki takie są obsługiwane jeden po drugim i co ważne, aby podmoduł mógł przejść do następnego hotfolderu, wszystkie one muszą zostać przetworzone. Jeżeli podmoduł nie jest w stanie obsłużyć wszystkich plików do czasu upływu kolejnego interwału, nie jest on uruchamiany dopóki nie zakończy niedokończonych zadań. Wspomnianą liczbę plików można określić, korzystając z opcji „Limit plików do przetworzenia podczas iteracji” (sekcja „Konfiguracja systemu” → węzeł „Hotfoldery” → nazwa hotfolderu → zakładka „Ustawienia zaawansowane” → pozycja „Limit plików do przetworzenia podczas iteracji”). Warto nadmienić ponadto, że w przypadku ustawienia takich samych priorytetów dla dwóch lub więcej hotfolderów o kolejności wykonywania zadań system zdecyduje losowo.

Opisana powyżej logika, w tym działanie priorytetów, ma zastosowanie także do hotmailboxów.

 

Polecenia przesyłane ze środowisk zewnętrznych

Serwis może wykonywać zadania w następstwie poleceń przesłanych ze środowiska zewnętrznego. Za taką jednostronną komunikację odpowiada moduł „WCF Service”, którego działanie można podglądnąć w raporcie „Uruchomione moduły” (sekcja „Raporty” → węzeł „Serwis BPS Workflow” → pozycja „Uruchomione moduły”). W zależności od rodzaju zadania zostanie ono wykonane natychmiast niezależnie od innych wykonywanych zadań lub ewentualnie zakolejkowane.

Przykładem pierwszego typu zadań jest wysyłka wiadomości e-mail. Zadanie takie zostanie wykonane równolegle w stosunku do innych zadań wykonywanych przez serwis natychmiast po otrzymaniu polecenia ze środowiska zewnętrznego. Z kolei przykładem zadania, którego wykonanie może zostać zakolejkowane, jest synchronizacja – jeżeli nie może zostać wykonane, zadanie takie zostanie zakolejkowane.

Konfiguracja wysyłki e-mail – przykładowe zadanie wykonywane z polecenia środowiska zewnętrznego