คู่มือโซลูชัน
คู่มือวางแผนสำหรับลูปการรับคำขอจากผู้ขายด้วย Pipedream ครอบคลุมการตั้งค่า HTTP trigger การแมปคำขอ API การตรวจสอบประวัติอีเวนต์ ฟิลด์ใน Jodoo และข้อควรทราบก่อนเริ่มใช้งานจริง
เปิดคู่มือPIPEDREAM + JODOO
การตรวจรับคำขอจากผู้ขายด้วย AI ด้วย Pipedream + Jodoo
ใช้ Pipedream ร่วมกับ Jodoo เมื่ออีเวนต์การรับคำขอจากผู้ขายควรเริ่มผ่าน HTTP trigger ผ่านตรรกะเวิร์กโฟลว์แบบ API และสร้างเรคคอร์ดการตรวจสอบใน Jodoo ที่ติดตามได้
รับคำขอจากซัพพลายเออร์ผ่าน Pipedream HTTP triggerตรวจสอบประวัติอีเวนต์และข้อมูลคำขอ/การตอบกลับของ APIเขียนฟิลด์ความเสี่ยงของผู้ขายและคำแนะนำลงใน Jodooกำหนดการจัดการ secrets, endpoints และเจ้าของระบบ production ให้ชัดเจน
วิดีโอแนะนำการใช้งาน
สิ่งที่เกิดขึ้นในเดโม Pipedream
วิดีโอนี้แสดงให้เห็นว่า Pipedream ตรวจสอบคำขอรับข้อมูลผู้ขายจำลอง ส่งฟิลด์การตรวจสอบแบบมีโครงสร้าง และให้ Jodoo จัดเก็บเรคคอร์ดงานจัดซื้อ
Pipedream รับอีเวนต์ผู้ขาย
ตัวอย่างการทดสอบส่งข้อมูลซัพพลายเออร์จำลองไปยัง HTTP trigger เพื่อให้ทดสอบเวิร์กโฟลว์ได้เหมือน API endpoint
เวิร์กโฟลว์เตรียมคำขอ API
Pipedream แมปข้อมูลตัวตนผู้ขาย เอกสารที่ขาด ความเสี่ยง คำแนะนำ เจ้าของงาน และสถานะ ลงในเนื้อหาคำขอ
Build API Request ส่งข้อมูลไปยัง Jodoo
เวิร์กโฟลว์ส่งข้อมูลการตรวจสอบแบบมีโครงสร้างไปยังตัวกลาง และบันทึกการตอบกลับ data ID ของ Jodoo
Jodoo เก็บเรคคอร์ดงานจัดซื้อ
แอปการเริ่มต้นใช้งานผู้ขายเก็บข้อมูลการติดตามเอกสาร การตรวจสอบความเสี่ยง คำแนะนำการอนุมัติ และความรับผิดชอบด้านคอมพลายแอนซ์
สรุปเดโม
Pipedream ตรวจสอบผู้ขาย ส่วน Jodoo ติดตามงานต่อ
การทำงานรูปแบบนี้เหมาะเมื่อทีมต้องการการประสานงาน API ที่เป็นมิตรกับนักพัฒนาก่อนให้ Jodoo เป็นเรคคอร์ดกลางสำหรับการตรวจสอบผู้ขาย
เส้นทางที่เริ่มจาก webhook
Pipedream เริ่มจาก HTTP trigger ที่รับอีเวนต์การรับคำขอจากซัพพลายเออร์
การตั้งค่าคำขอ API
เวิร์กโฟลว์กำหนดเนื้อหาคำขอให้ตรงกับโมเดลฟิลด์การตรวจสอบผู้ขายของ Jodoo
ประวัติอีเวนต์
การรันนี้แสดงอีเวนต์ ผลลัพธ์ของคำขอ และการตอบกลับจากตัวกลางเขียนข้อมูลกลับ
Jodoo data ID
Pipedream ได้รับ Jodoo data ID ที่ถูกสร้างหลังคำขอ API เสร็จสมบูรณ์
เรคคอร์ดงานจัดซื้อ
Jodoo เก็บความเสี่ยงของผู้ขาย เอกสารที่ขาด คำแนะนำ ผู้ตรวจสอบ และสถานะการเริ่มต้นใช้งาน
การส่งต่องานให้ทีมนักพัฒนา
สูตรการทำงานนี้เน้นเรื่องเจ้าของ endpoint, environment variables, request logging และการวางแผนอัตราการใช้งาน
หมายเหตุการตั้งค่าแพลตฟอร์ม
สิ่งที่เฉพาะสำหรับ Pipedream
โมเดลเรคคอร์ดของ Jodoo สามารถคงรูปแบบเดิมได้ แต่แต่ละแพลตฟอร์มเอเจนต์มีรูปแบบการสร้าง มุมมองการทดสอบ และการส่งต่องานสู่ระบบใช้งานจริงที่ต่างกัน
ความรับผิดชอบของ HTTP trigger
Pipedream เหมาะเมื่อการรับคำขอจากผู้ขายเริ่มต้นเป็นอีเวนต์หรือคำขอ API และมีเจ้าของด้านเทคนิคดูแล endpoint
ความชัดเจนของคำขอ API
ขั้นตอน Build API Request ทำให้มองเห็น method, URL, body และ response logging ได้ชัดเจนสำหรับการดีบัก
แนวทางจัดการ secrets
การเขียนข้อมูลกลับใน production ควรใช้ managed environment variables และ credentials แบบ least-privilege
การวางแผนอีเวนต์และอัตราการใช้งาน
ก่อนขึ้น production ควรกำหนดปริมาณอีเวนต์ พฤติกรรมการ retry การจัดการอัตราการใช้งาน และการแจ้งเตือนรอบการส่งข้อมูลจากซัพพลายเออร์
ชุดเวิร์กโฟลว์
สร้างลูปการตรวจรับคำขอจากผู้ขายแบบเดียวกัน
ดูคู่มือ คัดลอกสูตรการทำงานของเวิร์กโฟลว์ และใช้โมเดลฟิลด์ของ Jodoo เมื่อต้องการปรับเวิร์กโฟลว์ Pipedream ให้เข้ากับแหล่งข้อมูลผู้ขายของคุณ
สิ่งที่ทีมของคุณนำกลับมาใช้ซ้ำได้
Pipedream รับคำขอจากซัพพลายเออร์เป็น HTTP event เตรียมคำขอ API และบันทึกการตอบกลับจากการเขียนข้อมูลกลับ ส่วน Jodoo เก็บฟิลด์ผู้ขาย เอกสาร ความเสี่ยง คำแนะนำ ผู้ตรวจสอบ และการเริ่มต้นใช้งานสำหรับการติดตามของทีมจัดซื้อ
เวิร์กโฟลว์ธุรกิจโมเดลฟิลด์ของ Jodooพรอมป์ต์ของเอเจนต์เช็กลิสต์ก่อนเปิดใช้งาน
เวิร์กโฟลว์ที่นำกลับมาใช้ซ้ำได้
เวิร์กโฟลว์ช่วยตัดสินใจ Jodoo ช่วยให้งานเดินหน้าต่อ
- 01
HTTP trigger
รับอีเวนต์ซัพพลายเออร์จาก Atlas Packaging Co.
- 02
เวิร์กโฟลว์ Pipedream
HTTP trigger รับคำขอจากผู้ขาย และขั้นตอน Build API Request จะส่งข้อมูลการตรวจสอบแบบมีโครงสร้างเข้าไปยัง Jodoo
- 03
Build API Request
ส่ง vendor review JSON ไปยัง Jodoo writeback bridge
- 04
ประวัติอีเวนต์
แสดงผลลัพธ์ของคำขอ response body และ data ID
- 05
แอปผู้ขายใน Jodoo
เก็บข้อมูลความเสี่ยง คำแนะนำ ผู้ตรวจสอบ และการติดตามเอกสาร
ลูปเวิร์กโฟลว์
จาก Pipedream HTTP trigger สู่การตรวจสอบผู้ขายใน Jodoo
Pipedream HTTP trigger รับคำขอจากผู้ขายจากพอร์ทัลซัพพลายเออร์ ฟอร์ม บริการจัดซื้อ หรือคำขอทดสอบจำลอง
เวิร์กโฟลว์เตรียมข้อมูลการตรวจสอบแบบมีโครงสร้างให้ตรงกับโมเดลฟิลด์การเริ่มต้นใช้งานผู้ขายของ Jodoo
ขั้นตอน Build API Request จะส่งข้อมูลตัวตนซัพพลายเออร์ เอกสารที่ขาด ความเสี่ยง คำแนะนำ เจ้าของงาน และสถานะ ไปยังตัวกลาง
ประวัติอีเวนต์ของ Pipedream แสดงผลลัพธ์ของคำขอและ Jodoo data ID ที่คืนกลับมาจากชั้นเขียนข้อมูลกลับ
Jodoo สร้างเรคคอร์ดการเริ่มต้นใช้งานผู้ขายและจัดระเบียบงานติดตามตามความเสี่ยง สถานะเอกสาร เจ้าของงาน และคำแนะนำการอนุมัติ
ทีมสามารถเพิ่ม environment variables, การยืนยันตัวตนของแหล่งข้อมูล, การเรียกใช้โมเดล และการมอนิเตอร์ production API ได้หลังจากการเขียนข้อมูลกลับพื้นฐานมีความเสถียรแล้ว
การแมปฟิลด์
ผลลัพธ์จากเอเจนต์กลายเป็นฟิลด์ใน Jodoo
| ข้อมูลจากเอเจนต์หรือแหล่งข้อมูลต้นทาง | ฟิลด์เรคคอร์ดของ Jodoo |
|---|---|
| vendor_name, vendor_category, business_need | ชื่อนิติบุคคลของผู้ขาย, หมวดหมู่ผู้ขาย, คำอธิบายความต้องการทางธุรกิจของผู้ขาย |
| contact_name, contact_email | ชื่อผู้ติดต่อหลัก, อีเมลผู้ติดต่อหลัก |
| requested_by, suggested_owner | ชื่อผู้ขอ, ผู้ตรวจสอบคอมพลายแอนซ์ |
| missing_documents, compliance_status | ความครบถ้วนของเอกสาร, ความคิดเห็นจากการตรวจสอบ |
| risk_level, recommendation, review_status | ระดับความเสี่ยง, คำแนะนำการอนุมัติ, สถานะการเริ่มต้นใช้งาน |
สูตรการทำงานของเอเจนต์
พรอมป์ต์และผลลัพธ์แบบมีโครงสร้าง
บทบาทของเวิร์กโฟลว์ Pipedream
รับอีเวนต์การรับคำขอจากซัพพลายเออร์หนึ่งรายการผ่าน HTTP trigger และส่งข้อมูลการตรวจสอบผู้ขายแบบมีโครงสร้างเข้าไปยัง Jodoo ผ่านคำขอ API
กฎของข้อมูลคำขอ API
ตรวจสอบฟิลด์ผู้ขายที่จำเป็นก่อนขั้นตอน request และระบุ missing_documents, risk_level, recommendation, suggested_owner และ review_status ให้ชัดเจน
ข้อตกลงเรื่อง secrets และ endpoint
เก็บ URL production และ credentials ไว้ใน managed environment variables ไม่ใช่ในข้อความเวิร์กโฟลว์สาธารณะที่คัดลอกมาหรือในภาพหน้าจอ
ผลลัพธ์ที่ต้องมี
ส่งกลับ vendor_name, vendor_category, contact_email, business_need, requested_by, risk_level, compliance_status, missing_documents, recommendation, suggested_owner, next_best_action และ source_platform
{
"vendor_name": "Atlas Packaging Co.",
"vendor_category": "ผู้จัดหาบรรจุภัณฑ์",
"contact_name": "Nora Patel",
"contact_email": "nora.patel@atlaspackaging.example",
"business_need": "ผู้จัดหาบรรจุภัณฑ์รองสำหรับการจัดส่งฝั่งตะวันตก",
"requested_by": "ฝ่ายจัดซื้อปฏิบัติการ",
"spend_estimate": "120000 ต่อปี",
"risk_level": "ปานกลาง",
"compliance_status": "ต้องใช้ W-9 และใบรับรองประกัน",
"missing_documents": "W-9, ใบรับรองประกัน, นโยบายความยั่งยืน",
"recommendation": "ดำเนินการตรวจสอบแบบมีเงื่อนไข",
"suggested_owner": "ทีมปฏิบัติการจัดซื้อ",
"next_best_action": "ขอเอกสารที่ขาดและนัดหมายการทบทวนการจัดหา",
"review_status": "ต้องติดตามเอกสาร",
"source_platform": "pipedream",
"agent_confidence": "0.84"
}แอปเริ่มต้นของ Jodoo
แอปเริ่มต้นสำหรับการตรวจรับคำขอจากผู้ขาย
ใช้โมเดลฟิลด์ มุมมองที่แนะนำ และกฎอัตโนมัติเมื่อต้องการปรับเวิร์กโฟลว์การเริ่มต้นใช้งานผู้ขายให้เหมาะกับทีมจัดซื้อ
ฟิลด์ที่รวมอยู่
- ชื่อนิติบุคคลของผู้ขาย
- หมวดหมู่ผู้ขาย
- ความต้องการทางธุรกิจ
- ผู้ติดต่อหลัก
- ผู้ขอ
- ผู้ตรวจสอบคอมพลายแอนซ์
- ความครบถ้วนของเอกสาร
- ระดับความเสี่ยง
- คำแนะนำการอนุมัติ
- สถานะการเริ่มต้นใช้งาน
- ความคิดเห็นจากการตรวจสอบ
- ผลลัพธ์ดั้งเดิมจากเอเจนต์
มุมมองที่แนะนำ
- ต้องติดตามเอกสารเพิ่มเติม
- ความเสี่ยงระดับกลางหรือสูง
- คิวของเจ้าของงาน
- พร้อมสำหรับการตรวจสอบด้านจัดหา
- การตรวจสอบผู้ขายทั้งหมด
กฎระบบอัตโนมัติ
- สร้างเรคคอร์ดการเริ่มต้นใช้งานผู้ขายใน Jodoo หลังจาก Pipedream ส่งผลลัพธ์แบบมีโครงสร้างกลับมา
- ย้ายผู้ขายที่มีความเสี่ยงระดับกลางหรือสูงไปยังคิวการตรวจสอบคอมพลายแอนซ์
- แจ้งผู้ตรวจสอบคอมพลายแอนซ์เมื่อความครบถ้วนของเอกสารยังไม่สมบูรณ์
- เก็บผลลัพธ์ดั้งเดิมของเวิร์กโฟลว์ไว้ในความคิดเห็นจากการตรวจสอบหรือบริบทการตรวจสอบย้อนหลัง
เช็กลิสต์ก่อนเปิดใช้งาน
สิ่งที่ต้องยืนยันก่อนใช้งานจริง
- สร้างหรือ deploy HTTP trigger และส่งข้อมูลซัพพลายเออร์จำลองก่อน
- ยืนยันโครงสร้างเนื้อหาคำขอก่อนเพิ่มการเรียกใช้โมเดลหรือขั้นตอนเพิ่มเติม
- ย้าย URLs, tokens และ production secrets ไปไว้ใน managed environment variables
- ตรวจสอบประวัติอีเวนต์สำหรับสถานะ response body และ Jodoo data ID
- วางแผนปริมาณอีเวนต์ การจัดการอัตรา API การ retry และการส่งต่อไปยังเจ้าของงาน
- เพิ่มการยืนยันตัวตนของแหล่งซัพพลายเออร์ก่อนประมวลผลข้อมูลผู้ขายจริง
เอกสารอ้างอิงสำหรับการนำไปใช้
เก็บรายละเอียดการตั้งค่าไว้ให้ทีมของคุณ
พิมพ์เขียวแอปเริ่มต้น Jodoo
โมเดลฟิลด์ของ Jodoo มุมมองผู้ขายที่แนะนำ ข้อมูลตัวอย่าง และการแมปการเขียนข้อมูลกลับที่ใช้หลังเวิร์กโฟลว์ Pipedream ทำงานเสร็จ
เปิดพิมพ์เขียวพรอมป์เอเจนต์ + สูตรการทำงานของเวิร์กโฟลว์
การตั้งค่า Pipedream HTTP trigger, เนื้อหาคำขอของ Build API Request, หมายเหตุเรื่อง endpoint และ secrets, การตรวจสอบประวัติอีเวนต์, ข้อมูลผู้ขายตัวอย่าง และการแมปฟิลด์ใน Jodoo
เปิดสูตรการทำงานเวิร์กโฟลว์
จากการตรวจสอบผู้ขายใน Pipedream สู่เรคคอร์ดการเริ่มต้นใช้งานใน Jodoo
Pipedream จัดการ webhook และเวิร์กโฟลว์ API; ส่วน Jodoo เก็บเรคคอร์ดที่ทีมจัดซื้อสามารถกรอง มอบหมาย และตรวจสอบได้
Pipedream HTTP trigger รับคำขอจากผู้ขายจากพอร์ทัลซัพพลายเออร์ ฟอร์ม บริการจัดซื้อ หรือคำขอทดสอบจำลอง
เวิร์กโฟลว์เตรียมข้อมูลการตรวจสอบแบบมีโครงสร้างให้ตรงกับโมเดลฟิลด์การเริ่มต้นใช้งานผู้ขายของ Jodoo
ขั้นตอน Build API Request จะส่งข้อมูลตัวตนซัพพลายเออร์ เอกสารที่ขาด ความเสี่ยง คำแนะนำ เจ้าของงาน และสถานะ ไปยังตัวกลาง
ประวัติอีเวนต์ของ Pipedream แสดงผลลัพธ์ของคำขอและ Jodoo data ID ที่คืนกลับมาจากชั้นเขียนข้อมูลกลับ
Jodoo สร้างเรคคอร์ดการเริ่มต้นใช้งานผู้ขายและจัดระเบียบงานติดตามตามความเสี่ยง สถานะเอกสาร เจ้าของงาน และคำแนะนำการอนุมัติ
ทีมสามารถเพิ่ม environment variables, การยืนยันตัวตนของแหล่งข้อมูล, การเรียกใช้โมเดล และการมอนิเตอร์ production API ได้หลังจากการเขียนข้อมูลกลับพื้นฐานมีความเสถียรแล้ว
เรคคอร์ด Jodoo
สิ่งที่ Jodoo จัดเก็บ
หลังเวิร์กโฟลว์ทำงาน Jodoo จะเก็บฟิลด์การตรวจสอบผู้ขายที่ใช้งานต่อได้ระยะยาว ได้แก่ ชื่อผู้ขาย ความต้องการทางธุรกิจ ผู้ตรวจสอบคอมพลายแอนซ์ ความครบถ้วนของเอกสาร ความเสี่ยง คำแนะนำ และสถานะการเริ่มต้นใช้งาน
ชื่อนิติบุคคลของผู้ขายหมวดหมู่ผู้ขายความต้องการทางธุรกิจผู้ติดต่อหลักผู้ขอผู้ตรวจสอบคอมพลายแอนซ์ความครบถ้วนของเอกสารระดับความเสี่ยงคำแนะนำการอนุมัติสถานะการเริ่มต้นใช้งานความคิดเห็นจากการตรวจสอบผลลัพธ์ดั้งเดิมจากเอเจนต์
การทดสอบจริง
เวิร์กโฟลว์ Pipedream เขียนข้อมูลการตรวจสอบผู้ขายลงใน Jodoo
ภาพหน้าจอใช้ข้อมูลผู้ขายจำลอง และแสดงการตั้งค่า Pipedream การรันที่สำเร็จ และแถวข้อมูลใน Jodoo ที่สร้างโดยเวิร์กโฟลว์
การกำหนดค่าเวิร์กโฟลว์
HTTP trigger รับคำขอจากผู้ขาย และขั้นตอน Build API Request จะส่งข้อมูลการตรวจสอบแบบมีโครงสร้างเข้าไปยัง Jodoo
การรัน Pipedream ที่สำเร็จ
การรันเวิร์กโฟลว์ Pipedream เสร็จสมบูรณ์และส่งกลับ Jodoo data ID จากตัวกลาง
Jodoo writeback
ข้อมูลการตรวจสอบผู้ขายถูกเขียนลงในเรคคอร์ดการเริ่มต้นใช้งานผู้ขายใน Jodoo พร้อมฟิลด์ความเสี่ยง คำแนะนำ และผู้ตรวจสอบคอมพลายแอนซ์
FAQ
คำถามที่พบบ่อย
คำตอบเกี่ยวกับการใช้แพลตฟอร์มเอเจนต์ร่วมกับเรคคอร์ด เวิร์กโฟลว์ และเทมเพลตแอปของ Jodoo
เวิร์กโฟลว์ผู้ขายใน Pipedream นี้ผ่านการทดสอบครบทุกขั้นตอนแล้วหรือไม่?
ใช่ การทดสอบใช้ Pipedream HTTP trigger, การเขียนข้อมูลกลับผ่าน Build API Request และภาพหน้าจอ Jodoo ที่ตรวจสอบแล้วพร้อมบันทึกหลักฐาน
ทำไมจึงควรใช้ Pipedream สำหรับการตรวจรับคำขอจากผู้ขาย?
ใช้ Pipedream เมื่อเวิร์กโฟลว์ขับเคลื่อนด้วยอีเวนต์ เน้นการทำงานผ่าน API และมีทีมเทคนิคที่ต้องการบันทึกคำขอและการตอบกลับที่ชัดเจน
Pipedream จำเป็นต้องเรียกใช้โมเดล AI หรือไม่?
ไม่จำเป็น การทดสอบนี้ยืนยันเส้นทางของอีเวนต์และการเขียนข้อมูลกลับก่อน จากนั้นจึงค่อยเพิ่มขั้นตอนโมเดลได้หากยังคงโครงสร้างการตรวจสอบผู้ขายเดิมไว้
ควรตรวจสอบอะไรบ้างก่อนใช้งานจริงใน production?
ยืนยันการยืนยันตัวตนของ endpoint, managed secrets, ปริมาณอีเวนต์, พฤติกรรมการ retry, การเก็บรักษาข้อมูล และความรับผิดชอบของผู้ตรวจสอบก่อนประมวลผลข้อมูลซัพพลายเออร์จริง
Jodoo จัดเก็บอะไรหลังจาก Pipedream ทำงานเสร็จ?
Jodoo จัดเก็บข้อมูลตัวตนผู้ขาย ความครบถ้วนของเอกสาร ระดับความเสี่ยง คำแนะนำ ผู้ตรวจสอบคอมพลายแอนซ์ สถานะการเริ่มต้นใช้งาน และความคิดเห็นจากการตรวจสอบ
ขั้นตอนถัดไป
เปลี่ยนคำขอจากผู้ขายให้เป็นงานติดตามของทีมจัดซื้อ
เริ่มจากคำขอของซัพพลายเออร์หนึ่งรายการ แล้วนำรูปแบบการเขียนข้อมูลกลับแบบเดียวกันไปใช้ซ้ำกับการตรวจสอบคอมพลายแอนซ์ การเริ่มต้นใช้งานผู้ขาย การรับสัญญา และคำขอจัดซื้อ