Cleanup jobs w D365FO: dlaczego standardowe zadania czyszczące przestają wystarczać

Na pytanie „czy czyścicie dane w swoim środowisku Dynamics 365 Finance & Operations” większość zespołów utrzymania odpowiada twierdząco, i wskazuje na skonfigurowane zadania czyszczące. Odpowiedź jest zgodna z prawdą i zarazem myląca: obecność działających cleanupów nie oznacza, że baza przestała rosnąć, a tym bardziej, że rośnie tylko tam, gdzie powinna. Standardowe zadania czyszczące są niezbędnym fundamentem higieny środowiska, ale mają granicę skuteczności, którą dojrzałe instalacje przekraczają niezauważenie. Ten artykuł pokazuje, gdzie ta granica przebiega, dlaczego każde podejście do czyszczenia musi zaczynać się od analizy oraz kiedy i jak sięgnąć po poziom zaawansowany: dedykowane skrypty i cykliczne zadania SQL-owe.

‍

Co daje standard: przegląd wbudowanych cleanupów

W pakiecie, w standardzie funkcjonowania F&O, dostępny jest zestaw zadań czyszczących obejmujących typowe kategorie danych technicznych i historycznych. Do tego dochodzą cleanupy z dwóch dodatkowych źródeł: modyfikacji zaimplementowanych przez partnerów Microsoftu oraz nabytych rozwiązań ISV, pakietów dołączonych do środowiska ERP, które potrafią przynosić własne mechanizmy porządkowe.

Które są zwykle skonfigurowane, a które nikt nigdy nie uruchomił

Między „dostępne” a „działające” rozciąga się jednak luka, którą warto zinwentaryzować. W typowym środowisku część cleanupów jest skonfigurowana i uruchomiona, zwykle te, które ktoś włączył przy wdrożeniu. Część istnieje, ale nigdy nie została uruchomiona: nikt nie podjął decyzji, nikt nie znał konsekwencji, temat nie miał właściciela. Dotyczy to w równym stopniu mechanizmów standardowych, co tych z modyfikacji i pudełek ISV, obecność rozwiązania w środowisku nie oznacza, że ktokolwiek je skonfigurował. Pierwszym, niemal bezkosztowym krokiem porządków jest więc audyt: które zadania czyszczące istnieją, które działają, z jakimi parametrami, i dlaczego pozostałe stoją.

‍

Punkt, w którym standard się wykłada

Nawet komplet poprawnie skonfigurowanych cleanupów ma granicę skuteczności, i wyznacza ją wolumen.

Rosnąca liczba dokumentów vs wydajność zadań czyszczących

Zazwyczaj podejście do problemu może zakończyć się uruchomieniem odpowiednich zadań, i przy umiarkowanych wolumenach to będzie w zupełności wystarczające. Ale w momencie, kiedy liczba dokumentów rośnie, standardowe cleanupy przestają dawać radę: zadanie, które ma przetworzyć dziesiątki milionów rekordów w oknie serwisowym, zaczyna się w tym oknie nie mieścić, konkurować o zasoby z procesami biznesowymi albo po prostu nie nadążać za tempem przyrostu. Efekt jest podstępny, bo niewidoczny w monitoringu: zadanie formalnie działa, raportuje sukcesy, a baza i tak rośnie, ponieważ czyszczenie przetwarza mniej, niż przybywa. Środowisko z działającymi cleanupami i rosnącym balastem to najczęstszy obraz, jaki zastajemy w analizach.

Cleanupy z modyfikacji partnerskich i pudełek ISV, pomoc czy dodatkowy problem

Mechanizmy porządkowe spoza standardu wymagają osobnej uwagi z dwóch powodów. Po pierwsze, ich zakres i parametry zna zwykle tylko autor, a autor bywa partnerem sprzed dwóch zmian dostawcy. Po drugie, same modyfikacje i rozwiązania ISV są równocześnie źródłami przyrostu danych: dokładają własne tabele i logi, których standardowe cleanupy Microsoftu nie znają i nie czyszczą. Bilans bywa więc ujemny, pudełko przynosi jeden mechanizm czyszczący i trzy nowe kategorie balastu. Dlatego inwentaryzacja z poprzedniej sekcji musi objąć cały ekosystem środowiska, nie tylko standard.

‍

Zawsze zaczynaj od analizy: tabela po tabeli na wiernej kopii produkcji

