Los errores internos los pueden producir programas que almacenan datos no válidos en la base de datos o se pueden producir debido a un defecto en la lógica de un flujo.
La estrategia más simple para manejar los errores de ESQL es no hacer nada y utilizar el comportamiento por omisión del intermediario. El comportamiento por omisión es atajar el proceso del mensaje anómalo y continuar en el mensaje siguiente. Los nodos de entrada y salida proporcionan opciones para controlar exactamente qué sucede cuando se ataja el proceso.
Cada una de estas estrategias tiene sus ventajas. El modelo transaccional conserva la coherencia de los datos, mientras que el modelo no transaccional maximiza la continuidad del proceso de mensajes. Recuerde que en el modelo transaccional, el mensaje de entrada anómalo se vuelve a transferir a la cola de entrada y el intermediario intentará procesarlo otra vez. El resultado más probable de esto es que el mensaje continúe fallando hasta que se alcance el límite de reintentos, momento en el cual se pone en una cola de mensajes no entregados. La razón por la que no se ha podido procesar el mensaje se registra en el registro de sucesos del sistema (Windows) o syslog (UNIX). De este modo, el mensaje anómalo retiene el proceso de los mensajes correctos subsiguientes durante un tiempo y, a continuación, el intermediario lo deja sin procesar.
La mayoría de bases de datos operan de forma transaccional para que todos los cambios realizados en las tablas de base de datos se confirmen si el proceso del mensaje se realiza satisfactoriamente o se restituyan si el proceso falla, manteniendo de este modo la integridad de los datos. Existe una excepción de esto cuando falla el propio intermediario o una base de datos. (Por ejemplo, se puede interrumpir la alimentación de las máquinas que se están ejecutando.) En estos casos, es posible que los cambios se confirmen en algunas bases de datos y que no se confirmen en otras o que los cambios de base de datos se confirmen pero que los mensajes de entrada y salida no. Si estas posibilidades le preocupan, se deberá coordinar el flujo y se deberán configurar para este modo de trabajo las bases de datos implicadas.
Utilice terminales de anomalías para captar errores no manejados. Conecte un flujo de lógica simple al terminal de anomalías. Este flujo de lógica puede constar de una base de datos o un nodo Compute que graba un registro de anotaciones en una base de datos (posiblemente incluyendo la corriente de bits del mensaje) o graba un registro en el registro de sucesos. También puede contener un nodo de salida que graba el mensaje en una cola especial.
El árbol de excepción completo se pasa a cualquier nodo conectado a un terminal de anomalías. (El árbol de excepción se describe en el apartado Estructura del árbol Lista de excepciones.)
Para obtener una descripción detallada de las opciones que puede utilizar para procesar errores en un flujo de mensajes, consulte el apartado Manejar errores en flujos de mensajes. Los temas siguientes proporcionan ejemplos de lo que se puede hacer:
Es difícil manejar los mensajes de entrada que no son válidos sintácticamente (y los mensajes de entrada que parecen no ser válidos porque la información de formato de mensaje es errónea) porque el intermediario no tiene ni idea de lo que contiene el mensaje. Probablemente el mejor modo de tratarlos consiste en configurar el nodo de entrada para analizar y validar totalmente el mensaje.
Sin embargo, tenga en cuenta que esto sólo se aplica a mensajes predefinidos, es decir MRM o IDOC.
Para tratar un mensaje anómalo, conecte un flujo de lógica simple al terminal de anomalías.
La única desventaja de esta estrategia es que, si el flujo normal no necesita acceso a todos los campos del mensaje, al forzar el análisis completo del mensaje el rendimiento queda afectado.
Si necesita algo mejor que el manejo de errores por omisión, el primer paso es utilizar un manejador (consulte el apartado Sentencia DECLARE HANDLER) para interceptar la excepción. El manejador puede determinar la naturaleza de la anomalía a partir del estado de SQL devuelto por la base de datos.
Sin embargo, tenga cuidado con esta clase de estrategia. Dado que el manejador absorbe la excepción, se confirman los cambios en otras bases de datos o las grabaciones en colas.
Los errores que se producen en los nodos de salida MQ
indican la naturaleza del error en el estado
de SQL y proporcionan información adicional en la variable de error nativo de
SQL. De este modo, si se necesita algo mejor que el manejo de errores por
omisión, el primer paso es utilizar un manejador (consulte Sentencia DECLARE HANDLER)
para interceptar la excepción. Un manejador de este tipo sólo suele encargarse de una sola
sentencia PROPAGATE.
En la ausencia de una restricción de tipo, un intento de acceder a un campo de mensaje no existente produce el valor nulo. Los valores nulos se propagan mediante las expresiones, haciendo que el resultado sea nulo. De este modo, si una expresión, por compleja que sea, no devuelve un valor nulo, sabrá que todos los valores que necesitaba para calcular el resultado no eran nulos.
Las expresiones de transformación CAST pueden tener una cláusula por omisión. Si hay una cláusula por omisión, las transformaciones CAST fallan silenciosamente; en lugar de generar una excepción, simplemente devuelven el valor por omisión. El valor por omisión puede ser un número inocuo (por ejemplo, cero para un entero) o un valor que claramente no es válido en el contexto (por ejemplo, -1 para un número de cliente). Nulo puede ser especialmente adecuado, porque es un valor que es diferente de todos los demás y que se propagará mediante las expresiones sin ninguna posibilidad de que la condición de error quede enmascarada.
Es posible que las excepciones que se producen en otros nodos (es decir, en sentido descendente de una sentencia PROPAGATE) las capten de forma normal los manejadores. Sin embargo, el manejo inteligente de dichos errores plantea el problema especial que supone el hecho de que, dado que había otro nodo implicado en el error original, es muy probable que otro nodo y no necesariamente el que ha originado la excepción esté implicado en el manejo del mismo.
Para ayudar en estas situaciones los nodos de base de datos y de cálculo tiene cuatro terminales nuevos denominados out1, out2, out3 y out4. Además, se ha ampliado la sintaxis de la Sentencia PROPAGATE para incluir cláusulas de expresión de destino, de origen de mensajes y de control para proporcionar más control sobre estos terminales adicionales.