SOA 11g - BPEL Performance Tuning Parameters

This post shows some properties which we can be set inside our composite which impact the performance.

·         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 True, 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.

·         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 table dlv_message. These requests are later acquired by Oracle BPEL Server worker threads and delivered to the targeted BPEL process. This property persist delivery messages and is applicable to durable processes.

When setting the oneWayDeliveryPolicy property to async.cache, One-way invocation messages are stored in the delivery cache until delivered and 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.

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.

Refernce: Oracle SOA Performance Tuning Guide

SOA 11g - The Transaction was rolled back. The work performed for the instance "X" was rolled back........

Error: The transaction was rolled back. The work performed for bpel instance "X" was rolled back, but the audit trail has been saved for this instance.If this is a sync request, please resubmit the request from the client. If it is an async request, please recover from the recovery console by resubmitting the invoke message.The transaction was rolled back. The work performed for bpel instance "X" was rolled back, but the audit trail has been saved for this instance.If this is a sync request, please resubmit the request from the client. If it is an async request, please recover from the recovery console by resubmit the request from the client. If it is an async request, please recover from the recovery console by resubmitting the invoke message.

  

We usually get this error because of timeout issue. To see what exactly wrong you can see the log file and correct your code. But some time we didn’t see anything in log file and we don’t know what exactly causing this issue, then most of the time this issue comes when you call some service and that service is taking some time to send response back and during that time BPEL service timeout.

So to resolve this you can increase timeout setting that will help you to overcome this issue. You can find couple of blogs and oracle documents to increase timeout setting. I found below blog which explains all the timeout settings.

http://technology.amis.nl/2011/11/18/timeouts-in-oracle-soa-suite-11g/

But remember, once you change timeout setting that will affect all your services deployed to that domain.

Sometime we also notice that once BPEL process rollback then it will start processing again and it will retry (run the same BPEL) process 2-3 times and finally move to Manual recovery if that fault is retry able.

To resolve above issue (BPEL should not retry), we need to change setting in MBean browser. We can change below properties value in Mbean browser. 

• GlobalTxMaxRetry: Maximum number of time BPEL service will retry if fault is retry able..
• GlobalTxRetryInterval : Time interval between each retry

To change these property value go to below path.

Soa-infra à SOA Administration à Common Properties àMore SOA Infra Advanced Configuration Properties

You can set GlobalTxMaxRetry property vale to 0 to avoid BPEL process retries.

OSB 11g - Failure while unmarshalling message: Failed to transform MFL content from binary to XML.

In Post-1 & Post-2 , I explained how we can use MFL to transform Non-XML data to XML format. But we may face below error when we try to transform Non-XML data to XML format.

Error: Failure while unmarshalling message: Failed to transform MFL content from binary to XML.

  

Jeff Davis shared some useful information regarding this in his blog.

https://blogs.oracle.com/jeffdavies/entry/mfl_and_the_bea_382030

But if still it didn't slove your issue then follow below steps:

This is very simple trick, Go to mfl file and go to Tools --> Test

Instead of pasting data in left pane click on Generate --> Non-XML

This will generate sample Non-XML data for you.

Once you got correct sample Non-XML data from format builder then you can compare it with your file data and make necessary changes.

 

OSB 11g- Non-XML To XML Transformation (MFL) in OSB Part -2

In Part-1 , we created MFL file using format builder. In this post, I will show you how we can use  MFL in osb project to transform Non-XML data to XMl data.

First of all we will create xquery file which will map Non-XML data and XML data. Follow below steps to create Xquery file.

- Create XSD(Schema) file according to that XML structure that we need finally.

- In Xquery source side choose "Non-XML" radio button and choose Customer.mfl file.

- In Target Side choose "XML" radio button and choose above created schema.

- Perform the required mapping.

Now we will create a Business service to write XML file. You can follow my previous post to create the required business service.

Now we will create a proxy service that will read/poll the tab delimited file and pass this to above created business service. Follow below steps to create it.

- Choose "Messaging Service" as Service Type. Click Next.

- Choose "MFL" as Request Message type and browse Customer.mfl file.

- Fill all other required information, you can refer my previous post to see how to create proxy service to read/poll file.

- Now we will call Business service from proxy service, to do that go Message flow of proxy service and add route node. In the routing browse business service.

-Now in Request Action of Message Flow add assign activity, which will assign output of Xquery to a variable, we can not assign output of Xquery to Body variable, if we try to do then we will get below error.

