20
Feb
09

Una de BAM

La monitorización del negocio es una tarea importante dentro de cualquier actividad empresarial independientemente de lo organizada o caótica que pueda llegar a ser. Nos demos cuenta o no, siempre estamos al tanto del volumen aproximado de negocio que manejamos, del estado de las cuentas, de que actividades comerciales nos dejan un mayor beneficio y cuales menos; es decir, cuales nos interesan más, etc. etc.

Ahora, el tiempo y esfuerzo que gastamos en dicha gestión frente a los resultados obtenidos sí que es una variable en cada modelo de negocio y es totalmente dependiente de la cultura de empresa; vamos! de lo organizados que seamos, de la madurez de nuestros procedimientos y por qué no, la madurez tecnológica.

Business Activity Monitoring (BAM) es una herramienta dentro del marco de trabajo de BizTalk que nos ayuda a monitorizar el estado y salubridad de nuestros procesos de negocio en tiempo real. Y eso es lo realmente importante ya que desde el primer momento que salta un indicador, un analista de negocio podría decidir si es necesario moverse a un lado u otro del mercado sin tener que esperar a los bien conocidos informes consolidados mensuales, trimestrales o anuales y por tanto llegar a ser más ágil a la hora de cambiar la estrategia comercial.

En definitiva podemos pensar en BAM como el puente entre las técnicas de integración de aplicaciones y las de inteligencia empresarial (BI), ya que en última instancia, el objetivo de BAM es permitir sofisticadas técnicas de BI basadas en la información obtenida de los procesos de negocio en ejecución.

En otras palabras, BAM utiliza modelos BI basados en la información procedente de diferentes procesos de negocio. Dichos modelos se conocen como modelos de evento o actividad y normalmente se traducen en bases de datos relacionales y multidimensionales (Cubos OLAP) que se nutren de la información de negocio publicada mediante eventos producidos en el proceso de negocio como tal y captados por el modelo de observación BAM.

Entonces…… Si BAM no es más que prácticamente un sistema capaz de producir modelos multidimensionales de información en que se difiere de un Data Warehouse? Pues que aunque la infraestructura de ambas técnicas está basada en la generación y explotación de bases de datos relacionales y multidimensionales, BAM está centrado en la captura, procesamiento y análisis de eventos de procesos de negocio en tiempo real, mientras los Data-warehouse están más orientados al análisis agregación de históricos de diferentes fuentes de datos. BAM actúa sobre conjuntos de información muy específicos relacionados con una serie de procesos de negocio, mientras que los Data-warehouse se usan para representar vistas de datos agregados de un amplio rango de información que normalmente está asociada a un proceso de negocio, pudiendo usar por tanto estos últimos como complemento de BAM para enriquecer la información contenida en el Modelo de BAM.

El beneficio real del uso de una tecnología como BAM está en su habilidad para proveer métricas inteligentes de un dominio de negocio específico y que refleja el comportamiento de dicho proceso de negocio y en el poco esfuerzo (desarrollo/despliegue) que TI tiene que hacer para poder capturar dicha información debido a la infraestructura interna del producto. Esta habilidad a su vez se ve finalmente reflejada en la manera en que aplicaciones y usuarios de negocio consumen la información de actividad BAM para defender de una manera más inteligente y basada en hechos reales la toma de decisiones sobre el futuro inmediato de nuestro negocio.

02
Feb
09

Reencuentro

Buenas!!… Después de una gran temporada sin actividad en el blog, Dios! Casi seis meses desde el último post, quiero retomar las buenas costumbres y preparar un artículo BizTalk Fridays semanal, eso sí, igual con cierto carácter más tecnico (Objetivo muy ambicioso quizás, pero intentaremos conseguirlo)

En este reencuentro podría contaros alguna de las novedades de cara a la liberación de BizTalk Server 2009, la última release, que esperamos llegue antes de verano aunque… quien sabe. Pero seguro que dichas novedades ya no son noticia puesto que otros antes habrán hablado de ellas en sus blogs correspondientes.

