PIPEDREAM + JODOO

การส่งต่อการอนุมัติคำขอซื้อด้วย AI โดยใช้ Pipedream + Jodoo

ดูวิธีที่ Pipedream และ Jodoo จัดการการส่งต่อการอนุมัติคำขอซื้อ: ตรวจสอบคำขอต้นทาง ส่งคืนฟิลด์การตัดสินใจแบบมีโครงสร้าง เขียนผลลัพธ์กลับเข้า Jodoo และทำให้เจ้าของงาน สถานะ และขั้นตอนถัดไปมองเห็นได้ชัดเจน

1

ตรวจสอบข้อมูลคำขอซื้อด้วยเกณฑ์ที่สอดคล้องกัน

2

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

3

ทำให้คิวเจ้าของงานและสถานะการติดตามงานมองเห็นได้ชัดเจน

4

ใช้หลักฐานจาก Pipedream ก่อนปรับเวิร์กโฟลว์ให้เข้ากับแหล่งข้อมูลจริงในโปรดักชัน

5

หลักฐานสาธารณะใช้การทดสอบการทำงานของ Pipedream การตรวจสอบอีเวนต์ และบันทึกคำขอ เพื่อให้เจ้าของงานด้านเทคนิคตรวจสอบรูปแบบ payload และรายละเอียดการตอบกลับของ Jodoo ได้

วิดีโอแนะนำขั้นตอน

สิ่งที่เกิดขึ้นในเดโม Pipedream

วิดีโอแสดงให้เห็น Pipedream จัดการคำขอจากทีมบริการภาคสนามที่ขอแท็บเล็ตแบบทนทาน 12 เครื่อง พร้อมรหัสงบประมาณ กำหนดเวลาเริ่มใช้งาน ค่าใช้จ่ายโดยประมาณ และรายละเอียดการจัดการอุปกรณ์ที่ยังขาด จากนั้น Jodoo จะจัดเก็บเรคคอร์ดการปฏิบัติงาน

  1. HTTP trigger หรือการทดสอบแบบ manual รับคำขอ

    ทีมบริการภาคสนามขอแท็บเล็ตแบบทนทาน 12 เครื่อง พร้อมรหัสงบประมาณ กำหนดเวลาเริ่มใช้งาน ค่าใช้จ่ายโดยประมาณ และรายละเอียดการจัดการอุปกรณ์ที่ยังขาด

  2. Pipedream เตรียมฟิลด์รีวิวแบบมีโครงสร้าง

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

  3. ขั้นตอน API request เขียนข้อมูลไปยัง Jodoo

    การรันทดสอบส่งผลลัพธ์การรีวิวไปยัง Jodoo และได้รับ Jodoo data ID กลับจาก bridge

  4. หลักฐานจาก Pipedream ยังตรวจสอบย้อนหลังได้

    หลักฐานสาธารณะใช้การทดสอบการทำงานของ Pipedream การตรวจสอบอีเวนต์ และบันทึกคำขอ เพื่อให้เจ้าของงานด้านเทคนิคตรวจสอบรูปแบบ payload และรายละเอียดการตอบกลับของ Jodoo ได้

  5. Jodoo เก็บเรคคอร์ดของทีม

    แอป Jodoo จัดเก็บชื่อผู้ขอ แผนก วันที่ขอ ลำดับความสำคัญ หมวดหมู่สินค้า รายละเอียดสินค้า และจำนวน เพื่อการตรวจสอบและติดตามงาน

สรุปเดโม

Pipedream ตรวจสอบคำขอ ส่วน Jodoo ติดตามงานต่อ

การใช้งานนี้เหมาะกับทีมเทคนิคที่ต้องการเป็นเจ้าของ webhook มีบันทึกคำขอ และควบคุมขั้นตอนด้วยโค้ด หน้านี้แสดงการตั้งค่า webhook และเวิร์กโฟลว์ API การรันจริง และการเขียนข้อมูลกลับเข้า Jodoo หลักฐานเวิร์กโฟลว์เน้นมุมมอง API: trigger event, step output, response body, deployment state และ environment variables สำคัญกว่าหน้ากระดานแบบภาพ

เวิร์กโฟลว์ Pipedream

เวิร์กโฟลว์ Pipedream ใช้ขั้นตอน HTTP request เพื่อเรียก Jodoo bridge และบันทึกการตอบกลับให้ผู้พัฒนาดูได้

การตัดสินใจแบบมีโครงสร้าง

