Idempotency ใน YonLinker: Retry, Replay และ Reconciliation อย่างปลอดภัย
ออกแบบ Business Key, สถานะประมวลผล และ Replay Control สำหรับ Order, Journal และ Stock ไม่ให้ Network Retry ทำผลซ้ำ
เป้าหมายการเรียนรู้
พิสูจน์ว่าการส่งซ้ำสร้างผลธุรกิจเพียงครั้งเดียว
บทบาทที่เหมาะสม
เจ้าของธุรกิจ หัวหน้า Data/Integration, IT Operations, Security และ Audit
เงื่อนไขก่อนเริ่ม
- ส่งซ้ำได้ผลครั้งเดียว
- Key Conflict ถูกบล็อกและ Alert
- Replay มีอนุมัติและ Audit
การตรวจผลลัพธ์
- ส่งซ้ำได้ผลครั้งเดียว
- Key Conflict ถูกบล็อกและ Alert
- Replay มีอนุมัติและ Audit
ข้อผิดพลาดที่พบบ่อย
- ใช้ Timestamp เป็น Key
- ลบ Key เร็วเกินไป
- รัน Batch ที่สำเร็จบางส่วนซ้ำ
หมายเหตุสำหรับโครงการไทย
ประเทศไทยต้องยืนยันข้อมูลหลายภาษา THB/เงินต่างประเทศ เวลา Asia/Bangkok การแยกหน้าที่และการเก็บเอกสาร เรื่องภาษี ศุลกากร BOI และบัญชีตามกฎหมายต้องให้ผู้เชี่ยวชาญไทยตรวจ
โมดูลที่เกี่ยวข้อง
ขั้นตอน
- 01
เลือก Key คงที่ต่อ Message Type และใส่ Namespace ระบบต้นทาง
- 02
เก็บสถานะ Received, Validated, Processing, Success, Rejected, Quarantine และผลแรก
- 03
Key และเนื้อหาเดิมคืนผลเก่า ส่วน Key เดิมเนื้อหาต่างต้อง Alert
- 04
แยก Transport Retry จาก Business Replay ที่ต้องอนุมัติ Scope และเหตุผล
- 05
ใช้ Checkpoint และ Compensating Action สำหรับ Partial Success ห้ามรัน Batch ซ้ำทั้งหมด
- 06
เก็บ Key นานกว่า Retry Window สูงสุดและ Monitor Capacity
- 07
ทดสอบ Duplicate, Concurrent, Timeout หลังสำเร็จ, Out-of-order และ Replay จาก Quarantine พร้อมกระทบยอด
ข้อแนะนำการติดตั้ง
- ส่งซ้ำได้ผลครั้งเดียว
- Key Conflict ถูกบล็อกและ Alert