Інтеграція складу, ERP або транспортного порталу не призначена для перевірки кожні кілька секунд, чи щось змінилося в Time Slot Control. Вихідні вебхуки перенаправляють подію в момент її виникнення, зберігаючи при цьому чіткий результат кожної спроби доставки.

Від події до результату без опитувань

Коли змінюється резервація або замовлення, TSC створює подію і вибирає активні вебхуки, які відстежують цей тип. Кожна підписка отримує версійний JSON через HTTP POST на адресу призначення.

TSC виявляє зміну і створює унікальну подію.
Активні підписки порівнюються з її типом.
Окрема доставка буде створена для кожного відповідного замовлення.
Відповідь цільової системи визначає отриманий стан або наступну спробу.

Обробка керується подіями і відбувається асинхронно. Підключена система не обтяжує API частими запитами про опитування і може відповідати незабаром після фактичної зміни.

Потік доставки вихідного вебхука від події TSC через підписаний HTTP POST до стану Delivered, Failed або DeadLetter і ручного Resend

Журнал доставки замінює здогадки

Адміністратор може бачити доставку в одному місці і фільтрувати їх за підпискою на вебхук і статусом. Для кожного запису вказано тип події, кількість спроб, останній HTTP-статус, час останньої спроби та коротка інформація про помилку.

Статус	Що це означає
Pending	Доставка чекає в черзі на першу або наступну спробу.
Delivered	Цільова система відправила успішну HTTP-відповідь.
Failed	Остання спроба закінчилася тимчасовою помилкою і буде повторена.
DeadLetter	Автоматичні спроби завершилися або відповідь не повинна повторюватися автоматично.

Що відбувається, коли цільова система недоступна

Помилки мережі, відповіді HTTP 429 та помилки сервера 5xx повторюються з дедалі більшими інтервалами, максимум у п'ять спроб. Поширені помилки клієнта 4xx, крім 429, одразу переходять у стан DeadLetter, оскільки наступна автоматична спроба зазвичай закінчується тим самим.

Після ремонту приймаючої системи уповноважений користувач може скористатися Resend. TSC скидає кількість спроб, видаляє останню помилку і повертає доставку в чергу. Отже, немає потреби відкликати початкову бізнес-подію.

Події, що відповідають реальному трафіку

Каталог не обмежується загальним створенням, модифікацією та видаленням. Інтеграція також може прибрати певні моменти в життєвому циклі бронювання та замовлення, такі як reservation.pendingBookreservation.vehicle.platechangedreservation.markedasarrivalreservation.approval.approvedreservation.processingstartedreservation.markedasdeparted, A або order.confirmedA.

Підписка обирає лише ті події, які їй потрібні. Цільова система не повинна ретроспективно виводити загальну зміну того, що насправді сталося під час операції.

Підписані повідомлення та безпечна обробка

Адреса вебхука використовує HTTPS. TSC надсилає JSON-обгортку з schemaVersionполямиeventeventIdoccurredAt tenantIdта data. Тіло запиту підписується HMAC-SHA256, а отримувач отримує підпис у X-TSC-Signature заголовку разом із часовою позначкою.X-TSC-Timestamp

Приймаюча система повинна перевірити підпис і часову позначку, обробити eventId їх ідемпотентно і повернути успішний стан 2xx лише після того, як вона безпечно отримала повідомлення. Секрет можна повернути під час зміни безпеки.

Що вона приносить в інтеграційні операції

Менше запитів у опитуваннях і менше навантаження з обох сторін інтеграції.
читабельний статус кожної доставки без пошуку в кількох інструментах логування,
Автоматичне відновлення після тимчасових помилок
Контрольована ручна повторна спроба після ремонту цільової системи.
перевірене походження та цілісність кожного повідомлення.

Результатом є не лише швидша передача подій, а й оперативно передбачувана інтеграція: команда може бачити, що було реалізовано, що чекає на наступну спробу і що потребує втручання.

Ви хочете підключити TSC до ERP, WMS чи власної платформи інтеграції? Перегляньте варіанти інтеграції або опишіть нам свій сценарій.