Recovering from BPEL Process Service Engine Faults

13-10 Oracle Fusion Middleware Administrators Guide for Oracle SOA Suite and Oracle BPM Suite 3. Select a fault in the table. 4. Select one of the following options: Notes: ■ You can recover callback messages in resolved and undelivered states. These messages can be displayed for recovery when you execute search criteria in which you select Callback from the Type list and either Resolved or Undelivered from the Message State list. When a callback message first enters the BPEL process service engine, its state is undelivered. When this message is resolved to the target BPEL process instance either through matching a conversation ID or a correlation, the state is switched to resolved. In both of these states, the messages have not yet been consumed. Messages in these two states can be recovered redelivered into the BPEL process service engine for consumption. In other situations, the callback messages can become stranded in both of these states. Messages in these states can also be recovered. However, there is no guarantee that stranded callback messages always remain in an undelivered state. ■ If you select Invoke from the Type list and Undelivered from the Message State list, and then click Recover, a recovery is performed. However, the Last Modified Date column remains empty for this instance on the Dashboard page of the Oracle BPEL Process Manager service component or service engine. This is the expected behavior. The last modified date is not displayed because the initial Oracle BPEL Process Manager instance for example, bpel:70004 is created by the first invocation that is, it is created, but has not yet been modified. The recovery of the undelivered invocation message always creates a new instance for example, bpel:70005. The previously created instance bpel:70004 is not used and remains permanently in the same status the Last Modified Date column is empty. This information is provided for auditing purposes only. ■ The Message States list is applicable only to callback and invoke message type recovery, and not for activity message type recovery. Managing BPEL Process Service Components and Engines 13-11 Once a message is submitted for recovery, the BPEL process service engine may take time to complete the action. This typically takes less than several seconds. During this time, the message remains visible in the Recovery page. Duplicate attempts to recover the same message in that period are ignored. Refresh the page every few seconds to receive the latest recovery status. For information about configuring the maximum number of times to attempt an invoke and callback message recovery, see Section 11.4, Configuring Automatic Recovery Attempts for Invoke and Callback Messages. Action Description Recover Retries the message in which the fault occurred. If you select messages in the exhausted state and click this button, an attempt is made to recover them immediately. Should this recovery attempt also fail, the message is returned to the exhausted state. You must then select the message and click Reset to return the message to the automatic recovery queue. If an asynchronous BPEL process encounters a transaction rollback scenario because of any underlying exception error, it rolls back to the last dehydration activity. If this is a new instance, and a receive activity was the first dehydration activity, the BPEL process service engine creates a recoverable invoke. When you click Recover to recover the invoke, the service engine creates a new instance. This instance may run to completion with no exception error. However, you continue to see the older instance identified as faulted. Mark Cancelled Marks the message so it is never delivered. If you select messages in the exhausted state and click this button, recovery is never attempted on them. Reset Select to reset exhausted messages to the undelivered state. This returns the message to the automatic recovery queue. The messages that are displayed in the exhausted state disappear from the messages table. If you select Undelivered from the Message State list and click Search, these messages are displayed. Note that callback messages in the exhausted state can also be reset to the resolved state and still remain recoverable. Note: If you define a fault policy in a BPEL process with an ora-retry action and a fault occurs, the BPEL process attempts to recover from the fault the number of times you specified with the retryCount parameter. After this period, the process continues to be in a running state. The status of an activity in the process that has not completed such as an invoke or receive shows as pending a manual recovery. This is the expected behavior. 13-12 Oracle Fusion Middleware Administrators Guide for Oracle SOA Suite and Oracle BPM Suite