เวิร์กโฟลว์ส่งคืนสถานะการอนุมัติ สถานะการจัดหา เจ้าของงานจัดซื้อ เส้นทางการอนุมัติ ข้อมูลที่ขาด ยอดรวมโดยประมาณ ลำดับความสำคัญ และขั้นตอนถัดไปที่แนะนำ สำหรับคำขอแท็บเล็ตแบบทนทาน 12 เครื่องสำหรับทีมบริการภาคสนาม พร้อมเคสป้องกันและการสนับสนุนการลงทะเบียนอุปกรณ์

การทดสอบ Pipedream สำเร็จ

การรันทดสอบของ Pipedream แสดงว่าคำขอรูปแบบ API เสร็จสมบูรณ์ และ bridge ส่งคืน Jodoo data ID

รายละเอียดการใช้งาน Pipedream

เริ่มด้วย HTTP trigger หรืออีเวนต์ทดสอบแบบ manual ตรวจสอบ JSON payload และเก็บการเขียนข้อมูลกลับเข้า Jodoo ไว้ในขั้นตอน request ที่ตั้งชื่อไว้

รายละเอียดสูตรการทำงานสำหรับคำขอซื้อ

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

การเขียนข้อมูลกลับเข้า Jodoo

Jodoo จัดเก็บเรคคอร์ดคำขอซื้อและทำให้ขั้นตอนถัดไปมองเห็นได้ชัดเจน

การติดตามงานเชิงปฏิบัติการ

ขั้นตอนถัดไปที่แนะนำคือขอใบเสนอราคาจากผู้ขาย ยืนยันการอนุมัติจากเจ้าของงบประมาณ และส่งต่อคำขอไปยังฝ่ายการเงินก่อนเริ่มจัดหา

ชุดเครื่องมือที่นำกลับมาใช้ได้

ชุดสรุปประกอบด้วยคู่มือ พิมพ์เขียวฟิลด์ Jodoo และสูตรการทำงานเวิร์กโฟลว์ Pipedream

หมายเหตุการตั้งค่าแพลตฟอร์ม

สิ่งที่เฉพาะสำหรับ Pipedream

โมเดลเรคคอร์ดของ Jodoo สามารถคงรูปแบบเดิมได้ แต่แต่ละแพลตฟอร์มเอเจนต์มีรูปแบบการสร้าง มุมมองการทดสอบ และการส่งต่องานสู่ระบบใช้งานจริงที่ต่างกัน

  • หลักฐานการตั้งค่า

    หลักฐานนี้ใช้การทดสอบการทำงานของ Pipedream และ request logging แทนหน้ากระดานสถานการณ์แบบภาพ

  • เส้นทางการดำเนินการ

    ขั้นตอน request ทำให้ endpoint รูปแบบ body และข้อมูลการตอบกลับชัดเจนสำหรับเจ้าของงานด้านเทคนิค

  • จุดเน้นของสูตรการทำงาน

    เวิร์กโฟลว์สามารถเพิ่มโค้ดสำหรับ validation, environment variables และการมอนิเตอร์ API หลังจากการเขียนข้อมูลกลับทำงานเสถียรแล้ว

  • การวางแผนโปรดักชัน

    การวางแผนโปรดักชันควรครอบคลุมความปลอดภัยของ endpoint, secrets, ปริมาณอีเวนต์ และพฤติกรรมการ retry

  • รายละเอียดหลักฐาน

    หลักฐานสาธารณะใช้การทดสอบการทำงานของ Pipedream การตรวจสอบอีเวนต์ และบันทึกคำขอ เพื่อให้เจ้าของงานด้านเทคนิคตรวจสอบรูปแบบ payload และรายละเอียดการตอบกลับของ Jodoo ได้

  • หลักฐานการรัน

    หลักฐานเวิร์กโฟลว์เน้นมุมมอง API: trigger event, step output, response body, deployment state และ environment variables สำคัญกว่าหน้ากระดานแบบภาพ

  • รายละเอียดการสร้าง

    เริ่มด้วย HTTP trigger หรืออีเวนต์ทดสอบแบบ manual ตรวจสอบ JSON payload และเก็บการเขียนข้อมูลกลับเข้า Jodoo ไว้ในขั้นตอน request ที่ตั้งชื่อไว้

  • แนวทางการใช้งาน

    ใช้ขั้นตอน Node.js เพื่อทำ normalization ตรวจสอบ schema ใช้ตรรกะตามเกณฑ์วงเงิน หรือ enrich ข้อมูล ก่อนส่งฟิลด์เรคคอร์ดสุดท้ายไปยัง Jodoo

  • แนวป้องกันความเสี่ยง

    ตรวจสอบปริมาณอีเวนต์ concurrency พฤติกรรมการ retry และการยืนยันตัวตนของแหล่งข้อมูล ก่อนใช้ endpoint สำหรับคำขอจริงในโปรดักชัน

  • การควบคุมการรีวิว

    เพิ่ม logging ที่ชัดเจนสำหรับ request ID, Jodoo data ID และข้อความข้อผิดพลาด เพื่อให้การส่งต่องานที่ล้มเหลวสามารถ replay ได้พร้อมบริบทที่เพียงพอ

  • สูตรการทำงานของสถานการณ์

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

  • การปรับเวิร์กโฟลว์

    ขั้นตอน Node.js สามารถคำนวณยอดใช้จ่ายรวม เพิ่มกฎการเงินตามเกณฑ์วงเงิน หรือสร้าง ID คำขอซื้อที่ปลอดภัยต่อการ replay ก่อนที่คำขอจะเข้าสู่คิว Jodoo