Con lo que sí me voy a atrever es con la recopilación de ciertas cosas de interés relacionadas con BizTalk que han pasado en este último semestre:

  • Business Activity Monitoring in Depth for Developers: Interesante “White paper” sobre conceptos generales de BAM, buenas prácticas y ejemplos de código.
  • Nueva versión del BizTalk Adapter Pack: Paquete de adaptadores line-of-business basados en la tecnología WCF para integraciones Oracle, SAP, Siebel y SQL.
  • .Net services, lo que antes se llamaba BizTalk Services y que consisten en una serie de servicios “cloud aware” para el desarrollador que proporcionan los ‘building blocks’ para construir aplicaciones basadas en la nube.
  • Otro documento técnico llamado “Developing Integration Solutions using BizTalk Server 2006 and Team Foundation Server” en el que se explican técnicas de diseño desarrollo y despliegue de aplicaciones BizTalk Server 2006 R2 y Visual Studio Team Foundation Server
  • Guía ESB 2.0 que consiste en una Guía de arquitectura, patrones de diseño y buenas prácticas además de un conjunto de componentes .NET Framework y BizTalk para simplificar el desarrollo de un ESB en plataforma Microsoft.
  • Y otra guía más pero no por ello menos importante, la guía de operaciones de BizTalk Server, documento que ningún administrador u operador de BizTalk puede dejar de leer.
29
Ago
08

Motor de reglas: TDI o Gasolina

Últimamente he estado hablando en varios clientes sobre él valor añadido de los motores de reglas de negocio y en concreto de las características del motor de reglas de BizTalk. En la mayoría de esas reuniones han aparecido preguntas como ….. ¿Cuándo he de usar un motor del reglas vs embeber mi política de reglas en lógica de aplicación?, ¿Cómo de robusto será mi sistema si hago uso del motor de reglas?, ¿Se verá afectado el rendimiento de la aplicación?, ¿Cuánto se complicará mi arquitectura de la solución?, ¿Cómo de flexible será mi sistema frente a cambios en la política de negocio?, ¿Podrán los usuarios de negocio modificar dichas reglas?, …. Y un sinfín de preguntas más, pero que al final nos hace pensar que las cuatro preocupaciones principales son:

  • Fiabilidad
  • Rendimiento
  • Flexibilidad al cambio
  • Y por supuesto Facilidad en la implementación

Bueno…… Antes de empezar a hablar de todas estas cosas y por si alguien anda un poco despistado, ¿Qué es un motor de reglas? En pocas palabras podríamos decir que es un servicio que nos proporciona una infraestructura desacoplada del código de aplicación (Código fuente) para la definición y ejecución de reglas de negocio.

Vale pero…..  ¿Qué es una regla y por qué es todo esto tan importante? Una regla, no deja de ser una ejecución de ciertas tareas debido al cumplimento de una o varias condiciones de ciertos hechos que se cumplen en un momento dado. En definitiva…. de lo que se encargan Las reglas de negocio es de la definición y control del proceso de negocio en una organización. Y ahí está su importancia, todo software ya sea empresarial o no, está formado en gran parte por reglas.

Entonces,… . Si desde la creación del primer programa informático hemos sido capaces de lidiar con las reglas de negocio, ¿Por qué se habla tanto en estos días de los motores de reglas de negocio? Principalmente por el desacoplamiento con el código de la aplicación, un motor de reglas nos permitirá modificar la idiosincrasia de la política de reglas sin necesidad de re-compilar la aplicación. Es decir, podríamos modificar no solo los valores contra los que comparar nuestras reglas, sino también la estructura de dichas condiciones, e incluso las acciones a realizar tras el cumplimiento de una regla.

Dicho esto podríamos pensar…… Bueno si son tan potentes, ¿Por qué no usarlo siempre? Bueno pues como con casi todo, una solución no siempre encaja al 100% con la problemática que intentamos solventar. Quiero decir, si nuestro conjunto de reglas es muy sencillo y poco cambiante en cuanto a estructura de las condiciones a cumplir, ¿Por qué complicarse la vida con un motor de reglas como el de BizTalk pudiendo usar simples componentes que implementen dichas políticas de reglas? Apoyándose eso sí en información persistida en bases de datos para darle mayor flexibilidad en las variables a comparar. Pero si por el contrario el comportamiento de nuestro negocio es tan cambiante, ¿Por qué voy a dedicar esfuerzos en tareas tecnológicas (codificación, compilación, despliegue, etc.) pudiendo dedicarlos a la modelización de mi negocio de una manera ágil?

