17 Configuring BPEL Process Service Components and Engines

This chapter describes how to configure BPEL process service components and service engines, including configuring properties such as audit level and audit trail threshold, automatic recovery for BPEL processes, master node recovery scheduling, automatic recovery attempts for invoke and callback messages, and callback message order preservation.

This chapter includes the following topics:

• Configuring BPEL Process Service Engine Properties

• Configuring Automatic Recovery for Oracle BPEL Process Manager

• Configuring Master Node Recovery Scheduling

• Configuring Automatic Recovery Attempts for Invoke and Callback Messages

• Preserving the Order of Callback Messages

• Setting the Audit Level at the BPEL Process Service Component Level

• Avoiding Stuck Threads in High Database Load Environments

For more information about Oracle SOA Suite and Oracle BPEL process tuning and performance properties, see Tuning Performance.

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 process 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 the audit level, audit trail and large document thresholds, payload schema, and BPEL monitors and sensors.

   
   Description of the illustration bpel-engine-config-props.png

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: Business flow instance tracking and payload tracking information is not collected. Inherit: Logging equals the SOA Infrastructure audit level. This setting enables the BPEL process audit level to automatically change when the global setting is changed. Setting a different audit level tracking on this page overrides the tracking set at the SOA Infrastructure level. Minimal: The BPEL process 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 process 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 business flow instance tracking and payload tracking. All events are logged. However, it may have an impact on performance. This level is intended for debugging and can impact system performance.
   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 for a BPEL variable before its contents are stored in a separate location from the rest of the instance scope data.
   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.

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

   • AsyncAuditBatchSize: Stores multiple audit trail messages (across instances) in a single transaction on Oracle Exalogic platforms. For more information, see Storing Instance and Message Data in Oracle Coherence Distributed Cache on Oracle Exalogic Platforms.

   • BpelcClasspath: The extra BPEL class path to include when compiling BPEL-generated Java sources. For more information, see Section "How to Add Custom Classes and JAR Files" of Developing SOA Applications with Oracle SOA Suite.

   • DisableAsserts: Disables the execution of assertions in BPEL, including the bpelx:assert activity. For more information, see Section "How to Disable Assertions" of Developing SOA Applications with Oracle SOA Suite.

   • DisableSensors: Disables all calls to sensors.

   • DispatcherNonBlockInvokeThreads: The total number of threads allocated to process nonblocking invocation dispatcher messages. If your system has many nonblocking invokes, the value of this property can be incremented. The default value is 2. Any value less than 1 is automatically changed to the default value.

   • ExecuteCallbacksInOrder: Preserves BPEL process callbacks in the order of received time of the callback inside the BPEL process service engine (when set to true). For more information, see Preserving the Order of Callback Messages.

   • 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 the in-memory cache.

   • MaxRecoverAttempt: The number of automatic recovery attempts to submit in the same recoverable instance. For more information, see Configuring Automatic Recovery Attempts for Invoke and Callback Messages.

   • MinBPELWait: The minimum time duration for a BPEL process to perform a real wait that involves a dehydration. For more information, see Section "Creating a Wait Activity to Set an Expiration Time" of Developing SOA Applications with Oracle SOA Suite.

   • OneWayDeliveryPolicy: Changes whether one-way invocation messages are delivered.

   • QualityOfService: Enables or disables Oracle Coherence cache for the BPEL process service engine. For more information, see Configuring Oracle Coherence Caching.

   • RecoveryConfig: Configures automatic recovery of activities and configures clustered environments to use master node recovery scheduling. For more information, see Configuring Automatic Recovery for and Configuring Master Node Recovery Scheduling.

   • StatsLastN: The size of the most recently processed request list. Change this value to a value such as 1000. This enables you to view low level statistics in the Statistics page. For more information, see Monitoring BPEL Process Service Engine Request and Thread Performance Statistics.

   • SyncMaxWaitTime: The maximum time a request and response operation takes before timing out. For more information about this property, see Section "Specifying Transaction Timeout Values in Durable Synchronous Processes" of Developing SOA Applications with Oracle SOA Suite.

5. Make changes appropriate to your environment.

