Additional Tasks and Considerations When Upgrading the XREF Runtime Data

10-2 Oracle Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter, and ADF Manager or Oracle Enterprise Service Bus ESB services, 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. Using 10g Release 3 10.1.3 or 11g Dependency Services Based on the upgrade and deployment schedules of all the services in the dependency tree, you can choose to continue to use 10g Release 3 10.1.3 dependency services or proceed with the upgrade and redeployment of the dependency service. In general, Oracle recommends that users study their source project and their dependencies before any upgrade work. This analysis will result in a smoother upgrade experience. How to Correct Binding Errors Discovered During the Recompile 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 also redesign the dependency in Oracle JDeveloper 11g, using the WSIL Browser Resource Palette, and discover the service from the UI in the composite modeler. For more information, refer to the Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

10.1.2 Correcting Problems With Oracle BPEL Process Manager Test Suites

During upgrade in Oracle JDeveloper, BPEL test suites are converted to composite test suites. However, only the instance initiate action is migrated. This results in a composite test which initiates only a test run. The rest of any BPEL-based test actions are not automatically migrated and must be manually set up after the upgrade. To set up the tests in your 11g environment, refer to Testing SOA Composite Applications in the Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

10.1.3 Using Oracle BPEL Process Manager Deployment Plans After Upgrade

Deployment and configuration plans that you set up in Oracle Application Server 10g for your Oracle BPEL Process Manager user projects are not upgraded in Oracle JDeveloper 11g. In Oracle Fusion Middleware11g, a composite can be accompanied by deployment and configuration plan during deployment. However, you must create the 11g deployment plan manually, after you have migrated the application in Oracle JDeveloper. Upgrading Oracle BPEL Process Manager Applications 10-3 For more information about creating configuration plans in 11g, see Moving SOA Composite Applications to and from Development, Test, and Production Environments in the Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

10.1.4 Upgrading Fault Policies in an Oracle BPEL Process Manager Project

When you open your 10g application in Oracle JDeveloper and use the Oracle JDeveloper Migration Wizard to upgrade the application, any fault policies and bindings that you set up in a user project are not automatically upgraded to 11g. The reasons are as follows: ■ In Oracle BPEL Process Manager 10g, fault policies were stored with the server and bindings were either stored with the server or specified in bpel.xml. In Oracle BPEL Process Manager 11g, fault policies and fault bindings are stored in the Oracle JDeveloper 11g project. ■ In general, fault policies and bindings in Oracle BPEL Process Manager 11g are different than those in previous releases. For example, the file name and syntax is different, fault policies apply both to Oracle Mediator and Oracle BPEL Process Manager, and bindings are at a reference, component, and composite level in 11g. For these reasons, you must manually recreate the fault policies and bindings in the Oracle JDeveloper 11g project after you upgrade your applications. Similarly, when you upgrade an Oracle Enterprise Service Bus 10g Release 3 10.1.3 project to 11g, you must add the retry parameters defined in esb_config.ini file to the 11g fault-policy.xml file. For more information, see: ■ Using Fault Handling in a BPEL Process in the Oracle Fusion Middleware Developers Guide for Oracle SOA Suite ■ Using Mediator Error Handling in the Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

10.1.5 Upgrading a 10g Project With No BPEL Folder

If the 10g Release 3 10.1.3 application you are upgrading includes a project where all the project artifacts are in one folder and the BPEL artifacts are not separated into their own folder in the project, then the Oracle JDeveloper Migration Wizard will not be able to upgrade those artifacts. To avoid this problem, do one of the following: ■ Before upgrading the project, use Oracle JDeveloper 10g to create a BPEL folder and move all the artifacts except the build.xml and build.properties files into that folder. Then you can proceed with upgrading the project. ■ Use the Oracle SOA Suite command-line upgrade tool. The command-line tool will upgrade the artifacts even if a BPEL folder does not exist in the project. For more information, see Section 9.3.7, Using the Oracle SOA Suite Command-Line Upgrade Tool .

10.1.6 Post-Upgrade Steps for Projects That Use WSIF Bindings to EJBs

When you have Oracle SOA Suite 10g projects that use WSIF bindings to communicate with Enterprise Java Beans EJBs, then you must make some modifications to those projects after they are upgraded to 11g. 10-4 Oracle Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter, and ADF For example, after you upgrade a project that uses WSIF bindings and EJBs, it will fail to run on due to WSIF binding errors. To work around the these problems, you typically must perform the following steps after you have upgraded the project to Oracle JDeveloper 11g: 1. Replace the properties of the binding.wsif entry in the composite.xml file with the correct JNDI related properties for Oracle WebLogic Server. For example, the following are typical properties set for a Oracle WebLogic Server domain for an application called the BankTransferDemo application, which was deployed previously on Oracle Application Server 10g Release 3 10.1.3: binding.wsif port=....... location=...... . property name=jndiName ejbsessionBankTransfer property . property name=java.naming.factory.initial weblogic.jndi.WLInitialContextFactory property . property name=java.naming.provider.url t3:[SERVER HOST NAME]:[SERVER PORT] property . property name=java.naming.security.principal [DOMAIN ADMIN USER NAME] property . property name=java.naming.security.credentials [DOMAIN ADMIN PASSWORD] property . binding.wsif 2. Copy the EJB classes to the following directory in your newly upgraded 11g project: SOA_JDEV_PROJECT_HOME SCA-INFclasses For more information about using Oracle JDeveloper to modify your Oracle SOA Suite applications, see the Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

10.2 Additional Considerations for Oracle BPEL Process Manager Applications

The following sections describe additional considerations you should review after upgrading Oracle BPEL Process Manager applications: ■ Section 10.2.1, Verifying New and Deprecated Properties in the bpel.xml Deployment Descriptor ■ Section 10.2.2, Upgrading User-Defined Custom XPath Functions in an Oracle BPEL Process Manager Project ■ Section 10.2.3, Change in Support for Multiple BPEL Implementations