1.d) Message Translator

En muchos casos, las soluciones de integración rutean mensajes entre aplicaciones muy diferentes. Algunas son aplicaciones internas, otras externas, otras legadas. Cada una de estas aplicaciones tiene su propio modelo de datos, por ejemplo, cada una de ellas puede tener una forma diferente de representar a un Cliente, sus atributos o las relaciones con otras entidades. Este modelo de datos, normalmente guía a la representación física en la base de datos y, lógicamente, a las interfaces de conexión que ofrecen.

Inclusive cuando las interfaces de conectividad que un sistema ofrece no responde a la representación interna de los datos, esta representación normalmente está de acuerdo con estándares de la industria, lo cual puede no ser útil para la interacción necesaria, o, de manera contraria, es necesario llevar una representación interna al estándar para crear la solución de integración.

¿Cómo pueden sistemas utilizando diferentes formatos de datos, comunicarse utilizando mensajería?

Usando un filtro especial, un Message Translator que traduce un formato de datos a otro.

Implementación en Biztalk Server

Las transformaciones de mensajes en Biztalk Server se realizan a través de “mapas” que expresan estas transformaciones en XSLT. Para ésto, toma en cuenta que todo mensaje que circula por la plataforma tiene una definición en un esquema XSD.

En BizTalk Server tenemos dos tiempos de análisis para estas transformaciones:

a) En tiempo de diseño, la herramienta BizTalk Mapper, que se integra con Visual Studio, nos permite de manera visual crear todo tipo de transformaciones entre un esquema de mensaje y otro.

b) En tiempo de ejecución, los mapas definidos y “compilados” en transformaciones XSLT, pueden ubicarse en diferentes puntos de la solución de integración para que ejecuten la transformación

Los lugares donde pueden ejecutarse estas transformaciones son:

1) En un puerto de entrada: en este caso, la transformación se podrá realizar una vez que el mensaje pasó el pipeline de entrada, de esta manera se asegura que el mismo viene en un formato Xml que BizTalk pueda reconocer.

2) En un puerto de salida: en este caso la transformación se podrá realizar previo al pipeline de salida, para asegurar que el mensaje no se haya cambiado a un formato que no sea reconocible.

3) En una orquestación mediante el elemento de Transform que permite cambiar el formato de un mensaje aplicando una transformación conocida.

4) Manualmente, en un componente utilizando las primitivas de BizTalk. Aunque esta opción no es muy utilizada, existe la posibilidad y en ciertos escenarios específicos puede ofrecer algún tipo de ventajas.

Algunas particularidades adicionales:

- Las transformaciones pueden enriquecerse con un gran conjunto de “functoides” disponibles para realizar operaciones típicas de manera simple.

- También pueden utilizarse componentes nativos .NET dentro de las mismas.

- Cuando se utilizan en los pipelines de entrada y salida, pueden indicarse varios mapas para un canal, y BizTalk automáticamente aplica el mapa adecuado al tipo de mensaje que atraviesa el mismo.

- Cuando se utiliza en orquestaciones, puede utilizarse más de un mensaje de entrada para formar un mensaje de salida.

1.c) Pipes and Filters

En los escenarios de integración, la llegada de un mensaje puede disparar la ejecución de un conjunto de pasos de procesamiento, donde cada paso realiza una función específica. Por ejemplo, supongamos que el ordenes de venta deja un mensaje en nuestro sistema de mensajería. Un requerimiento podría ser que el mensaje esté encriptado, otro requerimiento es que tenga autenticación basada en un certificado digital, un último requerimiento podría ser que el mensaje cumpla con el formato establecido para ser aceptado.

Para cumplir con todos estos requerimientos, tenemos que transformar el stream de los mensajes encriptados y con información de autenticación, que pueden venir en formatos no aceptables, en un stream de mensajes simples con capacidad de ser procesados por el sistema de mensajería para llevarlo a los sistemas destino (potencialmente con la necesidad de aplicar el mismo esquema de procesamiento previo al envío)

¿Cómo podemos realizar un procesamiento complejo del mensaje manteniendo independencia y flexibilidad?

Usamos el estilo de arquitectura de Pipes and Filters para dividir la tarea compleja de procesamiento en una secuencia de pasos de procesamientos pequeños e independientes (Filters) que se conecan por canales (Pipes).