For more information about Oracle BPEL process tuning and performance parameters, see Tuning Performance.

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 callback 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. 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 0 value causes no messages to be selected from the database (effectively disabling recovery). Warning: Specifying a negative value causes all messages selected from the database to be submitted for recovery. This value can potentially overload your system. Do not specify this value.
   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 (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 threshold 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. Expand StartupScheduleConfig.

   This section enables you to configure server startup recovery attempts.

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

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.

Configuring Master Node Recovery Scheduling

You can configure a clustered environment to use master node recovery scheduling. In this environment, the master node is dedicated to performing recovery for all nodes in the cluster.

Note:

This feature does not work if you are using a pre-Oracle Fusion Middleware Release 11g (11.1.1.3) database schema.

Master node recovery scheduling enables you to perform the following tasks:

• Recover activities with expiration dates (for example, a wait activity or an OnAlarm branch of a pick activity) that are past due. The master node picks expired work items and reschedules them.

• Recover stranded work items

• Recover callback messages

• Recover invoke messages

• Fail over expired activities: When the master node detects a failed node, it tries to reschedule work items that have an expiration date.

To configure master node recovery scheduling:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control.
2. Right-click soa-infra.
3. Select SOA Administration > BPEL Properties.
4. Click More BPEL Configuration Properties.
5. In the Name column, click RecoveryConfig.
6. Expand ClusterConfig. The ClusterConfig properties work in association with the recurring recovery attempt properties and server startup recovery attempt properties that you set for RecurringScheduleConfig and StartupScheduleConfig, respectively.
7. Set the following properties to values appropriate to your environment, and click Apply.

   Note:

   Once an instance/message becomes recoverable, a recovery is attempted. However, the number of retries is not tracked. If a recovery fails, it continues to pick the same record, retry, and fail again.

   Property	Description
   clusterDbTimeRefresh	Specifies how often to refresh the local copy of the database time. This takes into account the clock drift on different computers. All nodes in the cluster rely on the database time, regardless of its accuracy. The default value is 12 hours (specified as 43200 seconds).
   heartBeatInterval	Specifies how often a node polls the cluster message table to check for messages published by other nodes in the cluster. The default value is 5 seconds. The following tasks are performed each interval: Updates the node's last updated time in the cluster_node table. Attempts to claim ownership of the master role. If the master role is claimed, the recovery manager resumes work. Checks for all nodes that have update times not updated for the nodeReapThreshold value, deletes those nodes from the cluster_node table, and reschedules all expiring work items from this node.
   masteAliveThreshold	Specifies the number of seconds a master node is considered to be active. Master nodes that have not checked in with the cluster for this number of seconds are considered to be terminated. Whichever node gets an exclusive lock on the cluster_master table after this point can claim the master role. The default value is 15 minutes (specified as 900 seconds).
   nodeReapInterval	Specifies how often the heartbeat thread is borrowed to mark old cluster nodes. Only the master node performs this job. The default value is 2 hours (specified as 7200 seconds).
   nodeReapThreshold	Specifies the number of seconds a node is considered to be active. Nodes that have not checked in with the cluster for this number of seconds are considered to be terminated. During its heartbeat cycle, the master node tries to clean up the cluster_node table. The default value is 15 minutes (specified as 900 seconds).

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 2 (the default value), two attempts are made to recover each recoverable message. Once the number of recovery attempts on a message exceeds the specified value, a message is marked as nonrecoverable.

To configure automatic 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.

   The recovery behavior for invoke and callback messages is different when MaxRecoverAttempt is set. For example, assume MaxRecoverAttempt is set to 4.

   • Invoke message recovery is retried 4 (N) times before moving the message to the exhausted state.

   • Callback message recovery is retried 5 times (N + 1) before moving the message to the exhausted state.

   This is the expected behavior. The first attempt is not counted as a recovery attempt. The recovery attempts are incremented by the BPEL process service engine. If MaxRecoverAttempt is set to 1, you see one default resolution process and then one recovery attempt.

5. Click Apply.

For information about recovering invoke and callback messages, see Performing BPEL Process Service Engine Message Recovery.

Preserving the Order of Callback Messages

You can preserve the order of callback messages in a BPEL process and ensure that they are delivered to the BPEL process instance in the correct order by setting the ExecuteCallbacksInOrder property to true in the System MBean Browser. ExecuteCallbacksInOrder enables callbacks to be picked up in the order in which they were received by the BPEL process service engine for a given business flow instance. This setting impacts all SOA composite applications deployed in the BPEL process service engine.

For information about accessing and configuring the ExecuteCallbacksInOrder property, see Configuring BPEL Process Service Engine Properties.

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

• In Oracle JDeveloper:

  Set the bpel.config.auditLevel property to an appropriate value in the composite.xml file of your SOA project.

  <component name="BPELProcess"> 
     <implementation.bpel src="BPELProcess.bpel" /> 
     <property name="bpel.config.auditLevel">Off</property> 
  </component>
  

For more information about audit levels, see Introduction to the Order of Precedence for Audit Level Settings.

Avoiding Stuck Threads in High Database Load Environments

On occasion, when you have high database loads in which the database server is too busy or CPU utilization becomes very high, select SQL queries without a transaction get stuck at the socket-level, outside of Oracle SOA Suite control.

Oracle recommends that you include a Statement Timeout in the SOADataSource and SOALocalDataSource data sources to avoid stuck threads occurring due to long running or stuck SQL queries that occur outside of Oracle SOA Suite control. This action helps Oracle SOA Suite

to avoid an increase in stuck threads, which have a negative impact on Oracle SOA Suite performance in high database load environments.

In this situation, the Statement Timeout value should be set higher than the JTA timeout value and less than but near to the stuck thread timeout value to reduce the chance of stuck threads.

Recommended value: JTA timeout < Statement timeout and Statement timeout < Stuck thread timeout, but closer to Stuck thread timeout and far from JTA timeout.

This range is recommended because:

• There is no impact when all threads are in the JTA transaction boundary.

• Long running SQL queries terminate just before being marked as stuck threads.

For information on setting the Statement Timeout, see Limiting Statement Processing Time with Statement Timeout in Administering JDBC Data Sources for Oracle WebLogic Server.