ชุดเวิร์กโฟลว์

สร้างลูปการส่งต่อการอนุมัติคำขอซื้อแบบเดียวกัน

อ่านคู่มือ คัดลอกสูตรการทำงานของเวิร์กโฟลว์ และใช้โมเดลฟิลด์ของ Jodoo เมื่อปรับเวิร์กโฟลว์ Pipedream ให้เหมาะกับทีมของคุณ

เวิร์กโฟลว์ที่นำกลับมาใช้ซ้ำได้

เวิร์กโฟลว์ช่วยตัดสินใจ Jodoo ช่วยให้งานเดินหน้าต่อ

  1. 01

    HTTP trigger หรือการทดสอบแบบ manual

    เริ่มการทดสอบคำขอซื้อด้วยคำขอแท็บเล็ตแบบทนทาน 12 เครื่องสำหรับทีมบริการภาคสนาม พร้อมเคสป้องกันและการสนับสนุนการลงทะเบียนอุปกรณ์ เริ่มด้วย HTTP trigger หรืออีเวนต์ทดสอบแบบ manual ตรวจสอบ JSON payload และเก็บการเขียนข้อมูลกลับเข้า Jodoo ไว้ในขั้นตอน request ที่ตั้งชื่อไว้

  2. 02

    เวิร์กโฟลว์ Pipedream

    เวิร์กโฟลว์ Pipedream ใช้ขั้นตอน HTTP request เพื่อเรียก Jodoo bridge และบันทึกการตอบกลับให้ผู้พัฒนาดูได้

  3. 03

    ขั้นตอน API request

    ส่ง JSON แบบมีโครงสร้างไปยัง Jodoo writeback bridge หลักฐานเวิร์กโฟลว์เน้นมุมมอง API: trigger event, step output, response body, deployment state และ environment variables สำคัญกว่าหน้ากระดานแบบภาพ

  4. 04

    การตอบกลับที่ใช้เป็นหลักฐาน

    แสดงการรันบนแพลตฟอร์มที่สำเร็จและ Jodoo data ID หลักฐานสาธารณะใช้การทดสอบการทำงานของ Pipedream การตรวจสอบอีเวนต์ และบันทึกคำขอ เพื่อให้เจ้าของงานด้านเทคนิคตรวจสอบรูปแบบ payload และรายละเอียดการตอบกลับของ Jodoo ได้

  5. 05

    คิว Jodoo

    จัดเก็บฟิลด์สำหรับให้เจ้าของงานตรวจสอบ ติดตามสถานะ และติดตามงานต่อ ตรวจสอบปริมาณอีเวนต์ concurrency พฤติกรรมการ retry และการยืนยันตัวตนของแหล่งข้อมูล ก่อนใช้ endpoint สำหรับคำขอจริงในโปรดักชัน

ลูปเวิร์กโฟลว์