Cada filtro expone una interfaz simple: recibe los mensajes en el pipe de entrada, procesa el mensaje y publica los resultados en el pipe de salida. El pipe conecta un filtro al siguiente, enviando los mensajes de salida de un filtro al otro. Dado que todos los componentes utilizan la misma interfaz externa, pueden ser compuestos en diferentes soluciones conectando los diferentes componentes a los diferentes pipes. Se pueden agregar nuevos filtros, omitir existentes o re-acomodarlos en nuevas secuencias.

Implementación en Biztalk Server

Biztalk Server implementa en sus “pipelines” de entrada y salida, el patrón de Pipes and Filters. Los pipelines de entrada BizTalk procesan los mensajes cuando entran y los pipelines de salida BizTalk procesan los mensajes a la salida. Cada pipeline consiste en una secuencia de transformaciones que pueden personalizarse, tanto en los componentes de transformación de la secuencia (lo que se denominan “pipeline components”) como en la personalización de los propios componentes (dado que se pueden construir “pipeline components” custom).

BizTalk define “etapas” en el pipeline de entrada y de salida, sin embargo, estas etapas pueden tener más de un componente cada una. Las etapas dan un marco conceptual al tipo de transformación que el mensaje debería recibir en cada una de ellas.

En el pipeline de entrada, estas etapas son:

• Decode: usada para decodificar los mensajes. Un ejemplo de uso es para los mensajes codificados con MIME o la desencriptación
• Disassemble: usado para normalizar los mensajes que llegan en un formato diferente al XML que pued ser reconocido por BizTalk a un formato aceptable. Un ejemplo son los mensajes que llegan en formato de archivo plano.
• Validate: que se utiliza para validar un documento contra un conjunto de esquemas posibles. Esto permite “interceptar” documentos que llegan por el canal y no son adecuados para ser procesados por el mismo.
• Resolve party: Verifica que el mensaje ha sido enviado por una fuente conocida y lo asocia a esa fuente en el registro “parties” de BizTalk.

En el pipeline de salida las etapas son:

• Pre-Assemble: permite realizar procesamiento del mensaje antes de ser ensamblado para su envío. Por ejemplo, puede validarse el XML de acuerdo a esquemas.
• Assemble: ensambla el documento XML BizTalk en un XML, archivo plano u otro formato necesario de salida.
• Encode: se utiliza para codificar y firmar digitalmente el mensaje en la salida.

Naturalmente, decodificar el mensaje es el primer paso que se realiza en el receive pipeline y codificarlo es el último paso en el pipeline de salida.

Este diseño asegura que todo el resto de los filtros en el pipeline pueden trabajar en mensajes que no están codificados.

BizTalk Server provee pipelines por defecto para usos frecuentes como “pass-through” que no realizan ningún procesamiento en el pipeline y los que realizan parsing en mensajes Xml.

1.b) Message

Dos aplicaciones se comunican via mensajería usando Message Channel que las conectan.

¿Cómo dos aplicaciones conectadas por Message Channel intercambian información ?

Empaquetan la información en un Message (mensaje) que es un conjunto de datos que pueden ser transmitidos por un Message Channel.

Dado que los dos sistemas conectados tienen su propio espacio de procesamiento y memoria, para que la información que está en uno llegue al otro, debe transmitirse. Esta transmisión normalmente se realiza como streams de datos, por lo que el proceso inicial debe serializar la información en un formato adecuado para la transmisión y el receptor debe de-serializarla para obtener la información original.

Se necesita entonces una manera simple de empaquetar los datos del origen y que el destino de una manera simple pueda desempaquetarla de manera que sea apropiada para transmitirla por el Message Channel sin esfuerzos adicionales.

Un mensaje consiste de dos partes:

• Header: Información que describe los datos que están siendo enviados.
• Body: La información que se está enviando

Para el sistema de mensajería, todos los mensajes son iguales desde el punto de vista del manejo del mismo. Sin embargo para la aplicación sobre el sistema de mensajería hay diferentes tipos de mensaje. Cómo se tipifica el mensaje en cada sistema de mensajería corresponde a la implementación del mismo.

Implementación en Biztalk Server

Toda interacción con información en Biztalk Server es por y a través de Mensajes (Message). No puede definirse ningun flujo de datos que no corresponda a un tipo de mensaje.

El Message en Biztalk Server tiene las siguientes características:

• Su serialización y representación interna siempre es en Xml
• La tipificación se realiza en base a definiciones en esquemas xml, representados en Xsd y tiene un diseñador específico
• El Header contiene información de contexto de Biztalk y puede ser extendido
• El Body contiene la información a trasmitir y se describe en el xsd

