ในหน้านี้
อัปเดตคำสั่งซื้อมาก่อนเหตุการณ์สร้างคำสั่งซื้อ อีกแห่ง เหตุการณ์ชำระเงินมาก่อนเหตุการณ์สมัครบริการที่เกิดก่อนหน้า นี่เป็นทีมสมมติที่ใช้ผลิตภัณฑ์และ payload ต่างกัน ทั้งคู่ถูกล่อให้ซ่อมด้วยการเรียงการส่งตามเวลาที่มาถึง
นี่ไม่ใช่รายงานเหตุขัดข้องของทีมใด มันถามว่าความล้มเหลวสองอย่างมีรูปแบบร่วมไหมแม้รายละเอียดผู้ให้บริการต่าง
บทสนทนาที่เก็บมาเรื่องความเชื่อมโยงทางคณิตศาสตร์ สังเกตว่าปัญหาที่ดูต่างกันอาจมีรูปแบบร่วมที่มีประโยชน์ การใช้แนวคิดนี้กับการเชื่อมต่อซอฟต์แวร์เป็นข้ออนุมาน จะมีประโยชน์ก็ต่อเมื่อรูปแบบร่วมสร้างการทดสอบที่พฤติกรรมในเอกสารของแต่ละระบบรองรับ
ตัดชื่อออก แล้วใส่ข้อกำหนดทางเทคนิคกลับ
อธิบายกรณีแรกโดยไม่เอ่ยผลิตภัณฑ์: เหตุการณ์เกี่ยวกับทรัพยากรอาจมาถึงหลังการเปลี่ยนที่ใหม่กว่าของทรัพยากรเดียวกัน ตัวรับที่ถือเวลามาถึงเป็นลำดับสถานะอาจเขียนข้อมูลเก่าทับใหม่
แล้วตรวจข้อกำหนดจริงของสองบริการ เอกสาร Webhook ของ Shopify ระบุว่าไม่รับประกันลำดับแม้ในหัวข้อเดียว และยกตัวอย่างอัปเดตผลิตภัณฑ์มาก่อนการส่งเหตุการณ์สร้างผลิตภัณฑ์ เอกสาร Webhook ของ Stripe ก็ระบุว่าเหตุการณ์ไม่รับประกันมาถึงตามลำดับที่สร้าง และแนะนำให้ดึงออบเจ็กต์ที่ขาดเมื่อเหตุการณ์ก่อนหน้าที่คาดยังไม่มา
Shopify และ Stripe ต่างเตือนว่าลำดับส่งเหตุการณ์ไม่รับประกัน คำถามร่วมคือสถานะสุดท้ายถูกไหม แต่ตัวระบุและกฎกู้คืนของแต่ละรายต้องทดสอบเอง
คำถามที่ย้ายได้คือ “หากเหตุการณ์นี้มาก่อนเหตุการณ์ที่เกี่ยวข้อง เรายังหาสถานะปัจจุบันที่ถูกได้ไหม” คำตอบด้านการทำงานย้ายตามสมมติไม่ได้ Shopify อธิบายส่วนหัวเช่น X-Shopify-Webhook-Id และเวลา Stripe ใช้ ID เหตุการณ์และกฎดึงออบเจ็กต์ของตน ตัวระบุที่หมายถึง “การส่ง” ในระบบหนึ่งอาจไม่ได้หมายเหมือนอีกระบบ
คู่มือคอนเน็กเตอร์ Brevo ของเรา ว่าด้วยฟิลด์และการแมปอีกชุด รายละเอียดเหล่านั้นสำคัญต่อการเชื่อมต่อที่ใช้งานได้ แต่ไม่ควรถูกเข้าใจเป็นพฤติกรรม API สากล
รูปแบบร่วมคือสิ่งที่ต้องคงจริง
สำหรับการซิงค์ลูกค้า สิ่งที่ต้องคงจริงอาจเป็น: หลังประมวลผล ระเบียนลูกค้าปลายทางสะท้อนสถานะปัจจุบันของต้นทางที่ได้รับอนุญาต สำหรับการเรียกเก็บเงิน อาจเป็น: การกระทำที่ขึ้นกับการชำระเงินเกิดเฉพาะเมื่อสถานะชำระเงินจากแหล่งข้อมูลที่มีอำนาจยืนยัน สิ่งนี้ตั้งชื่อเรื่องที่ต้องจริงแม้เหตุการณ์ช้า ซ้ำ หรือไม่ครบ
เขียนสี่ข้อก่อนเลือกวิธีแก้:
| คำถาม | ทำไมสำคัญ |
|---|---|
| ตัวระบุใดชี้ออบเจ็กต์ธุรกิจ | ID เหตุการณ์อาจชี้ข้อความ ไม่ใช่ลูกค้าหรือคำสั่งซื้อ |
| ระบบใดเป็นเจ้าของสถานะปัจจุบัน | payload อาจเป็นภาพรวม การเปลี่ยน หรือเพียงตัวชี้ |
| ต้นทางรับประกันเวลาแบบไหน | ลำดับส่งอาจไม่ใช่ลำดับสถานะ |
| เงื่อนไขปลายทางใดพิสูจน์สำเร็จ | รับเหตุการณ์ไม่ได้พิสูจน์ว่าปลายทางถูก |
ตารางช่วยคิด ไม่ใช่โปรโตคอล คำตอบเรื่องแหล่งข้อมูลหลักขึ้นกับเวิร์กโฟลว์ การค้นสดอาจจำเป็นในระบบหนึ่งและไม่เหมาะในอีกระบบ เหตุการณ์บางอย่างต้องเก็บเป็นข้อเท็จจริงประวัติ ไม่ใช่รวมเป็นภาพล่าสุด
ใช้การทดสอบซ้ำ แล้วปรับวิธีแก้
การทดสอบตามข้อกำหนดทางเทคนิคแบบเล็กอาจส่งเหตุการณ์ที่เกี่ยวกันย้อนลำดับแล้วถามว่าสถานะสุดท้ายปลายทางยังถูกไหม อีกการทดสอบส่งเหตุการณ์เดิมสองครั้ง สิ่งเหล่านี้เผยรูปแบบความเสี่ยง จากนั้นเอกสารผู้ให้บริการกำหนดวิธีระบุ ยืนยัน และกู้คืนแต่ละเหตุการณ์
ความต่างนี้ปกป้องทีมจากสถาปัตยกรรมคัดลอก คีย์กันซ้ำของ API หนึ่งอาจใช้ไม่ได้ในอีก API เวลาแบบหยาบอาจเรียงลำดับไม่ได้ การดึงออบเจ็กต์ปัจจุบันอาจจำเป็นต่อซิงค์สถานะ แต่สร้างทุกเหตุการณ์ประวัติระหว่างทางคืนไม่ได้ คู่มือเชื่อมต่อเครื่องมือธุรกิจหลายตัว เริ่มจากเลือกระบบเจ้าของแต่ละฟิลด์ หากไม่มีการเลือก “ใหม่สุด” ไม่มีความหมายชัด
การย้ายรูปแบบมีขอบเขต อาการคล้ายอาจมาจากเหตุต่างกัน: ระเบียนหายเพราะคำค้นไม่มีสิทธิ์ Webhook ล่าช้า การแมปผิด หรือการเขียนถูกปฏิเสธ ก่อนประกาศว่าสองกรณีเหมือนกัน เทียบข้อกำหนดของต้นทางและปลายทาง และเงื่อนไขหลังที่สังเกต หากอย่างใดต่าง ให้เก็บคำถามร่วมและเปลี่ยนการทดสอบ
วิธียังใช้ได้เกินการส่งเหตุการณ์ ฟิลด์ที่ API รับแต่ไม่ปรากฏในระเบียนที่ผู้ใช้เห็นตั้งคำถามทั่วไปเดียวกันในทุกคอนเน็กเตอร์: การตอบรับพิสูจน์อะไร และหลักฐานไหนพิสูจน์สถานะที่ตั้งใจ คำตอบอาจต้องอ่านปลายทาง ค้นสคีมา หรือตรวจสิทธิ์ รูปแบบบอกทีมให้แยกการขนส่งจากความหมาย ไม่ได้บอกว่าควรเรียกฟิลด์หรือ endpoint ใด บทเรียนแคบนี้น่าตื่นเต้นน้อยกว่าสูตรการเชื่อมต่อสากล แต่เดินทางได้ไกลกว่าเพราะเก็บข้อเท็จจริงในพื้นที่ไว้
บทเรียนใช้ซ้ำที่แข็งแรงที่สุดไม่ใช่โค้ดชิ้นหนึ่ง แต่เป็นคำถามที่ยังใช้ได้เมื่อย้ายไปอีกระบบและช่วยให้ตรวจข้อกำหนดเฉพาะของระบบนั้นง่ายขึ้น
คำถามที่พบบ่อย
การทดสอบการเชื่อมต่อเดียวกันใช้ซ้ำข้ามผู้ให้บริการได้ไหม?
คำถามมักย้ายได้ เช่น อัปเดตมาผิดลำดับได้ไหม แต่ ID เหตุการณ์ ความหมาย payload ลายเซ็น และขั้นกู้คืนต้องมาจากข้อกำหนดทางเทคนิคของผู้ให้บริการแต่ละราย
รูปแบบกับการแก้ที่คัดลอกต่างกันอย่างไร?
รูปแบบระบุเงื่อนไขล้มเหลวและสิ่งที่ต้องคงจริง การแก้คัดลอกสมมติว่าระบบที่สองมีตัวระบุ ลำดับ และความหมายสถานะเหมือนกันโดยไม่ตรวจ
หลังใช้เหตุการณ์ควรตรวจอะไร?
ตรวจสถานะปลายทางที่เวิร์กโฟลว์ต้องการ ไม่ใช่แค่รับเหตุการณ์หรือคำตอบ HTTP เงื่อนไขปลายทางขึ้นกับออบเจ็กต์ธุรกิจและกฎแหล่งข้อมูลหลัก