SAP Business One: cuando el Integration Service se detiene constantemente

El SAP Business One Integration Service es la base de los paneles, el reenvío de eventos y una gran parte de todas las conexiones con Business One. Cuando falla, rara vez se produce un fallo estrepitoso. La mayoría de las veces simplemente deja de ocurrir algo, y esto solo se nota cuando faltan cifras. El siguiente procedimiento de diagnóstico se basa en la documentación de SAP y en patrones de error documentados de la SAP Community, no en un caso de cliente.

¿Qué servicios hay detrás del Integration Service?

El Integration Service no es un único servicio, sino una cadena de servicios de Windows interdependientes: el Integration Service basado en Tomcat, el Event Sender, el System Landscape Directory y al menos dos servicios relacionados con el DIProxy. Quien solo se fija en el servicio con el nombre correspondiente busca el fallo en el lugar equivocado.

El documento de SAP DIProxy Configuration (Integration Framework for SAP Business One, SAP Global Roll-out, octubre de 2018, autor Bo Zhao) separa claramente los dos servicios DIProxy. El DI Proxy Service es «the main service which is listening on port 2099 by default for the DI-API calls». Junto a él está el DI Proxy Service Monitor, según SAP «the daemon service used to restart the DI Proxy automatically when the process stopped unexpectedly». Esta segunda línea es la frase más importante del documento: SAP incluye un vigilante porque se anticipan bloqueos inesperados.

Que esta infraestructura forma parte del sistema lo afirma la propia SAP: «The integration framework for SAP Business One is a Web browser-based solution to design integration flows for exchanging data between different systems», escribe Miriam Rieger, Product and Topic Expert del equipo Global Roll-out de SAP, en el blog central de B1if de la SAP Community (14 de agosto de 2018, actualizado en mayo de 2020, alrededor de 96.100 visitas).

¿Por qué el servicio se detiene repetidamente y no solo una vez?

En Business One, las detenciones repetidas suelen no ser un fallo, sino un reinicio configurado. El DIProxy incorpora parámetros que lo reinician de forma programada para limitar posibles fugas de memoria. Quien no lo sabe busca durante días un error que no existe.

• MAXDIERRORS: 50 de forma predeterminada en instalaciones on-premise, 200 en instalaciones en la nube. Según SAP, el valor indica «the count of DI-errors that may happen until the DIProxy will be restarted for the sake of potential memory leaking».
• RESTARTPERIOD: 60 de forma predeterminada en on-premise y 0 en la nube. El valor es el tiempo en minutos hasta el próximo reinicio programado, por el mismo motivo.
• MAXACCESES: 0 de forma predeterminada, es decir, ilimitado. SAP advierte que apagar el DIProxy puede tardar «a very long time» cuando hay muchísimos accesos simultáneos. Esto es exactamente lo que el administrador percibe como un servicio bloqueado en «deteniéndose».

Para el diagnóstico, lo que cuenta es la frecuencia, no la detención en sí. Desaparecer brevemente cada hora se ajusta a lo esperado con los valores predeterminados on-premise. Desaparecer cada pocos minutos, en cambio, no.

Este patrón de error lleva años documentado. Un usuario lo describió brevemente en 2017: «sap business one integration service is stopping […] it repeats once in a while». Un hilo de 2011 relata que, al reiniciar, «the service returns an error and status is ‘stopping’ or ‘starting’» y que la única salida fiable es reiniciar el servidor. Ambas publicaciones siguen hoy sin respuesta publicada (comprobado el 3 de agosto de 2026).

¿En qué orden debe diagnosticar el fallo?

El orden determina si encuentra la causa o simplemente aparta el síntoma. El reinicio debe ir al final, porque destruye las pruebas.

• Primero, la cadena de servicios. Compruebe individualmente el Integration Service, el Event Sender y ambos servicios DIProxy. Un servicio principal que se reinicia cíclicamente mientras el servicio de supervisión sigue en marcha es una situación distinta a la de un servicio que ya no vuelve a arrancar.
• Subir el nivel de registro de forma selectiva. Controlado mediante DIProxylog.properties en el directorio del DIProxy, con los registros en la subcarpeta log. De forma predeterminada: nivel SEVERE, 10.485.760 bytes por archivo y tres archivos. Para la resolución de problemas, SAP recomienda «.level=FINER» con «java.util.logging.FileHandler.count = 10». Con los ajustes predeterminados, la causa lleva mucho tiempo sobrescrita al cabo de unos días.
• Unificar el direccionamiento. El desencadenante citado con más frecuencia en la comunidad para «cannot connect to SAP Business One integration service» es el direccionamiento mixto. Una respuesta en el hilo correspondiente lo resume así: «Can you Check if you use the same hostname or ip address in SLD landscape directory and in integration service or event sender?» O bien el nombre de host en todas partes, o bien la dirección IP en todas partes.
• Verificar los puertos. El DIProxy escucha por defecto en el puerto 2099. Si está en un servidor propio, ese puerto debe estar abierto. Varias instancias necesitan cada una su propio puerto en diproxyserver.properties.
• Reiniciar solo al final. Tras un cambio de perfil del sistema, el framework exige de todos modos un reinicio del Integration Service.

