Administering BPEL Process Service Components and Engines

This part describes how to administer BPEL process service components and engines.

This part includes the following chapters:

• Configuring BPEL Process Service Components and Engines
• Monitoring BPEL Process Service Components and Engines
• Managing BPEL Process Service Components and Engines

a) Configuring BPEL Process Service Components and Engines

This chapter describes how to configure BPEL process service components and service engines.

This chapter includes the following topics:

• Configuring BPEL Process Service Engine Properties
• Configuring Automatic Recovery for Oracle BPEL Process Manager
• Configuring Automatic Recovery Attempts for Invoke and Callback Messages
• Setting the Audit Level at the BPEL Process Service Component Level

i) Configuring BPEL Process Service Engine Properties

You can configure BPEL process service engine properties, which are used by the BPEL process service engine during processing of BPEL service components.

To configure BPEL process service engine properties:

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

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

The BPEL Service Engine Properties page displays properties for setting audit trail and large document thresholds, setting dispatcher thread properties, validating payload schema, and setting the audit trail level.

Description of the illustration soaadmin_bpel_props.gif

2.       Make changes to the service engine properties that are appropriate to your environment.

Property	Description
Audit Level	Select one of the following options: Off: Composite instance tracking and payload tracking information is not collected. Inherit: Logging equals the SOA Infrastructure audit level. This setting enables the BPEL audit level to automatically change when the global setting is changed. Setting a different audit level tracking in this page overrides the tracking set at the SOA Infrastructure level. Minimal: The BPEL service engine does not capture any audit details. Therefore, they are not available in the flow audit trails. All other events are logged. Production: The BPEL service engine does not capture the payload. The payload details are not available in the flow audit trails. Payload details for other BPEL activities are collected, except for assign activities. This level is optimal for most standard operations and testing. Development: Allows both composite instance tracking and payload tracking. All events are logged. However, it may have an impact on performance. This level is useful mostly for debugging purposes.
Audit Trail Threshold	Enter the maximum size in bytes of an instance audit trail before it is chunked and saved in a dehydration store table separate from the audit trail. If the threshold is exceeded, the View XML link is shown in the audit trail instead of the payload.
Large Document Threshold	Enter the maximum size of a generated document within a BPEL process component instance before it is stored in a separate table in the dehydration store.
Dispatcher System Threads	Specify the total number of threads allocated to process system dispatcher messages. System dispatcher messages are general cleanup tasks that are typically processed quickly by the server (for example, releasing stateful message beans back to the pool). Typically, only a small number of threads are required to handle the number of system dispatch messages generated during runtime.The default value is 2 threads. Any value less than 1 thread is changed to the default.
Dispatcher Invoke Threads	Specify the total number of threads allocated to process invocation dispatcher messages. Invocation dispatcher messages are generated for each payload received and are meant to instantiate a new instance. If the majority of requests processed by the service engine are instance invocations (as opposed to instance callbacks), greater performance may be achieved by increasing the number of invocation threads. Higher thread counts may cause greater CPU utilization due to higher context switching costs.The default value is 20 threads. Any value less than 1 thread is changed to the default.
Dispatcher Engine Threads	Specify the total number of threads allocated to process engine dispatcher messages. Engine dispatcher messages are generated whenever an activity must be processed asynchronously. If most of the processes deployed are durable with a large number of dehydration points (midprocess receive, onMessage, onAlarm, and wait activities), greater performance may be achieved by increasing the number of dispatcher engine threads. Note that higher thread counts can cause greater CPU utilization due to higher context-switching costs.The default value is 30 threads. Any value less than 1 thread is changed to the default.
Payload Validation	Select to enable validation of inbound and outbound messages. Nonschema-compliant payload data is intercepted and displayed as a fault.Note: This setting is independent of the SOA composite application and SOA Infrastructure payload validation level settings. If payload validation is enabled at both the service engine and SOA Infrastructure levels, data is checked twice: once when it enters the SOA Infrastructure, and again when it enters the service engine.
Disable BPEL Monitors and Sensors	Select this checkbox to disable all BPEL monitors and sensors defined for all BPEL components across all deployed SOA composite applications.

