Integracja ERP z e-commerce: synchronizacja danych

Integracja ERP z e-commerce: jak określić dopuszczalne opóźnienie danych

„Integracja w czasie rzeczywistym” brzmi jak precyzyjne wymaganie, ale nim nie jest.

Stan magazynowy, nowe zamówienie, cena, opis produktu i faktura nie muszą docierać z ERP do e-commerce w takim samym czasie. Dla jednych danych opóźnienie może wpłynąć na możliwość prawidłowego zrealizowania transakcji. Dla innych aktualizacja okresowa może spełniać wszystkie wymagania procesu.

Dlatego przed wyborem webhooków, kolejek czy synchronizacji cyklicznej trzeba odpowiedzieć na inne pytanie:

Jak długo konkretne dane mogą pozostawać nieaktualne, zanim zaczną powodować niewłaściwe decyzje lub zakłócać proces?

Zamiast „real-time” określ świeżość danych

Opóźnienie można mierzyć od momentu zmiany danych w systemie źródłowym do momentu, w którym poprawna wartość jest dostępna w systemie docelowym.

Google SRE używa pojęcia Service Level Indicator (SLI) dla mierzalnej właściwości usługi oraz Service Level Objective (SLO) dla oczekiwanego poziomu takiego wskaźnika. W materiałach dotyczących przetwarzania danych Google wymienia wprost data freshness jako właściwość, dla której można definiować SLO.

Wymaganie może więc przyjąć formę:

99% zmian danego typu ma być dostępnych w systemie docelowym w czasie krótszym niż T.

T nie jest uniwersalną wartością. Trzeba je ustalić dla konkretnego procesu.

Dopóki taki cel pozostaje wymaganiem technicznym lub operacyjnym, właściwszym terminem jest SLO. SLA oznacza zobowiązanie dotyczące określonego poziomu usługi i konsekwencji jego niedotrzymania.

Nie zaczynaj od pytania „jak często synchronizować?”

Najpierw trzeba ustalić konsekwencję wykorzystania nieaktualnych danych.

Dla każdego przepływu warto odpowiedzieć na cztery pytania:

1. Który system jest źródłem danej wartości?

2. Jak często ta wartość może się zmieniać?

3. Co się stanie, jeśli drugi system przez pewien czas będzie korzystał ze starej wartości?

4. Co ma zrobić system, jeśli aktualnych danych chwilowo nie można uzyskać?

Dopiero wtedy można zdecydować, czy dane powinny być pobierane na żądanie, przesyłane po wystąpieniu zdarzenia czy synchronizowane okresowo.

Stany, ceny i zamówienia mają inne wymagania

Nie warto ustalać jednego interwału dla całej integracji.

Sama częstotliwość synchronizacji nie naprawi również błędnie zdefiniowanego źródła danych. Aktualizowanie co kilka sekund niewłaściwego stanu magazynowego nadal daje niewłaściwy wynik.

Zamówienia pokazują różnicę między szybkością a niezawodnością

Nowe zamówienie może wymagać szybkiego przekazania do ERP, ale nie oznacza to automatycznie, że checkout powinien czekać na synchroniczną odpowiedź ERP.

Komunikacja asynchroniczna pozwala rozdzielić moment przyjęcia operacji od jej późniejszego przetworzenia. Microsoft opisuje taki model jako komunikację opartą na wiadomościach, w której nadawca nie zakłada natychmiastowej odpowiedzi, a stan systemów może zostać uzgodniony z opóźnieniem.

Wtedy wymaganie dla zamówienia powinno obejmować nie tylko czas dostarczenia, ale też:

• ponawianie nieudanych operacji,

• wykrywanie błędów,

• obsługę duplikatów,

• monitoring,

• sposób postępowania, gdy zamówienie nie dotrze do ERP.

Integracja, która przekazuje większość zamówień bardzo szybko, ale część z nich gubi albo tworzy podwójnie, nie spełnia poprawnie zdefiniowanego procesu.

Retry oznacza konieczność obsługi duplikatów

