Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite
11g Release 1 (11.1.1.6.3)

Part Number E10226-16
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

14 Managing BPEL Process Service Components and Engines

This chapter describes how to manage BPEL process service components and service engines, including recovering from service component and service engine faults, managing service component policies, performing BPEL process message recovery, and storing instance and callback message data in Oracle Coherence cache.

This chapter includes the following topics:

For more information, see the following sections:

14.1 Recovering from BPEL Process Service Component Faults

You can monitor and perform individual and bulk fault recoveries for BPEL process service components that are identified as recoverable. For BPEL process faults to be identified as recoverable, there must be a fault policy defined that is bound to the fault (through the fault-bindings.xml file) and which triggers the action ora-human-intervention. However, without defining any fault policies, the fault takes its standard course as either a recoverable or nonrecoverable fault.

To recover from BPEL process service component faults:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator...
    1. Select Home.

    2. Select the Deployed Composites tab.

    3. In the Composite section, select a specific SOA composite application.

    1. Under soa-infra, expand the partition.

    2. Select a specific SOA composite application.


  2. Select the BPEL process service component in the Component Metrics section.

  3. Click Faults.

    The Faults page displays the following details:

    • A utility for searching for a specific fault by specifying criteria and clicking Search. Click the Help icon for details.

    • Faults that occurred in the service component, including the fault ID, error message, whether you can recover from the fault, time at which the fault occurred, service component instance ID, activity in which the fault occurred, and a link to a log file describing the fault.

    Description of bpel_comp_faults.gif follows
    Description of the illustration bpel_comp_faults.gif

    BPEL process service component faults identified as recoverable can be recovered.

  4. Select faults for recovery using one of the following methods. Fault recovery selection at the BPEL process service component level equals the SOA Infrastructure level, SOA composite application level, and Oracle Mediator service component level.

    For... Then...

    Single fault recovery

    There are three options from which to choose for single-fault recovery:

    1. Click the row of the fault that has been identified as recoverable. With the row highlighted, select a specific action from the Recovery Action list, as described in Step 6.

    2. In the Recovery column, click the Recover link to access the Faults page of the instance audit trail to perform fault recovery.

    3. In the Error Message column, click the message of a fault that has been identified as recoverable. This displays complete fault details, including the fault ID, fault time, fault location, fault type, and error message text. A Recover Now option is displayed for recoverable faults. Click Recover Now to access the Faults page of the instance audit trail to perform fault recovery.

    Bulk fault recovery

    There are two options from which to choose for bulk-fault recovery:

    1. Use Shift+Click or Control+Click to select specific faults in the rows.

      or

    2. From the Select menu, choose Select All Recoverable. Then use Shift+Click or Control+Click to deselect the faults to not include in the recovery operation.

      Then:

    3. Select an action from the Recovery Action list, as described in Step 6.

      Note: Only the actions applicable to all selected faults are available.

    Recovery of all faults

    1. From the Select menu, choose Select All Recoverable.

    2. Select an action from the Recovery Action list, as described in Step 6.

      Note: Only the actions applicable to all selected faults are available.


    Note:

    In most cases, fault policy actions are automatically executed. The only exception is if you defined a fault policy that uses the action ora-human-intervention. This action creates a recoverable fault that can be recovered from Oracle Enterprise Manager Fusion Middleware Control.

  5. Select an action from the Recovery Action list.

    Action Description

    Retry

    Retries the instance directly. An example of a scenario in which to use this recovery action is when the fault occurred because the service provider was not reachable due to a network error. The network error is now resolved.

    Abort

    Terminates the entire instance.

    Replay

    Replays the entire scope activity again in which the fault occurred.

    Rethrow

    Rethrows the current fault. BPEL fault handlers (catch branches) are used to handle the fault. By default, all exceptions are caught by the fault management framework unless an explicit rethrow fault policy is provided.

    Continue

    Ignores the fault and continues processing (marks the faulted activity as a success).


  6. Perform the following additional monitoring tasks from within the faults table:

    1. Click the Show only recoverable faults checkbox to display only faults from which you can recover.

    2. From the Fault Type list, select to display all faults, system faults, business faults, or Oracle Web Services Manager (OWSM) faults in the faults table. Click the Help icon for a description of these fault types.

    3. From the View list, select Columns > Fault ID to display the fault IDs for each error message. The fault ID is automatically generated and uniquely identifies a fault. The fault ID is also displayed when you click an error message.

    4. In the Component Instance ID column, click a specific service component ID to access task details about the instance (for example, the current state of a task). Rejected messages do not have a component instance ID.

    5. In the Logs column, click a link to access the Log Messages page with filtered messages specific to that instance.

For more information, see the following documentation:

14.2 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 Oracle Fusion Middleware Security and Administrator's Guide for Web Services for definitions of available policies and details about which ones to use in your environment.

To manage BPEL process service component policies:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator...
    1. Select Home.

    2. Select the Deployed Composites tab.

    3. In the Composite section, select a specific SOA composite application.

    1. Under soa-infra, expand the partition.

    2. Select a specific SOA composite application.


  2. Select the BPEL process service component in the Component Metrics section.

  3. Click Policies.

    The Policies page enables you to attach and detach policies to and from BPEL process service components. The Policies section displays the attached policy name, the policy reference status (enabled or disabled) that you can toggle, the category (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.

    Description of bpel_comp_policy.gif follows
    Description of the illustration bpel_comp_policy.gif

  4. 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.

  5. 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.

  6. Select to attach policies appropriate to your environment.

  7. Click Attach.

  8. When you are finished attaching policies, click Validate.

  9. If an error message appears, make the necessary corrections until you no longer have any validation errors.

  10. Click OK.

    The attached policy is displayed in the policies table.

For more information, see the following documentation:

14.3 Recovering from BPEL Process Service Engine Faults

You can monitor and perform individual and bulk recoveries of faults occurring in BPEL process service engines that are identified as recoverable. All BPEL process service component faults, regardless of the SOA composite application instance of which they are a part, can be viewed in the BPEL process service engine. For BPEL process faults to be identified as recoverable, there must be a fault policy defined that is bound to the fault (through the fault-bindings.xml file) and which triggers the action ora-human-intervention. However, without defining any fault policies, the fault takes its standard course as either a recoverable or nonrecoverable fault.

To recover from BPEL process service engine faults:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator...
    1. Select Service Engines > BPEL.

    1. Right-click soa-infra.

    2. Select Service Engines > BPEL.


  2. Click Faults.

    The Faults page displays the following details:

    • A utility for searching for a specific fault by specifying criteria and clicking Search. Click the Help icon for details.

    • Faults that occurred in the service engine, including the fault ID, the error message, whether you can recover from the fault, the time at which the fault occurred, the SOA composite application and service component in which the fault occurred, and the service component instance ID.

    Description of bpel_se_faults.gif follows
    Description of the illustration bpel_se_faults.gif

    BPEL process service engine faults identified as recoverable can be recovered.

  3. Select faults for recovery using one of the following options. As with fault recovery at the SOA Infrastructure level, SOA composite application level, and Oracle Mediator service component level, you can perform single fault recovery, bulk fault recovery, and recovery of all faults. See Step 5 of Section 14.1, "Recovering from BPEL Process Service Component Faults" for instructions on selecting faults to perform these types of recovery.

    Note:

    In most cases, fault policy actions are automatically executed. The only exception is if you defined a fault policy that uses the action ora-human-intervention. This action creates a recoverable fault that can be recovered from Oracle Enterprise Manager Fusion Middleware Control.

  4. Select an action from the Recovery Action list.

    Action Description

    Retry

    Retries the instance with an option to provide a retry success action. An example of a scenario in which to use this recovery action is when the fault occurred because the service provider was not reachable due to a network error. The network error is now resolved.

    Abort

    Terminates the entire instance.

    Replay

    Replays the entire scope activity again in which the fault occurred.

    Rethrow

    Rethrows the current fault. BPEL fault handlers (catch branches) are used to handle the fault. By default, all exceptions are caught by the fault management framework unless an explicit rethrow fault policy is provided.

    Continue

    Ignores the fault and continues processing (marks the faulted activity as a success).


  5. Perform the following additional monitoring tasks from within the faults table:

    1. Click the Show only recoverable faults checkbox to only display faults from which you can recover.

    2. From the Fault Type list, select to display all faults, system faults, business faults, or OWSM faults in the faults table. Click the Help icon for a description of these fault types.

    3. From the View list, select Columns > Fault ID to display the fault IDs for each error message. The fault ID is automatically generated and uniquely identifies a fault. The fault ID is also displayed when you click an error message.

    4. In the Composite column, click a specific SOA composite application to access its home page.

    5. In the Component column, click a specific service component to access its home page.

    6. In the Component Instance ID column, click a specific service component ID to access task details about the instance (for example, the current state of a task). Rejected messages do not have a component instance ID.

For more information, see the following sections:

14.4 Performing BPEL Process Service Engine Message Recovery

You can perform a manual recovery of undelivered invoke or callback messages due to a transaction rollback in the process 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 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:

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:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator...
    1. Select Service Engines > BPEL.

    1. Right-click soa-infra.

    2. Select Service Engines > BPEL.


  2. 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 on an onAlarm branch of a pick activity was initiated, but the transaction was rolled back. You can resynchronize these jobs with the BPEL 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.

      You can enter the execution context ID (ECID) value in the ECID field. The ECID value enables you to track a message flow that crosses instances of different composite applications. If there are BPEL process messages requiring recovery and the AuditConfig property in the System MBean Browser is set to All (the default value), the following message is displayed in the Trace table of the Flow Trace page:

      BPEL Message Recovery Required
      

      Clicking Show Details or the recovery icon that appears next to this message displays a Warning dialog with information about the number of invoke, callback, and activity recoverable message types and the ECID value. You can copy the ECID value from the Warning dialog, paste it into the ECID field, and select the recoverable message type from the Type list as part of creating your search criteria on the Recovery page.

      For more information, see Section 13.1, "Monitoring the Audit Trail and Process Flow of a BPEL Process Service Component."

      Note:

      Oracle recommends that you add an index on the DLV_MESSAGE.ECID column of the DLV_MESSAGE table to improve SQL query performance when searching messages for a specific ECID value. This is because if there are too many entries in the DLV_MESSAGE table, the search query may be slow and may also overload the database. For information on adding an index, see Chapter "Creating Indexes" of the Oracle Database Administrator's Guide.

    • 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.

    Description of bpel_se_recov.gif follows
    Description of the illustration bpel_se_recov.gif

    Notes:

    • 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 BPEL process 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.

    • If you select Invoke from the Type list and Undelivered from the Message State list, and then click Recover, a recovery is performed. However, the Last Modified Date column remains empty for this instance on the Dashboard page of the Oracle BPEL Process Manager service component or service engine. This is the expected behavior. The last modified date is not displayed because the initial Oracle BPEL Process Manager instance (for example, bpel:70004) is created by the first invocation (that is, it is created, but has not yet been modified). The recovery of the undelivered invocation message always creates a new instance (for example, bpel:70005). The previously created instance (bpel:70004) is not used and remains permanently in the same status (the Last Modified Date column is empty). This information is provided for auditing purposes only.

    • The Message States list is applicable only to callback and invoke message type recovery, and not for activity message type recovery.

  3. Select a fault in the table.

  4. 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.

    Mark Cancelled

    Marks the message so it is never delivered. If you select messages in the exhausted state and click this button, recovery is never attempted on them.

    Note: The Recover and Mark Cancelled buttons are enabled in the following situations:

    • For users with the administrator or operator role. These buttons are disabled for users with the monitor role.

    • In the context of a recoverable message. You must select a recoverable message for these buttons to be enabled.

    For more information about roles, see Appendix C, "Roles and Privileges."

    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-retry action and a fault occurs, the BPEL process attempts to recover from the fault the number of times you specified with the retryCount parameter. 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 configuring the maximum number of times to attempt an invoke and callback message recovery, see Section 12.4, "Configuring Automatic Recovery Attempts for Invoke and Callback Messages."

14.5 Storing Instance and Callback 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 11g Release 1 11.1.1.6 on an Oracle Exalogic platform, you can use the distributed cache feature of Oracle Coherence to store instance and callback 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:

For more information about Oracle Coherence, see the Oracle Coherence Getting Started Guide and Oracle Coherence Developer's Guide.

For more information about Oracle Exalogic, see the Oracle Exalogic Machine Owner's Guide.

14.5.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 14-1 provides details about the dehydration process.

Figure 14-1 Dehydration Process

Description of Figure 14-1 follows
Description of "Figure 14-1 Dehydration Process"

During rehydration, instance objects are read from cache. JTA implementations do not provide XA guarantees for transaction completion notification, and cache eviction may delete the object from cache. JTA implementations account for these two scenarios and address the issues of cache not returning an object or returning an older version of the object. Figure 14-2 provides details about the rehydration process.

Figure 14-2 Rehydration Process

Description of Figure 14-2 follows
Description of "Figure 14-2 Rehydration Process"

If the instance object is not found in cache, it is loaded from the database. In this scenario, cache does not provide any benefits. However, if you configure the correct amount of cache for your environment, this is not common. The correct cache size varies based on your environment. Therefore, Oracle Coherence configuration must be available and you should be able to configure it.

To identify object staleness, the CACHE_VERSION column in the database table is queried and compared to the corresponding cacheVersion object attribute. If the comparison fails, instance objects are loaded from the database. In this scenario, cache provides no benefit. However, this is a rare occurrence.

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. The BPEL process service engine checks for the availability of cache, resuming its usage when it is back online. While cache is unavailable, warning messages are logged and you may notice a decrease in performance.

14.5.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 Section 14.5.5, "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 Oracle Coherence Developer's Guide.

14.5.3 Configuring Oracle Coherence Caching

The System MBean Browser property QualityOfService enables you to configure Oracle Coherence for dehydration. You must configure this property on all nodes in the SOA cluster.

To configure Oracle Coherence for dehydration:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator...
    1. Select SOA Administration > BPEL Properties.

    1. Right-click soa-infra.

    2. Select SOA Administration > BPEL Properties.


    The BPEL Service Engine Properties page is displayed.

  2. Click More BPEL Configuration Properties.

  3. In the Attributes tab, click QualityOfService.

  4. In the Value field, enter a value appropriate to your environment. This change does not require a SOA Infrastructure restart.

    Table 14-1 qualityOfService Values

    Value Description

    DirectWrite

    No cache is used for dehydration and rehydration. Read and write operations are done to the database. This is the default setting.

    CacheEnabled

    During 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 stale, data is read from the database.


  5. Click Apply.

14.5.4 Configuring the Storage of Multiple Audit Trail Messages in One Transaction

For asynchronous flows, performance gains can be achieved by storing multiple audit 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 messages in one transaction:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator...
    1. Select SOA Administration > BPEL Properties.

    1. Right-click soa-infra.

    2. Select SOA Administration > BPEL Properties.


    The BPEL Service Engine Properties page is displayed.

  2. Click More BPEL Configuration Properties.

  3. In the Attributes tab, click AsynchAuditBatchSize.

  4. In the Value field, enter a value appropriate to your environment. The default value of -1 indicates that there is no audit trail message batching. Each audit message is persisted in its own transaction.

    The recommended value range is 5 to 25. For example, if you set this property to 8, 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.

  5. Click Apply.

14.5.5 Starting the BPEL Process Cache Servers

You must run the start-bpel-cache.sh. script to start the BPEL process cache servers. This script must be run on UNIX platforms. This script is independent of the SOA cluster. It can be on the same node as the SOA cluster nodes or on a completely different host. 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 or setDomainEnv.bat 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 (setDomainEnv.sh or setDomainEnv.bat).

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 Oracle Fusion Middleware High Availability Guide or Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for details.

To start the BPEL process cache servers:

  1. Go to the $FMW_HOME/SOA_ORACLE_HOME/bin directory.

  2. Open the start-bpel-cache.sh file.

  3. Follow the instructions inside this file to create the bpelCacheEnv.sh file and configure various environment variables.

    Environment/shell variable names and value formats are described in the initial notes section of the start-bpel-cache.sh file.

  4. Ensure that you first set the QualityOfService property to CacheEnabled in Oracle Enterprise Manager Fusion Middleware Control, as described in Section 14.5.3, "Configuring Oracle Coherence Caching."

  5. Go to the $FMW_HOME/SOA_ORACLE_HOME/bin directory.

  6. Run the following script:

    start-bpel-cache.sh