3.     Click Apply.

• If you want to configure advanced BPEL properties in the System MBean Browser, click More BPEL Configuration Properties. Properties that display include, but are not limited to, the following. Descriptions are provided for each property.
  • BpelcClasspath: The extra BPEL class path to include when compiling BPEL-generated Java sources.
  • DisableAsserts: Disables the execution of assertions in BPEL, including the bpelx:assert activity.
  • DisableSensors: Disables all calls to sensors.
  • ExpirationMaxRetry: The maximum number of times a failed expiration call (wait/onAlarm) is retried before failing.
  • ExpirationRetryDelay: The delay between expiration retries.
  • InstanceKeyBlockSize: The size of the block of instance IDs to allocate from the dehydration store during each fetch.
  • MaximumNumberOfInvokeMessagesInCache: The number of invoke messages stored in in-memory cache.
  • MaxRecoverAttempt: The number of automatic recovery attempts to submit in the same recoverable instance.
  • OneWayDeliveryPolicy: Changes whether one-way invocation messages are delivered.
  • StatsLastN: The size of the most recently processed request list.
  • SyncMaxWaitTime: The maximum time a request and response operation takes before timing out.

• Make changes appropriate to your environment.

ii) Configuring Automatic Recovery for Oracle BPEL Process Manager

Oracle SOA Suite provides an automatic recovery feature in Oracle Enterprise Manager Fusion Middleware Control that enables you to configure and recover:

• All activities (for example, wait activities and OnAlarm branches of pick activities) that have an associated expiration date and are scheduled with the SOA Infrastructure to be rescheduled
• All activities that are not complete over a provided threshold time
• All invoke and call-back messages that are unresolved

To configure automatic recovery:

1. In the navigator, right-click soa-infra and select SOA Administration>BPEL Properties.
2. Click More BPEL Configuration Properties.
3. In the Name column, click RecoveryConfig.
4. Expand RecurringScheduleConfig.

This section enables you to configure recurring recovery attempts.

5.   Set the following properties to values appropriate to your environment, and click Apply.

Property	Description
maxMessageRaiseSize	The maximum number of messages to submit for each recurring recovery attempt. Use this property to limit the impact of recovery on the server. Note that this value specifies the maximum number of messages to filter from activity, invoke, and callback queries; that is, 50 messages from each of the activity, invoke, and callback tables.The default value is 50. A negative value causes all messages selected from the database to be submitted for recovery. A 0 value causes no messages to be selected from the database (effectively disabling recovery).
startWindowTime	The start time for the daily recovery window, specified in a 24-hour notation. Therefore, 2:00 pm is specified as 14:00. The leading zero does not need to be specified for single digit hour values (1:00-9:00).The default value is midnight (00:00). Any invalid parsed time value is defaulted to midnight.
stopWindowTime	The stop time for the daily recovery window, specified in a 24-hour notation. Therefore, 2:00 pm is specified as 14:00. The leading zero does not need to be specified for single digit hour values (1:00-9:00).If you do not want daily recovery, set the start and stop window times to be the same value. If the stop window time is earlier than the start window time, both the start and stop window times are changed to their respective default values.The default value is midnight (04:00), effectively setting recurring recovery to run until 04:00.Any invalid parsed time values default to 00:00.
subsequentTriggerDelay	The number of seconds between recovery attempts during daily recurring startup recovery periods. If the next recovery trigger falls outside of the current recovery period, that trigger is not scheduled until the next recurring recovery period (tomorrow).The default value is 300 (five minutes). A negative value causes the default to be selected.
threshHoldTimeInMinutes	This is the threshold time in minutes to ignore for automatic recovery processing. For automatic invoke and callback recovery, this value is used for picking messages with a received date less than the threshhold time.For automatic activities recovery, this value is used for picking activities with a modification date less than the threshold time.This property prevents the message contention scenario in which a BPEL process service engine picks up a message for recovery while another thread on the service engine is in the middle of processing the message. This property ensures that the recovery part of the service engine only attempts recovery on messages older than the value for threshHoldTimeInMinutes.The default value is 10 minutes. A negative value causes the default to be selected.

6.

7.  Expand StartupScheduleConfig.

This section enables you to configure server startup recovery attempts.

8.  Set the following properties to values appropriate to your environment, and click Apply.

Property	Description
maxMessageRaiseSize	The maximum number of messages to submit for each startup recovery attempt. Use this property to limit the impact of recovery on the server. Note that this value specifies the maximum number of messages to filter from activity, invoke, and callback queries; that is, 50 messages from each of the activity, invoke, and callback tables.The default value is 50. A negative value causes all messages selected from the database to be submitted for recovery. A zero value causes no messages to be selected from the database (effectively disabling recovery).
startupRecoveryDuration	Specifies the number of seconds that the startup recovery period lasts. After the server starts, it goes into a startup recovery period. During this period, pending activities and undelivered callback and invocation messages are resubmitted for processing.The default value is 600 (ten minutes). A negative or zero value disables startup recovery.
subsequentTriggerDelay	The number of seconds between recovery attempts during the server startup recovery period. If the next recovery trigger falls outside the server startup period, that trigger is not scheduled and the server moves into the recurring recovery period.The default value is 300 (five minutes). A negative value causes the default to be selected.

9.

Note:In a cluster, it is possible for different nodes to concurrently attempt an automatic recovery of the same items. The first node to lock the item attempts the recovery, while other nodes may raise an exception that can be safely ignored.

iii) Configuring Automatic Recovery Attempts for Invoke and Callback Messages

You can configure the number of automatic recovery attempts to submit in the same recoverable instance. The value you provide specifies the maximum number of times invoke and callback messages are recovered. If the value is 0 (the default value), it recovers all messages. Once the number of recovery attempts on a message exceeds the specified value, a message is marked as nonrecoverable.

To configure automatically recovery attempts for invoke and callback messages:

1. In the navigator, right-click soa-infra and select SOA Administration>BPEL Properties.
2. Click More BPEL Configuration Properties.
3. Go to MaxRecoverAttempt.
4. In the Value field, enter a value.
5. Click Apply.

iv) Setting the Audit Level at the BPEL Process Service Component Level

You can set the audit level for a BPEL process service component. This setting takes precedence over audit level settings at the SOA Infrastructure, service engine, and SOA composite application levels.

The service component level setting is only available for BPEL processes and is not supported for the mediator, human workflow, and business rule service components.

There are two ways to set the audit level for BPEL process service components. Supported values are Off, Minimal, Inherit, Development, and Production.

To set the audit level for BPEL process service components:

• In the System MBean Browser of Oracle Enterprise Manager Fusion Middleware Control:
  1. In the navigation tree, expand the SOA folder.
  2. Right-click soa-infra, and select Administration>System MBean Browser.
  3. Select Application Defined MBeans>oracle.soa.config>Server:server_name>SCAComposite>Composite_Name>SCAComposite.SCAComponent>BPEL_Service_Component>Properties.
  4. Click the Add icon.
  5. Expand the Element_number folder.
  6. From the many list, select false.
  7. In the name field, enter bpel.config.auditlevel.
  8. In the value field, enter a value.
  9. Click Apply.

b) Monitoring BPEL Process Service Components and Engines

This chapter describes how to monitor BPEL process service components and service engines.

This chapter includes the following topics:

• Viewing the Audit Trail and Process Flow of a BPEL Process Service Component
• Monitoring BPEL Process Service Component Instances and Faults
• Monitoring BPEL Process Service Component Instances
• Monitoring Sensor Data and Values in BPEL Process Service Components
• Monitoring BPEL Process Service Engine Instances and Faults
• Monitoring BPEL Process Service Engine Request and Thread Statistics

• Monitoring BPEL Process Service Engine Instances
• Monitoring Deployed BPEL Processes in the Service Engine

Viewing the Audit Trail and Process Flow of a BPEL Process Service Component

This section describes how to view the audit trail and process flow of a BPEL process service component in a SOA composite application instance.

Note:This section assumes a SOA composite application instance has been initiated.

