La panoramica della roadmap Odoo di René Passmann segnala JSON-2 e la prevista sostituzione delle precedenti interfacce XML-RPC e JSON-RPC. Indica un cambiamento, ma non definisce con precisione gli endpoint interessati o le date di rimozione. Consideratela un motivo per verificare le dipendenze, non un’autorizzazione a riscrivere ogni connettore.
Approvate gli interventi correttivi quando un’incompatibilità documentata o una scadenza di supporto applicabile interessa un flusso di lavoro necessario. Quando il rischio è plausibile ma non dimostrato, commissionate un test di compatibilità dal perimetro definito. Se non è stata verificata alcuna incompatibilità rilevante, monitorate la situazione stabilendo esplicitamente cosa farà scattare una nuova verifica. I risultati da richiedere sono un registro delle integrazioni basato su evidenze e una specifica di test circoscritta, non una stima indistinta della migrazione.
Stabilire quale avviso sul ciclo di vita si applica
La panoramica della roadmap descrive una direzione tecnica e Passmann ricorda che una roadmap è una dichiarazione d’intenti, non una garanzia. Per definire il budget, sostituite l’etichetta generica “deprecazione RPC” con l’endpoint, il servizio e l’ambiente di deployment interessati.
L’avviso Odoo sul ciclo di vita delle API RPC identifica /xmlrpc, /xmlrpc/2 e /jsonrpc come deprecati. Specifica che il servizio db è stato rimosso in Odoo 20, mentre la rimozione di common e object è prevista in Odoo 22, nell’autunno 2028, e in Odoo Online 21.1, nell’inverno 2027. Gli altri controller che utilizzano @route(type='jsonrpc') sono espressamente esclusi dall’avviso. Non assegnate quindi interventi di migrazione a un controller personalizzato soltanto perché qualcuno lo descrive come JSON-RPC.
JSON-2 è documentata come novità di Odoo 19.0: non bisogna presumere che arrivi soltanto con il prossimo aggiornamento. Registrate separatamente la versione di partenza e quella di destinazione, includendo il contesto di hosting. Ricontrollate l’avviso applicabile prima di impegnare il budget, distinguendo una rimozione programmata da un malfunzionamento dimostrato nell’ambiente di destinazione.
Costruire un registro basato sui flussi di lavoro, non sui nomi dei connettori
In un webinar sulla sovranità digitale dell’ERP, i relatori indicano il modello operativo e la concentrazione delle dipendenze attorno all’ERP come elementi importanti da considerare. L’implicazione pratica è mappare ciò da cui dipende l’operatività aziendale, compreso chi può occuparsi della manutenzione, anziché limitarsi a elencare le applicazioni collegate.
Per ogni integrazione, chiedete al responsabile di processo e al referente tecnico della manutenzione di compilare questo registro. Allegate, dove possibile, estratti delle configurazioni, riferimenti al codice o documentazione del manutentore.
- Responsabilità aziendale: titolare del processo, risultato richiesto, periodi operativi critici e procedura alternativa accettabile.
- Deployment: versione Odoo attuale e di destinazione, modello di hosting, edizione, abbonamento e condizioni di supporto pertinenti.
- Interfaccia effettiva: endpoint, servizio RPC o controller personalizzato, applicazione chiamante, versione del connettore e metodo di autenticazione. Registrate chi è responsabile delle credenziali, non i segreti.
- Operazioni: letture, creazioni, aggiornamenti e azioni di processo rappresentativi, inclusi campi obbligatori, metodi personalizzati e moduli da cui dipendono.
- Manutenzione: manutentore del connettore, dichiarazione di compatibilità pubblicata, matrice delle versioni supportate e responsabilità per i difetti.
- Scenari di errore: aggiornamenti rifiutati, risposte mancanti e richieste ripetute; chi rileva il problema, riconcilia i dati e autorizza il ripristino.
La scheda per approvare le personalizzazioni ERP distingue l’accettazione della modifica aziendale da parte del responsabile di processo dalla responsabilità del referente tecnico per implementazione, dipendenze e supporto. Qui il fattore scatenante è una modifica esterna dell’interfaccia, non una richiesta di personalizzazione. Verificate se il flusso di lavoro è ancora necessario prima di decidere come mantenerlo.
Non accettate “il connettore supporta Odoo” come prova sufficiente. Richiedete la versione rilasciata del connettore applicabile, l’ambiente di destinazione e le operazioni coperte. Se la risposta riguarda soltanto una release pianificata, mantenete aperta la verifica di compatibilità e incaricate un referente di ottenere una build testabile o valutare un’alternativa.
Commissionare un test di compatibilità circoscritto
La documentazione Odoo di JSON-2 specifica l’autenticazione bearer tramite chiave API e l’uso di argomenti nominati anziché posizionali. I modelli, i campi e i metodi disponibili sono specifici del database e consultabili nella sua pagina /doc. Esaminate i metodi personalizzati necessari nel database di destinazione: una lettura generica riuscita non dimostra la compatibilità.
Verificate anche il diritto di accesso. La restrizione documentata da Odoo per i piani commerciali rende disponibile l’accesso alle API esterne sui piani Custom, ma non su One App Free o Standard. Confermate le condizioni applicabili all’ambiente di destinazione, senza interpretare questa indicazione come una determinazione delle condizioni di licenza dell’edizione Community.
La specifica di test dovrebbe identificare ambiente, account dell’integrazione, build del connettore, dati rappresentativi, risultati aziendali attesi e responsabili dell’accettazione. Richiedete letture e scritture rappresentative, verifiche degli accessi consentiti e negati, esecuzione dei metodi personalizzati e gestione degli errori osservabile. Raccogliete le registrazioni aziendali risultanti, oltre alle evidenze delle richieste e delle risposte.
Scenario ipotetico di accettazione: un’applicazione esterna invia l’aggiornamento di un ordine ma non riceve una risposta utilizzabile. Chiedete al team di stabilire se l’aggiornamento sia stato confermato, dimostrare il ripristino, ripetere la richiesta in condizioni controllate e riconciliare entrambi i sistemi. Superare il test significa accertare lo stato aziendale concordato e assegnare un responsabile alle eccezioni, non soltanto ottenere il successo di un’altra richiesta.
Esaminate con attenzione le scritture articolate in più passaggi. Ogni chiamata JSON-2 viene eseguita nella propria transazione SQL, confermata in caso di successo e annullata in caso di errore; non è possibile concatenare più chiamate in un’unica transazione. Chiedete cosa succede se una chiamata precedente riesce e una successiva fallisce. Il rollback di una transazione non dimostra che ripetere le richieste sia sicuro, né che la vecchia e la nuova interfaccia si comportino allo stesso modo.
Distinguere monitoraggio, test e interventi confermati
Monitorate quando dal registro non emerge alcuna incompatibilità rilevante. Documentate il motivo e stabilite gli eventi che richiedono una nuova verifica, come un cambiamento della release di destinazione, una revisione dell’avviso sul ciclo di vita o una modifica del supporto del manutentore. Un endpoint non identificato non è una prova di compatibilità.
Eseguite i test quando l’endpoint, il modello di autenticazione, i metodi personalizzati o la posizione del manutentore rendono plausibile un rischio. Approvate un’indagine circoscritta, con flussi di lavoro identificati e risultati documentati da consegnare, anziché una riscrittura senza un perimetro definito.
Intervenite quando un’incompatibilità documentata o una scadenza di supporto applicabile interessa un flusso necessario. Confrontate l’aggiornamento a un connettore supportato, una modifica mirata dell’adattatore e la sostituzione usando gli stessi criteri di accettazione. Una riscrittura è giustificata soltanto quando il suo perimetro deriva dalle dipendenze interessate e le alternative non soddisfano il requisito.
Prima di approvare la spesa, riesaminate il registro con ogni responsabile di processo e manutentore, separando le modifiche confermate dalle ipotesi ancora da verificare. Se avete bisogno di supporto funzionale e di sviluppo per delimitare questi interventi, confrontatevi sui flussi interessati e sui test di compatibilità con gli specialisti Odoo di Digiventi.
