Internal errors can be caused by programs storing invalid data in the database or by a flaw in the logic of a flow.
The simplest strategy for handling ESQL errors is to do nothing and use the broker's default behavior. The default behavior is to cut short the processing of the failing message and to proceed to the next message. Input and output nodes provide options to control exactly what happens when processing is cut short.
Each of these strategies has its advantages. The transactional model preserves the consistency of data, while the non-transactional model maximizes the continuity of message processing. Remember that in the transactional model the failing input message is put back on to the input queue and the broker will attempt to process it again. The most likely outcome of this is that the message continues to fail until the retry limit is reached, at which point it is placed on a dead letter queue. The reason for the failure to process the message is logged to the system event log (Windows) or syslog (UNIX). Thus the failing message holds up the processing of subsequent good messages for a while and is then left unprocessed by the broker.
Most databases operate transactionally, so that all changes made to database tables are committed if the processing of the message succeeds and rolled back if it fails, thus maintaining the integrity of data. An exception to this is if the broker itself, or a database, fails. (For example, the power to the machines they are running on could be interrupted.) It is possible in these cases for changes in some databases to be committed and changes in others not; or for the database changes to be committed but the input and output messages not to be committed. If these possibilities concern you, the flow should be made coordinated and the databases involved configured for this way of working.
Use failure terminals to catch unhandled errors. Attach a simple logic flow to the failure terminal. This logic flow could consist of a database or compute node that writes a log record to a database (possibly including the message's bit-stream) or writes a record to the event log. It could also contain an output node that writes the message to a special queue.
The full exception tree is passed to any node connected to a failure terminal. (The exception tree is described in ExceptionList tree structure.)
For a detailed discussion of the options that you can use to process errors in a message flow, see Handling errors in message flows. The following topics provide examples of what you can do:
Input messages that are syntactically invalid (and input messages that appear to be not valid because of erroneous message format information) are difficult to deal with because the broker has no idea what the message contains. Probably the best way of dealing with them is to configure the input node to fully parse and validate the message.
Note, however, that this applies only to predefined messages, that is, MRM or IDOC.
To deal with a failing message, connect a simple logic flow to the failure terminal.
The only disadvantage to this strategy is that, if the normal flow does not require access to all the message's fields, the forcing of complete parsing of the message affects performance.
If you require something better than default error handling, the first step is to use a handler (see DECLARE HANDLER statement) to intercept the exception. The handler can determine the nature of the failure from the SQL state returned by the database.
However, take care with this sort of strategy. Because the handler absorbs the exception, any changes to other databases or writes to queues are committed.
Errors occurring in MQ output nodes report
the nature of the error in the SQL state and give additional information in
the SQL native error variable. Thus, if something better
than default error handling is required, the first step is to use a handler
(see DECLARE HANDLER statement) to intercept the exception. Such
a handler typically surrounds only a single PROPAGATE statement.
In the absence of a type constraint, an attempt to access a non-existent message field results in the value null. Null values propagate through expressions, making the result null. Thus, if an expression, however complex, does not return a null value, you know that all the values it needed to calculate its result were not null.
Cast expressions can have a default clause. If there is a default clause, casts fail quietly; instead of throwing an exception, they simply return the default value. The default value could be an innocuous number (for example, zero for an integer), or a value that is clearly invalid in the context (for example, -1 for a customer number). Null might be particularly suitable, because it is a value that is different from all others and that will propagate through expressions without any possibility of the error condition being masked.
Exceptions occurring in other nodes (that is, downstream of a PROPAGATE statement) might be caught by handlers in the normal way. Handling such errors intelligently, however, poses the special problem that, as another node was involved in the original error, another node, and not necessarily the originator of the exception, is very likely to be involved in handling it.
To help in these situations the database and compute nodes have four new terminals called out1, out2, out3, and out4. In addition the syntax of the PROPAGATE statement has been extended to include target expression, message source and control clauses to give more control over these extra terminals.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac17140_ |