Integracja z magazynem, ERP lub portalem transportowym nie ma na celu sprawdzania co kilka sekund, czy coś się zmieniło w Time Slot Control. Outbound webhooki przekazują zdarzenie w momencie jego wystąpienia, jednocześnie zachowując jasny wynik każdej próby dostawy.

Od wydarzenia do dostawy bez odpytywania

Gdy rezerwacja lub zamówienie się zmienia, TSC tworzy zdarzenie i wybiera aktywne subskrypcje webhooków śledzące ten typ. Każda subskrypcja otrzymuje wersjonowany JSON przez HTTP POST na adres docelowy.

TSC wykrywa tę zmianę i tworzy unikalne zdarzenie.
Aktywne subskrypcje są porównywane do ich typu.
Dla każdego odpowiadającego zamówienia zostanie utworzona osobna dostawa.
Odpowiedź systemu docelowego decyduje o wyniku lub kolejnej próbie.

Przetwarzanie jest sterowane zdarzeniami i odbywa się asynchronicznie. Połączony system nie musi obciążać API częstymi zapytaniami i może odpowiedzieć krótko po faktycznej zmianie.

Przepływ dostarczania webhooka wychodzącego od zdarzenia TSC przez podpisany HTTP POST do statusu Delivered, Failed lub DeadLetter i ręcznego Resend

Dziennik dostaw zastępuje domysły

Administrator może zobaczyć dostawę w jednym miejscu i filtrować ją zarówno według subskrypcji webhooka, jak i statusu. Dla każdego rekordu dostępny jest typ zdarzenia, liczba prób, status ostatniego HTTP, czas ostatniej próby oraz krótka informacja o błędzie.

Status	Co to oznacza
Pending	Dostawa czeka w kolejce na pierwszą lub następną próbę.
Delivered	System docelowy zwracał pomyślną odpowiedź HTTP.
Failed	Ostatnia próba zakończyła się tymczasowym błędem i zostanie powtórzona.
DeadLetter	Automatyczne próby się zakończyły lub odpowiedź nie powinna być automatycznie powtarzana.

Co się dzieje, gdy system docelowy jest niedostępny

Błędy sieciowe, odpowiedzi HTTP 429 oraz błędy serwera 5xx powtarzają się w coraz dłuższych odstępach, maksymalnie w pięciu próbach. Typowe błędy klienta 4xx z wyjątkiem 429 przechodzą bezpośrednio do stanu DeadLetter, ponieważ kolejna automatyczna próba zwykle kończy się tak samo.

Po naprawie systemu odbiorczego użytkownik autoryzowany może użyć Resend. TSC resetuje liczbę prób, usuwa ostatni błąd i zwraca dostawę do kolejki. W związku z tym nie ma potrzeby przywoływania oryginalnego zdarzenia biznesowego.

Zdarzenia odpowiadające rzeczywistemu ruchowi

Katalog nie kończy się na generycznym tworzeniu, modyfikacji i usuwaniu. Integracja może również usunąć konkretne punkty z cyklu rezerwacji i zamówienia, takie jak reservation.pendingBookreservation.vehicle.platechangedreservation.markedasarrivalreservation.approval.approvedreservation.processingstartedreservation.markedasdeparted, A czy order.confirmedA.

Subskrypcja wybiera tylko te zdarzenia, których potrzebuje. System docelowy nie musi wyprowadzać retrospektywnie z ogólnej zmiany tego, co faktycznie miało miejsce podczas operacji.

Podpisane wiadomości i bezpieczne przetwarzanie

Adres webhooka używa HTTPS. TSC wysyła wrapper JSON z schemaVersionpolamieventeventIdoccurredAt tenantIdoraz data. Ciało żądania jest podpisane za pomocą HMAC-SHA256, a odbiorca otrzymuje podpis w nagłówku X-TSC-Signature wraz ze znacznikiem czasu.X-TSC-Timestamp

System odbiorcy powinien zweryfikować podpis i znacznik czasu, przetworzyć eventId je idempotentnie i zwrócić udany stan 2xx dopiero po bezpiecznym odebraniu wiadomości. Sekret można obrócić po zmianie bezpieczeństwa.

Co wnosi do operacji integracyjnych

Mniej zapytań w sondażach i mniejszy ciężar po obu stronach integracji.
czytelny status każdej dostawy bez konieczności wyszukiwania w kilku narzędziach logowania,
Automatyczne odzyskiwanie błędów tymczasowych
Kontrolowana ręczna próba po naprawie systemu celu.
Weryfikowalne pochodzenie i integralność każdej wiadomości.

W rezultacie nie tylko szybsze przekazywanie wydarzeń, ale także operacyjnie przewidywalna integracja: zespół może zobaczyć, co zostało dostarczone, co czeka na kolejną próbę, a co wymaga interwencji.

Czy chcesz połączyć TSC z ERP, WMS lub własną platformą integracyjną? Przejrzyj opcje integracji lub opisz nam swój scenariusz.