Cross Reference o Referencias cruzadas es una de las técnicas más utilizadas para la integración de aplicaciones basadas en Arquitectura SOA, en donde las distintas aplicaciones comparten información similar pero replicada en cada una de ellas. De entrada puede resultar un poco tonto decir que la información se encuentre en varias aplicaciones, sin embargo existen escenarios donde esto es así y en realidad no está mal. Pero antes de debatir este punto me gustaría explicar en qué consiste Cross Reference.
Como funciona Cross Reference
Imaginemos un escenario de la vida real. Estamos a cargo del desarrollo de un ERP, el cual dentro de sus características está la de comunicarse con los proveedores para realizar pedidos de los productos que vendemos desde nuestro B2C (Business To Customer). Estos productos son solicitados a nuestros proveedores por medio de un WebService, el cual nos requiere como entrada los productos a comprar y la cantidad, entre otros datos más, los productos a comprar son indicados al proveedor por medio del ID del producto. El problema viene a continuación, tu pueden vender una Laptop marca ACME modelo XX la cual tiene un ID de producto XYZ, sin embargo este mismo producto para tu proveedor tiene un ID distinto, por ejemplo ABC. En este punto creo que ya somos más conscientes del problema ¿NO?. Sin entrar más en detalle imagina que el área de compras realizar su orden de compra para abastecer el producto bajo en existencia, esto generará la orden con el producto Laptops marca ACME modelo XX con ID XYZ. Aquí tenemos un problema, si yo le mando esa orden a mi proveedor me la rechazará por que el ID no lo reconoce, no sabe que producto le estas solicitando por lo que tendríamos que hacer un mapeo de los ID de nuestros productos con los productos de nuestro proveedor.
Este mapeo se realiza con las tablas XREF o Tablas de referencia cruzada, en la imagen podemos apreciar una tabla llamada products la cual tiene la relación de los ID de los productos con los ID de nuestros partners, de esta manera, cada ID nuestro corresponde contra un ID de nuestro partner. Cuando un producto es enviado al partner este deberá primero mapeado contra nuestra tabla XREF para obtener los ID que correspondan con el partner.
En la imagen podemos ver el proceso por el cual el pedido es procesado, el ERP genera el pedido y lo envía a una integración, el cual podrías ser un servicio o un BPEL para automatizar el proceso, el proceso realizaría el mapeo de claves contra la XREF generando un nuevo documento con los identificadores para el partner especifico.
Tablas XREF
Ya hablamos del proceso en sí, pero no hemos hablado de cómo es que las tablas XREF funcionan y cuál es la estructura que estas tablas deben de tener. En la actualidad sobresalen dos formatos para estas tablas.
XREF por entidad
Este formato consiste en crear una tabla por cada entidad del sistema, en esta tabla todos los registros que encontremos pertenecerán siempre a la misma entidad como por ejemplo todos los productos, pero solo productos.
En la imagen ponemos un ejemplo de una tabla XREF por entidad, lo primero que vemos es que se llama PRODUCTS aunque el nombre no es relevante, lo segundo es que tenemos una columna llamada ERP, esta columna nos indica el ID del producto en nuestro ERP, la columna PARTNER nos indica el ID del mismo producto pero para nuestro PARTNER. Para obtener el ID de nuestro partner solo tendremos que lanzar un query muy simple: SELECT PARTNER FROM PRODUCTS WHERE ERP =’XYZ’.
Este modelo tiene el inconveniente de que necesitaremos una tabla por cada entidad que necesitemos mapear, aunque por otro lado nos permite dar privilegios a las aplicaciones solo para las tablas requeridas.
XREF General:
La segunda manera es crear una tabla general en la cual tengamos todas las entidades con una columna especial que nos indica de qué tipo de entidad se trata el registro. De esta manera todas las entidades que se manejen estarán aquí, por ejemplo productos, proveedores, clientes, etc.
En esta tabla podemos ver que se agrega la columna ENTITY, la cual indica de qué tipo de objeto es el registro. Esta tabla funciona de forma muy similar a la XREF por entidad, solo que en esta tendríamos que añadir en la búsqueda el tipo de entidad que estamos buscando, por ejemplo: SELECT PARTNER FROM XREF WHERE ENTITY = ‘PRODUCT’ AND ERP = ‘XYZ’, este query buscara el ID de nuestro partner pero filtrando solo los registros de productos.
XREF para varios partners
Una de las características de las XREF es que nos permiten agregar más de un solo partner, por ejemplo, ¿qué pasaría si un mismo producto no lo puede surtir más de un proveedor?, agregar una tabla XREF por proveedor sería algo muy incómodo e impráctico, por esta razón, a las tablas XREF se les pues agregar una nueva columna por cada partner con el que tenemos comunicación.
En la imagen podemos apreciar que un mismo productos puede estar mapeado contra 3 partner distintos, lo que nos permite en cualquier momento obtener el ID del productos para cualquier de ellos. Es este caso el query cambia un poco según al partner al que nos estemos comunicando, por ejemplo: SELECT PARTNER1 FROM PRODUCTS WHERE ERP = ‘XYZ’, otra variante seria tener una tabla XREF general, en la cual solo agregamos la Entidad que estamos buscando.
Sincronización de las XREF
Otro de los puntos fundamentales para que una tabla XREF funcione, es tener la tabla actualizada, es decir que cada nuevo producto nuevo sea sincronizado, esto se puedo hacer de dos formas, automatizada o manual. Cuando es manual, no hay mucho que decir, pues se requiere de una persona o personas que estén constantemente actualizando los catálogos para que la información cuadre. Este escenario lo dejaremos de lado, ya que lo que nos interesa es automatizar el proceso.
En el escenario que explicamos anteriormente es mucho más complejo automatizar el proceso, pues la creación de los productos no está en nuestro control, y no es posible determinar qué productos es cual en nuestro aplicación, por este motivo expondremos un segundo escenario en el cual la creación de entidades si este bajo nuestro control.
Imaginemos que dentro de nuestra arquitectura tenemos una aplicación CRM desde la cual ofrecemos los productos a nuestros clientes y otra aplicación que se encarga de la facturación, del lado del CRM se crean los productos y se personalizan y desde el lado del facturador se asignan los precios y se generan las facturas mensuales a los clientes. Ambos sistemas comparten los mismos productos pero estos tienen sus propias copias en su base de datos. Cuando el CRM le vende productos a un cliente, este le envía al facturador los productos vendidos, luego el facturador le envía al CRM el detalle de la factura con los productos facturados.
En este punto es más que evidente que cada aplicación tiene su propia copia local del producto, por lo tanto cada uno maneja ID distintos, por otra lado, los productos son creados por el CRM aunque también podrían ser creados por el facturador. La pregunta es ¿Cómo podemos sincronizar los productos?, para resolver esta pregunta veamos la siguiente imagen:
La sincronización se da de la siguiente manera:
- Un producto es creado en el CRM
- El CRM ejecuta una integración para replicar el producto a los demás sistemas
- La integración crea el mismo objeto en el facturador y espera hasta que le regresa el ID generado.
- El ID del CRM que fue enviado y el ID generado por el facturador son insertados en la tabla XREF.
- De igual forma, si el facturador crea un nuevo producto este es replicado con la misma técnica.
Si un nuevo sistema es agregado y requiere de la sincronización de productos es simplemente es agregado en el proceso de sincronización y se agrega una columna extra a la tabla para poder guardar el ID generado para este nuevo sistema.
Conclusiones:
Cabe mencionar que esta técnica es implementada por lo fabricantes de Middleware más importantes y en muchos de los casos este tipo de integraciones son vendidas como paquetes para conectar los principales ERP, CRM, etc. En el caso de Oracle, este los vende como Process Integration Packs o PIP’s que son parte de un paquete llamado AIA o Application Integration Architecture.
Mi recomendación es investigar si nuestros productos ya tienen integraciones previamente desarrolladas que nos permitan ahorrarnos un gran esfuerzo antes de decidir desarrollar nuestras propias integraciones.