File Adapter Error Handling through Fault Policy Framework for rejected files.

Hi,

In this post, let us see how to handle rejected files.

File Adapters/ FTP Adapters which are used in scenarios where files are polled in SOA Suite, there are cases where corrupt or bad files can come or be present.

By default, File Adapter uses a default location to put rejected files as per the control directory which is configured in the Adapter configuration in weblogic. The instance is faulted in EM console corresponding to the rejected file case. The moment happens before an instance is created through BPEL/Mediator and after the JCA based File Adapter polls the file.

Here is a diagram which explains something about Fault Policy Framework
image : www.ateam-oracle.com

 
The fault policy framework works for File Adapter error scenarios if in place.

Here is a sample:

Below is an extract from Fault Binding xml file. A fault binding file is structured for composite, component, reference and service faults. Here, file adapter read is a service so I have added "RejectedMessages" as the fault policy to refer to. There are two composites which uses File/FTP adapter to read the files.

-ReadOrderFile
-ReadPaymentFile
 

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicyBindings version="2.0.0"
                     xmlns="http://schemas.oracle.com/bpel/faultpolicy"
                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <composite faultPolicy="ErrorFaultPolicy"/>
    <component faultPolicy="ErrorFaultPolicy"/>
    <reference faultPolicy="ErrorFaultPolicy"/>
    <service faultPolicy="RejectedMessages">
        <name>ReadOrderFile</name>
        <name>ReadPaymentFile</name>
    </service>
</faultPolicyBindings>


Forany service related error, we can configure the Fault Policy framework to handle it.

Let us see the Fault policy file.

<faultPolicy version="2.0.0" id="RejectedMessages">
    <Conditions>
      <faultName xmlns:rjm="http://schemas.oracle.com/sca/rejectedmessages"
                 name="rjm:ReadOrderFile">
        <condition>
          <action ref="ReadOrderFile_001"/>
        </condition>
      </faultName>
      <faultName xmlns:rjm="http://schemas.oracle.com/sca/rejectedmessages"
                 name="rjm:ReadPaymentFile">
        <condition>
          <action ref="ReadOrderFile_002"/>
        </condition>
      </faultName>
...
...
...
 <Actions>
      <Action id="ReadOrderFile_001">
        <fileAction>
          <location>/../../../error</location>
          <fileName>Order_Error_%ID%_%TIMESTAMP%.dat</fileName>
        </fileAction>
      </Action>
      <Action id="ReadOrderFile_002">
        <fileAction>
          <location>/../../../error</location>
          <fileName>Payment_Error_%ID%_%TIMESTAMP%.dat</fileName>
        </fileAction>
      </Action>
...
...

So you can see here, that rejected files will be thrown to the given sample location with a generated ID and TIMESTAMP. The location and fileName tags defines those details about the File Action.

The actions are choice. We can either call a java service, a bpel composite , retry , rethrow etc for the way we want to handle the fault.

The best practice is to push the rejected files into a particular location shared to the application response for generating file data. Further, any manual/automated activity can be executed to decide actions taken on those corrupted files.

Thanks.

Dynamic Endpoint Url Invocation in BPEL

Hi,

I would like to share how to dynamically call a Web Service through BPEL using Endpoint Reference.

Firstly lets understand what use the Dynamic Endpoint Invocation could be. In scenarios where you have a good number of Services whose consumption parameters are same, ie input-output, to avoid code multiplication, we use DEI. Else a developer would end up creating as many partner links as the number of isomorphic services exists.

image : msdn.microsoft.com




First of all, you need to have the URL generated at runtime either through DVM / any source service request/ Database/ MDS etc.

In BPEL, assign the URL to a variable say ServiceToInvokeVar


ex:
 1
<assign name="Set_ServiceToInvokeVar">
      <copy>
        <from variable="inputVariable" part="payload"
              query="/ns3:******/ns3:*******/ns3:AbcsEndPointUrl"/>
        <to variable="ServiceToInvokeVar"/>
      </copy>
    </assign>
2
 <assign name="Assign_Endpoint">
      <copy>
        <from>
<EndpointReference xmlns="http://schemas.xmlsoap.org/ws/2003/03/addressing">
            <Address/>
 </EndpointReference>
</from>
        <to variable="EndpointReferenceVar" query="/ns1:EndpointReference"/>
      </copy>
      <copy>
        <from variable="ServiceToInvokeVar"/>
        <to variable="EndpointReferenceVar"
            query="/ns1:EndpointReference/ns1:Address"/>
      </copy>
      <copy>
        <from variable="EndpointReferenceVar"/>
        <to partnerLink="ABCSService"/>
      </copy>
    </assign>


