Monday, April 12, 2010

Multiple Source Transformation in BPEL

There will be many instances in your project where you will be having requirements to transform data from multiple sources into a single destination. An example scenario will be the need to do selective data enrichment (from a different source) to a collection of existing records. Currently multiple source transformations are not supported out of the box in 10g. Only single source can be mapped to single destination. As always there is a workaround for every problem. I will list down the steps for the workaround .In one of my previous blog that I had written on Payload splitting using XSL uses similar steps.

There is a pre-requisite for this, a schema. In case you are using AIA below is the location

<xsd:import namespace="" schemaLocation="http://<hostname>:<port>/AIAComponents/UtilityArtifacts/bpel-common.xsd" />

Or else you have create your own custom XSD

Code Snippet :: Custom schema - Param.xsd

<xsd:schema xmlns:xsd=""





<xsd:element name="parameters">



<xsd:element name="item" minOccurs="1" maxOccurs="unbounded">



<xsd:element name="name" type="xsd:string"/>

<xsd:element name="value" type="xsd:string"/>








1. Initialization

Create a Variable Params which should be of type parameters(Refer Param.xsd)

2. Assign XML fragment mentioned below to the parameters

Code Snippet :: XML fragment in Assign

<assign name="AssignXMLFragment">



<common:parameters xmlns:common="">







<to variable="Params" query="/common:parameters"/>



3. Read the data from second source using a ora:getContentAsString() function into the InputDataFromSource2 parameter

Code Snippet :: Assign in .bpel file

<assign name="AssignDataFromSource2To Params">


<from expression="ora:getContentAsString(bpws:getVariableData('InputSource2Msg','InputParameters','/ns12: InputParameters'))"/>

<to variable="Params" query="/common:parameters/common:item[common:name=' InputDataFromSource2']/common:value"/>



4. Now we will use transformations leveraging the feature of Passing Parameters into XSLT. We will pass the data in Params variable as the 3rd parameter so that it can be accessed in the XSL

Code Snippet :: Assign in .bpel file

<assign name="MultipleSourceTransformation">


<from expression="ora:processXSLT('Xform_From_Two_Sources.xsl',bpws:getVariableData('inputVariable','TestInABM','/ns8:'TestABM'),bpws:getVariableData('Params'))"/>

<to variable="outputVariable" part="TestOutABM”/>



5. Inside the XSL we will be accessing the Param data using xsl:param tag . The entire data will be available in the InputDataFromSource2 parameter. We will use orcl:parseEscapedXML function to convert the string data into proper XML format.

Code Snippet :: .xsl file




<xsl:param name="InputDataFromSource2">

<xsl:text disable-output-escaping="yes"><test:InputSource2Msg



<xsl:variable name="Source2Data"


6. After step 5 the data in XML format will be available in Source2Data variable which can be used as any other variable definition and all child elements can be accessed using this variable.

Code Snippet :: .xsl file



<xsl:value-of select=”$Source2Data /test:inputData/test:First_Name"/>

</geo: FirstName >

That’s it.. Compile and deploy. You will be able to access the data from different sources in same XSL.

Friday, April 9, 2010

AIA FP and PIP installation issues with Oracle Service Registry

AIA FP and PIP installations are always tricky and can throw up different issues in different environments. For one of the clients we had successfully completed the AIA PIP installation but there were couple of build scripts which had failed due to certain environment issues.

All the BPEL/ESB processes that are part of AIA will be plugged in with a feature to enable CAVS testing. This helps in doing individual testing of the processes developed to form part of a PIP. So all the processes will have routing to the CAVS, which will be a generic WSDL. The EBS services that come with PIPs (ESB processes) will be shared among different business process flows. So depending on the PIP that you deploy the Routing rules gets added at a PIP specific installation.

For all these routing rules to be added it becomes mandatory to have all the endpoint up and running, and since CAVS URL is one among them, it also needs to be available at time of installation.

CAVS ESB is referring to the wsdls inside the AIAApplication.ear, but the AIA app urls were not accessible even though AIAApplication was up and running.

The context in the urls refered in CAVS ESB(

(eg: http://:/AIAValidationSystemServlet/asyncrequestrecipient?wsdl).

) was AIAValidationSystemServlet and the search for this context directed us to AIAApplication.ear .

As a workaround we redeployed the AIAApplication.ear and all the wsdls became accessible. But once the server gets restarted the AIA app urls become inaccessible.

AIAApplication was not starting up even though the application was deployed.

The workaround didn’t work for long. So finally we had to zero in on the issue to solve it.

This issue is with having registry.ear and AIAApplication.ear together .There seems to be a conflict in starting these applications together due to shared resources of different versions being used by both applications. So as a workaround we modified the order in which the applications are loaded at server startup.The entries were modified in server.xml and default-web-site.xml with AIAApplication entries above the registry entries.