เอกสาร master ของ Odoo ระบุว่าบริการ RPC ฐานข้อมูลแบบเดิมถูกยกเลิกใน Odoo 20 โดย API XML-RPC และ JSON-RPC ในภาพรวมถูกเลิกใช้งานมาตั้งแต่เวอร์ชัน 19.0 แต่ Odoo 20 ไม่ได้ยกเลิกบริการเดิมทั้งหมด Odoo ระบุว่าบริการ common และ object จะยังใช้งานได้จนถึง Odoo 22 (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) ดังนั้นทีมอินทิเกรชันจึงต้องระบุว่าการเชื่อมต่อภายนอกแต่ละรายการใช้บริการใด แทนที่จะมองว่าการรองรับ RPC แบบเดิมเป็นฟีเจอร์เดียวที่มีวันยกเลิกวันเดียว
หน้ากิจกรรม Americas ของ Odoo ระบุว่า Odoo 20 จะเปิดตัวระหว่างงานที่ซานฟรานซิสโกในวันที่ 2 และ 3 กันยายน 2026 (Oxp26 Americas Introduction) การวางแผนอัปเกรดสามารถคำนึงถึงการยกเลิกบริการฐานข้อมูลตามเอกสารได้แล้ว แต่การตัดสินใจในระบบจริงควรตรวจสอบกับเอกสารการเปิดตัว Odoo 20 ฉบับสุดท้าย
การยกเลิกนี้มีผลกับบริการเฉพาะ
Odoo ระบุ `/xmlrpc`, `/xmlrpc/2` และ `/jsonrpc` เป็น endpoint แบบเดิมที่เลิกใช้งานตั้งแต่เวอร์ชัน 19.0 ภายใน API เหล่านี้ บริการ database ถูกยกเลิกใน Odoo 20 ขณะที่บริการ common และ object มีกำหนดให้ยังอยู่จนถึง Odoo 22 (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) การอินทิเกรตที่ใช้บริการซึ่งยังคงอยู่ อาจยังทำงานได้หลังอัปเกรดเป็น Odoo 20 แต่ endpoint เพียงอย่างเดียวไม่ได้ยืนยันความเข้ากันได้
ระบบหนึ่งสามารถใช้บริการต่างกันผ่านอินเทอร์เฟซ RPC แบบเดิมได้ ดังนั้นการตรวจสอบอินทิเกรชันควรบันทึกทั้ง endpoint และบริการที่เรียก การอธิบายแอปพลิเคชันเพียงว่าเป็นการอินทิเกรต XML-RPC หรือ JSON-RPC ไม่ได้แสดงว่ามันพึ่งพาการทำงานที่ถูกยกเลิกใน Odoo 20 หรือไม่ (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
ความพร้อมใช้งานต่อไปของบริการ common และ object เป็นเพียงชั่วคราว Odoo กำหนดให้ทั้งสองบริการถูกยกเลิกใน Odoo 22 (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) ทีมงานสามารถแยกงานเร่งด่วนที่เกี่ยวกับการเรียกบริการฐานข้อมูลออกจากการย้ายบริการที่ยังคงอยู่ได้ แต่ทั้งสองส่วนต้องมีแผน
JSON-2 เปลี่ยนสัญญาการร้องขอ
Odoo ระบุว่า JSON-2 เป็น API ทดแทน รูปแบบ endpoint คือ `/json/2/<model>/<method>` โดยใส่ model และ method ไว้ใน URL (Odoo master Docs: Reference External API) ดังนั้นการย้ายจึงไม่ใช่แค่เปลี่ยน base path ในไคลเอนต์ RPC เดิม แต่ละการทำงานต้องถูกแมปไปยังเส้นทาง model และ method ที่เหมาะสม
JSON-2 ต้องใช้อาร์กิวเมนต์แบบตั้งชื่อใน body ของคำขอ JSON แทนอาร์กิวเมนต์ RPC แบบตำแหน่ง (Odoo master Docs: Reference External API) wrapper, middleware และไคลเอนต์ที่สร้างอัตโนมัติที่มีอยู่ อาจสมมติว่าลำดับของอาร์กิวเมนต์เป็นตัวกำหนดความหมาย องค์ประกอบเหล่านั้นต้องได้รับการตรวจสอบทีละส่วน การส่งต่อคำขอเดิมไปยัง endpoint ใหม่จะไม่ทำงานหากไคลเอนต์ยังคงสร้างพารามิเตอร์แบบตำแหน่ง
สำหรับแต่ละการทำงานที่ย้ายแล้ว ทีมงานควรบันทึก model เป้าหมาย method และอาร์กิวเมนต์แบบตั้งชื่อที่ JSON-2 ต้องใช้ (Odoo master Docs: Reference External API) จากนั้นควรทดสอบคำขอในสภาพแวดล้อม Odoo 20 ที่เกี่ยวข้อง โดยเฉพาะเมื่อไลบรารีอินทิเกรชันที่ใช้ร่วมกันสร้างคำขอสำหรับหลายแอปพลิเคชัน การเปรียบเทียบ payload แบบคงที่ไม่สามารถยืนยันได้ว่าเซิร์ฟเวอร์หรือไคลเอนต์จัดการคำขอทั้งหมดอย่างไร
การยืนยันตัวตนก็ต้องเปลี่ยนด้วย
JSON-2 ใช้การยืนยันตัวตนด้วย bearer API-key (Odoo master Docs: Reference External API)งานย้ายระบบควรครอบคลุมการสร้างคีย์ การจัดเก็บอย่างปลอดภัย การจัดการส่วนหัวการอนุมัติ และการแทนที่คีย์ พร็อกซี เกตเวย์ และไลบรารีฝั่งไคลเอนต์ควรได้รับการตรวจสอบเพื่อให้แน่ใจว่ารักษาส่วนหัวไว้เมื่อส่งต่อคำขอ ควรทบทวนการบันทึก การเฝ้าระวัง และการจัดการข้อผิดพลาดด้วย เพื่อไม่ให้ข้อมูลรับรองถูกเปิดเผย
เอกสารกำหนดวิธีการยืนยันตัวตนแล้ว แต่แต่ละองค์กรต้องกำหนดเองว่า API key จะสอดคล้องกับการควบคุมข้อมูลรับรองอย่างไร (Odoo master Docs: Reference External API) ซึ่งรวมถึงการกำหนดผู้รับผิดชอบคีย์ การควบคุมว่าคีย์จะถูกใช้ที่ใดได้บ้าง และการกำหนดวิธีอัปเดตการเชื่อมต่อที่ได้รับผลกระทบเมื่อมีการแทนที่คีย์
ฟิลด์ไบนารีมีการเปลี่ยนแปลงความเข้ากันได้แยกต่างหาก
บันทึกการเปลี่ยนแปลง ORM ของ Odoo ระบุการเปลี่ยนแปลง RPC อีกอย่างใน Odoo 20 คือ การแทนค่าของฟิลด์ไบนารีเพิ่ม `BinaryValue.filename` (Odoo master Docs: Orm Changelog) เรื่องนี้แยกจากการนำ database-service ออก เพราะเป็นการเปลี่ยนข้อมูลที่ส่งกลับมา ไม่ใช่ความพร้อมใช้งานของบริการ แอปพลิเคชันที่อ่าน แปลง หรือตรวจสอบความถูกต้องของคำตอบที่มีฟิลด์ไบนารีควรถูกนำรวมไว้ในการทดสอบความเข้ากันได้
บันทึกการเปลี่ยนแปลงยืนยันว่าได้เพิ่มสมาชิก `filename` แต่ผลในทางปฏิบัติขึ้นอยู่กับไคลเอนต์ (Odoo master Docs: Orm Changelog) การทดสอบควรตรวจสอบว่า schema ที่เข้มงวด ตัวแปลงข้อมูลแบบซีเรียล การเปรียบเทียบคำตอบ และการแปลงต่อเนื่องยอมรับสมาชิกเพิ่มเติมนี้หรือไม่ ไคลเอนต์ที่ไม่สนใจฟิลด์ที่ไม่รู้จักอาจไม่ต้องปรับแก้ แต่พฤติกรรมดังกล่าวควรได้รับการยืนยัน ไม่ใช่คาดเอาเอง
วิธีการกำหนดขอบเขตการตรวจสอบการผสานระบบ
เริ่มต้นด้วยการระบุการเชื่อมต่อที่ใช้ `/xmlrpc`, `/xmlrpc/2` หรือ `/jsonrpc` ซึ่ง Odoo ระบุว่าเป็นปลายทางที่เลิกใช้แล้ว (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) รายการควรครอบคลุมแอปพลิเคชันที่พัฒนาภายใน มิดเดิลแวร์ กระบวนการตามกำหนดเวลา และตัวเชื่อมต่อของบุคคลที่สามที่มีการเข้าถึงการกำหนดค่าหรือซอร์สโค้ดได้ กำหนดเจ้าของให้แต่ละการเชื่อมต่อ เพื่อให้สามารถยืนยันวัตถุประสงค์และสถานะได้
ถัดไป ให้จัดประเภทแต่ละการเชื่อมต่อตามบริการเดิม การใช้ database-service ต้องได้รับการแก้ไขสำหรับ Odoo 20 ขณะที่การใช้ common service และ object service ยังคงระบุว่าสามารถใช้งานได้จนถึง Odoo 22 (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) สิ่งนี้สนับสนุนแผนแบบเป็นขั้นตอน, จัดการความไม่เข้ากันกับ Odoo 20 ก่อน จากนั้นกำหนดวันที่ย้ายระบบสำหรับการเรียกที่เลิกใช้แล้วที่เหลือ
สำหรับการผสานระบบที่ย้ายไปใช้ JSON-2 ให้บันทึกเส้นทาง `/json/2/<model>/<method>` อาร์กิวเมนต์ของคำขอที่มีชื่อ และการยืนยันตัวตนด้วย bearer API-key ที่อินเทอร์เฟซทดแทนต้องใช้ (Odoo master Docs: Reference External API) ชุดทดสอบควรครอบคลุมคำขอที่สำเร็จ การยืนยันตัวตนที่ถูกปฏิเสธ อาร์กิวเมนต์ที่มีชื่อไม่ถูกต้อง และการจัดการข้อมูลที่ส่งกลับมาของแอปพลิเคชัน ให้เพิ่มกรณีของฟิลด์ไบนารีทุกครั้งที่มีฟิลด์ดังกล่าว
ยืนยันพฤติกรรมสุดท้ายของ Odoo 20
รายละเอียดการนำออกมาจากเอกสารสำหรับนักพัฒนาของ Odoo master ส่วนกำหนดเวลาที่ประกาศมาจากหน้าอีเวนต์ที่ระบุว่า Odoo 20 จะเปิดตัวในงาน Americas เดือนกันยายน 2026 (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) ก่อนปรับใช้งาน ทีมงานควรตรวจสอบเอกสารอีกครั้งสำหรับ Odoo 20 เวอร์ชันที่เผยแพร่แล้ว และ edition กับ build ที่ต้องการใช้ให้แน่ชัด
การใช้ปลายทาง RPC ที่เลิกใช้แล้วเพียงอย่างเดียวไม่ได้พิสูจน์ว่าอินทิเกรชันจะหยุดทำงานใน Odoo 20 เพราะ common service และ object service ยังคงระบุว่าสามารถใช้งานได้จนถึง Odoo 22 ในทางกลับกัน การทำงานสำเร็จบนเวอร์ชันก่อนหน้าไม่ได้ยืนยันความเข้ากันได้สำหรับการเรียก database-service หลังจากถูกนำออก (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
รายการตรวจสอบการตัดสินใจอัปเกรด
ก่อนอนุมัติการอัปเกรดเป็น Odoo 20 ผู้มีอำนาจตัดสินใจควรขอทะเบียนการผสานระบบที่แสดงปลายทางที่เลิกใช้แล้วแต่ละรายการ บริการที่ถูกเรียก เจ้าของ และการแก้ไขที่วางแผนไว้ ความเชื่อมโยงที่พึ่งพา database-service ควรมีทางเลือกทดแทนที่ได้ทดสอบแล้ว ส่วนการผสานระบบที่ยังใช้ common service หรือ object service ควรมีกำหนดการย้ายระบบแยกต่างหากที่สะท้อนการนำออกตามเอกสารใน Odoo 22 (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
การตรวจสอบควรยืนยันว่า การใช้งาน JSON-2 วางโมเดลและเมธอดไว้ใน URL ใช้อาร์กิวเมนต์ JSON แบบตั้งชื่อ และยืนยันตัวตนด้วย API key แบบ bearer หากมีฟิลด์ไบนารี การทดสอบควรคำนึงถึงการเพิ่ม `BinaryValue.filename` (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) การตรวจสอบเหล่านี้ช่วยแยกแยะการนำบริการฐานข้อมูลของ Odoo 20 ออกไปในทันทีจากการยุติการให้บริการแบบเดิมที่เหลืออยู่ในภายหลัง