Klient klika „Zamawiam” o 23:40. Rano magazynier ma już na terminalu listę do skompletowania, system kurierski ma dane do etykiety, a stan towaru w sklepie spadł o jedną sztukę. Nikt niczego nie przepisywał. Za taką automatyzacją procesów logistycznych stoją trzy mechanizmy, które dobrze rozumieć, zanim zamówi się integrację: API, webhooki i warstwa pośrednia, czyli middleware.
API, czyli umówiony sposób wymiany danych
API to zestaw zasad, według których jeden program prosi drugi o dane albo o wykonanie konkretnej akcji. Sklep udostępnia na przykład adres, z którego system magazynowy pobiera listę nowych zamówień. WMS z kolei udostępnia adres, pod który sklep wysyła informację o zmianie stanu. Najczęściej spotyka się REST z danymi w formacie JSON. Coraz popularniejszy jest też GraphQL, w którym system pobierający dane sam decyduje, jakie pola chce dostać.
Na etapie oferty rzadko mówi się o limitach zapytań, a praktycznie każda platforma określa, ile żądań można wysłać w danym czasie. Ma to znaczenie dla automatyzacji opartej na odpytywaniu. Sprawdzanie nowych zamówień raz na minutę to 1440 zapytań na dobę, a co pięć sekund już 17 280 i to tylko dla jednego typu danych. Do tego dochodzą zapytania pobierające szczegóły każdego zamówienia oraz te, które aktualizują stany. Integracja, która przy 50 zamówieniach dziennie działa bez zarzutu, w czasie wyprzedaży może więc przekroczyć limit.
Webhooki: sklep sam daje znać
Ciągłe odpytywanie API przypomina dzwonienie do kuriera co pięć minut z pytaniem, czy paczka już jest. Webhook odwraca tę relację. Gdy w sklepie pojawi się zamówienie, zmieni się status płatności albo klient anuluje zakup, platforma sama wysyła krótką wiadomość na wskazany adres. Magazyn dostaje sygnał od razu i nie zużywa zapytań na próżno.
Webhooki mają jednak słabe strony. Wiadomość może przyjść dwa razy, w złej kolejności albo wcale, jeśli serwer odbiorcy akurat nie odpowiadał. Dobra integracja sprawdza więc podpis każdej wiadomości, ignoruje duplikaty i co jakiś czas uruchamia zapasową synchronizację przez API, żeby wyłapać to, co umknęło.
Middleware, czyli tłumacz między systemami
Sklep i oprogramowanie magazynowe rzadko mówią dokładnie tym samym językiem. Jeden system zapisuje warianty produktu jako osobne pozycje, drugi jako cechy jednego indeksu. Jeden liczy wagę w gramach, drugi w kilogramach. Middleware stoi pomiędzy nimi: mapuje pola, przelicza jednostki, ustawia komunikaty w kolejce i pilnuje, żeby awaria jednego systemu nie zatrzymała drugiego. Może to być gotowy integrator, platforma typu iPaaS (czyli usługa w chmurze do łączenia różnych aplikacji) albo program napisany pod konkretny proces.
Sprawa komplikuje się, gdy systemów jest więcej niż dwa. Sklep, ERP, PIM, magazyn i kilku przewoźników tworzą sieć zależności, w której jeden źle zmapowany kod produktu potrafi zablokować wysyłki na cały dzień. Takie projekty lepiej powierzyć zespołom, które robiły je wielokrotnie. Przykładem jest Noto Agency, która przy wdrożeniach sklepów Shopify łączy je z systemami ERP i PIM.
Pytania, które trzeba zadać przed startem
Zanim powstanie pierwsza linijka kodu, warto ustalić, który system jest źródłem prawdy dla stanów, cen i opisów produktów. Jeśli oba mogą je zmieniać, prędzej czy później nadpiszą sobie dane. Trzeba też zdecydować, co dzieje się z zamówieniem, którego magazyn nie może przyjąć, i kto dostaje powiadomienie o błędzie synchronizacji. E-mail na skrzynkę, której nikt nie czyta, nie jest żadnym monitoringiem. Na koniec zostaje test obciążeniowy: jak integracja zachowa się przy pięciokrotnie większym ruchu niż zwykle.
Integracja, o której się zapomina
Dobrze zbudowane połączenie sklepu z magazynem jest nudne. Działa w tle, nie wymaga codziennego doglądania, a zespół przypomina sobie o nim dopiero wtedy, gdy przegląda raport z rekordowego dnia sprzedaży, w którym nie było ani jednej pomyłki w wysyłce. Do takiej nudy warto dążyć.