W systemach opartych na komunikatach ten sam komunikat może zostać dostarczony więcej niż raz. Microsoft opisuje ten problem przy modelu at-least-once delivery i zaleca idempotentne przetwarzanie, tak aby ponowne wykonanie tej samej operacji nie tworzyło kolejnego skutku biznesowego.

To samo występuje w rzeczywistych integracjach e-commerce. Shopify dokumentuje możliwość wielokrotnego dostarczenia tego samego webhooka, np. po timeoutach lub ponowieniach, i zaleca idempotentne przetwarzanie albo deduplikację na podstawie identyfikatora dostarczenia.

Przy tworzeniu zamówień, rezerwacji czy innych operacji zmieniających stan systemu jest to część wymagań funkcjonalnych integracji, a nie wyłącznie detal infrastruktury.

Jaki mechanizm synchronizacji wybrać?

Mechanizm powinien wynikać z wymaganego czasu i konsekwencji niedostępności.

Zapytanie synchroniczne ma sens, gdy dalsza operacja nie może bezpiecznie zostać wykonana bez aktualnej odpowiedzi.

Zdarzenia, webhooki lub kolejki pozwalają szybko propagować zmiany bez uzależniania nadawcy od chwilowej dostępności odbiorcy. Wymagają jednak obsługi retry, duplikatów i monitorowania przetwarzania.

Synchronizacja okresowa może wystarczyć, jeżeli biznes akceptuje określone opóźnienie i nie ma potrzeby reagowania na każdą zmianę natychmiast.

Jedna integracja może korzystać z kilku tych mechanizmów jednocześnie. Nie ma technicznego powodu, aby wszystkie typy danych synchronizować w taki sam sposób.

Świeżość trzeba mierzyć

Jeżeli wymaganie ma być później weryfikowalne, potrzebujemy informacji przynajmniej o:

• momencie zmiany w systemie źródłowym,

• momencie odebrania zmiany przez integrację,

• momencie zastosowania jej w systemie docelowym.

Google przy definiowaniu SLO zaleca używanie mierzalnych wskaźników i określonych progów. W przypadku potoków danych podaje świeżość jako odsetek danych przetworzonych w zadanym czasie lub wiek najstarszych danych.

Dlatego lepsze wymaganie brzmi:

99% aktualizacji danego typu ma zostać zastosowanych w czasie krótszym niż T.

niż:

synchronizacja ma działać real-time.

Pierwsze można zmierzyć. Drugie wymaga dopiero interpretacji.

Co dzieje się po awarii?

Szybkie przesyłanie zdarzeń nie gwarantuje spójności danych.

Webhook może nie dotrzeć, przetwarzanie może zakończyć się błędem, a ta sama wiadomość może zostać dostarczona ponownie. Shopify zaleca zarówno obsługę duplikatów, jak i mechanizm odzyskania brakujących danych po dłuższej niedostępności aplikacji.

Dlatego przy ważnych danych warto określić również sposób rekoncyliacji, czyli okresowego wykrywania rozbieżności pomiędzy systemami niezależnie od podstawowego kanału synchronizacji.

Kanał zdarzeniowy odpowiada wtedy za bieżące zmiany. Rekoncyliacja pozwala wykryć te, które z różnych powodów nie zostały poprawnie przetworzone.

Co powinno być ustalone przed wyceną integracji

Opis „dwukierunkowa integracja ERP ze sklepem w czasie rzeczywistym” nie określa wystarczająco zakresu projektu.

Dla każdego istotnego typu danych warto określić:

Dopiero taki opis pozwala dobrać architekturę do procesu zamiast traktować „real-time” jako cechę całej integracji.

Od tego powinien zacząć się projekt integracji

Bardziej rygorystyczne SLO nie jest automatycznie lepsze. Google SRE zwraca uwagę, że źle dobrany, zbyt agresywny cel może prowadzić do pracy, która nie daje użytkownikowi proporcjonalnej wartości.

Dlatego przed zaprojektowaniem integracji ERP z e-commerce warto ustalić dla każdego przepływu:

jak stare mogą być dane, zanim zaczną powodować problem biznesowy?

Dopiero ta odpowiedź pozwala sensownie zdecydować, co wymaga szybkiej propagacji zdarzeń, co odczytu na żądanie, a co może być synchronizowane okresowo.