Conectar dos programas: qué verificar antes de prometer una integración

«¿Los dos sistemas se hablan?» es una pregunta a la que no se puede responder. Se hablan para hacer qué: qué dato, en qué dirección, con qué frecuencia, y quién tiene razón cuando los dos dicen cosas distintas. Esta guía sirve para responder antes de asumir un compromiso, porque una integración prometida y no verificada convierte un proyecto en un mantenimiento sin fin.

Casi todas las integraciones fallidas tienen la misma historia: funcionaba en pruebas, luego llegó un caso no previsto —un pedido anulado, un cliente con dos fichas, un artículo eliminado— y nadie se dio cuenta de que desde hacía tres días no pasaba nada.

Una línea por cada dato

El documento de partida es una lista: una línea por dato, cuatro columnas. Si no se consigue rellenarlo, todavía no es el momento de mirar las especificaciones técnicas.

La última columna es la que evita las discusiones. Si el precio de un artículo resulta distinto en los dos sistemas, ¿quién tiene razón? Si la respuesta es «depende», la integración producirá datos incoherentes con independencia de la tecnología que uséis.

Los datos que cambian de dueño por el camino

Algunos datos cambian de propietario y es el caso más delicado. Un pedido pertenece a la web hasta que se adquiere; a partir de ese momento la verdad está en el sistema de gestión y la web solo muestra una copia. Si los dos pueden modificarlo, tarde o temprano dos modificaciones se cruzarán y ganará la última que llegue, que no es necesariamente la correcta.

La regla práctica es una sola: para cada dato, en cada momento, solo un sistema puede escribirlo. Los demás leen.

Lo que las interfaces no dicen en la primera página

• Los permisos. Las credenciales que os dan pueden no cubrir todos los campos que necesitáis, y la autorización puede caducar o requerir una renovación periódica que alguien debe recordar hacer.
• Los límites. Cuántas llamadas por minuto o por día, cuántos registros por solicitud. Un catálogo grande puede no caber dentro de los límites con la frecuencia que necesitáis, y esto cambia el proyecto, no solo el código.
• Los campos realmente disponibles. La documentación enumera los objetos, pero no siempre dice si vuestros campos personalizados están expuestos: hay que mirarlos sobre vuestros datos, no sobre el ejemplo.
• El entorno de pruebas. Si no existe, cada verificación se hace sobre los datos reales, con lo que eso implica. Es una limitación que hay que tener en cuenta antes, no descubrir después.
• Las condiciones del proveedor. Qué está permitido hacer, con qué plan, y si el acceso al intercambio de datos está incluido o es un coste aparte.

Ficha de integración: el pedido que llega dos veces

El caso que hay que diseñar no es el normal, es el sucio. Un pedido se envía al sistema de gestión, la respuesta no llega por un problema de red, el sistema reintenta, y el pedido entra dos veces. Es la avería más común de todas.

1. Cada mensaje lleva un identificador estable, decidido por quien lo envía: el número de pedido de la web, no un consecutivo generado en el momento del envío.
2. Quien lo recibe comprueba si ese identificador ya se ha procesado. Si es así, no repite nada y responde que ya está hecho. Es esta propiedad la que hace seguro reintentar.
3. Los intentos se repiten a intervalos crecientes y un número definido de veces; después el mensaje va a una cola de errores que revisa una persona. Reintentar indefinidamente oculta el problema en vez de resolverlo.
4. A intervalos regulares se comparan los dos sistemas sobre el período: cuántos pedidos por un lado, cuántos por el otro, cuáles faltan. Es la reconciliación, y es lo único que dice de verdad si la integración funciona.
5. La recuperación es un procedimiento escrito: quién elimina el duplicado y en qué sistema, qué pasa con el documento ya emitido en su caso, quién avisa al cliente si ha recibido dos confirmaciones.

La misma ficha debe rellenarse para la ficha del cliente, donde la avería típica es otra: dos fichas para la misma empresa, creadas con el número de IVA escrito de dos formas distintas. Hace falta una regla de reconocimiento decidida de antemano, y un lugar donde vayan los casos dudosos a la espera de que una persona los revise.

Quién se entera cuando se para

Una integración se para siempre, tarde o temprano: el proveedor actualiza, una contraseña caduca, un certificado no se renueva, un campo cambia de formato. La pregunta no es si sucederá, sino cuánto tiempo pasará antes de que alguien lo note.

• Un control que verifique el paso reciente de datos y avise cuando el flujo se interrumpe, en lugar de esperar la llamada de un cliente.
• Un destinatario con nombre y apellidos para ese aviso, y un segundo nombre para cuando el primero no está.
• Un registro de los intercambios consultable sin llamar a un desarrollador: cuando un pedido no llega, la primera pregunta es siempre «¿ha salido?».
• Una responsabilidad declarada para el mantenimiento, con las fechas de caducidad de credenciales y certificados anotadas en un lugar que alguien revisa.

Lo que esta guía no cubre

Aquí se diseña el intercambio entre dos sistemas destinados a convivir. Traer datos históricos —de un sistema de gestión antiguo o de hojas de cálculo— es un trabajo distinto, con problemas de limpieza y de control del resultado, y tiene una guía dedicada. También el caso específico de la conexión entre tienda online e inventario se trata aparte.