Rewizja zmian danych to mechanizm audytowy platformy StudioSystem, który dla tabel oznaczonych w skorowidzu RVZN automatycznie zapisuje historię zmian pól w tabeli _revision - ze starą i nową wartością, datą zapisu oraz loginem osoby, która dokonała zmiany. Uruchamia się przy każdej edycji przez standardowe transakcje takie jak j_insert_update.
Jak działa rewizja zmian
Zmiany danych w StudioSystem najczęściej zapisywane są przez uniwersalne transakcje edycji j_insert_update i h_insert_update, wspólne dla wielu formularzy platformy. Rewizja nie jest osobnym modułem obok nich - jest dodatkowym krokiem wykonywanym w tle w momencie zapisu, o ile tabela docelowa została do tego wyznaczona.
Przy każdym zapisie program sprawdza, czy edytowana tabela znajduje się na liście tabel podlegających audytowi. Jeśli tak, uruchamiana jest automatyczna funkcja zapisująca historię zmian - bez udziału programisty i bez modyfikacji formularza, z którego korzysta użytkownik. Włączenie audytu dla kolejnej tabeli sprowadza się więc do zmiany konfiguracji, a nie do zmiany kodu.
To rozróżnienie ma znaczenie praktyczne przy wdrożeniu. Zespół wdrożeniowy nie musi przewidywać z góry, które tabele w przyszłości będą wymagały śledzenia zmian - decyzję można podjąć później, w dowolnym momencie eksploatacji systemu, bez ryzyka związanego z modyfikacją działającego kodu formularzy. Jedynym warunkiem jest to, aby zmiana danych przechodziła przez standardową transakcję edycji, a nie na przykład przez bezpośredni import danych z pominięciem warstwy aplikacji.
Konfiguracja - skorowidz RVZN
Decyzję o tym, które tabele mają być śledzone, podejmuje się w skorowidzu RVZN, dostępnym z poziomu pozycji Skorowidze w module administratora. Dodanie aktywnej pozycji ze wskazaniem nazwy tabeli włącza dla niej rewizję - bez dodatkowych ustawień po stronie samej tabeli.
Przykładowo, aby kontrolować zmiany zapisywane w tabeli KNKON, przechowującej kartoteki kontrahentów, wystarczy dodać w skorowidzu RVZN definicję wskazującą tę tabelę. Od tego momentu każda zmiana wprowadzona przez transakcję insert_update w rekordach KNKON zostanie automatycznie odnotowana.
Wyłączenie audytu przebiega równie prosto - dezaktywacja pozycji w skorowidzu RVZN zatrzymuje zapisywanie nowych wpisów, nie usuwając przy tym historii już zgromadzonej w tabeli _revision.
Konfiguracja bez zmian w kodzie
Włączenie audytu dla kolejnej tabeli to jedna pozycja w skorowidzu, nie zmiana w formularzu ani w bazie danych.
Struktura tabeli _revision
Każda odnotowana zmiana pola trafia do tabeli _revision jako osobny wiersz. Rewizja zapisuje komplet informacji potrzebnych do odtworzenia, co się zmieniło, kto to zrobił i kiedy:
| Kolumna | Znaczenie |
|---|---|
NRIDREV | Unikalny identyfikator rewizji |
TABELA | Nazwa tabeli bazy SQL, która była poddawana rewizji |
REFNO | Identyfikator wiersza (rekordu) w tabeli, wskazuje edytowaną pozycję |
REVCOLUMN | Nazwa kolumny bazy danych, która była zmieniana |
OVALUE | Dotychczasowa (stara) wartość - przed zmianą |
NVALUE | Nowa wartość zapisana po zmianie |
KIEDY | Data i czas wykonania zapisu zmian |
LOGIN | Login użytkownika, który dokonał zmiany |
BAZA | Nazwa połączenia do bazy, w której wykonano zapis |
CAPTION | Etykieta pola formularza powiązana ze zmienioną kolumną |
Warto zwrócić uwagę na ziarnistość zapisu: rewizja nie kopiuje całego rekordu przed i po zmianie, tylko odnotowuje pojedyncze zmienione pole. Przy edycji kilku pól naraz w tabeli _revision pojawi się tyle wierszy, ile pól zostało faktycznie zmienionych - wszystkie ze wspólnym numerem NRIDREV, co pozwala je później zgrupować jako jedną operację edycji.
Przykład - zmiana danych kontrahenta
Załóżmy, że w skorowidzu RVZN aktywowano audyt dla tabeli KNKON. Operator otwiera kartotekę kontrahenta i zmienia dwa pola: nazwę pełną na KLIENT B2B oraz NIP na 7791010701, po czym zapisuje formularz przyciskiem ZAPISZ.
Program sprawdza skorowidz, stwierdza, że tabela KNKON podlega rewizji, i zapisuje w tabeli _revision historię wyłącznie tych dwóch pól, które faktycznie się zmieniły:
| REVCOLUMN | OVALUE | NVALUE | KIEDY | CAPTION |
|---|---|---|---|---|
| NAZWA | KLIENT B1 | KLIENT B2B | 2016-07-01 13:25:41 | Nazwa pełna |
| NIP | 4654656564 | 7791010701 | 2016-07-01 13:25:41 | NIP |
Oba wiersze dzielą ten sam numer rewizji NRIDREV i ten sam REFNO, wskazujący edytowany rekord kontrahenta. Zestawienie takie jak powyższe wystarczy do udzielenia odpowiedzi na klasyczne pytanie kontrolne: kto, kiedy i na jaką wartość zmienił dany zapis.
Rewizja przy wielu bazach danych
Wdrożenia korzystające z więcej niż jednej bazy danych SQL Server - na przykład osobnej bazy dla danych niestandardowych klienta - też są objęte mechanizmem. Służy do tego kolumna BAZA, zapisująca nazwę połączenia, z którego pochodziła zmiana: domyślnie SoftwareStudioConnectionString, a w razie potrzeby dodatkowe CustomConnectionString.
Dzięki temu jedna wspólna tabela _revision może gromadzić historię zmian z kilku źródeł danych jednocześnie, bez ryzyka pomylenia, z której bazy pochodzi dany wpis - kolumna BAZA jednoznacznie to rozstrzyga przy każdym zapytaniu raportowym.
Praktyczne zastosowania
Najczęstszym powodem włączania rewizji jest potrzeba wyjaśnienia spornej zmiany danych - na przykład rozbieżności w danych kontrahenta, które ktoś zauważa dopiero tygodnie po fakcie. Zamiast pytać po kolei każdego, kto mógł mieć dostęp do formularza, wystarczy jedno zapytanie do tabeli _revision filtrujące po TABELA i REFNO.
- Kartoteki podstawowe - kontrahenci, towary i inne słowniki, gdzie błędna zmiana wpływa na wiele powiązanych dokumentów.
- Dane cennikowe - śledzenie, kto i kiedy zmienił warunki handlowe zapisane w bazie.
- Zgodność i kontrola wewnętrzna - gotowy ślad audytowy bez konieczności budowania własnego mechanizmu logowania.
- Diagnostyka błędów zgłaszanych przez użytkowników - szybkie ustalenie, czy problem wynika ze zmiany danych, czy z błędu aplikacji.
Decyzja, które tabele objąć rewizją, warto podejmować selektywnie. Włączenie audytu dla każdej tabeli w systemie generuje dużą liczbę wpisów w _revision i utrudnia znalezienie w niej tego, co rzeczywiście istotne - w praktyce sprawdza się ograniczenie mechanizmu do kartotek podstawowych i danych o największym znaczeniu biznesowym, których strukturę opisano szerzej w materiale o dokumentacji struktury bazy danych.
Typowy scenariusz wygląda tak: dział księgowości zgłasza, że warunki płatności zapisane przy kontrahencie różnią się od ustaleń handlowych sprzed miesiąca. Bez rewizji jedyną drogą jest przepytanie kolejnych osób, które mogły mieć dostęp do kartoteki, co przy większym zespole handlowym potrafi zająć więcej czasu niż samo wyjaśnienie sprawy. Z włączoną rewizją administrator uruchamia jedno zapytanie do tabeli _revision filtrujące po numerze kontrahenta i od razu widzi, kto, kiedy i na jaką wartość zmienił dane pole - łącznie z ewentualną serią kolejnych korekt, jeśli wartość była poprawiana kilkukrotnie.
Czego rewizja nie rejestruje
Mechanizm ma jasno określony zakres, o którym warto wiedzieć przed założeniem, że zastąpi on pełny audyt bazy danych. Rewizja obejmuje wyłącznie zmiany wartości pól wykonane standardowymi transakcjami edycji - dodanie nowego rekordu ani jego usunięcie nie generują wpisu w tabeli _revision. Nie są też rejestrowane zmiany wykonane bezpośrednio na bazie danych, z pominięciem warstwy aplikacji, na przykład ręcznym zapytaniem UPDATE uruchomionym z poziomu narzędzia administracyjnego.
Dla większości scenariuszy biznesowych - wyjaśnienia spornej zmiany wartości pola przez użytkownika - ten zakres jest wystarczający. Tam, gdzie potrzebny jest pełny ślad również dla operacji dodawania i usuwania rekordów, warto rozważyć uzupełnienie rewizji o dodatkowe mechanizmy na poziomie samej bazy danych.
Warto też pamiętać o praktycznej konsekwencji włączenia audytu dla tabeli o bardzo wysokiej częstotliwości zapisów, na przykład stanów magazynowych aktualizowanych przy każdej transakcji. Tabela _revision rośnie wtedy szybko, a przeszukiwanie jej historii staje się wolniejsze. Z tego powodu rewizję warto włączać świadomie - dla kartotek zmienianych relatywnie rzadko, gdzie liczy się możliwość wyjaśnienia pojedynczej zmiany, a nie dla tabel transakcyjnych zmienianych setki razy dziennie.
Podsumowanie
Rewizja zmian danych to lekki, konfigurowalny mechanizm audytowy: włączenie sprowadza się do jednej pozycji w skorowidzu RVZN, a każda kolejna zmiana pola w oznaczonej tabeli trafia automatycznie do tabeli _revision ze starą i nową wartością, datą, loginem i czytelną etykietą pola.
To rozwiązanie sprawdza się przy wyjaśnianiu spornych zmian w kartotekach podstawowych i danych cennikowych, natomiast nie zastępuje pełnego audytu operacji dodawania i usuwania rekordów ani zmian wykonanych z pominięciem standardowych transakcji edycji.