| Oracle® SOA Suite Developer's Guide 10g (10.1.3.1.0) Part Number B28764-01 |
|
|
View PDF |
| Oracle® SOA Suite Developer's Guide 10g (10.1.3.1.0) Part Number B28764-01 |
|
|
View PDF |
When an error occurs in Oracle Enterprise Service Bus processing, the error is noted by visual cues, such as icon and color changes, in Oracle ESB Control. A red icon identifies an error condition, as shown in Figure 12-9.
Figure 12-9 Instances View – Tracking Tab with Error
In addition to the visual cues in Oracle ESB Control, you can set up notifications by email, fax, or phone when errors occur. See Section 12.3.1, "How to View and Modify System Definitions".
Error handling in Oracle Enterprise Service Bus involves several types of errors that can occur in transaction processing:
Rejection: A validation error in the message that must be fixed by the user
Retry: A temporary loss of a service impacting the routing of the message, but that is usually resolved in a relatively short time period
Fatal: A disabled or deleted service or system, out of memory condition, or other serious problem that results in a serious error requiring attention by a system administrator
Error handling is processed differently whether asynchronous and synchronous execution is specified for a routing service. In general, errors during synchronous execution cannot be retried and errors during asynchronous execution can be resubmitted.
For synchronous execution, the transaction is rolled back and an error notification is returned to the adapter that initiated the processing. The calling adapter is expected to handle the error and resubmission process. See Section 12.11.1, "About Adapter Error Handling".
For more information about adapters, including a discussion of managing errors, see Oracle Application Server Adapter Concepts.
For asynchronous execution, the user can resubmit the transaction after the error condition has been resolved. See Section 12.11.2, "How to Resubmit Messages on Errors".
For more information about error handling in Oracle Enterprise Service Bus, see "Error Handling" in Oracle Enterprise Service Bus Developer's Guide.
An adapter handles exceptions and faults using the default error handling process of the adapter.
By default, an adapter retries the message three times at five-second intervals for an error condition. The retry count and interval can be specified in the endpoint properties of the adapter service. For information about endpoint properties, see Section 6.6, "Adding Endpoint Properties for Adapter or SOAP Services".
If an inbound adapter fails to invoke a routing service for a certain number of consecutive times, it marks itself broken and disables itself. Oracle ESB Control displays this event source with a special icon to visually represent its disabled state. You can enable the adapter service.
If the next service that the inbound adapter invokes does not exist, perhaps because it has been deleted or is not enabled, then the inbound adapter processor disables itself and marks itself broken.
If a subscription fails a certain number of consecutive times, the service notifies the repository to mark it as in a broken state. The dispatcher does not dispatch this subscription after it is marked as broken.
When an error occurs while a message is being processed, it is indicated by a red icon next to the routing service in Oracle ESB Control, as shown in Figure 12-9.
In some situations, a message instance can be resubmitted. If a routing rule has been set to asynchronous execution, you can resubmit a message instance after fixing the error condition.
You can view error message, trace, and payload details by clicking the Error Details icon under the Message column on the Errors tab, as shown in Figure 12-11.
Figure 12-10 provides an example of the Error Details dialog.
After you review the error details and fix the error condition, you can resubmit the message to the invoking service.
To resubmit a message on error:
At the top of Oracle ESB Control, click the Instances icon to display the message instance processing.
In the Instances panel of the Instances view, click the message instance where the error occurred.
The Tracking tab appears, similar to Figure 12-9.
Click the Error tab to display the error information.
Click the Error Details icon under the Message column to view error message, trace, and payload details about the error condition in the Errors Detail dialog.
Click OK to close the Errors Detail dialog after reviewing the error message details.
Correct the error condition, and then click Resubmit in the Error tab.
For example, edit the message payload in the Resubmission Payload window if is incorrect and then click Resubmit.
Figure 12-11 provides an example of the resubmitted message instance.
