lstGeeksMs.Where(u => u.Estado == "papafeliz").Select(u => u).ToList().Add(new UserGeek() { Nombre = "sergiotarrillo", Estado = "papafeliz", Hijo = “marcello” });

Marcelo en el tercer planeta

Pues que nada, me uno a lista de padres en Geeks.ms.

Ser papá es un sentimiento difícil de describir con palabras, pero, si ser papá es hablarle a la barriguita de tu esposa durante nueve meses, si ser papá es emocionarte con cada patadita del bebé dentro de la barriguita, si ser papá es llorar junto con el bebé cuando da su primer llanto, si ser papá es ensuciarte con el bebé cuando le cambias los pañales, si ser papá es poner cara de tonto cuando el bebé da su primera sonrisa, si ser papá es contarlo públicamente en tu blog, pues si, que soy un papá feliz!

Y eso, que es una nueva motivación en la vida para ser una persona mejor.

Saludos,

Integrando Sistemas de Informacion?

http://sergiot2.com/blogimages/2009/06Jun/20090609-Integration.jpg

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 “on-line”, 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   Descripction  Price  Stock
    Prdo01     Este es un producto muy bueno  34.6  8
    Prdo02     Este es un producto muy barato  24.6  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.

Saludos,