#291 BPEL configuration properties

Rule of thumb for BPEL is - keep those processes short and sweet.
Transient, synchronous is the way to go, if possible.

ORCL docs provide for very good reading in this area - I recommend the FMW Developer Guide for SOA Suite, the FMW SOA Suite Administrators Guide as well as the FMW Performance Guide. The info below, has to a great extent, been taken from there. I also recommend AnTony Reynolds and Matt Wright's - Oracle SOA Suite 11g Developers Guide - available here

Tuning BPEL Engine Threads -

These are the guys who do the actual work -

The dspInvokeThreads property specifies 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 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 dspEngineThreads property specifies the total number of threads allocated to process engine dispatcher messages. Engine dispatcher messages are generated whenever an activity must be processed asynchronously. If the majority of processes deployed are durable with a large number of dehydration points (mid-process receive, onMessage, onAlarm, and wait activities), greater performance may be achieved by increasing the number of engine threads. Note that higher thread counts can cause greater CPU utilization due to higher context switching costs.

The dspSystemThreads property specifies the total number of threads allocated to process system dispatcher messages. System dispatcher messages are general clean-up 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 run time.

Start off with the defaults, and tune - if necessary - paying attention to the heuristics above.

These properties can be set in EM. 

As you can see, the Audit Level is set to Inherit as default. Please see my My Post on Logging for more info.

Here is the doc -

For production systems - use Production or Error - depending on your logging requirements.

Audit Detail threshold - under the threshold? - details store in the audit_trail table.
over the threshold? then audit info will be written to the audit_details table.

Large Doc Threshold - same concept -

This is the maximum size (in kilobytes) of a BPEL variable before it is stored in a separate location from the rest of the instance scope data.

Payload Validation - validates incoming and outgoing XML documents 
Incurs a performance hit.

Other Configuration properties

Now let's look at the rest -

As you can see, the descriptions shown in EM are useful and succinct.
You will not change most of these, however - some are worth investigating -


For one way invokes with possible callbacks -

Per default requests to execute a BPEL process are written to the soa_infra.dlv_message table - this causes a message to be generated that is then picked up by a worker thread which then starts executing the process.

Big benefit - Reliability no requests get lost - however we do have an extra DB write.

If set to async.cache then the request is cached in-memory - better Performance

If set to sync -> queuing is bypassed, and the BPEL process is invoked synchronously.
Client has full control of what happens.


1. bpel.config.oneWayDeliveryPolicy
Default value specified in MBean - accessible from em

async.persist: Messages are persisted in the database hash map.
sync.cache: Messages are stored in memory.
sync: Direct invocation occurs on the same thread.

Can be overwritten in the BPEL process definition in composite.xml -

onewayDeliveryPolicy=sync
and
transaction=required
BPEL process runs in the same thread and the same transaction.

onewayDeliveryPolicy=sync
and
transaction=requiresNew
BPEL process runs in the same thread but within a new transaction.

completionPersistPolicy

Here you need to ask yourself, whether the instance data needs to be persisted, and if so to what extent.
If your BPEL process integrates System A with System B. then the fact that the data has been successfully written to B suffices.

Simple example -

here is my one-way BPEL process that writes its input to a file -

Test - here is the output order.

Here is the em trace -

Now I set the the completePersistPolicy to off in composite.xml -
I also need to set inMemoryOptimization = true

Re-test - my output file has been written.

Check the audit trail in em -

Probably faulted would be the best setting here.

The SyncMaxWaitTime property sets the maximum time the process result receiver
waits for a result before returning. Results from asynchronous BPEL processes are
retrieved synchronously by a receiver that waits for a result from Oracle BPEL Server.
The default value is 45 seconds.

If you have sync BPEL processes and you see the need to up this property, then consider making the processes async.

MaxRecoverAttempt - number of times to attempt recovery of invoke/callback messages.

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.

Recovery Configuration

This feature is detailed in the Administrator’s Guide for Oracle SOA Suite and Oracle
Business Process Management Suite


e.g. We are trying to update a DB and it is temporarily unavailable.

This covers -
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

When should auto-recovery be available?
Check out the RecurringScheduleConfig - set start/stopWindowTime

Check out StartupScheduleConfig -
the default config tells us -

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.

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.

Partner Link Properties

The main ones ares -

nonBlockingInvoke=true
PartnerLink Service will executed in a separate transaction.

idempotent=false
Executes on same Thread/transaction