Documentația principală Odoo afirmă că serviciul RPC legacy pentru baze de date este eliminat în Odoo 20. API-urile XML-RPC și JSON-RPC, în sens larg, sunt depreciate din versiunea 19.0, dar Odoo 20 nu elimină toate serviciile legacy. Odoo documentează serviciile common și object ca fiind disponibile până la Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Prin urmare, echipele de integrare trebuie să identifice serviciul folosit de fiecare conexiune externă, nu să trateze suportul RPC legacy ca pe o singură funcționalitate cu o singură dată de eliminare.
Pagina evenimentului Odoo pentru Americi a spus că Odoo 20 va fi lansat în cadrul evenimentului din San Francisco, pe 2 și 3 septembrie 2026. (Oxp26 Americas Introduction) Planificarea upgrade-ului poate lua acum în calcul eliminarea documentată a serviciului pentru baze de date, dar deciziile de producție trebuie verificate în raport cu documentația finală de lansare Odoo 20.
Eliminarea se aplică unui serviciu specific
Odoo identifică `/xmlrpc`, `/xmlrpc/2` și `/jsonrpc` drept endpointuri legacy depreciate din versiunea 19.0. În cadrul acestor API-uri, serviciul pentru baze de date este eliminat în Odoo 20, iar serviciile common și object sunt programate să rămână până la Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) O integrare care folosește un serviciu păstrat poate continua să funcționeze după un upgrade la Odoo 20, dar endpointul singur nu stabilește compatibilitatea.
Un sistem poate folosi servicii diferite prin interfața RPC legacy. O analiză a integrării ar trebui, prin urmare, să noteze atât endpointul, cât și serviciul apelat. Descrierea unei aplicații doar ca integrare XML-RPC sau JSON-RPC nu arată dacă depinde de o operațiune eliminată în Odoo 20. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Disponibilitatea continuă a serviciilor common și object este temporară. Odoo programează eliminarea ambelor în Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Echipele pot separa lucrările urgente pentru apelurile serviciului de baze de date de migrarea serviciilor păstrate, dar ambele necesită un plan.
JSON-2 schimbă contractul cererii
Odoo documentează JSON-2 ca API de înlocuire. Formatul endpointului este `/json/2/<model>/<method>`, cu modelul și metoda incluse în URL. (Odoo master Docs: Reference External API) Migrarea implică, așadar, mai mult decât înlocuirea bazei de cale într-un client RPC existent. Fiecare operațiune trebuie mapată la ruta corectă pentru model și metodă.
JSON-2 necesită argumente numite într-un corp JSON al cererii, nu argumente RPC poziționale. (Odoo master Docs: Reference External API) Wrapper-ele existente, middleware-ul și clienții generați pot presupune că ordinea argumentelor determină sensul. Aceste componente au nevoie de o verificare individuală. Redirecționarea unei cereri legacy către noul endpoint nu va funcționa dacă clientul continuă să construiască parametri poziționali.
Pentru fiecare operațiune migrată, echipele ar trebui să documenteze modelul țintă, metoda și argumentele numite cerute de JSON-2. (Odoo master Docs: Reference External API) Cererile ar trebui apoi testate în mediul Odoo 20 relevant, mai ales când o bibliotecă de integrare partajată construiește apeluri pentru mai multe aplicații. Comparațiile statice ale payload-urilor nu pot confirma modul în care serverul sau clientul gestionează cererea completă.
Autentificarea trebuie să se schimbe, de asemenea
JSON-2 folosește autentificare prin cheie API bearer. (Odoo master Docs: Reference External API) Activitatea de migrare ar trebui să acopere crearea cheilor, stocarea securizată, gestionarea antetului de autorizare și înlocuirea cheilor. Proxy-urile, gateway-urile și bibliotecile client ar trebui verificate pentru a se asigura că păstrează antetul la redirecționarea solicitărilor. De asemenea, ar trebui revizuite logarea, monitorizarea și gestionarea erorilor, astfel încât acreditările să nu fie expuse.
Documentația stabilește metoda de autentificare, dar fiecare organizație trebuie să determine cum se potrivesc cheile API în controalele sale pentru acreditări. (Odoo master Docs: Reference External API) Aceasta include atribuirea responsabilității pentru chei, controlul locurilor în care pot fi utilizate și definirea modului în care integrările afectate vor fi actualizate când o cheie este înlocuită.
Câmpurile binare au o modificare separată de compatibilitate
Jurnalul de modificări al ORM-ului Odoo înregistrează o altă schimbare RPC în Odoo 20: reprezentarea câmpurilor binare adaugă `BinaryValue.filename`. (Odoo master Docs: Orm Changelog) Aceasta este separată de eliminarea serviciului de baze de date, deoarece modifică datele returnate, nu disponibilitatea serviciului. Aplicațiile care citesc, transformă sau validează răspunsuri ce conțin câmpuri binare ar trebui incluse în testarea de compatibilitate.
Jurnalul de modificări confirmă că membrul `filename` este adăugat, dar efectul său practic depinde de client. (Odoo master Docs: Orm Changelog) Testele ar trebui să verifice dacă schemele stricte, serializatoarele, comparațiile răspunsurilor și transformările din aval acceptă membrul suplimentar. Clienții care ignoră câmpurile necunoscute pot să nu necesite ajustări, dar acest comportament ar trebui verificat, nu presupus.
Cum să delimitați auditul integrării
Începeți prin a identifica conexiunile care folosesc `/xmlrpc`, `/xmlrpc/2` sau `/jsonrpc`, pe care Odoo le marchează drept puncte finale depreciate. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Inventarul ar trebui să acopere aplicațiile dezvoltate intern, middleware-ul, procesele programate și conectorii terți pentru care configurarea sau codul sursă este disponibil. Atribuiți un responsabil fiecărei conexiuni, astfel încât scopul și starea ei să poată fi verificate.
Apoi, clasificați fiecare conexiune după serviciul moștenit. Utilizarea serviciului de baze de date necesită remediere pentru Odoo 20, în timp ce utilizarea serviciilor common și object rămâne documentată ca disponibilă până la Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Aceasta sprijină un plan etapizat: abordați mai întâi incompatibilitatea Odoo 20, apoi stabiliți datele de migrare pentru apelurile depreciate rămase.
Pentru integrările care trec la JSON-2, înregistrați ruta `/json/2/<model>/<method>`, argumentele cererii numite și autentificarea bearer cu cheia API cerute de interfața de înlocuire. (Odoo master Docs: Reference External API) Cazurile de test ar trebui să acopere solicitări reușite, autentificare respinsă, argumente numite invalide și gestionarea de către aplicație a datelor returnate. Adăugați cazuri pentru câmpuri binare ori de câte ori apar aceste câmpuri.
Confirmați comportamentul final al Odoo 20
Detaliile despre eliminare sunt preluate din documentația de dezvoltator master a Odoo, în timp ce momentul lansării anunțate provine de pe o pagină de eveniment care precizează că Odoo 20 va fi lansat în timpul evenimentului Americas din septembrie 2026. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) Înainte de implementare, echipele ar trebui să verifice din nou documentația pentru versiunea Odoo 20 lansată și ediția și buildul exacte pe care intenționează să le folosească.
Folosirea unui punct final RPC depreciat nu dovedește, prin ea însăși, că o integrare va înceta să funcționeze în Odoo 20, deoarece serviciile common și object rămân documentate ca disponibile până la Odoo 22. În mod invers, funcționarea cu succes pe o versiune anterioară nu stabilește compatibilitatea pentru un apel al serviciului de baze de date după eliminarea acestuia. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Listă de verificare pentru decizia de upgrade
Înainte de a aproba un upgrade la Odoo 20, factorii de decizie ar trebui să solicite un registru al integrărilor care să arate fiecare punct final depreciat, serviciul apelat, responsabilul și remedierea planificată. Dependențele de serviciul de baze de date ar trebui să aibă un înlocuitor testat. Integrările care rămân pe serviciile common sau object ar trebui să aibă o dată separată de migrare, care să reflecte eliminarea documentată în Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Revizuirea ar trebui să confirme că implementările JSON-2 plasează modelul și metoda în URL, folosesc argumente JSON numite și se autentifică cu o cheie API bearer. Unde sunt prezente câmpuri binare, testarea ar trebui să țină cont de adăugarea `BinaryValue.filename`. (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) Aceste verificări disting eliminarea imediată din Odoo 20 a serviciului de bază de date de retragerea ulterioară a celorlalte servicii legacy rămase.