Problem while Emulating the XADataSource

Hi All,

In domain.log, If you can see the following error ;

Message handle error.
An exception occurred while attempting to process the message "com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessage"; the exception is: Branch [oracle.oc4j.sql.xa.EmulatedXAResource@454837, Xid( Global Id d4.14.26.b6.ff.ff.ff.ff.d8.b4.9d.4d.22.01.00.00.80.a5.1f.00.00.00.00.00, Format Id 1330790740, Branch Id 33.d3.88.8e.00.00.00.00.00.00.00.00.00.00.00.01), oracle.oc4j.sql.xa.EmulatedXAResource@454837, state={PREPARED}, exception error code=] in transaction Global Transaction Xid( Global Id d4.14.26.b6.ff.ff.ff.ff.d8.b4.9d.4d.22.01.00.00.80.a5.1f.00.00.00.00.00, Format Id 1330790740), type=orabpel, state=COMMITTING, time in completion or recovering=1)
{
[oracle.oc4j.sql.xa.EmulatedXAResource@454837, Xid( Global Id d4.14.26.b6.ff.ff.ff.ff.d8.b4.9d.4d.22.01.00.00.80.a5.1f.00.00.00.00.00, Format Id 1330790740, Branch Id 33.d3.88.8e.00.00.00.00.00.00.00.00.00.00.00.01), oracle.oc4j.sql.xa.EmulatedXAResource@454837, state={PREPARED}, exception error code=],
[oracle.oc4j.sql.xa.EmulatedXAResource@8833d8, Xid( Global Id d4.14.26.b6.ff.ff.ff.ff.d8.b4.9d.4d.22.01.00.00.80.a5.1f.00.00.00.00.00, Format Id 1330790740, Branch Id 33.d3.88.8e.00.00.00.00.00.00.00.00.00.00.00.00), oracle.oc4j.sql.xa.EmulatedXAResource@8833d8, state={PREPARED}, exception error code=]
} returned RB* during commit.

This problem arises because OC4j is trying to emulate the XADataSource.
When Oc4j tries to emulate the data source, it can lead to inconsistent transaction.

For more information refer to EMULATING XA section in following doc
http://download.oracle.com/docs/cd/B25221_04/web.1013/b14427/datasrc.htm#CHDHGDII

To solve the error,

1.We need to change the connection factory class attribute of connectionPools from 'oracle.jdbc.pool.OracleDataSource' to 'oracle.jdbc.xa.client.OracleXADataSource'.

2. We need to increase the maxConnection value of the BPELServerDataSource.

3. Increase the transaction time out value. We can also decrease the audit level.

Deployment Framework in SOA Suite 10.1.3.4

One of the coolest features in BPEL 10.1.3.4 is the deployment framework which makes the job of moving processes between dev, test and production environments much easier. Modifying the bpel.xml file or altering descriptors through the console provide a degree of customization for different environments, but it is all done on a single property at a time basis and requires a lot of work for each environment, especially when it is considered that individual WSDL files may also need to be updated. There is a better way in SOA Suite 10.1.3.4; the deployment framework.
The deployment framework combines the BPEL suitcase with a deployment plan that updates multiple files in the BPEL suitcase with the correct values for the deployment environment. Different deployment plans can be created and maintained for each deployment plan.

It is possible to generate a template BPEL deployment plan from a BPEL suitcase which can then be customized and used with the base BPEL suitcase at deployment time to update the various URLs and properties.
The steps to customize the BPEL Suitcase for each environment are as follows.
· Create a deployment template from the BPEL project or suitcase which will be used as the basis for the deployment plans.
· Create a deployment plan based on the template for each target environment.
· Attach the appropriate deployment plan to the BPEL suitcase or project prior to deploying in the target environment.
· Deploy the BPEL process into the target environment.

To create a deployment template we need to add the following commands to the build.xml ant file that is built by JDeveloper and found in the Resources folder of our BPEL project.


