Consideraciones sobre mensajes
BizTalk Server proporciona un amplio conjunto de funcionalidades para enviar, recibir, transformar y procesar mensajes. Estas son algunas de las funcionalidades:
Capacidad de enviar y recibir mensajes mediante varios transportes estándar del sector, como HTTP, SMTP, FTP/FTPS y WCF. La compatibilidad de nivel de transporte para enviar y recibir mensajes se realiza mediante adaptadores de BizTalk Server. La integración de BizTalk Server procesamiento de mensajes con varias aplicaciones de "línea de negocio" (LOB) se realiza mediante uno de los muchos aceleradores o adaptadores de BizTalk Server disponibles, como el Acelerador de BizTalk para HIPAA, el Acelerador de BizTalk para SWIFT o el adaptador de SAP de BizTalk. Estos aceleradores y adaptadores se ajustan a los estándares del sector que, a su vez, admiten una integración sencilla de BizTalk Server con sistemas que se ajustan a un estándar específico del sector.
Capacidad de procesar varios formatos de mensaje, como texto sin formato, XML, binario y otros. Esta funcionalidad es fundamental para proporcionar integración de BizTalk Server con un amplio espectro de socios comerciales.
Compatibilidad con la transformación de mensajes o la asignación de documentos. La asignación admite la transformación de datos entre distintos esquemas. Por ejemplo, la asignación podría usarse para transformar el contenido de un pedido de compra de cliente recibido en un recibo con notificación de envío que se enviará al cliente.
BizTalk Server orquestaciones proporcionan funcionalidad para crear procesos empresariales que abarcan el tiempo, las organizaciones, las aplicaciones y las personas. BizTalk Server proporciona la interfaz gráfica orchestration Designer para desarrollar procesos empresariales que incluyen compatibilidad con transacciones (tanto el tipo MSDTC "atómico" tradicional como la larga duración), el control de excepciones, la depuración, el seguimiento y la extensibilidad para llamar a código externo.
Nota
Consulte Optimización del rendimiento de orquestación para obtener instrucciones sobre los procedimientos recomendados que se deben seguir al usar orquestaciones en BizTalk Server. Consulte el tema Creación de orquestaciones mediante Designer de orquestación (https://go.microsoft.com/fwlink/?LinkId=158997) en la documentación de BizTalk Server para obtener información detallada sobre el uso de Designer de orquestación.
En el resto de este tema se describen las consideraciones de rendimiento relacionadas con el tamaño, la complejidad y el perfil de distribución de los mensajes que se procesan en un entorno de BizTalk Server.
Consideraciones sobre el tamaño del mensaje
Aunque BizTalk Server no impone ninguna restricción en el tamaño del mensaje, los límites prácticos y las dependencias pueden requerir que minimice el tamaño de los mensajes porque los mensajes grandes requieren más recursos de procesamiento. A medida que aumenta el tamaño del mensaje, el rendimiento general (mensajes procesados por segundo) disminuye. Al diseñar el escenario y planear la capacidad, tenga en cuenta el tamaño medio del mensaje, el tipo de mensaje y el número de mensajes BizTalk Server procesos. No utilice nombres de atributos y etiquetas innecesariamente largos; Si es posible, mantenga la longitud por debajo de 50 caracteres. Por ejemplo, no use un nombre de etiqueta de 200 caracteres para un tamaño de mensaje de solo 1 byte.
Si el tamaño en memoria de un mensaje recibido supera el número de bytes especificados para el tamaño del fragmento de mensaje grande (configurable en la página Propiedades de grupo del grupo de BizTalk en la consola de administración de BizTalk Server), el mensaje se divide en fragmentos del tamaño especificado. Además, los fragmentos se escriben en el Cuadro de mensajes en el contexto de una transacción del Coordinador de transacciones distribuidas de Microsoft (MSDTC) como se indica a continuación:
Si el mensaje entrante se publica en el contexto de una transacción MSDTC existente, esta transacción se usa al escribir los fragmentos de mensaje en la base de datos de Cuadro de mensajes de BizTalk. Por ejemplo, si un adaptador transaccional está publicando el mensaje entrante para requerir transacciones, la transacción existente se usaría al escribir los fragmentos de mensaje en la base de datos messageBox.
Si el mensaje entrante no se publica en el contexto de una transacción MSDTC existente, se crea una nueva transacción MSDTC para escribir los fragmentos de mensaje en la base de datos messageBox. En este escenario, se aplican las siguientes consideraciones:
Aumente el valor de Tamaño de fragmento de mensaje grande para reducir la frecuencia con la que se fragmentan los mensajes grandes y reducir la incidencia de creación de las transacciones MSDTC asociadas. Esto es necesario porque un uso excesivo de transacciones MSDTC tiene un gran impacto sobre el rendimiento. Tenga en cuenta que, al aumentar este valor, se aumenta también la cantidad de memoria disponible que se utiliza.
Si tarda más tiempo que el tiempo de espera máximo permitido de transacción MSDTC de 60 minutos para escribir un mensaje en el Cuadro de mensajes, se agota el tiempo de espera de la transacción, se produce un error y se produce un error al intentar escribir el mensaje y se revierte. El valor de tamaño del fragmento de mensaje grande debe aumentarse lo suficiente para evitar este problema al procesar mensajes muy grandes. En función de la memoria disponible, este valor debe aumentarse hasta un máximo de 1.000.000 bytes.
Cada fragmento de mensaje en un mensaje crea uno o más bloqueos de base de datos SQL Server en la base de datos de cuadro de mensajes. Cuando el número de bloqueos supera varios cientos de miles, es posible que SQL Server generen errores de "bloqueo insuficiente". Si se produce este problema, aumente el valor de Tamaño de fragmento de mensaje grande para reducir el número de fragmentos (lo que disminuye el número de bloqueos de base de datos de SQL Server realizados en la base de datos de cuadro de mensajes) o considere la posibilidad de hospedar la base de datos de cuadro de mensajes en una versión de 64 bits de SQL Server. El número de bloqueos disponibles es significativamente mayor en la versión de 64 bits de SQL Server que en una versión de 32 bits de SQL Server. La fórmula siguiente se puede usar para calcular el número máximo de mensajes por intercambio cuando la base de datos messageBox se hospeda en una versión de 32 bits de SQL Server:
200,000 / (Number of CPUs * BatchSize * MessagingThreadPoolSize)
Para obtener más información sobre cómo BizTalk Server procesa mensajes grandes, incluidas las directrices para procesar mensajes grandes, vea How BizTalk Server Processes Large Messages (https://go.microsoft.com/fwlink/?LinkID=154680).
Consideraciones sobre el tipo de mensaje
Los mensajes se reciben en BizTalk Server en uno de los dos formatos principales: archivos XML o archivos planos. El tipo de mensaje siempre debe tenerse en cuenta en el perfil de distribución de mensajes debido a los distintos requisitos de recursos de los mensajes XML y de archivos planos.
Archivos XML Para que BizTalk Server realizar cualquier procesamiento en un mensaje distinto del enrutamiento de paso a través, el mensaje debe estar en el formato de archivo XML.
Archivos planos Los archivos planos deben analizarse en un formato XML antes de que BizTalk Server pueda realizar cualquier procesamiento que no sea el enrutamiento de paso a través. Al analizar un archivo sin formato en un archivo XML, el tamaño del archivo puede aumentar considerablemente. Los archivos sin formato no contienen etiquetas XML con información descriptiva acerca de sus datos. Por otro lado, los archivos XML ajustan todos sus datos en etiquetas XML descriptivas. En algunos escenarios, el análisis puede aumentar el tamaño de un archivo plano en un factor de 10 o más, dependiendo de la cantidad de datos descriptivos que contengan las etiquetas XML del archivo.
Documentos de archivos planos encapsulados en un único nodo de sección de CDATA en un documento XML Este tipo de documento es una combinación de XML y archivo plano, y a menudo consume mucha memoria, ya que BizTalk Server debe cargar todo el documento de archivo plano encapsulado en la memoria antes de procesarlo.
Consideraciones sobre sobrecargas
La mayoría de las aplicaciones BizTalk Server no reciben mensajes a una velocidad constante específica. Normalmente, el procesamiento de mensajes está sujeto a picos y valles. , por ejemplo, una aplicación de banca en línea puede procesar un mayor volumen de mensajes por primera vez por la mañana, luego durante el medio del día y al final del día. BizTalk Server soluciones deben probarse para asegurarse de que podrán controlar estos escenarios de sobrecarga. Para determinar qué tan bien una solución de BizTalk Server puede controlar escenarios de sobrecarga, se debe determinar el rendimiento máximo sostenible (MST) de la solución BizTalk Server. El MST es la carga más alta del tráfico de mensajes que un sistema puede controlar indefinidamente en un entorno de producción. Para obtener más información sobre MST, vea Planning for Sustained Performance (https://go.microsoft.com/fwlink/?LinkID=158065) and What Is Sustainable Performance? (https://go.microsoft.com/fwlink/?LinkID=132304) en la documentación de BizTalk Server.
Complejidad del esquema
El rendimiento del análisis de mensajes (especialmente el análisis de archivos planos) se ve afectado por la complejidad de los esquemas. A medida que aumenta la complejidad del esquema, el rendimiento general disminuye. Al diseñar esquemas, reduzca la longitud de los nombres de nodo y mueva las propiedades promocionadas a la parte superior del esquema. Esto reduce el tiempo de recuperación y, por tanto, aumenta el rendimiento.
Complejidad del mapa
En función de la complejidad de los mapas, la transformación del mapa puede consumir muchos recursos. A medida que aumenta la complejidad del mapa, el rendimiento general disminuye. Para mejorar el rendimiento general, minimice el número de vínculos y functoids usados en los mapas, especialmente functoids que llaman a recursos externos, como el functoid Búsqueda de base de datos.
Consideraciones de análisis de archivos planos
Los dos factores que tienen el mayor impacto en el rendimiento del análisis de archivos planos son el tamaño de archivo y la complejidad del esquema. Un esquema ambiguo es un esquema que contiene muchos campos opcionales. Cuando se usan tamaños de archivo grandes, un esquema con muchos campos opcionales puede degradar el rendimiento porque los archivos más grandes pueden coincidir con diferentes ramas del esquema. La complejidad del esquema tiene menos impacto en archivos más pequeños que en archivos más grandes.