Si tienes integraciones montadas sobre Business Central desde hace años, es muy probable que alguna de ellas hable SOAP sin que nadie se acuerde de ello. Puede ser un feed bancario, un enlace con un proveedor EDI, un escáner de almacén algo antiguo o un dataset de Power BI que un consultor montó hace tiempo y que "simplemente funciona". Ese tipo de integración es precisamente la que va a dejar de funcionar cuando actualices a la versión 29 de Business Central.
Vamos a ver, con calma y con las fuentes oficiales de Microsoft delante, qué es lo que realmente cambia, por qué Microsoft lo está haciendo así, y qué puedes hacer para no llevarte una sorpresa.
Un adiós anunciado desde hace diez años
SOAP lleva en la plataforma NAV/Business Central desde Microsoft Dynamics NAV 2009. Durante más de quince años fue la forma por defecto de exponer páginas y codeunits a sistemas externos: conciliación bancaria, proveedores EDI, aplicaciones .NET a medida, capas de reporting… toda una generación de integraciones se construyó sobre SOAP porque, durante mucho tiempo, no había una alternativa mejor.
Esto cambió con la llegada de OData y, más tarde, de las API REST construidas sobre OData v4. Microsoft ha sido claro en su documentación de desarrollador: OData V4 sustituye a SOAP, y recomienda migrar las integraciones antiguas cuanto antes. Las Access Keys (autenticación Basic Auth) para servicios web ya se retiraron en octubre de 2022, empujando todo el ecosistema hacia OAuth2. La retirada de SOAP que ahora llega con la versión 29 no es una sorpresa ni un giro de política: es la siguiente ficha de un dominó que lleva cayendo una década.
Lo que sí es nuevo es la concreción. Por primera vez, Microsoft ha puesto una versión y una fecha exactas al cambio.
Qué desaparece en la versión 29 (octubre de 2026)
A partir de la versión 26 (2025 release wave 1), Microsoft ya deshabilitó por defecto la posibilidad de exponer una página estándar como SOAP, aunque dejó una puerta trasera: la feature key "Disable SOAP web services on Microsoft UI pages", que permite reactivar esa capacidad mientras se completa la migración.
Con la versión 29, que llega en octubre de 2026 dentro de la 2026 release wave 2, esa puerta se cierra del todo:
- Deja de ser posible publicar cualquier página de UI de Microsoft (Base Application, System Application, o cualquier app first-party) como endpoint SOAP.
- La propia feature key que hoy permite reactivar SOAP desaparece junto con la capacidad. No quedará ningún interruptor en Feature Management para volver atrás.
Si necesitas mantener esa integración por SOAP, la recomendación oficial de Microsoft es copiar el código fuente de la página y alojarlo en tu propia extensión (per-tenant extension), publicando esa copia como endpoint SOAP.
El siguiente paso: la versión 30 y OData
Este dato suele pasar desapercibido, y sin embargo está en el mismo documento oficial de deprecaciones: a partir de la versión 30 (2027 release wave 1), tampoco será posible exponer una página de Microsoft como endpoint OData. La misma lógica que hoy afecta a SOAP se aplicará a OData un año después, sobre las mismas páginas estándar.
Dos matices importantes:
- Esto afecta únicamente a páginas publicadas por el editor "Microsoft" (Base App, System App, apps first-party), no a tus propias páginas de extensión.
- Las API pages y API queries no se ven afectadas por ninguno de los dos cambios. Es, precisamente, la razón de ser de esta distinción.
La razón detrás de la decisión
El propio documento de Microsoft explica el porqué con un argumento sencillo: una página de interfaz de usuario no es una API. Los cambios que Microsoft introduce en una página estándar de un release a otro un campo nuevo, una acción reordenada, no se consideran cambios disruptivos ("breaking changes") desde el punto de vista de la UI. Pero si esa misma página es también tu endpoint de integración, ese cambio de interfaz sí rompe tu conexión, aunque nadie haya incumplido ninguna promesa técnica.
La solución estructural de Microsoft es separar de una vez por todas "lo que se ve" (las páginas de UI) de "lo que se integra" (las API pages y API queries), diseñadas específicamente para mantenerse estables de versión en versión.
El matiz que casi nadie explica bien
Aquí es donde muchos artículos y publicaciones sobre este tema se quedan cortos, y donde conviene ser preciso para no generar ni pánico innecesario ni falsa tranquilidad.
Lo que tiene fecha confirmada: exponer una página estándar de Microsoft como SOAP. Eso desaparece en la v29, en octubre de 2026, sin excepciones ni prórrogas.
Lo que todavía no tiene fecha: SOAP sobre codeunits y SOAP sobre páginas de tus propias extensiones (PTE) son una categoría distinta. La documentación de Microsoft indica que ese soporte se retirará "en un release futuro", sin comprometer todavía una versión concreta. De hecho, esta es la vía de escape que el propio Microsoft recomienda para quien necesite conservar una integración SOAP más allá de octubre de 2026: replicar la página estándar dentro de una extensión propia y publicar esa copia.
Tratar ambas situaciones como si fueran lo mismo es el error más habitual: lleva a preocuparse por integraciones que van a seguir funcionando, o a confiarse con integraciones que sí van a romperse.
Dónde suele esconderse el riesgo real
Este tipo de deprecación rara vez preocupa hasta que causa un problema real, porque las integraciones SOAP llevan funcionando en silencio durante años. Los escenarios donde más aparecen son:
- Conciliación bancaria : feeds con el banco montados hace tiempo sobre páginas SOAP estándar.
- Proveedores EDI : el intercambio de pedidos con un cliente retail; un fallo aquí puede derivar en penalizaciones económicas (chargebacks).
- Escáneres de almacén : hardware de logística ya antiguo, conectado directamente por SOAP.
- Reporting y Power BI : datasets construidos sobre un endpoint SOAP que nadie ha vuelto a tocar desde que se creó.
- Aplicaciones .NET a medida : desarrolladas por una consultora o un empleado que ya no está en la empresa.
- Add-ons de terceros : soluciones ISV o flujos de Power Automate que siguen apoyándose en SOAP por debajo, aunque el proveedor asegure que "ya usan API".
Cómo saber si te afecta, sin adivinar
La buena noticia es que no hace falta preguntar departamento por departamento ni confiar en la memoria de nadie. Business Central registra cada llamada a un servicio web en la telemetría de partner, incluyendo el tipo de endpoint (SOAP, OData o API) : el problema es que casi ninguna organización consulta activamente esos datos.
Con una consulta KQL sobre Application Insights, filtrando por el identificador de evento de las llamadas SOAP, se puede obtener una lista concreta y verificable de qué entornos, páginas y codeunits siguen recibiendo tráfico SOAP en producción ahora mismo. Es un ejercicio de datos, no de desarrollo, y debería tener prioridad alta independientemente de en qué versión te encuentres hoy.
Las tres rutas de migración
Para cualquier integración SOAP construida sobre una página estándar de Microsoft, Microsoft plantea tres caminos:
- API pages / API queries (recomendada). Diseñadas específicamente para integración: contrato de datos estable, sin lógica de interfaz de por medio, versionado propio (v2.0, beta…). Es la opción que Microsoft empuja para todo desarrollo nuevo.
- OData V4 (alternativa). Sigue soportado sobre páginas estándar, hasta que a esa página le llegue el turno en la versión 30 y puede servir como paso intermedio si necesitas migrar rápido sin rediseñar la integración desde cero.
- Replicar la página en una extensión propia (si de verdad necesitas SOAP). Copiar el código fuente de la página estándar, alojarla en una per-tenant extension y publicar esa copia como endpoint SOAP. Sigue siendo un camino soportado, sin fecha de caducidad anunciada todavía.
Un plan de acción realista
En los próximos 30 días: extraer de la telemetría qué llamadas SOAP existen realmente en tus entornos, clasificadas por página o codeunit. Es trabajo de auditoría de datos, no de desarrollo, y conviene hacerlo cuanto antes, estés en la versión que estés.
Antes de octubre de 2026: migrar primero lo crítico, feeds bancarios, EDI, cualquier dato que llegue al cliente final, hacia API pages u OData V4. Si hay una razón de peso para mantener SOAP, replicar la página en una extensión propia.
Después del cambio: aprovechar la migración como excusa para consolidar. No es raro descubrir, al auditar, tres o cuatro integraciones distintas haciendo prácticamente lo mismo, construidas por proveedores diferentes en momentos distintos. Es también un buen momento para valorar si las nuevas capacidades nativas de automatización e IA de Business Central ya cubren una necesidad que antes exigía una integración a medida.
Lo esencial, en cuatro frases
- La versión 29 (octubre de 2026) elimina para siempre la posibilidad de publicar páginas de Microsoft como SOAP, junto con la feature key que hoy permite reactivarlo.
- La versión 30 (2027) hace lo mismo con OData sobre esas mismas páginas; las API pages no se ven afectadas por ninguno de los dos cambios.
- SOAP sobre codeunits y sobre páginas de tu propia extensión sigue sin fecha de retirada confirmada: es una categoría distinta.
- La telemetría de Application Insights, no la memoria del equipo, es la forma fiable de saber qué te afecta de verdad.
Fuentes
- Microsoft Learn - Deprecated features in the platform: Clients, Server, and Database
- Microsoft Learn - SOAP Web Services y Disable SOAP web services on Microsoft UI pages feature key
Puedes ver el video aquí:
No hay comentarios:
Publicar un comentario