C Deployment Descriptor Properties

This appendix describes how to define deployment descriptor configuration and partner link properties for BPEL process service components used at runtime by Oracle WebLogic Server, Oracle Enterprise Manager Fusion Middleware Control, or both.

This appendix includes the following section:

• Introduction to Deployment Descriptor Properties

For more information about deployment descriptor properties, see Chapter "Oracle BPEL Process Manager Performance Tuning" of Tuning Performance.

C.1 Introduction to Deployment Descriptor Properties

Deployment descriptors are BPEL process service component properties used at runtime by Oracle WebLogic Server, Oracle Enterprise Manager Fusion Middleware Control, or both. There are two types of properties:

• Configuration

• Partner link binding

Table C-1 lists the configuration deployment descriptor properties.

When you define configuration properties, you must add a prefix of bpel.config to the property name. For example, the property inMemoryOptimization must be defined as bpel.config.inMemoryOptimization. For information on defining properties in the Property Inspector in Oracle JDeveloper, see How to Define Deployment Descriptor Properties in the Property Inspector.

Table C-1 Properties for the configurations Deployment Descriptors

Property Name	Description
completionPersistPolicy	This property configures how the instance data is saved. It can only be set at the BPEL service component level. The following values are available: on (default): The completed instance is saved normally. deferred: The completed instance is saved, but with a different thread and in another transaction. faulted: Only The faulted instances are saved. Note: When an unhandled fault occurs, regardless of these flags, audit information for instances is persisted within the CUBE_INSTANCE table. off: No instances of this process are saved.
disableAsserts	This property, when set to true, disables assertions in BPEL projects.
globalTxMaxRetry	If using outbound adapters in an asynchronous BPEL process, specify the maximum number of retries for a remote fault.
globalTxRetryInterval	If using outbound adapters in an asynchronous BPEL process, specify the time interval in milliseconds between retries for a remote fault.
inMemoryOptimization	Default value is false. This property can only be set to true if it does not have dehydration points. Activities like wait, receive, onMessage, and onAlarm create dehydration points in the process. If this property is set to true, in-memory optimization is attempted on the instances of this process on to-spec queries.
keepGlobalVariables	Specify whether the server can keep global variable values in the instance store when the instance completes: false (default): Global variable values are deleted when the instance completes. true: Global variable values are not deleted.
oneWayDeliveryPolicy	This property sets the persistence policy of the process in the delivery layer. The possible values are: 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 information about setting this property during BPEL process creation, see How to Add a BPEL Process Service Component.
reenableAggregationOnComplete	This property controls the number of instances to create and use to route messages. The possible values are: true: Creates a new instance to handle the messages of the same correlation. false: Creates only one instance for handling messages. For more information, see Routing Messages to the Same Instance.
sensorActionLocation	The location of the sensor action XML file. The sensor action XML file configures the action rule for the events.
sensorLocation	The location of the sensor XML file. The sensor XML file defines the list of sensors into which events are logged.
transaction	This property configures the transaction behavior of the BPEL instance for initiating calls. requiresNew: A new transaction is created for the execution, and the existing transaction (if there is one) is suspended. This behavior is true for both request/response (initiating) environments and one-way, initiating environments in which bpel.config.oneWayDeliveryPolicy is set to sync. required: In request/response (initiating) environments, this setting joins a caller's transaction (if there is one) or creates a new transaction (if there is no transaction). In one-way, initiating environments in which bpel.config.oneWayDeliveryPolicy is set to sync, the invoke message is processed using the same thread in the same transaction. notSupported: Executes a business process without the need for a transaction. For more information, see Executing a Business Process Without a Transaction. Note: This property does not apply for midprocess receive activities. In those cases, another thread in another transaction is used to process the message. This is because a correlation is needed and it is always done asynchronously. For information about setting this property during BPEL process creation, see How to Add a BPEL Process Service Component.

Table C-2 lists the partner link binding deployment descriptor properties.

When you define partner link binding properties, you must add a prefix of bpel.partnerLink.partner_link_name to the property name. For example, the property nonBlockingInvoke must be defined as bpel.partnerLink.partner_link_name.nonBlockingInvoke. For information on defining properties in the Property Inspector in Oracle JDeveloper, see How to Define Deployment Descriptor Properties in the Property Inspector.

