Los cinco principales patrones de integración de datos

Los datos son un activo empresarial muy valioso, pero a menudo resultan difíciles de acceder, compilar e interpretar.

Cuando se trasladan entre sistemas, ese traslado no siempre se produce siguiendo un formato estándar; la integración hace que los datos no dependan de ningún modelo concreto y que puedan abrirse y gestionarse con facilidad.

A fin de obtener un mayor nivel de utilización e incluso de velocidad, los desarrolladores pueden usar patrones para estandarizar el proceso de integración.

Estos patrones, al igual que los senderos de montaña, se descubren y establecen en función del uso. Siempre presentan diferentes niveles de perfección, pero se pueden optimizar o adoptar teniendo en cuenta las necesidades empresariales que requieren soluciones. Podemos concebir el caso de uso empresarial como una ejecución del patrón, es decir, un uso del proceso genérico de movimiento y gestión de los datos.

Existen cinco patrones de integración de datos en función de los casos de uso empresariales y los patrones de integración en la nube.

La migración es el acto de transferir datos de un sistema a otro. Una migración conlleva un sistema de origen en el que residen los datos antes de la ejecución, los criterios que determinan el alcance de los datos que se van a migrar, la transformación por la que pasará el conjunto de datos y el sistema de destino donde se insertará, así como la capacidad de guardar los resultados de forma que se pueda conocer el estado alcanzado respecto al estado deseado.

La migración es esencial para todos los sistemas de datos. La creación y el mantenimiento de los datos suponen una gran inversión de tiempo, y la migración es clave para garantizar la independencia de los datos respecto a las herramientas utilizadas para su creación, visualización y gestión. Sin ella, se perderían todos los datos acumulados cada vez que se cambiase de herramienta, lo que perjudicaría la productividad en un mundo digitalizado.

La migración se produce al transferir datos de un sistema a otro diferente o a una instancia nueva o distinta del sistema original, al crear un nuevo sistema que amplía la infraestructura actual, al realizar una copia de seguridad de un conjunto de datos, al añadir nodos a clústeres de base de datos, al sustituir el hardware de una base de datos y al consolidar sistemas, entre otros procesos.

La transmisión también puede llamarse "sincronización unidireccional de un sistema a muchos" y hace referencia a la transferencia de datos desde un único sistema de origen hasta múltiples sistemas de destino de manera continua y en tiempo real (o casi en tiempo real).

Allá donde exista la necesidad de mantener los datos actualizados entre múltiples sistemas a lo largo del tiempo, será preciso un patrón de transmisión, sincronización bidireccional o correlación. El patrón de transmisión, como sucede en la migración, solo transfiere los datos en una dirección, desde el origen hasta el destino. La diferencia radica en su carácter transaccional.

De acuerdo con este enfoque, no se ejecuta la lógica de los procesadores de mensajes para todos los elementos dentro del alcance; lo que se ejecuta es más bien una lógica únicamente para los elementos modificados recientemente. La transmisión puede entenderse como una ventana corredera que solo captura aquellos elementos con valores de campo que han cambiado desde la última ejecución de la transmisión.

Otra diferencia importante es cómo se diseña la implementación del patrón. La migración se puede ajustar para dar cabida a grandes volúmenes de datos, procesar numerosos registros en paralelo y aislar de forma eficaz los elementos problemáticos en caso de fallos. Los patrones de transmisión están optimizados para procesar los registros rápidamente y demostrar una alta fiabilidad a fin de evitar la pérdida de datos esenciales durante el tránsito.

El patrón de transmisión es especialmente valioso cuando un sistema B necesita acceder en tiempo real a información que se origina o reside en un sistema A. Por ejemplo, puede que se desee crear un panel de informes en tiempo real: un destino para diferentes aplicaciones de transmisión que reciba actualizaciones inmediatas sobre lo que ocurre en distintos sistemas.

Quizás se desee empezar a servir inmediatamente los pedidos recibidos a través de sistemas CRM, herramientas de comercio electrónico o internas en las que el sistema de tramitación de pedidos esté centralizado, independientemente del canal del que proceda el pedido. Puede tratarse de enviar una notificación sobre la temperatura de una turbina de vapor al sistema de supervisión cada 100 ms. O de transmitir datos al sistema de gestión de pacientes de un médico de cabecera cuando uno de sus pacientes habituales tiene que ingresar en urgencias. Los casos en los que se necesita transmitir datos de un sistema de origen a otro de destino son innumerables.

La "necesidad" de un patrón de transmisión puede identificarse fácilmente atendiendo a los siguientes criterios:

• ¿Debe el sistema B saber de inmediato si se produce un evento? — Sí
• ¿Deben los datos fluir automáticamente de A a B, sin intervención humana? — Sí
• ¿Debe el sistema A saber lo que ocurre con el objeto en el sistema B? — No

La primera pregunta ayuda a decidir si se debe usar el patrón de migración o transmisión en función de si los datos deben ser en tiempo real o no. Cualquier caso inferior a una hora aproximadamente precisará un patrón de transmisión. No obstante, siempre hay excepciones basadas en los volúmenes de datos.