Niezależnie od tego, czy środowisko jest na etapie standardu, czy potrzebuje poziomu zaawansowanego, każde podejście do ograniczania nadmiernej konsumpcji przestrzeni bazodanowej musi zaczynać się od tego samego elementu: analizy, tabela po tabeli, wykonanej na wiernej kopii środowiska produkcyjnego.

Identyfikacja ciężaru zamiast czyszczenia na ślepo

Powód jest praktyczny: bez analizy czyszczenie jest zgadywaniem. Analiza wskazuje, gdzie elementy nadmiernej konsumpcji rzeczywiście są, gdzie leży ich ciężar, i tym samym, na którym elemencie należy położyć nacisk, żeby praca przyniosła uzysk. Bywa, że wynik zaskakuje: zespół spodziewa się problemu w dokumentach sprzedaży, a ciężar siedzi w tabeli alertów albo w logach integracji; bywa też, że dominują indeksy, a wtedy właściwą odpowiedzią nie jest żaden cleanup, lecz zupełnie inny zabieg. Analiza chroni więc przed dwoma błędami naraz: przed czyszczeniem obszarów, które nic nie ważą, i przed pominięciem tych, które ważą najwięcej.

‍

Poziom zaawansowany: dedykowane skrypty i cykliczne zadania SQL-owe

Gdy analiza pokaże, że standard nie domyka tematu, potrzebne są dodatkowe narzędzia i dodatkowa wiedza ekspercka.

Kategoryzacja rekordów i cięcie bez wpływu na operacje biznesowe

Sednem poziomu zaawansowanego nie jest „mocniejsze kasowanie”, lecz precyzja. Potrzebne jest właściwe pocięcie problemu: skategoryzowanie rekordów konkretnych tabel, co jest balastem, co podlega retencji, co jest w użyciu operacyjnym, i ich umiejętne wycięcie ze środowiska. Kluczowe ograniczenie brzmi: nie zawsze można czyścić dane z konkretnych tabel bez wpływu na operacje biznesowe, więc mechanizm czyszczący musi być zaprojektowany pod to ograniczenie, a nie wbrew niemu. W praktyce oznacza to dedykowane skrypty pisane pod konkretne tabele i konkretne reguły, tam, gdzie standard nie oferuje odpowiedniego zadania albo oferuje zbyt tępe narzędzie.

Rekurencyjność: dlaczego jednorazowe sprzątanie nie wystarcza

Drugim filarem jest forma wykonania: cykliczne, rekurencyjne zadania w postaci SQL-owej, które maksymalizują efektywność czyszczenia przy minimalnym wpływie na biznes. Iteracyjne przetwarzanie małych partii, zamiast jednej wielkiej operacji, pozwala czyścić bez blokowania środowiska i bez walki o okno serwisowe. A cykliczność odpowiada na naturę problemu: kategorie balastu przyrastają nieprzerwanie, więc jednorazowa akcja daje uzysk, który eroduje z każdym miesiącem. Trwały efekt ma tylko reguła działająca stale, czyszczenie jako proces, nie projekt.

‍

Podział pracy: co klient zrobi sam, a gdzie potrzebna wiedza ekspercka

Uczciwy podział wygląda tak. Po stronie zespołu klienta w pełni wykonalne są: audyt i uruchomienie standardowych cleanupów z rozsądnymi parametrami, inwentaryzacja mechanizmów z modyfikacji i ISV oraz cykliczne monitorowanie rozmiarów. To praca, której nie warto zlecać na zewnątrz, i której my jako partner nie chcemy wykonywać za klienta, bo naszym celem jest ograniczenie kosztów i ryzyka, a nie realizowanie operacji, które organizacja wykona własnym sumptem. Wiedza ekspercka staje się potrzebna tam, gdzie rośnie ryzyko i złożoność: przy analizie ciężaru i interpretacji jej wyników, przy projektowaniu dedykowanych skryptów dla tabel, których standard nie obsługuje, oraz przy budowie cyklicznych zadań SQL-owych działających bez wpływu na operacje. Możemy wspomóc klientów w napisaniu takich skryptów albo w dołączeniu naszego rozwiązania, w którym rekurencyjne joby mają postać SQL-ową, granicę zaangażowania wyznacza zawsze cel, nie billing

‍

‍

‍