← บทความทั้งหมด
บทช่วยสอน

หยุด runtime ของ UnifyPort โดยไม่ให้ระบบกู้คืนเปิดการเชื่อมต่ออีก

หากต้องการหยุดการเชื่อมต่อบัญชีรับส่งข้อความของ UnifyPort ชั่วคราวโดยไม่ลบบัญชี ให้ส่ง {} ไปยัง POST /v1/accounts/{account_id}/runtime/stop และยืนยันว่า runtime_status เป็น stopped ส่วน stopping ยังต้องตรวจสอบต่อ ก่อนเรียก API ควรแจ้งระบบกู้คืนของแอปว่าการหยุดนี้เป็นความตั้งใจ มิฉะนั้น worker ที่คอยรักษาการเชื่อมต่ออาจเปิดบัญชีกลับขึ้นมาอีก

ประเด็นสำคัญ

  • การหยุด runtime ยังคงเก็บบัญชีไว้ ไม่ใช่การลบบัญชี
  • บันทึกคำสั่งพักในพื้นที่จัดเก็บถาวรของแอปก่อนหยุดการเชื่อมต่อ
  • สถานะ runtime_status ที่สังเกตได้ กับการอนุญาตให้กู้คืน เป็นคนละเรื่องกัน
  • การเปิดการเชื่อมต่อใหม่ไม่ได้พิสูจน์ว่าข้อความระหว่างหยุดถูกกู้คืนแล้ว

การกู้คืนที่ถูกต้อง แต่อาจเกิดผิดเวลา

สมมติว่าผู้ดูแลหยุดบัญชีสำหรับงานบำรุงรักษาระบบบริการลูกค้าบน LINE จากนั้น worker ตรวจสุขภาพอ่านค่า stopped และเรียก start เพราะถูกออกแบบให้รักษาบัญชีให้ออนไลน์ นี่เป็นสถานการณ์ตัวอย่าง ไม่ใช่เหตุขัดข้องของลูกค้าที่รายงานจริง คำขอทั้งสองอาจถูกต้องตาม API แต่ขัดกับเจตนาของผู้ดูแล

วิธีแก้ไม่ใช่การเข้าสู่ระบบอีกครั้ง แต่คือการตัดสินใจร่วมกันในแอปว่า ขณะนี้บัญชีควรออนไลน์หรือไม่ คู่มือกู้คืน runtime อธิบายการกู้คืนการเชื่อมต่อที่ควรออนไลน์ ส่วนการหยุดตามแผนต้องเพิ่มเงื่อนไขควบคุมก่อนเริ่มตรรกะนั้น

เงื่อนไขนี้ไม่ใช่การตั้งค่า API ใหม่ เอกสารวงจรชีวิตบัญชี แยก status ของบัญชี สถานะการยืนยันตัวตน และ runtime_status ออกจากกัน บันทึกการพักที่เสนอในบทความเป็นข้อมูลของแอปเอง ไม่ใช่ฟิลด์ UnifyPort และไม่ใช่พฤติกรรมที่รับประกันจากการเปลี่ยน status ของบัญชี

เลือกก่อนว่าต้องหยุดส่วนใด

เป้าหมายจุดควบคุมที่เหมาะสม
หยุดเขียน CRM หรือประมวลผล AI แต่ยังรับข้อความพัก consumer ของแอป
หยุดการเชื่อมต่อสดของบัญชี แต่เก็บบัญชีไว้Stop runtime
เลิกใช้และนำทรัพยากรบัญชีออกกระบวนการลบบัญชีแยกต่างหาก

หากบำรุงรักษาเฉพาะระบบปลายทาง ให้ดู การเปรียบเทียบวิธีพัก webhook และ worker การหยุดการเชื่อมต่อไม่ใช่วิธีพักข้อความไว้ในบัฟเฟอร์ถาวร

ใช้ คู่มือลบบัญชี เฉพาะเมื่อตั้งใจเลิกใช้ทรัพยากร ข้อกำหนดของ runtime stop ไม่ได้สัญญาว่าจะคืนเงิน พักสมาชิก ลบบัญชีบนแพลตฟอร์มต้นทาง หรือลบข้อความที่จัดเก็บไว้

ทำให้ worker เห็นคำสั่งพักก่อนส่งคำขอหยุด

