Su integración con Business Central no era una API

El lunes

El e-commerce deja de crear pedidos en Business Central. No hubo deploy, nadie tocó el conector, la base de datos responde y el usuario del servicio sigue activo. Lo único que cambió fue una actualización que corrió un viernes por la noche.

El equipo revisa la cola de mensajes, las credenciales, el certificado, la URL. Todo parece bien. El error es escueto y no dice lo que realmente pasó: la función que permitía publicar una pantalla del sistema como servicio web ya no está, porque Microsoft la retiró. El conector sigue llamando a una dirección que ahora responde que no existe.

Y aquí viene la parte que convierte un incidente en un problema de calendario: la corrección que todo el mundo intenta primero, mover el mismo servicio al formato nuevo sobre la misma pantalla, también tiene fecha de cierre.

Qué cambia, exactamente

Microsoft documenta dos retiros, en dos ciclos distintos, y conviene entender qué son esos dos formatos antes de seguirlos.

SOAP es el formato antiguo con el que dos sistemas se hablaban por internet. OData es el que lo reemplazó: hace lo mismo, con reglas más simples y mejor soporte. Business Central permitía publicar cualquier pantalla como servicio web en cualquiera de los dos, sin escribir una línea de código. De ahí viene todo el problema.

En la versión 29, que ya está disponible, ya no se puede publicar una pantalla de Microsoft como servicio SOAP. El cambio entró con el ciclo de octubre de 2026, pero no es un apagón global: el bloqueo se aplica cuando cada ambiente se actualiza a esa versión. La ventana para elegir esa fecha llega hasta febrero de 2027, marzo funciona como periodo de gracia y desde abril de 2027 la actualización se aplica de forma forzada.

En la versión 30, prevista para el primer ciclo de 2027, Microsoft registra la eliminación de la misma posibilidad, pero para OData.

Qué se retira	Cuándo	Sobre qué
Publicar una pantalla de Microsoft como servicio SOAP	En la versión 29, al actualizar cada ambiente	Ventana hasta febrero de 2027, gracia en marzo, forzado desde abril
Publicar una pantalla de Microsoft como servicio OData	En la versión 30, primer ciclo de 2027	La misma pantalla estándar
La llave de Feature Management que lo reactivaba	Ya no sirve desde la 29	Deja de ser una salida

Una precisión que evita un error común: no existe una fecha calendario única de apagado de SOAP. Depende de cuándo se actualice cada ambiente. Quien le diga "el 31 de marzo se apaga SOAP" está simplificando algo que tiene una fecha distinta por cliente. Y sobre la versión 30, la fuente de Microsoft la registra como versión del ciclo de 2027, no con un mes fijado; hablar de abril es razonable por el ritmo habitual de dos versiones por año, pero no es un dato que la documentación primaria fije.

El patrón que lo hace peligroso: la pantalla como contrato

Microsoft explica el retiro con una frase corta y muy buena: una página de interfaz de usuario no es una API, así que sus cambios pueden ocurrir en una versión sin ser considerados un cambio incompatible. Traducido: una pantalla está hecha para que la use una persona, no para que la llame un programa, y por eso el proveedor se reserva el derecho de moverla cuando quiera.

Leída desde el lado del proveedor, la frase es razonable: mantiene libertad para rediseñar pantallas. Leída desde el lado del cliente, significa lo contrario y conviene decirlo sin adornos: su integración depende de un objeto que el proveedor declara por escrito que puede mover sin avisar.

Durante años eso no fue un problema, porque funcionaba. Un servicio web publicado sobre una pantalla estándar respondía, devolvía datos y no había que pedirle permiso a nadie. Era el atajo que resolvía la semana. El atajo cumplió, y ese fue precisamente el problema: funcionó tanto que dejó de verse, porque nada se rompía.

La idea que un Director de TI puede llevar a su comité, en una línea: si su integración lee o escribe en una pantalla, no tiene un contrato. Tiene una coincidencia.

Qué sobrevive y qué no

Antes de planificar cualquier migración, conviene saber si uno está expuesto. La distinción es más simple de lo que parece, y depende de una sola cosa: quién firma la aplicación donde vive esa pantalla.