This creates two new ant targets, generate_plan_from_project and generate_plan_from_suitcase. These both create a template deployment plan, either directly from the project files, or from a generated suitcase. A BPEL suitcase is only generated when a BPEL project is deployed or when the project is “made”, so if using the option to generate from a suitcase it is necessary to ensure that the suitcase has previously been created. If the suitcase generated is a revision other than 1.0 then it is necessary to set the revision property in the build.properties file that is found in the Resources folder of the BPEL project in JDeveloper.

# Change below if deploying with process revision other than 1.0
rev = 1.1

The generateplan command in ant uses four attributes
· suitecase or descfile is the source information for the deployment plan.
· planfile is the location of the planfile template to be generated.
· overwrite will replace any existing planfile of the same name.
· verbose turns up the level of reporting.
A sample deployment plan template is shown below. Note the use of two elements:
· is used to replace the value of a property within a specific part of the bpel.xml
· is used to for a string in WSDL and XSD files and it with another string.

Creating a Deployment Plan
Having created a template we can use this to create deployment plans for each specific environment. We do this by creating a copy of the deployment plan by selecting Save As from the file menu in JDeveloper and then editing the and tags to match our target environment.
We will search and replace all instances of our local development machine hostname, w2k3, with the name of our test server, testserver, across wsdl and xsd files. To do this we modify the search and replace elements.

This will cause the BPEL process manager to search all WSDL and schema files “*” in the suitcase at deployment time and replace the string “w2k3” with the string “testserver”. Note that it is possible to have multiple elements.

Attaching a Deployment Plan to a BPEL Suitcase
Having created and saved a deployment plan specific for one or more specific environments we will want to deploy our process into an environment. Before doing this we must first attach the specific deployment plan to the BPEL suitcase. We do this using the following ant command.
<target name="attach_plan">

This will create a file bpeldeployplan.xml in the BPEL suitcase. This is the deployment plan that will be used at deployment time by the BPEL process manager. Note that the name of the deployment plan to use is encoded as an Ant property planfile that must be set in the build.xml. Once attached the deployment plan will be executed when the BPEL suitcase is deployed.

Modifying Ant to Use Deployment Plan
In addition to adding the two tasks above to the build.xml file, it is possible to add the attachment of the plan file as part of the regular deploy process by modifying the dependencies of the process-deploy task by adding the attach_plan dependency after the compile dependency.

Now when building and deploying with ant the deployment plan will be attached to the suitcase before the suitcase is deployed to the target environment. This allows us to provide a different deployment plan for each environment, which can then be deployed from the command line in a reproducible fashion.

Summary
The deployment plans allow a lot of automation in the move from development to production, and because they can be used with editable files and command lines they are easy to include in the version control systems and automated build environments. Congratulations to the BPEL developers on a useful piece of functionality that appeals to those responsible for ensuring consistency of environments rather than developers.

Cheers
Ayush

SOA Overview

Service-oriented architecture (SOA) Definition : A service-oriented architecture can be defined as a group of services, which communicate with each other.
The process of communication involves either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
SOAs build applications out of software services. Services are intrinsically unassociated units of functionality, which have no calls to each other embedded in them. They typically implement functionalities most humans would recognize as a service, such as filling out an online application for an account, viewing an online bank statement, or placing an online booking or airline ticket order. Instead of services embedding calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement.

XML has been used extensively in SOA to create data which is wrapped in a nearly exhaustive description container. Analogously, the services themselves are typically described by WSDL, and communications protocols by SOAP. Whether these description languages are the best possible for the job, and whether they will remain the favorites in the future, is an open question. What is certain is that SOA is utterly dependent on data and services that are described using some implementation of metadata which meets the following two criteria: the metadata must be in a form which software systems can use to configure themselves dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity. The metadata must also be in a form which system designers can understand and manage at a reasonable cost and effort.
SOA services are loosely coupled, in contrast to the functions a linker binds together to form an executable, a dynamically linked library, or an assembly. SOA services also run in "safe" wrappers such as Java or .NET, and other programming languages that manage memory allocation and reclamation, allow ad hoc and late binding, and provide some degree of indeterminate data typing.
SOA is an architecture that relies on service-orientation as its fundamental design principle.In a SOA environment, independent services can be accessed without knowledge of their underlying platform implementation.
SOA relies on services exposing their functionality via interfaces which other applications and services read to understand how the service can be utilized.