Integrando Sistemas de Informacion?

Integrando Sistemas de Informacion?
En la mayoría de proyectos uno de los retos de alguna u otra forma es intercambiar información con
sistemas de terceros, a los cuales no tenemos acceso directamente a su fuente de datos. Un caso común
es el intercambio de información con proveedores, con entidades financieras, entidades públicas, o
alguna otro tipo de aplicación de terceros. Los comentarios a continuación son basados en los
escenarios y proyectos en que participado, y siempre se pueden complementar con alguna experiencia
adicional en los comentarios.
¿Por qué esta necesidad de intercambiar información?
 Por que nuestro negocio necesita de otras organizaciones para lograr sus metas. Por ejemplo,
si tengo un sitio en la que se realizan ventas on-line, podría crear mi propio medio de pago y
encargarme de la cobranza, pero perdería la visión de mi negocio: “vender”, lo que puedo
hacer para centrar los esfuerzos en mi negocio, es apoyarme en algún medio de cobro ya
existente, pero surge una nueva necesidad: intercambiar información con un sistema de cobro.
 Eliminar la redundancia de información dentro de nuestra organización. La mayoría de
organizaciones, sobre todo las grandes, cuentan con empaquetados o software comúnmente
llamado ERP. Pero adicionalmente a tener un ERP, también podemos contar sistemas propios,
ya sea por que el ERP no se adecua en todas las áreas dentro de mi organización, o por que
simplemente no hay presupuesto para comprar los otros módulos. Tener varios sistemas en
nuestra organización, crea la necesidad de poder integrar los mismos, para no tener
información “duplicada” en cada sistema, y para remover esa redundancia debemos integrar
los sistemas.
 Crear nuevas oportunidades de negocio en nuestra empresa. Digamos que soy una entidad
financiera, o soy una empresa que vende electrodomésticos, y que deseo como nueva
oportunidad de negocio, vender determinados seguros dentro de mi organización. Una opción
simple y práctica para hacerlo, es sólo vender los seguros y no cubrir los siniestros, para eso
debemos buscar una compañía de seguros constituida que sea quien cubra los siniestros, y
nosotros sólo centrarnos en vender seguros a nuestros clientes. Pero para llevar a cabo ello,
tenemos el reto, del área de TI, de integrar mi información de ventas con la aseguradora. Y
este reto también es en viceversa, la aseguradora debe tener los mecanismos que me permitan
recibir información.
 Reportar información a sistemas de terceros. Cuando tenemos que reportar información, a
entidades públicas reguladoras, o a otros sistemas dentro de la corporación, por ejemplo en el
caso que estemos dentro de alguna franquicia.
Y dentro de las opciones de comunicación tenemos hasta tres escenarios comunes de intercambiar
información:
 Manual. En esta opción hay un esfuerzo del área de TI que va recibir la información, ya que
debe realizar la aplicación que usarán terceros para ingresar información en su fuente de datos.
Por ejemplo, una aseguradora no te va dar un conexión directa a su base de datos, una de las
opciones que tienen ellos para vender seguros en organizaciones de terceros, es desarrollar
una aplicación que sea usada por todas las empresas quieran vender nuestros seguros. Este
escenario también es la principal fuente de datos de un ERP, yo puedo consultar y ingresar
información a una fuente de datos de un ERP, a través de su aplicación front-end.
 Masiva. En muchos casos usar el sistema de terceros para enviarles nuestra información a su
fuente de datos, puede no ser la mejor solución debido a problemas de infraestructura, de
personalización, o simplemente por que no hay un front-end, para realizar aquello. Una opción
es intercambiar información a través de archivos, digamos que al finalizar el día puedo
generar un archivo plano que contiene toda la información que deseo ingresar en otra fuente
de datos. Esta puede ser la manera más práctica, rápida, fácil e interoperable, de intercambiar
información, ya que todos los sistemas operativos soportan los archivos planos, y todos los
lenguajes contienen librerías, apis, o clases, para el manejo de archivos, sólo basta con definir
una estructura y podemos integrar sistemas. Los empaquetados o ERP, normalmente también
deberían permitir carga masiva de información a través de archivos.
 Automatizada o Directa. Una de las “desventajas” del intercambio de información a través de
