Webhooki¶
Webhooki to powiadomienia wychodzące: po wystąpieniu zdarzenia w magazynie MobiSkan WMS sam wysyła żądanie HTTP na wskazany przez klienta adres.
Dostępność. Ekran zarządzania webhookami nie jest dziś dostępny w interfejsie panelu. Mechanizm działa w pełni i dostarcza zdarzenia, ale subskrypcje zakłada się i modyfikuje przez interfejs API. Patrz API.
Do czego służą¶
Webhook pozwala systemowi zewnętrznemu reagować na to, co dzieje się w magazynie, bez cyklicznego odpytywania:
- odświeżenie danych w sklepie internetowym po zmianie stanu,
- powiadomienie systemu nadrzędnego o zamknięciu dokumentu,
- zasilenie hurtowni danych zdarzeniami z rejestru ruchów.
Katalog zdarzeń¶
Subskrybować można zamknięty zestaw zdarzeń:
| Zdarzenie | Kiedy powstaje |
|---|---|
goods.created |
dodano pozycję katalogu towarów |
goods.updated |
zmieniono pozycję katalogu towarów |
document.closed |
zamknięto dokument |
stock.changed |
zmienił się stan magazynowy |
inventory.transaction |
dopisano wpis do rejestru ruchów magazynowych |
Jedna subskrypcja może obejmować kilka rodzajów zdarzeń.
Subskrypcja¶
Subskrypcja składa się z nazwy, adresu docelowego, listy zdarzeń oraz przełącznika aktywności.
Przy tworzeniu subskrypcji zwracany jest sekret służący do podpisywania dostarczeń. Sekret jest zwracany wyłącznie w tej jednej odpowiedzi i nigdy więcej - trzeba go od razu zapisać po stronie odbiorcy.
Subskrypcja bez sekretu jest obsługiwana: dostarczenia są wtedy wysyłane bez podpisu, a nie odrzucane.
Dostarczanie¶
| Element | Zachowanie |
|---|---|
| Metoda | żądanie POST z treścią zdarzenia w formacie JSON |
| Podpis | nagłówki z podpisem HMAC-SHA256 oraz znacznikiem czasu |
| Limit czasu | 12 sekund na odpowiedź |
| Kadencja | zdarzenia oczekujące są wysyłane w cyklu minutowym |
| Ponawianie | maksymalnie 5 prób, w stałej kadencji, bez wydłużania odstępów |
| Duplikaty | odbiorca, który odpowiedział kodem 2xx, nie dostaje tego samego zdarzenia ponownie |
| Brak odbiorców | zdarzenie bez pasującej subskrypcji jest uznawane za dostarczone, a nie za błąd |
| Trwałe niepowodzenie | po piątej nieudanej próbie zdarzenie zostaje oznaczone jako nieudane i nie jest już ponawiane |
Nie ma osobnej kolejki zdarzeń nieodebranych ani mechanizmu ponownego nadania. Odbiorca, który był niedostępny dłużej niż okno ponawiania, musi uzupełnić brakujące dane odczytem z API.
Weryfikacja podpisu po stronie odbiorcy¶
Podpis jest liczony dokładnie z tej treści, która trafia do ciała żądania. Odbiorca powinien:
- odczytać nagłówki z podpisem i znacznikiem czasu,
- policzyć własny podpis HMAC-SHA256 z surowej treści żądania, używając zapisanego sekretu,
- porównać wyniki i odrzucić żądanie, jeśli się nie zgadzają,
- odrzucić także żądanie ze zbyt starym znacznikiem czasu.
Bezpieczeństwo adresu docelowego¶
Adres jest sprawdzany ponownie w momencie wysyłki i przypinany do rozwiązanego adresu IP. Zabezpiecza to przed skierowaniem żądania do zasobów wewnętrznych sieci oraz przed podmianą adresu między konfiguracją a wysyłką. Adresy wskazujące na sieć wewnętrzną są odrzucane.
Diagnostyka¶
Nieudane dostarczenia są przechowywane i można je odczytać przez API. Ekran ich podglądu w panelu jest dziś wyłączony z nawigacji.
Rosnąca liczba nieudanych dostarczeń jest jedną z metryk technicznych systemu, nadającą się do podpięcia pod monitoring.
Integracja z systemem ERP¶
Powiadamianie systemu handlowego o zamknięciu dokumentu nie korzysta z webhooków. Konektor ERP ma własną, synchroniczną ścieżkę powiadamiania. Patrz dokumentacja konektorów.