ขั้นตอนต่อไปนี้เป็นคำแนะนำสำหรับการออกแบบแอป:

  1. ตรวจ workspace, account_id, ช่องทาง ผู้ดำเนินการ และเหตุผล อ่านข้อมูลบัญชีกับสถานะยืนยันตัวตนแยกกัน
  2. บันทึกคำสั่งพักสำหรับบัญชีนี้อย่างถาวร ให้ทั้ง worker กู้คืนและ worker ส่งข้อความตามกำหนดตรวจบันทึกก่อนส่งคำขอใหม่
  3. ประสานงานกับงานที่เริ่มแล้ว แฟล็กที่เพิ่งบันทึกไม่สามารถยกเลิก API request ที่ส่งออกไปแล้วได้ ใช้การประสานงานรายบัญชีของแอปและตรวจผลของคำขอที่ยังดำเนินอยู่
  4. เปิด receiver ของ webhook ไว้เพื่อยืนยันและบันทึกเหตุการณ์ที่ยังเข้ามา อย่าตีความ runtime stop ว่ารอจนการส่ง webhook ทั้งหมดเสร็จสิ้น
  5. ส่งคำขอหยุดที่ตรวจทานแล้วหนึ่งครั้ง จากนั้นตรวจผล

ตัวอย่างนี้เป็นรหัสเทียมของแอป ไม่ใช่ไวยากรณ์ SDK หรือ endpoint ใหม่:

ก่อนเรียก start หรือ reconnect อัตโนมัติ:
    อ่านเจตนาการทำงานปัจจุบันของบัญชีจากข้อมูลภายในแอป
    ถ้าผู้ดูแลสั่งพัก:
        ไม่ส่งคำขอกู้คืน
    ถ้าไม่ใช่:
        ตรวจสถานะยืนยันตัวตนและ runtime
        เลือกการกู้คืนตามเอกสาร

ทุกช่องทางกู้คืนต้องใช้เงื่อนไขเดียวกัน รวมถึงงานที่หน่วงเวลาและปุ่มกู้คืนด้วยมือ ประสานการเปลี่ยนคำสั่งพักและเปิดใหม่ เพื่อไม่ให้งาน start เก่ากลับมามีสิทธิ์ทำงานเพียงเพราะมีการเปลี่ยนหน้าจอภายหลัง

หยุดหนึ่งครั้ง แล้วตรวจสถานะจริง

เอกสาร Stop runtime ระบุให้ส่ง JSON object ว่าง ตัวอย่างต่อไปนี้ยังไม่ได้รันจริง กำหนดตัวแปรจากบัญชีที่ backend ตรวจแล้วและ API key ที่จัดเก็บอย่างปลอดภัย:

curl -X POST \
  "https://api.unifyport.ai/v1/accounts/${UNIFYPORT_ACCOUNT_ID}/runtime/stop" \
  -H "X-Api-Key: ${UNIFYPORT_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{}'

เก็บ API key ไว้ฝั่งเซิร์ฟเวอร์ บันทึก HTTP status และข้อมูลวินิจฉัยคำขอที่มี โดยไม่บันทึกความลับ

สิ่งที่พบความหมายและขั้นตอนถัดไป
runtime_status: stoppedหยุดระดับ runtime แล้ว แต่ยังคงคำสั่งพักในแอป
runtime_status: stoppingอยู่ระหว่างเปลี่ยนสถานะ ต้องตรวจต่อ
Timeout หรืออ่าน response ไม่ได้ยังไม่ทราบผล อ่านสถานะก่อนแก้ไขซ้ำ
แอปยังสั่งพัก แต่ runtime กลับเป็น runningตรวจเส้นทาง start หรือ reconnect ที่แข่งขันกัน อย่ารายงานว่าพร้อมบำรุงรักษาแล้ว

ใช้ Get account หรือ Refresh runtime state เพื่อตรวจสอบ Refresh เป็นการซิงก์สถานะ ไม่ใช่การสั่งเริ่มใหม่ กำหนดนโยบายตรวจซ้ำและส่งต่อปัญหาที่มีขอบเขตในแอป โดยไม่สมมติระยะเวลาสิ้นสุดตายตัว

อย่ารอเหตุการณ์ account.stopped ที่ไม่มีในรายการสาธารณะ เอกสารวงจรชีวิตระบุว่า account.status.updated ไม่ได้รับประกันสำหรับทุกการเปลี่ยนสถานะจากคำขอ การไม่มีข้อความเข้าไม่ได้พิสูจน์ว่า runtime หยุดแล้ว

เปิดใช้งานใหม่เป็นการเปลี่ยนสถานะที่ต้องยืนยันแยกกัน

ยังคงระงับงานส่งข้อความขณะตรวจสถานะยืนยันตัวตนของบัญชี หากต้องให้ผู้ใช้ดำเนินการ ให้ทำตามขั้นตอนยืนยันตัวตนที่เกี่ยวข้อง เมื่อยืนยันสำเร็จ runtime มักเริ่มโดยอัตโนมัติ จึงไม่ควรเริ่มยืนยันตัวตนใหม่ระหว่างพักโดยไม่ตั้งใจ

หากการยืนยันยังใช้ได้และ runtime หยุดอยู่ ให้ใช้ Start runtime ประสานคำสั่งเปิดใหม่กับการควบคุมภายในแอป ตรวจจนเป็น running จริง เพราะ starting ยังไม่ใช่การเสร็จสิ้น

ก่อนปล่อยงานสะสม ตรวจว่าแต่ละงานยังเหมาะจะทำหรือไม่ ส่งข้อความทดสอบที่ควบคุมได้ แล้วติดตามเหตุการณ์ใหม่ผ่านการตรวจลายเซ็นและการจัดเก็บ จากนั้นจึงเปิด consumer และนโยบายกู้คืนอัตโนมัติที่ต้องการ

อินเทอร์เฟซที่ไม่เป็นทางการของ UnifyPort ไม่รับประกันการส่ง payload ที่พลาดซ้ำ และไม่มี REST API ทั่วไปสำหรับอ่านประวัติข้อความ บันทึกช่วงหยุดว่าอาจมีช่องว่างการรับข้อมูล การทดสอบข้อความใหม่สำเร็จพิสูจน์เพียงเส้นทางที่กลับมาทำงาน ไม่ใช่การเติมช่องว่างนั้น

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

Stop ลบบัญชีรับส่งข้อความหรือไม่?

ไม่ลบ เอกสารระบุว่าหยุด runtime โดยเก็บบัญชีไว้ การเริ่มใหม่เป็นอีกการกระทำหนึ่ง

Worker ควรเปิดทุกบัญชีที่เป็น stopped หรือไม่?

ไม่ควร ต้องตรวจว่าแอปต้องการให้บัญชีนั้นออนไลน์ในขณะนี้หรือไม่ สถานะ runtime ไม่ได้บอกเจตนาของผู้ดูแล

หยุดสำเร็จแล้วจะยกเลิกข้อความตอบกลับในคิวหรือ webhook หรือไม่?

อย่าสมมติเช่นนั้น จัดการงานในแอปแยกต่างหาก ข้อกำหนดสาธารณะไม่ได้สัญญาว่าจะยกเลิกงานที่ส่งไปแล้วหรือรอให้ webhook หมด

หยุดแล้วพักการคิดค่าบริการด้วยหรือไม่?

ข้อกำหนด runtime stop ไม่ได้สัญญาเรื่องนี้ อย่าใช้สถานะการเชื่อมต่อเป็นหลักฐานการเปลี่ยนแปลงทางการเงิน

ขั้นตอนต่อไปและแหล่งอ้างอิง

พัฒนาการควบคุมสิทธิ์กู้คืนร่วมกับ Stop runtime ทดสอบ worker ที่แข่งขันกัน คำขอ start ที่ยังทำงานอยู่ response หยุดที่สูญหาย สถานะ stopping การเปิดใหม่โดยตั้งใจ และข้อความตอบกลับเก่าในคิว รายการนี้เป็นข้อเสนอการทดสอบ ไม่ใช่ผลที่ผ่านแล้ว

ตรวจเอกสารเมื่อ 2026-11-04:

UnifyPort API

เปลี่ยนการเชื่อมต่อข้อความให้เป็น pipeline ผลิตภัณฑ์ที่เสถียร

เริ่มจากการส่งผ่าน API เดียว แล้วส่งข้อความขาเข้าทั้งหมดกลับสู่ระบบธุรกิจของคุณด้วย event มาตรฐาน