Odczyt kontrolny zaraz po zapisie mówi tylko, co było w rekordzie w tej chwili. Jeśli do sklepu zapisuje też inny proces, rekord może zmienić się później. Dlatego po większym wdrożeniu sprawdza się wyrenderowane strony całej partii, a gdy dane zmieniają się „same”, daty edycji pomagają znaleźć okna zapisów, a autora i kanał zapisu potwierdzają logi integracji.
| Objaw | 1 z kilkudziesięciu kategorii wróciła do starej treści po zapisie potwierdzonym odczytem |
|---|---|
| Wykrycie | kontrola wyrenderowanych stron całej partii po wdrożeniu |
| Przyczyna | nieustalona; możliwe hipotezy w sekcji 02 |
| Naprawa | ponowny zapis tej kategorii i kontrole po 20 s, po 2 min i na stronie: treść się utrzymała |
Objaw: kategoria wróciła do starej treści
Partia kilkudziesięciu kategorii dostała nowe opisy przez Shoper API. Każdy zapis przeszedł odczyt kontrolny: treść w rekordzie była nowa. Po wdrożeniu narzędzie, które pobiera wyrenderowane strony i sprawdza tytuł, opis meta i widoczny tekst kategorii, znalazło jedną kategorię ze starą treścią. Ponowny odczyt z API też pokazał stan sprzed zmiany.
Kategorię zapisaliśmy jeszcze raz i sprawdziliśmy po 20 s, po 2 minutach i na wyrenderowanej stronie. Treść się utrzymała. Ani zapis, ani odczyt kontrolny nie wykazały problemu. Wykryła go dopiero kontrola stron po wdrożeniu.
Możliwe przyczyny, których nie da się rozstrzygnąć z samego sklepu
Przyczyny tego jednego przypadku nie ustaliliśmy. Między zapisem a kontrolą coś zmieniło rekord albo odczyt pokazał coś innego niż to, co sklep trzymał. Możliwe wyjaśnienia:
- inny proces zapisał rekord: integracja albo inny klucz API z dostępem do kategorii
- równoległy zapis tego samego rekordu
- odczyt kontrolny pokazał stan chwilowy: w innym sklepie zauważyliśmy, że Shoper potrafi przez kilkanaście sekund po zapisie oddawać przy odczycie stare dane, a powtórzony zapis kategorii bywa po cichu odrzucany (opisuje to pierwszy wpis z tej serii)
Żadnej z tych hipotez nie da się potwierdzić z poziomu sklepu, bo Shoper nie pokazuje, kto i kiedy zapisał rekord kategorii. Dlatego zamiast zgadywać przyczynę trzeba mieć kontrolę, która wykryje skutek.
Kontrole po zapisie, które łapią cofnięcie
- odczyt kontrolny z opóźnieniem, nie od razu po zapisie, a przy niezgodności ponowienia po 10, 20 i 30 s
- po większym wdrożeniu kontrola wyrenderowanych stron całej partii: tytuł, opis meta i widoczny tekst, pobierane wolno, jedna strona na sekundę
- przy pojedynczych wątpliwych rekordach kontrole po kilkunastu sekundach, po kilku minutach i na stronie
- plik ze stanem sprzed zapisu dla każdej partii i narzędzie, które z niego przywraca, domyślnie w trybie podglądu, z odczytem po każdym przywróceniu
- odczyt przed zapisem i porównanie z kopią: rekord zmieniony w międzyczasie przez kogoś innego jest pomijany zamiast nadpisywany
Kto nadpisał dane, skoro panel nie ma dziennika API
Ten sam problem wraca w innej postaci: ceny albo stany zmieniają się masowo, w sklepie działa kilka aplikacji i kilka kluczy API, a panel nie pokazuje, która z nich zapisała rekord. Rekordy magazynowe nie mają daty modyfikacji, ale produkty mają datę edycji. To poszlaka: pozwala znaleźć okna zapisów i zawęzić podejrzenia, ale nie rozstrzyga, kto zapisał dane.
| Wzorzec dat edycji | Co może oznaczać |
|---|---|
| wiele produktów z tą samą sekundą | edycja zbiorcza w panelu albo automat, który zapisuje partiami |
| kolejne sekundy rosnąco po ID produktu | proces, który przechodzi katalog po kolei, np. przez API |
| okna masowych zapisów, np. w nocy, w dniach bez własnych zapisów | kandydat na synchronizację integracji do sprawdzenia w jej dzienniku |
W opisanym sklepie daty edycji szły co 1–2 sekundy rosnąco po ID, co pasowało do procesu przechodzącego katalog po kolei, a nie do jednej edycji zbiorczej. Własne skrypty wykluczyliśmy po plikach kopii: w dniach okien zapisów nie było ich wcale. Ten sam wzorzec mógłby jednak dać też inny sposób zapisu, więc traktowaliśmy go jako wskazówkę, gdzie szukać, a nie jako dowód.
Granica tej metody: pokazuje, kiedy i w jakim rytmie zmieniano dane, ale nie pokazuje, kto ani przez który kanał. To rozstrzyga dopiero dziennik synchronizacji po stronie integratora. Warto od razu poprosić o datę i godzinę ostatniej synchronizacji do sklepu, ustawienia integracji (np. który magazyn zasila stany sklepu) oraz eksport stanów z rezerwacjami.
Poprawka tylko w sklepie nie wystarczy
Jeśli dane w sklepie zapisuje integracja, poprawka zrobiona w panelu albo przez własny skrypt zostanie nadpisana przy jej kolejnym przebiegu. Kolejność jest więc taka: najpierw ustalić źródło i poprawić dane tam, potem w sklepie, a na koniec sprawdzić stan po następnej synchronizacji.
Przykład takiego mechanizmu, w którym integracja zostawia sklepowi zły rekord przy każdym przebiegu, opisuje poradnik o wariancie domyślnym w Shoperze po imporcie z BaseLinkera.
Kiedy szukanie źródła zmian zrobisz sam, a kiedy z kimś
Pobranie dat edycji z API, posortowanie ich i znalezienie okien zapisów. Wzorzec zawęzi listę podejrzanych integracji i godzin, które warto porównać z ich dziennikami.
Kilka integracji i kluczy API naraz, masowe wdrożenia, które muszą być odwracalne, albo spór, czy dane psuje sklep, ERP, czy integrator.
Gdy zlecasz nam taką analizę, dostajesz zestawienie okien zapisów z wzorcem dat, listę integracji i kluczy do sprawdzenia, prośbę o konkretne eksporty po stronie integratora i, przy wdrożeniach, kontrolę wyrenderowanych stron z kopią stanu sprzed zmiany. Więcej o pracy przez Shoper API i w przeglądzie najczęstszych błędów Shoper API.