Volver

Entendiendo las Entidades Biztalk

Capítulo traducido desde el ebook online Biztalk Unleashed que está en http://book.itzero.com/read/microsoft/0505/sams.microsoft.biztalk.server.2004.unleashed.nov.2004.ebook-lib_html/0672325985/toc.html
por Hernaldo González C. - Development Team Leader
http://darknromhacking.com
hernaldog@gmail.com
(* Notas del traductor)



Desde la perspectiva de un administrador, una solución BizTalk Server tiene muchos tipos de entidades manejables, cada uno con sus propias propiedades y capacidades. Para manejar sus propiedades, es importante entender como esas diferentes entidades se relacionan.

Un Servidor BizTalk es un computador físico que tiene instalado el software BizTalk Server 2004. Es también la entidad en el cual los host y las instancias host son creadas y configuradas.

Un BizTalk Server Group (Grupo de Servidores Biztalk) actúa como un contenedor de varios servidores BizTalk. Cada BizTalk server group tiene una sola Base de datos BizTalk Management que es compartida por los servidores en ese grupo.

Durante la creación de un nuevo Servidor BizTalk, puedes agregarla a un BizTalk server group
existente o crear uno nuevo. Si creas un nuevo BizTalk server group, una Base de datos Management siempre será creada. Todos los Servidores BizTalk que se agrupan en un BizTalk server group comparten las siguientes bases de datos:

  • BizTalk Management database

  • Master MessageBox database
  • Tracking database
  • Tracking Analysis (OLAP) database
  • BAM (Business Activity Monitoring) database
  • Rule Engine database


  • Un host es un contendor de otras entidades BizTalk, incluyendo orquestaciones, objetos de recepción y de envío. Así, un host puede ser configurado para realizar actividades como recibir, procesar y enviar mensajes. Existen 2 tipos de host:

  • In-Process host: Este tipo de host corre dentro del espacio de memoria del servicio de BizTalk. Los adaptadores File, SMTP, FTP y SQL corren en este tipo de host. Un In-Process host puede ser usado para recibir mensajes, enviar mensajes y procesar orquestaciones.
  • Isolated host: Como el nombre sugiere (*host aislado), este tipo de host corre dentro de su propio espacio de memoria, lo que significa que es creado un proceso por separado donde corre el host. Un buen ejemplo son los adaptadores SOAP y HTTP. Esos adaptadores corren bajo su propio worker process (W3P.exe) creado por IIS. BizTalk Service no controla este tipo de host. Un isolated host puede ser usado para recibir y enviar mensajes, pero no para para procesar mensajes en orquestaciones.

    Si un escenario requiere un alto performance, es bueno crear diferentes host para recibir, procesar o enviar mensajes. Dedicando un host para cada una de esas 3 actividades y esencialmente desacoplando sus work queues (*más abajo se ve este tema), así se ayuda a BizTalk ya que se particiona el trabajo. Este tópico es explorado en mayor detalle en el siguiente capítulo.

    Adicionalmente, puede ser útil crear múltiples host con la idea de configurar los límites de diferentes aspectos como la seguridad. Diferentes hosts pueden correr bajo diferentes contextos de seguridad, lo que puede ser muy útil cuando una solución BizTalk interactúa con mensajes de agentes o empresas externas.

    Un instancia host es el servicio BizTalk que en ese momento corre en un máquina física con BizTalk server. Este servicio consta de los servicios XLANG, MSMQT, TDDS y BizTalk Messaging Service. Estos subservicios no son visibles para el administrador. La instalación de BizTalk Server 2004 por defecto crea un Servicio BizTalk (BizTalk Server Application BTSNTSvcs.exe).

    Debes considerar las siguientes aspectos cuando bayas a crear un host e instancias host:

  • Un Servidor BizTalk puede tener múltiples hosts.

  • Un host puede tener múltiples instancias hosts.

  • El hecho de mapear un host a BizTalk Server se crea una instancia host.

  • Un host puede ser mapeado a uno o mas BizTalk Servers.
  • Un host puede registrar solo una instancia host de un servidor específico.


  • Una receive location es un punto de comunicación que es usado como una dirección para los mensajes entrantes. Si un receive location está desactivado (*se refiere a que biztalk lo desactiva, ya que uno manualmente lo puede igualmente desactivar), BizTalk Server no recibirá ningún mensaje por esa ubicación, lo que causa una situación de server down (*no anda el servidor). Hay varias razones por las cuales Biztalk puede desactivar un receive location, como una URL inválida, un fallo en el conexión de red, un inválido username/password, etc.

    Un send port es un punto de comunicación que es usado para transmitir mensajes de salida. La send location es usada como dirección de todos los mensajes de salida de diferentes transportes, como de los adaptadores File, MSMQT, SQL, SMTP, FTP o algún adaptador personalizado.

    Un send port group es un colección de send ports usados para enviar mensajes a múltiples destinos.

    Un adaptador es una pieza personalizada de envío de mensaje (*un middleware) que intercambia mensajes con un sistema externo a BizTalk. Los Adaptadores pueden ser categorizados en estos 3 tipos:

  • Transport adapters (Adaptadores de Transporte): Estos adaptadores implementan protocolos de transporte para recibir y enviar mensajes. BizTalk Server 2004 provee adaptadores out-of-the-box (*llegar y correr, sin instalar) para 6 protocolos de transporte: FILE, SMTP, HTTP, SOAP, FTP y BizTalk Server Message Queuing.
  • Estos adaptadores son conocidos como adaptadores nativos ya que vienen como parte de la instalación de BizTalk Server 2004.
  • Application adapters (Adaptadores de Aplicación): Estos adaptadores son usados para el intercambio de mensajes con sistemas o aplicaciones como SAP y Siebel.
  • Database adapters (Adaptadores de Base de Datos): Estos adaptadores son usados para conectar varias bases de datos como una SQL Server, Oracle o DB2 como origen o destino para los mensajes. BizTalk Server 2004 viene por defecto con un adaptador para SQL Server.


  • Un receive handler maneja los mensajes de entrada y es básicamente el que mapea entre los hosts y los receive locations. Un receive handler es también usado para configurar propiedades generales para todos los receive locations que están bajo ese handler. Esas propiedades globales pueden ser sobrescritas por un receive location específico.

    Un ejemplo son las configuraciones de un firewall de un receive handler FTP, el cual por defecto, está con las mismas propiedades que todos FTP receive locations. Las propiedades pueden ser sobrescritas cuando creas un receive location FTP específico.

    Puedes tener más de un receive handler por cada adaptador de cada BizTalk server group. Tener varios receive handlers por adaptador es útil para lograr los siguiente:

  • Límites de Seguridad: Ayuda a decidir si debes tener una seguridad más rigurosa para los recibos de mensajes del mundo externo. Esto puede ser realizado en parte agregando un segundo receive handler para el adaptador requerido. Este receive handler puede ser mapeado a un host con seguridad alta.

  • Necesidad de Alto Performance: Algunas veces, deberás tener un SLA (Service Level Agreement) en el proceso de todos los mensajes. En tal situación puedes crear receive handlers con hosts dedicados.

    Un send handler maneja los mensajes de salida y es básicamente el mapeo entre los host y los send ports. Tal como el receive handler, un send handler puede ser usado para configurar propiedades globales de todos los send ports bajo ese handler. Esas propiedades globales pueden ser sobrescritas por un send port específico.

    No puedes agregar mas de un send handler por BizTalk server group por cada adaptador. La escabilidad en el lado del envío puede ser alcanzada agregando más BizTalk servers.

    Un ejemplo es configurar las propiedades proxy para el nivel HTTP del send handler, el cual por defecto tiene las mismas propiedades para todos send ports HTTPs. Las propiedades pueden ser sobrescritas cuando creas un send port HTTP específico.

    Una orquestación es un proceso de negocio ejecutable que usualmente incluye el intercambio de mensajes con entidades de fuera de BizTalk server. Así, una orquestación es a menudo conocida como "procesador de mensajes" desde el punto de vista del administrador.

    Varias Bases de Datos de BizTalk Server son instaladas por defecto durante la instalación de BizTalk Server 2004:

  • BizTalk Management database: Esta base de datos guarda información de diferentes artefactos como orquestaciones, receive locations, send ports, party, etc.
  • BizTalk Tracking database: Esta base de datos guarda todo el negocio y información relacionada con los mensajes que fluyen a través de BizTalk.

  • Tracking Analysis database: Esta base de datos contiene el monitoreo de Health y Business de los cubos OLAP.

  • Enterprise Single-Sign On database: Esta es un servidor de credenciales que guarda toda la información acerca de receive y send locations con seguridad usando una clave maestra (*master-secret key).

  • Business Rule Engine database: Esta base de datos actúa como un repositorio del vocabulario, reglas y políticas.

  • BAM Primary database: Esta base de datos colecciona todos los datos de rastreo (*tracking data) requerido por el Monitoreo de Actividad de Negocio (*Business Activity Monitoring).

  • BAM StarSchema database: Esta base de datos contiene tablas de escenas, medidas, y dimensiones.

  • BAM Analysis database: Esta base de datos contiene los cubos OLAP para análisis online y offline. Esta base de datos es creada bajo Analysis Services.

  • BizTalk HWS Administration database: Esta base de datos contiene toda la administración relacionada a los Human WorkFlow Services.

  • BizTalk EDI database: Esta base de datos guarda el rastreo EDI y datos de procesamiento.

  • Trading Partner Management database: Esta guarda meta información de los Business Activity Services.

    Los MessageBox son el corazón de BizTalk. Estos guardan todos los mensajes y suscripciones a esos mensajes. Los MessageBox también contienen información acerca de las orquestaciones ejecutadas durante el procesos de deshidratación (dehydration process).

    Durante la instalación de BizTalk Server 2004, un MessageBox es creado y que es conocido como el Master MessageBox. Este mantiene todas las suscripciones para todos los mensajes. Cada BizTalk server group puede tener solo un Master MessageBox, pero puedes tener cero o mas MessageBoxes adicionales para mejorar el rendimiento del procesamiento. BizTalk suporta sobre 5 MessageBoxes (incluyendo el Master MessageBox) para un BizTalk server group dado.


    TIPS

    En escenarios donde se necesite un alto performance, puede ser bueno tener un Master MessageBox dedicado que no realice ningún procesamiento de mensajes; esto se puede hacer deshabilitando la publicación de mensajes en la Master MessageBox. En este caso, la Master MessageBox mantiene solo las suscripciones y no participará en el procesamiento de mensajes.

    Los MessageBox mantienen diferentes colas de mensajes:

  • Work Queue: Esta cola es donde los work items (mensajes) esperan ser procesados. Durante la instalación, BizTalk Server crea 2 work queues, una para cada host, llamadas BiztalkServerApplicationQ y BizTalkServerIsolationQ. Si agregas un nuevo Host, BizTalk creará una nueva work queue. Todos los work items serán encolados y desencolados en el MessageBox por todos los HostInstances de los host, el cual es configurado en un receive port/send port.

  • Suspended Queue: Esta cola mantiene work items (mensajes) que no serán procesados por BizTalk Server. Los Mensajes pueden terminar en una cola de suspendidos (suspended queue) por varias razones como fallas en el pipeline o problemas en el send port. Esta cola guarda esos work items hasta que sean reprocesados o borrados manualmente usando la herramienta Health Activity Tracking.

    Hasta ahora hemos discutido acerca de las diferentes entidades manejables de BizTalk Server. Ahora hablaremos acerca de las diferentes tareas administrativas que son realizadas sobre estas entidades.


    **Traducido el 06/07/2007. Dudas o comentarios a hernaldog@gmail.com.



    Volver

    2003-2011