Naprawa zerwanej integracji między sklepem a systemem firmowym

Działało miesiącami, nagle przestało

Integracja, która pracowała bez zarzutu i nagle przestała synchronizować dane, ma zwykle jedną konkretną przyczynę. Diagnoza polega na ustaleniu, co zmieniło się po którejś ze stron — bo samo połączenie nie psuje się bez powodu.

Najczęstsze przyczyny

• Aktualizacja jednego z systemów, która zmieniła sposób wymiany danych.
• Zmienione hasło do konta używanego przez integrację.
• Wygasły klucz dostępu albo certyfikat.
• Zmiana adresu serwera po przenosinach albo po przebudowie sieci.
• Zapełniona przestrzeń dyskowa zatrzymująca zapis po stronie odbiorczej.
• Zablokowany port po zmianach na urządzeniu brzegowym.

Pierwsze pytanie

Co zmieniało się w ostatnich dniach — po stronie sklepu, systemu firmowego, sieci albo hostingu. Odpowiedź na to pytanie skraca diagnozę bardziej niż jakiekolwiek narzędzie.

Ciche zerwanie

Najgroźniejszy wariant: integracja przestaje działać, ale nikt nie dostaje o tym informacji. Rozbieżność narasta dniami, a wychodzi przy pierwszym niezrealizowanym zamówieniu. Dlatego konfigurujemy powiadomienie o braku synchronizacji — cisza musi być sygnałem, nie stanem normalnym.

Nadrobienie zaległości

Po naprawie sprawdzamy, co nie przeszło w czasie przerwy, i uzupełniamy to ręcznie albo powtórnym przesłaniem. Samo przywrócenie połączenia nie odzyskuje danych z okresu awarii.

Po naprawie

Ustalamy, jak uniknąć powtórki: osobne konto dla integracji z hasłem, którego nikt nie zmienia przy okazji, oraz zapis terminów wygasania kluczy.

Różne warianty zerwanej synchronizacji

Awaria integracji nie zawsze oznacza całkowity brak wymiany danych. Czasem zamówienia trafiają do systemu firmowego, ale nie wracają informacje o ich realizacji. W innym wariancie aktualizują się stany magazynowe, lecz ceny pozostają niezmienione. Może też działać przesyłanie nowych kartotek, podczas gdy modyfikacje istniejących produktów są pomijane. Rozpoznanie kierunku i rodzaju brakujących danych pozwala zawęzić obszar diagnozy.

Problem może dotyczyć tylko części asortymentu. Przyczyną bywają nietypowe znaki w nazwie produktu, brak wymaganego pola, zmieniony symbol magazynu albo niezgodny sposób identyfikowania towaru. Identyfikator to unikalna wartość, dzięki której oba systemy rozpoznają ten sam produkt. Jeżeli po jednej stronie towar jest wskazywany symbolem, a po drugiej innym numerem, aktualizacja może zostać odrzucona lub przypisana do niewłaściwej kartoteki.

Osobnym wariantem są opóźnienia. Dane przechodzą, ale pojawiają się w systemie docelowym znacznie później niż wcześniej. Wtedy sprawdzana jest kolejka zadań, czyli lista operacji oczekujących na wykonanie. Rosnąca kolejka może wskazywać na błąd pojedynczego dokumentu, niedostępność usługi albo zbyt długie przetwarzanie odpowiedzi. Nie jest to jeszcze całkowite zerwanie, lecz bez reakcji może doprowadzić do zatrzymania całej wymiany.

Jak przebiega rozdzielenie problemu na etapy

Najpierw ustala się, czy dane opuszczają system źródłowy. Następnie sprawdza się, czy docierają do mechanizmu pośredniczącego i czy system docelowy je przyjmuje. Taki podział zapobiega przypadkowemu zmienianiu kilku konfiguracji naraz. Jeżeli sklep poprawnie przygotował zamówienie, ale system firmowy odrzucił je podczas zapisu, naprawy wymaga inny etap niż w sytuacji, gdy sklep w ogóle nie rozpoczął wysyłki.

