Harmonogram Zadań w enova365 — nocne zadanie, które przestało działać sześć tygodni temu

Sześć tygodni. Tyle nocne zadanie w enova365 potrafiło nie działać, zanim ktokolwiek się odezwał — mój osobisty rekord. Klient wcale nie był niefrasobliwy: miał kompetentnego administratora wewnętrznego, umowę serwisową z partnerem i dashboard. Nie miał tylko niczego, co zauważyłoby nieobecność.

To trzecia i ostatnia z dróg, którymi dane wychodzą z enova365. Pobieranie przez WebAPI opisałem szeroko, pozostałe dwie wymieniłem w tekście o KSeF i JPK: Harmonogram Zadań wypychający dane na zewnątrz i replika SQL tylko do odczytu, której jeszcze pożałujecie. Harmonogram zasługuje na osobny tekst, bo jako jedyny psuje się bez błędu, bez alertu i bez jednej linijki w czyjejkolwiek skrzynce.

Harmonogram działa. To nie to samo, co działająca automatyzacja

Harmonogram Zadań jest zrobiony dobrze. Wbudowany w enova365 silnik automatyzacji oparty na wyzwalaczach i akcjach; da się go skonfigurować tak, żeby wysyłał powiadomienie HTTP na zewnątrz, kiedy coś w systemie się zmieni — status dokumentu, nowa faktura, stan magazynowy przekraczający próg. Robi to, co obiecuje.

Awaria jest piętro wyżej. Realnym wynikiem zaplanowanego zadania nie jest praca, którą wykonuje, tylko twierdzenie: uruchomiło się i było dobrze. W większości instalacji, które otwieram, nikt tego twierdzenia nigdy nie sprawdził — i nie ma czym.

Jedno zastrzeżenie, zanim cokolwiek wokół tego zaprojektujecie, i od czasu przewodnika programisty nic się tu nie zmieniło: nie każda instalacja ma harmonogram skonfigurowany pod wychodzące webhooki. Funkcja jest w produkcie. Czy jest ustawiona na maszynie, z którą się integrujecie, to pytanie do administratora albo do partnera — zadajcie je przed rysowaniem architektury, nie po. A jeśli już z tego korzystacie, po Waszej stronie musi stać publicznie dostępny endpoint HTTPS. Instalacja widoczna tylko przez VPN oznacza, że najpierw czeka Was robota z routingiem.

Sukces i cisza wyglądają identycznie

Cały problem w jednym zdaniu. Z zewnątrz enova365 zadanie, które się uruchomiło i nic nie znalazło, oraz zadanie, które w ogóle nie wystartowało, zostawiają dokładnie ten sam ślad: żaden.

Oba stany są bardzo częste. W porządku jest tylko jeden. Nocne uzgodnienie faktycznie nic nie znajduje w spokojny wtorek. To samo zadanie nic nie znajduje również wtedy, gdy usługa jest zatrzymana, gdy po aktualizacji wróciło wyłączone albo gdy jego filtr po cichu przestał cokolwiek łapać. Wszystkie te przypadki są niewidoczne, jeśli jedynym sygnałem, na który patrzycie, jest pojawienie się wyniku.

Lekarstwo jest banalne i prawie nikt go nie stosuje. Każcie zadaniu raportować, co obejrzało, a nie tylko co znalazło. Uruchomienie, które mówi sprawdzono 412 dokumentów, 0 nowych, jest zdrowe. Uruchomienie, które nie mówi nic, jest pytaniem. Oba komunikaty kosztują tyle samo, a różnica w tym, co z nich wynika, jest ogromna.

Heartbeat musi mieszkać poza enova365

Monitoring trzeba tu odwrócić. Większość alertów odpala się na błędzie, a to milczące założenie, że psujący się system jest na tyle sprawny, żeby się poskarżyć. Harmonogram, który nie działa, nie zgłosi, że nie działa. Warunkiem alarmu nie może więc być błąd, tylko nieobecność.