To view the audit trail and process flow of a BPEL process service component:

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.

The Dashboard page for the selected composite application appears.

2.   Use one of the following methods to select an instance of the application:

• For recent instances of this application, click the instance number of an instance in the Instance ID column of the Recent Instances
• For all instances of this application, click the Instances tab, then click a specific instance in the Instance ID

The Flow Trace page displays the following details:

• The Faults section shows the faults occurring in the services, service components, and references that comprise the SOA composite application. Sensors enable you to monitor BPEL process activities, variables, and faults during runtime. Selecting a fault highlights the row in the Trace section in which the fault occurred. Closing the fault clears the selection in the Trace

• The Sensors section displays details about composite sensors included in the service and reference binding components of the SOA composite application. The total number of sensors is shown in the section header. Composite sensors can be added to service and reference binding components during design time in Oracle JDeveloper. You cannot add composite sensors to service components. Selecting a composite sensor in this section highlights the service or reference in the Trace section in which composite sensor data was collected. Closing the sensor clears the selection in the Trace

Note: Expand the Faults or Sensors sections one at a time. The fault or sensor information is only displayed for viewing in this way.

• The Trace section shows the sequence of the message flow through the services, service components, and references that comprise the SOA composite application.

The flow trace is a runtime trail of a message flow identified by an execution context ID (ECID) that is displayed in the upper right-hand corner of the page. An ECID enables you to track a message flow that crosses instances of different composite applications. The flow trace lists all services, references, and components across composite applications participating in the flow.

Description of the illustration bp_compsensor3.gif

For the flow example in the Trace section, the service binding component, service components, and reference binding component involved in the flow have successfully received and processed messages.

• Select a fault in the Faults

This highlights the row in the Trace section in which the fault occurred.

• Close the fault to clear the selection in the Trace
• Expand the Sensors section to display composite sensors.

Description of the illustration bp_compsensor1.gif

• Select a sensor in the Sensors

This highlights the row in the Trace section in which the composite sensor data was collected.

If there are BPEL process messages that require recovery from the Recovery page of the BPEL process service engine, a BPEL Message Recovery Required inline warning message and recovery icon are displayed.

Description of the illustration bpel_recoveryecid2.gif

• Click Show Details or the recovery icon to display a Warning dialog with the following recovery details:
  • The number of invoke, callback, and activity recoverable message types
  • The ECID value

Description of the illustration bpel_recoveryecid.gif

Use this information for creating search criteria for filtering the recoverable messages on the Recovery page of the BPEL process service engine. You can copy the ECID number from the Warning dialog, paste it into the ECID field, and select the recoverable message type from the Type list.

The display of this message recovery information on the Flow Trace page is controlled by the AuditConfig property in the System MBean Browser. By default, this property is set to All, which enables this information to be displayed. To prevent this information from displaying on the Flow Trace page, set the bpelRecoveryStatus key to Off for the AuditConfig property in the More SOA Infra Advanced Configuration Properties section of the SOA Infrastructure Common Properties page.

Note the following restrictions with ECIDs:

• A separate ECID is displayed for each instance of a composite application and not for the composite level ECID that can track the complete flow of any instances for the composite application.
• To get complete flow information, you must find the composite level ECID in the log files. Use that value to get all information for a particular composite and therefore all its executed instances.
• ECIDs are not propagated through business events. This can limit the amount of logging information that is collected. For example, if you publish an event that is subscribed to in the same composite application, limited logging information is available.
• In the Instance column of the Trace section, click a specific BPEL process service component instance. Service component instances can be accessed from this section; services and references cannot be accessed.

The Instance page appears.

Description of the illustration bpel_comp_audittrail.gif

Use these four pages to view the audit trail, flow, sensor values, and faults of a BPEL process service component instance. The following links provide additional details about the instance:

• Flow Tracelink: Click the breadcrumbs in the upper left-hand corner of the page to access the flow trace for the ECID (composite instance) that contains this BPEL component instance.
• Information icon: Click the information icon to the right of the name of the BPEL component (in the page title) to see biographical information about this BPEL instance. This information includes a summary of the instance, including instance ID, ECID, instance startup time or last modification time, instance state (for example, running), and number of faults.

