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

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.

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.