Konkretnie: każde uruchomienie zapisuje znacznik czasu i jedno zdanie podsumowania poza ERP — do tabeli we własnej bazie, do kolejki, na endpoint monitoringu, gdziekolwiek, co i tak już utrzymujecie. Osobna kontrola, też na zewnątrz, alarmuje, kiedy ten znacznik zestarzeje się ponad interwał plus zapas. Kwadrans roboty. I różnica między tym, że dowiecie się dziś w nocy, a tym, że dowiecie się na zamknięciu miesiąca.

Zapas ustawcie rozsądnie. Za ciasny — budzicie kogoś przy każdym dłuższym imporcie. Za luźny — macie z powrotem ten sam problem, tylko z dodatkowymi krokami. Dla zadania nocnego zwykle sprawdza się interwał plus połowa.

Interwał cichej awarii

To liczba, o którą proszę, zanim cokolwiek tknę. Kosztuje jedno spotkanie.

Dla każdego zaplanowanego zadania w instalacji odpowiedzcie na dwa pytania: gdyby stanęło dziś w nocy, kto by to zauważył i kiedy? Odpowiedź podana w dniach to interwał cichej awarii tego zadania — najdłuższy czas, przez jaki mogłoby leżeć martwe, zanim ktoś natknąłby się na to przypadkiem.

Rozrzut bywa ogromny i układa się w trzy grupy. Zadania zasilające ekran, który ktoś otwiera co rano, mają interwał liczony w godzinach. Zadania zasilające raport czytany na zamknięciu miesiąca — dwa do czterech tygodni. I zawsze jest trzecia grupa, w której uczciwa odpowiedź brzmi nigdy: jedynym widocznym efektem zadania jest plik wrzucony do folderu albo rekord w tabeli, do której nikt nie zagląda, dopóki coś innego już nie poszło źle.

Wszystko powyżej tygodnia to nie automatyzacja, tylko zakład. To zdanie kończy dyskusję szybciej niż jakakolwiek propozycja monitoringu, bo przenosi rozmowę z narzędzi na ryzyko. Podpowiada też, od czego zacząć — nie od najważniejszego zadania, tylko od tego z najdłuższym interwałem.

Trzy rzeczy zabijają działające zadanie i żadna się nie zapowiada

Aktualizacja albo migracja serwera. Ta jest najczęstsza. Zadania wracają wyłączone albo ze zmienionym zachowaniem i nikt ich nie włącza z powrotem, bo nikt nie miał listy tego, co w ogóle działało. Jeśli macie wynieść z tego tekstu jeden nawyk operacyjny, wynieście tę listę — i trzymajcie ją poza systemem, który opisuje.

Zmiana poświadczeń. Zadanie uruchamia się na jakimś koncie, konto ma hasło, a hasło zmienia podczas przeglądu bezpieczeństwa ktoś, kto nie ma pojęcia, że wisi na nim nocne zadanie. Ten sam problem dostępu co opóźnienie dostępowe z tekstu o harmonogramie wdrożenia, tylko oglądany z drugiej strony i osiemnaście miesięcy później. Zadanie nie wywala się w żaden widoczny sposób. Próbuje się uwierzytelnić, dostaje odmowę i milknie.

Filtr, który przestaje łapać. Najpaskudniejszy z tej trójki, bo zadanie dalej się uruchamia i dalej raportuje sukces. Ktoś zmienia definicję pola własnego, przemianowuje typ dokumentu albo poprawia wartość słownikową — i warunek, który wybierał dwieście rekordów, wybiera zero. Dokładnie ten dryf opisałem w tekście o polach własnych: pięć minut pracy administratora, żadnego obowiązku informowania Was, a Wasza integracja jest jedyną stroną, która to kiedykolwiek zauważy. To również ten przypadek, w którym sprawdzono 412 dokumentów kontra sprawdzono 0 dokumentów powiedziałoby Wam wszystko od razu — a 0 nowych nie powiedziało nic.

