Procesamiento por lotes de mensajes para el procesamiento de envío

Gestión de lotes de envío del adaptador

Cuando se usan transacciones en el lado de envío, la misma transacción creada por BizTalk Server y usada para enviar al sistema de destino se usa para la eliminación de mensajes correspondiente una vez que se ha enviado correctamente. Si se produce algún error, se puede finalizar la transacción, en cuyo caso se anula la eliminación y los datos permanecen en BizTalk Server y no en el sistema de destino. Esto evita la duplicación de mensajes. Las transacciones solo se admiten para adaptadores de envío asincrónicos. No debe usar transacciones con adaptadores de envío sincrónicos.

Pero el adaptador no puede terminar la transacción; también debe controlar correctamente el estado de los mensajes proporcionados. En concreto, el adaptador debe llamar a los métodos Resubmit, MoveToNextTransport y MoveToSuspendQ correctamente según el recuento de reintentos y si hay disponible un transporte de copia de seguridad.

Es importante colocar las operaciones Delete y SubmitResponse juntas en un lote que usa la misma transacción. El error se controla finalizando la transacción (para asegurarse de que los datos solo se envían una vez a un sistema externo). Pero aún así desea reenviar el mensaje o llamar a MoveToNextTransport de nuevo en BizTalk Server. Para ello, use un lote normal (no transaccional) independiente para estos tipos de operaciones.

En la ilustración siguiente se muestra el uso de lotes independientes para los mensajes de respuesta.

Ordenación de los lotes transaccionales de Send-Side por punto de conexión

Los lotes de mensajes enviados por BizTalk Server al adaptador pueden abarcar varios puertos de envío (o puntos de conexión). Dado que el adaptador normalmente quiere tener una transacción en un único punto de conexión, el adaptador debe ordenar los mensajes en función del puerto de envío (SPName o OutboundTransportLocation). Al hacerlo, el adaptador puede crear una transacción que abarque solo un puerto de envío determinado.

Por ejemplo, cuando un adaptador de envío FTP recibe un lote de mensajes de BizTalk Server, obtiene un lote mixto de mensajes para todos los puertos de envío FTP activos actualmente. Esto sucede porque la API está basada en singleton, lo que significa que solo se carga un único adaptador FTP, no uno por puerto de envío.

El adaptador debe ordenar primero el lote de mensajes proporcionados por BizTalk Server en lotes independientes, uno para cada punto de conexión. A continuación, puede tratar con cada punto de conexión a su vez y probablemente construirá lotes de eliminación para cada punto de conexión. Las clases genéricas de BaseAdapter reutilizables del código de ejemplo del SDK funcionan de la misma manera.

Ordenación para envío dinámico

Una orquestación de BizTalk Server puede enviar un mensaje a un puerto que no se ha configurado siempre que proporcione suficientes detalles de configuración en el encabezado del mensaje y en la propia dirección URL. BizTalk Server debe reconocer el protocolo de la dirección URL.

Al ordenar los mensajes, tenga cuidado de establecer lo que defina un punto final. Esto es especialmente cierto en el caso de un envío dinámico. Si solo el URI define el punto de conexión, las cosas son sencillas. Sin embargo, en una sesión FTP, el servidor FTP podría usar los detalles de inicio de sesión del nombre de usuario para definir el punto de conexión verdadero. En este caso, si el adaptador inicia sesión como una cuenta diferente, puede estar conectado a otro directorio.

En algunos casos, el punto de conexión true no se conoce hasta que haya ejecutado el comando Enterprise Single Sign-On (SSO) ValidateAndRedeemTicket.

En el caso de MQSeries, se puede configurar si se deben usar transacciones. Dada la arquitectura y el uso de un objeto COM+ remoto, es mejor considerar un punto de conexión transaccional como distinto de un punto de conexión no transaccional.

En resumen, ordenar los mensajes en sus lotes de punto de conexión único a veces es una tarea no trivial y puede implicar tales pasos adicionales, como considerar los valores de contexto e incluso el resultado de una llamada a SSO.

Clasificación para Envío Estático

Si el punto de conexión es un punto de conexión configurado estáticamente, hay un GUID único en el contexto del mensaje denominado id. de puerto estático (SPID). Este valor se puede utilizar para clasificar el punto final. El código siguiente se puede usar para recuperarlo:

string spid = (string)message.Context.Read("SPID", "http://schemas.microsoft.com/BizTalk/2003/system-properties");  

Esto resulta útil cuando se consideran los problemas introducidos por el marco de configuración basado en definición de esquema XML (XSD). Con este marco, tiene una propiedad que podría formar parte de la clave de punto de conexión enterrada dentro de XML en una sola propiedad de contexto. Si tiene un SPID en el contexto, puede usarlo como una manera de ordenar el lote. De lo contrario, está realizando un envío dinámico y necesita construir una clave alternativa con la que ordenar el lote.

En la ilustración siguiente se muestra la ordenación de mensajes por punto de conexión.

Recuerde que el recuento de reintentos de un mensaje no tiene en cuenta el éxito o el fallo de un lote. En el lado de envío, puede producirse un error en un lote de mensajes porque se han producido errores en algunos mensajes del lote. El adaptador debe tomar una determinación para cada mensaje que reciba. En el escenario de lote con errores, podrías suponer que se vuelve a enviar cada mensaje. Sin embargo, si se vuelven a enviar todos los mensajes de un lote con errores, el recuento de reintentos (que mantiene el motor de BizTalk Server) se incrementa incorrectamente incluso para los mensajes correctos porque se encuentran en el mismo lote que los mensajes con error. En este caso, un adaptador podría reformar el lote de salida y volver a intentar enviar los mensajes exitosos en el sistema externo.