จากการส่งต่อการอนุมัติคำขอซื้อใน Pipedream สู่ Jodoo

  1. HTTP trigger หรือการทดสอบแบบ manual รับหรือเริ่มการส่งต่อการอนุมัติคำขอซื้อด้วยข้อมูลจำลองก่อน

  2. Pipedream ใช้คำสั่งรีวิวแบบเจาะจงและส่งคืนสถานะการอนุมัติ สถานะการจัดหา เจ้าของงานจัดซื้อ เส้นทางการอนุมัติ ข้อมูลที่ขาด ยอดรวมโดยประมาณ ลำดับความสำคัญ และขั้นตอนถัดไปที่แนะนำ

  3. ขั้นตอน API request ส่งผลลัพธ์แบบมีโครงสร้างไปยัง Jodoo writeback bridge และได้รับ data ID กลับมา

  4. สำหรับการส่งต่อการอนุมัติคำขอซื้อ Pipedream สามารถตรวจสอบผู้ขอ รายละเอียดสินค้า ยอดรวมโดยประมาณ รหัสงบประมาณ วันที่ต้องการใช้ และเส้นทางการอนุมัติ ก่อนเรียก Jodoo

  5. ขั้นตอน Node.js สามารถคำนวณยอดใช้จ่ายรวม เพิ่มกฎการเงินตามเกณฑ์วงเงิน หรือสร้าง ID คำขอซื้อที่ปลอดภัยต่อการ replay ก่อนที่คำขอจะเข้าสู่คิว Jodoo

  6. event inspector มีประโยชน์สำหรับการเชื่อมต่อด้านจัดซื้อ เพราะแสดง trigger payload, step output, response body และ replay context

  7. หลังจากพิสูจน์การทำงานแล้ว Pipedream สามารถเพิ่ม schema validation, audit logging, managed secrets และ ID ที่ปลอดภัยต่อการ replay สำหรับคำขอซื้อที่มาจากแหล่งข้อมูล API

  8. เริ่มด้วย HTTP trigger หรืออีเวนต์ทดสอบแบบ manual ตรวจสอบ JSON payload และเก็บการเขียนข้อมูลกลับเข้า Jodoo ไว้ในขั้นตอน request ที่ตั้งชื่อไว้

  9. ใช้ขั้นตอน Node.js เพื่อทำ normalization ตรวจสอบ schema ใช้ตรรกะตามเกณฑ์วงเงิน หรือ enrich ข้อมูล ก่อนส่งฟิลด์เรคคอร์ดสุดท้ายไปยัง Jodoo

  10. Jodoo สร้างเรคคอร์ดฟอร์มคำขอซื้อและจัดเก็บชื่อผู้ขอ แผนก วันที่ขอ ลำดับความสำคัญ หมวดหมู่สินค้า รายละเอียดสินค้า จำนวน และราคาต่อหน่วยโดยประมาณ

  11. ทีมตรวจสอบคิว มอบหมายเจ้าของงาน และดำเนินขั้นตอนถัดไปให้เสร็จ: ขอใบเสนอราคาจากผู้ขาย ยืนยันการอนุมัติจากเจ้าของงบประมาณ และส่งต่อคำขอไปยังฝ่ายการเงินก่อนเริ่มจัดหา

  12. ตรวจสอบปริมาณอีเวนต์ concurrency พฤติกรรมการ retry และการยืนยันตัวตนของแหล่งข้อมูล ก่อนใช้ endpoint สำหรับคำขอจริงในโปรดักชัน

  13. เพิ่ม logging ที่ชัดเจนสำหรับ request ID, Jodoo data ID และข้อความข้อผิดพลาด เพื่อให้การส่งต่องานที่ล้มเหลวสามารถ replay ได้พร้อมบริบทที่เพียงพอ

การแมปฟิลด์

ผลลัพธ์จากเอเจนต์กลายเป็นฟิลด์ใน Jodoo

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

สูตรการทำงานของเอเจนต์

พรอมป์ต์และผลลัพธ์แบบมีโครงสร้าง

บทบาทของ Pipedream

ตรวจสอบคำขอการส่งต่อการอนุมัติคำขอซื้อ 1 รายการ และส่งคืนฟิลด์แบบมีโครงสร้างที่ Jodoo สามารถจัดเก็บ ส่งต่อ และรายงานได้ เริ่มด้วย HTTP trigger หรืออีเวนต์ทดสอบแบบ manual ตรวจสอบ JSON payload และเก็บการเขียนข้อมูลกลับเข้า Jodoo ไว้ในขั้นตอน request ที่ตั้งชื่อไว้

คำสั่งสำหรับการรีวิว

ใช้บริบทตัวอย่างสำหรับคำขอแท็บเล็ตแบบทนทาน 12 เครื่องสำหรับทีมบริการภาคสนาม พร้อมเคสป้องกันและการสนับสนุนการลงทะเบียนอุปกรณ์ ตัดสินสถานะการอนุมัติ สถานะการจัดหา เจ้าของงานจัดซื้อ เส้นทางการอนุมัติ ข้อมูลที่ขาด ยอดรวมโดยประมาณ ลำดับความสำคัญ และขั้นตอนถัดไปที่แนะนำ และระบุขั้นตอนถัดไปที่แนะนำให้เฉพาะเจาะจง สำหรับการส่งต่อการอนุมัติคำขอซื้อ Pipedream สามารถตรวจสอบผู้ขอ รายละเอียดสินค้า ยอดรวมโดยประมาณ รหัสงบประมาณ วันที่ต้องการใช้ และเส้นทางการอนุมัติ ก่อนเรียก Jodoo

