12 Managing BPEL Process Service Components and Engines

12.1 Recovering from BPEL Process Service Component Faults

You can monitor and perform individual and bulk fault recoveries for BPEL process service components that are identified as recoverable. For BPEL process faults to be identified as recoverable, there must be a fault policy defined that is bound to the fault (through the fault-bindings.xml file) and which triggers the action ora-human-intervention. However, without defining any fault policies, the fault takes its normal course as either a recoverable or nonrecoverable fault.

To recover from BPEL process service component faults:

1. Access this page through one of the following options:

   From the SOA Infrastructure Menu...	From the SOA Folder in the Navigator...
   Select Home. Select the Deployed Composites tab. In the Composite section, select a specific SOA composite application.	Under soa-infra, select a specific SOA composite application.

   
   

2. Select the BPEL process service component in the Component Metrics section.

3. Click Faults.

   The Faults page displays the following details:

   • A utility for searching for a specific fault by specifying a criteria and clicking Search. Click the Help icon for details.

   • Faults that occurred in the service component, including the fault ID, error message, whether you can recover from the fault, time at which the fault occurred, service component instance ID, activity in which the fault occurred, and a link to a log file describing the fault.

   
   Description of the illustration bpel_comp_faults.gif
   
   

   BPEL process service component faults identified as recoverable can be recovered.

4. Select faults for recovery using one of the following methods. Note that fault recovery selection at the BPEL process service component level equals the SOA Infrastructure level, SOA composite application level, and Oracle Mediator service component level.

   For...	Then...
   Single fault recovery	There are three options from which to choose for single-fault recovery: Click the row of the fault that has been identified as recoverable. With the row highlighted, select a specific action from the Recovery Action list, as described in Step 5. In the Recovery column, click the Recover link to access the Faults page of the instance audit trail to perform fault recovery. In the Error Message column, click the message of a fault that has been identified as recoverable. This displays complete fault details, including the fault ID, fault time, fault location, fault type, and error message text. A Recover Now option displays for recoverable faults. Click Recover Now to access the Faults page of the instance audit trail to perform fault recovery.
   Bulk fault recovery	There are two options from which to choose for bulk-fault recovery: Use Shift+Click or Control+Click to select specific faults in the rows. or From the Select menu, choose Select All Recoverable. Then use Shift+Click or Control+Click to deselect the faults to not include in the recovery operation. Then: Select an action from the Recovery Action list, as described in Step 5. Note: Only the actions applicable to all selected faults are available.
   Recovery of all faults	From the Select menu, choose Select All Recoverable. Select an action from the Recovery Action list, as described in Step 5. Note: Only the actions applicable to all selected faults are available.

   
   

   Note:

   In most cases, fault policy actions are automatically executed. The only exception is if you defined a fault policy that uses the action ora-human-intervention. This action creates a recoverable fault that can be recovered from Oracle Enterprise Manager Fusion Middleware Control Console.

5. Select an action from the Recovery Action list.

   Action	Description
   Retry	Retries the instance directly. An example of a scenario in which to use this recovery action is when the fault occurred because the service provider was not reachable due to a network error. The network error is now resolved.
   Abort	Aborts the entire instance.
   Replay	Replays the entire scope again in which the fault occurred.
   Rethrow	Rethrows the current fault. BPEL fault handlers (catch branches) are used to handle the fault. By default, all exceptions are caught by the fault management framework unless an explicit rethrow fault policy is provided.
   Continue	Ignores the fault and continues processing (marks the faulting activity as a success).

   
   

6. Perform the following additional monitoring tasks from within the faults table:

   1. Click the Show only recoverable faults check box to display only faults from which you can recover.

   2. From the Fault Type list, select to display all faults, system faults, business faults, or Oracle Web Service Manager (OWSM) faults in the faults table. Click the Help icon for a description of these fault types.

   3. From the View list, select Columns > Fault ID to display the fault IDs for each error message. The fault ID is automatically generated and uniquely identifies a fault. The fault ID also displays when you click an error message.

   4. In the Component Instance ID column, click a specific service component ID to access task details about the instance (for example, the current state of a task). Note that rejected messages do not have a component instance ID.

   5. In the Logs column, click a link to access the Log Messages page with filtered messages specific to that instance.

For more information, see the following documentation:

• Section 1.4.3.1, "Understanding Fault Recovery"

• Section 8.5.1, "Examples of Fault Recovery for BPEL Processes"

• Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite

• Oracle Fusion Middleware Administrator's Guide for details about viewing and searching log files

12.2 Managing BPEL Process Service Component Policies