Error: “Failed to set the value of context variable "body". Value must be an instance of {http://schemas.xmlsoap.org/soap/envelope/}Body.”

To assign xquery response to a variable, go to "XQuery Resources" tab and refer Xquery path and variable binding.

- Now we need to intilize the body variable to pass it to business servive, to do that add another assign activity and go to "Expression" tab and assign empty body to body variable.

- Now we will insert test variable to body variable, to do that ass Insert activity.

- Below is the final Message Flow of proxy service.

Test this by putting tab delimited file in read folder from where proxy service will read/poll that file. and we will final xml file in required format.


You may face below error while transforming Non-XML data to XML data, follow my next post to resolve that error.

OSB 11g - Non-XML to XML transformation (MFL) in OSB Part - 1

In SOA, we use file adapter to read Non-XMl file and transform it to XML format but in OSB along with file adapter we also have MFL that we can use to transform Non-XML data to XML data.

We use Format Builder to create mfl files and we can't create mfl file from OSB console, we have to use OSB IDE (Eclipse) to create this mfl file.

In this post, I will show you how we can transform Non-XML data to XML data using MFL. To show this, we prepared one use case in which we will read tab delimited file and transform it to XML format and write to one location.

Tab Delimited File

1              Vivek      28           India

2              Garg       28           India

Final XML Format

<Customer >

<CustInfo>

<Id>1</Id>

<Name>Vivek</Name>

<Age>28</Age>

<Country>India<Country>

</CustInfo>

<CustInfo>

<Id>2</Id>

<Name>Garg</Name>

<Age>28</Age>

<Country>India<Country>

</CustInfo>

</Customer>

First of all, we will create mfl file from Format Builder. Follow below steps to create MFL file.

- Open Eclipse and create one OSB project. Create required folder structure and under mfl folder create new MFL file. Give it a name (Customer.mfl).

- Open above created mfl file and start building it. Whatever name you will give to mfl file name, that name will appear as first element in mfl. As "CustInfo" is the repeating tag so we will add a Group under Customer in Mfl, to do this right-click on Customer and click on Insert Group.

- Choose below options for CustInfo Group.

- Now add respective elements under CustInfo Group and all these element will be added as child of Group. Id, Age, Name elements are separated by tab.

 Another main point to note here is the Code Page, choose "UTF-8......." from dropdown.

- Country element/child is delimited by end of line so in delimiter mention \n.

- Below is the final structure.

Follow below steps to test above created MFL file.

 - Go to Tools --> Test.

- Put Non-XML data that we want to test in left pane and click on "Non-XML To XML" under Transform option.

-  You will see the final XML in right pane.

Follow Part-2 to see how we will use this MFL file in OSB project to transform Non-XML data to XML format.

OSB 11g - Change Filename Dynamically in Oracle Service Bus

In my previous post, I explained how we can write file in OSB using file protocol. But in that case we hard-coded the file name and we may come across some requirement in that we need to set filename dynamically.

In this post, I will show you how you can change/set filename dynamically in Oracle Service Bus.

To accomplish this, OSB provided one activity with the name “Transport Header”. We will use this activity to set file name dynamically. In this activity we can also add multiple headers that mean we can set multiple headers at one time.

 To set File name choose "fileName" under file.

To set new file name click on expression in "set header to". you can new name to file name dynamically , like I simply assign input element text to file name.

Make sure to put /text() at end of element to get text of that element.

OSB 11g - Access MDS in OSB

Oracle Service Bus does not support MDS so we can't use oramds: function in OSB as we can use it in SOA.

But we can use some alternative ways to access MDS from OSB. Below are the two ways to access MDS from OSB.

ACCESS MDS VIA HTTP

Suppose all the required artifacts are there in MDS and we want to use Item.xsd schema in OSB which is there in MDS under EnterpriseObjectLibrary folder .

Assume you have a SOA process “HelloWorld” deployed to SOA server, then you can access the above schema like below:

http://host:port/soa-infra/services/parition/HelloWorld/apps/EnterpriseObjectLibrary /Item/Item.xsd

Please note, "HelloWorld" can be a process that has nothing to do with your XSD file collections! In other words, you can use any other SOA process to access MDS artifacts. All of the XSDs in MDS can be accessed this way.

Cons:

•         Since we used full path which includes server host and port so when we move our code to respective environments then we have to change server host and port respective to server.
•         OSB project will be dependent on SOA server because all the artifacts will be accessible only when SOA server is up, when SOA server is down then we will not be able to access the artifacts as SOA process will also be down when SOA server is down through which we access MDS artifacts.

Registering MDS Artifacts with OSB (Import MDS Jar to OSB)

The MDS artifacts are shared project resources that must be uploaded for development of any project.

These common resources can be uploaded into the OSB using two approaches:

·          As a zipped file

·          As a jar file

The recommended approach is to register the MDS artifacts as a jar file.

MDS artifacts are subject to enhancements and these enhancements are usually applied as patches, or as new versions of the libraries. To update the existing MDS you must upload the updated artifacts into OSB and manage the enhancements. It is recommends that the artifacts be imported as a jar file into OSB. When enhancements/patches are to be applied, a new jar file with changed artifacts must be re-imported into OSB. Thus, the artifacts that require an update are replaced by the new ones in the new jar file.

Note: If you change or extend an Enterprise Business Object or an Enterprise Business Service, you need to re-import it into OSB. You can either import those artifacts alone or you can zip the whole library again and import. AIA recommends importing only those objects that have changed.

Note: It is assumed that a jar file with MDS artifacts is available. (This jar file is a service bus configuration file.) The following issue should be addressed by jar file

OSB can only create services from WSDLs that have either binding or port information in them. AIA recommends that binding information be added to the ESL (Enterprise Service Library) with SOAP as the binding.

The MDS artifacts library, imported into the OSB as a jar file, should have the all WSDL files updated with details of bindings before it is used for creating OSB services.

References: Guide to Implementing Application Integration Architecture on Oracle Service Bus

An Oracle White Paper

March 2011