Oracle® Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite 11g Release 1 (11.1.1.6.3) Part Number E10226-16 |
|
|
PDF · Mobi · ePub |
This chapter describes how to configure BPEL process service components and service engines, including configuring properties such as audit level, audit trail threshold, and dispatcher thread values; automatic recovery for BPEL processes; master node recovery scheduling; and automatic recovery attempts for invoke and callback messages.
This chapter includes the following topics:
Section 12.1, "Configuring BPEL Process Service Engine Properties"
Section 12.2, "Configuring Automatic Recovery for Oracle BPEL Process Manager"
Section 12.4, "Configuring Automatic Recovery Attempts for Invoke and Callback Messages"
Section 12.5, "Setting the Audit Level at the BPEL Process Service Component Level"
For more information about Oracle SOA Suite and Oracle BPEL process tuning and performance parameters, see Oracle Fusion Middleware Performance and Tuning Guide.
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:
Access this page through one of the following options:
From the SOA Infrastructure Menu... | From the SOA Folder in the Navigator... |
---|---|
|
|
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.
Make changes to the service engine properties that are appropriate to your environment.
Property | Description |
---|---|
Audit Level |
Select one of the following options:
|
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 For information about monitoring these threads, see Section 13.6, "Monitoring BPEL Process Service Engine Request and Thread Statistics." |
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 For information about monitoring these threads, see Section 13.6, "Monitoring BPEL Process Service Engine Request and Thread Statistics." |
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. Higher thread counts can cause greater CPU utilization due to higher context-switching costs. The default value is For information about monitoring these threads, see Section 13.6, "Monitoring BPEL Process Service Engine Request and Thread Statistics." |
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. |
Select this checkbox to disable all BPEL monitors and sensors defined for all BPEL components across all deployed SOA composite applications. |
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.
AsynchAuditBatchSize: Stores multiple audit trail messages (across instances) in a single transaction on Oracle Exalogic platforms. For more information, see Section 14.5, "Storing Instance and Callback 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.
DisableAsserts: Disables the execution of assertions in BPEL, including the bpelx:assert
activity.
ExpirationMaxRetry: The maximum number of times a failed expiration call (wait/onAlarm) is retried before failing.
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 Section 12.4, "Configuring Automatic Recovery Attempts for Invoke and Callback Messages" and Section 14.5.4, "Configuring the Storage of Multiple Audit Trail Messages in One Transaction."
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 Section 14.5.3, "Configuring Oracle Coherence Caching."
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.
For more information about Oracle BPEL process tuning and performance parameters, see Oracle Fusion Middleware Performance and Tuning Guide.
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:
In the navigator, right-click soa-infra and select SOA Administration > BPEL Properties.
Click More BPEL Configuration Properties.
In the Name column, click RecoveryConfig.
Expand RecurringScheduleConfig.
This section enables you to configure recurring recovery attempts.
Set the following properties to values appropriate to your environment, and click Apply.
Expand StartupScheduleConfig.
This section enables you to configure server startup recovery attempts.
Set the following properties to values appropriate to your environment, and click Apply.
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 1 (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 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:
Log in to Oracle Enterprise Manager Fusion Middleware Control.
Right-click soa-infra.
Select SOA Administration > BPEL Properties.
Click More BPEL Configuration Properties.
In the Name column, click RecoveryConfig.
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.
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.
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 automatic recovery attempts for invoke and callback messages:
In the navigator, right-click soa-infra and select SOA Administration > BPEL Properties.
Click More BPEL Configuration Properties.
Go to MaxRecoverAttempt.
In the Value field, enter a value.
Click Apply.
For information about recovering invoke and callback messages, see Section 14.4, "Performing BPEL Process Service Engine Message Recovery."
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:
In the navigation tree, expand the SOA folder.
Right-click soa-infra, and select Administration > System MBean Browser.
Select Application Defined MBeans > oracle.soa.config > Server: server_name > SCAComposite > Composite_Name > SCAComposite.SCAComponent > BPEL_Service_Component > Properties.
Click the Add icon.
Expand the Element_number folder.
From the many list, select false.
In the name field, enter bpel.config.auditlevel
.
In the value field, enter a value.
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 Section 1.4.1.1, "Introduction to the Order of Precedence for Audit Level Settings."