You can attach and detach policies to and from BPEL process service components in currently deployed SOA composite applications. Policies apply security to the delivery of messages. Oracle Fusion Middleware uses a policy-based model to manage Web services.

To manage BPEL process service component policies:

1. Access this page through one of the following options:

   From the SOA Infrastructure Menu...	From the SOA Folder in the Navigator...
   Select Home. Select the Deployed Composites tab. In the Composite section, select a specific SOA composite application.	Under soa-infra, select a specific SOA composite application.

   
   

2. Select the BPEL process service component in the Component Metrics section.

3. Click Policies.

   The Policies page enables you to attach and detach policies to and from BPEL process service components. The policies table displays the attached policy name, the policy reference status (enabled or disabled) that you can toggle, the category (Management, Reliable Messaging, MTOM Attachment, Security, or WS Addressing), the violations, and the authentication, authorization, confidentiality, and integrity failures since the SOA Infrastructure was last restarted.

   
   Description of the illustration bpel_comp_policy.gif
   
   

4. Click Attach/Detach.

   If multiple components are available, you are prompted to select the service or component for which to perform the attachment or detachment.

5. Select the service or component to which to attach or detach a policy.

   This invokes a dialog for attaching or detaching policies.

   Policies currently attached appear in the Attached Policies section. Additional policies available for attachment appear in the Available Policies section.

6. Select to attach policies appropriate to your environment.

7. Click Attach.

8. When you are finished attaching policies, click Validate.

9. If an error message appears, make the necessary corrections until you no longer have any validation errors.

10. Click OK.

    The attached policy displays in the policies table.

For more information, see the following documentation:

• Section 1.4.3.2, "Understanding Policies"

• Section 8.8, "Managing SOA Composite Application Policies" for the dialogs that display during policy attachment

• Oracle Fusion Middleware Security and Administrator's Guide for Web Services for definitions of available policies and details about which ones to use for your environment

12.3 Recovering from BPEL Process Service Engine Faults

You can monitor and perform individual and bulk recoveries of faults occurring in BPEL process service engines that are identified as recoverable. All BPEL process service component faults, regardless of the SOA composite application instance of which they are a part, can be viewed in the BPEL process service engine. For BPEL process faults to be identified as recoverable, there must be a fault policy defined that is bound to the fault (through the fault-bindings.xml file) and which triggers the action ora-human-intervention. However, without defining any fault policies, the fault takes its normal course as either a recoverable or nonrecoverable fault.

To recover from BPEL process service engine faults:

1. Access this page through one of the following options:

   From the SOA Infrastructure Menu...	From the SOA Folder in the Navigator...
   Select Service Engines > BPEL.	Right-click soa-infra. Select Service Engines > BPEL.

   
   

2. Click Faults.

   The Faults page displays the following details:

   • A utility for searching for a specific fault by specifying a criteria and clicking Search. Click the Help icon for details.

   • Faults that occurred in the service engine, including the fault ID, error message, whether you can recover from the fault, the time at which the fault occurred, the SOA composite application and service component in which the fault occurred, and the service component instance ID.

   
   Description of the illustration bpel_se_faults.gif
   
   

   BPEL process service engine faults identified as recoverable can be recovered.

3. Select faults for recovery using one of the following options. As with fault recovery at the SOA Infrastructure level, SOA composite application level, and Oracle Mediator service component level, you can perform single fault recovery, bulk fault recovery, and recovery of all faults. See Step 4 of Section 12.1, "Recovering from BPEL Process Service Component Faults" for instructions on selecting faults to perform these types of recovery.

   Note:

   In most cases, fault policy actions are automatically executed. The only exception is if you defined a fault policy that uses the action ora-human-intervention. This action creates a recoverable fault that can be recovered from Oracle Enterprise Manager Fusion Middleware Control Console.

4. Select an action from the Recovery Action list.

   Action	Description
   Retry	Retries the instance with an option to provide a retry success action. An example of a scenario in which to use this recovery action is when the fault occurred because the service provider was not reachable due to a network error. The network error is now resolved.
   Abort	Aborts the entire instance.
   Replay	Replays the entire scope again in which the fault occurred.
   Rethrow	Rethrows the current fault. BPEL fault handlers (catch branches) are used to handle the fault. By default, all exceptions are caught by the fault management framework unless an explicit rethrow fault policy is provided.
   Continue	Ignores the fault and continues processing (marks the faulting activity as a success).

   
   