La segunda pregunta normalmente descarta las aplicaciones bajo demanda, y los patrones de transmisión, por lo general, se iniciarán a raíz de una notificación push o un trabajo programado, por lo que no existirá la intervención humana.

La última pregunta permite saber si es necesario unificar los dos conjuntos de datos para que se sincronicen en ambos sistemas: un proceso conocido como sincronización bidireccional. Las necesidades diferentes requieren patrones diferentes de integración, pero el patrón de transmisión ofrece una flexibilidad mucho mayor a la hora de conectar las aplicaciones, por lo que se recomienda utilizar dos aplicaciones de transmisión en lugar de una aplicación de sincronización bidireccional.

La "necesidad" de un patrón de transmisión puede identificarse fácilmente atendiendo a los siguientes criterios:

• ¿Debe el sistema B saber de inmediato si se produce un evento? — Sí
• ¿Deben los datos fluir automáticamente de A a B, sin intervención humana? — Sí
• ¿Debe el sistema A saber lo que ocurre con el objeto en el sistema B? — No

La primera pregunta ayuda a decidir si se debe usar el patrón de migración o transmisión en función de si los datos deben ser en tiempo real o no. Cualquier caso inferior a una hora aproximadamente precisará un patrón de transmisión. No obstante, siempre hay excepciones basadas en los volúmenes de datos.

La segunda pregunta normalmente descarta las aplicaciones bajo demanda, y los patrones de transmisión, por lo general, se iniciarán a raíz de una notificación push o un trabajo programado, por lo que no existirá la intervención humana.

La última pregunta permite saber si es necesario unificar los dos conjuntos de datos para que se sincronicen en ambos sistemas: un proceso conocido como sincronización bidireccional. Las necesidades diferentes requieren patrones diferentes de integración, pero el patrón de transmisión ofrece una flexibilidad mucho mayor a la hora de conectar las aplicaciones, por lo que se recomienda utilizar dos aplicaciones de transmisión en lugar de una aplicación de sincronización bidireccional.

Un patrón de integración de datos de sincronización bidireccional consiste en combinar dos conjuntos de datos en dos sistemas diferentes de forma que actúen como uno solo, respetando su existencia como entidades aparte. Esta necesidad de integración surge de tener herramientas o sistemas diferentes para realizar distintas funciones sobre el mismo conjunto de datos.

Por ejemplo, es posible que se tenga un sistema para recibir y gestionar pedidos y otro para la atención al cliente. También es posible que se piense que ambos sistemas son de lo mejor de su clase y que es importante utilizarlos, en lugar de un paquete que realice ambas funciones y disponga de una base de datos compartida. Utilizar la sincronización bidireccional para compartir el conjunto de datos permitirá utilizar ambos sistemas a la par que se mantiene una vista coherente y en tiempo real de los datos que hay en ellos.

La sincronización bidireccional puede ser a la vez un catalizador y una salvación, según sean las circunstancias que justifiquen su necesidad. Si existen dos o más representaciones independientes o aisladas de la misma realidad, se puede usar la sincronización bidireccional para optimizar esos procesos.

Por otro lado, la sincronización bidireccional permite pasar de un conjunto de productos que funcionan bien conjuntamente (aunque quizá no sean los mejores en sus funciones concretas) a un conjunto de soluciones que se pueden seleccionar por separado e integrar entre sí utilizando una plataforma de integración empresarial como Anypoint Platform de MuleSoft.

La necesidad de una aplicación de integración mediante sincronización bidireccional es sinónimo de querer representaciones de objetos de la realidad que sean completas y coherentes. Por ejemplo, si se desea una vista única del cliente, se puede conseguir otorgando manualmente acceso a todas las personas para la totalidad de sistemas que tienen una representación de la noción de un cliente. Sin embargo, una solución más eficiente sería comunicar los campos que deben ser visibles para ese objeto de cliente y en qué sistemas, así como determinar qué sistemas son sus propietarios.

La mayoría de sistemas empresariales tienen una forma de ampliar objetos que permite modificar la estructura de datos de los objetos de cliente para incluir dichos campos. Así, es posible crear aplicaciones de integración, ya sean de punto a punto (utilizando una plataforma de integración común) si se trata de una solución sencilla, o un sistema más avanzado como el modelo de enrutamiento basado en una publicación/suscripción o en cola si entran en juego varios sistemas.

Por ejemplo, un vendedor debe conocer el estado de una entrega, pero no necesita saber en qué almacén se encuentra. Del mismo modo, la persona responsable de despachar una entrega necesita saber el nombre del cliente, pero no cuánto ha pagado por ella. La sincronización bidireccional les da a ambas personas una vista en tiempo real del mismo cliente, pero ajustada a sus necesidades.

El patrón de integración de datos correlacionados es un diseño que identifica la intersección de dos conjuntos de datos y realiza una sincronización bidireccional solo si el elemento se encuentra en ambos sistemas de manera natural. De manera similar a cómo el patrón bidireccional sincroniza la unión del conjunto de datos pertinente, la correlación sincroniza la intersección.

