Scheduler¶
Serwer aplikacji wyposażony jest w mechanizm cyklicznego uruchamiania dowolnego kodu napisanego w C# wg określonego harmonogramu. Reguły przechowywane są w tabelach rozpoczynających się od SYS_SCHEDULER a ich struktura została wyemitowana w zgłoszeniu PR58086.
Konfiguracja schedulera¶
Aby uruchomić moduł schedulera należy w pliku smd zdefiniować następującą sekcję:
[Scheduler]
StartSchedulerService=yes <- parametr opcjonalny, jeśli go nie ma to scheduler jest włączony
Interval=1 <- co ile minut odpala się scheduler
SchedulerDatabase=esystem
SchedulerDir=libraries <- katalog na skompilowane reguły
DaysAfterRemoveHistory=7
AutoRemoveHistoryCronExpression=* * * * *
SettingParametersProcedure=SCHEDULER_SET_GLOBAL_PROCEDURE <- opis w sekcji 'Ustawienie parametrów globalnych dla automatów'
SchedulerSymbol=A <- symbol schedulera, do rozdzielania reguł do wykonania w przypadku posiadaniach uruchomianych więcej niż 1 schedulera
Parametr Interval mówi, z jaką częstotliwością (w minutach) sprawdzana jest konieczność uruchamiania poszczególnych reguł.
Parametr SchedulerDatabase wskazuje alias bazy danych w których zdefiniowano struktury niezbędne do działania schedulera. Baza danych o tym aliasie musi być zdefiniowana w sekcji Database tego samego pliku smd, gdyż moduł schedulera działa w tle bez zalogowanego żadnego użytkownika, a więc nie posiada wskazanego żadnego pliku app.
Parametr SchedulerDir wskazuje na ścieżkę, w której będą przechowywane automatycznie skompilowane biblioteki dll.
W parametrze DaysAfterRemoveHistory podajemy z ilu ostatnich dni ma być trzymana historia (domyślnie 7 dni).
W parametrze AutoRemoveHistoryCronExpression podajemy przy pomocy wyrażenia cron jak często ma być wywoływana metoda do czyszczenia historii schedulera (domyślnie codziennie o 23).
Szczegóły konfiguracji schedulera w pliku smd są dostępne pod tym linkiem.
Definiowanie reguł¶
Interfejs do definiowania reguł jest aplikacją w neosie i stanowi część projektu SENTE. W przypadku braku dostępu do definiowania reguł z nawigatora należy dodać akcję umożliwiającą pokazanie okna BROWSE obiektu SENTE.SCHEDULER.
Definiowanie reguł jest bardzo proste. Należy podać nazwę reguły i określić interwał, co ile minut reguła ma być wywoływana. Domyślnie reguła jest wywoływana 24/7, ale można to zmienić poprzez dodanie wpisów w harmonogramie wywołania reguły. Można sprawić aby reguła była aktywna tylko w określonych dniach tygodnia lub określonych dniach miesiąca. Można także zawęzić przedział godzin w ciągu doby, w których reguła jest uruchamiana.
Następnie należy napisać kod metody wykonawczej, który można edytować na drugiej zakładce. Kod będzie skompilowany i uruchomiony automatycznie. Wynik metody w postaci stringa trafi do loga historii wywołań. Jeśli metoda zgłosi wyjątek to zostanie automatycznie wywołana metoda obsługi błędu (trzecia zakładka), w której będzie można go obsłużyć. W przypadku braku takiej metody treść wyjątku zostanie zaraportowana do loga. Jeśli któraś z metod zwraca błędy kompilacji to one także trafią do loga.
Po napisaniu kodu reguły wystarczy ją aktywować. Efekty pracy reguły można śledzić w logu dostępnym w ostatniej zakładce. Logi są przechowywane przez 30 dni.
Note
Limity czasu były robione aby sztucznie przerywać reguły trwające zbyt długo. Niestety okazało się, że mechanizm ten nie potrafi ładnie przerwać wątku, który utknął w kodzie drivera firebird i np czeka na zakończenie procedury SQL. W takich przypadkach reguła może nie otrzymać czasu zakończenia i przerwać na stałe swoje wykonywanie. Dlatego użycie poniższych pól jest silnie niezalecane i prawdopodobnie mechanizm limitu czasu zostanie usunięty z schedulera.
Pole Limit czasu Pole limit czasu określa ile minut ma dana reguła na zwrócenie wyniku. Po tym czasie jeżeli reguła się nie zakończy zostanie ona zatrzymana.
Pole limit czasu alive Pole limit czasu alive określa ile minut będziemy czekać na wywołanie metody Scheduler.Alive(). Jeśli ten czas zostanie przekroczony reguła zostanie zatrzymana. Przydatne np w pętli gdzie informujemy o tym, że reguła jeszcze żyje i nie należy jej przerywać
Dostęp do metod i obiektów NEOSowych z Scheudlera
W wersji 4.6 serwera NEOS został dodany mechanizm dostępu z kodu metody wykonawczej (scheduler) do obiektów ze wszystkich załadowanych aktualnie do NEOSa projektów. Można tego używać, jednak należy przestrzegać kilka ważnych zasad:
Uwaga!
Projekty NEOSowe z których korzystamy w schedulerze muszą się kompilować!!
Uwaga!
Gdy utworzymy programowo jakiś obiekt aby dostać się np. do zaimplementowanej w nim metody to należy pamiętać aby bezwzględnie zamykać takie obiekty po zakończeniu metody. Przykład poniżej:
TEST t = new TEST();
t.MojaUlubionaMetoda();
t.Close();
Eksport reguł Schedulera do plików dbscripts¶
Od wersji Signature Helpera 5.1.14 mamy możliwość eksportowania oraz aktualizacji reguł Schedulera.
Uwaga!
Wymagane są do tego odpowiednie struktury bazodanowe dostępne w skryptach dbscripts oraz w migracjach Neosowych, które wcześniej muszą zostać wgrane na bazę danych.
Na oknie definiowania reguł schedulerowych zostały dodane 2 pola: - Sygnatura - Odpowiada za sygnatury tematów w jakich zostały wprowadzone zmiany w danej regule. - Symbol sh - Symbol po którym Signature Helper rozpoznaje czy dana reguła ma być eksportowana - później pojawia się jako nazwa pliku do którego zapisywana jest reguła.
Jeżeli chcemy aby dana reguła była eksportowana przez SH należy wypełnić pole Symbol sh. Signature Helper znajdzie takie reguły a następnie je wyeksportuje do folderu dbscripts/scheduler.
Eksportowane i aktualizowane są : - Kod metody wykonawczej - Kod metody obsługi błedu - Nazwa reguły - Grupa - Symbol schedulera - Sygnatury tematów - Symbol sh
Jeżeli tworzymy nową regułę to jest ona domyślnie nieaktywna z domyślnym harmonogramem. Jeżeli aktualizujemy regułę to zmieniane są tylko wymienione wyżej pola a reszta jest pozostawiana bez zmian.