Hlavní dokumentace Odoo uvádí, že stará databázová RPC služba je v Odoo 20 odstraněna. Širší XML-RPC a JSON-RPC API jsou od verze 19.0 označena jako zastaralá, ale Odoo 20 neodstraňuje každou starou službu. Odoo uvádí, že služby common a object zůstávají dostupné až do Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Integrační týmy proto musí identifikovat službu použitou každým externím připojením, místo aby považovaly podporu starých RPC za jednu funkci s jediným datem odstranění.
Stránka události Odoo Americas uvedla, že Odoo 20 bude vydáno během akce v San Francisku ve dnech 2. a 3. září 2026. (Oxp26 Americas Introduction) Plánování upgradu může nyní zohlednit zdokumentované odstranění databázové služby, ale rozhodnutí pro produkci je třeba ověřit podle finální dokumentace vydání Odoo 20.
Odstranění se týká konkrétní služby
Odoo uvádí `/xmlrpc`, `/xmlrpc/2` a `/jsonrpc` jako staré endpointy zastaralé od verze 19.0. V rámci těchto API je v Odoo 20 odstraněna databázová služba, zatímco služby common a object mají zůstat do Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Integrace používající zachovanou službu může po upgradu na Odoo 20 nadále fungovat, ale samotný endpoint kompatibilitu nezaručuje.
Systém může přes staré RPC rozhraní používat různé služby. Kontrola integrace by proto měla zaznamenat jak endpoint, tak volanou službu. Popsat aplikaci pouze jako XML-RPC nebo JSON-RPC integraci neukazuje, zda závisí na operaci odstraněné v Odoo 20. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Další dostupnost služeb common a object je dočasná. Odoo plánuje odstranění obou v Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Týmy mohou oddělit urgentní práci na voláních databázové služby od migrace zachovaných služeb, ale obojí vyžaduje plán.
JSON-2 mění kontrakt požadavku
Odoo uvádí JSON-2 jako náhradní API. Jeho formát endpointu je `/json/2/<model>/<method>`, přičemž model i metoda jsou součástí URL. (Odoo master Docs: Reference External API) Migrace tedy znamená víc než jen nahradit základní cestu v existujícím RPC klientovi. Každou operaci je třeba namapovat na odpovídající model a routu metody.
JSON-2 vyžaduje pojmenované argumenty v těle JSON požadavku namísto pozičních RPC argumentů. (Odoo master Docs: Reference External API) Existující wrappery, middleware a generovaní klienti mohou předpokládat, že pořadí argumentů určuje význam. Tyto komponenty vyžadují samostatnou kontrolu. Přesměrování starého požadavku na nový endpoint nebude fungovat, pokud klient nadále sestavuje poziční parametry.
U každé migrované operace by týmy měly zdokumentovat cílový model, metodu a pojmenované argumenty vyžadované JSON-2. (Odoo master Docs: Reference External API) Požadavky by se pak měly otestovat v příslušném prostředí Odoo 20, zejména když sdílená integrační knihovna sestavuje volání pro více aplikací. Statické porovnání payloadů nemůže potvrdit, jak server nebo klient zpracuje celý požadavek.
Musí se změnit také ověřování
JSON-2 používá ověřování pomocí bearer API klíče. (Odoo master Docs: Reference External API) Migrační práce by měla zahrnovat vytvoření klíčů, jejich bezpečné ukládání, zacházení se záhlavím autorizace a nahrazení klíčů. Proxy servery, brány a klientské knihovny je třeba zkontrolovat, aby se ověřilo, že při přeposílání požadavků záhlaví zachovávají. Přehodnotit je třeba také protokolování, monitorování a zpracování chyb, aby nebyly vystaveny přihlašovací údaje.
Dokumentace stanovuje metodu ověřování, ale každá organizace musí určit, jak API klíče zapadají do jejích kontrol přihlašovacích údajů. (Odoo master Docs: Reference External API) To zahrnuje určení odpovědnosti za klíče, řízení toho, kde je lze používat, a definování, jak budou dotčené integrace aktualizovány při nahrazení klíče.
Binární pole mají samostatnou změnu kompatibility
Záznam změn ORM v Odoo uvádí další změnu RPC v Odoo 20: reprezentace binárních polí přidává `BinaryValue.filename`. (Odoo master Docs: Orm Changelog) To je oddělené od odstranění databázové služby, protože mění vracená data, nikoli dostupnost služby. Aplikace, které čtou, transformují nebo ověřují odpovědi obsahující binární pole, by měly být zahrnuty do testování kompatibility.
Záznam změn potvrzuje, že se přidává člen `filename`, ale jeho praktický dopad závisí na klientovi. (Odoo master Docs: Orm Changelog) Testy by měly ověřit, zda přísná schémata, serializátory, porovnávání odpovědí a navazující transformace přijímají přidaný člen. Klienti, kteří ignorují neznámá pole, nemusí vyžadovat žádnou úpravu, ale toto chování je třeba ověřit, nikoli předpokládat.
Jak vymezit audit integrace
Začněte identifikací připojení, která používají `/xmlrpc`, `/xmlrpc/2` nebo `/jsonrpc`, jež Odoo označuje jako zastaralé koncové body. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Inventář by měl zahrnovat interně vyvinuté aplikace, middleware, plánované procesy a konektory třetích stran, u nichž je k dispozici konfigurace nebo zdrojový kód. Ke každému připojení přiřaďte vlastníka, aby bylo možné ověřit jeho účel a stav.
Poté každé připojení zařaďte podle starší služby. Použití databázové služby vyžaduje nápravu pro Odoo 20, zatímco použití společné a objektové služby zůstává podle dokumentace dostupné až do Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) To podporuje postupný plán: nejprve řešte nekompatibilitu s Odoo 20 a poté stanovte migrační termíny pro zbývající zastaralá volání.
U integrací přecházejících na JSON-2 zaznamenejte trasu `/json/2/<model>/<method>`, pojmenované argumenty požadavku a autentizaci pomocí bearer API klíče požadovanou náhradním rozhraním. (Odoo master Docs: Reference External API) Testovací případy by měly zahrnovat úspěšné požadavky, zamítnuté ověření, neplatné pojmenované argumenty a zpracování vrácených dat aplikací. Kde se tato pole vyskytují, přidejte případy s binárním polem.
Potvrďte konečné chování Odoo 20
Podrobnosti o odstranění vycházejí z vývojářské dokumentace Odoo master, zatímco oznámený termín vydání pochází ze stránky události, která uvádí, že Odoo 20 bude vydáno během akce Americas v září 2026. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) Před nasazením by si týmy měly znovu zkontrolovat dokumentaci pro vydanou verzi Odoo 20 a přesnou edici a sestavení, které hodlají použít.
Použití zastaralého RPC koncového bodu samo o sobě neprokazuje, že integrace přestane v Odoo 20 fungovat, protože společná a objektová služba zůstávají podle dokumentace dostupné až do Odoo 22. Naopak úspěšný provoz na starší verzi neprokazuje kompatibilitu pro volání databázové služby po jejím odstranění. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Kontrolní seznam pro rozhodnutí o upgradu
Před schválením upgradu na Odoo 20 by si rozhodující osoby měly vyžádat registr integrací zobrazující každý zastaralý koncový bod, volanou službu, jejího vlastníka a plánovanou nápravu. Závislosti na databázové službě by měly mít otestovanou náhradu. Integrace, které zůstávají na společných nebo objektových službách, by měly mít samostatné datum migrace odrážející jejich zdokumentované odstranění v Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Kontrola by měla potvrdit, že implementace JSON-2 umisťují model a metodu do URL, používají pojmenované argumenty JSON a ověřují se pomocí bearer API klíče. Pokud jsou přítomna binární pole, testování by mělo zohlednit přidání `BinaryValue.filename`. (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) Tyto kontroly odlišují okamžité odstranění databázové služby v Odoo 20 od pozdějšího ukončení zbývajících starších služeb.