Como puede verse en la figura encima, el editor de esquemas de Biztalk nos permite definir los tipos de mensaje que utilizaremos en nuestras soluciones de integración.

Este editor nos permite describir en detalle las características del mensaje y, al estar definido en Xsd, podemos incorporarle un conjunto de reglas y características al mismo como parte de su descripción.

Nota: aún cuando para Biztalk Server todo tiene que ser un mensaje con tipo, esto no implica que los sistemas origen/destino deban conocer y respetar el formato que entiende Biztalk Server para poder comunicarse con la plataforma de mensajería. Tanto la infraestructura de Pipes and Filter los Chanel Adapters y la posibilidad de utilizar Message Translator para los mensajes nos da la posibilidad de abstraer en el sistema origen el formato del mensaje.

1- Sistemas de Mensajería

Los patrones a describir dentro de esta sección son los pilares de la infraestructura de integración y el propósito de describir algunos aquí es asociarlos a la implementación en Biztalk Server.

1.a) Message Channel

Existe una integración entre dos aplicaciones que necesitan comunicarse y está implementado por mensajería.

¿Cómo una aplicación se comunica con  la otra utilizando mensajería?

Se conectan las aplicaciones utilizando un Message Channel donde una aplicación envía información al canal y otra lee información del canal.

Las aplicaciones no envían simplemente mensajes al sistema de mensajería de manera descoordinada mientras otras aplicaciones reciben todos los mensajes de manera aleatoria, esto sería una forma muy ineficiente de operar. De esta manera, las aplicaciones que envían información saben qué tipo de información es y las aplicaciones que reciben, también saben qué tipo de información van a buscar.

Cuando una aplicación envía un mensaje  no lo envía directamente al sistema de mensajería sino que lo hace en un Message Channel particular, de la misma manera, la aplicación que recibe un mensaje lo recibe de un Message Channel  particular.

La aplicación que envía no tiene por qué saber qué aplicación recibirá la información pero se asegura por el sistema de mensajería, que la aplicación que lo recibe está interesada en la información.

Implementación en Biztalk Server

Los puntos de conexión de las aplicaciones con Biztalk Server son los puertos. En particular para la definición de un Message Channel como un punto de conexión “lógico” cuya implementación depende de la instalación, es lo más cercano al mismo.

En lo que hace a la definición de lo que son puertos “físicos” de Biztalk (que podemos ver y definir en la interfaz de administración como se ve encima) en el caso de los “Receive Ports” que no definen el Channel Adapter la definición es clara, pues solamente se especifica un punto de entrada que luego puede conectarse de diferentes maneras e incluso con diferentes y varios adaptadores. En el caso de los Send Ports definidos, esta línea es más borrosa pues en el mismo puerto debe definirse el adaptador.

En la interfaz de la orquestación, tenemos acceso a definir “puertos lógicos” sin especificar su implementación física.

Estos puertos luego podrán ser “conectados” (binding) a puertos físicos, y son la implementación estricta de lo que sería un Message Channel. En la ilustración encima tenemos en los Port Surface dos puertos lógicos (Message Channels) de una orquestación que recibirá mensajes de una aplicación y lo enviará a otra/s aplicaciones interesadas en los mismos.

Un acercamiento adicional, los Send Port Groups como Message Channel

Conversando con mi amigo Cristofer luego de publicar este post, me refirió a la inclusión de la orquestación como innecesaria para ilustrar el concepto del Message Channel en Biztalk.

Entendiendo su concern con respecto al tema, no solamente por la realidad de poder explicarlo de otra manera sino por la peligrosidad de asociar un concepto a una implementación en orquestaciones, cuando normalmente favorecemos procesamiento “sin orquestación” en todos los casos en que es posible y no incorporamos lógica de  negocios por la mayor velocidad y escalabilidad que logramos en las soluciones.

Así es que, sin quitar lo que hemos visto hasta ahora, puedo explicitar algunos temas que hacen más compleja la visión pero la acercan a la implementación concreta.

En primer lugar, los puertos que hemos visto en el diseñador de orquestaciones, tienen la capacidad de poder ser lógicos y luego ser conectados a puertos físicos, con lo que serían fieles a la descripción que hemos hecho de Message Channel sin embargo, existe la posibilidad de indicar físicamente los puertos en la creación en la propia herramienta, esto hará que en el momento de la publicación se creen, pero igualmente la separación entre el Message Channel y el Channel Adapter se rompe para beneficiar la conveniencia del que está configurando la solución, pero es un escenario que quería evitar y por eso incluí la orquestación y, en rigor, también podría dejarla fuera.

