BPEL Persistance properties are used to control, when a process need to dehydrate. Below are the properties which we can use to control it for BPEL Component in a Composite.

inMemoryOptimization

This property indicates to Oracle BPEL Server that this process is a transient process and dehydration of the instance is not required. When set to true, Oracle BPEL Server keeps the instances of this process in memory only during the course of execution. This property can only be set to true for transient processes (process type does not incur any intermediate dehydration points during execution).

false (default): instances are persisted completely and recorded in the dehydration store database for a synchronous BPEL process.

true: Oracle BPEL Process Manager keeps instances in memory only.

completionPersistPolicy

This property controls if and when to persist instances. If an instance is not saved, it does not appear in Oracle BPEL Console. This property is applicable to transient BPEL processes (process type does not incur any intermediate dehydration points during execution).

This property is only used when inMemoryOptimization is set to true.

This parameter strongly impacts the amount of data stored in the database (in particular, the cube_instance, cube_scope, and work_item tables). It can also impact throughput.

on (default): The completed instance is saved normally.

deferred: The completed instance is saved, but with a different thread and in another transaction, If a server fails, some instances may not be saved.

This property controls database persistence of messages entering Oracle BPEL Server. Its used when we need to have a sync-type call based on a one way operation. This is mainly used when we need to make an adapter synchronous to the BPEL Process.

By default, incoming requests are saved in the following delivery service database tables: dlv_message

1. If your Synchronous process exceed, say 1000 instances per hour, then its better to set inMemoryOptimization to true and completionPersistPolicy to faulted, So that we can get better throughput, only faulted instances gets dehydrated in the database, its goes easy on the purge (purging historical instance data from database)

2. Do not include any settings to persist your process such as (Dehydrate, mid process receive, wait or Onmessage)

3. Have good logging on your BPEL Process, so that you can see log messages in the diagnostic log files for troubleshooting.

This error can be safely ignored in the development environment. For production environment, consult with Oracle support. The reference on this error is also available in the weblogic documentation- CR#361988 HERE

After a few failed attempts, Ravi suggested that the Java version needs to be at least 1.6 or more. When I ran "java -version", it turned up to be 1.4.2. I knew that I had JDK 1.6 installed inside my Middleware home directory. I just had to change where the OS looked to to find the Java program. I tried setting the PATH and JAVA_HOME parameters but to no avail. Finally, I ran the command. "which java" which turned up "/usr/bin/java". That file turned out to be a symbolic link. All I had to was delete the symbolic link and recreate it to point to the JDK Java, which I did by running, "ln -s /oracle/fmwhome/jdk160_18/bin/java /usr/bin/java". To verify, I checked the version again by running "java -version" and it displayed "1.6". You might have to switch to root user to delete/recreate the symbolic link.

Now, after I ran the dbping command, it turned up a successful result.

Run the Repository Creation Utility (RCU) to install the metadata repository. The RCU is started from the rcuHome/bin directory. The RCU creates all tablespaces, schemas, and database objects required in the metadata repository for SOA Suite and BAM.

Install WebLogic Server and create the middleware home. Run the downloaded executable file for WebLogic Server 11g (the internal release number is 10.3.x). Select the option Create A New Middleware Home.

Install the SOA Suite. Run the executable runInstaller (Linux and Unix) or setup.exe and pass the parameter -jreLoc, specifying the location of a Java 6 run-time environment (for example, the one installed along with WebLogic Server in MIDDLEWARE_HOMEjdk160_11).

Configure the SOA Suite. At this point, we have the metadata repository prepared in the database and a clean install of the WebLogic Server. The SOA Suite software has been installed, but not yet configured. There is no SOA container running inside WebLogic Server just yet. This Configuration Wizard is located in the SOA_ HOME/common/bin directory (for Linux) or the SOA_HOMEcommonbin directory (for Windows). The wizard will create a new WebLogic domain called soa_domain. You have to provide the credentials for a new user who will have the Administrator role.

Install the Oracle Service Bus 11g. Install the OSB 11g into the same Middleware Home used for the SOA Suite 11g.

Start the AdminServer and the managed servers for SOA and BAM. First, to start the AdminServer, locate the startWebLogic.cmd script (Linux: startWebLogic.sh) in the MIDDLEWARE_HOME user_projectsdomainssoa_domain directory. Run this script from the command line. When the AdminServer is running, you should start the SOA server and optionally the BAM server and/or the OSB server. Go to the directory MIDDLEWARE_HOME user_projectsdomainssoa_domainbin, which was created by the SOA Suite Configuration Wizard. Open a command window and enter the following command to execute: startManagedWebLogic.cmd soa_server1