17 Managing BPEL Process Service Components and Engines
This chapter includes the following topics:
-
Storing Instance and Message Data in Oracle Coherence Distributed Cache on Oracle Exalogic Platforms
For conceptual information about service components and service engines, see the following sections:
17.1 Managing BPEL Process Service Component Policies
You can attach and detach policies to and from BPEL process service components in currently deployed SOA composite applications. Policies apply security to the delivery of messages. Oracle Fusion Middleware uses a policy-based model to manage web services.
Note:
Before attaching policies, see Securing Web Services and Managing Policies with Oracle Web Services Manager for definitions of available policies and details about which ones to use in your environment.
To manage BPEL process service component policies:
-
Access this page through one of the following options:
From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... -
Select Home.
-
Select the Deployed Composites tab.
-
In the Composite section, select a specific SOA composite application.
-
Under soa-infra, expand the partition.
-
Select a specific SOA composite application.
-
-
Select the BPEL process service component in the Components section.
-
Click Policies.
The Policies page enables you to attach and detach policies to and from BPEL process service components. The Policies table displays the attached policy name, the policy reference status (enabled or disabled) that you can toggle, the category (such as Management, Reliable Messaging, MTOM Attachment, Security, or WS-Addressing), the violations, and the authentication, authorization, confidentiality, and integrity failures since the SOA Infrastructure was last restarted.
-
Click Attach/Detach.
If multiple components are available, you are prompted to select the service or component for which to perform the attachment or detachment.
-
Select the service or component to which to attach or detach a policy.
This invokes a dialog for attaching or detaching policies.
Policies currently attached appear in the Attached Policies section. Additional policies available for attachment appear in the Available Policies section.
-
Select to attach policies appropriate to your environment.
-
Click Attach.
-
When you are finished attaching policies, click Validate.
-
If an error message appears, make the necessary corrections until you no longer have any validation errors.
-
Click OK.
The attached policy is displayed in the Policies table.
For more information, see the following documentation:
-
Managing SOA Composite Application Policies for the dialogs that are displayed during policy attachment
-
Securing Web Services and Managing Policies with Oracle Web Services Manager for definitions of available policies and details about which ones to use for your environment
17.2 Performing BPEL Process Service Engine Message Recovery
In Release 12.1.3, issues with business flow instances, including BPEL process message recovery, are reported as faults. Therefore, you can perform message recovery from the Recovery page of the BPEL process service engine or from the Error Hospital page.
You can perform a manual recovery of undelivered invoke or callback messages due to a transaction rollback in the business flow instance. Recovery of invoke messages applies to asynchronous BPEL processes only. Synchronous BPEL processes return an error to the calling client and are not recoverable from the Recovery page. Recoverable activities are activities that failed and can be recovered. For example, if you are using the file adapter to initiate an asynchronous BPEL process and your system fails while the business flow instance is processing, you can manually perform recovery when the server restarts to ensure that all message records are recovered.
You can also manage messages that have failed automatic recovery attempts by the BPEL process service engine. To ensure that automatic recovery of these messages is not attempted multiple times, these messages are placed in the exhausted state. You can then perform one of the following actions on these messages:
-
Return them to the automatic recovery queue
-
Never attempt a recovery on them again
-
Attempt to recover them immediately
For example, assume you have a BPEL process that writes to a database adapter. If the database is down, these messages are sent to a recovery queue. Automatic recovery of these messages fails while the database is down. Such messages are marked with the exhausted state so that automatic recovery is not attempted on them again. When the database begins running again, you can reset these messages (return them to the automatic recovery queue) so that an automatic recovery is attempted on them again.
To perform BPEL process service engine message recovery:
-
Access this page through one of the following options:
From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... -
Select Service Engines > BPEL.
-
Right-click soa-infra.
-
Select Service Engines > BPEL.
-
-
Click Recovery.
The Recovery page displays the following details:
-
A Refresh Alarm Table button for resynchronizing lost, in-memory, Quartz-scheduled jobs in the database. For example, assume a timer on a wait activity or an onAlarm branch of a pick activity was initiated, but the transaction was rolled back. You can resynchronize these jobs with the business flow instances residing in the wait activity/onAlarm branch in the database.
-
A utility for searching for a specific message failure by specifying criteria and clicking Search. Click the Help icon for details.
-
Message failures in the service engine, including the conversation ID, whether you can recover from the message failure, the service component and composite application in which the failure occurred, and the time at which the fault occurred. Depending on the state, you can recover these messages immediately, cancel these messages, or reset these messages for automatic recovery.
Note:
-
You can recover callback messages in resolved and undelivered states. These messages can be displayed for recovery when you execute search criteria in which you select Callback from the Type list and either Resolved or Undelivered from the Message State list. When a callback message first enters the BPEL process service engine, its state is undelivered. When this message is resolved to the target business flow instance either through matching a conversation ID or a correlation, the state is switched to resolved. In both of these states, the messages have not yet been consumed. Messages in these two states can be recovered (redelivered into the BPEL process service engine for consumption). In other situations, the callback messages can become stranded in both of these states. Messages in these states can also be recovered. However, there is no guarantee that stranded callback messages always remain in an undelivered state.
-
The Message States list is applicable to the callback and invoke message type recovery, and the activity message type recovery for the undelivered, cancelled, and exhausted states. The delivered and resolved message states are not applicable to activity messages in Release 12c.
-
-
Select a fault in the table.
-
Select one of the following options:
Action Description Recover
Retries the message in which the fault occurred.
If you select messages in the exhausted state and click this button, an attempt is made to recover them immediately. Should this recovery attempt also fail, the message is returned to the exhausted state. You must then select the message and click Reset to return the message to the automatic recovery queue.
If an asynchronous BPEL process encounters a transaction rollback scenario because of any underlying exception error, it rolls back to the last dehydration activity. If this is a new instance, and a receive activity was the first dehydration activity, the BPEL process service engine creates a recoverable invoke. When you click Recover to recover the invoke, the service engine creates a new instance. This instance may run to completion with no exception error. However, you continue to see the older instance identified as faulted.
Abort
Select to display a confirmation message that enables you to terminate the entire flow in which the message marked as cancelled is included, and update the instance state. Message cancellation is executed in the context of the flow ID. If instances are linked using this flow ID, all instances are terminated. A flow ID enables you to track a message flow that crosses different composite applications.
If you select messages in the exhausted state and click this button, recovery is never attempted on them.
Reset
Select to reset exhausted messages to the undelivered state. This returns the message to the automatic recovery queue. The messages that are displayed in the exhausted state disappear from the messages table. If you select Undelivered from the Message State list and click Search, these messages are displayed. Callback messages in the exhausted state can also be reset to the resolved state and still remain recoverable.
Once a message is submitted for recovery, the BPEL process service engine may take time to complete the action. This typically takes less than several seconds. During this time, the message remains visible in the Recovery page. Duplicate attempts to recover the same message in that period are ignored. Refresh the page every few seconds to receive the latest recovery status.
Note:
If you define a fault policy in a BPEL process with an
ora-retryaction and a fault occurs, the BPEL process attempts to recover from the fault the number of times you specified with theretryCountparameter. After this period, the process continues to be in a running state. The status of an activity in the process that has not completed (such as an invoke or receive) shows as pending a manual recovery. This is the expected behavior.For information about fault recovery in the Error Hospital, see Recovering From Faults in the Error Hospital.
For information about configuring the maximum number of times to attempt an invoke and callback message recovery, see Configuring Automatic Recovery Attempts for Invoke and Callback Messages.
For information about designing a fault policy, see Section "Handling Faults with the Fault Management Framework" of Developing SOA Applications with Oracle SOA Suite.
17.3 Storing Instance and Message Data in Oracle Coherence Distributed Cache on Oracle Exalogic Platforms
With BPEL processes, a potential performance issue is the number of database interactions required per instance. This factor is the main reason for synchronous transient flows outperforming asynchronous durable flows. You can design around this issue by utilizing synchronous transient flows in situations where low response times are required. However, you may be unable to design this type of flow for business reasons.
If you are running Oracle SOA Suite on an Oracle Exalogic platform, you can use the distributed cache feature of Oracle Coherence to store instance and message data from BPEL processes. This eliminates database reads, thereby reducing the number of database interactions.
Oracle Coherence is a component of Oracle Fusion Middleware that enables organizations to scale mission-critical applications by providing access to frequently used data. Oracle Coherence includes a distributed cache feature that provides scalability for both read and write access. Data is automatically, dynamically, and transparently partitioned across nodes. The distribution algorithm minimizes network traffic and avoids service pauses by incrementally shifting data.
Oracle Exalogic is an integrated hardware and software system designed to provide a platform for a range of application types and varied workloads. Oracle Exalogic is intended for large-scale, performance-sensitive, mission-critical application deployments.
Note:
If your environment is not using Oracle Exalogic, Oracle Coherence distributed cache is not available.
The potential performance gains of using a distributed cache for BPEL processes are as follows:
-
Eliminates the read operation required for messages (invoke and callback) from the database after initial delivery
-
Eliminates the read operation required for cube instances after a dehydration point
For more information about Oracle Coherence, see the Oracle Coherence Getting Started Guide and Developing Applications with Oracle Coherence.
17.3.1 Introduction to the Oracle Coherence Caching Architecture
During dehydration, instance objects are stored in the database using the Java Persistence API (JPA) in a container-managed Enterprise JavaBeans (EJB) transaction. The BPEL process service engine registers the transaction afterCompletion listener for post-transaction processing. Instance objects modified during a transaction are tracked and made available to the afterCompletion listener, which updates the cache. Figure 17-1 provides details about the dehydration process.
During rehydration, instance objects are read from cache. Implementations do not provide XA guarantees for transaction completion notification, and cache eviction may delete the object from cache. Implementations account for these two scenarios and address the issues of cache not returning an object or returning an older version of the object.
Cache lookup usually provides a valid object. In this scenario, performance gain for dehydration and rehydration using cache over direct writes (the default) equals the following:
(database read time + relational to object mapping) minus (Object serialization + reading from serialized form + Coherence network overhead + query to database for reading CACHE_VERSION)
It also reduces activity on the database server.
If Oracle Coherence cache is not available due to a network issue, the BPEL process service engine continues to work. If there are no errors, business process instances continue to progress.
17.3.2 Running with Default SOA Cluster Nodes and Coherence Cache Grid Nodes
BPEL process caches are not created on an Oracle SOA Suite cluster node. You must start the BPEL cache servers, which host the BPEL caches, by following the instructions in Starting the BPEL Process Cache Servers. Start at least four servers to observe an increase in performance.There is no requirement for ordering of an Oracle SOA Suite cluster and BPEL cache servers. The BPEL process service engine continues to function without BPEL cache servers, even when the QualityOfService property is set to CacheEnabled in Oracle Enterprise Manager Fusion Middleware Control.
For more information about Oracle Coherence, see the Oracle Coherence Getting Started Guide and Developing Applications with Oracle Coherence.
17.3.3 Configuring Oracle Coherence Caching
The System MBean Browser property QualityOfService enables you to configure Oracle Coherence for dehydration. You can configure this property on one of the nodes in the SOA cluster.
To configure Oracle Coherence caching for dehydration:
-
Access this page through one of the following options:
From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... -
Select SOA Administration > BPEL Properties.
-
Right-click soa-infra.
-
Select SOA Administration > BPEL Properties.
The BPEL Service Engine Properties page is displayed.
-
-
Click More BPEL Configuration Properties.
-
In the Attributes tab, click QualityOfService.
-
In the Value field, enter a value appropriate to your environment. This change does not require a SOA Infrastructure restart.
Table 17-1 QualityOfService Values
Value Description DirectWriteNo cache is used for dehydration and rehydration. Read and write operations are done to the database. This is the default setting.
CacheEnabledDuring dehydration, the instance data is stored in the database using an XA data source connection; the placement of objects into cache is part of post-transaction processing.
During rehydration, data is fetched from the cache. If the data is not found (for example, the BPEL process cache servers are not available) or the version is aborted, data is read from the database.
-
Click Apply.
17.3.4 Configuring the Storage of Multiple Audit Trail Messages in One Transaction
For asynchronous flows, performance gains can be achieved by storing multiple audit trail messages in one transaction. To improve performance, you can store multiple audit trail messages (across instances) in a single transaction by setting the System MBean Browser property AsynchAuditBatchSize in Oracle Enterprise Manager Fusion Middleware Control.
Setting this property to an appropriate value reduces audit trail transaction commits. Instead, a commit is only performed when a specified limit is reached.
To configure the storage of multiple audit trail messages in one transaction:
-
Access this page through one of the following options:
From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... -
Select SOA Administration > BPEL Properties.
-
Right-click soa-infra.
-
Select SOA Administration > BPEL Properties.
The BPEL Service Engine Properties page is displayed.
-
-
Click More BPEL Configuration Properties.
-
In the Attributes tab, click AsynchAuditBatchSize.
-
In the Value field, enter a value appropriate to your environment. The default value of
-1indicates that there is no audit trail message batching. Each audit message is persisted in its own transaction.The recommended value range is
5to25. For example, if you set this property to8, this indicates that when eight audit trail messages have accumulated, a transaction is created with these messages and committed to the dehydration store.This parameter only impacts Oracle Exalogic environments. For other environments, it is not operational.
This change does not require a SOA Infrastructure restart.
-
Click Apply.
17.3.5 Configuring the Storage of the Audit Trail to Oracle Coherence Cache
You can store the audit trail in Oracle Coherence cache by setting the following System MBean Browser properties to these values in Oracle Enterprise Manager Fusion Middleware Control:
-
AuditStorePolicy is set to
async. This property is now set from theAuditConfigattribute at the SOA Infrastructure level. -
QualityOfServiceOneWayDeliveryPolicyUseDistributedCache is set to
This property is set under BPEL Service Engine Properties.true. -
QualityOfService is set to
CacheEnabled. This property is set under BPEL Service Engine Properties. For instructions, see Configuring Oracle Coherence Caching.
These settings enable the following to occur:
-
Oracle Coherence cache acts as a queue and writes the audit trail to the database.
-
The SOA server node heap and threads do not process the audit trail.
If one of these properties is set to a different value, the heap and dispatcher threads are used for writing to the database.
To configure the storage of the audit trail into Oracle Coherence cache:
-
Access this page through one of the following options:
From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... -
Select SOA Administration > BPEL Properties.
-
Right-click soa-infra.
-
Select SOA Administration > BPEL Properties.
The BPEL Service Engine Properties page is displayed.
-
-
Click More BPEL Configuration Properties.
-
In the Attributes tab, click AuditStorePolicy .
-
In the Value field, enter
async.Note:
If the server crashes (the SOA/BPEL cache server), some audit trail messages are not persisted to the database. This results in loss of the audit log. Failover is not supported. This is true for both Oracle Coherence and memory/heap caches.
-
Click Apply.
-
Click Return.
-
In the Attributes tab, click QualityOfService.AuditStorePolicy.UseDistributedCache.
-
From the Value list, select true.
-
Click Apply.
17.3.6 Configuring the Storage of Invocation Messages to Oracle Coherence Cache
You can store invocation messages in Oracle Coherence cache by setting the following System MBean Browser properties to these values in Oracle Enterprise Manager Fusion Middleware Control:
-
OneWayDeliveryPolicy is set to
async.cache. -
QualityOfServiceOneWayDeliveryPolicyUseDistributedCache is set to
true. -
QualityOfService is set to
CacheEnabled. For instructions, see Configuring Oracle Coherence Caching.
If one of these properties is set to a different value, local memory is used for cache, and not Oracle Coherence cache.
Note:
Invocation messages in the middle of execution at the time of a server crash (both SOA and BPEL process cache servers) can be lost or duplicated. Failover is not supported. This is true for both Oracle Coherence and memory/heap caches.
-
Access this page through one of the following options:
From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... -
Select SOA Administration > BPEL Properties.
-
Right-click soa-infra.
-
Select SOA Administration > BPEL Properties.
The BPEL Service Engine Properties page is displayed.
-
-
Click More BPEL Configuration Properties.
-
In the Attributes tab, click OneWayDeliveryPolicy .
-
In the Value field, enter
async.cache. -
Click Apply.
-
Click Return.
-
In the Attributes tab, click QualityOfServiceOneWayDeliveryPolicyUseDistributedCache.
-
From the Value list, select true.
-
Click Apply.
17.3.7 Starting the BPEL Process Cache Servers
Run the start-bpel-cache.sh script to start the BPEL process cache servers on UNIX machines on which Oracle SOA Suite is installed.
The only requirement is network connectivity. The Oracle SOA Suite nodes must be reachable from the host on which the BPEL process cache servers are installed.
This script joins an Oracle SOA Suite cluster with a multicast, default address and port. These values match with the corresponding values in the $FMW_HOME/user_projects/domains/domain_name/bin/setDomainEnv.sh file.
If you choose multicast for a cluster, but use a different address and port, you can override it in the bpelCacheEnv.sh file by using an environment variable or setting a shell variable. Use the same values for SOA managed servers (in setDomainEnv.sh).
The default cache configuration for the Oracle SOA Suite cluster must be unicast, and not multicast. For more information about this recommended cache configuration for Oracle SOA Suite clusters for Oracle Coherence, see the High Availability Guide or Enterprise Deployment Guide for Oracle SOA Suite for details.
To start the BPEL process cache servers: