Skip to main content

กฎทริกเกอร์และงานตั้งเวลา

ภาพรวม​

Trigger rule คือกฎในรูปแบบ "เมื่อเกิดเหตุการณ์ X ให้ทำ Y" ทำหน้าที่เชื่อมเหตุการณ์จริงที่เกิดขึ้นในระบบ เข้ากับการกระทำที่ต้องการ

  • ต้นเหตุ (source) เช่น attribute ของเพื่อนเปลี่ยนค่า มีการส่งฟอร์ม มีการกดลิงก์แคมเปญ มีเพื่อนใหม่เพิ่มบัญชี หรือถึงเวลาตามตารางที่ตั้งไว้
  • การกระทำ (action) เช่น ส่งข้อความ เพิ่มผู้ใช้เข้ากลุ่มเป้าหมาย สลับ rich menu หรือเดิน workflow ต่อจากโหนดที่ค้างอยู่

การกระทำที่ต้องรอเวลาจะไม่ถูกดำเนินการทันที แต่ถูกบันทึกไว้ในคิว scheduled_action จนกว่าจะถึงกำหนด ส่วนกฎที่ทำงานตามตารางเวลาจะมีตาราง scheduled_trigger_execution ทำหน้าที่ป้องกันการรันซ้ำในรอบเดียวกัน

โครงสร้างข้อมูลหลัก​

trigger_rule — ตัวกฎ​

เก็บนิยามของกฎแต่ละข้อ โดยแยกส่วนต้นเหตุและส่วนการกระทำออกจากกันอย่างชัดเจน

กลุ่มข้อมูลคอลัมน์รายละเอียด
ต้นเหตุsource_type, source_configประเภทเหตุการณ์ พร้อมพารามิเตอร์แบบ JSONB
การกระทำaction_type, action_configประเภทการกระทำ พร้อมพารามิเตอร์แบบ JSONB
การควบคุมความถี่enabled, frequency, cooldown_secondsค่าเริ่มต้นของ frequency คือ once_per_hour
การผูกกับผังงานworkflow_id, workflow_node_pathใช้เมื่อกฎเป็นส่วนหนึ่งของ workflow
ขอบเขตline_oa_id, organization_idแยกข้อมูลตามช่องทางและองค์กร

ตารางนี้ใช้ soft delete ผ่าน deleted_date และมี index บน (line_oa_id, organization_id) กับ (deleted_date) เพื่อรองรับการดึงเฉพาะกฎที่ยังใช้งานอยู่ของแต่ละช่องทาง

trigger_log — ประวัติการทำงาน​

บันทึกทุกครั้งที่กฎถูกประเมินและทำงาน ใช้ primary key แบบ BIGINT เพราะมีปริมาณข้อมูลสูง

  • อ้างอิงกลับ: trigger_rule_id, audience_id, user_id (LINE userId), trigger_on
  • เก็บ action_type และ action_config ที่ใช้จริงในขณะนั้น ทำให้ตรวจสอบย้อนหลังได้แม้กฎจะถูกแก้ไขไปแล้ว
  • ผลลัพธ์: status (ค่าเริ่มต้น success) และ error_message
  • index (trigger_rule_id, created_date DESC) รองรับหน้าดูประวัติของกฎแต่ละข้อ

scheduled_action — คิวงานตั้งเวลา​

เก็บงานที่ถูกสร้างจากกฎแต่ยังไม่ถึงเวลาดำเนินการ

  • ข้อมูลงาน: trigger_rule_id (เว้นว่างได้), user_id, action_type, action_config, source_config
  • เวลา: execute_at, expires_at, executed_at
  • สถานะ: status (ค่าเริ่มต้น pending) และ retry_count
  • workflow_id กับ workflow_node_path ใช้เดิน workflow ต่อจากจุดที่หยุดรอ

ชุด index ถูกออกแบบตามรูปแบบการใช้งานจริง ได้แก่ idx_scheduled_action_pending (execute_at) สำหรับดึงงานที่ถึงกำหนด, idx_scheduled_action_processing (updated_at) สำหรับ reaper ที่คอยเก็บกวาดงานค้างสถานะ processing และ idx_scheduled_action_user (user_id, trigger_rule_id) สำหรับตรวจสอบว่าผู้ใช้รายนี้มีงานค้างจากกฎเดิมอยู่หรือไม่

scheduled_trigger_execution — รอบการรันตามตาราง​

หนึ่งแถวแทนหนึ่งรอบของกฎที่ทำงานตามเวลา หัวใจของตารางนี้คือ unique constraint (trigger_rule_id, scheduled_at) ชื่อ uq_scheduled_trigger_execution ซึ่งทำให้แม้มี worker หลายตัวพยายามรันรอบเดียวกันพร้อมกัน ก็จะมีเพียงตัวเดียวเท่านั้นที่สร้างแถวสำเร็จ

นอกจากนี้ยังเก็บสถานะและสถิติของรอบนั้น ได้แก่ started_at, completed_at, status (ค่าเริ่มต้น processing), total_users, processed_users, failed_users และ error_message

ไฟล์ที่เกี่ยวข้อง​

  • prisma/schema.prisma:1340 — model TriggerRule
  • prisma/schema.prisma:1369 — model TriggerLog
  • prisma/schema.prisma:1494 — model ScheduledAction
  • prisma/schema.prisma:1520 — model ScheduledTriggerExecution
  • manual-sql/1.notify_attribute_change.sql, manual-sql/2.notify_attribute_change.sql, manual-sql/3.bank.sql, manual-sql/4.sql, manual-sql/5.sql — trigger pg_notify ที่ทำหน้าที่เป็นต้นเหตุของกฎ
  • schema-dumps/2026-07-24/schema.sql:3077, :3038, :2706, :2751

จุดเชื่อมต่อกับ Service อื่น​

  • worker-go เป็นหัวใจของ domain นี้ โดย pg-listener จะรับเหตุการณ์ attribute_changed, form_submitted, campaign_click, friend_track_event_inserted และ booking_event แล้วประเมินกฎที่ตรงเงื่อนไข เขียน trigger_log และสร้างหรือรัน scheduled_action
  • cms-api-go ดูแลการสร้างและแก้ไขกฎผ่านโมดูล trigger-rule รวมถึงหน้าดูประวัติการทำงาน
  • เชื่อมโยงกับ ผังงาน (Workflow), pg_notify และ Event Outbox, กลุ่มเป้าหมาย และ ระบบติดตามลิงก์