IBM Sterling B2B Integrator es una de esas plataformas que mueven billones de dólares en transacciones anuales y que casi nadie fuera de ciertos sectores conoce. Banca, finanzas, retail, supply chain — en todos estos dominios, Sterling es la pieza que conecta partners, procesa archivos EDI, orquesta transferencias y garantiza que los datos lleguen donde tienen que llegar.
Llevo años operándolo en entornos bancarios de producción. Lo que sigue no es la documentación oficial de IBM — es lo que aprendí manteniendo la plataforma funcionando cuando las cosas no salen como esperas.
Qué es Sterling y por qué importa
Sterling B2B Integrator es una plataforma de integración empresarial diseñada para comunicaciones B2B. Su función principal es recibir, transformar, enrutar y entregar datos entre organizaciones. Soporta protocolos como AS2, SFTP, FTPS, HTTP/S, MQ y conectores específicos para estándares EDI (X12, EDIFACT).
En el sector financiero, Sterling procesa archivos de pagos, conciliaciones, reportes regulatorios y comunicaciones interbancarias. Si Sterling se cae, las transacciones se detienen. No es una aplicación más — es infraestructura crítica.
Arquitectura interna: las piezas que importan
Sterling se compone de tres capas fundamentales que todo operador debe entender:
- Adapters: son los conectores con el mundo exterior. Cada protocolo tiene su adapter: SFTP Adapter, HTTP Adapter, MQ Adapter, File System Adapter. Los adapters escuchan conexiones entrantes o inician conexiones salientes. Cuando un adapter falla, ese canal de comunicación se interrumpe. Monitorear el estado de los adapters es lo primero que haces cada mañana.
- Business Processes (BPs): son los workflows que orquestan el flujo de datos. Un BP define los pasos: recibir archivo, validar formato, transformar, enrutar, entregar, notificar. Se diseñan en el Business Process Modeler y se ejecutan en el engine de workflows. Un BP atascado es el problema más común y el más frustrante de diagnosticar.
- Base de datos: el centro nervioso — y el punto débil. Sterling almacena todo en la base de datos: configuración, estado de los BPs, documentos en tránsito, logs, metadatos de partners. Una base de datos lenta convierte a Sterling en un sistema lento. Una base de datos bloqueada lo convierte en un sistema muerto.
Por encima de todo esto, Sterling File Gateway (SFG) actúa como capa de routing simplificado. SFG abstrae la complejidad de los BPs para el caso de uso más común: mover archivos entre partners. Defines reglas basadas en partner, protocolo, formato y destino, y SFG se encarga del resto. Para los equipos de operaciones que no diseñan BPs a medida, SFG es la interfaz principal con la plataforma.
Operación en producción: lo que la documentación no te dice
Operar Sterling en producción es un ejercicio de vigilancia constante. Estas son las áreas que requieren atención diaria:
- Monitoreo de BPs: la consola de Sterling muestra el estado de los business processes: Success, Error, Waiting, Interrupted. Los BPs en estado "Waiting" durante más de lo esperado son señal de problemas. Configura alertas para BPs que excedan su tiempo normal de ejecución. No esperes a que alguien te diga que un archivo no llegó.
-
Logs: Sterling genera logs en múltiples ubicaciones. Los más útiles son los logs de
business processes (accesibles desde la consola), los logs del sistema (
noapp.log,system.log) y los logs de adapters. Cuando algo falla, correlaciona los tres. El error en el BP te dice qué falló; el log del sistema te dice por qué. - JVM tuning: Sterling corre sobre la JVM, y su rendimiento depende directamente de la configuración de memoria. Un heap demasiado pequeño provoca Full GCs frecuentes. Un heap demasiado grande alarga las pausas de GC. El sweet spot depende del volumen de transacciones, pero en entornos bancarios he trabajado con heaps de 8-16 GB y G1GC como collector.
- Connection pools: Sterling mantiene pools de conexiones a la base de datos y a servicios externos. Un pool agotado bloquea todo. Monitorea el uso de los pools y ajusta el tamaño según la demanda real, no según la documentación genérica de IBM.
- Purge schedules: Sterling acumula datos en la base de datos: documentos procesados, logs de BPs, metadatos de transacciones. Sin purga periódica, la base de datos crece hasta degradar el rendimiento. Configura schedules de purga agresivos para datos que ya no necesitas. He visto bases de datos de 500 GB que deberían ser de 50 GB.
Troubleshooting real: los problemas que vas a enfrentar
Después de años operando Sterling, estos son los problemas recurrentes y cómo abordarlos:
- BP estancado en "Waiting": el escenario más frecuente. Un business process queda en estado Waiting y no avanza. Primero, revisa en qué paso del workflow se detuvo. Luego, verifica si el adapter que necesita está activo y funcional. Si el adapter está bien, revisa si hay un lock en la base de datos bloqueando la transacción. En última instancia, un thread dump del proceso Java te mostrará si hay contención de hilos.
- File Gateway routing failures: SFG no enruta un archivo. Revisa la configuración del routing channel: partner correcto, protocolo correcto, patrón de nombre de archivo coincidente. Los errores de routing suelen ser errores de configuración, no errores de la plataforma. Revisa los logs de SFG para ver qué regla evaluó y por qué descartó el archivo.
- Database contention: Sterling hace un uso intensivo de la base de datos. Lock waits prolongados degradan todo. Identifica las queries más lentas, verifica que los índices estén actualizados, y asegúrate de que las purgas estén corriendo. En Oracle, revisa los wait events. En DB2, los lock escalations. La base de datos es siempre el primer sospechoso.
- Thread pool exhaustion: Sterling tiene pools de threads para procesar BPs, adapters y operaciones internas. Si todos los threads están ocupados, las nuevas operaciones quedan encoladas indefinidamente. Captura un thread dump para ver qué están haciendo los threads. Si están todos esperando respuesta de la base de datos, el problema no es el pool — es la base de datos.
Alta disponibilidad: cómo no depender de una sola instancia
Sterling soporta configuraciones active-active con balanceo de carga. La arquitectura típica incluye:
- Dos o más nodos Sterling detrás de un load balancer para distribuir las conexiones entrantes.
- Almacenamiento compartido (NFS, GPFS, o storage empresarial) para que todos los nodos accedan a los mismos archivos.
- Base de datos en cluster (Oracle RAC, DB2 HADR) como capa de persistencia compartida.
- Afinidad de sesión configurada en el balanceador para que los BPs de larga duración no salten entre nodos.
El punto crítico en HA es la base de datos. Si la base de datos falla, ambos nodos de Sterling fallan. No importa cuántos nodos de aplicación tengas — si comparten una base de datos sin redundancia, no tienes alta disponibilidad real. El failover de base de datos debe estar probado, automatizado y ensayado periódicamente.
Sterling es tan robusto como la atención que le dediques en producción. No es un sistema que configuras una vez y olvidas. Es infraestructura crítica que demanda monitoreo constante, purgas disciplinadas y un equipo que entienda su arquitectura interna.
