¿Quieres enviar a firmar contratos y documentos de RRHH sin tener que salir de SAP?

En GROUPmee hemos creado un Conector que integra Signaturit en tu ERP SAP para acelerar los procesos de firma de documentos y contratos con una solución legal.

Hemos optimizado todo el proceso, para que el envío de documentos y contratos a empleados, se haga de forma automática y con un solo click.

Sergio siempre decía que lo que más le gustaba de trabajar con integraciones era que, cuando todo funcionaba bien, nadie se acordaba de él. No había llamadas, no había urgencias, no había correos con asunto en mayúsculas. Solo silencio. Y durante mucho tiempo, ese silencio había sido su mejor indicador de que todo estaba en orden.

Aquella mañana empezó como cualquier otra, con el café todavía caliente al lado del teclado y una rápida revisión de los iFlows en CPI antes de abrir el resto de tareas del día. Todo en verde. Todo en “Completed”. Todo tranquilo. Demasiado tranquilo, pensó sin darle demasiada importancia, mientras cerraba la pantalla y pasaba a otra cosa, sin saber que ese mismo silencio llevaba días escondiendo algo que ya había empezado a fallar… y que nadie, ni siquiera él, había sido capaz de ver.

En aquella empresa, SAP era el punto de partida de todo, pero hacía tiempo que había dejado de ser el final. Los pedidos nacían en el sistema, sí, pero su destino estaba fuera, en otros sistemas, en otras plataformas, en procesos que nadie veía directamente. Entre medias, silenciosa, invisible, estaba la integración. SAP Integration Suite, CPI para los de dentro. Una capa que nadie del negocio miraba, que pocos entendían realmente, pero de la que dependía absolutamente todo.

Sergio llevaba meses siendo el responsable técnico de ese mundo que no hacía ruido. Le gustaba así. Le gustaba que todo fluyera sin interrupciones, sin alarmas, sin sobresaltos. Cuando CPI funcionaba bien, nadie lo notaba y eso, para él, era una señal de que todo estaba en orden.

El flujo que habían desarrollado conectaba SAP con un sistema externo de logística. Un pedido se creaba, se generaba un IDoc, CPI lo recogía, lo transformaba y lo enviaba a través de una API. A partir de ahí, el proceso seguía fuera. Si ese mensaje no llegaba… el pedido no existía para nadie más.

Durante semanas, todo funcionó con una precisión casi perfecta. Sergio revisaba los mensajes en CPI y veía líneas verdes, estados “Completed”, ejecuciones limpias. No había errores visibles, no había interrupciones, no había nada que indicara que algo pudiera estar fallando. Y poco a poco, sin darse cuenta, dejó de mirar en profundidad. Porque cuando todo parece estable… uno deja de buscar problemas.

Habían implementado una gestión de excepciones en el iFlow. Algo sencillo, algo práctico. Si la llamada al sistema externo fallaba, el flujo no se rompía, simplemente capturaba el error, lo procesaba internamente y terminaba. No había reintentos, no había alertas, no había nada que sacara ese error fuera del propio flujo. En aquel momento, aquello parecía suficiente.

Lo que nadie cuestionó fue lo que ocurría después de esa excepción.

Porque cuando el flujo entraba en ese bloque, devolvía un HTTP 200.

No un error.

No una señal de fallo.

Un 200.

Como si todo hubiese ido bien.

Y con ese 200… el mensaje pasaba a estado “Completed”.

Una mañana cualquiera, sin nada especial en el ambiente, se creó un pedido más. Uno normal, sin urgencia, sin peculiaridades. SAP hizo su parte, generó el IDoc, lo envió a CPI y el flujo comenzó su recorrido habitual. Todo avanzó como siempre… hasta que la llamada al sistema externo devolvió un error.

El iFlow lo capturó, entró en la excepción, procesó el fallo y devolvió un 200 antes de terminar como si nada hubiese pasado.

El mensaje quedó marcado como completado.

Y el pedido… simplemente no llegó.

Nadie vio nada.

Nadie sospechó nada.

Porque no había nada que ver.

por que sucedio esto? por un fallo en la parametrizacion de la excepcion:

Y lo más inquietante de todo… es que no era un fallo evidente.

El sistema sí había hecho algo.

Había capturado el error.

Lo había procesado.

Y lo había convertido en algo que parecía correcto.

Como si alguien, sin darse cuenta, hubiese enseñado al flujo a fallar… sin que pareciera un fallo.

Pasaron los días. El sistema seguía funcionando. Los pedidos seguían entrando. CPI seguía mostrando estados en verde. Todo parecía correcto. Todo parecía estable. Y ese fue el verdadero problema.

Hasta que, varios días después, alguien en negocio preguntó por un pedido que no había salido. No era una alarma. No era una queja. Era una simple duda.

Sergio lo revisó en SAP. El pedido estaba perfecto. Sin errores. Sin bloqueos. Todo en orden.

Buscó en el sistema de logística.

No estaba.

Ese fue el momento en el que algo empezó a incomodar.

Volvió a CPI. Buscó el mensaje. Lo encontró enseguida.

Estado: Completed.

Demasiado fácil.

Entró en el detalle. Empezó a leer cada paso, cada log, cada línea. Y ahí, en medio del flujo, encontró ese bloque que durante semanas había pasado desapercibido. La excepción. El error capturado. El 200.

Un fallo… disfrazado de éxito.

Sergio no se quedó ahí. Siguió buscando. Revisó otros mensajes. Y encontró más. Pocos. Pero suficientes.

Lo realmente complicado no era detectar que algo fallaba… era encontrar qué pedidos habían desaparecido sin dejar rastro.

Pedidos que no habían llegado. Mensajes que habían fallado. Procesos que el sistema daba por correctos… cuando no lo eran.

El silencio empezó a hacerse incómodo.

No era un error que explotara. No era algo evidente. Era algo que había estado ocurriendo sin que nadie lo viera. Y eso era lo que realmente inquietaba.

Tuvieron que sentarse con los funcionales. Revisar pedidos uno a uno. Analizar materiales, fechas, estados. Reconstruir lo que había pasado sin que nadie lo hubiera detectado en su momento. No era una revisión técnica, era casi una investigación.

Los pedidos se reenviaron. Se corrigieron manualmente. Se ajustaron procesos.

Pero el problema ya no era solo ese.

El proyecto estaba cerrado.

Y ahora… había que reabrirlo.

Los responsables tuvieron que justificar una ampliación. Explicar por qué un desarrollo que funcionaba aparentemente bien necesitaba más tiempo, más inversión, más cambios. Implementaron reintentos. Añadieron alertas. Crearon monitorización real. Cambiaron la lógica de las excepciones para que un error volviera a ser un error.

Para que un fallo… no volviera a parecer un éxito.

Sergio volvió muchas veces a ese punto concreto del flujo, a esa excepción, a ese 200.

Y fue entonces cuando lo entendió de verdad.

El sistema no había fallado de forma evidente.

No había roto nada.

No había avisado a nadie.

Había fallado… en silencio.

MORALEJA:

En integración, un error que devuelve un 200 es mucho más peligroso que uno que falla con un 500, porque el primero no se ve, no se revisa y no se cuestiona… y cuando nadie mira, el SAPOCALYPSIS no empieza con un fallo, empieza con un silencio.