Pomocne są logi, czyli techniczne dzienniki zdarzeń zapisywane przez aplikację, serwer lub moduł integracyjny. Log może wskazać godzinę błędu, rodzaj wykonywanej operacji i odpowiedź drugiego systemu. Sam komunikat nie zawsze podaje gotową przyczynę. Informacja o braku autoryzacji może oznaczać błędne dane konta, wygaśnięcie klucza albo odebranie kontu wymaganych uprawnień. Dlatego zapis błędu jest zestawiany z ostatnimi zmianami i zachowaniem obu systemów.

Sprawdzana jest także komunikacja sieciowa. DNS, czyli mechanizm zamieniający nazwę serwera na jego adres sieciowy, może nadal kierować integrację pod nieaktualny adres. Zapora sieciowa może blokować połączenie po zmianie reguł. Certyfikat, czyli cyfrowe potwierdzenie tożsamości usługi i zabezpieczenie transmisji, może być nieważny lub niedopasowany do używanej nazwy. Każdy z tych przypadków może wyglądać dla użytkownika tak samo, mimo że wymaga innej korekty.

Co trzeba zabezpieczyć przed ponownym przesłaniem danych

Przed uruchomieniem zaległej synchronizacji trzeba ustalić, czy operacja jest odporna na powtórzenia. Oznacza to sprawdzenie, czy ponowne wysłanie tego samego zamówienia zaktualizuje istniejący zapis, czy utworzy drugi dokument. Bez tej kontroli masowe wznowienie może spowodować duplikaty zamówień, rezerwacji magazynowych, klientów albo dokumentów sprzedaży.

Weryfikowane są znaczniki przetworzenia, numery zewnętrzne dokumentów oraz zakres czasu objęty awarią. Znacznik przetworzenia to informacja zapisana przez integrację, że konkretny rekord został już obsłużony. Jeżeli oznaczenie nie odpowiada rzeczywistemu stanowi, część danych może zostać pominięta albo przesłana ponownie. Najpierw wykonuje się kontrolowaną próbę na ograniczonym zestawie danych, a dopiero po sprawdzeniu wyniku uruchamia pozostałe operacje.

Ważna jest też kolejność. Niektóre dane zależą od innych: kartoteka produktu powinna istnieć przed zapisaniem pozycji zamówienia, a kontrahent przed wystawieniem dokumentu przypisanego do jego konta. Przesłanie zaległości bez zachowania zależności może przywrócić komunikację, ale pozostawić niekompletne dokumenty. Po wznowieniu porównuje się więc nie tylko liczbę operacji, lecz również zawartość najważniejszych rekordów.

Błędy podczas samodzielnych prób naprawy

Częstą próbą jest wielokrotne ręczne uruchamianie synchronizacji. Jeżeli poprzednie zadanie nadal pracuje albo zatrzymało się po częściowym zapisie, kolejne uruchomienia mogą zwiększyć kolejkę i utrudnić ustalenie pierwotnego błędu. Bezpieczniej najpierw sprawdzić stan bieżącego procesu oraz potwierdzić, które dane zostały już przyjęte.

Ryzykowna jest także zmiana hasła głównego konta administratora i wpisanie go do integracji. Konto integracyjne powinno mieć wyłącznie uprawnienia potrzebne do wymiany danych. Ogranicza to skutki pomyłki oraz ułatwia rozpoznanie operacji wykonywanych automatycznie. Hasło nie powinno być przesyłane w zwykłej wiadomości ani zapisywane w publicznie dostępnej instrukcji. Dostęp do konta jest potrzebny tylko wtedy, gdy bez niego nie można przeprowadzić konkretnej kontroli, a cel użycia powinien zostać wyjaśniony.

Innym błędem jest wyłączanie weryfikacji certyfikatu, reguł zapory lub innych zabezpieczeń tylko po to, aby połączenie zaczęło działać. Taki test może chwilowo wskazać obszar problemu, lecz nie powinien stawać się rozwiązaniem docelowym. Należy poprawić certyfikat, nazwę serwera albo właściwą regułę dostępu, a następnie pozostawić mechanizmy ochronne aktywne.

Nie należy też usuwać całej kolejki błędów bez zapisania jej zawartości. Znajdują się w niej informacje potrzebne do odtworzenia zakresu awarii. Podobnie przed aktualizacją wtyczki, modułu lub programu integracyjnego warto zachować konfigurację i sprawdzić zgodność wersji. Aktualizacja wykonywana w ciemno może zastąpić jeden problem innym oraz zatrzeć ślady potrzebne do diagnozy.