Bueno y que decir en cuanto a las preocupaciones principales de las que hablábamos al inicio del artículo:

  • 1. Flexibilidad al cambio: En mi opinión le podemos dar un 10 a esta característica del motor de reglas de BizTalk ya que nos permite modelar nuevas políticas de reglas sin necesidad de re-compilar o re-desplegar ningún assembly. Además existe el concepto de versionado de tal manera que todas las transacciones que se iniciaron con una versión de una política de reglas seguirán ejecutando dicha política mientras que las nuevas transacciones usarán la política actual.
  • 2. Fiabilidad: Gracias a las ventajas de configuración en alta disponibilidad que los servicios de BizTalk proporcionan y de la robustez del producto en sí misma se puede garantizar un alto grado de fiabilidad del sistema, siendo capaces de aislar unos procesos de otros de manera que no sea necesario parar unos servicios por el mal funcionamiento de otros. Además al tener la posibilidad de desplegar nuevas políticas de reglas en caliente, nuestro motor de reglas estará siempre disponible.
  • 3. Rendimiento: Existen muchos estudios de rendimiento de aplicaciones que usan motores de reglas, entre ellos uno de los mejores el que publica en su blog Charles Young comparando el rendimiento de los motores de reglas de WF y BizTalk. Inicialmente, podemos pensar que tendremos una pequeña pérdida de rendimiento al hacer uso de este tipo de servicios frente a desarrollar nuestros propios componentes de ejecución de reglas. Pero si ponemos en la balanza todas las características que nos proporcionan este tipo de motores frente al poco overhead a soportar, no cabe duda que a no ser que estemos hablando de sistemas de tiempo real esa mínima perdida de rendimiento está totalmente justificada.
  • 4. Y por último, Facilidad en la implementación: Lógicamente al hacer uso de este tipo de motores, añadimos un ápice de complejidad a la arquitectura del sistema, y aunque no sean extremadamente complejas las herramientas que el producto proporciona para la modelización de las reglas, es necesario cierto perfil técnico. En mi opinión el Business Rule Composer es la asignatura pendiente del motor, ¡no todo iba a ser bueno! J. Pero lo realmente importante es que al existir todo un framework de trabajo, podemos ser capaces de crear tanto nuestras políticas de reglas como la herramienta para su modelización programáticamente. Además si conseguimos tener definidos y organizados tanto nuestros procesos de negocio como las reglas que los componen sin necesidad de ir a línea de código…..

      …… Tendremos mucho terreno ganado y una aproximación BPM (Business Process management) muy eficiente.

22
Jul
08

BizTalk services añade un servicio de workflow

Hace muy poco el equipo de desarrollo de Microsoft BizTalk Services ha liberado la R12, que se espera sea más potente que el actual R28 de Fernando Alonso :-) ,en la que además de añadir ciertas mejoras en los servicios existentes, como el soporte de TCP y HTTP en los servicios de “Mensajería” y soporte REST para la transferencia de identidad (Servicios de “Identidad”). Se ha incorporado un nuevo servicio de workflow. El susodicho está escrito como no, sobre Windows workflow foundation y los servicios de mensajería. Este servicio permite orquestar servicios de la web para automatizar procesos de negocio distribuidos.

Si te parece interesante puedes leer más sobre esto en el blog de uno de los creadores Clemens Vasters o en la página oficial de laboratorios BizTalk

27
Jun
08

Objetos desacoplados 100%

Últimamente he estado involucrado en un proyecto, que por qué no decirlo, de los que más orgulloso me siento arquitecturalmente hablando. El sistema funcionalmente no era demasiado complejo, básicamente consistía en captar una colección de noticias, tratarlas, clasificarlas y publicarlas en diferentes portales de difusión pública.

El kit de la cuestión y de ahí mi satisfacción por el resultado, se debe a la modularidad, extensibilidad y flexibilidad a cualquier tipo de cosa involucrada en el proceso, del que se tenía que dotar al sistema. Si alguno de vosotros ha tenido la oportunidad de trabajar en algo relacionado con “Telco y media” sabrá de qué estoy hablando, porque ….. Si hay algo que está totalmente des-normalizado, y espero no herir a nadie un poco caótico, es el mundo de las noticias. (Aunque entiendo que es normal, ser el primero en proporcionar una noticia para ganar a tus competidores no es cosa fácil).