archivos es que tengo que esperar que estos sean procesados para ver reflejada la información
en el sistema. Pero tenemos otra opción “automatizada” de intercambiar información “online”, y es que la organización que va enviar información desarrolle su propio sistema,
personalizado con las necesidades del mismo, pero que ingrese directamente información en
otra fuente de datos, y para lograr este objetivo necesitamos a los famosos “conectores”, y que
cualquier producto empaquetado sea ERP u otro, debería tener, y estos pueden ser conectores
limitados (del propio fabricante) o conectores estandarizados, como usar Web Services, y en
general cualquier otro “Servicio” que me permita conectarme con una fuente de datos de
terceros.
Lo ideal sería que nuestro negocio soporte los tres tipos de comunicación para no perder ninguna
oportunidad de crecimiento:
1. Vayamos al escenario de una organización que fábrica determinados productos electrónicos.
La organización, desea aumentar su fuerza de ventas, y para eso tiene pensado elaborar
convenios con pequeños proveedores que no tienen un área de TI claramente definida, y que
no tienen un sistema de ventas implementado, en este escenario se podría dar desarrollar una
aplicación de ventas para los proveedores que quieran vender nuestros productos.
2. Pero que pasa si hay otros proveedores, que tienen un área de TI definida, y que cuentan con
sistemas propios de ventas, una manera simple de recibir la información del proveedor es
aceptar la carga masiva a través de archivos, para ello la organización que recibe la
información debe definir la estructura, y validación del archivo a intercambiar.
3. Y finalmente, si hay un proveedor que desea realizar ventas on-line, debido a que en algunos
casos se venden productos sin stock, por el tiempo para enviar y procesar un archivo, pero
ellos no quieren usar la aplicación de ventas del fabricante, por que tendrían que duplicar la
información para que ellos mismos cuenten con la información registrada, en cambio el
proveedor quieren realizar una aplicación que registre la venta en su fuente de datos, pero a la
vez y de manera automática que registre la venta en la fuente de datos del fabricante, y ahí la
necesidad de un conector o Web Services, y en general un servicio, para enviar la información
en tiempo real.
Conocer la visión de negocio o el porque de la necesidad de integrar sistemas, es importante para tener
claro proceso y los objetivos de integrar información. Ahora vayamos a un punto de vista más técnico,
que me permita “integrar sistemas”.
En el primer escenario no hay mucha ciencia, ya es algo común y natural desarrollar aplicaciones, sólo
hay que tener en cuenta que la misma puede ser usada por terceros fuera de mi organización. Además
que existen que internet podemos encontrar muchos frameworks de desarrollo, o blogs hablando de tips
para el desarrollo de aplicaciones. Por eso nos vamos a centrar en los dos últimos escenarios
mencionados.
Veamos algunos ejemplos:
1. Windows Live Product Search, o lo que ahora es Bing Shopping. Si soy una empresa de venta
de productos, este servicio me permite promocionar mis productos, es decir va ser un sistema
de apoyo a mi negocio. Live Product Search, tenía un servicio para vendedores llamado:
Product Upload Service, este servicio me permitía ingresar información en su fuente de datos
enviando información en archivos planos o archivos de texto, delimitados por el carácter
TAB,
un
ejemplo
sería:
Product
Prdo01
Prdo02
Este
Este
es
es
Descripction
un
producto
un
producto
Price
muy
bueno
muy
barato
34.6
24.6
Stock
8
4
Sólo tengo que enviar mi archivo con todos los productos de mi sistema que deseo publicar, y
que serán ingresado en la fuente de datos de ellos, para que ellos puedan promocionarlos en su
Web. Google también tiene su Google Product Search, y que también soporta el envío de
archivos de texto delimitados por TAB. Además de archivos planos con separación por tab,
otro formato común son los archivos CSV, y hasta se puede intercambiar información en
archivos usando archivos Excel, pero es 100% recomendable usar archivos de texto, para no
limitar el intercambio de información a determinadas tecnologías.
2. NetSuite. Dentro de una organización puedo tener aplicaciones de 3 terceros, para realizar
nuestras operaciones transaccionales más importantes, como la contabilidad. Pero a medida
que la organización sigue creciendo necesita del apoyo de otros negocios o sistemas, y para
lograr aquello necesitamos personalizar nuestra comunicación con el empaquetado o ERP que
usemos, en nuestro ejemplo el producto es NetSuite. Como primera fuente NetSuite nos
brinda una aplicación Web, para ingresar información en su fuente de datos. ¿Qué pasa, si
quiero consultar directamente a mi información de NetSuite a través de un sistema?, o ¿si
quiero manipular la misma?. Digamos que quiero vender mis productos en Amazon, ellos me
envían diariamente las ordenes de compra y quiero enviar directamente las ordenes a Netsuite,
no manualmente a través de la Web, si no que sea un proceso automático de un sistema
propio. Para lograr aquello, NetSuite posee un juego o api de Web Services llamado
SuiteTalk, con el cual podemos hacer diversas operaciones contra nuestra información,
consulta o modificación, directamente, sin la necesidad de que sea un proceso manual a través
de su Front-End. Un caso similar, es con SAP, el cual posee conectores que permite tener
acceso a la información de un sistema SAP, hay una implementación para .Net: SAP .NET
Connector, y aquí pueden revisar un ejemplo: ASP.NET Using SAP .NET Connector.
Notemos, que nosotros no sabemos que motor de base de datos usa Live Products, Google Products, o
NetSuite. Pero ello no impide que con un front-end, un archivo masivo, o un conector, pueda consultar
y modificar: “mi información”. Y obviamente estos modelos de negocio de poder acceder directamente
a mi información, tiene que ver con el modelo SaaS, pero ese será tema de otras entradas.
Resumiendo, si quiero que otras organizaciones se comuniquen o integren con nuestros sistemas,
tenemos 3 opciones:
1. Desarrollar una aplicación Web o Windows, y que ellos usen la misma para ingresar
información directamente en nuestra fuente de datos.
2. Usar un archivo de carga masiva. Debemos definir: la estructura del archivo, las reglas de
validación, y la frecuencia de envío. Y obviamente, soportar la carga masiva a nuestra fuente
de datos.
3. Crear conectores, que pueden ser Web Services u otro Servicio, que permita que terceros
puedan desarrollar sus propias aplicaciones, y se ingrese automáticamente la información a
nuestra fuente de datos.
Tomemos el punto 3 para hacer algunas aclaraciones. Definamos la siguiente frase: “Un Web Service
no es para que te comuniques tu mismo, un Web Services o Servicio es para habilitar que otro sistemas
se comuniquen contigo”. Por ejemplo, si en un mismo servidor estará la base de datos, el Web Service,
y una la Aplicación Web. Usar un Servicio, Web Services, o WCF para que la aplicación Web se
conecte a la base de datos, ¿se justifica la creación de una capa de servicios para pasar información
dentro del mismo servidor?, ¿sabiendo que ese Servicio sólo lo usaremos nosotros?, Nuevamente este
es un problema de moda, recomendar el uso de WCF sin conocer el escenario puede ser un problema
que finalmente terminan sufriendo los desarrolladores duplicando la comunicación, cuando no hay un
entorno distribuido y cuando nadie más que nosotros va a usar el servicio. Esto no quiere decir que no
debamos usar WCF, debemos usarlo pero cuando la infraestructura lo necesite o cuando necesitemos
que terceros se comuniquen con nuestra fuente de datos, y no por que en todos lados hablan de
Servicios, Web Services, o WCF. Leer también este artículo de elBruno: la arquitectura de la cebolla,
del mismo podemos acotar la siguiente frase: “aplicar la solución correcta al problema específico, y
que cuando el mismo cambie o evolucione, en ese momento cambiemos o evolucionemos nuestra
solución”
Y para cerrar, ya mencionamos algunas opciones para poder integrar sistemas, en los siguientes post
vamos a desarrollar el uso de intercambio de archivos para carga masiva de información.