When you design your message flow, consider which terminals on the input node to connect:
All input nodes process non-transactional, non-persistent messages. The built-in input nodes handle failures and exceptions associated with these messages in this way:
The Real-timeInput and Real-timeOptimizedFlow nodes retry once before they discard the message; that is, they retrieve the message again and attempt to process it.
The HTTPInput and SCADAInput nodes do not propagate the message to the failure terminal if an exception is generated in the catch flow. The node logs the error in the local error log and discards the message.
In every situation in which it discards the message, the HTTPInput node waits until the time specified by the node property Maximum client wait time expires, and returns an error to the Web services client.
This action is summarized in the table below:
Error event | Failure terminal connected | Failure terminal not connected | Catch terminal connected | Catch terminal not connected |
---|---|---|---|---|
Node detects internal error | Fail flow handles the error | Node logs the error and discards the message | Not applicable | Not applicable |
Node propagates message to out terminal, exception occurs in out flow | Not applicable | Not applicable | Catch flow handles the error | Node logs the error and discards the message |
Node propagates message to catch terminal, exception occurs in catch flow | Fail flow handles the error (not HTTPInput or SCADAInput) | Node logs the error and discards the message | Not applicable | Not applicable |
Node propagates message to failure terminal, exception occurs in fail flow | Not applicable | Not applicable | Node logs the error and discards the message | Node logs the error and discards the message |