Przejdź do głównej zawartości

Obce zapisy

product.stock jest wynikiem. Stockly wyprowadza go z półek po każdej operacji i nadpisuje to, co tam zastanie. Integracja, która to pole zapisuje, nie rozmawia z magazynem; ściga się z następnym przeliczeniem i przegrywa.

Ta strona opisuje mechanizm. Ustawienie, ekran rejestru i dzienne podsumowanie opisują obce zapisy stanu dla ludzi, którzy to obsługują.

Każdy legalny zapis aktualizuje product.stock i cień dostępności w tej samej transakcji. Ponieważ ta para rusza się atomowo, niezgodność zaobserwowana pod blokadą wiersza wołającego nie może być stanem pośrednim, bo nic nie może być w połowie. Ktoś zapisał pole, nie mówiąc o tym modułowi.

Cień prowadzony jest niezależnie od tego, czy wykrywanie jest włączone, więc włączenie go później startuje z aktualnej podstawy, a nie z lawiny fałszywych alarmów.

Dwa punkty wykrycia, o różnym momencie:

Wartość sourceZapisane przezZłapane
dalAdmin API, panel, dowolny zapis przez DALnatychmiast, przy zapisie produktu
sqlsurowy SQL wprost w baziez opóźnieniem, przy najbliższym zdarzeniu stanu tego produktu — dokładnie wtedy, gdy moduł i tak by to po cichu nadpisał

Model zagrożenia to źle skonfigurowana integracja, a nie sabotaż od strony bazy. System, który podrabia także tabelę cienia, jest poza zasięgiem jakiegokolwiek mechanizmu na poziomie aplikacji.

Polityka jest ustawieniem, a jej wartości docierają do integracji dosłownie, w policyApplied:

WartośćCo dzieje się z liczbą
offbrak wykrywania i brak zapisu: edycja przez DAL jest wchłaniana jak zwykła korekta stanu, a zapis surowym SQL-em zostaje nadpisany przy najbliższym przeliczeniu
correctwygrywa liczba z zewnątrz — różnica jest księgowana w magazynie, a incydent zapisany
restorewygrywają półki — nic nie jest księgowane, pole zostaje odtworzone z półek, a odrzucony zapis zapisany

Przy correct różnica zapisuje się jako prawdziwy ruch, więc korekta jest w historii produktu jak każda inna. Przy restore ruchu nie ma, bo fizycznie nic się nie zmieniło.

p2lab_stockly.external_stock_write_detected wysyłane jest raz na produkt na całość pracy, po zatwierdzeniu transakcji:

Klucz
productId
expectedValueco trzymało Stockly
foundValueco zostawił piszący
deltaróżnica
sourcedal albo sql
policyAppliedoff, correct albo restore

W odróżnieniu od każdego innego zdarzenia z katalogu to niesie wartości proste zamiast wspólnej koperty, ponieważ jest pisane pod Flow Builder i webhooki App System, dlatego sklep może powiesić na nim mail bez pisania kodu.

p2lab_stockly_external_stock_incident, jeden wiersz na wykrycie:

Pole
productId
expectedAtpliczba, którą dają półki
foundValueliczba, którą ktoś zapisał
delta
sourcedal albo sql
policyAppliedcorrect albo restore
userId, integrationIdkto zapisał, gdy zapis przyszedł przez API

integrationId jest tu najcenniejsze dla autora integracji: wskazuje konkretną integrację API, która zapisu dokonała, co zamienia ogólne zgłoszenie o nadpisywaniu stanów w konkretne poświadczenie.

Czytaj to jak każdą encję (/api/search/p2lab-stockly-external-stock-incident); rosnąca liczba wierszy dla jednego integrationId jest warta osobnego alarmu.

Wiersze przeżywają usunięcie produktu i tak ma być: ślad audytowy znikający razem ze swoim tematem nie jest śladem audytowym. Są usuwane po roku.

ChceszWywołaj
zaksięgować przyjęcie towaruwarehouse/stock/add
zaksięgować wydaniewarehouse/stock/remove
skorygować liczbę do policzonejwarehouse/stock/count
naprawić product.stock, który ktoś już nadpisałwarehouse/stock/sync-product/{productId}

Każde z nich zostawia wiersz w rejestrze, przelicza publikowaną liczbę i aktualizuje cień, a to jest cała różnica między zmianą stanu a zmianą stanu, której nikt później nie umie wytłumaczyć.

Jeśli system zewnętrzny naprawdę jest właścicielem liczb, to jest architektura do obrony: ustaw politykę na correct i pozwól mu wygrywać jawnie, z każdym nadpisaniem zapisanym. Nigdy nie jest w porządku zapis pola przy wyłączonym wykrywaniu i założenie, że się utrzymał.