Ir a las preguntas frecuentes
Transferencia de ficheros · MFT

Qué es IBM Connect:Direct y por qué sigue moviendo los ficheros de la bancaEn qué se diferencia de SFTP, cómo funcionan sus Process y el reinicio desde el punto de fallo, y cuándo tiene sentido hoy.

Hay software que conoce todo el mundo y software que lleva décadas sosteniendo el proceso nocturno de un banco sin que nadie fuera del departamento lo haya oído nombrar. IBM Connect:Direct es de los segundos.

Mueve ficheros entre sistemas (las nóminas, el cuadre de tarjetas, el envío a la cámara de compensación), no tiene interfaz bonita, no sale en ninguna presentación de producto y su documentación sigue hablando de «nodos» como hace treinta años. Y sigue ahí.

Qué es exactamente


Connect:Direct es un producto de transferencia gestionada de ficheros (MFT, por sus siglas en inglés) que mueve datos punto a punto entre dos sistemas que se conocen previamente. Usa su propio protocolo y no pasa por ningún servidor de terceros. IBM lo llamó durante años Sterling Connect:Direct, y en la documentación actual ya aparece como IBM Connect:Direct.

A un servidor SFTP se conecta cualquiera que tenga credenciales, y lo que pueda hacer una vez dentro depende de cómo esté configurado el servidor. Aquí la relación es al revés: los dos extremos son nodos definidos el uno en el otro, con su identidad, sus permisos y sus reglas, y una transferencia entre dos sistemas que no se han declarado mutuamente no ocurre.

La segunda diferencia es la que explica por qué sigue instalado, y es tan poco vistosa como decisiva: el reinicio desde el punto de fallo. Cuando se transfiere un fichero de doscientos gigas y la línea se cae al 93 %, un FTP o un SFTP lanzados desde un script suelen volver a empezar desde cero. Solo continúan si alguien programó la reanudación. Connect:Direct va guardando puntos de control por el camino, y el parámetro ckpt del paso de copia define cada cuánto, así que al reanudar continúa desde el último. En una ventana nocturna que termina a las seis de la mañana, esa diferencia decide si el proceso del día siguiente arranca o no.

PreguntaSFTPConnect:Direct
¿Quién puede conectarse?Cualquiera con credenciales del servidor.Solo los nodos que se han declarado el uno en el otro.
¿Y si se corta a mitad?Desde un script, normalmente vuelta a empezar.Sigue desde el último punto de control.
¿Qué pasa al terminar?Nada, salvo que lo programes aparte.El Process puede lanzar un job o un comando en el destino.
¿Socios fuera de tu red?Lo habitual es dejar un servidor expuesto en la DMZ.Secure Proxy en la DMZ, sin puertos entrantes hacia la red interna.

El trabajo se declara, no se teclea


En Connect:Direct no se «hace una transferencia»: se escribe un Process, un pequeño programa en su propio lenguaje que declara qué hay que mover, desde dónde, hacia dónde, con qué disposición de fichero y qué hacer después. Y ese «qué hacer después» es más de lo que parece, porque un Process puede ejecutar un job, un programa o un comando en el servidor del otro extremo, encadenar pasos y decidir el siguiente según el resultado del anterior.

Un mismo Process puede recoger el fichero, enviarlo, lanzar en el destino el proceso que lo carga en la base de datos y avisar si el código de retorno no es el esperado. Todo eso queda escrito, versionado y auditable en un sitio, en vez de repartido entre un script, un planificador y la memoria de quien lo montó. La contrapartida es que hay que aprender el lenguaje, y ahí es donde se atasca casi todo el que llega desde el mundo del scripting.

La seguridad, que es de donde vienen casi todos los proyectos


El complemento Secure Plus añade cifrado y autenticación a las sesiones entre nodos, con TLS y certificados, de modo que los dos extremos se identifican antes de mover un solo byte.