El principal problema aparece con la diversidad de formatos de entrada con los que te encuentras, no solo en cuanto a tipo de mensajes a tratar sino en contenido de los mismos. De manera que cada tipo de noticia (Feed para los entendidos) desemboca en un procesamiento diferente con un mayor o menor número de tareas.

Por resumir, la cadena de tareas más común a realizar podría reflejarse este diagrama:

Al tratarse de tareas encadenadas no cabe duda, en terminología BizTalk, que es necesario hacer uso de Pipelines, pero sería una locura tener que crear un pipeline por cada tipo de noticia y gestionar por tanto cientos de Receive Locations para poder asignar estos pipelines.

¿Cómo lo evitamos?

Creando una colección de “Custom Component Pipelies” base encargados, de en función del resultado de la ejecución de una serie de reglas de negocio, ejecutar los componentes que realmente realizan el proceso de la tarea en cuestión de forma dinámica.

 Los componentes base por tanto tienen como misión el funcionamiento del proceso de ejecución de mensajes de BizTalk, la ejecución de las políticas de reglas asociadas a la tarea involucrada en el proceso, y la instanciación y ejecución de los componentes de segundo nivel que como decíamos son los verdaderamente encargados del tratamiento de las noticias.

Los componentes de segundo nivel no tienen por qué tener ningún conocimiento de la infraestructura BizTalk, ni del resto de componentes de la arquitectura, solo se encargan de tareas simples como:

  • - Transformación al formato estándar NewsML
  • - Gestión de recursos (Fotos, videos, gráficos, etc.) de las noticias
  • - Tratamiento de dichos recursos (Calidad e imagen)
  • - Edición de los textos de las noticias
  • - Clasificación de las noticias para su posterior publicación en los portales de difusión
  • - Y un largo etc.

Como resultado de la arquitectura tenemos un BizTalk Pipeline capaz de ejecutar diferentes procesos para tratamiento de noticias en el que simplemente instalando nuevos assemblies a la GAC y modificando la política de reglas somos capaces de gestionar un mayor tipo de noticias o incluso realizar diferentes acciones para un tipo de noticia dado.

24
Jun
08

WF / WCF MSDN Webcasts

El blog del del equipo desarrollo de BizTalk Server ha anunciado una serie de Webcast para el mes de junio en los que se hablará sobre las capadidades de .Net Framework 3.5

Por lo que dicen consistirán en demostraciones “Deep Dive” de Windows Comunication Foundation y Windows Workflow Foundation.

Los ponentes serán gente tan conocida en el mundo  de la industria como: Juval Lowy, John Flanders, Jesus Rodriguez y Matt Milner

si quieres registrarte directamente lo puedes hacer en:

http://www.microsoft.com/events/series/msdnnetframework35.aspx?tab=webcasts&id=liveall

 

13
Jun
08

La capa de datos, esa gran desconocida

A estas alturas, quinta versión del producto, todos deberíamos saber que el motor de BizTalk se basa en una base de datos SQL (y solo SQL Server). No creo que nadie se extrañe, ya que dentro de la casa, ¡Microsoft claro!, existen varios productos que se basan en el motor de base de datos SQL Server, como sharepoint, Commer Server,….. E incluso productos de otros vendors como SAP también están montados sobre SQL, y es que si un producto funciona…. Por qué no usarlo.

Bueno como decía, BizTalk para su uso interno maneja como mínimo cuatro bases de datos que son:

  • BizTalk Management database (BizTalkMgmtDb)
  • BizTalk MessageBox database (BizTalkMsgBoxDb)
  • BizTalk Tracking database (BizTalkDTADb)
  • Y Single Sign-On database (SSODB)

Pero dependiendo de la funcionalidad BizTalk a usar se pueden llegar a usar hasta 17 bases de datos solo para uso interno del sistema, es decir, no cuentan las bases de datos de las aplicaciones con las que nos tengamos que integrar. Estas 17 bases de datos se reparten en:

  • Business Activity Monitoring (7): BAMAnalysis, BAMArchive, BAMAlertsApplication, BAMAlertsNSMain, BAMPrimaryImport, BAMStarSchema, BizTalkAnalysisDb
  • Mensajería EDI (1): BizTalkEDIdb
  • Human Workflow Services (1): BizTalkHwsDb
  • Business Rule Engine (1): BizTalkRuleEngineDb
  • Business Activity Services (3): TPM, Windows SharePoint Services configuration database, Windows SharePoint Services content database
  • Más las cuatro dictadas anteriormente para uso interno del motor.