If the above seems complicated to you, here I can explain here,

1. Assigned your runtime populated Endpoint to a variable say X.
2. Assign the EndpointReference WS-Addressing structure to a variable say E with null address.
3. Assign X to "/ns1:EndpointReference/ns1:Address"
4. Assign  E to your partner link.

Thats it !

Calling a HTTPs POST REST url web service which is SSL Certificate Secured Oracle Service Bus OSB

In one of my projects, I had a requirement to call a web service which was a REST service and I had to POST XML content to the web service. The web service URL demanded to query parameters though and the service only wanted a XML to be POSTed.
The service was Certificate SSL secured with HTTPs basic authentication.

So here are the steps which I did using Oracle Service Bus.

Firstly, I went to the UNIX box the ran the below command to load the certificate from the web service.
I used the openssl utility to load the certificate. Other option is any browser to do the same. The certificates nature vary from being a chain of certificates being CA signed or a single self- signed certificate. In my case it turned out to be a single self signed certificate.
Here is the command -

openssl s_client -connect host:port | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' &gt; /..../somename.cert

Once the certificate was loaded. I had to loaded it up into the keystore of weblogic. To load it, I used the keytool utility.

Loading into the Java Keystore -

keytool -import -trustcacerts -keystore /appl/oracle/dev/fmw/11g/java/jrockit-jdk1.6.0_81/jre/lib/security/cacerts -noprompt -alias somealias -file somename.cert



Loading into the Default weblogic demoTrust keystore. Note, for production, it can be the Custom Trust store.

keytool -import -trustcacerts -keystore /appl/oracle/dev/fmw/11g/product/wlserver_10.3/server/lib/DemoTrust.jks -noprompt -alias somealias -file somename.cert

and the work for the certificate part was done.

Now, since the service was HTTPs basic authentication secured too, so an OSB Service Account was used to provide a static username and password and associate it with the Business Service.

After create the Business Service, I had too only put the XML content in the Request panel and the work was done.

Importance of Synchronous BPEL composite using File Adapter

By default, the JDeveloper wizard generates asynchronous WSDLs when you use technology adapters. Typically, a user follows these steps when creating an adapter scenario in 11g:
1) Create a SOA Application with either "Composite with BPEL" or an "Empty Composite". Furthermore, if  the user chooses "Empty Composite", then he or she is required to drop the "BPEL Process" from the "Service Components" pane onto the SOA Composite Editor. Either way, the user comes to the screen below where he/she fills in the process details. Please note that the user is required to choose "Define Service Later" as the template.

2) Creates the inbound service and outbound references and wires them with the BPEL component:
 
  3) And, finally creates the BPEL process with the initiating activity to retrieve the payload and an activity to write the payload.

This is how most BPEL processes that use Adapters are modeled. And, if we scrutinize the generated WSDL, we can clearly see that the generated WSDL is one way and that makes the BPEL process asynchronous (see below)


In other words, the inbound FileAdapter would poll for files in the directory and for every file that it finds there, it would translate the content into XML and publish to BPEL. But, since the BPEL process is asynchronous, the adapter would return immediately after the publish and perform the required post processing e.g. deletion/archival and so on.  The disadvantage with such asynchronous BPEL processes is that it becomes difficult to throttle the inbound adapter. In otherwords, the inbound adapter would keep sending messages to BPEL without waiting for the downstream business processes to complete. This might lead to several issues including higher memory usage, CPU usage and so on.
In order to alleviate these problems, we will manually tweak the WSDL and BPEL artifacts into synchronous processes. Once we have synchronous BPEL processes, the inbound adapter would automatically throttle itself since the adapter would be forced to wait for the downstream process to complete with a before processing the next file or message and so on.
Please see the tweaked WSDL below and please note that we have converted the one-way to a two-way WSDL and thereby making the WSDL synchronous:

Add a activity to the inbound adapter partnerlink at the end of your BPEL process e.g.

Finally, your process will look like this:

You are done.

Please remember that such an excercise is NOT required for Mediator since the Mediator routing rules are sequential by default. In other words, the Mediator uses the caller thread (inbound file adapter thread) for processing the routing rules. This is the case even if the WSDL for mediator is one-way.

FATAL Alert: BAD_CERTIFICATE - A corrupt or unuseable certificate was received

I am trying to invoke a third part web-service (https) through the Oracle Service Bus/Weblogic Server. However whenever I try to use a business service to connect I get the following error message:

The invocation resulted in an error: FATAL Alert:BAD_CERTIFICATE - A corrupt or unuseable certificate was received..


WL doesn't like wild card certs.

If you submit your request to "someserver.thirdparty.com" and you get back the above, you'll get the error.

You can 

* Disable host name verification ( never a pleasant thought )
* Write your own custom hostname verification
* Ask them to get a cert specific to their host ( with a CN of "someserver.mdsol.com, for instance ).
 

* Or apply the following method as part of Oracle given solution for WLS 10.3.6. or 10.3.5 and below  

In WLS releases before WLS 11.1.1.5 (WLS 10.3.5), WebLogic Server's hostname verification code did not support wildcard certificates. Thus as per a product enhancement, we have created a separate hostname verification code, which allows wildcard certificates.

Thus in order to have this functionality on WLS 10.3.5 and below, we have Patch 10215257 for WLS 10.3.0, 10.3.4, and 10.3.5.
NOTE: This wildcard implementation is embedded in the binaries of WLS 10.3.6 and 12.1.1.0, thus there is no requirement for a patch on those versions and higher.

Once we apply the apprropriate patch we need to do the following:

Add the server start-up parameter (in the java_options):
-Dweblogic.security.SSL.hostnameVerifier=weblogic.security.utils.SSLWLSWildcardHostnameVerifier,/div>
Navigate to Admin Console -> server_name -> SSL -> Advanced. Check the checkbox Use JSSE.

This has to be done on all the servers where we are planning to use the wild card certificate. If you are using WLS 10.3.6+ or WLS 12.1.1.0+, do the following:

Enable "Use JSSE."
Navigate to Admin console -> server_name -> SSL -> Advanced ->. Check the checkbox Use JSSE.
Select the value "weblogic.security.utils.SSLWLSWildcardHostnameVerifier" from the dropdown list of "Hostname verfication" parameters.

Note:

Weblogic server by default implements certicom SSL. In release WLS 10.3.4 the JSSE is implemented and certcom deprecated. As mentioned above.

But wth previous version i.e. 10.3 which hasn't got this option available in the console, we can implement the following parameters to enable Sun SSL implementation instead of certicom:

-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
-Dssl.SocketFactory.provider=com.sun.net.ssl.internal.SSLSocketFactoryImpl
-DUseSunHttpHandler=true
-Dweblogic.wsee.client.ssl.usejdk=true (for webservice clients)

***If the trust authority of weblogic default certificate and provider's certificate is same then you don't need to import its certificate in your trust store.

Weblogic WLST Script to Create JMS Artifacts in Clustered Environment

As a part one event, I had developed a WLST script to deploy JMS artifacts in a clustered environment. The script can deploy as many JMS Servers, JDBC Stores, File Stores, DQueues, DTopics with JMS Modules and Sub Deployments in a clustered web-logic environment.

Below figure depicts conventionally followed JMS Deployment Architecture.

JMS Deployment Architecture

Now let us start with the script :

There are two files as a whole. One is the python script or wlst script and the other is a properties file which contains metadata for the script.

1. createGenieJMSResources.py
2. crowdGenieJMS.properties

Let me first lay down the properties file contents.


################Start of the properties file###############

username=weblogic
password=weblogic@123
providerURL=t3://localhost:7001

#Cluster name on which the module is to be targeted
jms_clusterName=GenieCluster

#jms module and its sub deployment
jms_module=GenieModule

#files stores and data source and their respective store directory path - note: name assumed is "Store_"+jms_persistent_store_type+"_"+jms_targetManageServerName
jms_persistent_store_type=File,JDBC
optional_explicit_fileStoreDirectory=
dataSourceJNDIName=localDS

#manage servers which are to be targeted by JMS Servers and file stores respectively - note: name assumed for JMSServer is jms_module+"_JMSServer_"+jms_targetManageServerName
jms_targetManageServerName=Server-Genie1,Server-Genie2

#Destination Name and their respective jndi
jms_destination_jndi_name=jms/GenieQueue1,jms/GenieQueue2,jms/GenieQueue3,jms/GenieQueue4,jms/GenieQueue5,jms/GenieTopic1,jms/GenieTopic2,jms/GenieTopic3,jms/GenieTopic4
jms_type=Queue,Queue,Queue,Queue,Topic,Topic,Topic,Topic

#Connection Factories and their respective jndi's
jms_connFacJNDIName=fac/GenieConnFac1,fac/GenieConnFac2
xa_conn_flag=true,false

#flag for logging - if true then logs in the domain path with genieWLST.log else it stdouts on the console
log_file=true
log_path=

#flag to check if existing resources needs to be deleted and recreated, or error should log/pop out.
delete_if_exist_flag=true

#################End of the properties file#################

The important thing to note in the properties file is the comma separated values of several properties like jms_destination_jndi_name, jms_targetManageServerName. The script reads the values in a array loop on values split delimited by the ','. Look at the script code to better understand.
There are also naming convention to the file or data stores.

Now let us look at the script :


#the part contains import from java python lib. FOS and FIS is required for loading the properties file.
from java.io import FileOutputStream
from java.io import FileInputStream
from java.util import Properties
from java.io import File
import sys

try:

# Load the properties file.
def loadProperties(fileName):
properties = Properties()
input = FileInputStream(fileName)
properties.load(input)
input.close()

result= {}
for entry in properties.entrySet(): result[entry.key] = entry.value

return result

properties = loadProperties("crowdGenieJMS.properties")

#This is it checks if the WLST output files is to be generated a a user defined path or default same directory path where WLST script is kept.
if(properties['log_path']==""):
logFilePath="genieWLST.log"
else:
logFilePath=properties['log_path']+"//genieWLST.log"

#Setting the output log file
if(properties['log_file'] == "true"):
f = File(logFilePath)
fos = FileOutputStream(f)
theInterpreter.setOut(fos)


# Initializing

username = properties['username']
password = properties['password']
url = properties['providerURL']

moduleName = properties['jms_module']
subDeploymentName = moduleName+"SubDeployment"
storeType = properties['jms_persistent_store_type']

destinationJNDIName = properties['jms_destination_jndi_name']
destinationType = properties['jms_type']

CFJNDIName = properties['jms_connFacJNDIName']

clusterName = properties['jms_clusterName']

targetms = properties['jms_targetManageServerName']


# Connect to Admin Server
connect(username, password, url)
adminServerName = cmo.adminServerName


# Delete old resources, if they exist.
def deleteIgnoringExceptions(mbean):
try: delete(mbean)
except: pass

def startTransaction():
edit()
startEdit()

def endTransaction():
save()
activate(block="true")


def createUDTopic(topicName, jndiTopicName):

cd('/JMSSystemResources/'+moduleName+'/JMSResource/'+moduleName) 
udt1 = create(topicName, "UniformDistributedTopic")
udt1.JNDIName = jndiTopicName

cd("UniformDistributedTopics/"+topicName)
cmo.setSubDeploymentName(subDeploymentName)
cd("/")


def createUDQueue(qname, qjndiname):

cd('/JMSSystemResources/'+moduleName+'/JMSResource/'+moduleName)
udq1 = create(qname, "UniformDistributedQueue")
udq1.JNDIName = qjndiname

cd("UniformDistributedQueues/"+qname)
cmo.setSubDeploymentName(subDeploymentName)
cd("/")

def createCF(cfname, cfjndiname, xaEnabled):

cd('/JMSSystemResources/'+moduleName+'/JMSResource/'+moduleName)
cf = create(cfname, "ConnectionFactory")
cf.JNDIName = cfjndiname
cf.subDeploymentName = subDeploymentName

# Set XA transactions enabled
if (xaEnabled == "true"):
cf.transactionParams.setXAConnectionFactoryEnabled(1)
cd("/")

def createJMSModule():

cd('/JMSSystemResources')
jmsModule = create(moduleName, "JMSSystemResource")

cd('/JMSSystemResources/'+moduleName)
set('Targets',jarray.array([ObjectName('com.bea:Name='+clusterName+',Type=Cluster')], ObjectName))

# Create and configure JMS Subdeployment for this JMS System Module

sd = create(subDeploymentName, "SubDeployment")

cd('SubDeployments/'+subDeploymentName)

objName = ""
for mserver in targetms.split(','):
objName = objName + "ObjectName('com.bea:Name="+moduleName+"_JMSServer_"+mserver+",Type=JMSServer'), " 

objName="set('Targets',jarray.array(["+objName[:-2]+"], ObjectName))"

# executing python command to set target implicitly
exec objName

def createJMSServer():

i=0
ds=0
for mserver in targetms.split(','):

startTransaction()

# Assumed naming conventions
jmsServerName = moduleName+"_JMSServer_"+mserver
storeName = "Store_"+storeType.split(',')[i]+"_"+mserver


# Delete existing JMS Server and its persistent store
if(properties['delete_if_exist_flag']== "true"):
cd("/JMSServers")
deleteIgnoringExceptions(jmsServerName)

cd("/"+storeType.split(',')[i]+"Stores")
deleteIgnoringExceptions(storeName)

#Create JDBC Stores or File Stores
if(storeType.split(',')[i] == "JDBC"):
cd('/')
dsName = properties['dataSourceJNDIName'].split(',')[ds]
store = cmo.createJDBCStore(storeName)

cd('/JDBCStores/'+storeName)
cmo.setDataSource(getMBean('/SystemResources/'+dsName))
set('Targets',jarray.array([ObjectName('com.bea:Name='+mserver+',Type=Server')], ObjectName))
cmo.setPrefixName("GENIE_T_LOG_"+dsName)
ds=ds+1
else:
cd('/')
fileDir = properties['optional_explicit_fileStoreDirectory']
if fileDir == "":
fileDir = cmo.rootDirectory+"\\fileStores"+storeName

store = cmo.createFileStore(storeName)
store.setDirectory(fileDir)
cd('/FileStores/'+storeName)
set('Targets',jarray.array([ObjectName('com.bea:Name='+targetms.split(',')[i]+',Type=Server')], ObjectName))

endTransaction()
#Committed the creation of filestores

startTransaction()
cd("/JMSServers")
# Create JMS server and assign the Filestore

jmsServer = create(jmsServerName, "JMSServer")
jmsServer.setPersistentStore(store)

cd(jmsServerName)
set('Targets',jarray.array([ObjectName('com.bea:Name='+mserver+',Type=Server')], ObjectName))

i=i+1
endTransaction()

# The creation flow starts from here


if(properties['delete_if_exist_flag']== "true"):

startTransaction()
cd("/JMSSystemResources")
deleteIgnoringExceptions(moduleName)
endTransaction()

# Create JMS Servers along with JDBCStores or Filestores , delete the existing if required.
createJMSServer()


startTransaction()
# Create JMS Module and its subdeployment
createJMSModule()

# Create Queues and Topics : The names are same as the JNDI name tagged to the assumed Subbdeployment
di=0
for dtype in destinationType.split(','):
dname = destinationJNDIName.split(',')[di]
if(dtype == "Queue"):
createUDQueue(dname, dname)

if(dtype == "Topic"):
createUDTopic(dname, dname)
di=di+1

# Create Connection Factory with name same as JNDI tagged to the assumed Subdeployment
ci=0
for cf in CFJNDIName.split(','):
createCF(cf,cf, properties['xa_conn_flag'].split(',')[ci])
ci=ci+1

endTransaction()
except Exception, e:
dumpStack()
print e
cancelEdit("y")
#raise

disconnect()

stopRedirect()
exit()

Code shared in the below link :

https://drive.google.com/folderview?id=0B5jwUx0GPlTOZlZnNUtTNHFQYVE&usp=sharing

BPEL Performance Tuning Properties – 11g

Oracle SOA 11g 11. 1.1.6 Performance Tuning of BPEL Processes

BPEL Properties Set Inside a Composite

All the properties set in this section affect the behavior of the component containing the BPEL process only. Each BPEL process can be created as a component of a composite. These properties can be modified in composite.xml or in the System MBean Browser of Oracle Enterprise Manager Fusion Middleware Control. 

Some Concepts First

As a general practice, it is better to design your BPEL processes as transient instead of durable if performance is a concern. Note that this may not always be possible due to the nature of your process, but keep the following points in mind.

The dehydration store is uses to maintain long-running asynchronous BPEL instances storing state information as they wait for asynchronous callbacks. This ensures the reliability of these processes in the event of server or network loss. Oracle BPEL Process Manager supports two types of processes; transient and durable.

Transient Processes

Transient processes do not incur dehydration during their process execution. If an executing process experiences an unhandled fault or the server crashes, instances of a transient process do not leave a trace in the system. Thus, these instances cannot be saved in-flight regardless if they complete normally or abnormally. Transient processes are typically short-lived, request-response style processes. Synchronous processes are examples of transient processes.

Durable Processes

Durable processes incur one or more dehydration points in the database during execution. Dehydration is triggered by one of the following activities:

• Receive activity
• OnMessage branch in a pick activity
• OnAlarm branch in a pick activity
• Wait activity
• Reply activity
• checkPoint() within a <bpelx:exec> activity

 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, the completionPersistPolicy is used to determine persistence behavior. This property can only be set to True for transient processes or processes that do not contain any dehydration points such as receive, wait, onMessage and onAlarm activities. The inMemoryOptimization property is set at the BPEL component level. When set to False, dehydration is disabled which can improve performance in some use cases.
Values:
This property has the following values:

• False (default): instances are persisted completely and recorded in the dehydration store database.
• True: The completionPersist policy is used to determine persistence behavior. 

completionPersistPolicy

This property configures how the instance data is saved. It can only be set at the BPEL component level.The completionPersistPolicy property can only be used when inMemoryOptimization is set to be True (transient processes). Note that this parameter may affect database growth and throughput (due to reduced I/O).

Value	Description
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 of the instance is persisted within cube_instance table.
Off	No instances of this process are saved.

<component name="BPELProcess">
   <implementation.bpel src="BPELProcess.bpel" />

   <property name="bpel.config.completionPersistPolicy">faulted</property>
   <property name="bpel.config.inMemoryOptimization">true</property>
   ...
</component>

auditLevel

You can set the audit level for a BPEL process service component. This setting takes precedence over audit level settings at the SOA Infrastructure, service engine, and SOA composite application levels.

Set the bpel.config.auditLevel property to an appropriate value in the composite.xml file of your SOA project as shown in the example below:

<component name="BPELProcess">
<implementation.bpel src="BPELProcess.bpel" />
<property name="bpel.config.auditLevel">Off</property>
</component>

Value	Description
Inherit	Inherits the audit level from infrastructure level.
Off	No audit events (activity execution information) are persisted and no logging is performed; this can result in a slight performance boost for processing instances.
Minimal	All events are logged; however, no audit details (variable content) are logged.
Error	Logs only serious problems that require immediate attention from the administrator and are not caused by a bug in the product. Using this level can help performance.
Production	All events are logged. The audit details for assign activities are not logged; the details for all other activities are logged.
Development	All events are logged; all audit details for all activities are logged.

Partner Link Property

You can dynamically configure a partner link at runtime in BPEL. This is useful for scenarios in which the target service that BPEL wants to invoke is not known until runtime. The following Partner Link properties can be tuned for performance:

idempotent

An idempotent activity is an activity that can be retried (for example, an assign activity or an invoke activity). Oracle BPEL Server saves the instance after a nonidempotent activity. This property is applicable to both durable and transient processes.

Values:

This property has the following values:

• 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.
• True (default): If Oracle BPEL 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. Some examples of where this property can be set to True are: read-only services (for example, CreditRatingService) or local EJB/WSIF invocations that share the instance's transaction.

A BPEL invoke activity is by default an idempotent activity, meaning that the BPEL process does not dehydrate instances immediately after invoke activities. Therefore, if idempotent is set to true and Oracle BPEL Server fails right after an invoke activity executes, Oracle BPEL Server performs the invoke again after restarting. This is because no record exists that the invoke activity has executed. This property is applicable to both durable and transient processes.

If idempotent is set to false, the invoke activity is dehydrated immediately after execution and recorded in the dehydration store. If Oracle BPEL Server then fails and is restarted, the invoke activity is not repeated, because Oracle BPEL Process Manager sees that the invoke already executed.

When idempotent is set to false, it provides better failover protection, but at the cost of some performance, since the BPEL process accesses the dehydration store much more frequently. This setting can be configured for each partner link in the bpel.xml file.

nonBlockingInvoke

By default, Oracle BPEL Process Manager executes in a single thread by executing the branches sequentially instead of in parallel. When this property is set to True, the process manager creates a new thread to perform each branch's invoke activity in parallel. This property is applicable to both durable and transient processes.

Consider setting this property to True if you have invoke activities in multiple flow or flow n branches. This is especially effective if the parallel invoke activities are two-way, but some benefits can be realized for parallel one-way invokes as well.

Note:

Invocations to the same partner link will happen in sequence and not in parallel. If you invoke different partner links each time with nonBlockingInvoke set to True, then each link will work in parallel even if all of the partner links point to the same source.

Values:

• True: Oracle BPEL Server spawns a new thread to execute the invocation.
• False (default): Oracle BPEL Server executes the invoke activity in the single process thread.

validateXML

Enables message boundary validation. Note that additional validation can impact performance by consuming extra CPU and memory resources.

Values:

• True: When set to True the engine validates the XML message against the XML schema during <receive> and <invoke> for this partner link. If the XML message is invalid thenbpelx:invalidVariables run time BPEL Fault is thrown. This overrides the domain level validateXML property.
• False (default): Disables XML validation.

General Recommendations:

1. If your Synchronous process exceed, say 1000 instances per hour, then its better to set inMemoryOptimization to true and completionPersistPolicyto 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.

What should you do?

• If the design of the process allows it, design your BPEL processes as short-lived, synchronous transactions.
• If the design of the process allows it, avoid the activities listed above.

Any time your process is dehydrated to the dehydration store, this naturally impacts the performance of the process, and becomes a concern particularly in high volume environments.

Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL Processes:BPEL Threading Model

Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL Processes:BPEL Threading Model

When the dispatcher must schedule a dispatch message for execution, it can enqueue the message into a thread pool. Each dispatch set can contain a thread pool (java.util.concurrent.ThreadPoolExecutor). The BPEL thread pool implementation notifies the threads when a message has been enqueued and ensures the appropriate number of threads are instantiated in the pool.

Dispatcher System Threads

The dspSystemThreads property specifies the total number of threads allocated to process system dispatcher messages. System dispatcher messages are general clean-up tasks that are typically processed quickly by the server (for example, releasing stateful message beans back to the pool). 

Typically, only a small number of threads are required to handle the number of system dispatch messages generated during run time.

The minimum number of threads for this thread pool is 1 and it cannot be set to 0 a or negative number.

The default value is 2. Any value less than 1 thread is changed to the default.

Dispatcher Invoke Threads

The dspInvokeThreads property specifies the total number of threads allocated to process invocation dispatcher messages. Invocation dispatcher messages are generated for each payload received and are meant to instantiate a new instance.
If the majority of requests processed by the engine are instance invocations (as opposed to instance callbacks), greater performance may be achieved by increasing the number of invocation threads. Higher thread counts may cause greater CPU utilization due to higher context switching costs.

The minimum number of threads for this thread pool is 1 and it cannot be set to 0 a or negative number.
The default value is 20 threads. Any value less than 1 thread is changed to the default.

Dispatcher Engine Threads

The dspEngineThreads property specifies the total number of threads allocated to process engine dispatcher messages. Engine dispatcher messages are generated whenever an activity must be processed asynchronously. If the majority of processes deployed are durable with a large number of dehydration points (mid-process receive, onMessage, onAlarm, and wait activities), greater performance may be achieved by increasing the number of engine threads.


Note that higher thread counts can cause greater CPU utilization due to higher context switching costs.

The minimum number of threads for this thread pool is 1 and it cannot be set to 0 a or negative number.
The default value is 30 threads. Any value less than 1 thread is changed to the default.

Dispatcher Maximum Request Depth

The dspMaxRequestDepth property sets the maximum number of in-memory activities to process within the same request. After processing an activity request, Oracle BPEL Process Manager attempts to process as many subsequent activities as possible without jeopardizing the validity of the request. Once the activity processing chain has reached this depth, the instance is dehydrated and the next activity is performed in a separate transaction.
If the request depth is too large, the total request time can exceed the application server transaction time out limit.This process is applicable to durable processes.

The default value is 600 activities.

Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL Processes:Audit

AuditLevel

The auditLevel property sets the audit trail logging level. This configuration property is applicable to both durable and transient processes. This property controls the amount of audit events that are logged by a process. Audit events result in more database inserts into the audit_trail table which may impact performance. Audit information is used only for viewing the state of the process from Oracle Enterprise Manager Console.

Value	Description
Inherit	Inherits the audit level from infrastructure level.
Off	No audit events (activity execution information) are persisted and no logging is performed; this can result in a slight performance boost for processing instances.
Minimal	All events are logged; however, no audit details (variable content) are logged.
Error	Logs only serious problems that require immediate attention from the administrator and are not caused by a bug in the product. Using this level can help performance.
Production	All events are logged. The audit details for assign activities are not logged; the details for all other activities are logged.
Development	All events are logged; all audit details for all activities are logged.

AuditDetailThreshold

The auditdetailthreshold property sets the maximum size (in kilobytes) of an audit trail details string before it is stored separately from the audit trail. If an audit trail details string is larger than the threshold setting, it is not immediately loaded when the audit trail is initially retrieved; a link is displayed with the size of the details string. Strings larger than the threshold setting are stored in theaudit_details table, instead of the audit_trail table.

The details string typically contains the contents of a BPEL variable. In cases where the variable is very large, performance can be severely impacted by logging it to the audit trail.

The default value is 50000 (50 kilobytes).

AuditStorePolicy

This property specifies the strategy to persist the BPEL audit data.

Value	Description
syncSingleWrite (default)	AuditTrail and dehydration are persisted to DB in one transaction.
syncMultipleWrite	AuditTrail and dehydration are persisted in the same thread but separate transactions.
async	AuditTrail and dehydration are persisted by separate threads and separate transactions.

By default, audit messages are stored as part of the main BPEL transaction. A BPEL instance holds on to the audit messages until the flow reaches dehydration. In some use cases, for example when you have a large loop, and there is no dehydration point in the loop, a large number of audit logs are accumulated. This could lead to an out-of-memory issue and BPEL main transaction can experience timeout errors. You may consider using syncMultipleWrite or async to store the audit message separately from the main transaction.
When you use syncMultipleWrite and async auditStorePolicy, there are a few other properties that need to be considered. Please see the sections below.

AuditFlushByteThreshold

This property controls how often the engine should flush the audit events, basically after adding an event to the current batch, the engine checks to see if the current batch byte size is greater than this value or not.
Consider tuning this property when async or syncMultipleWrite audit strageties are used. This size needs to be tuned based on the application.

AuditFlushEventThreshold

This property controls how often the engine should flush the audit events, basically when it reaches this limit of the number of events, the engine would trigger the store call.
Consider tuning this property when async or syncMultipleWrite audit strageties are used. This size needs to be tuned based on the application.

Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL: Significant Tips

OneWayDeliveryPolicy

The oneWayDeliveryPolicy is from the Oracle 10g configuration property deliveryPersistencePolicy.

The new configuration property name is bpel.config.oneWayDeliveryPolicy.

The oneWayDeliveryPolicy property controls database persistence of messages entering Oracle BPEL Server. By default, incoming requests are saved in the delivery service database tabledlv_message. These requests are later acquired by Oracle BPEL Server worker threads and delivered to the targeted BPEL process. This property persists delivery messages and is applicable to durable processes.
When setting the oneWayDeliveryPolicy property to async.cache, if the rate at which one-way messages arrive is much higher than the rate at which Oracle BPEL Server delivers them, or if the server fails, messages may be lost. In addition, the system can become overloaded (messages become backlogged in the scheduled queue) and you may receive out-of-memory errors. Consult your own use case scenarios to determine if this setting is appropriate.
One-way invocation messages are stored in the delivery cache until delivered. If the rate at which one-way messages arrive is much higher than the rate at which Oracle BPEL Server delivers them, or if the server fails, messages may be lost.

Value	Description
async.persist (Default)	Delivery 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, this setting should be considered.
sync	Directs Oracle BPEL Server to bypass the scheduling of messages in the invoke queue, and invokes the BPEL instance synchronously. In some cases this setting can improve database performance.

MaximumNumberOfInvokeMessagesInCache

This property specifies the number of invoke messages that can be kept in the in-memory cache. Once the engine hits this limit, it would push the message to dispacther in-memory cache, instead it would save the message in the db and these saved messages can be recovered using recovery job. You can use value -1 to disable.
The default value is 100000 messages.

StatsLastN

The StatsLastN property sets the size of the most-recently processed request list. After each request is finished, statistics for the request are kept in a request list. A value less than or equal to 0 disables statistics gathering. To optimize performance, consider disabling statistics collection if you do not need them.
This property is applicable to both durable and transient processes.
The default value is -1.

LargeDocumentThreshold

The largedocumentthreshold property sets the large XML document persistence threshold. This is the maximum size (in kilobytes) of a BPEL variable before it is stored in a separate table from the rest of the instance scope data.
This property is applicable to both durable and transient processes.
Large XML documents impact the performance of the entire Oracle BPEL Server if they are constantly read in and written out whenever processing on an instance must be performed.
The default value is 10000 (100 kilobytes).

Validate XML

The validateXML property validates incoming and outgoing XML documents. If set to True, the Oracle BPEL Process Manager applies schema validation for incoming and outgoing XML documents. Nonschema-compliant payload data is intercepted and displayed as a fault.
This setting is independent of the SOA composite application and SOA Infrastructure payload validation level settings. If payload validation is enabled at both the service engine and SOA Infrastructure levels, data is checked twice: once when it enters the SOA Infrastructure, and again when it enters the service engine
CAUTION: Enabling XML payload validation can impact performance.
This property is applicable to both durable and transient processes.
The default value is False.

SyncMaxWaitTime

The SyncMaxWaitTime property sets the maximum time the process result receiver waits for a result before returning. Results from asynchronous BPEL processes are retrieved synchronously by a receiver that waits for a result from Oracle BPEL Server.
The default value is 45 seconds.

InstanceKeyBlockSize

The InstanceKeyBlockSize property controls the instance ID range size. Oracle BPEL Server creates instance keys (a range of process instance IDs) in batches using the value specified. After creating this range of in-memory IDs, the next range is updated and saved in the ci_id_range table.
For example, if instanceKeyBlockSize is set to 100, Oracle BPEL Server creates a range of instance keys in-memory (100 keys, which are later inserted into the cube_instance table as cikey). To maintain optimal performance, ensure that the block size is larger than the number of updates to the ci_id_range table.
The default value is 10000.

MaxRecoverAttempt

You can configure the number of automatic recovery attempts to submit in the same recoverable instance. The value you provide specifies the maximum number of times invoke and callback messages are recovered. Once the number of recovery attempts on a message exceeds the specified value, a message is marked as nonrecoverable.
When a BPEL instance makes a call to another server using invokeMessage, and that call fails due to a server down, validation error, or security exception, the invokeMessage is placed in a recovery queue and BPEL attempts to retry those messages. When there are many messages, and a majority of them are being sent to the same target, the target can become overloaded. Setting the appropriate value of MaxRecoveryAttempt will prevent excessive load on servers that are targeted from BPEL web service calls.