A one-way invocation (with a possible callback) is typically exposed in a WSDL file as shown in the following example:

<wsdl:operation name="process">
        <wsdl:input message="client:OrderProcessorRequestMessage"/>
    </wsdl:operation>

This causes the BPEL process service engine to split the execution into two parts:

• For the first part, and always inside the caller transaction, the insertion into the dlv_message table of the dehydration store occurs (in release 10.1.3.x, it was inserted into the inv_message table).

• For the second part, the transaction and the new thread execute the work items, and a new instance is created.

This has several advantages in terms of scalability, because the service engine's thread pool (invoker threads) executes when a thread is available. However, the disadvantage is that there is no guarantee that it executes immediately.

If you require a synchronous-type call based on a one-way operation, then you can use the onewayDeliveryPolicy property, which is similar to the deliveryPersistPolicy property of release 10.1.3.x.

Specify bpel.config.oneWayDeliveryPolicy as follows:

• In the Create BPEL Process dialog for a new BPEL process.

• In the BPEL process service component section of the composite.xml file for an existing BPEL process.

If this value is not set in composite.xml, the value for oneWayDeliveryPolicy in the System MBean Browser in Oracle Enterprise Manager Fusion Middleware Control is used. The following values are possible.

• async.persist: Messages are persisted in the database. With this setting, reliability is obtained with some performance impact on the database. In some cases, overall system performance can be impacted.

• async.cache: Incoming delivery messages are kept only in the in-memory cache. If performance is preferred over reliability, consider this setting. When set to async.cache, if the rate at which one-way messages arrive is much higher than the rate at which they are delivered, or if the server fails, messages can be lost. In addition, the system can become overloaded (messages become backlogged in the scheduled queue) and you can receive out-of-memory errors. Consult your own use case scenarios to determine if this setting is appropriate.

  When you set oneWayDeliveryPolicy to async.cache in high availability environments, invoke and callback messages in the middle of execution at the time of a server crash may be lost or duplicated. Server failover is not supported for async.cache.

• sync: Direct invocation occurs on the same thread. The scheduling of messages in the invoke queue is bypassed, and the BPEL instance is invoked synchronously. In some cases this setting can improve database performance.

For more information about setting the bpel.config.oneWayDeliveryPolicy property, see How to Add a BPEL Process Service Component and How to Define Deployment Descriptor Properties in the Property Inspector.

Table 13-4 describes the behavior when the main process calls the subprocess asynchronously. Table 13-4 is based on the use cases described in BPELCaller Process Calls a BPELCallee Process That Has bpel.config.transaction Set to requiresNew and BPELCaller Process Calls a BPELCallee Process That Has bpel.config.transaction Set to required.