Puede diseñar un flujo de mensajes para captar excepciones antes de que éstas se devuelvan al nodo de entrada. En un flujo individual, puede incluir uno o varios nodos TryCatch 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. 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 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 la Lista de excepciones, grabando encima de la información que está almacenada allí.
Ahora el nodo propaga el mensaje a la secuencia de nodos conectados al terminal de captación (flujo de captaciones). El contenido del árbol de mensaje que se propaga es idéntico al contenido que se ha propagado al terminal de intentos, que es el contenido del árbol cuando el nodo TryCatch lo ha recibido por primera vez. Amplía este árbol con la nueva información de excepción que ha grabado en la Lista de excepciones. Las modificaciones o adiciones realizadas en los nodos del flujo de intentos que afecten al árbol de mensaje no aparecerán en el árbol de mensaje que se propaga al flujo de captaciones.
Sin embargo, éstas no se pierden si el flujo de intentos ha terminado un proceso que incluye actualizaciones en bases de datos externas. Las actualizaciones persisten mientras el flujo de captaciones procesa el mensaje y la decisión sobre si se confirman o se restituyen las actualizaciones 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 en el flujo de captaciones lógica que restituya los cambios que se han efectuado.
Para revisar las opciones de configuración, consulte el apartado Configurar nodos para flujos de mensajes coordinados.
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:
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 verdaderos y falsos 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 ambos terminales 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 (por ejemplo Real-timeInput) y desea procesar errores en el flujo, deberá incluir un nodo TryCatch. El ejemplo siguiente muestra cómo puede conectar un flujo para proporcionar este proceso de errores. En este ejemplo, puede configurar el ESQL en el nodo Compute del flujo de captaciones para examinar la excepción que se ha captado y establecer el nombre de cola de salida dinámicamente.