Oracle SOA Suite 10g to 11g Migration - Unable to access the following endpoint : REPLACE_WITH_ACTUAL_URL

Unable to access the following endpoint : REPLACE_WITH_ACTUAL_URL:

The invocation of the synchronous web service from the composite has failed with the following error after migrating the code to Oracle SOA Suite 11g.

"Unable to access the following endpoint : REPLACE_WITH_ACTUAL_URL"

After a long struggle ,we have identified the issue .The issue was with the callback interface was wrongly configured with the value same us interface during the migration in the composite.xml and the component files of the composite that invokes the web service(synchronous) that doesn't support any callback .

Composite.xml with callback configured as same as interface:

Component file with callback configured as same as interface:

Oracle SOA Suite 10g to 11g Migration - Unable to register a service endpoint for a defined reference callback

Unable to register a service endpoint for a defined reference callback:

The invocation of the asynchronous web service from the composite has failed with the following error after migrating the code to Oracle SOA Suite 11g.

"Unable to register a service endpoint for a defined reference callback. Please ensure the WSDL and reference configuration are correct".

After a long struggle ,we have identified the issue .The issue was with the callback interface was wrongly configured with the value same us interface(no separate callback port is defined in the WSDL) during the migration in the composite.xml and the component files of the composite that invokes the asynchronous web service that doesn't have any callback defined.

Composite.xml with callback configured:



Component file with callback configured:

Oracle SOA Suite 10g to Oracle SOA Suite 11g Migration – FlowN execution issue

Oracle SOA Suite 10g to Oracle SOA Suite 11g Migration – FlowN execution issue:

We had a flow in 10g that invokes another composite inside the FlowN activity with different data based on the index variable and it was working properly but after the migration the composite has always invoked with the payload of the first flow branch.

We did some analysis and found that 10g FlowN activity and 11g FlowN activities are working in different manner.

In 10g ,the activities in the same flow branch is executed in sequence that after completing the first branch the second branch getting executed

But in 11g, the execution of the activities are swapped between branches that the first activity in the first branch is executed then the first activity in second branch then second activity in first branch and second activity in second activity and so on.

In 10g even though we are using the global variables inside the flowN activity each flowN branch is working with different message/payload based on the Index Variable.

In 11g if we are using the global variables inside the flowN activity all the flowN branches are executed with the same message/payload of the first flow branch.

To overcome this issue we have copied the global variable data to local FlowN scope variable and used the local variable inside the FlowN.

Below is the detailed execution of activities within FlowN in 10g:-

FlowN with two branches and both the branches are working on the same global variable ‘Varaible_1’

The value of ‘Varaible_1’ has incremented to 1 in Assign_2 and to 2 in Assign_3 (Assign_2 and Assign_3 data’s are displayed together) of Flow2

The value of ‘Varaible_1’ has incremented to 3 in Assign_2 and to 4 in Assign_3 (Assign_2 and Assign_3 data’s are displayed together) of Flow1

Oracle SOA Suite 10g to 11g Migration - Web service Invocation issue,Invalid URI "urn:#NewOperation"

Oracle SOA Suite 10g to 11g Migration  - Web service Invocation issue,Invalid URI "urn:#NewOperation":

The web service invocation has failed after migrating the web services to 11g with the following error

Caused By: oracle.j2ee.ws.common.addressing.api.AddressingException: Invalid URI "urn:#NewOperation" in Addressing element Action.

But the same web service was working properly in 10g.

To overcome this we have changed the soapaction "urn:#NewOperation" to empty string in web service WSDL manually and it resolved the issue.

10g:-

11g:-

Oracle SOA Suite 10g to 11g Migration - Instance Title for Composites and Components

Oracle SOA Suite 10g to 11g Migration -  Instance Title for Composites and Components:

Composite instance title:-

ora:setCompositeInstanceTitle() method can be used to set the composite instance title.

The composite instance title can be used to search the composite instances from em console but the wildcard search is not applicable on this field.

– There is no method provided to get the composite instance tile

We are only having the option to set the composite instance title using setCompositeInstanceTitle() method but no option to get the title.

BPEL Component instance Title:-

As like 10g we can use the setTitle() method to set the BPEL component title and getTitle() method to get the instance title.

BPEL Component instance Title can’t be used in em console to search the instances.

Oracle SOA Suite 10g to 11g Migration - Part3 - Things to consider post migration of the code.

Oracle SOA Suite 10g to 11g Migration - Part3  - Things to consider post migration of the code:

We have to consider the below points post migration of the code.

ValidateXML property:

