| Oracle® Enterprise Service Bus Developer's Guide 10g (10.1.3.3.0) Part Number E10295-01 |
|
|
View PDF |
| Oracle® Enterprise Service Bus Developer's Guide 10g (10.1.3.3.0) Part Number E10295-01 |
|
|
View PDF |
This chapter describes how to interpret error conditions and how to handle them in Oracle Enterprise Service Bus. The Instances view in the Oracle ESB Control enables you to view and manage error conditions that occur across the enterprise service bus.
This chapter contains the following topics:
You can also view the log files with Oracle Enterprise Manager to check for details on error conditions. See "Checking Log Files".
When an error occurs in Oracle Enterprise Service Bus processing, the error is noted by visual cues, such as icon and color changes, in the Oracle ESB Control. See Figure 10-4, Figure 10-5, and Figure 10-6. Also, you can also set up notifications by email, fax, or phone when errors occur. See "Setting Up Notification Channels".
Error handling in Oracle Enterprise Service Bus involves several types of errors that can occur in transaction processing:
Application or Business Faults
Retryable Exceptions: A temporary loss of a service impacting the routing of the message, but is usually resolved in a relatively short time period
Fatal Exceptions: 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. Errors during synchronous execution are rolled back and cannot be retried with Oracle ESB Control; errors during asynchronous execution can be resubmitted. For more information about asynchronous and synchronous execution, see "Specifying Synchronous or Asynchronous Execution".
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. See "Inbound Adapter Error Handling".
For asynchronous execution, the user can resubmit the transaction after the error condition has been resolved. See "User Error Handling".
This section discuses how to manage errors conditions that occur with Oracle Enterprise Service Bus.
The topics contained in this section are:
An inbound 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 "Using Endpoint Properties".
If an inbound adapter fails to invoke a routing service for a certain number of consecutive times, it marks itself broken and disables itself. The 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.
The administrator is notified of any disabled services.
For more information about adapters, including a discussion of managing errors, see Oracle Application Server Adapter Concepts.
When an error occurs during process a message instance, it is indicated by a red service icon in the Tracking tab of the Oracle ESB Control Instances view.
An error condition in the Tracking tab appears similar to Figure 11-1.
Figure 11-1 Instances View – Tracking Tab
You can view the error message, trace, and payload details by clicking on the Error Details icon in the Message column on the Errors tab, shown in Figure 11-3.
Figure 11-2 is 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.
For information about enabling validation of the payload at runtime, see Table 3-6 in "Viewing Service Definitions".
In some situations, a message instance can be resubmitted. If a routing rule has been set to asynchronous execution, you can usually resubmit a message instance after fixing the error condition.
To resubmit a message on error, follow these steps:
At the top of the 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.
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, 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 11-3 is an example of the resubmitted message instance.
