El análisis de René Passmann sobre la hoja de ruta de Odoo identifica JSON-2 y la sustitución prevista de las antiguas interfaces XML-RPC y JSON-RPC. Señala un cambio, pero no establece los endpoints concretos afectados ni las fechas de retirada. Considérelo un motivo para auditar las dependencias, no una autorización para reescribir todos los conectores.
Apruebe las correcciones cuando una incompatibilidad documentada o un plazo de soporte aplicable afecte a un flujo de trabajo necesario. Cuando el riesgo sea plausible pero no esté demostrado, encargue una prueba de compatibilidad acotada. Cuando no se haya verificado ninguna incompatibilidad relevante, mantenga la supervisión con un criterio explícito de revisión. Los entregables deben ser un registro de integraciones respaldado por evidencias y una especificación de pruebas con alcance definido, no una estimación de migración que trate todo por igual.
Determine qué aviso de ciclo de vida resulta aplicable
El análisis de la hoja de ruta describe una dirección técnica, y Passmann advierte de que una hoja de ruta es una declaración de intenciones, no una garantía. Para presupuestar, sustituya la etiqueta general «obsolescencia de RPC» por el endpoint, el servicio y el despliegue concretos.
El aviso de ciclo de vida de RPC de Odoo identifica /xmlrpc, /xmlrpc/2 y /jsonrpc como obsoletos. Indica que el servicio db se eliminó en Odoo 20, mientras que la retirada de common y object está prevista para Odoo 22, en otoño de 2028, y Odoo Online 21.1, en invierno de 2027. El aviso excluye expresamente otros controladores que utilicen @route(type='jsonrpc'). No debería asignarse trabajo de migración a un controlador personalizado solo porque alguien lo describa como JSON-RPC.
JSON-2 figura en la documentación como novedad de Odoo 19.0, no como algo que deba suponerse que llegará por primera vez con la siguiente actualización. Registre por separado las versiones de origen y destino, incluido el contexto de alojamiento. Vuelva a comprobar el aviso aplicable antes de comprometer el gasto y distinga entre una retirada programada y un fallo demostrado en el despliegue de destino.
Organice el registro por flujos de trabajo, no por nombres de conectores
En un webinario sobre soberanía digital del ERP, los ponentes señalan el modelo operativo y la concentración de dependencias en torno al ERP como aspectos importantes. La consecuencia práctica es identificar de qué depende el negocio y quién puede mantenerlo, en lugar de limitarse a enumerar las aplicaciones conectadas.
Para cada integración, pida al responsable de negocio y al responsable de mantenimiento técnico que completen este registro. Adjunte extractos de configuración, referencias al código o documentación del mantenedor siempre que sea posible.
- Responsabilidad de negocio: responsable del proceso, resultado necesario, periodos operativos críticos y alternativa aceptable en caso de fallo.
- Despliegue: versiones actual y de destino de Odoo, modelo de alojamiento, edición, suscripción y condiciones de soporte pertinentes.
- Interfaz utilizada realmente: endpoint, servicio RPC o controlador personalizado, aplicación que realiza las llamadas, versión del conector y método de autenticación. Registre quién es responsable de las credenciales, no sus valores secretos.
- Operaciones: lecturas, creaciones, actualizaciones y acciones de negocio representativas, incluidos los campos obligatorios, los métodos personalizados y los módulos dependientes.
- Mantenimiento: mantenedor del conector, declaración de compatibilidad de la versión publicada, matriz de versiones admitidas y responsabilidad sobre los defectos.
- Escenarios de fallo: actualizaciones rechazadas, respuestas ausentes y solicitudes repetidas; quién detecta los problemas, concilia los datos y autoriza la recuperación.
La ficha para aprobar personalizaciones del ERP separa la aceptación del cambio de negocio por parte del responsable del proceso de la responsabilidad técnica sobre la implementación, las dependencias y el soporte. Aquí, el desencadenante es un cambio externo de interfaz, no una personalización solicitada. Compruebe si el flujo de trabajo sigue siendo necesario antes de decidir cómo conservarlo.
No acepte «el conector es compatible con Odoo» como evidencia suficiente. Solicite la versión publicada del conector que corresponda, el despliegue de destino y las operaciones cubiertas. Si la respuesta se limita a una versión prevista, mantenga la compatibilidad como cuestión pendiente y asigne un responsable para obtener una compilación que pueda probarse o evaluar una alternativa.
Encargue una prueba de compatibilidad acotada
La documentación de JSON-2 de Odoo especifica autenticación bearer mediante clave de API y argumentos con nombre en lugar de argumentos posicionales. Los modelos, campos y métodos disponibles son específicos de cada base de datos y pueden consultarse en su página /doc. Examine los métodos personalizados necesarios en la base de datos de destino; no deduzca la compatibilidad a partir de una lectura genérica que haya funcionado.
Verifique también el derecho de acceso. La restricción documentada de los planes comerciales de Odoo permite acceder a la API externa con los planes Custom, pero no con One App Free ni Standard. Confirme las condiciones aplicables al despliegue de destino, en lugar de interpretar esa afirmación como una conclusión sobre las licencias de la edición Community.
La especificación de pruebas debe identificar el entorno, la cuenta de integración, la compilación del conector, los datos representativos, los resultados de negocio esperados y los responsables de aceptación. Exija lecturas y escrituras representativas, comprobaciones de acceso permitido y denegado, ejecución de métodos personalizados y un tratamiento de errores observable. Recopile tanto los registros de negocio resultantes como las evidencias de las solicitudes y respuestas.
Escenario hipotético de aceptación: una aplicación externa envía la actualización de un pedido, pero no recibe una respuesta utilizable. Pida al equipo que determine si la actualización se confirmó, demuestre la recuperación, repita la solicitud en condiciones controladas y concilie ambos sistemas. Superar la prueba significa que se ha establecido el estado de negocio acordado y que las excepciones tienen un responsable, no simplemente que otra solicitud haya funcionado.
Examine con atención las escrituras de varios pasos. Cada llamada a JSON-2 se ejecuta en su propia transacción SQL, que se confirma si tiene éxito y se descarta si hay un error; no es posible encadenar varias llamadas dentro de una única transacción. Pregunte qué ocurre si una llamada anterior tiene éxito y una posterior falla. La reversión de una transacción no demuestra que repetir solicitudes sea seguro ni que las interfaces antigua y nueva se comporten de forma equivalente.
Separe la supervisión, las pruebas y las correcciones confirmadas
Supervise cuando el registro permita establecer que no existe ninguna incompatibilidad relevante. Documente el motivo y defina desencadenantes de revisión, como un cambio de versión de destino, una modificación del aviso de ciclo de vida o un cambio en el soporte del mantenedor. Un endpoint sin identificar no es evidencia de compatibilidad.
Pruebe cuando el endpoint, el patrón de autenticación, los métodos personalizados o la posición del mantenedor planteen un riesgo plausible. Apruebe una investigación acotada, con flujos de trabajo identificados y un entregable de evidencias, en lugar de una reescritura sin límites definidos.
Corrija cuando una incompatibilidad documentada o un plazo de soporte aplicable afecte a un flujo necesario. Compare una actualización del conector con soporte, un cambio puntual del adaptador y su sustitución utilizando los mismos criterios de aceptación. Una reescritura solo se justifica cuando su alcance se deriva de las dependencias afectadas y las alternativas no cumplen el requisito.
Antes de aprobar el gasto, revise el registro con cada responsable de proceso y de mantenimiento, separando los cambios confirmados de los supuestos sin resolver. Si necesita apoyo funcional y de desarrollo para delimitar ese trabajo, comente los flujos afectados y las pruebas de compatibilidad con los especialistas en Odoo de Digiventi.
