Megbízható kimenő webhookok: egyértelmű kézbesítési állapot minden integrációnál

A raktár-, ERP- vagy szállítási portál integráció nem arra szolgál, hogy néhány másodpercenként ellenőrizze, változott-e valami az Időablak Vezérlésben. A kimenő webhook továbbítja az eseményt, miközben minden kézbesítési próbálkozás egyértelmű eredményét őrzi.

Az eseménytől a kiszállításig szavazás nélkül

Amikor egy rezervátum vagy rendelés változik, a TSC létrehoz egy eseményt, és kiválasztja azokat az aktív webhook előfizetéseket, amelyek követik az adott típust. Minden előfizetés HTTP POST-on keresztül kap egy verziós JSON-t a célcímére.

1. A TSC észleli a változást, és egyedi eseményt hoz létre.
2. Az aktív előfizetéseket a típusához hasonlítják.
3. Minden megfelelő rendeléshez külön kézbesítést hoznak létre.
4. A célrendszer válasza határozza meg az eredményt vagy a következő próbálkozást.

A feldolgozás eseményvezérelt és aszinkron módon történik. A csatlakoztatott rendszer nem terheli az API-t gyakori lekérdezésekkel, és a tényleges változás után röviddel tud reagálni.

A kézbesítési napló helyettesíti a találgatást

Az adminisztrátor egy helyen láthatja a kézbesítést, és szűrheti őket mind webhook-előfizetés, mind státusz alapján. Minden rekordhoz van eseménytípus, a próbálkozások száma, az utolsó HTTP státusz, az utolsó próbálkozás ideje és egy rövid hibainformáció.

Mi történik, ha a célrendszer nem elérhető

A hálózati hibák, HTTP 429 válaszok és 5xx szerver hibák egyre nagyobb időközönként ismétlődnek, legfeljebb öt próbálkozással. A 4xx gyakori klienshibái, kivéve a 429-et, közvetlenül a DeadLetter állapotba kerülnek, mert a következő automatikus próbálkozás általában ugyanígy végződik.

Miután a fogadó rendszert kijavították, az engedélyezett felhasználó használhatja a Resend funkciót. A TSC visszaállítja a próbálkozások számát, eltávolítja az utolsó hibát, és visszaadja a kézbesítést a sorba. Így nincs szükség az eredeti üzleti esemény visszahívására.

Események, amelyek megfelelnek a tényleges forgalomnak

A katalógus nem ér véget általános létrehozással, módosítással és törléssel. Az integráció eltávolíthatja a foglalási és rendelési életciklus bizonyos pontjait is, például reservation.pendinga könyvetreservation.vehicle.platechangedreservation.markedasarrivalreservation.approval.approvedreservation.processingstartedreservation.markedasdeparted, az A vagy order.confirmedA-t.

Az előfizetés csak azokat az eseményeket választja ki, amire szüksége van. A célrendszer nem kell utólag levezetnie az általános változásból azt, ami valójában történt a műveletben.

Aláírt üzenetek és biztonságos feldolgozás

A webhook cím HTTPS-t használ. A TSC küld egy JSON csomagolást mezőkkelschemaVersioneventIdeventtenantIdoccurredAt, és data. A kérelmek teste HMAC-SHA256-tal van aláírva, és a címzett aláírást kap a X-TSC-Signature fejlécben egy időbélyeggel együtt.X-TSC-Timestamp

A fogadó rendszernek ellenőriznie kell az aláírást és időbélyeget, idempotívan kell feldolgoznia eventId , és csak akkor kell visszaadnia a sikeres 2xx állapotot, amikor biztonságosan megkapta az üzenetet. A titok váltható, amikor a biztonságot megváltoztatják.

Mit ad ez az integrációs műveletekhez

• Kevesebb közvélemény-kutatási kérdés és kevesebb teher mindkét oldalon az integráció során.
• minden kézbesítés olvasható állapota több naplókészítő eszközben való keresés nélkül,
• Automatikus helyreállítás ideiglenes hibákból
• Kontrollált kézi újrapróbálkozás a célrendszer javítása után.
• minden üzenet ellenőrizhető eredete és integritása.

Az eredmény nemcsak gyorsabb események továbbítása, hanem működésileg kiszámítható integráció is: a csapat láthatja, mi érkezett a kézbesített, mi vár a következő próbálkozásra, és mi szükséges beavatkozásra.

Szeretnéd összekapcsolni a TSC-t egy ERP-hez, WMS-hez vagy saját integrációs platformodhoz? Böngéssze az integrációs lehetőségeket , vagy írja le nekünk a helyzetét.