Puede diseñar un flujo de mensajes para captar excepciones antes de que éstas se devuelvan al nodo de entrada. Puede incluir uno o varios nodos TryCatch en un flujo para proporcionar un solo punto de anomalía para una secuencia de nodos. Con esta técnica, puede proporcionar un proceso y una recuperación de error muy específicos.
Un nodo TryCatch no procesa un mensaje de ningún modo, sólo representa un punto de decisión en un flujo de mensajes. Cuando el nodo TryCatch recibe un mensaje, lo propaga al terminal de intentos (try). El intermediario pasa el control a la secuencia de nodos conectados a dicho terminal (flujo de intentos).
Si se genera una excepción en el flujo de intentos, el intermediario devuelve el control al nodo TryCatch. El nodo graba el contenido actual del árbol de la lista de excepciones en las anotaciones de error locales y, a continuación, graba la información para la excepción actual en el árbol de la lista de excepciones, grabando encima de la información que haya almacenada allí.
El nodo propaga el mensaje a la secuencia de nodos conectados al terminal de captación (flujo de captación). El contenido del árbol de mensajes que se propaga es idéntico al contenido que se ha propagado al terminal de intentos, que era el contenido del árbol cuando el nodo TryCatch lo recibió por primera vez. El nodo amplía el árbol de mensajes con la información de la excepción nueva que se ha grabado en el árbol de lista de excepciones. Las modificaciones o adiciones realizadas en los nodos del flujo de intentos que afecten al árbol de mensajes no aparecerán en el árbol de mensajes que se propaga al flujo de captación.
Sin embargo, si se ha terminado el proceso del flujo de intentos que implica actualizaciones en las bases de datos externas, estas actualizaciones no se pierden sino que persisten mientras el flujo de captación procesa el mensaje y la decisión sobre si las actualizaciones se confirman o se restituyen se toma en la configuración del flujo de mensajes y de los nodos individuales que interactúan con las bases de datos. Si las actualizaciones se confirman debido a la configuración que se ha establecido, deberá incluir lógica en el flujo de captación que restituya los cambios que se han efectuado.
Para revisar las opciones de configuración, consulte el apartado Configuración de la transaccionalidad de flujos de mensajes.
El intermediario devuelve el control al siguiente punto de captación del flujo de mensajes (que puede ser otro nodo TryCatch, pero que es siempre, en última instancia, el nodo de entrada) si se cumple una de las condiciones siguientes:
El ejemplo siguiente muestra cómo se puede configurar el flujo para captar excepciones en el nodo de entrada. El terminal de captación del nodo MQInput se conecta a un nodo Trace para registrar el error.
En el ejemplo siguiente, el flujo de mensajes tiene dos flujos de proceso independientes conectados a los terminales verdadero y falso del nodo Filter. Aquí se incluye un nodo TryCatch en cada una de las dos rutas que puede tomar el mensaje. El terminal de captación de los dos nodos TryCatch se conecta a un subflujo de proceso de errores común.
Si el nodo de entrada del flujo de mensajes no tiene un terminal de captación y desea procesar errores del flujo, deberá incluir un nodo TryCatch.