This icon is only displayed on the Audit Trail pages of BPEL processes and Oracle Mediators, and not on the pages of human tasks and business rules.

• Audit Level Settings: Click to display information details, such as the audit level used by this instance.

• View Raw XML: Click to display the raw XML of the audit trail.

The Audit Trail page displays execution details about the activities in the BPEL process.

• Scroll through the audit trail to check for errors and expand the payload links to view their contents at a given point in the flow.

Notes:

• Canceled onMessage branches of pick or scope activities that did not execute are displayed in the audit trail. However, the flow diagram does not show these same canceled onMessage branches. This is the expected behaviour.
• The following error message appears when a transaction is displayed as rolled back in the Audit Trail page:
• The transaction was rolled back. The work performed for bpel
• instance "instance_ number" was rolled back to the previous
• Dehydration point, but the audit trail has been saved.
• You can recover the instance from the recovery console by
• resubmitting the callback message or activity for execution

This message does not specifically state whether recovery should happen on either the activity or the callback. This is the intended behavior. Oracle recommends that you do not recover each instance through the audit messages. Instead, set up automatic recovery to recover these instances.

• Click the Flow tab

A flow diagram of the BPEL process activities appears. This flow diagram shows a fault highlighted in a BPEL process activity.

Description of the illustration bpel_comp_flow1.gif

• Click an activity to view the flow of the payload through the process.

Note:

If using Microsoft Internet Explorer, you can click Copy details to clipboard to copy the activity details to the clipboard. If using Mozilla Firefox, this link does not appear. Instead, you must manually select the text, and copy and paste it to a file.

• Scroll through the flow diagram to check for errors and click the highlighted activity to view error messages.

Description of the illustration bpel_comp_flow2.gif

• Close the message.
• Click the Faults

This page shows the error message, whether you can recover from the fault, the time at which the fault occurred, and the activity in which the fault occurred. This page displays the faults in the BPEL component instance (but not the faults that occurred in a service or reference binding component).

If a fault occurs when processing activities, the activity location of the fault is not usually shown in the Activity column.

• For Oracle BPEL Process Manager, this column only shows a receive activity that has timed out. In all other cases, this column is empty.
• For Oracle BPM, this column is always empty.

This is the expected behaviour.

You can recover from instance faults identified as recoverable. This page lists all instance faults, recoverable or not. The component instance faults that occurred in a service or reference are not listed here.

This page enables you to target individual faults from which to recover, and provides a degree of fault recovery granularity not available on other pages.

Description of the illustration bpel_instancedetails_faults.gif

However, you cannot perform bulk fault recoveries on this page. To perform bulk fault recovery, use one of the following pages:

• Faults page of the BPEL process service engine or of a specific BPEL process service component
• Faults and Rejected Messages page of a specific SOA composite application or of the SOA Infrastructure
• Select a fault for recovery that has been identified as recoverable through one of the following methods. The page refreshes to display a fault recovery section at the bottom of the page.

• If you click a fault in the Error Message column, a popup message displays details about the fault, including the fault ID, fault time, fault location, fault type, and complete error message text. If the fault is identified as recoverable, a Recover Now button that you can click is displayed.
• You click a fault identified as recoverable in the Recovery

• Select an action from the Recovery Action

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	Terminates the entire instance.
Replay	Replays the entire scope activity 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 faulted activity as a success).

Your selection causes additional fields to appear. For example, the following fields are displayed if you select Rethrow:

• Description of the illustration bpel_instancefaultrec2.gif
• Use the After Successful Retry list to select defined actions to invoke after a successful retry. If you select a variable in the Variable list, you can edit the value in the Value text box.
• Click the Back button of your browser to exit the flow diagram.

c) Monitoring BPEL Process Service Component Instances and Faults

You can monitor recent instances and faults for BPEL process service components. Each service component in a SOA composite application has its own instance ID. These IDs are different from the overall instance ID of the SOA composite application of which each service component is a part.

To monitor BPEL process service component instances and 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.    In the Component Metrics section, select the BPEL process service component.

