After taking a break from the weblogic upgrade I am continuing the series. You can view the
Previous Post here.
BPEL Upgrade
The following section will describe the various process we used for upgrading BPEL.
Abstract WSDL Issue
When a source project in your application depends on Oracle Application Server 10g Release 3 (10.1.3) Oracle BPEL Process Manager, then as a pre-cursor to migration, the Oracle JDeveloper Migration Wizard creates local copies of their abstract WSDLs.
The abstract WSDLs, by definition, lack service and port endpoint information. During upgrade, when the Migration Wizard creates external composite references for the service dependencies, the references are created as abstract references with no binding information.
These abstract references are flagged with WARNING messages in the upgrade log. After upgrade, when you attempt 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. If you want to continue using a 10g Release 3 (10.1.3) dependency service, you can do so. Some of the dependency service endpoint URLs that are captured in the upgrade log can be used for this step. You can find more information here.
Partner Link Information Issue
When any partner link is opened it does not allow to save and a message is shown saying partner link is not correct.
All partner links need to be verified after migration. After removing the partner role, composite.xml needs to be corrected.
Some of the partner links have the same PartnerRole and MyRole. This is not valid for synchronous invocation. Only Partner role should be provided.
Also callback for the partner links are created for synchronous web services. These also need to be deleted.
Once this is corrected in the BPEL, the wire element from composite.xml is removed. The wire element needs to be added again in composite.xml
JMS Adapter Issue
After deployment the JMS adapter does not work.
The adapter configuration for JMS adapter has changed from 10g to 11g. The configuration of queues and their reference in adapter has changed.
The queue names provided in 10g were physical queue names with the resource providers.
But in 11g the remote queue needs to be configured in the application server and needs to be used in BPEL adapter
JMS adapters need to be reconfigured in BPEL by executing the wizard. All used JMS adapters need to be reconfigured. Similar steps are required for AQ adapter also.
You can find more information here.
DB adapter Issue
The DB adapter configurations were not properly migrated when we ran the migration utility. So what we did was to delete the db adapter and re-create it.
BPEL Process hanging while migrating
When we are migrating the BPEL projects using JDeveloper the screen hangs for a long time. This was because In some projects both WSDL location and WSDL runtime location was specified. JDeveloper due to some reason was unable to access the deployed application.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.
This was fixed by removing the wsdlRuntime location in bpel.xml . The composite was modified to add location manually for the partner links
Business Exception Fault Issue
While executing the BPEL process instance if any partner link is throws a business fault, the composite does not propagate the exception to the process rather it retries it from the location provided in the WSDL. This causes the business fault not to be propagated to the BPEL flow. Also this can be very risky since the URIs in WSDL can point to different environment.
This is the default behavior of Oracle SOA engine and this cant be altered. The only resolution is to remove the endpoint location attribute from our deployment guide and composite.xml. The location attribute is only provided in the wsdl files like http://serverName:serverPort/webService
In the deployment guide we replace serverName and serverPort with actual details for every environment.
Build and Deployment Changes
The deployment approach of generated ant scripts has changed for 11g.
In 10g SOA suite build.xml was generated in every project. 11g does not have any such file since the deployment approach of generated ant scripts has changed for 11g.
XSD Validtaion Problem
If XML validation is turned on, an error is received if a nillable attribute is specified as below in request as shown below.
<ns2:FreightCurrencyCode xsi:nil="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
But if the xml is similar to the one show below then no error is specified.
<ns2:FreightCurrencyCode xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
This is bug in 11g. Sine our BPEL webservices are used by our external clients we could not affort a change in XSD. So we used the transform activity of BPEL to accomplish this, so that the client does not face an issue if either of the xml is sent to us.
Configuring Fault Handling
Fault handling framework implementation changed in 11g and so we had to change our implementation as well.
In 11g the fault policy and fault binding can only be provided inside the SOA project or in the MDS. The decision of which binding will use which fault policy can only be provided in the binding file. In 10g the common files could be put in the domain folder (a location was provided for these files) and these could be directly referenced in the BPEL projects. Also the fault policy which should be invoked was provided in bpel.xml that means that fault-binding could be common.
This issue was solved by deploying the common files in MDS and the process which require specific fault handling it was provided in the SOA project.
The below code snippet needed to be added in the composite.xml.
<property name="oracle.composite.faultPolicyFile">oramds:/apps/FaultPolicy/fault-policies.xml</property> <property name="oracle.composite.faultBindingFile">oramds:/apps/FaultPolicy/afault-bindings.xml</property> 
No comments:
Post a Comment