Raport JEŻELI to zadanie cykliczne usługi SSJob, które nie generuje żadnego pliku raportu, tylko sprawdza warunek zapisany jako zapytanie SQL i wysyła e-mail wyłącznie wtedy, gdy warunek zostanie spełniony lub niespełniony - w zależności od konfiguracji. Uruchamia się tylko w dni robocze od poniedziałku do piątku.
Czym jest raport JEŻELI
Raport JEŻELI to jedno z zadań cyklicznych usługi SSJob, korzystające z tego samego mechanizmu konfiguracyjnego co pozostałe zadania tej rodziny - kopię bazy MSSQL, kopię aplikacji czy organizację bazy danych - a mimo to działające zupełnie inaczej niż pozostałe. Zamiast wykonywać operację na plikach czy strukturach bazy danych, raport JEŻELI sprawdza warunek logiczny i decyduje, czy w ogóle wysłać jakąkolwiek wiadomość.
Nazwa nawiązuje do klasycznej konstrukcji warunkowej znanej z programowania - zadanie testuje warunek i, w zależności od jego wyniku, podejmuje jedną z dwóch możliwych akcji: wysyła powiadomienie o spełnieniu warunku, wysyła powiadomienie o jego niespełnieniu, albo nie wysyła niczego, jeśli tak właśnie skonfigurowano dane zadanie.
Różnica względem zwykłego raportu
Warto odróżnić raport JEŻELI od standardowego raportu SSJob, mimo podobnej nazwy obu transakcji. Zwykły raport w każdym cyklu generuje plik w określonym formacie, zapisuje go tymczasowo we wskazanym folderze, a następnie wysyła mailem do odbiorców - niezależnie od tego, jakie dane ten raport zawiera.
Raport JEŻELI działa odwrotnie - nie generuje żadnego pliku ani nie korzysta z folderu tymczasowego. Zamiast tego wykonuje proste zapytanie zliczające wiersze spełniające określony warunek biznesowy, a wysyłana wiadomość to gotowy, wcześniej zdefiniowany tekst, a nie wygenerowane zestawienie danych. To zadanie bliższe monitoringowi i alertowaniu niż raportowaniu w klasycznym rozumieniu tego słowa.
Różnica ta ma też praktyczne znaczenie dla odbiorcy wiadomości. Standardowy raport trzeba samodzielnie otworzyć i przejrzeć, by ocenić, czy zawarte w nim dane wymagają jakiejkolwiek reakcji - nawet jeśli w danym cyklu wszystko wygląda prawidłowo. Raport JEŻELI odwraca tę logikę: sama treść otrzymanej wiadomości od razu informuje, jaki wynik dała weryfikacja warunku, bez konieczności analizowania żadnego załącznika ani otwierania dodatkowego pliku.
Konfiguracja w tabeli _jobs
Zadanie raportu JEŻELI korzysta z rozszerzonego zestawu pól tabeli _jobs, obejmującego zarówno pola wspólne dla większości zadań SSJob, jak i pola właściwe wyłącznie temu jednemu typowi zadania:
| Pole | Znaczenie |
|---|---|
| OSTATNIOWYKONANO | Data ostatniego poprawnego wykonania zadania |
| MAILPOWIADOMIENIE | Adresy e-mail odbiorców powiadomienia o wyniku warunku |
| CONECTIONSTRINGNAME | Łańcuch połączeniowy do bazy danych, na której wykonywane jest zapytanie |
| JEŻELI_ZAPYTANIE | Zapytanie typu SELECT COUNT decydujące o dalszym działaniu zadania |
| JEZELI_TAK | Czy wysłać powiadomienie, gdy zapytanie zwróci jakikolwiek rekord |
| JEZELI_NIE | Czy wysłać powiadomienie, gdy zapytanie nie zwróci żadnego rekordu |
| JEZELI_TAK_MAIL | Treść wiadomości wysyłanej przy spełnionym warunku |
| JEZELI_NIE_MAIL | Treść wiadomości wysyłanej przy niespełnionym warunku |
W odróżnieniu od pozostałych zadań SSJob, w konfiguracji raportu JEŻELI nie występują pola CYKLICZNOSC ani CYKLICZNOSCTYPE w takiej samej roli jak przy zadaniach utrzymaniowych - harmonogram tego zadania podlega dodatkowo twardemu ograniczeniu dni tygodnia opisanemu dalej, niezależnemu od ustawionego interwału.
Powiadomienia tylko wtedy, gdy naprawdę trzeba
Raport JEŻELI ogranicza liczbę wysyłanych e-maili do sytuacji, w których faktycznie wymagana jest reakcja odbiorcy.
Jak działa mechanizm warunku
W trakcie każdego uruchomienia usługa SSJob wykonuje zapytanie zapisane w polu JEŻELI_ZAPYTANIE na bazie danych wskazanej przez CONECTIONSTRINGNAME. Zapytanie to ma postać SELECT COUNT i zwraca liczbę wierszy spełniających zdefiniowany warunek biznesowy - może to być na przykład liczba dokumentów magazynowych oczekujących na zatwierdzenie dłużej niż ustalony próg czasowy.
Jeżeli zapytanie zwróci przynajmniej jeden pasujący rekord, o dalszym działaniu decyduje pole JEZELI_TAK - gdy jest ono ustawione na wysyłkę, na adresy z pola MAILPOWIADOMIENIE trafia wiadomość o treści zapisanej w polu JEZELI_TAK_MAIL. Jeżeli zapytanie nie zwróci żadnego rekordu, analogiczną rolę pełnią pola JEZELI_NIE i JEZELI_NIE_MAIL. Taka konstrukcja pozwala skonfigurować zadanie tak, by powiadamiało tylko o jednym z dwóch scenariuszy, o obu naraz, albo w ogóle nie wysyłało żadnej wiadomości, jeśli akurat taka jest potrzeba biznesowa.
Harmonogram dni roboczych
Istotnym ograniczeniem raportu JEŻELI, odróżniającym go od pozostałych zadań SSJob, jest wykonywanie się wyłącznie w dni robocze od poniedziałku do piątku. W soboty, niedziele i inne dni wolne od pracy zadanie nie uruchamia się w ogóle, niezależnie od ustawionego interwału cykliczności.
Ograniczenie to ma praktyczne uzasadnienie - warunki biznesowe monitorowane tym zadaniem, na przykład zaległości w obsłudze dokumentów, mają sens wyłącznie w kontekście dni, w których ktokolwiek faktycznie obsługuje system. Powiadomienie wysłane w niedzielę o zaległych zamówieniach, których i tak nikt nie przetworzy przed poniedziałkiem, nie wnosiłoby żadnej wartości, a jedynie zwiększałoby liczbę odbieranych e-maili.
To ograniczenie odróżnia raport JEŻELI od zadań utrzymaniowych opisanych w tej samej serii, takich jak odbudowa czy reorganizacja indeksów, które ze względu na czysto techniczny charakter działają identycznie każdego dnia tygodnia, niezależnie od tego, czy ktokolwiek akurat korzysta z systemu. Raport JEŻELI, jako zadanie skierowane wprost do ludzi, a nie do samej infrastruktury bazy danych, musi uwzględniać rytm pracy firmy, a nie tylko dostępność zasobów serwera.
Typowe zastosowania
Mechanizm raportu JEŻELI sprawdza się wszędzie tam, gdzie potrzebne jest powiadamianie warunkowe, oparte na stanie danych w bazie, a nie na sztywnym harmonogramie:
- Monitoring zaległych dokumentów - powiadomienie, gdy liczba niezrealizowanych zamówień lub dokumentów magazynowych przekroczy ustalony próg.
- Kontrola przeterminowanych płatności - alert wysyłany tylko wtedy, gdy w bazie pojawią się należności po terminie płatności.
- Wykrywanie błędów integracji - informacja o nieudanych synchronizacjach z systemami zewnętrznymi, wysyłana wyłącznie w przypadku faktycznego wystąpienia błędu.
- Sygnalizowanie braków magazynowych - powiadomienie magazyniera lub działu zakupów, gdy stan wybranych indeksów towarowych spadnie poniżej minimum.
We wszystkich tych przypadkach kluczową zaletą jest ograniczenie liczby wysyłanych wiadomości do sytuacji rzeczywiście wymagających uwagi odbiorcy, w przeciwieństwie do standardowego raportu wysyłanego cyklicznie niezależnie od tego, czy dane w nim zawarte są istotne.
Dobre praktyki
Kilka zasad pomaga skutecznie skonfigurować i utrzymać zadanie raportu JEŻELI:
- Precyzyjne zapytanie warunkowe - pole
JEŻELI_ZAPYTANIEpowinno jednoznacznie odzwierciedlać monitorowany warunek biznesowy, bez ryzyka fałszywych alarmów. - Jasna treść wiadomości - pola
JEZELI_TAK_MAILiJEZELI_NIE_MAILpowinny od razu wskazywać odbiorcy, jakiej reakcji się od niego oczekuje. - Rozważne ustawienie obu gałęzi warunku - w wielu przypadkach warto pozostawić wysyłkę wyłącznie w gałęzi
JEZELI_TAK, by nie zalewać skrzynek odbiorczych codziennym potwierdzeniem braku problemów. - Weryfikacja pola OSTATNIOWYKONANO - regularna kontrola tej wartości potwierdza, że zadanie faktycznie się wykonuje zgodnie z harmonogramem dni roboczych.
- Testowanie zapytania przed wdrożeniem - warto ręcznie sprawdzić działanie zapytania z pola JEŻELI_ZAPYTANIE na kilku różnych stanach danych, zanim zadanie zacznie działać automatycznie w środowisku produkcyjnym.
Zadanie to, w odróżnieniu od zadań utrzymaniowych opisanych przy okazji odbudowy i reorganizacji indeksów, nie wpływa bezpośrednio na wydajność bazy danych, tylko na jakość komunikacji między systemem a jego użytkownikami - źle skonfigurowany warunek prowadzi albo do zalewu niepotrzebnych powiadomień, albo do przeoczenia sytuacji faktycznie wymagającej reakcji.
Podsumowanie
Raport JEŻELI to nietypowe na tle pozostałych zadań SSJob narzędzie warunkowego powiadamiania, oparte na prostym zapytaniu SQL zamiast na generowaniu pliku raportu. Konfiguruje się je wierszem w tabeli _jobs, wskazując zapytanie warunkowe, treść wiadomości dla obu możliwych wyników oraz adresy odbiorców, z zastrzeżeniem, że zadanie wykonuje się wyłącznie w dni robocze.
Tam, gdzie potrzebny jest pełny, cykliczny raport z danymi niezależnie od spełnienia jakiegokolwiek warunku, właściwszym wyborem pozostaje standardowy raport SSJob, opisany osobno w poprzednim materiale tej samej serii poświęconej automatyzacji zadań StudioSystem. Oba mechanizmy - raport klasyczny i raport warunkowy - można też stosować równolegle dla różnych obszarów tej samej platformy, dobierając rodzaj powiadomienia do charakteru monitorowanych danych.