3.    Click Dashboard.

The upper part of the Dashboard page displays the following details:

• Recent instances of the BPEL process service component, including the instance ID, the state of the instance (for example, completed successfully or faulted), the start time, the last modification time, and logs describing the instance.
• Recent faults in the BPEL process service component, including the error message, whether you can recover from the fault, the time at which the fault occurred, the instance ID of the BPEL service component, the BPEL activity in which the fault occurred, and logs describing the fault.
• The average processing time for each activity in the BPEL process service component.

Description of the illustration bpel_comp_dash_upper.gif

• In the Recent Instances section, perform the following tasks:
  • . In the Instance ID column, click an instance ID for a service component to view its audit trail, process flow, sensor values, and faults.

1. In the Logs column, click a specific log to access the Log Messages page with filtered messages specific to that instance.
2. Click Show All below the section to access the Instances page of the service component.

• In the Recent Faults section, perform the following tasks:
  1. . In the Error Message column, click an error message to display complete information about the fault. If the fault is identified as recoverable, click the Recover Now link to perform fault recovery.

1. In the Recovery column, click a fault identified as Recoverable to perform fault recovery at the component instance level.
2. In the Logs column, click a specific log to access the Log Messages page with filtered messages specific to that instance.
3. Click Show All below the section to access the Faults page of the service component.

The lower part of the Dashboard page displays the following details:

• Details about the time distribution for activities, including the activity name, the total number of activities for all instances, and the average execution time

Description of the illustration bpel_activity_time_dist.gif

• A graphical representation of the number of successful, faulted, and incoming (pending) instances of the BPEL process service component over a specific time range. Click Table View to display throughput details for the last five minutes, including the throughput for successful instances, the total faults throughput, and the instance throughput.

Description of the illustration bpel_comp_dash_lower.gif

Monitoring BPEL Process Service Component Instances

You can monitor BPEL process service component instances. Each service component has its own unique instance ID. This ID is in addition to the instance ID of the overall SOA composite application of which this service component is a part.

To monitor BPEL process service component instances:

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

3.      Click Instances.

The Instances page displays the following details:

• A utility for searching for a specific BPEL service component instance by specifying criteria and clicking Search.
• BPEL process service component instances, including the instance ID, instance state (for example, completed or faulted), instance start time, last instance modification time, and log files describing the instance.

Description of the illustration bpel_com_dash_instances.gif

• In the Instance ID column, click an instance ID for a service component to view its audit trail, process flow, sensor values, and faults.
• In the Logs column, click a specific log to access the Log Messages page with filtered messages specific to that instance.

Monitoring Sensor Data and Values in BPEL Process Service Components

You can view the fault, activity, and variable sensor data of a BPEL process service component. You design sensors in BPEL processes and trackable fields in Oracle JDeveloper. Sensors enable you to monitor BPEL process activities, variables, and faults during runtime.

To monitor sensor data and values in BPEL process service components:

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.   Use one of the following methods to select an instance of the application:

• For recent instances of this application, click the instance number of an instance in the Instance ID column of the Recent Instances
• For all instances of this application, click the Instances tab, then click a specific instance in the Instance ID

The Flow Trace page appears.

• Click a specific BPEL process service component in the Instance column of the Trace
• Click the Sensor Values
• Select a sensor to view details.

If you created JMS sensors in your BPEL process, JMS sensor values are not displayed in Oracle Enterprise Manager Fusion Middleware Control. Only sensor values in which the sensor action is to store the values in the database appear (for example, database sensor values).

Monitoring BPEL Process Service Engine Instances and Faults

You can monitor instances and faults of all BPEL process service components running in the BPEL process service engine. These BPEL process service components can be part of separate SOA composite applications.

To monitor BPEL process service engine instances and 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 Dashboard.

The upper part of the Dashboard page displays recent instances of all BPEL process service components running in the BPEL process service engine, including the instance ID of the service component, the service component name, the SOA composite application of which the service component is a part, the state of the instance (for example, completed successfully or faulted), the instance start time, the last modification time, and logs describing the instance.

Description of the illustration bpel_dashboard_upper.gif