Kiedy przyczyna leży poza samą integracją

Brak nowego zamówienia w systemie firmowym nie zawsze oznacza przerwanie połączenia. Zamówienie może mieć status, którego reguła eksportu celowo nie obejmuje. Może również oczekiwać na płatność, potwierdzenie albo ręczną akceptację. W takim przypadku mechanizm działa zgodnie z konfiguracją, a wyjaśnienia wymaga warunek uruchamiający wymianę.

Nieaktualny stan magazynowy może wynikać z rezerwacji, dokumentu pozostawionego w buforze albo przypisania sklepu do innego magazynu. Bufor oznacza roboczy zapis, który nie został jeszcze zatwierdzony i może nie wpływać na stan dostępny dla sklepu. Podobnie błędna cena nie musi być skutkiem awarii komunikacji. Źródłem może być inny cennik, promocja, indywidualny poziom cenowy lub zaokrąglenie wykonywane dopiero po stronie sklepu.

Jeżeli błędne dane docierają regularnie i bez opóźnień, połączenie prawdopodobnie działa, a problem dotyczy mapowania. Mapowanie to zestaw reguł określających, które pole jednego systemu odpowiada polu w drugim. Zmieniona stawka, jednostka miary, sposób zapisu wariantu albo nowa wartość statusu może wymagać uzupełnienia tych reguł, nie naprawy transmisji.

Dodatkowe pytania dotyczące awarii integracji

Czy można pracować w systemach podczas diagnozy?

Zależy to od rodzaju usterki. Jeżeli wymiana została bezpiecznie zatrzymana, bieżąca sprzedaż może być rejestrowana, ale trzeba jasno oznaczyć dane powstałe podczas przerwy. Gdy istnieje ryzyko duplikowania dokumentów lub błędnej rezerwacji stanów, konieczne może być czasowe ograniczenie wybranych operacji. Zakres ustala się po sprawdzeniu, co integracja zdążyła wykonać.

Czy połączenie można po prostu skonfigurować od początku?

Ponowna konfiguracja może być właściwa, jeśli ustawienia są uszkodzone albo nie odpowiadają aktualnym usługom. Nie powinna jednak poprzedzać zabezpieczenia logów i kopii konfiguracji. Utworzenie połączenia od nowa bez zachowania identyfikatorów może sprawić, że wcześniej przesłane rekordy zostaną potraktowane jako nowe.

Jak rozpoznać moment rozpoczęcia awarii?

Porównuje się czas ostatniej poprawnej operacji z pierwszym błędem zapisanym w logach. Sprawdzane są również ostatnie prawidłowe zamówienia, aktualizacje stanów i dokumenty utworzone w systemie firmowym. Pozwala to wyznaczyć zakres danych wymagających kontroli bez opierania się wyłącznie na chwili zauważenia problemu.

Czy naprawa wymaga zatrzymania sklepu?

Nie każda awaria wymaga wyłączenia sprzedaży. Często wystarcza zatrzymanie konkretnego zadania synchronizacji, podczas gdy sklep nadal przyjmuje zamówienia. Decyzja zależy od tego, czy dalsza praca zwiększa ryzyko niespójności. Priorytetem jest zachowanie zamówień oraz uniknięcie podwójnego przetworzenia płatności, rezerwacji i dokumentów.

Co warto monitorować po przywróceniu działania?

Należy kontrolować czas ostatniej udanej wymiany, liczbę błędnych zadań oraz obecność rekordów oczekujących w kolejce. Istotne jest też porównanie kilku rzeczywistych zamówień po obu stronach: produktów, ilości, cen, sposobu płatności, dostawy i statusu realizacji. Sam komunikat o powodzeniu potwierdza wykonanie zadania, ale nie zawsze potwierdza poprawność wszystkich danych.

Kontrola, która zamyka awarię bez pozostawienia rozbieżności

Naprawę można uznać za zakończoną dopiero wtedy, gdy nowe dane przechodzą prawidłowo, zaległości zostały rozliczone, a po obu stronach nie pozostały niewyjaśnione różnice. Dokumentuje się przyczynę, wprowadzoną zmianę i sposób sprawdzania kolejnych operacji. Dzięki temu następne odstępstwo jest widoczne wcześniej, a historia naprawy nie kończy się na samym komunikacie „synchronizacja uruchomiona”.