Lo que no se cae por este cambio: SOAP sobre bloques de código propio, que en Business Central se llaman codeunits, y SOAP sobre páginas de extensiones propias o de terceros. Si su integración entra por ahí, el retiro no la toca.

Lo que sí se cae: cualquier servicio SOAP que apunte a una pantalla cuya aplicación esté firmada por Microsoft, es decir la aplicación base, la aplicación del sistema y las apps de primera línea. Y en el ciclo siguiente, lo mismo pero por la vía de OData.

La ruta que Microsoft documenta como soportada es copiar el código de la pantalla a una extensión propia y publicar esa extensión. La otra es moverse a las páginas de API y a la interfaz REST v2.0, la vía oficial que Microsoft mantiene: REST es el formato con el que un programa le pide datos a otro.

Y el consejo que hay que decir en voz alta porque es contraintuitivo: no "arregle" una integración SOAP moviéndola a OData sobre la misma pantalla de Microsoft. Eso solo compra un ciclo. La puerta que está usando se cierra doce meses después, y el equipo habrá gastado el presupuesto de este año para tener el mismo problema el año que viene con otro nombre.

Por qué el inventario no está en el diagrama

En una empresa mediana, la integración con el ERP rara vez aparece como "el ERP" en el mapa de arquitectura. Aparece como nada. Son cosas dispersas: el conector del e-commerce, la tarea programada que exporta facturas, el job de nómina, el script que sincroniza stock, la capa que alguien armó en medio para no volver a tocarlo.

Por eso la pregunta útil no es "¿usamos SOAP?" sino estas cuatro.

Qué programas llaman a los servicios web de Business Central. No qué usuarios entran al ERP. Qué procesos automáticos le hablan.

Cuáles apuntan a pantallas estándar y no a páginas de API. Esta es la que separa lo expuesto de lo que no.

Cuál de esos programas tiene dueño con nombre. No un área. Una persona.

Quién decide la fecha de actualización de cada ambiente. Esta última suele ser la que nadie puede contestar, y es la más importante: porque el cambio tiene fecha por ambiente, y esa fecha la elige la empresa, no Microsoft. Un cliente que no sabe quién decide cuándo actualizar tampoco sabe cuándo se va a romper su integración, y va a descubrirlo un lunes.

El mismo patrón aparece en cualquier ERP con conectores expuestos: una pantalla pensada para personas empieza a usarse como puerta para programas, y nadie lo documenta porque al principio funcionaba.

Los próximos dos trimestres

Cuatro cosas, en orden, antes de que febrero deje de estar lejos.

Inventario de programas y direcciones de servicio. Qué procesos llaman a Business Central, a qué pantalla apuntan y quién responde por cada uno.

Revisión de qué se puede mover a extensión propia. No todo necesita una extensión nueva; parte del trabajo es distinguir qué integración merece una interfaz de verdad y cuál se puede reemplazar por una ruta más simple.

Un plan de actualización por ambiente, con fecha elegida y no impuesta. Escribir quién decide, cuándo y en qué orden. Si la fecha llega por actualización forzada, el proyecto deja de ser planificado y pasa a ser una emergencia.

Un runbook para producción. Qué se hace si esto falla un lunes: quién mira el log, cómo se identifica el programa afectado y cuál es el cambio mínimo que lo devuelve a funcionar.

Para el contexto de por qué esto cuesta lo que cuesta, hay dos artículos hermanos: por qué las integraciones con el ERP nunca se cotizan bien y el costo de sostener conexiones sin dueño. Y el mismo patrón de fecha de proveedor, en otro ERP, está en la fecha de 2027 en SAP.

Si su equipo no sabe hoy qué programas llaman a los servicios web de Business Central, ni quién decide la fecha de actualización de cada ambiente, ese inventario se puede levantar antes de febrero. En Byxel mapeamos integraciones, consumidores y dueños de cada flujo, y rediseñamos lo que depende de una pantalla para que no vuelva a depender. Escríbanos por WhatsApp y lo revisamos con su equipo técnico.