También existen una serie de jobs que hacen un mejor engranaje de las piezas importantes del sistema y por lo tanto un mejor comportamiento, los más importantes son:

  • TrackedMessages_Copy_BizTalkMsgBoxDb: Se encarga de copiar el body de los mensajes trazados por la MessageBox a la base de datos de tracking (BizTalkDTADb).
  • MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb: Este gestiona la referencia al contador de logs de mensajes para determinar cuando un mensaje no ha sido referenciado por ningún subscriptor.
  • PurgeSubscriptionsJob_BizTalkMsgBoxDb: Encargado de purgar suscripciones no usadas la MessageBox
  • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb: Se usa para liberar entradas BTF (BizTalk Framework) expiradas en la base de datos de management (BizTalkMgmtDb).
  • MessageBox_DeadProcesses_Cleanup_BizTalkMsgBoxDb: Este Job usado por los componentes de administración de BizTalk se encarga de detectar cuando una instancia de host ha parado y libera todo el trabajo bloqueado por dicha instancia de host para que el trabajo pueda ser realizado por cualquier otra instancia del host perteneciente a la granja.
  • DTA Purge and Archive (BizTalkDTADb): Este se encarga de archivar datos de interés del flujo de proceso en la base de datos de tracking y purgar los obsoletos. ¡Cuidado con este! Hay que tenerlo muy en cuenta en los planes de backup y recuperación.

 

En mi opinión, y siempre hablando bajo mi experiencia en consultoría de proyectos BizTalk, no sé por qué, pero siempre nos olvidamos de esta capa de datos de la cual somos tan dependientes. En todo proyecto de integración en el que he participado ha existido la figura del usuario de negocio (Más o menos participativo), de los desarrolladores, de los administradores del entorno, e incluso del arquitecto BizTalk preocupado de definir cuando era mejor usar una orquestación, cuando usar únicamente servicios de mensajería, vamos en pocas palabras diseñar el mejor planteamiento de integración posible y de la manera más elegante, pero….. ¿Qué pasa con la capa de datos? ¿Dónde está esa figura de DBA involucrado en tareas de definición de los planes de capacidad y escalabilidad, tunning de la base de datos, planes de recuperación, y un largo etc.?

Pues la verdad es que casi nunca está, y como conclusión el sistema una vez desplegado llega un momento en que el sistema empieza a decaer y nadie sabe por qué.

 En la guía de operaciones de BizTalk se muestran varios trucos para mitigar esos problemas, cosas relacionadas con la planificación de la carga de mensajes (A más mensajes necesitaremos más bases de datos MessageBox en cluster), configuración de los jobs de tracking y purgado, y sobre todo un par de capítulos que hablan sobre consideraciones para la planificación de la capa de datos para mejorar el rendimiento, alta disponibilidad y testing.

A veces son cosas tan básicas como crear un cluster de base de datos activo-activo y simplemente separar las instancias de la Messagebox del resto de bases de datos del sistema, ya que es la base de datos que mayor actividad tiene en acciones de lectura-escritura porque todo el motor de publicación y suscripción de mensajes se apoya en esta base de datos. Y otras no tan básicas como definir el plan de backup y la configuración de los jobs y settings del sistema para que todo ruede mucho más fino.

06
Jun
08

Por qué sigue siendo tan dificil

Hace no muy poco estuve involucrado en una prueba de concepto en la que había que integrar diferentes aplicaciones, plataformas y servicios.
El escenario consistía básicamente, en realizar un sistema ESB (Enterprise Service Bus) que integrara una aplicación hecha en java a través de los servicios de mensajería de JMS  y todo corriendo en un Linux,  con una base de datos Oracle montada en una máquina Solaris y una serie de servicios Windows desarrollados tanto en .Net como en COM.  
El sistema ESB lógicamente estaba implementado mediante los servicios de mensajería y flujos de proceso de BizTalk Server.     ¡Todo un catálogo de tecnologías, eh!
La integración con los servicios Windows ya fueran COM o .Net fue sencilla, ya que al tratarse todo tecnología Microsoft no tenía por qué haber ningún problema, aunque bueno ya sabemos que de vez en cuando aparece algún que otro expediente “X” cuando interop anda por medio.

