Każda integracja sklepu, marketplace'u albo CRM z systemem ERP musi odpowiedzieć na jedno pytanie: skąd ERP ma wiedzieć, że coś się zmieniło? Są na to dwa sposoby i od wyboru zależy, jak szybko dane dotrą i ile integracja będzie kosztować w utrzymaniu.
Odpytywanie API (polling)
Integracja co jakiś czas, na przykład co 5 minut, pyta drugi system: „czy są nowe zamówienia?”. Jeśli są, pobiera je.
- Plusy: działa z niemal każdym systemem, który ma API. Jest proste do zbudowania i łatwe do zrozumienia.
- Minusy: dane docierają z opóźnieniem równym odstępowi między pytaniami. Większość zapytań kończy się odpowiedzią „nic nowego”, a przy wielu sklepach czy ofertach zapytania szybko zbliżają się do limitów API.
Webhook
To odwrotny kierunek: system, w którym zaszła zmiana, sam wysyła powiadomienie pod ustalony adres. Nowe zamówienie w sklepie wywołuje webhook, a integracja od razu przekazuje je do ERP.
- Plusy: zmiany docierają praktycznie od razu. Zapytań jest dużo mniej, bo integracja działa tylko wtedy, gdy coś się wydarzyło.
- Minusy: nie każdy system oferuje webhooki dla wszystkich zdarzeń. Trzeba też przygotować się na to, że powiadomienie przyjdzie dwa razy, w innej kolejności albo w ogóle nie dojdzie.
Odpytywanie API co 5 min
- Zapytania
- 0
- w tym puste
- 0
- Zamówienie dotarło po
- —
Webhook przy każdej zmianie
- Zapytania
- 0
- w tym puste
- 0
- Zamówienie dotarło po
- —
nowe zamówieniepusta odpowiedź „nic nowego”
Co wybrać?
W praktyce najlepiej sprawdza się połączenie obu:
- Webhooki jako główny sposób dla zdarzeń, które mają dotrzeć szybko: nowe zamówienie, zmiana statusu, płatność.
- Rzadkie odpytywanie kontrolne, na przykład raz na godzinę, które porówna oba systemy i wyłapie to, co mogło się zgubić.
- Samo odpytywanie tam, gdzie system nie ma webhooków albo dane zmieniają się rzadko, na przykład cenniki aktualizowane raz dziennie.
O czym pamiętać przy webhookach
- Rozpoznawanie powtórek. Integracja powinna wiedzieć, że dane zamówienie już obsłużyła, i nie tworzyć go w ERP drugi raz.
- Kolejność zdarzeń. Zmiana statusu może przyjść przed informacją o samym zamówieniu. Warto to przewidzieć.
- Szybka odpowiedź. Webhook powinien być przyjęty od razu, a cięższa praca, na przykład zapis w ERP, wykonana chwilę później w tle.
- Widoczność błędów. Nieudane przekazanie danych musi być widać w logach albo w powiadomieniu, zanim zauważy je klient.
Webhook w MultiBridge
Jeśli w firmie działa MultiBridge, adres, na który inny system wyśle webhook, wystawia się bez programowania. W module SQL Bridge wystarczy dodać endpoint przyjmujący żądania POST i wskazać, co ma się stać z danymi:
- zapis do tabeli SQL: pola z powiadomienia przypisuje się do kolumn albo zapisuje całą treść (JSON lub XML) w jednej kolumnie,
- wywołanie procedury składowanej, która od razu przetworzy dane po stronie bazy.
Endpoint może też sprawdzać podpis webhooka (HMAC), jeśli system wysyłający go podpisuje. Powiadomienie bez poprawnego podpisu zostaje odrzucone, zanim cokolwiek trafi do bazy. Każde wywołanie, także odrzucone, widać w monitorze dostępu MultiBridge.
Tak zbudowaliśmy między innymi integrację ERP z Base (BaseLinker), gdzie przejście na webhooki mocno zmniejszyło liczbę zapytań do API.