Wykonywanie zadań systemowych

Po co osobna usługa

Zadania systemowe, takie jak pobieranie poczty, wysyłka powiadomień, reguły okresowe czy synchronizacja z Active Directory, działają bez udziału użytkownika i często trwają długo. Dlatego AMODIT nie wykonuje ich w aplikacji webowej, która obsługuje użytkowników, tylko w osobnej usłudze Windows AMODAsynchronousService. Usługę można uruchomić na tym samym serwerze co aplikację webową albo na osobnym serwerze, żeby zadania w tle nie spowalniały pracy użytkowników.

Aplikacja webowa w IIS nie uruchamia zadań według harmonogramu. Gdy usługa nie działa, żadne zadanie systemowe się nie wykonuje, choć użytkownicy dalej normalnie pracują w AMODIT.

Jak to działa

Aplikacja webowa i usługa nie łączą się ze sobą bezpośrednio. Łączy je baza danych AMODIT: administrator zapisuje harmonogram zadania na zakładce Zadania w Ustawieniach systemowych, a usługa odczytuje go z bazy. Usługa co kilka sekund sprawdza, które zadania mają już termin, a listę zadań odświeża z bazy co minutę. Zmiana harmonogramu zaczyna więc obowiązywać najpóźniej po około minucie.

Przed startem usługa zapisuje w bazie, który serwer wykonuje zadanie. Na zakładce Zadania widać wtedy stan W trakcie z nazwą serwera. Zadanie działa z uprawnieniami użytkownika systemowego. Po zakończeniu usługa zapisuje wynik: datę, nazwę serwera i usługi, czas wykonania oraz treść błędu, jeśli wystąpił. Potem wylicza kolejny termin według harmonogramu.

Przed uruchomieniem zadań usługa sprawdza, czy wersja bazy danych pasuje do wersji usługi. Gdy nie pasuje, na przykład gdy po aktualizacji AMODIT na serwerze nie zaktualizowano bazy danych, usługa nie uruchamia zadań tej organizacji i zapisuje w logu systemowym komunikat z prośbą o aktualizację bazy w AMODIT Database Admin.

Kilka serwerów

W większej instalacji usługa może działać na kilku serwerach naraz, wszystkie z tą samą bazą. Każde zadanie wykona wtedy tylko jeden serwer: pierwszy, który zapisze w bazie, że je przejmuje. Pozostałe serwery widzą ten zapis i pomijają zadanie.

O tym, który serwer wykonuje zadanie, decyduje pole Preferowany serwer w ustawieniach zadania. Puste pole oznacza, że każdy serwer jest preferowany. Gdy pole zawiera nazwę serwera, inne serwery uruchamiają zadanie dopiero 30 minut po jego terminie, i to przy każdym terminie. Dzięki temu zadanie wykona się także wtedy, gdy preferowany serwer nie działa, ale rzadziej, niż mówi harmonogram: zadanie ustawione co 5 minut wykonuje się wtedy mniej więcej co 35 minut.

Usługa obsługuje organizacje swojej grupy serwerów, wskazanej w jej pliku konfiguracyjnym. Ma to znaczenie w instalacjach z wieloma organizacjami. W typowej instalacji z jedną organizacją jedna usługa obsługuje całą bazę. Na jednym serwerze może też działać kilka instancji usługi, na przykład dla środowiska testowego i produkcyjnego, każda z własną bazą.

Zatrzymanie usługi i przerwane zadanie

Gdy administrator zatrzymuje usługę, na przykład przed aktualizacją, usługa nie uruchamia nowych zadań i czeka do 3 minut, aż trwające zadania się zakończą. Pobieranie poczty, wyszukiwanie pełnotekstowe, reguły okresowe i synchronizacja słowników kończą wtedy bieżącą jednostkę pracy: mail, sprawę albo słownik. Kolejnej już nie zaczynają. Pozostałe zadania kończą się normalnie albo zostają przerwane razem z usługą. Zadanie przerwane razem z usługą zostaje oznaczone tak samo jak po awarii.

Gdy usługa albo serwer przestaną działać w trakcie zadania, na przykład po awarii, w bazie zostaje zapis, że zadanie wykonuje ten serwer. Zadanie wznowi tylko ten sam serwer po ponownym uruchomieniu usługi: wykona je i wtedy usunie ten zapis. Inne serwery go nie przejmą, a zakładka Zadania cały czas pokazuje stan W trakcie z nazwą tego serwera. Ekran nie ma akcji, która usuwa ten zapis.

Kluczowe rozróżnienia

• Aplikacja webowa a usługa – aplikacja webowa obsługuje użytkowników i zapisuje harmonogramy. Zadania według harmonogramu wykonuje wyłącznie usługa.
• Zatrzymane zadanie a zatrzymana usługa – zatrzymanie zadania na zakładce Zadania wyłącza tylko to jedno zadanie. Zatrzymanie usługi wstrzymuje na tym serwerze wszystkie zadania organizacji, które ta usługa obsługuje. Gdy usługa działa na kilku serwerach, pozostałe serwery dalej wykonują zadania.
• Preferowany serwer a jedyny serwer – preferowany serwer ma pierwszeństwo, ale inny serwer też wykona zadanie, 30 minut po każdym terminie. Pole nie ogranicza zadania do jednego serwera.
• Wykonaj teraz a natychmiastowe wykonanie – akcja nie uruchamia zadania od razu. Ustawia tylko Kolejny start za minutę, a zadanie uruchamia usługa, gdy odczyta nowy termin z bazy (robi to mniej więcej co minutę). Zadanie startuje więc zwykle po około minucie, najpóźniej po dwóch. Gdy usługa nie działa, zadanie wykona się dopiero po jej uruchomieniu. Gdy zadanie ma preferowany serwer, a ten serwer nie działa, inny serwer uruchomi je dopiero 30 minut po tym terminie.

Przykład

Firma ma dwa serwery aplikacyjne, A i B, z usługą na każdym. Zadanie pobierania poczty ma preferowany serwer A i harmonogram co 5 minut. Pocztę pobiera serwer A, a serwer B tylko czeka. Gdy serwer A wyłączono do konserwacji, serwer B pobiera pocztę 30 minut po każdym terminie, czyli mniej więcej co 35 minut, aż serwer A wróci do pracy.

Powiązane artykuły

• Zadania systemowe w AMODIT – za co odpowiadają zadania i gdzie szukać szczegółów.
• Zakładka Zadania – kolumny, akcje i harmonogram – co oznacza każda kolumna i pole harmonogramu.
• Dlaczego model on-premises – warianty rozmieszczenia aplikacji, usługi i bazy na serwerach.
• Konfiguracja środowiska testowego i produkcyjnego na jednym serwerze aplikacyjnym – druga instancja usługi.
• Synchronizacja z Active Directory – konto domenowe, na którym musi działać usługa przy synchronizacji z AD.