5. Perform the following additional monitoring tasks from within the faults table:

   1. Click the Show only recoverable faults check box to only display faults from which you can recover.

   2. From the Fault Type list, select to display all faults, system faults, business faults, or OWSM faults in the faults table. Click the Help icon for a description of these fault types.

   3. From the View list, select Columns > Fault ID to display the fault IDs for each error message. The fault ID is automatically generated and uniquely identifies a fault. The fault ID also displays when you click an error message.

   4. In the Composite column, click a specific SOA composite application to access its home page.

   5. In the Component column, click a specific service component to access its home page.

   6. In the Component Instance ID column, click a specific service component ID to access task details about the instance (for example, the current state of a task). Note that rejected messages do not have a component instance ID.

For more information, see the following sections:

• Section 1.4.3.1, "Understanding Fault Recovery" for conceptual details about faults

• Section 8.5.1, "Examples of Fault Recovery for BPEL Processes"

12.4 Performing BPEL Process Service Engine Message Recovery

You can perform a manual recovery of undelivered invoke or callback messages due to a transaction rollback in the process instance. Recovery of invoke messages applies to asynchronous BPEL processes only. Synchronous BPEL processes return an error to the calling client and are not recoverable from this page. Recoverable activities are activities that failed and can be recovered. For example, if you are using the file adapter to initiate an asynchronous BPEL process and your system crashes while the instance is processing, you can manually perform recovery when the server restarts to ensure that all message records are recovered.

To perform BPEL process service engine message recovery:

1. Access this page through one of the following options:

   From the SOA Infrastructure Menu...	From the SOA Folder in the Navigator...
   Select Service Engines > BPEL.	Right-click soa-infra. Select Service Engines > BPEL.

   
   

2. Click Recovery.

   The Recovery page displays the following details:

   • A utility for searching for a specific message failure by specifying a criteria and clicking Search. Click the Help icon for details.

   • Message failure in the service engine, including the conversation ID, whether you can recover from the message failure, the service component and composite application in which the failure occurred, and the time at which the fault occurred.

   
   Description of the illustration bpel_se_recov.gif
   
   

3. Select a fault in the table.

4. Select one of the following options:

   Action	Description
   Recover	Retries the message in which the fault occurred. 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.

   
   

   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.

   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, 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.

12.5 Disabling BPEL Monitors and Sensors

By default, BPEL sensors defined in SOA composite applications are enabled. You can disable all BPEL sensors (variable, fault, and activity) at the following levels:

• At the BPEL service engine level (defined for all the BPEL components across all deployed SOA composite applications).

• At the SOA composite application level (applies to all BPEL sensors defined for all BPEL components that comprise the composite). The service engine level setting takes precedence when sensors are disabled (that is, the composite level setting for enabling and disabling BPEL sensors has no impact if the global service engine level setting is disabled). If the global service engine level setting is enabled (the default setting), you can enable or disable BPEL sensors at the composite level.

You can also disable BPEL monitors, which are used to capture BPEL process metrics that are sent to Oracle BAM Server, and then used for analysis and graphic display.

Disabling sensors means that sensor values are not captured during run time. This results in the values not being displayed in the Sensor Values page of the BPEL audit trail.

You cannot enable or disable BPEL sensors at the service component level.

To disable BPEL monitors and sensors at the service engine level:

1. Access the BPEL Service Engine Properties page by following the steps in Section 10.1, "Configuring BPEL Process Service Engine Properties."

2. Select the Disable BPEL Monitors and Sensors check box.This action enables the BPEL engine to disable all calls to sensors.

3. Click Apply.

To disable BPEL monitors and sensors at the SOA composite application level:

1. Go to the home page of the SOA composite application in which you want to disable monitors and sensors.

2. From the Settings menu, select Enable/Disable BPEL Monitors and Sensors. This selection only displays for composites that have a BPEL service component, regardless of whether that component includes sensors.

   
   Description of the illustration sca_sensordis.gif
   
   

3. If sensors are enabled at the BPEL process service engine level, the current setting for sensors at the SOA composite application level indicates which confirmation message displays next.

   1. If monitors and sensors are enabled at the composite level, you are prompted to confirm to disable all BPEL monitors and sensors defined for all BPEL components that comprise the selected composite.

   2. If monitors and sensors are disabled at the composite level, you are prompted to confirm to enable all BPEL monitors and sensors defined for all BPEL components that comprise the selected composite.

4. If monitors and sensors are disabled at the BPEL process service engine level, then an inline message is displayed indicating that you cannot modify the monitor and sensor values. The current setting for monitors and sensors at the composite level is not shown in this case.

For more information about BPEL monitors, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.