En el caso del patrón de correlación, es posible que esos elementos que residen en ambos sistemas se hayan creado manualmente en cada uno de ellos, como si dos representantes de ventas hubieran introducido el mismo contacto en ambos sistemas CRM. O también es posible que se hayan incluido como parte de una integración diferente. Con el patrón de correlación, no importa de donde procedan los objetos, ya que los sincroniza de manera independiente siempre y cuando se encuentren en ambos sistemas.

El patrón de integración de datos de correlación es útil cuando se tienen dos grupos o sistemas que quieren compartir datos únicamente si ambos tienen un registro que represente al mismo elemento/persona en la realidad. Tomemos el ejemplo de un grupo hospitalario que tiene dos hospitales en la misma ciudad. Es posible que se desee que los dos hospitales compartan datos, de forma que si un paciente acude a cualquiera de ellos, se pueda acceder a un historial actualizado del tratamiento recibido por el paciente en ambos hospitales.

Para conseguir una integración de esta clase, pueden crearse dos integraciones de patrón de transmisión: una desde el hospital A al hospital B y otra que vaya del B al A. De esta manera, se garantiza la sincronización de los datos; sin embargo, ahora habrá que gestionar dos aplicaciones de integración.

Para eliminar la necesidad de gestionar dos aplicaciones diferentes, se puede utilizar simplemente el patrón de sincronización bidireccional entre el hospital A y el B. No obstante, a fin de incrementar la eficiencia, sería recomendable no extraer los registros del hospital B de los clientes que no tengan ninguna relación con el hospital A y solo hacerlo con los registros pertinentes en tiempo real y en cuanto se generan. El patrón de correlación es útil porque solo sincroniza bidireccionalmente los objetos relevantes, en lugar de transferir conjuntos de datos completos en ambas direcciones.

El patrón de integración de datos de correlación es de mayor utilidad cuando el hecho de disponer de datos adicionales supone más un coste que una ventaja, ya que permite descartar los datos innecesarios. Otro ejemplo sería el de una universidad que forma parte de un sistema universitario más amplio y busca generar informes sobre sus estudiantes.

La universidad no necesita que aparezcan en los informes aquellos alumnos que nunca han estudiado allí. Pero sí que debe incluir las asignaturas que dichos alumnos han cursado en otras universidades del mismo sistema universitario. En este caso, el patrón de correlación ahorraría mucho trabajo, ya sea en la integración o en la generación de informes, porque permite sincronizar únicamente la información de los estudiantes que han asistido a ambas universidades.

La agregación es el acto de recoger o recibir datos de varios sistemas e insertarlos en uno solo. Por ejemplo, es posible que la integración de datos del cliente resida en tres sistemas y que un analista de datos desee generar un informe con datos de todos ellos. Sería posible crear una migración diaria desde cada uno de esos sistemas a un repositorio de datos y, a continuación, consultar esa base de datos. No obstante, habría que supervisar y mantener la sincronización de otra base de datos más.

Asimismo, habría que actualizar el repositorio constantemente a medida que se produzcan cambios en los otros tres sistemas. Otra desventaja es que los datos tendrían una antigüedad de un día, así que para obtener informes en tiempo real, el analista tendría que iniciar migraciones manualmente o esperar otro día. Una opción sería configurar tres aplicaciones de transmisión para que la base de datos de informes esté siempre actualizada y refleje los cambios más recientes que se producen en cada sistema. Sin embargo, habría que seguir manteniendo esta base de datos que solo almacena datos replicados para que pueda consultarse con asiduidad. Además, sería necesario malgastar una serie de llamadas de API para garantizar que la base de datos nunca tenga un desfase de más de un determinado número de minutos con respecto a la realidad.

Aquí es donde entra en juego el patrón de agregación. Al crear una aplicación, o utilizar una de nuestras plantillas, se observará que se pueden consultar muchos sistemas bajo demanda, combinar el conjunto de datos y aplicarlo al propósito que se estime conveniente.

Por ejemplo, se puede crear una aplicación de integración que consulte varios sistemas, combine los datos y, a continuación, genere un informe. De esta forma, se evita tener una base de datos adicional y se puede obtener el informe en formato .csv u otro que se elija. Es un informe que se puede almacenar en la ubicación donde estos se guardan directamente.

El patrón de agregación es valioso porque permite extraer y procesar datos de varios sistemas en una aplicación unificada. De esta manera, los datos se encuentran actualizados en el momento preciso, no se replican y se pueden procesar o combinar para generar el conjunto de datos deseado.

El patrón de agregación es valioso si se crean APIs de coordinación para "modernizar" sistemas heredados, especialmente una API que reciba datos de varios sistemas y los procese en una sola respuesta. Otro caso de uso es la creación de informes o paneles para extraer datos de varios sistemas y crear una experiencia a partir de estos datos.

Por último, es posible que los sistemas de cumplimiento o auditoría requieran datos relacionados que proceden de varios sistemas. El patrón de agregación ayuda a garantizar que los datos de cumplimiento residan en un solo sistema pero puedan ser una amalgama de datos pertinentes de varios sistemas. De este modo, se puede reducir la cantidad de aprendizaje respecto a los distintos sistemas para garantizar la visibilidad sobre lo que se está haciendo.