Drugie uruchomienie to miejsce, w którym znikają pieniądze

Zaplanowane zadania uruchamiają się po raz drugi znacznie częściej, niż ktokolwiek to przewiduje: ponowienie po częściowej awarii, ręczne powtórzenie przez administratora, który nie był pewien, czy pierwsze przeszło, albo nałożenie się przebiegów, gdy zadanie trwa dłużej niż jego własny interwał. Jeśli praca nie jest idempotentna, każdy z tych przypadków zostawia duplikat.

Duplikaty z harmonogramu są ciche w bardzo konkretny i kosztowny sposób. Zduplikowana faktura zatrzymuje się na walidacji. Zduplikowany rozrachunek już nie — rozlicza coś, dopina się do prawdziwej należności i wypływa kilka tygodni później jako niewytłumaczalnie nadpłacony klient. Ta sama awaria, którą opisałem przy wyciągach śróddziennych w tekście o imporcie MT940, a harmonogram to drugi popularny sposób, żeby ją wyprodukować.

Zatem: każda jednostka pracy dostaje klucz naturalny, sprawdzacie przed zapisem, a nakładające się uruchomienia czynicie niemożliwymi, nie mało prawdopodobnymi. Blokada jest tańsza niż uzgadnianie.

Co powinien tu robić agent, a czego nie

Podział uprawnień z tekstu o tym, kto podpisuje układa się tutaj wyjątkowo czysto i wyjątkowo nisko na skali. Nic z tego nie wymaga prawa zapisu. Nic z tego nie wymaga kontaktu z kimkolwiek.

Na start zbudowałbym obserwatora. Trzyma oczekiwany harmonogram — które zadania, jak często, czego każde powinno było dotknąć — porównuje to z tym, co faktycznie się zgłosiło, i kładzie rozbieżność na biurko człowieka. Wyłapuje wyłączone zadanie, cichy błąd uwierzytelnienia i filtr, który przestał łapać, tej samej nocy, a nie na koniec kwartału. Czego nie może robić: naprawiać czegokolwiek samodzielnie. Włączenie z powrotem zadania, które administrator świadomie wyłączył na czas aktualizacji, to dokładnie ten rodzaj usłużności, który zamienia narzędzie monitorujące w incydent.

Jest jeszcze jedna korzyść, uboczna, ale konkretna. Kiedy coś zaczyna pilnować, czy nocne zadania się uruchomiły, przy okazji powstaje ich inwentarz — a w instalacjach żyjących od kilku lat sam ten inwentarz bywa znaleziskiem. Zadania, których celu nikt nie potrafi wyjaśnić, są częste. Dwa zadania po cichu robiące dokładnie to samo — też.

Od czego zacząłbym w poniedziałek

Spiszcie listę. Każde zaplanowane zadanie, co robi, na jakim koncie się uruchamia i jaki ma interwał cichej awarii. Popołudnie roboty, zero oprogramowania, zero budżetu.

Potem oprzyrządujcie to jedno zadanie o najdłuższym interwale, dokładnie tak, jak wyżej: heartbeat wychodzący tam, gdzie i tak już patrzycie, linijka podsumowania z tym, co obejrzano, a nie tylko z tym, co znaleziono, i alarm na nieobecność przy interwale plus połowa. Jedno zadanie, jeden tydzień. Potem będziecie wiedzieć, czy resztę warto ruszać.

Chcecie drugą opinię o własnej liście? Przyślijcie zaplanowane zadania z jednej instalacji enova365 razem z tym, co każde z nich zasila, a powiem Wam, które mogą być martwe już teraz, a nikt o tym nie wie. Pół godziny, bez opłat — napiszcie do mnie. A jak to wygląda od strony usług, opisuję tutaj: integracja enova365 z AI.