En cuanto a los Send Port Groups, en BizTalk el Send Port Group es una unidad lógica que permite agrupar diferentes Send Port de manera que en la configuración de la solución, el uso de un “Send Port Group” nos acercaría a la definición más ajustada del Message Channel para la salida, dado que no contiene más que la información necesaria para que la aplicación envíe el mensaje en este “Send Port Group” sin necesidad de informar el Channel Adapter que conectará a la aplicación destino.

Si bien esto complementa y permite explicar el patrón sin utilizar orquestaciones, continúo dejando el otro ejemplo pues el uso del Send Port Group es opcional y no mandatorio. El problema principal radica en que la implementación de los puertos de salida con respecto a los puertos de entrada en BizTalk no es simétrica, el uso opcional y la no inclusión de mapas en el Send Port Group y si en el Receive Port son solamente un par. Yo desearía que la implementación hubiera sido simétrica pero me imagino (o quiero imaginar ) que existe una buena razón para que así sea.

Hace un tiempo que no escribo sobre Biztalk, la verdad que a propósito, dado que las señales sobre la continuidad eran, por decirlo de alguna manera: “confusas”.

Pero bueno, sin una opción diferente para un gran conjunto de escenarios para cubrir con la plataforma y la versión 2010 ya en Beta, estoy armando una presentación para el próximo 26 de Agosto Ver aquí

Y para que no quede simplemente en la presentación, y luego de buscar material, pensé que era importante y valía la pena volver al blog con el tema de la presentación, de manera de forzarme a ser ordenado y metódico en la preparación.

Motivación

El libro referente sobre patrones de integración es Enterprise Integration Patterns pero el mismo hace referencia a los patrones genéricamente y sin experiencia suficiente, a veces se hace difícil distinguir los mismos en un producto como Biztalk Server.

De esta manera, vale la pena repasar algunos de los patrones más relevantes y cómo ellos ya se encuentran implementados en Biztalk Server o cómo pueden implementarse fácilmente.

Aviso importante

Éste y los siguientes blogs acerca del tema no pretenden presentar nuevos conceptos, de hecho gran parte de los mismos estarán referenciados aquí en español simplemente como manera de asegurar que el vocabulario a utilizar sea homogéneo y signifique lo mismo para todos los que interactuemos.

El valor que pretendo agregar es que sobre un vocabulario “conocido y aceptado”(tanto en lo básico como en los patrones de integración)  construyamos ejemplos en Biztalk Server que nos ayuden en futuras implementaciones de integración.

Otra aclaración super pertinente es que la presente serie de publicaciones, solamente considera la funcionalidad de BizTalk server sin considerar la funcionalidad que agrega el Biztalk ESB Toolkit. Existen patrones que podrían asociarse más claramente utilizando esa funcionalidad e, inclusive, algunos patrones que solamente es interesante explicarlos utilizando su funcionalidad, por lo que quizá quede para otra serie de patrones a analizar y la revisión de los que en esta serie haga.

Estilo de Integración

Existen varias formas de acercarse a los problemas de integración que, considerando ciertas características se resumen en estilos. En particular, el estilo de integración que nos interesa cuando hablamos de Biztalk Server es el estilo de Mensajería.

El estilo de integración basado en Mensajería, nos permite integrar múltiples aplicaciones intercambiando paquetes de datos de manera frecuente, inmediata, de manera confiable y asincrónicamente usando formatos personalizables.

El asincronismo de la mensajería es un resultado lógico de integrar sistemas distribuidos, dado que enviar un mensaje no requiere que los dos sistemas  conectados estén disponibles en el mismo momento. Además, ver la comunicación de manera asincrónica, fuerza a reconocer que la interacción con un sistema remoto es más lenta y que es mejor diseñar componentes con una alta cohesión y bajo acoplamiento.

Conceptos básicos de mensajería

Para poder avanzar en los patrones, debemos concordar en la semántica de los conceptos básicos que estaremos utilizando.

Channels (Canales)– Las aplicaciones de mensajería transmiten datos sobre un Message Channel una tubería virtual que conecta al que envía con el que recibe.

