ดึงข้อมูล Amazon Seller Central อัตโนมัติ: เริ่มจาก CLI

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

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

API หรือเบราว์เซอร์: ข้อแลกเปลี่ยนที่ต้องพิจารณา

SP-API ครอบคลุมรายงานส่วนใหญ่ที่สำคัญต่อข้อมูลการดำเนินงาน ทั้งคำสั่งซื้อ สินค้าคงคลัง การชำระยอดเงิน การจัดการคำสั่งซื้อและจัดส่งสินค้าด้วย FBA และผลการดำเนินงานของแคตตาล็อก การใช้ API ล้วนจึงเหมาะกว่า เพราะเร็วกว่า เชื่อถือได้กว่า และไม่ขึ้นกับการเปลี่ยนหน้าจอ การลงทุนจัดการการยืนยันตัวตน SP-API ให้ถูกต้อง ทั้งข้อมูลรับรอง LWA การต่ออายุโทเคน และการควบคุมอัตราคำขอคุ้มค่าได้เร็ว

แต่รายงานบางกลุ่มไม่มีใน SP-API เลย เช่น รายงานโฆษณาที่เกินขอบเขต Advertising API เอกสารการปฏิบัติตามกฎระเบียบบางประเภท และสรุปการเงินหลายรูปแบบ จึงต้องใช้เบราว์เซอร์ ควรเลือกการควบคุมเบราว์เซอร์อัตโนมัติอย่างระมัดระวัง เฉพาะกรณีเหล่านี้ และเข้าใจต้นทุนการดำเนินงานทั้งหมด

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

การตั้งชื่อไฟล์แบบแน่นอนเป็นรากฐาน

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

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

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

การติดตามสถานะด้วย YAML

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

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

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

เวิร์กโฟลว์สองรอบสำหรับรายงานที่รอข้ามคืน

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

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

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

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

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

รูปแบบความล้มเหลวที่พบบ่อยที่สุดเมื่อใช้งานจริงไม่ใช่การดึงรายงาน แต่เป็นการจัดการข้อมูลรับรอง SP-API ใช้โทเคนการเข้าถึง LWA (Login With Amazon) ที่หมดอายุทุกชั่วโมง และต้องต่ออายุด้วยโทเคนต่ออายุซึ่งมีอายุยาวกว่าแต่ยังมีวันหมดอายุ ไปป์ไลน์ที่จัดการการต่ออายุโทเคนได้ถูกต้องระหว่างพัฒนามักล้มเหลวเมื่อรันจริงโดยไม่มีคนเฝ้าเป็นเวลานาน แล้วโทเคนต่ออายุหมดอายุโดยไม่ได้ต่ออายุใหม่

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

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