During the migration,the property validateXML did not migrated by default to SOA 11g.The property needs to be added manually to the required partner links .

The below steps need to be followed to add the validateXML property(Enable the schema validation).

1.Open the .bpel file corresponding to the Composites that require the schema validation.

2. Double click the partnerlink that requires the schema validation for the request payload and select the property tab .

3.Add the validateXML property with the value true.

The added property will be available in the Composite.xml file as shown below.

DVM Issues:

1. Duplicate Rows:

In 10g, if the value in the source column is duplicated then the lookup function will return the last row for that key but in 11g the lookup will fail with the exception.

If we are looking for the value corresponding to the column “SiebelValue” by passing the “EAIVAlue” as “New”, in 10g the lookup function will return the result as “Awaiting Approval” but in 11g exception will be thrown for duplicate values.
To resolve this issue remove the duplicate rows from the DVM.

2. Invalid Column:

In 10g, if we are looking for a DVM column value that is not available in the DVM the lookup function will return the default value specified in the lookup function but in 11g the exception will be thrown for invalid column.

If the column “CANONICAL” is not available in DVM, in 10g the lookup function will return the default value (empty string) specified in the function but in 11g the exception will be thrown from the lookup function.

To resolve this issue make sure the columns specified in the lookup functions are valid.

Oracle SOA Suite 10g to 11g Migration - Part2 - Resolving the deployment issues with the migrated composites.

Oracle SOA Suite 10g to 11g Migration - Part2 - Resolving the deployment issues with the migrated composites:

The below are the some of the issues we have faced during the deployment of the migrated code with the solution what we have provided to resolve the issue.

Base64 encoding/decoding class issue

BPEL compilation might fail if we have used com.collaxa.common.util.Base64Decoder/Base64Encoder classes in 10g.The import of com.collaxa.common.util.Base64Decoder/Base64Encoder class should be changed to oracle.soa.common.util.Base64Decoder/Base64Encoder

Recursive Import issue

The deployment of the migrated composite might fail if the composite invokes the partner WSDL that is having the duplicate import of same WSDL with the following error “WSDL contains recursive import loop”.

To overcome this one of the import should be commented or removed.

RuntimeFault.wsdl and ws-addressing.xsd cannot found

The http://xxxxx:xxxx/orabpel/xmllib/RuntimeFault.wsdl and
http://xxxxx:xxxx/orabpel/xmllib/ws-addressing.xsd could not be found after migration.
In 11g these files are moved to MDS .change the location manually to the following MDS location in the code oramds:/soa/shared/bpel/RuntimeFault.wsdl and oramds:/soa/shared/common/ ws-addressing.xsd

Oracle SOA Suite 10g to 11g Migration - Part1 - Things to consider before starting the migration of the code.

Oracle SOA Suite 10g to 11g Migration - Part1 - Things to consider before starting the migration of the code:

We have to consider the below points before starting the migration of the code.

Move all the Common artifacts (XSD, WSDL, DVM and XREF) to MDS:

Before starting the code migrations move all the common artifacts to MDS with the folder structure that requires for the project.

Partner link Location in bpel.xml:

If the Runtime WSDL’s are used for partner link invocation in 10g,make sure all the partner link URL’s(host name and port) in bpel.xml are reachable else change with reachable endpoints by using ant script or manually.

Common XSD and WSDL References:

Make sure the common XSD’s and WSDL files referred in the 10g projects are reachable else change the location of the URL (host name and port) with reachable by using ant script or manually.

The below sample Ant script can be used to change the host name and port in XSD, WSDL and XML files.

<?xml version="1.0" encoding="iso-8859-1"?>
<project name="HostnameReplace">
<replace dir="${basedir}" token="eaidev1:7777" value="${hostname}:${http.port}">
<include name="**/*.xsd"/>
<include name="**/*.wsdl"/>
<include name="**/*.xml"/>
</replace>

<replace dir="${basedir}" token="10.15.35.22:8888" value="${hostname}:${http.port}">
<include name="**/*.xsd"/>
<include name="**/*.wsdl"/>
<include name="**/*.xml"/>
</replace>
</project>

BPEL preferences:

SOA 11g does not accept spaces in preference name and the migration might fail with the following error “preference.BPEL Process Name' does not match pattern for xs:NCName”,if 10g has the preference name with empty spaces in between , so that they should be trimmed for empty spaces in bpel.xml and *.bpel.

Space in Schema Name:

The migration might fail if the 10g schema has a space in the name, the space should be trimmed in the name and also the places wherever the schema name has reference.