La documentazione master di Odoo indica che il servizio RPC legacy del database viene rimosso in Odoo 20. Le API XML-RPC e JSON-RPC più ampie sono deprecate dalla versione 19.0, ma Odoo 20 non rimuove tutti i servizi legacy. La documentazione di Odoo indica che i servizi common e object resteranno disponibili fino a Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) I team di integrazione devono quindi identificare il servizio usato da ciascuna connessione esterna, invece di considerare il supporto RPC legacy come una singola funzionalità con una sola data di rimozione.
La pagina dell'evento Americas di Odoo indicava che Odoo 20 sarebbe stato rilasciato durante l'evento di San Francisco del 2 e 3 settembre 2026. (Oxp26 Americas Introduction) La pianificazione dell'aggiornamento può già tenere conto della rimozione documentata del servizio database, ma le decisioni di produzione dovrebbero essere verificate rispetto alla documentazione finale del rilascio di Odoo 20.
La rimozione riguarda un servizio specifico
Odoo identifica `/xmlrpc`, `/xmlrpc/2` e `/jsonrpc` come endpoint legacy deprecati dalla versione 19.0. All'interno di queste API, il servizio database viene rimosso in Odoo 20, mentre i servizi common e object sono programmati per rimanere fino a Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Un'integrazione che usa un servizio mantenuto può continuare a funzionare dopo un aggiornamento a Odoo 20, ma il solo endpoint non stabilisce la compatibilità.
Un sistema può usare servizi diversi tramite l'interfaccia RPC legacy. Una revisione dell'integrazione dovrebbe quindi registrare sia l'endpoint sia il servizio chiamato. Descrivere un'applicazione solo come integrazione XML-RPC o JSON-RPC non mostra se dipende da un'operazione rimossa in Odoo 20. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
La disponibilità continuata dei servizi common e object è temporanea. Odoo ne prevede la rimozione in Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) I team possono separare il lavoro urgente sulle chiamate al servizio database dalla migrazione dei servizi mantenuti, ma entrambi richiedono un piano.
JSON-2 cambia il contratto della richiesta
Odoo documenta JSON-2 come API sostitutiva. Il formato dell'endpoint è `/json/2/<model>/<method>`, con model e method inclusi nell'URL. (Odoo master Docs: Reference External API) La migrazione quindi richiede più che sostituire il base path in un client RPC esistente. Ogni operazione deve essere mappata al percorso corretto di model e method.
JSON-2 richiede argomenti con nome in un body JSON della richiesta, invece di argomenti RPC posizionali. (Odoo master Docs: Reference External API) Wrapper, middleware e client generati esistenti possono assumere che l'ordine degli argomenti ne determini il significato. Questi componenti richiedono una revisione individuale. Reindirizzare una richiesta legacy al nuovo endpoint non funzionerà se il client continua a costruire parametri posizionali.
Per ogni operazione migrata, i team dovrebbero documentare il model di destinazione, il method e gli argomenti con nome richiesti da JSON-2. (Odoo master Docs: Reference External API) Le richieste dovrebbero quindi essere testate nell'ambiente Odoo 20 pertinente, in particolare quando una libreria di integrazione condivisa costruisce chiamate per più applicazioni. I confronti statici dei payload non possono confermare come il server o il client gestisca l'intera richiesta.
Anche l'autenticazione deve cambiare
JSON-2 usa l'autenticazione con API key bearer. (Odoo master Docs: Reference External API) Il lavoro di migrazione dovrebbe coprire la creazione delle chiavi, l'archiviazione sicura, la gestione dell'intestazione di autorizzazione e la sostituzione delle chiavi. Proxy, gateway e librerie client dovrebbero essere verificati per assicurarsi che preservino l'intestazione durante l'inoltro delle richieste. Anche la registrazione, il monitoraggio e la gestione degli errori dovrebbero essere riesaminati, in modo che le credenziali non vengano esposte.
La documentazione stabilisce il metodo di autenticazione, ma ogni organizzazione deve determinare come le chiavi API si inseriscono nei propri controlli delle credenziali. (Odoo master Docs: Reference External API) Questo include l'assegnazione della responsabilità delle chiavi, il controllo di dove possono essere usate e la definizione di come le integrazioni interessate verranno aggiornate quando una chiave viene sostituita.
I campi binari hanno una modifica di compatibilità separata
Il changelog dell'ORM di Odoo registra un'altra modifica RPC di Odoo 20: la rappresentazione dei campi binari aggiunge `BinaryValue.filename`. (Odoo master Docs: Orm Changelog) Questo è distinto dalla rimozione del servizio database, perché modifica i dati restituiti anziché la disponibilità del servizio. Le applicazioni che leggono, trasformano o validano risposte contenenti campi binari dovrebbero essere incluse nei test di compatibilità.
Il changelog conferma che il membro `filename` viene aggiunto, ma il suo effetto pratico dipende dal client. (Odoo master Docs: Orm Changelog) I test dovrebbero verificare se schemi rigorosi, serializer, confronti delle risposte e trasformazioni a valle accettano il membro aggiuntivo. I client che ignorano i campi sconosciuti potrebbero non richiedere alcun adeguamento, ma questo comportamento dovrebbe essere verificato anziché dato per scontato.
Come delimitare l'audit dell'integrazione
Iniziate identificando le connessioni che usano `/xmlrpc`, `/xmlrpc/2` o `/jsonrpc`, che Odoo indica come endpoint deprecati. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) L'inventario dovrebbe includere applicazioni sviluppate internamente, middleware, processi pianificati e connettori di terze parti, quando la configurazione o il codice sorgente sono disponibili. Assegnate un responsabile a ciascuna connessione, in modo che il suo scopo e il suo stato possano essere verificati.
Poi classificate ogni connessione per servizio legacy. L'uso del servizio database richiede una correzione per Odoo 20, mentre l'uso dei servizi common e object rimane documentato come disponibile fino a Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Questo supporta un piano a fasi: affrontate prima l'incompatibilità di Odoo 20, poi impostate le date di migrazione per le restanti chiamate deprecate.
Per le integrazioni che passano a JSON-2, registrate il percorso `/json/2/<model>/<method>`, gli argomenti della richiesta con nome e l'autenticazione bearer con chiave API richiesta dall'interfaccia sostitutiva. (Odoo master Docs: Reference External API) I casi di test dovrebbero coprire richieste riuscite, autenticazione rifiutata, argomenti con nome non validi e la gestione da parte dell'applicazione dei dati restituiti. Aggiungete casi per campi binari ogni volta che tali campi sono presenti.
Confermate il comportamento finale di Odoo 20
I dettagli della rimozione sono tratti dalla documentazione per sviluppatori master di Odoo, mentre il timing annunciato del rilascio proviene da una pagina evento che afferma che Odoo 20 sarebbe stato rilasciato durante l'evento Americas di settembre 2026. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) Prima del deployment, i team dovrebbero ricontrollare la documentazione per la versione rilasciata di Odoo 20 e l'edizione e la build esatte che intendono usare.
L'uso di un endpoint RPC deprecato non dimostra da solo che un'integrazione smetterà di funzionare in Odoo 20, perché i servizi common e object restano documentati fino a Odoo 22. Viceversa, il funzionamento riuscito su una versione precedente non stabilisce la compatibilità di una chiamata al servizio database dopo la sua rimozione. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Checklist decisionale per l'upgrade
Prima di approvare un upgrade a Odoo 20, i decisori dovrebbero richiedere un registro delle integrazioni che mostri ogni endpoint deprecato, il servizio chiamato, il relativo responsabile e la correzione pianificata. Le dipendenze dal servizio database dovrebbero avere una sostituzione testata. Le integrazioni che restano sui servizi common o object dovrebbero avere una data di migrazione separata, che rifletta la loro rimozione documentata in Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
La revisione dovrebbe confermare che le implementazioni JSON-2 inseriscono il modello e il metodo nell'URL, utilizzano argomenti JSON con nome e si autenticano con una chiave API bearer. Quando sono presenti campi binari, i test dovrebbero tenere conto dell'aggiunta di `BinaryValue.filename`. (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) Questi controlli distinguono l'immediata rimozione del database-service in Odoo 20 dal successivo ritiro degli altri servizi legacy.