Rozdziały przewodnika
Integracje ze sklepami sprzedawców
Problem#
Sprzedawca, który już gdzieś sprzedaje, nie chce wpisywać katalogu drugi raz. Z jego perspektywy to jedno kliknięcie. Z perspektywy platformy to moment, w którym ten sam produkt zaczyna istnieć w dwóch systemach, każdy z własną ceną, stanem i historią zmian.
Cała trudność integracji sprowadza się do jednego pytania zadanego osobno dla każdego pola: który system ma rację, gdy obie strony mówią co innego.
Drabina dojrzałości#
Nie zaczyna się od synchronizacji. Kolejne szczeble są tanie i każdy z nich rozwiązuje realny problem, zanim pojawi się następny.
| Etap | Kiedy wystarcza | Co dokłada |
|---|---|---|
| Ręczne dodawanie | kilkunastu sprzedawców, mały katalog | nic, i o to chodzi |
| Import z pliku | sprzedawca ma setki produktów | mapowanie kolumn, walidacja, raport błędów |
| Import jednorazowy z API | sprzedawca ma sklep i nie chce eksportować | uwierzytelnienie, mapowanie identyfikatorów |
| Synchronizacja stanów | ten sam towar sprzedaje się w dwóch miejscach | nasłuch zmian, kolejka, obsługa błędów |
| Synchronizacja ciągła | katalog żyje po stronie sprzedawcy | wykrywanie konfliktów, rozstrzyganie źródła prawdy |
Minimalna wersja#
Pierwsza integracja potrzebuje czterech rzeczy i żadna z nich nie jest synchronizacją.
- Połączenie: zapis, że dany sprzedawca podpiął dany sklep, wraz z poświadczeniami trzymanymi osobno od reszty danych.
- Mapowanie identyfikatorów: tabela wiążąca rekord u Ciebie z rekordem po stronie źródła, na poziomie wariantu, nie tylko produktu.
- Zadanie importu z widocznym stanem: ile pozycji, ile przeszło, ile odpadło i dlaczego.
- Rozłączenie, które nie kasuje zaimportowanych produktów, tylko zrywa powiązanie.
Czego nie budować teraz#
- Własnego konektora pisanego od zera dla każdego dostawcy. Drugi dostawca ma trafić w tę samą warstwę, co pierwszy.
- Synchronizacji dwukierunkowej. Zacznij od jednego kierunku i od jednego typu danych.
- Interfejsu do ręcznego rozwiązywania konfliktów, zanim zobaczysz, jakie konflikty faktycznie występują.
- Synchronizacji opisów i zdjęć. To dane, które najczęściej mają zostać po stronie platformy.
Zaplanuj z góry#
Źródło prawdy per pole, nie per integracja#
Nie ma jednej odpowiedzi na pytanie, kto wygrywa. Typowy podział: stan magazynowy po stronie sklepu sprzedawcy, cena i opis po stronie platformy, bo to platforma odpowiada za prezentację i promocje. Ważne, żeby ten podział był zapisany jako reguła, a nie wynikał z tego, który zapis przyszedł ostatni.
Idempotencja od pierwszej wersji#
Każda operacja synchronizacji ma mieć klucz, który pozwala rozpoznać, że to już było. Systemy zewnętrzne wysyłają powiadomienia po kilka razy, nie po kolei i czasem po godzinie. Bez klucza pierwszy powtórzony webhook zdubluje produkt albo cofnie stan.
Kolejka zamiast wywołań w locie#
Import i synchronizacja mają iść przez kolejkę z ponowieniami, a nie dziać się w trakcie żądania HTTP. To nie jest optymalizacja wydajności, tylko warunek tego, żeby awaria po stronie dostawcy nie kończyła się utratą danych.
Do kolejki należą trzy zachowania, które łatwo pominąć na starcie i drogo dorabia się później: rosnące odstępy między ponowieniami, wyłączenie dostawcy po serii błędów zamiast dobijania go w pętli, oraz miejsce, gdzie ląduje to, czego nie udało się przetworzyć.
Wyzwalacze#
- drugi sprzedawca prosi o ten sam typ sklepu, co pierwszy;
- sprzedawca podpina drugi sklep do tego samego konta;
- pierwsza sprzedaż towaru, którego nie było już na stanie w sklepie źródłowym;
- import zaczyna trwać na tyle długo, że ktoś pyta, czy się zawiesił;
- pierwszy konflikt, w którym cena u Ciebie i u sprzedawcy różnią się w trakcie promocji.
Następny etap#
Po drugim wyzwalaczu: rozdzielenie połączenia od sprzedawcy, bo jeden sprzedawca może mieć ich kilka. Po trzecim: synchronizacja stanów, wciąż jednokierunkowa. Po piątym: jawne wykrywanie konfliktów z decyzją operatora, zanim zbudujesz automatyczne rozstrzyganie.
Częste błędy#
| Założenie | Dlaczego kosztuje |
|---|---|
| "Jeden sprzedawca to jedno połączenie." | Drugi sklep tego samego sprzedawcy wymusza przebudowę modelu. |
| "Powiadomienie przychodzi raz." | Powtórki dublują produkty albo cofają stan magazynowy. |
| "Zsynchronizujmy wszystko, skoro już mamy dostęp." | Opisy i zdjęcia wracają jako nadpisania treści przygotowanej przez platformę. |
| "Rozłączenie usuwa produkty." | Sprzedawca traci katalog przy zmianie sklepu, a zamówienia tracą kontekst. |
| "Ponowimy natychmiast." | Dostawca z awarią dostaje lawinę żądań i blokuje konto. |
Co się sprawdza w praktyce#
Przy integracjach najważniejsze okazało się podpięcie wszystkich dostawców pod jedną warstwę wykonawczą zamiast pisania osobnej integracji dla każdego. Kolejne platformy różnią się sposobem uwierzytelnienia i kształtem danych, ale kolejka, ponowienia, idempotencja i obsługa powtórzonych powiadomień są dla nich wspólne. Praca przy nowym dostawcy sprowadza się wtedy do tego, co go faktycznie odróżnia, a nie do odtwarzania całej mechaniki od nowa.
Druga rzecz: rozłączenie, które zrywa powiązanie zamiast kasować dane. Sprzedawca może zmienić sklep, stracić dostęp albo chcieć podpiąć go ponownie, a katalog skasowany przy rozłączeniu jest nie do odzyskania.
Checklista#
- Połączenie jest osobnym bytem, a sprzedawca może mieć ich więcej niż jedno.
- Mapowanie identyfikatorów istnieje na poziomie wariantu.
- Dla każdego synchronizowanego pola wiadomo, kto jest źródłem prawdy.
- Każda operacja ma klucz idempotencji, a odebrane powiadomienia mają rejestr.
- Synchronizacja idzie przez kolejkę z rosnącymi odstępami ponowień.
- Rozłączenie zrywa powiązanie, nie usuwa produktów.
Projektuję platformy multi-vendor wraz z onboardingiem, płatnościami, moderacją i procesami operacyjnymi.
Zobacz usługę budowy marketplace