Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La instalación de control de errores permite al diseñador designar el control automatizado de errores de mensajería como alternativa al comportamiento tradicional (ahora predeterminado) de colocar mensajes con errores en la cola suspendida. Este control automatizado enruta un mensaje de error a cualquier destino de enrutamiento de suscripción, como un puerto de envío o una orquestación. El mensaje de error es un clon del mensaje original con todas las propiedades promocionadas anteriormente ahora degradadas y con las propiedades seleccionadas relacionadas con el error de mensajería específico promocionado al contexto del mensaje.
Advertencia
Los mensajes con error contienen una copia del mensaje original. Si el mensaje original contiene información confidencial, diseñe los procesos manuales y automáticos de mensajes fallidos para evitar la divulgación accidental.
¿En qué consiste el enrutamiento de mensajes fallido?
Cuando el enrutamiento de mensajes con error está habilitado, BizTalk Server no suspende el mensaje; en su lugar, enruta el mensaje. El enrutamiento de mensajes con error se puede habilitar en puertos de recepción y envío, con los siguientes resultados:
Si el enrutamiento de mensajes con error está habilitado en un puerto de recepción y se produce un error en la canalización de recepción o en el enrutamiento, se genera un mensaje con error. En el caso de que se produzca un error en o antes de la fase de desensamblaje, el mensaje de error es un clon del intercambio original.
Si el enrutamiento de mensajes con error está habilitado en un puerto de envío y se produce un error en la canalización de envío, se genera un mensaje con error.
Cuando se genera un mensaje con error, BizTalk Server promueve las propiedades de contexto del mensaje relacionadas con el informe de errores y degrada las propiedades de contexto de mensaje normales antes de publicar el mensaje con errores. Compare este comportamiento con el comportamiento predeterminado cuando el enrutamiento de mensajes con error no está habilitado: los mensajes que producen un error se suspenden.
¿Qué tipos de errores de mensajería desencadenan un mensaje de error?
Los errores que se producen en el procesamiento del adaptador, el procesamiento de canalizaciones, la asignación o el enrutamiento de mensajes producen un mensaje de error si el enrutamiento de mensajes con errores está habilitado. Cuando se produce un error de mensajería mientras se recibe una orquestación desde un puerto de recepción o se envía a un puerto de envío, el mensaje de error resultante está asociado a los puertos de mensajería a los que está enlazada la orquestación.
Suscribirse a un mensaje de error
Los mensajes de error se entregan a orquestaciones o puertos de envío que se han suscrito para recibirlos. Normalmente, una suscripción selecciona un mensaje de error en función del nombre del puerto en el que se produjo el error de mensajería (un puerto de envío o recepción). Una suscripción también puede filtrar por otras propiedades disponibles en el contexto de mensaje del error (por ejemplo, InboundTransportLocation o FailureCode).
Especificación del mensaje de error
Un mensaje de error es un clon del mensaje fallido original, con todas las propiedades previamente promocionadas degradadas y un conjunto de propiedades específicas del error promocionadas al contexto del mensaje. Las propiedades promocionadas anteriormente se degradan para evitar la entrega no deseada a los suscriptores no designados para recibir el mensaje de error. El mensaje de error se publica para la distribución a los suscriptores (orquestaciones, puertos de envío y grupos de puertos de envío).
Todas las propiedades que se promueven al contexto de un mensaje de error se encuentran en el espacio de nombres ErrorReport en BizTalk Server. Son los siguientes:
| Nombre de propiedad | Tipo de dato | Promovido | Descripción |
|---|---|---|---|
| CódigoDeError | xs:string | Sí | Código de error. Valor hexadecimal que se notifica en la consola de administración de BizTalk Server. |
| CategoríaDeFallo | xs:int | Sí | Esta propiedad no se usa. Su valor no está definido. |
| Descripción | xs:string | No | Descripción del error. El mismo texto de diagnóstico que se escribe en el registro de eventos de la aplicación con respecto a este error de mensajería. |
| TipoDeMensaje | xs:string | Sí | Tipo de mensaje con error o vacío si el tipo de mensaje es indeterminado. BizTalk Server usa el tipo de mensaje para asociar mensajes a sus esquemas XML. El tipo de mensaje se forma mediante la concatenación del espacio de nombres de esquema con el nodo raíz del esquema: http://mynamespace#rootnode. Nota: Los mensajes que producen un error antes de que se determine su tipo de mensaje no tienen establecido esta propiedad. |
| NombreDelPuertoDeRecepción | xs:string |
Promovido si se produjo el fallo durante el procesamiento de entrada (en un puerto de recepción) No se promueve si se produjo el error en un puerto de envío. |
Nombre del puerto de recepción donde se produjo el error. |
| InboundTransportLocation | xs:string |
Promocionado si el error ocurrió durante el procesamiento de entrada (en un puerto de recepción) No se promueve si se produjo el error en un puerto de envío. |
URI de la ubicación de recepción donde se produjo el error. |
| SendPortName | xs:string |
Promocionado si se produjo el error durante el procesamiento saliente (en un puerto de envío) No se promueve si el error se produjo en un puerto de recepción. |
Nombre del puerto de envío donde se produjo el error. |
| OutboundTransportLocation | xs:string |
Promocionado si se produjo el error durante el procesamiento saliente (en un puerto de envío) No se promueve si el error se produjo en un puerto de recepción. |
URI de la ubicación de envío donde se produjo el error. |
| Tipo de Error | xs:string | Sí | Indica el tipo de mensaje que contiene el error. Esta propiedad siempre contiene el valor FailedMessage, lo que significa que el error contiene el mensaje de error original. |
| IDInformeDeFalloDeEnrutamiento | xs:string | Sí | Esta propiedad proporciona el identificador del informe de error de enrutamiento que BizTalk Server genera cuando se produce un error de enrutamiento. Un informe de error de enrutamiento es un mensaje especial que BizTalk Server genera y suspende. Este mensaje no tiene un cuerpo, pero tiene el contexto del mensaje con error. Con este identificador, una orquestación de control de errores o un puerto de envío puede consultar la base de datos messageBox y procesar el informe de errores de enrutamiento. Por ejemplo, una orquestación puede querer finalizar el informe de error de enrutamiento después de obtener el mensaje fallido. |
| Tiempo de Fallo | xs:dateTime | Fecha y hora de la aparición del error | |
| FailureMessageID | xs:string | ||
| FailureInstanceID | xs:string | ||
| FailureAdapter | xs:string |
Control de mensajes de error
El control de errores se especifica mediante una suscripción de orquestación o puerto de envío cuyo filtro coincide con las propiedades que se han promocionado al contexto de mensaje del mensaje de error.
Implicaciones de seguridad
La identidad asociada al mensaje original (ya sea su identidad inicial o su identidad final determinada por la etapa de Resolución de Parte de la canalización de recepción) se asigna al mensaje de error.
Los mecanismos de seguridad que restringen la entrega de mensajes a puertos y orquestaciones de suscripción autorizados también se aplican a los mensajes de error.
Un puerto de envío que se suscribe a un mensaje de error, pero no está configurado con un certificado de descifrado adecuado, no recibe los mensajes de error que se generan por fallas de mensajería en o antes de la etapa de descifrado de la canalización de recepción a través de la cual el mensaje original entró al servidor BizTalk. En su lugar, los mensajes con errores se colocan en la cola Suspendida.
Error de mensajería del adaptador
Si un adaptador suspende un mensaje, se publica un mensaje de error. No se genera ningún mensaje de error si el mensaje no está suspendido.
Tuberías de Recepción Transaccional
Si una canalización de recepción transaccional produce una excepción (especifica que se debe anular la transacción), la transacción se anula y se publica un mensaje de error.
Si una canalización de recepción transaccional especifica explícitamente que MessageDestination = SuspendQueue, el mensaje se suspende, la transacción actual puede proceder (y puede ser confirmada a menos que las etapas posteriores especifiquen su anulación), y el mensaje de error resultante se publica.
Solicit-Response Puertos de Envío
Cuando se envía un mensaje de solicitud desde una orquestación y se produce un error en la transmisión o un error en el procesamiento entrante, la orquestación recibe una excepción, independientemente de si el mensaje fallido ha sido enrutado.
En el caso de que un puerto de envío de solicitud-respuesta esté conectado a un puerto de recepción de solicitud-respuesta, el puerto de recepción obtiene un mensaje de respuesta (si la transmisión se realiza correctamente) o una NACK (si se produce un error en la transmisión), independientemente de si el mensaje con error se ha enrutado.
One-Way puertos de envío
Cuando se envía un mensaje desde una orquestación a través de un puerto de envío configurado para la notificación de entrega, la orquestación recibe una notificación de entrega independientemente de si se ha enrutado el mensaje de error. En otras palabras, el puerto de envío genera una notificación de entrega para la orquestación aunque el puerto encuentre un error de mensajería durante el procesamiento. La notificación confirma la entrega al puerto, pero no aborda el procesamiento correcto a través del puerto.
Reanudación de mensajes suspendidos
La mayoría de los mensajes que producen un error en el procesamiento de entrada (es decir, el procesamiento desde e incluido el adaptador de recepción, hasta pero no la publicación en el buzón de mensajes) y cuyos errores no se gestionan, se suspenden de manera que se pueden reanudar. La excepción es que los mensajes de solicitud de puertos de recepción bidireccionales se suspenden como no reanudables.
Normalmente, los mensajes se suspenden en su forma original (como estaban antes del procesamiento de canalización), con dos excepciones:
Mensajes suspendidos por componentes de canalización. BizTalk Server suspende este tipo de mensaje en la misma forma en que fue proporcionado al componente de canalización con errores. Cuando se reanuda el mensaje, se somete al procesamiento de la canalización desde el principio de la misma canalización. Esto implica que un componente de canalización en una fase de canalización que precede a la fase en la que se produjo el error original debe estar preparado para controlar el mensaje "mismo" en un formulario diferente del formulario original en el que procesó ese mensaje.
Mensajes del desensamblaje de intercambio recuperable que posteriormente producen un error en el enrutamiento. BizTalk Server suspende este tipo de mensaje de la misma forma que se publicó. Este es el formulario que tenía el mensaje después de la ejecución de la canalización. Cuando se reanuda el mensaje, omite el procesamiento de la canalización y se publica directamente en la base de datos MessageBox.
Escenarios que conducen a mensajes suspendidos (no reanudables)
Aunque es más común que los mensajes se suspenden como reanudables, hay algunos escenarios que conducen a mensajes no reanudables:
En un puerto de envío de entrega ordenada con continuar en caso de error habilitado, si hay un error en la tubería, mapeo o transmisión.
En un puerto de recepción de entrega ordenada, si el adaptador está configurado para suspender mensajes en caso de error no reanudable. Por ejemplo, si la configuración del adaptador de MSMQ "On Failure" está establecida en "Suspender como no reanudable" o el adaptador MQSeries tiene habilitado "Suspender como no reanudable", los mensajes con fallo se suspenderán como no reanudables.
En un puerto de recepción bidireccional, si el mensaje de respuesta falla en la canalización, asignación o transmisión.
En un puerto de recepción bidireccional, si el mensaje recibido falla en la canalización, asignación o transmisión. El comportamiento del adaptador individual puede ser diferente. Por ejemplo, el adaptador HTTP no suspende los mensajes de forma predeterminada, pero se puede configurar para hacerlo.
Véase también
control de errores
Uso de reconocimientos
Entrega ordenada de mensajes