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.
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.
Rearranging the files in the composite:
Move XSD and XSL files to their respective folders in the project(XSD'd and the XSL files will not moved to the respective folders during the migration).After moving the XSDs and XSLs to their respective folders, change the references in BPEL file, WSDL file, and XSL files.
Providing Missing Binding Information for partner links:
When a source project in your application depends on Oracle Application Server 10g Release 3 (10.1.3) Oracle BPEL Process Manager or Oracle Enterprise Service Bus (ESB) services, the Oracle JDeveloper Migration Wizard creates local copies of their abstract WSDLs.
The abstract WSDLs, by definition, lack service and port endpoint information so that the binding information will not be added in the composite.xml file.
When we are attempting to compile the projects, Oracle JDeveloper will generate compilation errors alerting you to the presence of abstract references in the composite.
To correct binding errors due to the abstract references, right-click on the reference node in the Oracle JDeveloper 11g composite editor and choose the correct concrete WSDL(The WSDL of the composite deployed in the server).
Pointing Common Schema's and WSDL's to MDS:
Every common schema and wsdl import must be modified to refer the MDS .We should use ORAMDS references instead of HTTP references.
In 10g:
In 11g:
Pointing XREF's and DVM's to MDS:
Every DVM and XREF lookup must be modified to point to MDS location.
10g:
orcl:lookup-dvm("SAPAMPaymentTerms","SIEBEL",/local:payTerms,"SAP",local:payTerms)
xref:populateXRefRow("OM_ASSET_INT_ID_ITEM_NO","ASSET_INT_ID",xsdLocal:assetIntegrationId,"ITEM_NO",,xsdLocal:itemNumber,"ADD")
xref:lookupXRef("OM_ASSET_INT_ID_ITEM_NO","ASSET_INT_ID",xsdLocal:assetIntegrationId"ITEM_NO",true())
11g:
dvm:lookupValue("oramds:/apps/EAIMetaData/dvm/SAPAMPaymentTerms.dvm","SIEBEL",local:payTerms,"SAP",local:payTerms)
xref:populateXRefRow("oramds:/apps/EAIMetaData/Xref/OM_ASSET_INT_ID_ITEM_NO.xref","ASSET_INT_ID",xsdLocal:assetIntegrationId,"ITEM_NO", xsdLocal:itemNumber,"ADD")
xref:lookupXRef("oramds:/apps/EAIMetaData/Xref/OM_ASSET_INT_ID_ITEM_NO.xref","ASSET_INT_ID",xsdLocal:assetIntegrationId,"ITEM_NO",true())
ora:getProcessID():
During the migration of the code, the BPEL process name got changed for some of the processes in 11g.
The process name CSOM_TransformOrderStatus in 10g got changed to CSOM_TransformOrderStatusProcess(Process got appended with the BPEL name) in 11g and also the name of the .bpel file got changed in the same way.
If we are using the ora:getProcessID() function to get the process id and testing against a value like ora:getProcessID() = 'CSOM_TransformOrderStatus' then the test will fail after the migration.
10g:
11g:
The value need to be changed accordingly to match the process name.
ora:getInstanceId():
In 10g, if we are using the ora: getInstanceId () method to get the BPEL instanced id and tracking the instance based on this id in the BPEL console, the same won’t work in 11g after migration.In 11g,ora:getInstanceId() will return the BPEL Component instanced id not the composite instance id and if you are searching in the EM console with this id the instance will not be found.
There is no option in EM console to search the instance based on the BPEL Component instance id but can be searched based on composite instance id.
In this case, we have to use the ora: getCompositeInstanceId () method instead of using ora: getInstanceId ().
Issue in using the current node operator (.) in conjunction with union operator (|) in XLST:
We were using the below code snippet in 10g to identify the distinct subscriber‘s available in the request payload.
<xsl:key name="subscribers" match="/xsdLocal:CSOrderRequest/xsdLocal:orderLineItem" use="xsdLocal:subscriber"/>
<xsl:for-each select="/xsdLocal:CSOrderRequest//xsdLocal:orderLineItem[count(. | key('subscribers',xsdLocal:subscriber)[1])=1]">
<xsdLocal:orderLineItem>
<xsdLocal:CRMOLIId>
<xsl:value-of select="xsdLocal: orderLineId"/>
</xsl:for-each>
<xsl:for-each select="/xsdLocal:CSOrderRequest//xsdLocal:orderLineItem[count(. | key('subscribers',xsdLocal:subscriber)[1])=1]">
<xsdLocal:orderLineItem>
<xsdLocal:CRMOLIId>
<xsl:value-of select="xsdLocal: orderLineId"/>
</xsl:for-each>
It was working fine in 10g but after migrating the code to 11g we were receiving the exception.
After a little struggle, we have identified that the current node operator (.) is not working with union operator (|).
Below are the different options that could be used to overcome this issue.
1. Current node operator can be replaced with self::node () as shown below.
<xsl:for-each select="/xsdLocal:CSOrderRequest//xsdLocal:orderLineItem[ count(self::node() | key('subscribers',xsdLocal:subscriber)[1])=1]">
2. Use the generate-id function to get the distinct nodes.
<xsl:for-each select="/xsdLocal:CSOrderRequest//xsdLocal:orderLineItem[generate-id(.)=generate-id(key('subscribers',xsdLocal:subscriber)[1])]">
Schema validation issue for xsd:date type fields(if we have enabled the schema validation at run time):
After the migration the schema validation will fail for the fields with the type xsd:date,if the data send to that field is of type dataTime instead of date.
In 10g the xsd:date field can accept both date and dateTime values without any issue.
But in 11g the xsd:date field can only accept the date types not the dateTime.
To accept the dateTime value the type of the element should be changed to xsd:dateTime.
Partner link timeout:
In 11g SOA, we don't have the "Timeout" property that we can set in partnerlinks to set a maximum wait time for the webservice invocation. The “Timeout” property will not be migrated to 11g during the code migration.
If we are using this property in 10g the same has to be changed in 11g as mentioned below.
Webservice invocation Timeout in 11g:
The property oracle.webservices.httpReadTimeout
(in Milliseconds) can be used to set the webservice invocation timeout in 11g.
If the Web Service is on the same weblogic domain as the SOA Composite, you will also have to set:
oracle.webservices.local.optimization = false (This property is not required if the call is remote)
Variable type mismatch:
In 10g, we had an xpath expression as shown below to fetch the element from the array of element based on the index value and it was working properly.
After migration the same flow was throwing the below error because multiple nodes were return by the same expression in 11g.
Exception :- "The result contains 2 nodes for the XPath expre
ssion: "/client:process/client:input[$index]/client:result1".
After analysis, we have identified that unfortunately in 10g the index variable type was defined as String and it was working fine in 10g but 11g expects the variable type as integer.
If the index variable type is invalid like String then all the nodes are returned as a result. Even in all the cases, 11g is stricter than 10g in case of variable types. In 10g we can use the integer type in place of String type but not in 11g.
Issue with Migrated Composite that invokes a secured web services:-
We have faced the issue after migrating the code to 11g to invoke the secured web service from the composite but it was working properly in 10g.
We have done a tcpmon setup to monitor the request that send to the external web service and found that the security credentials are not set in the http header.
After a little struggle, we have identified that the corresponding client policy should be attached to invoke the service.
The issue got resolved after attaching the policy oracle/wss_http_token_client_policy to the partner link.
The polices can be attached from JDeveloper or em console
Change the java package import for custom XPATH:
In10g,the custom xpath function java classes use com.oracle.bpel.xml.xpath java package for the implementation but in 11g the same be changed to oracle.fabric.common.xml.xpath.Replacing the orabpel and oraesb schema reference in the codebase to SOAINFRA:
If we had used orabpel and oraesb schema name as the qualifier in the 10g code base the same has to be changed to SOAINFRA.The orabpel and oraesb schemas are replaced with SOAINFRA in 11g.
Nice one dude :)
ReplyDelete