IOSOR

IOSOR Tieto

Saapuvat SMS-webhookit: uudelleenyritykset, tapahtumajärjestys ja idempotenssi vastaanotossa

Rakennusopas B2B-tiimeille, jotka käsittelevät saapuvia SMS-viestejä: miksi uudelleenyrityksiä tapahtuu, miksi tapahtumajärjestystä ei taata, ja miten tehdä vastaanottopäätepisteestänne idempotentti sen sijaan, että kopioisitte keskusteluja ja STOP-käsittelyä.

Saapuvat SMS-webhookit: uudelleenyritykset, tapahtumajärjestys ja idempotenssi vastaanotossa.

Jokainen saapuvien viestien käsittelijä kohtaa lopulta samat kolme yllätystä: sama webhook laukeaa kahdesti, "delivered"-tapahtuma saapuu sen "failed"-tapahtuman jälkeen, jonka piti korvata se, ja asiakkaan STOP-vastaus käsitellään kahdesti, koska kaksi palvelinta vastaanotti saman uudelleenyrityksen. Mikään näistä ei ole bugi alustassa, joka lähettää teille webhookin — se on minkä tahansa "vähintään kerran" -toimitusjärjestelmän normaalia käyttäytymistä, ja vastaanottopäätepisteenne on rakennettava tälle todellisuudelle ensimmäisestä päivästä lähtien.

Miksi webhookit ylipäätään yrittävät uudelleen

Webhook-palveluntarjoaja ei voi tietää varmasti, onnistuiko päätepisteenne käsittelemään toimituksen. Palvelimenne saattaa palauttaa 200 OK -vastauksen sen jälkeen, kun se on tallentanut tiedon tietokantaan, joka sitten peruutetaan. Kuormantasaaja saattaa hukata vastauksen matkalla takaisin, vaikka käsittelijänne onnistui. Käyttöönotto saattaa käynnistää prosessinne uudelleen kesken pyynnön.

Kolme vikatilaa, joille teidän on suunniteltava

Kaksinkertainen toimitus: Sama tapahtumatunnus saapuu useammin kuin kerran. Tämä johtaa kaksinkertaisesti laskettuihin vastauksiin, kaksinkertaiseen STOP-käsittelyyn ja kaksinkertaisiin keskusteluketjuihin. Väärässä järjestyksessä olevat tapahtumat: Myöhemmin aikaleimattu tapahtuma saapuu ennen aikaisempaa. Esimerkiksi "delivered"-tila kirjoitetaan takaisin "sent"-tilaksi.

Idempotenssi: yksi ominaisuus, joka korjaa kaikki kolme

Idempotentti vastaanottopäätepiste tuottaa saman lopputilan riippumatta siitä, kuinka monta kertaa sama tapahtuma toimitetaan. Mekanismi on yksinkertainen ja hyvin ymmärretty: jokainen saapuva tapahtuma sisältää yksilöllisen tapahtumatunnuksen. Ennen käsittelyä tarkistatte, oletteko jo tallentaneet kyseisen tunnuksen. Jos olette, palautatte onnistumisen välittömästi ilman uudelleenkäsittelyä.

Tapahtumajärjestys: miksi "viimeinen kirjoitus voittaa" on vaarallista

Saman viestin webhook-tapahtumien ei taata saapuvan siinä järjestyksessä, jossa ne tapahtuivat. Aikaisemman "queued"-tapahtuman uudelleenyritys voi saapua myöhemmän "delivered"-tapahtuman jälkeen verkon viiveiden, palveluntarjoajan puolen jonotuksen tai oman työntekijäpoolinne pyyntöjen väärässä järjestyksessä käsittelyn vuoksi.

STOP, HELP, ja muut saapuvat avainsanat tarvitsevat saman kurin

Vaatimustenmukaisuuden kannalta kriittiset saapuvat avainsanat ansaitsevat tiukimman idempotenssin kaikista. Kaksinkertaisen STOP-pyynnön ei pitäisi koskaan kirjata kieltäytymistapahtumaa kahdesti tai lähettää kahta vahvistusvastausta. Kaksinkertaisen HELP-pyynnön ei pitäisi koskaan laukaista kahta erillistä tukitietoviestiä samaan numeroon saman minuutin sisällä.

Aloittakaa IOSORin kanssa

Tarkastelkaa viime viikon saapuvien webhookien lokeja ja laskekaa tapahtumatunnukset, jotka saapuivat useammin kuin kerran. Toistakaa yksi kaksoiskappale ja yksi väärässä järjestyksessä oleva pari (esim. epäonnistunut, sitten toimitettu). Vastaanottimen tulisi käsitellä tämä yhdellä tavalla: yksi rivi saapuneissa viesteissä, yksi merkintä STOP-käsittelystä, yksi tapahtuma lompakossa. "Viimeinen kirjoitus voittaa" -logiikka, joka kumoaa STOP-pyynnön, on tuhoisa.

IOSOR-yhteenveto

Saapuvat webhookit yrittävät uudelleen. Vastaanoton idempotenssi on ainoa turvallinen ratkaisu; järjestystä ei voi taata. Tehkää näin: avainta tapahtuma ja ohittakaa kaksoiskappaleet. Älkää tehkö näin: käyttäkö "viimeinen kirjoitus voittaa" -logiikkaa STOP-pyyntöihin älkääkä veloittako samaa tapahtumaa kahdesti.

Oliko tästä oppaasta apua?

Aiheeseen liittyvät oppaat