¿Qué debe incluir la supervisión para detectar el fallo antes que el usuario?

La supervisión es escasa de fábrica, por lo que los fallos pasan desapercibidos durante mucho tiempo. Según Log Maintenance in Integration Framework (SAP Global Roll-Out, enero de 2019, autora Nidhi Singh), el registro de mensajes no está activo por defecto en el perfil «Productive System». SAP recomienda como máximo el nivel más bajo, «Infoset», para sistemas productivos.

El valor predeterminado con las consecuencias más importantes se encuentra en el manejo de errores: para las transacciones asíncronas, ambos perfiles aplican «Retrial after 1 minute and stop processing of following messages». Un único mensaje erróneo detiene así toda la cola. El servicio sigue funcionando, pero la integración se detiene. Este es el estado en el que la supervisión de servicios indica verde y, sin embargo, no llegan datos.

• Supervisar la cola en lugar del estado del servicio. El Queue Monitor está disponible por defecto. Una cola que no se vacía es la señal honesta más temprana.
• Registros detallados solo de forma temporal. SAP lo expresa sin ambigüedad: «We do not recommend enabling detailed logging for an extended period, because it generates large log files for each transaction.» Activar, reproducir el error, exportar, desactivar.
• Evaluar el tamaño de la base de datos. SAP proporciona una consulta de conteo sobre BZSTIDXH y BZSTIDXP en el esquema IFSERV. Si predomina el tipo de registro com.sap.b1i.system.xc.iodata, esto apunta a transacciones que se repiten constantemente, es decir, a la cola bloqueada.

¿Qué significa esto para los workflows de n8n, Power Automate y RPA?

Un workflow de automatización no debe depender de que el Integration Service esté funcionando. Tres precauciones cuestan poco de implementar si se planifican desde el principio.

• Reportar errores en lugar de ignorarlos. Una rama que envía un mensaje a una persona en caso de error vale más que una entrada de registro que nadie lee. En NordFlux integramos exactamente esta rama en cada conexión con Business One, junto con una llamada de prueba periódica contra la interfaz.
• Reintentar con tiempo de espera. Un único intento falla en cada reinicio de un minuto; un número limitado de reintentos con una pausa lo salva.
• Construir de forma idempotente. Si una ejecución se interrumpe a mitad del procesamiento y se reinicia más tarde, no debe crearse un segundo documento. Para ello se necesita una clave de negocio para la conciliación.

Qué vía de acceso es la correcta se explica en Conectar SAP Business One: comparativa de Service Layer, OData y middleware RFC. La cuestión de licencias y herramientas correspondiente se trata en RPA o SAP Process Automation. Encontrará el marco para la operativa en nuestra página sobre consultoría de SAP Business One.

Preguntas frecuentes

¿Por qué el SAP Business One Integration Service se detiene una y otra vez?

Las detenciones repetidas suelen estar configuradas y no ser un defecto. Según SAP, el DIProxy se reinicia tras un tiempo determinado (RESTARTPERIOD, 60 minutos por defecto en on-premise) o tras un número determinado de errores DI (MAXDIERRORS, 50 por defecto en on-premise y 200 en la nube). Compruebe primero la frecuencia de las detenciones frente a estos dos valores.

¿Se reinicia el DIProxy automáticamente tras un bloqueo?

Sí, siempre que el segundo servicio esté en marcha. Para ello, SAP instala el DI Proxy Service Monitor, que según la documentación es «the daemon service used to restart the DI Proxy automatically when the process stopped unexpectedly». Si este servicio no está en marcha, un DIProxy bloqueado permanece caído de forma permanente.

¿Dónde encuentro los archivos de registro del DIProxy?

En la subcarpeta log del directorio del DIProxy, controlado mediante DIProxylog.properties. De forma predeterminada: nivel SEVERE, 10.485.760 bytes por archivo y tres archivos. Para la resolución de problemas, SAP recomienda el nivel FINER con diez archivos y volver a restablecerlo después.

El servicio está en marcha, pero no llegan datos. ¿A qué se debe?

Normalmente, a la cola bloqueada. Para las transacciones asíncronas, el ajuste predeterminado es «Retrial after 1 minute and stop processing of following messages»; un único mensaje erróneo bloquea todos los siguientes. Consulte el Queue Monitor y la sección de errores del registro de mensajes, no la ventana de servicios.