Załącznik ERP i rekord SQL opisują jeden dokument biznesowy, choć technicznie powstają w dwóch miejscach. Plik może zostać w repozytorium po błędzie transakcji bazy, a rekord może wskazywać treść, której zapis nie został ukończony. Sam czas modyfikacji nie wystarcza do połączenia obu elementów. Potrzebne są wspólny identyfikator, wersja i status nadawany przez aplikację. Rozdzielenie zadań aplikacji, SQL oraz repozytorium ułatwia analizę locków i wybór kopii, z których można przywrócić zgodny dokument bez mylenia problemu danych z działaniem infrastruktury.
Jedna faktura, dwa zapisy
Plik zawiera skan faktury, a rekord SQL przechowuje odwołanie, status i metadane potrzebne ERP. Oba elementy używają wspólnego identyfikatora operacji. Nazwa wersji, rozmiar oraz skrót pliku pomagają ustalić, czy rekord prowadzi do właściwej treści.
Sam plik w katalogu nie dowodzi, że dokument jest aktywny. Wpis w bazie również nie oznacza, że repozytorium zawiera pełny załącznik. Znaczenie dla użytkownika powstaje po związaniu obu elementów przez aplikację. Identyfikatora relacji nie można zastępować datą modyfikacji, ponieważ dwa zapisy mogą powstać niemal równocześnie.
Po przerwanym połączeniu mogą pozostać plik roboczy, niedokończona transakcja albo odwołanie do wcześniejszej wersji. Analiza wymaga tego samego oznaczenia w logu aplikacji, SQL i repozytorium. Oznaczenie prowadzi od komunikatu użytkownika do konkretnej transakcji i wersji pliku. Bez niego porównuje się przypadkowe zdarzenia zamiast jednej operacji biznesowej.
Aplikacja publikuje pełny dokument
Logika ERP określa, czy najpierw powstaje plik tymczasowy, rekord roboczy czy oba elementy w innej kolejności. Aplikacja nadaje status, obsługuje ponowienie i wybiera moment, w którym załącznik staje się widoczny. Za tę logikę odpowiada klient lub integrator utrzymujący rozwiązanie.
Bezpieczny obieg może używać statusu roboczego. Plik otrzymuje identyfikator, skrót i rozmiar, a rekord informuje o trwającej operacji. Publikacja następuje po związaniu obu stron. Gdy zapis się przerywa, użytkownik nie widzi niepełnego skanu jako poprawnego dokumentu.
Ponowienie odwołuje się do identyfikatora wcześniejszej operacji. Aplikacja kończy ją albo tworzy nową wersję zgodnie ze swoją regułą, bez bezwarunkowego nadpisania nowszego pliku. Serwer wirtualny i sieć nie określają takiego zachowania.
SQL i repozytorium pokazują różne błędy
Baza przechowuje identyfikator dokumentu, odwołanie do pliku, wersję i status operacji. Transakcja chroni zapis w SQL, lecz nie obejmuje automatycznie systemu plikowego. Log bazy może wskazać blokowaną transakcję lub nieudany zapis, ale sens zdarzenia wynika ze ścieżki aplikacyjnej.
Repozytorium przechowuje fizyczny plik, jego wersję i położenie. Plik roboczy powinien różnić się od opublikowanego, a historia nie może znikać przy zwykłym nadpisaniu nazwy. Skrót i rozmiar służą do porównania treści z metadanymi w SQL.
Błąd zapisu pliku może wynikać z konta procesu, zajętego uchwytu, ścieżki ustawionej w aplikacji albo braku miejsca na serwerze. Nie każdy taki przypadek jest awarią warstwy dyskowej. Klient lub integrator zarządza kontami, prawami do katalogów, konfiguracją bazy i regułami repozytorium.
Locki wymagają wspólnego identyfikatora
Konflikt locków pojawia się między innymi przy imporcie, równoległej edycji lub ponowieniu tej samej operacji. SQL pokazuje sesję i blokowaną transakcję. Ręczne usunięcie blokady bez związania jej z działaniem ERP może pozostawić częściowy zapis albo utracić nowsze odwołanie.
Identyfikator aplikacji łączy komunikat użytkownika, transakcję SQL i plik. Do analizy blokady nie jest potrzebna pełna treść faktury. Konieczne są status operacji i wersja załącznika. Zakres kont i dostępu ustala klient lub integrator stosownie do obowiązków związanych z ERP i danymi.
Po usunięciu przyczyny ponowienie sprawdza, czy rekord nie wskazuje już nowszej wersji. Jeżeli plik istnieje bez aktywnego wpisu, reguła aplikacji określa jego dalszą obsługę. Sama obecność pliku nie uzasadnia ręcznego dopisania relacji w SQL.
Zgodność kopii bazy i plików
G2E może dostarczyć serwery wirtualne dla aplikacji, SQL i repozytorium oraz prywatną sieć między nimi. Standardowa kopia VM w G2E powstaje co 24 godziny, a retencja wynosi 3 dni. Konta, dostęp, systemy operacyjne w przyjętym modelu, konfiguracja aplikacji, baza, repozytorium i spójność danych należą do klienta lub integratora. NSIX wykonuje tylko prace infrastrukturalne objęte uzgodnionym wsparciem.
Backup VM nie tworzy wspólnej transakcji między bazą a plikiem i nie zastępuje kopii aplikacyjnych lub SQL dobranych do ERP. Cofnięcie samej bazy może pozostawić rekord odnoszący się do pliku z innego momentu. Odzyskanie samego repozytorium tworzy odwrotną różnicę.
Przed naprawą zachowuje się potrzebne logi i listę rozbieżności. Następnie porównuje identyfikator wersji, skrót, status SQL i położenie pliku w wybranych kopiach. Po zakończeniu jedna faktura ma jeden aktywny rekord oraz zgodny załącznik, a pliki robocze są wyraźnie oddzielone. To potwierdza poprawność odtworzenia; samo uruchomienie maszyny lub udostępnienie katalogu jej nie potwierdza.