Table C-2 Properties for the partnerLinkBinding Deployment Descriptors

Property Name	Description
idempotent	An idempotent activity is an activity that can be retried (for example, an assign activity or an invoke activity). The instance is saved after a nonidempotent activity. This property is applicable to both durable and transient processes. true (default): If the server fails, it performs the activity again after restarting. This is because the server does not dehydrate immediately after the invoke and no record exists that the activity executed. false: Activity is dehydrated immediately after execution and recorded in the dehydration store. When idempotent is set to false, it provides better failover protection, but may impact performance if the BPEL process accesses the dehydration store frequently. For information about using fault handling with the idempotent property set to false, see What You May Need to Know About the idempotent Property and Fault Handling. For more information about the idempotent property, see Managing Idempotence at the Partner Link Operation Level.
nonBlockingInvoke	Default value is false. When this is set to true, a separate thread is spawned to perform the invocation so that the invoke activity does not block the instance. For more information, see What You May Need to Know About the Execution of Parallel Flow Branches in a Single Thread.
validateXML	Enables message boundary validation. When set to true, the XML message is validated against the XML schema during a receive activity and an invoke activity for this partner link. If the XML message is invalid, then a bpelx:invalidVariables runtime fault is thrown. This overrides the domain level validateXML property.

C.1.1 How to Define Deployment Descriptor Properties in the Property Inspector

You define configuration and partner link binding deployment descriptor properties and values in the Property Inspector of Oracle JDeveloper. When complete, the properties are displayed in the BPEL process service component section of the composite.xml file.

1. In the SOA Composite Editor, select the BPEL process service component, as shown in Figure C-1.

   Figure C-1 Selected BPEL Process Service Component

   
   Description of "Figure C-1 Selected BPEL Process Service Component"
2. Go to the Property Inspector in the lower right corner of Oracle JDeveloper.
3. In the Properties section, click the Add icon, as shown in Figure C-2.

   For this example, the oneWayDeliveryPolicy property is already defined because the Delivery option was selected in the Create BPEL Process dialog during BPEL process creation. For more information about setting this property during BPEL process creation, see How to Add a BPEL Process Service Component.

   Figure C-2 Property Inspector

   
   Description of "Figure C-2 Property Inspector"

   The Create Property dialog is displayed.

4. In the Name field, enter the deployment descriptor property. For this example, the configuration deployment descriptor property oneWayDeliveryPolicy is defined. Therefore, a prefix of bpel.config is required. For more information about configuration deployment descriptor properties, see Table C-1.

   If you instead add a partner link binding property, a prefix of bpel.partnerLink.partner_link_name is required, where partner_link_name is the name of the partner link (for example, LoanService). For more information about partner link binding deployment descriptor properties, see Table C-2.

5. In the Value field, enter an applicable value for this property (for example, async.persist).
6. Click OK.

   The Property Inspector displays the added deployment descriptor property.

7. Click Source in the SOA Composite Editor.

   The oneWayDeliveryPolicy configuration property with the bpel.config prefix is displayed in the composite.xml file, as shown in the following example:

<component name="LoanApproval" version="2.0">
. . .
  <componentType>
  . . .
  . . .
  <property name="bpel.config.oneWayDeliveryPolicy" type="xs:string"
  many="false">async.persist</property>
	</componentType>
</component>

If you instead define a partner link binding deployment descriptor property in the Property Inspector (for example, the nonBlockingInvoke partner link binding property), it is displayed in the composite.xml file, as shown in the example that follows. Note the prefix of bpel.partnerLink.partner_link_name, which is required for this type of property.

<component name="myBPELServiceComponent" version="2.0">
 . . .
  <componentType>
  . . .
  . . .
 <property name="bpel.partnerLink.partner_link_name.nonBlockingInvoke">
false</property>
 </componentType>
</component>

C.1.2 How to Get the Value of a Preference within a BPEL Process

The value of a property can be read by a BPEL process using the XPath extension function ora:getPreference(myPref). This gets the value of bpel.preference.myPref.

This function can be used as part of a simple assign statement, used in condition expressions, or used as part of a more complex XPath expression.