El caso que decide estos proyectos es cuando el socio está fuera de tu red, que es lo normal. La respuesta de IBM se llama Sterling Secure Proxy: un intermediario en la DMZ que termina ahí la sesión entrante, autentica al que llama y abre él mismo una conexión nueva hacia dentro. Nadie de fuera alcanza el servidor de verdad, y no hace falta abrir ningún puerto entrante hacia la red interna. Es la arquitectura que pide cualquier auditoría seria, y la razón por la que muchos proyectos de Connect:Direct no empiezan por una necesidad de negocio, sino por un informe de auditoría.

El último motivo de su longevidad es dónde corre: z/OS, UNIX y Linux, Windows, y también plataformas que ya casi nadie nombra pero siguen en producción, como i5/OS, OpenVMS o HP NonStop. Un nodo de z/OS y uno de Linux hablan entre sí igual, con el mismo lenguaje de Process y las mismas reglas, y nadie tiene que traducir nada entre el mainframe y el servidor distribuido. Cuando una organización tiene las dos cosas, y la banca las tiene, eso vale más que cualquier funcionalidad nueva.

Si montaras esto hoy de cero, ¿usarías Connect:Direct?


Depende de con quién tengas que hablar. Para un intercambio nuevo con un socio nuevo, hoy se empieza por algo más estándar: SFTP gestionado, una API, o Sterling File Gateway si hace falta una puerta de entrada única con su portal y sus perfiles. Connect:Direct gana cuando el volumen es grande, la ventana es estrecha, un fallo a mitad no es aceptable y, sobre todo, cuando el otro extremo ya lo tiene. Esto último pesa más que todo lo demás junto, porque en el intercambio de ficheros el protocolo casi siempre lo decide la entidad grande del otro lado.

Tampoco es un producto de EDI: mueve el fichero, pero no interpreta lo que hay dentro ni traduce un pedido de un formato a otro, que es trabajo de Sterling B2B Integrator. Ni sirve para que alguien mande un adjunto grande, porque está pensado para transferencias que se repiten cada día a la misma hora entre los mismos dos sistemas. Y cuando los nodos se cuentan por decenas, el seguimiento centralizado va aparte, en Sterling Control Center.

La formación, que es donde está el problema


El producto se vende, se soporta y se actualiza, pero la plantilla que lo montó en su día se va jubilando, y los Process que escribió siguen ejecutándose cada noche. Encontrar a alguien que sepa leerlos, y no digamos cambiarlos sin romper el cierre del día, es cada vez más difícil.

Nosotros impartimos los tres cursos oficiales, con laboratorio sobre nodos reales, porque el ckpt se entiende cortando la conexión a mitad de una transferencia y viendo qué pasa, no leyendo la definición del parámetro: Connect:Direct para UNIX (6C02G), para Windows (6C03G) y para z/OS (6C07G). Los tres cubren lo mismo desde la plataforma donde corra tu nodo, y el resto de la familia está en el catálogo de formación de IBM Sterling. Se montan en grupo cerrado, en español, inglés o francés, online o en tus instalaciones.

Preguntas frecuentes


¿Qué es IBM Connect:Direct?

Es un producto de IBM de transferencia gestionada de ficheros que mueve datos punto a punto entre sistemas que se conocen previamente. Tiene su propio protocolo, reinicia desde el punto de fallo y puede ejecutar tareas en el destino al terminar.

¿En qué se diferencia Connect:Direct de SFTP?

En SFTP se conecta cualquiera con credenciales y, si la transferencia se corta, vuelve a empezar. En Connect:Direct los dos nodos se declaran el uno en el otro, la transferencia continúa desde el último punto de control y el propio Process puede lanzar acciones en el otro extremo.

¿Connect:Direct sirve para EDI?

No. Mueve el fichero sin interpretar su contenido. La traducción de formatos de EDI la hace otro producto de la familia, Sterling B2B Integrator.

SIXE

¿Tienes un Connect:Direct heredado?

Si nadie en tu equipo sabe tocarlo, o una auditoría te ha dicho que no puedes seguir exponiendo el servidor, dinos qué versión tienes instalada y en qué plataforma, y te decimos qué haría falta.

Formación y soporte de IBM Sterling · sixe.es
SIXE