En cuanto a la base de datos lo primero fue pensar…… pues oye, ya lo hemos hecho miles de veces! Pero bueno ya que acaba de salir el “BizTalk Adapter Pack” (paquete de adaptadores Line-of-business implementados bajo la tecnología WCF) pues vamos a usarlo. Y ahí es cuando empiezan los problemas, Instálate el adaptador, descárgate el cliente Oracle adecuado, que si la conexión me da problemas solo porque la otra máquina es un Solaris, etc. etc. En fin, que hasta que afinas……

Pero con lo que sí sufrimos fue con la integración con la parte java. Como era requisito no hacer uso de servicios web sino conectarse mediante servicios de mensajería JMS pues implementamos un sistema de colas mediante Jboss. BizTalk no tiene ningún adaptador por defecto para integración mediante ese tipo de protocolo, por lo que tuvimos que recurrir a un partner especializado (no voy a decir el nombre eh!) La teoría es fácil, instalas un adaptador lo configuras y a correr, pero el problema viene cuando al más mínimo detalle de configuración no deseada empiezan a caerse tus conectores (lo que llamamos Receive Locations y Send Ports). En el visor de eventos te empiezan a aparecer errores encapsulados por lo que es difícil diagnosticar, y un largo etc.

Yo me pregunto, Por qué en una era tecnológica, en la que estamos acostumbrados a hablar de SOA, integración de aplicaciones, de facilidad de interconexión, etc. Al final siguen apareciendo los mismos problemas que hace 10 años cuando empezaban a aparecer las páginas asp, y componentes activeX.

Es cierto que las nuevas plataformas nos lo ponen todo mucho más fácil, no pongo en duda el beneficio de WCF, WWF, LinQ, Applications Blocks, patrones de diseño, BizTalk y sus adaptadores, sin ello tendríamos que estar continuamente reinventando la rueda, y dedicando mucho de nuestro tiempo a desarrollar funcionalidades tecnológicas comunes o incluso no habríamos salido del Ensamblador.

En mi opinión, en nuestro día a día deberíamos trabajar para hacer las cosas más fáciles y finalmente llegar a ese mundo SOA en el que todas las plataformas y tecnologías sepan hablar unas con otras sin tener que perder tanto tiempo en solucionar los problemas de configuración para la interconexión y dedicar más de nuestro esfuerzo en los problemas reales de negocio.

 

 

 

 

05
Jun
08

Tech-ed 2008 – Oslo a la vista

Ayer comenzó el Tech-ed 2008 en US, y tanto en la sesión de apertura de Bill Gates como en la presentación “Microsoft’s vision and strategy for Connected Systems”  de Oliver Sharp  se anunció que habrá un CTP (Comunity Technology Preview) público con algunos de los pilares de OSLO en el PDC de este otoño, Probablemente no sea mucho pero…. ¡Son buenas noticias para quien quiera empezar a trastear con ello!

Si aun no sabes lo que es OSLO, Eduardo Azanza en su blog Camino a Oslo nos habla de las características principales de esta estrategia SOA que está adoptando Microsoft.

 

04
Jun
08

Sesiones webcast en español

En este mes se van a celebrar un par de webcast  en español (Sesiones on-line para quien no las conozca) sobre BizTalk Server  2006 R2, bueno en concreto sobre la última versión del paquete de adaptadores empresariales (Line of Business) que se liberó …. Hace un mes prácticamente.

El “BizTalk Adapter Pack” es como os estaba diciendo un paquete de adaptadores “Line-of-business” bajo la plataforma Windows Communication Foundation que incluye tres adaptadores específicos para integración con Oracle, SAP y Siebel

El primero de los webcast, que se celebrará el día 10, hablará sobre la integración con bases de datos Oracle haciendo uso de este adaptador ¡Claro!. Mientras que el segundo, que tendrá lugar el día 27, tratará de los beneficios del uso de este tipo de adaptadores para la integración con SAP.

Si en tu negocio tienes estas necesidades de integración anímate y regístrate en: