REVISIÓN: Hay disponible un hotfix que proporciona las propiedades adicionales de modo de entrega para el protocolo de nivel inferior mínima envían y reciban los adaptadores en el Acelerador de BizTalk para HL7 en un entorno de BizTalk Server 2010

Se aplica a: BizTalk Server Branch 2010BizTalk Server Developer 2010BizTalk Server Enterprise 2010

Resumen


En este artículo se describe un hotfix que proporciona dos propiedades adicionales de modo de entrega para el protocolo de nivel inferior mínima (MLLP) envían y reciban los puertos al utilizar el Acelerador de BizTalk para HL7 en un entorno de Microsoft BizTalk Server 2010:
  • Utilice el reconocimiento de transporte MLLP
    Esta propiedad está disponible en ambos unidireccional reciben puertos y puertos de envío unidireccional.
  • Suspender el mensaje de solicitud en el transporte MLLP NAK
    Esta propiedad sólo está disponible en los puertos de envío unidireccional.
El MLLP recibe el adaptador es compatible con ambos modos de respuesta de solicitud unidireccional y bidireccional. Si se configura el adaptador de recepción, procesamiento de HL7 utiliza el parámetro de Entrega solicitada . Esto garantiza que se mantiene el orden de entrega de mensajes. Cuando reciba el MLLP adaptador funciona en modo bidireccional, el adaptador no recibe un nuevo mensaje del sistema ascendente hasta que el adaptador genera una confirmación de solicitud (MSA) para el mensaje anterior al sistema precede en la cadena. ACK/NAK generado se envía a la base de datos de cuadro de mensaje (MessageBoxDB). MessageBoxDB espera el siguiente intervalo de sondeo antes de enviar el ACK/NAK al sistema precede en la cadena.

El sistema ascendente envía solamente un mensaje a la vez y sólo después de que recibe un ACK/NAK. Además, se configura el intervalo de sondeo de BizTalk y el parámetro de Entrega solicitada se establece en True. Esto significa que el número de mensajes que se procesan por segundo es limitado. Esta revisión proporciona una configuración adicional para envío unidireccional y puertos de recepción. No afecta el ACK/NAK. Sin embargo, aumenta significativamente el número de documentos que se procesan por segundo.

Deberá utilizar los contadores de rendimiento para tomar una instantánea antes y después de aplicar este hotfix. Cuando el banco de pruebas, debe enviar a un número razonable de mensajes durante un período razonable. Por ejemplo, podría utilizar lo siguiente:
  • Para el BizTalk: mensajería categoría, utilice el contador de Documentos procesados por segundo .
  • Para el BizTalk: latencia de mensajería categoría, utilice todos los contadores disponibles.

Una opción para aumentar el número de documentos que se procesan por segundo es disminuir el valor de MaxReceiveInterval para el host de BizTalk. Según el entorno general, en el ajuste del equipo que ejecuta Biz Talk Server 2010 y, en el volumen de documentos que se procesan, disminuye el valor de MaxReceiveInterval podría tener un efecto adverso en el rendimiento de la instancia de SQL Server. Para la optimización de SQL Server y para la optimización de BizTalk, consulte todos los artículos técnicos disponibles.

Más información


Nota: Este hotfix también resuelve un problema en 2010 Acelerador de Microsoft BizTalk para HL7. Para obtener más información acerca de este problema, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
2454887 podrían registrarse sucesos de forma incorrecta para un mensaje basado en MLLP en 2009 el Acelerador de BizTalk para HL7 en un equipo que está ejecutando Microsoft BizTalk Server 2009 o Microsoft BizTalk Server 2010

Información de la revisión

Existe un hotfix disponible desde Microsoft. Sin embargo, esta revisión se diseñó para corregir el problema descrito en este artículo. Aplique esta revisión solamente a sistemas que experimenten el problema descripto en este artículo. Esta revisión podría ser sometida a comprobaciones adicionales. Por lo tanto, si no se ve muy afectado por este problema, recomendamos que espere a la próxima actualización de software que contenga este hotfix.

Si la revisión está disponible para su descarga, hay una sección de "Descarga de revisión disponible" en la parte superior de este artículo de Knowledge Base. Si esta sección no aparece, póngase en contacto con el servicio al cliente de Microsoft y soporte técnico para obtener la revisión.

Nota: Si se producen problemas adicionales o si se requiere cualquier otra solución, será necesario crear una solicitud de revisión independiente. Los costos habituales de soporte se aplicarán a las preguntas de soporte técnico adicionales y problemas que no califican para esta revisión específica. Para obtener una lista completa de los números de teléfono de servicio al cliente de Microsoft o para crear una solicitud de servicio independiente, visite el siguiente sitio Web de Microsoft:Nota: El formulario de "Descarga de Hotfix disponible" muestra los idiomas para los que el Hotfix está disponible. Si no ve su idioma, es porque no hay una revisión para ese idioma.

Requisitos previos

Debe tener Microsoft BizTalk Accelerator para HL7 (BTAHL7) instalado para poder aplicar este hotfix.

Información de reinicio

Tendrá que reiniciar el equipo después de aplicar este hotfix. Si no se le pide reiniciar, debe reiniciar servicios de BizTalk. Para obtener más información acerca de este procedimiento, consulte el archivo Readme.txt que se incluye en este paquete de revisiones.

Información de reemplazo

Esta revisión no sustituye a ninguna revisión publicada previamente.

Información de archivo

La versión en inglés de esta revisión tiene los atributos de archivo (o atributos del archivo más reciente) mostrados en la tabla siguiente. Las fechas y horas de estos archivos se muestran en la hora Universal coordinada (UTC). Al ver la información del archivo, se convierte en hora local. Para encontrar la diferencia entre la hora UTC y la hora local, utilice la ficha Zona horaria en el elemento de Fecha y hora del Panel de control.

Nombre del archivoVersión del archivoTamaño de archivoFechaHoraPlataforma
Microsoft.solutions.btahl7.mllp.dll3.9.526.2116,60807-Jun-201115:27x86
Microsoft.solutions.btahl7.shared.dll3.9.526.292,04007-Jun-201115:27x86
Mllpreceive.exe3.9.526.226,45607-Jun-201115:27x86
Mllpsend.exe3.9.526.226,44807-Jun-201115:27x86

Acerca de la revisión

Después de la revisión se ha instalado y configurada el flujo de mensajes

Después de aplicar y habilitar esta revisión, el adaptador MLLP envía cualquier mensaje recibido por el adaptador MLLP a MessageBoxDB. El Administrador de punto final (EPM) vuelve el adaptador junto con el estado de envío del método BatchComplete . Esto hace que el adaptador enviar la confirmación ACK/NAK al sistema precede en la cadena. A su vez, el sistema precede en la cadena recibe el ACK/NAK y, a continuación, envía el mensaje siguiente. El método BatchComplete es independiente de la configuración de MaxReceiveInterval y se llama inmediatamente después de que el mensaje se envió correctamente a BizTalk.

Tan pronto como está listo para enviar el mensaje, el adaptador de envío transmite el mensaje al sistema de nivel inferior. Si la propiedad de Uso MLLP transporte confirmación se establece en True, se espera el ACK/NAK. Si el envío es un ACK, BizTalk finaliza el procesamiento correctamente. Si el envío es una señal de no confirmación, y si la propiedad de Mensaje de solicitud de suspensión en señal de no confirmación de MLLP transporte se establece en True, el mensaje se suspende directamente sin intentarlo de nuevo. Sin embargo, si la propiedad de Mensaje de solicitud de suspensión en señal de no confirmación de MLLP transporte se establece en False, BizTalk volverá a intentar basándose en la configuración de intervalo de reintentos de puerto de envío. (De forma predeterminada, la propiedad de Mensaje de solicitud de suspensión en señal de no confirmación de MLLP transporte se establece en False).

El siguiente diagrama muestra el flujo de mensajes:
Message flow
  1. El mensaje que envía el sistema precede en la cadena de aplicación de envío es procesada por el MLLP adaptador de recepción.
  2. El adaptador MLLP envía el mensaje a BizTalk/EPM.
  3. El EPM vuelve el adaptador sobre el estado de envío de mensaje. El EPM realiza esto en el método Lote completo .
  4. Una confirmación ACK/NAK generado por el adaptador MLLP y se basa en el estado de envío del lote. ACK/NAK se envía a la aplicación de envío.

    Nota: Si el estado de envío del lote es correcto, el adaptador devuelve el ACK. Sin embargo, si se produce un error o si el envío el tiempo de espera (por ejemplo, si se agota el tiempo de espera de la llamada al método Lote completo ), el adaptador devuelve NAK a la aplicación de envío.

  5. El EPM pasa el mensaje al adaptador de envío MLLP para la transmisión.
  6. El MLLP enviar adaptador envía el mensaje procesado que el sistema indirecto.
  7. El nivel de transporte ACK/NAK espera por el adaptador de envío MLLP para completar la comunicación.
  8. Si el mensaje en el paso 7 es un ACK, el adaptador pregunta el EPM para eliminar el mensaje. De lo contrario, el adaptador tiene pedir la EPM un reintento que se basa en la configuración de intervalo de reintento. Una nueva opción se proporciona en la configuración del puerto de envío para suspender el mensaje directamente, sin un reintento, si se recibe un NAK MLLP. De forma predeterminada, esta opción se establece en False. Si esta opción está establecida en True, el mensaje se suspenderá directamente, sin un reintento, si se recibe un NAK MLLP.

Formato ACK/NACK de nivel de transporte

El sitio Web contiene la siguiente información:
  • Ejemplo de un acuse de recibo de confirmación MLLP:
    <SB><ACK><EB><CR>
  • Ejemplo de un negativo MLLP confirmar confirmación:
    <SB><NAK><EB><CR>
Notas:
  • En estos ejemplos, < SB > hace referencia al carácter de bloque de inicio (1 byte). Esto corresponde al carácter ASCII < VT > o < 0x0B >.

    No debe confundirse con los caracteres SOH o ASCII STX.
  • En estos ejemplos, < ACK > o < NAK > referencia al carácter de confirmación (1 byte. Se corresponde con el carácter ASCII < ACK > o < 0 x 06 >) o el carácter de acuse de recibo negativo (1 byte. Corresponde al carácter ASCII < NAK > o < 0x15 >).
  • En estos ejemplos, < EB > hace referencia al carácter de bloque End (1 byte). Esto corresponde al carácter ASCII < FS > o < 0x1C >.
  • En estos ejemplos, < CR > hace referencia al carácter de retorno de carro (1 byte). Esto corresponde al carácter ASCII < CR > o < 0x0D >.
  • Microsoft proporciona información de contacto de terceros para ayudarle a encontrar soporte técnico. Esta información de contacto puede cambiar sin previo aviso. Microsoft no garantiza la exactitud de esta información de contacto de terceros.

Cómo configurar la recepción y puertos a usar las nuevas propiedades de envío

Configurar la recepción y puertos de envío como sigue.

Nota: La configuración de puerto de envío y recepción se puede utilizar independientemente o juntos.

Configuración de puerto de recepción
  • El puerto debe ser un puerto unidireccional.
  • Debe habilitarse el parámetro de Entrega solicitada .
  • Debe establecer la propiedad de Confirmación de transporte de uso MLLP en True para habilitar la confirmación de nivel de transporte. De forma predeterminada, esta propiedad se establece en False para los puertos existentes o nuevos puertos.
Receive port
Enviar la configuración del puerto
  • El puerto debe ser un puerto unidireccional.
  • El modo de petición-respuesta debe establecerse en No.
  • Debe habilitarse el parámetro de Entrega solicitada .
  • Debe establecer la propiedad de Confirmación de transporte de uso MLLP en True para habilitar la confirmación de nivel de transporte. De forma predeterminada, esta propiedad se establece en False para los puertos existentes o nuevos puertos.
  • Debe establecer la propiedad de Mensaje de solicitud de suspensión en señal de no confirmación de MLLP transporte en True si los mensajes necesitan ser suspendido directamente sin se volverá a intentar cuando se recibe una señal de no confirmación de transporte desde un sistema de nivel inferior. De lo contrario, el mensaje se volverá el número de veces que se establece en el transporte de las opciones de puerto de envío avanzadas. De forma predeterminada, esta propiedad se establece en False para los puertos existentes o nuevos puertos.
Send port

Acerca de la propiedad de "Reconocimiento de transporte MLLP de uso"

La tabla siguiente describe el comportamiento esperado de puertos unidireccionales o bidireccionales que utilice la propiedad Usar reconocimiento de transporte MLLP . Debe aplicarse la combinación requerida de configuración como se describe en la sección "Cómo habilitar la revisión".

Notas:
  • "Sistema precede en la cadena" se refiere a la aplicación de envío. Envía mensajes a BizTalk. Estos mensajes son entrantes a BizTalk.
  • "Sistema indirecto" se refiere a la aplicación receptora. Recibe mensajes de BizTalk. Estos mensajes son saliente a BizTalk.


Tipo de puertoMLLP opción V2MLLP opción V2
Unidireccional recibirEnviar MLLP ACK/NAK al sistema precede en el método BatchComplete .Ningún cambio en el comportamiento. En esta situación, no se envía ninguna ACK/NAK al sistema precede en la cadena.
Ambos sentidos recibeNingún cambio en el comportamiento. En esta situación, el ACK de HL7/NAK en el método TransmitMessage se envía al sistema precede en la cadena.

Nota: No se admite esta opción. Por ejemplo, omitir incluso si el valor se establece en True.
Ningún cambio en el comportamiento. En esta situación, el ACK de HL7/NAK en el método TransmitMessage se envía al sistema precede en la cadena.
Envío unidireccionalEl MLLP ACK/NAK desde el sistema indirecto es esperado después de que el mensaje se transmite.Ningún cambio en el comportamiento. En esta situación, el ACK/NAK desde el sistema indirecto no es esperado después de que el mensaje se transmite.
Envío bidireccional o unidireccional enviar con el modo de petición-respuesta habilitadoNingún cambio en el comportamiento. En esta situación, el ACK de HL7/NAK desde el sistema indirecto es esperado después de que el mensaje se transmite.

Nota: No se admite esta opción. Por ejemplo, omitir incluso si el valor se establece en True.
Ningún cambio en el comportamiento. En esta situación, el ACK de HL7/NAK desde el sistema indirecto es esperado después de que el mensaje se transmite.


Bidireccional de recepción y envío no se cambia el comportamiento del puerto. Unidireccional de recepción y envío de comportamiento puerto también no cambia a menos que la propiedad Uso MLLP transporte confirmación está establecida en true.

Para obtener más información, consulte la documentación del adaptador MLLP. Si un sentido recibe y puertos de envío tienen la configuración adecuada, mejora el rendimiento. Si la característica de Reconocimiento de transporte MLLP de uso de un puerto bidireccional o unidireccional se establece en false, el tipo de confirmación generado continúa sin cambios. En esta situación, el tipo de confirmación generado depende de la configuración de BTAHL7 configuración explorador de la aplicación que envía el mensaje. El valor de campos MSH 15 y 16 de MSH de un mensaje específico puede invalidar esta configuración. Sin embargo, si la característica de Reconocimiento de transporte MLLP de uso de un puerto bidireccional o unidireccional se establece en false, puede establecer la configuración de las aplicaciones que esperan ACK estático sólo mediante el Explorador de configuración BTAHL7. Comportamiento de tiempo de espera para el puerto sufre..

El comportamiento esperado en los casos de esquina cuando se utilizan las propiedades es la siguiente:

RECEIVE
  • WrongMLLPFormat: el mensaje no se envía a BizTalk.
  • WrongHL7Format: el mensaje se envía a BizTalk y se transmite un ACK de MLLP/NAK que se basa en el estado de finalización de proceso por lotes.
  • TransmittingSocketIssue: el ACK de MLLP/NAK no se transmite, aunque el mensaje se envía a BizTalk.
  • ReceivingSocketIssue: el mensaje no se recibe y, por tanto, no se envía y no se envía ninguna transmisión MLLP ACK/NAK.
  • Si se produce un error en una presentación a BizTalk, se transmite una señal de no confirmación.
  • Si se recibe un estado negativo de lote completo, se transmite una señal de no confirmación.
Enviar y el puerto de envío propiedad "detener el envío de mensajes posteriores en caso de error de mensaje actual" = True
  • WrongMLLPFormat: el mensaje se ha suspendido porque no se puede leer el MLLP ACK/NACK. Procesamiento no continuará hasta que se borran los mensajes suspendidos.
  • WrongHL7Format: el mensaje no antes de que llegue el adaptador. Procesamiento no continuará hasta que se borran los mensajes suspendidos.
  • TransmittingSocketIssue: se ha suspendido el mensaje. Procesamiento no continuará hasta que se borran los mensajes suspendidos.
  • ReceivingSocketIssue: se ha suspendido el mensaje. Procesamiento no continuará hasta que se borran los mensajes suspendidos.

El comportamiento esperado cuando la propiedad de Mensaje de solicitud de suspensión en señal de no confirmación de MLLP transporte está establecida en True o en False es la siguiente:
  • Cuando la propiedad de Mensaje de solicitud de suspensión en señal de no confirmación de MLLP transporte se establece en True y se recibe una señal de no confirmación, se suspende el mensaje sin un reintento para enviarla.
  • Cuando se establece la propiedad de Mensaje de solicitud de suspensión en señal de no confirmación de MLLP transporte para el valor predeterminado de False, un reintento para enviar que el mensaje se inicia, se basa en la configuración de intervalo de reintentos de puerto de envío.

Cambios en la utilidad de SDK de MLLP

La utilidad de SDK de MLLP incluye los siguientes parámetros nuevos. Todos los demás parámetros permanecen sin cambios. Para obtener más información, consulte la documentación del producto.
  • Para MLLPReceive.exe, utilice el nuevo parámetro para devolver el ACK de MLLP/NAK después de recibir el mensaje. Por ejemplo:
    MLLPReceive /p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransACK
    MLLPReceive /p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransNAK
  • Para MLLPSend.exe, utilice el nuevo parámetro espera para MLLP ACK/NAK. Por ejemplo:
    MLLPSend /sb 11 /eb 28 /cr 13/f "C:\HL7\ls.txt" /I 127.0.0.1 /p 11000 /UseMLLPTransACK

Referencias


Para obtener más información acerca de cómo administrar la configuración de rendimiento en el servidor BizTalk server, visite el siguiente sitio Web de Microsoft Developer Network (MSDN):Para obtener más información acerca de los contadores de rendimiento de mensajería, visite el siguiente sitio Web MSDN:Para obtener más información acerca de pedidos de entrega de mensajes, visite el siguiente sitio Web MSDN:Para obtener más información acerca de 2010 el Acelerador de BizTalk para HL7 (BTAHL7), visite el siguiente sitio Web de Microsoft:Para obtener más información acerca del método IBTBatchCallBack.BatchComplete , visite el siguiente sitio Web MSDN:Para obtener más información acerca de las revisiones de BizTalk Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
2003907 información acerca de las revisiones de BizTalk Server