У головній документації Odoo зазначено, що застарілу RPC-службу бази даних видаляють в Odoo 20. Ширші XML-RPC та JSON-RPC API вважаються застарілими з версії 19.0, але Odoo 20 не видаляє всі застарілі служби. У документації Odoo зазначено, що служби common та object залишатимуться доступними до Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Отже, командам інтеграції потрібно визначити службу, яку використовує кожне зовнішнє з’єднання, а не розглядати підтримку застарілого RPC як одну функцію з однією датою видалення.
На сторінці події Odoo для Америки було зазначено, що Odoo 20 вийде під час заходу в Сан-Франциско 2 і 3 вересня 2026 року. (Oxp26 Americas Introduction) Планування оновлення вже може враховувати задокументоване видалення служби бази даних, але виробничі рішення слід перевіряти за фінальною документацією релізу Odoo 20.
Видалення стосується конкретної служби
Odoo визначає `/xmlrpc`, `/xmlrpc/2` і `/jsonrpc` як застарілі кінцеві точки, застарілі з версії 19.0. У межах цих API службу бази даних видаляють в Odoo 20, тоді як служби common та object заплановано залишити до Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Інтеграція, яка використовує збережену службу, може продовжити працювати після оновлення до Odoo 20, але сама кінцева точка ще не означає сумісність.
Система може використовувати різні служби через застарілий RPC-інтерфейс. Тому під час огляду інтеграції слід фіксувати і кінцеву точку, і викликану службу. Описувати застосунок лише як інтеграцію 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. Формат його кінцевої точки такий: `/json/2/<model>/<method>`, де model і method включено до URL. (Odoo master Docs: Reference External API) Отже, міграція означає більше, ніж просто заміну базового шляху в наявному RPC-клієнті. Кожну операцію потрібно зіставити з відповідним маршрутом model і method.
JSON-2 вимагає іменованих аргументів у тілі JSON-запиту, а не позиційних RPC-аргументів. (Odoo master Docs: Reference External API) Існуючі обгортки, проміжне ПЗ та згенеровані клієнти можуть припускати, що значення аргументів визначає їхній порядок. Ці компоненти потрібно перевірити окремо. Перенаправлення застарілого запиту на нову кінцеву точку не спрацює, якщо клієнт і надалі формує позиційні параметри.
Для кожної перенесеної операції команди мають задокументувати цільову модель, метод і іменовані аргументи, потрібні для JSON-2. (Odoo master Docs: Reference External API) Далі запити слід протестувати у відповідному середовищі Odoo 20, особливо коли спільна інтеграційна бібліотека формує виклики для кількох застосунків. Порівняння статичних корисних навантажень не може підтвердити, як сервер або клієнт обробляє повний запит.
Також має змінитися автентифікація
JSON-2 використовує автентифікацію за bearer API key. (Odoo master Docs: Reference External API) Міграційні роботи мають охоплювати створення ключів, безпечне зберігання, обробку заголовка авторизації та заміну ключів. Проксі, шлюзи та клієнтські бібліотеки слід перевірити, щоб переконатися, що вони зберігають заголовок під час пересилання запитів. Також слід переглянути журналювання, моніторинг і обробку помилок, щоб облікові дані не були розкриті.
Документація встановлює метод автентифікації, але кожна організація має визначити, як API-ключі вписуються в її контроль облікових даних. (Odoo master Docs: Reference External API) Це включає призначення відповідальності за ключі, контроль місць, де їх можна використовувати, і визначення того, як відповідні інтеграції буде оновлено після заміни ключа.
Поля binary мають окрему зміну сумісності
Журнал змін ORM Odoo фіксує ще одну зміну RPC в Odoo 20: представлення полів binary додає `BinaryValue.filename`. (Odoo master Docs: Orm Changelog) Це окремо від вилучення database-service, оскільки змінюються повернуті дані, а не доступність сервісу. Застосунки, які читають, перетворюють або перевіряють відповіді, що містять поля binary, слід включити до тестування сумісності.
Журнал змін підтверджує, що член `filename` додається, але його практичний вплив залежить від клієнта. (Odoo master Docs: Orm Changelog) Тести мають перевірити, чи приймають додатковий член суворі схеми, серіалізатори, порівняння відповідей і подальші перетворення. Клієнтам, які ігнорують невідомі поля, може не знадобитися жодних змін, але це слід перевірити, а не припускати.
Як визначити обсяг аудиту інтеграцій
Почніть з виявлення з’єднань, які використовують `/xmlrpc`, `/xmlrpc/2` або `/jsonrpc`, які Odoo позначає як застарілі кінцеві точки. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Інвентар має охоплювати внутрішньо розроблені застосунки, проміжне програмне забезпечення, заплановані процеси та сторонні конектори, для яких доступна конфігурація або вихідний код. Призначте власника для кожного з’єднання, щоб можна було перевірити його призначення та стан.
Далі класифікуйте кожне з’єднання за застарілим сервісом. Використання database-service потребує виправлення для Odoo 20, тоді як використання common і 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-ключем, яку вимагає замінний інтерфейс. (Odoo master Docs: Reference External API) Тестові випадки мають охоплювати успішні запити, відхилену автентифікацію, недійсні іменовані аргументи та обробку повернених даних застосунком. Додавайте випадки для binary-полів всюди, де вони зустрічаються.
Підтвердіть остаточну поведінку Odoo 20
Дані про вилучення взяті з майстер-документації розробника Odoo, тоді як оголошені терміни випуску взято зі сторінки події, де зазначено, що Odoo 20 буде випущено під час Americas event у вересні 2026 року. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) Перед розгортанням команди мають ще раз перевірити документацію для випущеної версії Odoo 20 та точну редакцію і збірку, які вони планують використовувати.
Використання застарілого RPC-ендпойнта саме по собі не доводить, що інтеграція перестане працювати в Odoo 20, оскільки common і object services залишаються задокументованими як доступні до Odoo 22. Навпаки, успішна робота в попередній версії не встановлює сумісність для виклику database-service після його вилучення. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Контрольний список для рішення щодо оновлення
Перед затвердженням оновлення до Odoo 20 особи, що ухвалюють рішення, мають запросити реєстр інтеграцій із зазначенням кожного застарілого ендпойнта, викликаного сервісу, його власника та запланованого виправлення. Залежності від database-service повинні мати перевірену заміну. Інтеграції, що залишаються на common або object services, повинні мати окрему дату міграції, яка враховує їх задокументоване вилучення в Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Перевірка має підтвердити, що реалізації JSON-2 розміщують модель і метод в URL, використовують іменовані аргументи JSON та автентифікуються за допомогою bearer API key. Якщо присутні бінарні поля, тестування має враховувати додавання `BinaryValue.filename`. (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) Ці перевірки відрізняють негайне вилучення сервісу бази даних в Odoo 20 від пізнішого виведення з експлуатації решти застарілих сервісів.