IOSOR ความรู้
การติดตาม Correlation ID จาก API Request ไปยัง DLR Webhook
เรียนรู้การติดตามแบบ end-to-end โดยการใส่ตัวระบุความสัมพันธ์แบบกำหนดเองใน API payload และแมปผ่าน asynchronous DLR webhook
การติดตาม Correlation ID จาก API Request ไปยัง DLR Webhook.
บทนำเกี่ยวกับการติดตามคำขอ
การใช้งาน CPaaS ปริมาณสูงจำเป็นต้องมีความสามารถในการตรวจสอบที่เข้มงวดข้ามขอบเขตแบบอะซิงโครนัส เมื่อส่งข้อความจำนวนมาก รหัสสถานะ HTTP ทั่วไปจะยืนยันเพียงการรับเข้าเบื้องต้นเท่านั้น เพื่อตรวจสอบสถานะการจัดส่งขั้นสุดท้าย วิศวกรต้องส่งผ่านตัวระบุร่องรอยที่กำหนดจาก payload ขาออกของ API ไปจนถึงใบเสร็จการจัดส่งขาเข้า IOSOR ให้การสนับสนุนแบบเนทีฟสำหรับการพกพาเฮดเดอร์ติดตามแบบกำหนดเองผ่านการส่งต่อของผู้ให้บริการ ช่วยให้สามารถกระทบยอดแบบเรียลไทม์ภายในระบบการสังเกตการณ์ภายในของคุณโดยไม่ต้องเดาสถานะข้อความ.
การแทรกตัวระบุตอนส่งมอบ
เริ่มต้นการติดตามด้วยการแทรกโทเค็นการติดตามที่ไม่ซ้ำกันลงใน JSON body ของคำขอส่ง SMS หรือ OTP ของคุณ IOSOR ยอมรับสตริงเมตาดาต้าแบบกำหนดเองภายในสคีมาคำขอ โดยรักษาค่าเหล่านี้ไว้ตลอดไปป์ไลน์การกำหนดเส้นทางภายใน สิ่งนี้ช่วยให้มั่นใจได้ว่าใบเสร็จการจัดส่งทุกรายการที่ส่งคืนผ่าน webhook มีการอ้างอิงการติดตามเดิมของคุณ โปรดจำไว้ว่าการเติมเงินในบัญชีต้องรักษายอดเงินสำรองแบบเติมเงิน 20 USD เพื่อให้ API การส่งเปิดอยู่ ในขณะที่บัญชีที่มีการใช้งานใกล้เคียง 1,000 USD/เดือน จะต้องผ่านการตรวจสอบแบบซอฟต์รีวิวมาตรฐานเพื่อป้องกันคอขวดในการทำงานอัตโนมัติ.
การจัดการ Webhook แบบอะซิงโครนัส
ใบเสร็จการจัดส่งจะมาถึงแบบอะซิงโครนัสในรูปแบบ JSON payload ที่ส่งไปยังปลายทาง webhook ที่คุณกำหนดค่าไว้ เนื่องจากการประลองรับส่งข้อมูลของผู้ให้บริการเป็นระลอก DLR จึงอาจมาถึงไม่ตามลำดับหรือประสบกับการลองใหม่ระดับเครือข่าย พนักงานการนำเข้าของคุณต้องวิเคราะห์ JSON ขาเข้า แยกการอ้างอิงการติดตามที่ฝังอยู่ และเชื่อมโยงสถานะเทอร์มินัลกับบัญชีแยกประเภทการทำธุรกรรมหลักของคุณ ตรวจสอบลายเซ็นต์การเข้ารหัสบน webhook ขาเข้าเสมอเพื่อป้องกันการปลอมแปลงและการโจมตีด้วยการฉีดข้อมูลต่อโครงสร้างพื้นฐานการบันทึกของคุณ.
การกระทบยอดบัญชีแยกประเภทและการแมปสถานะ
เมื่อแยกตัวระบุการติดตามออกจาก DLR ขาเข้าแล้ว ให้อัปเดตฐานข้อมูลแอปพลิเคชันของคุณเพื่อเปลี่ยนสถานะข้อความจากรอดำเนินการเป็นยืนยันแล้ว หมดอายุ หรือล้มเหลว สำหรับเวิร์กโฟลว์การจัดเตรียมหมายเลข โปรดจำไว้ว่าหมายเลขใช้การจัดเตรียมแบบ JIT การถือครองแบบเติมเงิน และการกำหนดทันที แทนที่จะเป็นสินค้าคงคลังแบบสถิตรุ่นเก่า การจัดสรรแบบไดนามิกนี้หมายความว่าไปป์ไลน์การติดตามของคุณต้องจัดการกับการเปลี่ยนผ่านสถานะทันทีในระหว่างรอบการซื้อและปล่อยหมายเลขเสมือนได้อย่างราบรื่น.
แนวปฏิบัติในการใช้งานที่แนะนำ
การสร้างไปป์ไลน์การติดตามที่ยืดหยุ่นต้องมีการเขียนโค้ดเชิงป้องกันเพื่อรับมือกับ webhook ที่หายไป payload ที่ผิดรูปแบบ และการส่งซ้ำที่ซ้ำซ้อน คุณควรใช้การเขียนฐานข้อมูลแบบ idempotent และกลไกการลองใหม่ที่เชื่อถือได้ สำหรับคำแนะนำทางสถาปัตยกรรมเพิ่มเติม โปรดตรวจสอบเอกสารดังต่อไปนี้: idempotency การลองใหม่ และเงิน, ลายเซ็น webhook และหน้าต่างเล่นซ้ำ, และ ID สหสัมพันธ์ข้าม debit และ DLR.
เริ่มต้นใช้งานกับ IOSOR
เลือก SMS หรือ OTP ขาออกหนึ่งฉบับ ประทับ correlation ID บนคำขอ API ก่อน accept แล้วเดินสายเดียวกันผ่านเมทาการส่งและตัวเนื้อ webhook ของ DLR ส่งออกรายการฮ็อป: รหัสคำขอ เวลารับ การมาถึงของเว็บฮุก สถานะปลายทาง อย่าหยุดที่ HTTP 200 และอย่าเรียกการเดินนี้ว่าการต่อแถวหักเงิน สัญญานั้นอยู่ในบทพี่น้อง
สรุป IOSOR
การตามคำขอถึง DLR คือโซ่ฮ็อป การรับไม่ใช่การส่งถึง
ทำ: รักษา ID ที่ไม่เปลี่ยนจากตัวเนื้อ API แรกถึง webhook ลงนามสุดท้าย
อย่า: ปิดตั๋วที่ HTTP 200 หรือประกอบเส้นทางจากตราเวลาผู้ให้บริการหลัง DLR หล่น
คู่มือนี้มีประโยชน์ไหม?
คู่มือที่เกี่ยวข้อง
- การจำลองความหน่วงและข้อผิดพลาด DLR ในการทดสอบการบูรณาการภายใน
เรียนรู้วิธีการจำลองใบรับรองการส่งมอบแบบอะซิงโครนัส จัดการความหน่วงของ DLR และทดสอบกรณีขอบในเครื่องก่อนโปรโมตการบูรณาการ CPaaS ของคุณ
- การสร้างสมดุลระหว่างการจัดกลุ่มชุดข้อมูลและปริมาณงาน API คำขอเดี่ยว
เพิ่มประสิทธิภาพกลยุทธ์ความพร้อมใช้งาน API สำหรับการส่งการแจ้งเตือนปริมาณมาก พร้อมทั้งรักษากฎการจำกัดอัตราในคอนโซล CPaaS แบบป้ายกำกับขาวของคุณ
- การกำหนดขอบเขตคีย์ API แบบหลายผู้เช่าเพื่อความปลอดภัยของแพลตฟอร์ม
รักษาความปลอดภัยให้บัญชีย่อย CPaaS แบบป้ายกำกับสีขาว โดยการกำหนดขอบเขตโทเค็น API เพื่อแยกการรับส่งข้อมูลของผู้เช่า ป้องกันการรั่วไหลของข้อความข้ามบัญชี และบังคับใช้ขีดจำกัดทางการเงิน