3.    In the Recent Instances section, perform the following monitoring tasks:

1. In the Instance ID column, click an instance ID for a service component to view its audit trail, process flow, sensor values, and faults.
2. In the Component column, click a specific service component to access its home page.
3. In the Composite column, click a specific SOA composite application to access its home page.
4. In the Logs column, click a specific log to access the Log Messages page with filtered messages specific to that instance.
5. Click Show All below the section to access the Instances page of the service engine.

The lower part of the Dashboard page displays the following details:

• The service components running in the service engine, the SOA composite applications of the service components, the state of the applications (for example, running), and the total, running, and faulted instances in the service engine.
• The recent faults in the service engine, including the error message, whether you can recover from the fault, the time at which the fault occurred, the SOA composite application in which the fault occurred, the service component, the instance ID of the service component, the activity in which the fault occurred, and log files describing the fault.

Description of the illustration bpel_dashboard_low.gif

• In the Components section, perform the following tasks:
  • . In the Name column, click a specific service component to access its home page.

1. In the Composite column, click a specific SOA composite application to access its home page.
2. Click Show All below the section to access the Deployed Components page of the service engine.

• In the Recent Faults section, perform the following tasks:
  • . In the Error Message column, click an error message to display complete information about the fault. If the fault is identified as recoverable, click the Recover Now link to perform fault recovery.

1. In the Recovery column, click a fault identified as Recoverable to perform fault recovery at the component instance level.
2. In the Composite column, click a specific SOA composite application to access its home page.
3. In the Component column, click a specific service component to access its home page.
4. In the Component Instance ID column, click an instance ID for a service component to view its audit trail, process flow, sensor values, and faults.
5. In the Logs column, click a specific log to access the Log Messages page with filtered messages specific to that fault.

Description of the illustration bpel_comp_sen.gif

Monitoring BPEL Process Service Engine Request and Thread Statistics

You can monitor request and thread statistics for all BPEL process service components running in the service engine.

To monitor BPEL process service engine request and thread statistics:

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

The upper part of the Statistics page displays the following details. Click the Help icon for additional details.

• Pending requests in the service engine
• Active requests in the service engine
• Thread statistics for the service engine

Description of the illustration bpel_stats_upper.gif

The lower part of the Statistics page displays details about the count and minimum, maximum, and average request processing times.

Monitoring BPEL Process Service Engine Instances

You can monitor all BPEL process service component instances running in the service engine. These BPEL process service components can be part of separate SOA composite applications.

To monitor BPEL process service engine instances:

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

The Instances page displays the following details:

• A utility for searching for a specific instance by specifying criteria and clicking Search.
• Instances, including the instance ID of the service component, the service component name, the SOA composite application name, the state of the instance (for example, completed successfully, running, or faulted), the instance start time, the last modification time, and log files describing the instance.

Description of the illustration bpel_instances.gif

• In the Instances section, perform the following monitoring tasks:
  • . In the Instance ID column, click an instance ID for a service component to view its audit trail, process flow, sensor values, and faults.

1. In the Component column, click a specific service component to access its home page.
2. In the Composite column, click a specific SOA composite application to access its home page.
3. In the Logs column, click a specific log to access the Log Messages page with filtered messages specific to that instance.

Monitoring Deployed BPEL Processes in the Service Engine

You can monitor all deployed SOA composite applications with BPEL process service components running in the service engine.

To monitor deployed BPEL processes in service engines:

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 Deployed Components.

The Deployed Components page displays the following details:

• A utility for searching for a specific deployed SOA composite application by specifying criteria and clicking Search.
• Details about deployed SOA composite applications with BPEL process service components running in this service engine, including the service component name, the SOA composite application, the current status, and the total, running, and faulted instances in the service engine.

Description of the illustration bpel_se_deployedcomps.gif

• In the Name column, click a specific service component to access its home page.
• In the Composite column, click a specific SOA composite application to access its home page.

Managing BPEL Process Service Components and Engines

This chapter describes how to manage BPEL process service components and service engines.

This chapter includes the following topics:

• Recovering from BPEL Process Service Component Faults
• Managing BPEL Process Service Component Policies
• Recovering from BPEL Process Service Engine Faults
• Performing BPEL Process Service Engine Message Recovery

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 standard 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

3.     Click Faults.

The Faults page displays the following details:

• A utility for searching for a specific fault by specifying 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.

• 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 is displayed 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.

• 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	Terminates the entire instance.
Replay	Replays the entire scope activity 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 faulted activity as a success).

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

• . Click the Show only recoverable faults checkbox to display only faults from which you can recover.

1. From the Fault Type list, select to display all faults, system faults, business faults, or Oracle Web Services Manager (OWSM) faults in the faults table. Click the Help icon for a description of these fault types.
2. 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 is also displayed when you click an error message.
3. 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.
4. In the Logs column, click a link to access the Log Messages page with filtered messages specific to that instance.

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 section 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 is displayed in the policies table.

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

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

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.

• Select an action from the Recovery Action

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	Terminates the entire instance.
Replay	Replays the entire scope activity 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 faulted activity as a success).

• Perform the following additional monitoring tasks from within the faults table:
  • . Click the Show only recoverable faults checkbox to only display faults from which you can recover.

1. 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.
2. 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 is also displayed when you click an error message.
3. In the Composite column, click a specific SOA composite application to access its home page.
4. In the Component column, click a specific service component to access its home page.
5. 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.

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 the Recovery 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 fails while the instance is processing, you can manually perform recovery when the server restarts to ensure that all message records are recovered.

You can also manage messages that have failed automatic recovery attempts by the BPEL process service engine. To ensure that automatic recovery of these messages is not attempted multiple times, these messages are placed in the exhausted state. You can then perform one of the following actions on these messages:

• Return them to the automatic recovery queue
• Never attempt a recovery on them again
• Attempt to recover them immediately

For example, assume you have a BPEL process that writes to a database adapter. If the database is down, these messages are sent to a recovery queue. Automatic recovery of these messages fails while the database is down. Such messages are marked with the exhausted state so that automatic recovery is not attempted on them again. When the database begins running again, you can reset these messages (return them to the automatic recovery queue) so that an automatic recovery is attempted on them again.

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 Refresh Alarm Table button for resynchronizing lost, in-memory, Quartz-scheduled jobs in the database. For example, assume a timer on a wait activity or on an onAlarm branch of a pick activity was initiated, but the transaction was rolled back. You can resynchronize these jobs with the BPEL instances residing in the wait activity/onAlarm branch in the database.
• A utility for searching for a specific message failure by specifying criteria and clicking Search. Click the Help icon for details.

You can enter the execution context ID (ECID) value in the ECID field. The ECID value enables you to track a message flow that crosses instances of different composite applications. If there are BPEL process messages requiring recovery and the AuditConfig property in the System MBean Browser is set to All (the default value), the following message is displayed in the Trace table of the Flow Trace page:

BPEL Message Recovery Required

Clicking Show Details or the recovery icon that appears next to this message displays a Warning dialog with information about the number of invoke, callback, and activity recoverable message types and the ECID value. You can copy the ECID value from the Warning dialog, paste it into the ECID field, and select the recoverable message type from the Type list as part of creating your search criteria on the Recovery page.

Note:

Oracle recommends that you add an index on the DLV_MESSAGE.ECID column of the DLV_MESSAGE table to improve SQL query performance when searching messages for a specific ECID value. This is because if there are too many entries in the DLV_MESSAGE table, the search query may be slow and may also overload the database. For information on adding an index, see Chapter "Creating Indexes"of the Oracle Database Administrator's Guide.

• Message failures 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. Depending on the state, you can recover these messages immediately, cancel these messages, or reset these messages for automatic recovery.

Description of the illustration bpel_se_recov.gif

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 When a callback message first enters the BPEL process service engine, its state is undelivered. When this message
  • 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 behaviour. 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. is resolved to the target BPEL process instance either through matching a conversation ID or a correlation, the state is switched to resolve. 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

• Select a fault in the table.
• Select one of the following options:

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.

• 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 retry Count 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 behaviour.