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.