คำถามที่พบบ่อย (FAQs)

ข้อกำหนดทางธุรกิจ: ต้องรองรับโหมดการสมัครรับข้อมูลหลายรูปแบบเพื่อตอบสนองความต้องการของผู้ใช้ที่แตกต่างกัน 1. รองรับโหมดการสมัครรับข้อมูล 3 รูปแบบ: - การสมัครรับข้อมูลแบบทั่วโลก: สมัครรับเหตุการณ์ของทรัพยากรที่เกี่ยวข้องทั้งหมด หลังจากบัญชีหลักสมัครแล้ว บัญชีย่อยทั้งหมดจะถูกสมัครรับโดยอัตโนมัติตามค่าเริ่มต้น - สมัครรับข้อมูลตามผู้ใช้: ต้องระบุ object_ids ที่เฉพาะเจาะจง กล่าวคือรหัสผู้ใช้ - สมัครรับข้อมูลตามแบบสอบถาม: ต้องระบุ object_ids ที่เฉพาะเจาะจง กล่าวคือรหัสแบบสอบถาม 2. กฎการตั้งค่า: - ยกเว้นการสมัครรับข้อมูลแบบทั่วโลก โหมดการสมัครรับข้อมูลอื่นทั้งหมดต้องระบุ object_ids ที่สอดคล้องกัน - เมื่อสมัครรับข้อมูลตามผู้ใช้ เหตุการณ์ create questionnaire ไม่จำเป็นต้องมี object_ids - เมื่อสมัครรับข้อมูลตามแบบสอบถาม ไม่สามารถรวมเหตุการณ์ create questionnaire ได้

คำถามทางธุรกิจ: ต้องการชี้แจงประเภทเหตุการณ์ที่รองรับและขอบเขตเฉพาะของแต่ละประเภท 1. รองรับประเภทเหตุการณ์ 7 ประเภท: - สร้างแบบสำรวจ - แก้ไขแบบสำรวจ (เฉพาะการแก้ไขคำถาม ไม่รวมการเปลี่ยนแปลงการตั้งค่าแบบสำรวจ) - ลบแบบสำรวจ - การตอบแบบสำรวจเสร็จสมบูรณ์ - อัปเดตการตอบแบบสำรวจ - ลบการตอบแบบสำรวจ - การตอบแบบสำรวจไม่ถูกต้อง (ส่งคืนสาเหตุของความไม่ถูกต้อง)

ปัญหาทางธุรกิจ: ความยาวของฟิลด์การอนุญาตต้องถูกควบคุมเพื่อให้มั่นใจในความปลอดภัย กฎทางธุรกิจ: - ความยาวของฟิลด์การอนุญาตจำกัดไว้ที่ 0-512 อักขระ

ปัญหาทางธุรกิจ: ต้องมั่นใจในความน่าเชื่อถือของการเรียกกลับของเว็บฮุก กฎทางธุรกิจ: 1. ลองใหม่ได้สูงสุด 5 ครั้ง 2. ช่วงเวลาระหว่างการลองใหม่: - ลองใหม่ครั้งที่ 1: 10 วินาที - ลองใหม่ครั้งที่ 2: 1 นาที - ลองใหม่ครั้งที่ 3: 5 นาที - ลองใหม่ครั้งที่ 4: 30 นาที (ส่งอีเมลแจ้งเตือนเกี่ยวกับความล้มเหลวในการส่ง) - ลองใหม่ครั้งที่ 5: 1 วัน (ส่งอีเมลแจ้งเตือนว่าได้ปิดใช้งานการส่งแล้ว)

ปัญหาทางธุรกิจ: คุณต้องจัดการกับความล้มเหลวที่เกิดขึ้นต่อเนื่องและแจ้งให้ผู้ใช้ทราบ กฎทางธุรกิจ: 1. ระบบจะตั้งค่า webhook ทั้งหมดที่มี URL เดียวกันให้เป็นปิดใช้งานโดยอัตโนมัติ 2. ส่งการแจ้งเตือนทางอีเมลไปยังผู้ใช้ (อีเมลจะถูกส่งไปยังบัญชีหลัก) 3. บันทึกข้อมูลความล้มเหลวลงในคิวแยกต่างหาก โดยใช้ webhook id เป็นคีย์ (เก็บรักษาไว้ 7 วัน) 4. อนุญาตให้ผู้ใช้ backfill ข้อมูลได้ภายใน 7 วัน

ปัญหาทางธุรกิจ: จำเป็นต้องจัดการเหตุการณ์ในช่วงเวลาที่ webhook ถูกปิดใช้งาน 1. บันทึกเหตุการณ์ภายใน 7 วันหลังจากปิดใช้งานจะถูกจัดเก็บไว้ในคิวแยกต่างหาก 2. หากจำนวนครั้งที่ปิดใช้งานเกิน 1 ครั้ง โปรดติดต่อฝ่ายสนับสนุนด้านเทคนิค 3. หลังจากเปิดใช้งานอีกครั้ง ข้อมูลในคิวจะถูกส่งแบบเชิงรุก

คำถามทางธุรกิจ: จำเป็นต้องบันทึก log การเรียก webhook เพื่อใช้ในการแก้ไขปัญหา กฎทางธุรกิจ: - การ callback ต้องรวมบันทึก log ของ Alibaba Cloud ในรูปแบบ JSON

ปัญหาทางธุรกิจ: ต้องป้องกันการกำหนดค่าเว็บฮุกซ้ำ กฎทางธุรกิจ: 1. การผสมผสานฟิลด์ต่อไปนี้ต้องไม่ซ้ำกัน: - subscription_model (โหมดการสมัครรับ) - event_type (ประเภทเหตุการณ์) - object_ids (รหัสวัตถุ) - url_subscription (URL สำหรับสมัครรับ) 2. ข้อยกเว้น: การใช้ url_subscription เดียวกันสำหรับเหตุการณ์ที่แตกต่างกันไม่ถูกจำกัด

คำถามทางธุรกิจ: ต้องใช้รูปแบบเวลาที่เป็นมาตรฐานเดียวกัน พร้อมทั้งมีลิงก์การเข้าถึงทรัพยากร กฎทางธุรกิจ: 1. Event Time ส่งคืนค่า timestamp ระดับมิลลิวินาที 2. พารามิเตอร์ที่ส่งแบบ push จะมี URL สำหรับเข้าถึงทรัพยากร

คำถามทางธุรกิจ: จำเป็นต้องชี้แจงประเภทสถานะของ webhook และผลกระทบของแต่ละสถานะ กฎทางธุรกิจ: สถานะของ webhook แบ่งออกเป็น 4 ประเภท: 1. ข้อมูลย้อนหลัง (status=0) 2. ใช้งานได้ (status=1) 3. ใช้งานไม่ได้ (status=2, ไม่ส่งข้อมูล) 4. ระบบปิดใช้งาน (status=3, การเรียกกลับล้มเหลวหลายครั้ง)