Messages (Mensajes) – Un Mensaje es un paquete de datos que puede ser transmitido en un canal.  La aplicación que envía debe empaquetar cada paquete de datos en un mensaje y enviar el mensaje en un canal. La aplicación que receptora recibe un mensaje y debe extraer los datos del mensaje para procesarlos. El sistema de mensajería se encarga de entregar el mensaje que recibe del que envía al que recibe.

Multi-step delivery (Envío de múltiples pasos) – En el caso más simple, el sistema de mensajería entrega el mensaje directamente del que envía al que recibe. Sin embargo, muchas veces es necesario realizar acciones luego que el mensaje ha sido enviado por el origen pero antes que sea recibido por el destino final. Por ejemplo, el mensaje puede tener que ser validado o transformado. La arquitectura de Pipes and Filters describe como un procesamiento en pasos puede ser encadenado usando channels (canales).

Routing (Ruteo) – En muchas organizaciones, un mensaje debe pasar por varios canales antes de llegar a su destino final. La ruta que un mensaje debe seguir puede ser tan compleja que el que envía originalmente el mensaje puede no conocer el canal por el cual el mensaje llegará al receptor final. En su lugar, el origen inicial envía el mensaje a un Message Router que es un componente de aplicación y filtro en la arquitecturaq de Pipes and Filters que determina como enviar el mensaje al receptor final..

Transformation (Transformación) Varias aplicaciones pueden necesitar diferentes representaciones para los mismos datos. El que envía da un formato al mensaje, aunque el destino puede esperar el mensaje en otro formato. Para ajustar estas diferencias, el mensaje debe ir por un Message Translator que convierta el mensaje de un formato a otro.
]]> http://gabrielcor.wordpress.com/2010/08/03/patrones-de-integracion-con-biztalk-server-2009-%e2%80%93-parte-1/feed/ 0 gabrielcor http://gabrielcor.wordpress.com/2009/06/18/plan-%e2%80%9csalve-los-ceibos%e2%80%9d/ http://gabrielcor.wordpress.com/2009/06/18/plan-%e2%80%9csalve-los-ceibos%e2%80%9d/#comments Thu, 18 Jun 2009 16:41:20 +0000 gabrielcor http://gabrielcor.wordpress.com/2009/06/18/plan-%e2%80%9csalve-los-ceibos%e2%80%9d ]]>

Mejor un lector de libros digitales por niño que una computadora verde con cuernos para cada uno.

Todos tendrían a tiempo y más económicos los libros de texto.

Y salvamos algunos árboles (capaz que no ceibos, pero otros).

Instalación: Respaldé todos mis datos, elegí instalación desde cero. Me pidió pocos datos y lo dejé comenzando a instalar. Me fui a dormir y cuando desperté estaba instalado y perfecto.

Se conectó a la red wifi y activó.

Instalé Office/Visual Studio/Live Mesh y Windows Live mucho más rápido que en veces anteriores.

La máquina responde más rápido, la interfaz es super intuitiva para quien venía usando Vista y la nueva Taskbar es maravillosa.

Totalmente recomendable

Mi máquina es un Acer Aspire 5100 con 2 GB Ram.

Luego de años y cientos de programas instalados, hoy tuve mi primer blue screen.

Eso no me molestó tanto, sino que al volver, Vista asumió que no tenía activada la copia y volvió a pedirla, pero al intentarlo me dio el error “Se superó el número máximo de secretos que se pueden guardar en un único sistema”. 0×80070565

En la línea de comandos (cmd.exe), probé con sfc /SCANNOW sin ningún éxito.

Bajé Dr.Web por algunas referencias a soluciones para problemas de este tipo (www.freedrweb.com) e hice un scan, encontró un malware, reboot, y volví a tener máquina.

Igualmente creo que ya es tiempo de reinstalar, así que el fin de semana probaré Windows 7 RC.

En realidad esta solución funciona para cualquier caso donde tenga que recibir un string y llevarlo a una orquestación donde el mensaje en el receive shape queramos que sea un string.

En el caso particular del adapter para MQSeries (o WebSphere MQ), de tipo cliente (que se instala con el CD de HIS), lo que recibo del adaptador es lo que está en el mensaje, con todos los datos de lo que sería el contexto del MQMessage en el contexto del mensaje Biztalk.

El problema es que si ingreso con un pipeline passthrough, Biztalk no procesará la suscripción, no entraré en detalles pero si les interesa lo que sucede se explica en el artículo de la Kb a continuación http://support.microsoft.com/kb/837860/en-us 