ข้อตกลงการเขียนข้อมูลกลับ

ส่งออบเจ็กต์ JSON ที่คาดเดาได้ผ่านขั้นตอน API request โดย Jodoo ควรได้รับชื่อฟิลด์ชุดเดียวกันในทุกการรัน Pipedream เหมาะกับทีมที่ต้องการควบคุมขั้นตอนด้วยโค้ด มองเห็นคำขอได้ ใช้ managed secrets และมี logs ที่นักพัฒนาอ่านได้รอบการเขียนข้อมูลกลับเข้า Jodoo

ผลลัพธ์ที่ต้องมี

ส่งคืนสถานะการอนุมัติ สถานะการจัดหา เจ้าของงานจัดซื้อ เส้นทางการอนุมัติ ข้อมูลที่ขาด ยอดรวมโดยประมาณ ลำดับความสำคัญ และขั้นตอนถัดไปที่แนะนำ รวมถึง source_platform, agent_confidence และผลลัพธ์เวิร์กโฟลว์ต้นฉบับสำหรับบริบทการตรวจสอบย้อนหลัง

การควบคุมใน Pipedream

ตรวจสอบปริมาณอีเวนต์ concurrency พฤติกรรมการ retry และการยืนยันตัวตนของแหล่งข้อมูล ก่อนใช้ endpoint สำหรับคำขอจริงในโปรดักชัน เพิ่ม logging ที่ชัดเจนสำหรับ request ID, Jodoo data ID และข้อความข้อผิดพลาด เพื่อให้การส่งต่องานที่ล้มเหลวสามารถ replay ได้พร้อมบริบทที่เพียงพอ ใช้ managed secrets และประวัติการ deploy แทนการ hard-code การตั้งค่า writeback ในขั้นตอนโค้ดที่มองเห็นได้ ใช้ประวัติการ deploy ระดับโปรเจกต์ การควบคุมอัตราของแหล่งข้อมูล จุดหมายการแจ้งเตือน และสิทธิ์การ replay ก่อนส่งอีเวนต์งานจริง

หมายเหตุการใช้งานคำขอซื้อ

สำหรับการส่งต่อการอนุมัติคำขอซื้อ Pipedream สามารถตรวจสอบผู้ขอ รายละเอียดสินค้า ยอดรวมโดยประมาณ รหัสงบประมาณ วันที่ต้องการใช้ และเส้นทางการอนุมัติ ก่อนเรียก Jodoo ขั้นตอน Node.js สามารถคำนวณยอดใช้จ่ายรวม เพิ่มกฎการเงินตามเกณฑ์วงเงิน หรือสร้าง ID คำขอซื้อที่ปลอดภัยต่อการ replay ก่อนที่คำขอจะเข้าสู่คิว Jodoo event inspector มีประโยชน์สำหรับการเชื่อมต่อด้านจัดซื้อ เพราะแสดง trigger payload, step output, response body และ replay context หลังจากพิสูจน์การทำงานแล้ว Pipedream สามารถเพิ่ม schema validation, audit logging, managed secrets และ ID ที่ปลอดภัยต่อการ replay สำหรับคำขอซื้อที่มาจากแหล่งข้อมูล API

{
  "requester_name": "Avery Brooks",
  "department": "ฝ่ายปฏิบัติการ",
  "item_category": "อุปกรณ์ IT",
  "item_description": "แท็บเล็ตแบบทนทาน 12 เครื่องสำหรับทีมบริการภาคสนาม",
  "quantity": 12,
  "estimated_total": 5820,
  "needed_by_date": "2026-06-21",
  "budget_code": "OPS-FIELD-2026",
  "approval_status": "รอตรวจสอบ",
  "sourcing_status": "ต้องขอใบเสนอราคา",
  "approval_route": "ผู้จัดการแผนก จากนั้นฝ่ายการเงิน",
  "procurement_owner": "ทีมปฏิบัติการจัดซื้อ",
  "missing_information": "ยืนยันจำนวนไลเซนส์การจัดการอุปกรณ์และที่อยู่จัดส่ง",
  "recommended_next_action": "ขอใบเสนอราคาจากผู้ขายและส่งต่อไปยังฝ่ายการเงินก่อนเริ่มจัดหา"
}

แอปเริ่มต้นของ Jodoo

แอปเริ่มต้นสำหรับคำขอซื้อ

