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 (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 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í.
El nodo propaga entonces 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. 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 mensajes no aparecerán en el árbol de mensajes que se propaga al flujo de captación.
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 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 Configurar flujos de mensajes coordinados globalmente.
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 (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 captación para examinar la excepción que se ha captado y establecer el nombre de cola de salida dinámicamente.