Мастер документацията на 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 за Americas посочваше, че 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) Съществуващи обвивки, междинен софтуер и генерирани клиенти може да приемат, че редът на аргументите определя значението. Тези компоненти трябва да бъдат прегледани поотделно. Пренасочването на наследена заявка към новата крайна точка няма да работи, ако клиентът продължи да изгражда позиционни параметри.
За всяка мигрирана операция екипите трябва да документират целевия model, method и именуваните аргументи, изисквани от JSON-2. (Odoo master Docs: Reference External API) След това заявките трябва да бъдат тествани в съответната среда на Odoo 20, особено когато споделена интеграционна библиотека изгражда извиквания за няколко приложения. Статичните сравнения на полезните товари не могат да потвърдят как сървърът или клиентът обработва цялата заявка.
Автентикацията също трябва да се промени
JSON-2 използва автентикация с bearer API ключ. (Odoo master Docs: Reference External API) Работата по миграцията трябва да обхване създаването на ключове, сигурното им съхранение, обработката на заглавката за авторизация и подмяната на ключове. Проксита, шлюзове и клиентски библиотеки трябва да бъдат проверени, за да се гарантира, че запазват заглавката при препращане на заявки. Логването, мониторингът и обработката на грешки също трябва да бъдат прегледани, за да не се разкриват идентификационни данни.
Документацията установява метода за удостоверяване, но всяка организация трябва да определи как API ключовете се вписват в нейните контроли за идентификационни данни. (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) Тестовете трябва да проверят дали строгите схеми, сериализаторите, сравненията на отговори и последващите трансформации приемат допълнителния член. Клиентите, които игнорират непознати полета, може да не изискват корекция, но това поведение трябва да бъде проверено, а не предположено.
Как да се обхване одитът на интеграциите
Започнете с идентифициране на връзки, които използват `/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) Тестовите случаи трябва да обхващат успешни заявки, отказано удостоверяване, невалидни именувани аргументи и обработка от приложението на върнатите данни. Добавете случаи с бинарни полета навсякъде, където се срещат тези полета.
Потвърдете окончателното поведение на 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 и точната редакция и build, които възнамеряват да използват.
Използването на отхвърлена RPC крайна точка само по себе си не доказва, че дадена интеграция ще спре да работи в Odoo 20, защото common и object service остават документирани като налични до Odoo 22. Обратно, успешната работа в по-ранна версия не установява съвместимост за извикване на database-service след неговото премахване. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Контролен списък за решение за надстройка
Преди да одобрят надстройка до Odoo 20, лицата, вземащи решения, трябва да поискат регистър на интеграциите, показващ всяка отхвърлена крайна точка, извиканата услуга, нейния собственик и планираната корекция. Зависимостите от database-service трябва да имат тествана замяна. Интеграциите, които остават на common или object service, трябва да имат отделна дата за миграция, отразяваща тяхното документирано премахване в Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Прегледът трябва да потвърди, че имплементациите на JSON-2 поставят модела и метода в URL адреса, използват именувани JSON аргументи и се удостоверяват с API ключ тип bearer. Когато са налични двоични полета, тестването трябва да отчита добавянето на `BinaryValue.filename`. (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) Тези проверки разграничават незабавното премахване на услугата за база данни в Odoo 20 от по-късното изваждане от употреба на останалите наследени услуги.