ใช้โมเดลฟิลด์ มุมมอง และ automation เมื่อปรับเวิร์กโฟลว์การส่งต่อการอนุมัติคำขอซื้อให้เหมาะกับทีมของคุณ

ฟิลด์ที่รวมอยู่

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

มุมมองที่แนะนำ

  • ต้องให้ทีมจัดซื้อตรวจสอบ
  • คิวอนุมัติของฝ่ายการเงิน
  • ต้องขอใบเสนอราคา
  • การซื้อที่มีลำดับความสำคัญสูง
  • คำขอซื้อทั้งหมด

กฎระบบอัตโนมัติ

  • สร้างเรคคอร์ด Jodoo หลังจาก Pipedream ส่งคืนผลลัพธ์แบบมีโครงสร้าง
  • ย้ายเรคคอร์ดที่มีลำดับความสำคัญสูงหรือเป็นข้อยกเว้นไปยังคิวเจ้าของงานที่ถูกต้อง
  • แจ้งเจ้าของงานที่แนะนำเมื่อมีข้อมูลที่ขาดหรือเหตุผลในการพักคำขอ
  • เก็บผลลัพธ์เวิร์กโฟลว์ต้นฉบับไว้ในบริบทการตรวจสอบย้อนหลัง

เช็กลิสต์ก่อนเปิดใช้งาน

สิ่งที่ต้องยืนยันก่อนใช้งานจริง

  • ตรวจสอบ HTTP event หรือ test payload ก่อนเพิ่มการเรียกโมเดล
  • ย้าย URLs และ production secrets ไปไว้ใน managed environment variables
  • บันทึกผลลัพธ์ของคำขอและ Jodoo data ID เพื่อใช้แก้ปัญหา
  • วางแผนการจัดการ API rate, retry และการยืนยันตัวตนของแหล่งข้อมูลก่อนใช้ข้อมูลจริง
  • ตรวจสอบปริมาณอีเวนต์ concurrency พฤติกรรมการ retry และการยืนยันตัวตนของแหล่งข้อมูล ก่อนใช้ endpoint สำหรับคำขอจริงในโปรดักชัน
  • เพิ่ม logging ที่ชัดเจนสำหรับ request ID, Jodoo data ID และข้อความข้อผิดพลาด เพื่อให้การส่งต่องานที่ล้มเหลวสามารถ replay ได้พร้อมบริบทที่เพียงพอ
  • ใช้ managed secrets และประวัติการ deploy แทนการ hard-code การตั้งค่า writeback ในขั้นตอนโค้ดที่มองเห็นได้
  • ใช้ประวัติการ deploy ระดับโปรเจกต์ การควบคุมอัตราของแหล่งข้อมูล จุดหมายการแจ้งเตือน และสิทธิ์การ replay ก่อนส่งอีเวนต์งานจริง
  • ขั้นตอน Node.js สามารถคำนวณยอดใช้จ่ายรวม เพิ่มกฎการเงินตามเกณฑ์วงเงิน หรือสร้าง ID คำขอซื้อที่ปลอดภัยต่อการ replay ก่อนที่คำขอจะเข้าสู่คิว Jodoo
  • event inspector มีประโยชน์สำหรับการเชื่อมต่อด้านจัดซื้อ เพราะแสดง trigger payload, step output, response body และ replay context
  • หลังจากพิสูจน์การทำงานแล้ว Pipedream สามารถเพิ่ม schema validation, audit logging, managed secrets และ ID ที่ปลอดภัยต่อการ replay สำหรับคำขอซื้อที่มาจากแหล่งข้อมูล API

ชุดเวิร์กโฟลว์

เก็บรายละเอียดการตั้งค่าไว้ให้ทีมของคุณ

เวิร์กโฟลว์

จากคำขอซื้อใน Pipedream สู่เรคคอร์ดใน Jodoo