Una posible solución es usar un RawString para la entrada como se explica en esta entrada http://www.traceofthought.net/CommentView,guid,c5418f3d-2ea7-4530-ab9c-ae4c49154fcb.aspx el único tema con esto es que hay que hacer el deployment no solamente del ContextAdder (ContextAdder) , sino del RawString, y usarlo en la orquestación. Asumiendo que entienda el artículo y cómo hacerlo, no es una mala solución.

La otra solución es tener un ContextAdder que además de agregar al contexto la propiedad MessageType como se ve debajo al tipo string, agregue al string raw que viene, el xml <string></string> alrededor del string original que entra.

Aquí ContextAdderModificado subo la solución con un ContextAdder modificado que hace lo anterior.

Igualmente persiste, si necesitamos escribir WebSphere MQ via el MQSC Adapter la necesidad de usar un RawString por lo que en el mismo proyecto está incluida la clase RawString del SDK.

Hay una orquestación que asume que están los artefactos correctamente implementados para probar y recibe un string y envía un string (con una lógica de dominio que puede quitarse si quieren probarse strings simples).

Ya que estamos, comento un par de cosas importantes para interactuar con MQSC.

1) en el Receive, los siguientes parámetros son mandatorios: Channel Name, Queue y Queue Manager

2) en el Send los párámetros mandatorios son: Channel Name, Connection Name, Queue y Queue Manager

Si estos parámetros no están, los errores 2058 con una descripción como Reason code 2058 Failure encountered while attempting to open queue pueden sucederse sin que esto nos indique exactamente qué está sucediendo.

La guía para optimización de performance en Biztalk ha sido publicada aquí, y me tomé el tiempo para no solamente leerla sino hacer un resumen de la misma para poder tener de referencia y buscar esos puntos. Es una guía muy interesante y diría que es de lectura obligatoria para todo el que piense realizar serios proyectos con Biztalk. Sin embargo, tampoco lo veo como la "guía definitiva" para la performance en Biztalk, dado que la variedad de escenarios puede ser muy compleja, la profundidad con la que se tocan los temas es variada y muchas porciones están teñidas (para bien Y para mal) por la experiencia de los participantes en la confección de la guía.

La primer parte "Performance Factors", es una recorrida por diferentes puntos que pueden afectar a la solución. Es extremadamente complejo hacer algo que abarque todo, pero es de esperar al menos que sea una muestra representativa de problemas encontrados por los que lo elaboraron. En este sentido, debe tomarse como un muy buen punto de comienzo, pero deben ser incorporadas experiencias de otros expertos.

De la revisión de los diferentes factores, elaboré el cuadro debajo.

La segunda parte "Performance Tools" es una lista de las herramientas que normalmente uno podría usar con Biztalk. Incluye todas las herramientas que se deben tener a mano pero es únicamente una pequeña lista.

La tercera parte se enfoca en realizar un "Performance Assessment" a una instalación Biztalk y es un acercamiento más metodológico que técnico. La metodología es más que adecuada y se ve no solamente alienada con las metodologías que normalmente usamos con MCS sino que es coherente y realizable.

Reseño debajo algunos puntos destacables

• En las páginas 35 y 36 hay una buena guía para el scoping del proyecto.
• La página 37 tiene una lista de potenciales medidas a optimizar en el análisis de performance.
• La página 39 es muy interesante dado que en un cuadro tenemos algunas medidas de los posibles máximos de performance. Inclusive menciona la máxima performance de orquestaciones por segundo que la ubica en 1156 con la friolera de 23 Quad Processor Biztalk 2006
• Documentación de cómo separar las diferentes bases de datos en la página 52.

La cuarta parte se centra en encontrar y eliminar los cuellos de botella en Biztalk. A continuación un cuadro de recomendaciones generales

y de las de Biztalk específicamente

La quinta parte trata del testing de aplicaciones. Es un muy detallado análisis del uso de herramientas, aunque en mi criterio no forma parte de la guía como tal y en ese lugar, sino en otra guía o apéndice (aunque debo reconocer que suma hojas para que la guía se vea contundente   )

La última sección está estrictamente dedicada a la optimización de performance. Hasta ahora, la guía, realmente ha centrado su atención en evitar, encontrar y corregir problemas que afectan la performance. En esta sección, entra directamente en la búsqueda de performance máxima una vez determinada una infraestructura. Esto será parte de mi próxima entrada en el blog.