Pipedream จัดการ webhook และเวิร์กโฟลว์ API ส่วน Jodoo เก็บเรคคอร์ดที่ทีมสามารถกรอง มอบหมาย และตรวจสอบได้

  1. HTTP trigger หรือการทดสอบแบบ manual รับหรือเริ่มการส่งต่อการอนุมัติคำขอซื้อด้วยข้อมูลจำลองก่อน

  2. Pipedream ใช้คำสั่งรีวิวแบบเจาะจงและส่งคืนสถานะการอนุมัติ สถานะการจัดหา เจ้าของงานจัดซื้อ เส้นทางการอนุมัติ ข้อมูลที่ขาด ยอดรวมโดยประมาณ ลำดับความสำคัญ และขั้นตอนถัดไปที่แนะนำ

  3. ขั้นตอน API request ส่งผลลัพธ์แบบมีโครงสร้างไปยัง Jodoo writeback bridge และได้รับ data ID กลับมา

  4. สำหรับการส่งต่อการอนุมัติคำขอซื้อ Pipedream สามารถตรวจสอบผู้ขอ รายละเอียดสินค้า ยอดรวมโดยประมาณ รหัสงบประมาณ วันที่ต้องการใช้ และเส้นทางการอนุมัติ ก่อนเรียก Jodoo

  5. ขั้นตอน Node.js สามารถคำนวณยอดใช้จ่ายรวม เพิ่มกฎการเงินตามเกณฑ์วงเงิน หรือสร้าง ID คำขอซื้อที่ปลอดภัยต่อการ replay ก่อนที่คำขอจะเข้าสู่คิว Jodoo

  6. event inspector มีประโยชน์สำหรับการเชื่อมต่อด้านจัดซื้อ เพราะแสดง trigger payload, step output, response body และ replay context

  7. หลังจากพิสูจน์การทำงานแล้ว Pipedream สามารถเพิ่ม schema validation, audit logging, managed secrets และ ID ที่ปลอดภัยต่อการ replay สำหรับคำขอซื้อที่มาจากแหล่งข้อมูล API

  8. เริ่มด้วย HTTP trigger หรืออีเวนต์ทดสอบแบบ manual ตรวจสอบ JSON payload และเก็บการเขียนข้อมูลกลับเข้า Jodoo ไว้ในขั้นตอน request ที่ตั้งชื่อไว้

  9. ใช้ขั้นตอน Node.js เพื่อทำ normalization ตรวจสอบ schema ใช้ตรรกะตามเกณฑ์วงเงิน หรือ enrich ข้อมูล ก่อนส่งฟิลด์เรคคอร์ดสุดท้ายไปยัง Jodoo

  10. Jodoo สร้างเรคคอร์ดฟอร์มคำขอซื้อและจัดเก็บชื่อผู้ขอ แผนก วันที่ขอ ลำดับความสำคัญ หมวดหมู่สินค้า รายละเอียดสินค้า จำนวน และราคาต่อหน่วยโดยประมาณ

  11. ทีมตรวจสอบคิว มอบหมายเจ้าของงาน และดำเนินขั้นตอนถัดไปให้เสร็จ: ขอใบเสนอราคาจากผู้ขาย ยืนยันการอนุมัติจากเจ้าของงบประมาณ และส่งต่อคำขอไปยังฝ่ายการเงินก่อนเริ่มจัดหา

  12. ตรวจสอบปริมาณอีเวนต์ concurrency พฤติกรรมการ retry และการยืนยันตัวตนของแหล่งข้อมูล ก่อนใช้ endpoint สำหรับคำขอจริงในโปรดักชัน

  13. เพิ่ม logging ที่ชัดเจนสำหรับ request ID, Jodoo data ID และข้อความข้อผิดพลาด เพื่อให้การส่งต่องานที่ล้มเหลวสามารถ replay ได้พร้อมบริบทที่เพียงพอ

เรคคอร์ด Jodoo

สิ่งที่ Jodoo จัดเก็บ

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

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

การทดสอบจริง

เวิร์กโฟลว์ Pipedream เขียนคำขอซื้อลงใน Jodoo

ภาพหน้าจอใช้ข้อมูลจำลองและแสดงการตั้งค่า Pipedream การรันที่สำเร็จ และแถวข้อมูลใน Jodoo ที่สร้างโดยเวิร์กโฟลว์

การตั้งค่า Pipedream สำหรับการส่งต่อการอนุมัติคำขอซื้อกับ Jodoo

การตั้งค่าเวิร์กโฟลว์ Pipedream

เวิร์กโฟลว์ Pipedream ใช้ขั้นตอน HTTP request เพื่อเรียก Jodoo bridge และบันทึกการตอบกลับให้ผู้พัฒนาดูได้

การรันการส่งต่อการอนุมัติคำขอซื้อด้วย Pipedream สำเร็จ พร้อมเขียนข้อมูลกลับเข้า Jodoo

การทดสอบ Pipedream สำเร็จ

การรันทดสอบของ Pipedream แสดงว่าคำขอรูปแบบ API เสร็จสมบูรณ์ และ bridge ส่งคืน Jodoo data ID

เรคคอร์ดการส่งต่อการอนุมัติคำขอซื้อใน Jodoo ที่สร้างจากผลลัพธ์ของ Pipedream

การเขียนข้อมูลกลับเข้า Jodoo

การส่งต่อการอนุมัติคำขอซื้อถูกเขียนลงใน Jodoo โดยมองเห็นฟิลด์ชื่อผู้ขอ แผนก วันที่ขอ ลำดับความสำคัญ หมวดหมู่สินค้า และรายละเอียดสินค้า

FAQ

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

คำตอบเกี่ยวกับการใช้แพลตฟอร์มเอเจนต์ร่วมกับเรคคอร์ด เวิร์กโฟลว์ และเทมเพลตแอปของ Jodoo

การส่งต่อการอนุมัติคำขอซื้อด้วย Pipedream นี้ทดสอบครบตั้งแต่ต้นจนจบหรือไม่

ใช่ หลักฐานนี้ใช้ข้อมูลจำลอง การรัน Pipedream จริง และภาพหน้าจอการเขียนข้อมูลกลับเข้า Jodoo ที่ตรวจสอบแล้วพร้อม proof manifest

ทำไมจึงใช้ Pipedream สำหรับการส่งต่อการอนุมัติคำขอซื้อ

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

การใช้งาน Pipedream นี้แตกต่างจากตัวอย่างแพลตฟอร์มอื่นอย่างไร

หลักฐานสาธารณะใช้การทดสอบการทำงานของ Pipedream การตรวจสอบอีเวนต์ และบันทึกคำขอ เพื่อให้เจ้าของงานด้านเทคนิคตรวจสอบรูปแบบ payload และรายละเอียดการตอบกลับของ Jodoo ได้ เริ่มด้วย HTTP trigger หรืออีเวนต์ทดสอบแบบ manual ตรวจสอบ JSON payload และเก็บการเขียนข้อมูลกลับเข้า Jodoo ไว้ในขั้นตอน request ที่ตั้งชื่อไว้ สำหรับการส่งต่อการอนุมัติคำขอซื้อ Pipedream สามารถตรวจสอบผู้ขอ รายละเอียดสินค้า ยอดรวมโดยประมาณ รหัสงบประมาณ วันที่ต้องการใช้ และเส้นทางการอนุมัติ ก่อนเรียก Jodoo

Jodoo เก็บอะไรหลังจากเวิร์กโฟลว์ทำงาน

Jodoo เก็บชื่อผู้ขอ แผนก วันที่ขอ ลำดับความสำคัญ หมวดหมู่สินค้า รายละเอียดสินค้า จำนวน ราคาต่อหน่วยโดยประมาณ ยอดรวมโดยประมาณ วันที่ต้องการใช้ รวมถึงผลลัพธ์เวิร์กโฟลว์ต้นฉบับสำหรับบริบทการตรวจสอบย้อนหลัง

ภายหลังสามารถเชื่อมต่อกับข้อมูลต้นทางในโปรดักชันได้หรือไม่

ได้ เริ่มจากการรันด้วยข้อมูลจำลองที่ตรวจสอบแล้ว จากนั้นเชื่อมต่อฟอร์ม พอร์ทัล กล่องอีเมล APIs หรือระบบภายใน เมื่อ schema การส่งต่อการอนุมัติคำขอซื้อเสถียรแล้ว ใช้ขั้นตอน Node.js เพื่อทำ normalization ตรวจสอบ schema ใช้ตรรกะตามเกณฑ์วงเงิน หรือ enrich ข้อมูล ก่อนส่งฟิลด์เรคคอร์ดสุดท้ายไปยัง Jodoo

ส่วนใดที่ทีมยังควรตรวจสอบเอง

เวิร์กโฟลว์สามารถเตรียมฟิลด์การตัดสินใจได้ แต่เจ้าของงานยังควรตรวจสอบความเสี่ยงทางธุรกิจ การอนุมัติด้านการชำระเงินหรือกฎหมาย และการตัดสินใจขั้นสุดท้ายในการดำเนินงาน ใช้ managed secrets และประวัติการ deploy แทนการ hard-code การตั้งค่า writeback ในขั้นตอนโค้ดที่มองเห็นได้

ขั้นตอนถัดไป

เปลี่ยนคำขอซื้อให้เป็นงานติดตามที่จัดการได้

เริ่มจากการรัน Pipedream ที่ตรวจสอบแล้ว 1 ครั้ง จากนั้นนำรูปแบบการเขียนข้อมูลกลับแบบเดียวกันไปใช้กับคิวรีวิวและการส่งต่องานในกระบวนการใกล้เคียง ก่อนใช้ endpoint สำหรับคำขอจริงในโปรดักชัน ควรตรวจสอบปริมาณอีเวนต์ concurrency พฤติกรรมการ retry และการยืนยันตัวตนของแหล่งข้อมูล