Oracle soa 10g to 11g migration
1 like2,237 views
This document provides an overview of migrating from Oracle SOA 10g to 11g. Key steps include installing the 11g server components, configuring prerequisites, and determining the migration method. There are two primary options - using the JDeveloper migration wizard to migrate projects one by one, or using command line utilities to migrate multiple projects at once. A post-migration checklist outlines steps to verify processes, adapters, metadata, and fault handling configuration.
Ad
More Related Content
What's hot (20)
Similar to Oracle soa 10g to 11g migration (20)
Ad
Recently uploaded (20)
Ad
Oracle soa 10g to 11g migration
- 1. Overview: • A number of enhancements, improvements and additions are included in Oracle SOA 11g as compared to 10g • 10g does not have a Service Bus and SCA compatible components, while 11g includes a Service Bus and SCA components • Inclusion of Service Bus in 11g completes the SOA architecture and promotes reuse, virtualization, decoupling and faster time to market • Application Server: 10g uses OC4J, while 11g uses WebLogic which uses JRockit as the JVM • Using WebLogic/JRockit can give a performance improvement of ~20% over 10g server • In 11g, components like BPEL, OWSM and ESB can be included in a single composite, allowing for logical grouping of the components • Central Metadata Store (MDS) and Local MDS can be used to store common artifacts in 11g • Oracle 10g is nearing end of life / end of support from Oracle These reasons make it imperative to migrate from 10g to 11g This document discusses the migration options, guidelines to follow, challenges and points to take care of when migrating. Pre-Migration Steps 1. Ensure all code is upgraded/migrated to Oracle 10g Release 3 (10.1.3) version. Only code in version 10.1.3 can be migrated to Oracle 11g 2. • Install Oracle SOA Suite 11g Server components: • Install Oracle Database • Install WebLogic Server • Create database schemas using the Repository Creation Utility (RCU) • Install Oracle SOA Suite
- 2. • Create SOA Domains • Developer components: • Oracle JDeveloper 11g • SOA Extensions 11g for JDeveloper 3. Configuration pre-requisites • Configure resources needed on Oracle SOA 11g server, such as JMS Queues/Topics, DB Connection pools, Security Policies, Work Managers etc • Ensure all projects, and dependent projects, are running of Oracle SOA 10g server • If the project has dependencies on external web services, need to ensure these web services are also up and running 4. Determine the method of migration to use Migration Options 1. Migrate using Oracle JDeveloper 11g – Use the migration wizard in JDeveloper to migrate from 10g to 11g • Manual process – can migrate only one project at a time • Open the Oracle SOA 10g project to be migrated in Oracle JDeveloper 11g • JDeveloper Migration wizard comes up • Select options to ‘Migrate Component IDs’ and ‘Randomize IDs’ • Confirm and finish the migration wizard • JDeveloper will migrate the project to be compatible with Oracle SOA 11g server • Once a project is migrated, it cannot be opened with Oracle SOA 10g developer tools or deployed to 10g server 2. Migrate using Command Line Utility – Use the ant-based migration command line utility that is available with Oracle SOA 11g • Ant-based upgrade utility – can migrate multiple SOA 10g projects to 11g • Scripts are included with Oracle SOA 11g suite • Provide source/target directory and application name to the script • After migration script, run the SCA compiler script to verify the migrated project(s) • Run the ant package and deploy scripts to package and deploy the project
- 3. Limitations of Command Line Utility • The JDeveloper files such as *.jpr (project file) and *.jws (application file) cannot be migrated by the command line utility • The project needs to be opened in Oracle JDeveloper 11g, saved and closed to migrate these files • To migrate any adapter configurations, need to use the configuration wizards of the adapters – thus, any project with adapter needs to be opened in Oracle JDeveloper and migrated • Separate ADF projects will be created for each Human Workflow task forms • The command line utility doesn’t support the deployment of ADF projects. Comparing the Migration Options MIGRATION USING JDEVELOPER MIGRATION USING COMMAND LINE UTILITY Can merge various BPEL projects into a single composite in order to achieve the logical grouping of the components based on Cannot merge multiple BPEL projects into a single composite business case. Can automate part of the migration process using scripts or other Cannot automate the migration process command-line automation tools. Cannot migrate multiple projects at a time Can migrate multiple projects at a time Cannot deploy the ADF projects from Command line utility after Can deploy the ADF projects from JDeveloper after migration migration The JDeveloper artifacts like .jws and .jpr files are migrated The JDeveloper artifacts are not migrated; these need to be along with the SOA artifacts. migrated manually Post Migration Checklist Generic 1. When Command Line Utility is used, open the upgraded project in Oracle JDeveloper 11g to migrate the *.jpr and *.jws files 2. When Command Line Utility is used, open project in Oracle JDeveloper 11g and run the adapter migration utility
- 4. 3. Migrate the processes in the order of dependency. if ‘A’ invokes ‘B’, ‘B’ has be migrated first 4. Change the WSDL end point URL to point to new upgraded sub process URL. 5. Move the artifacts into their respective folders. Change the location in referencing artifacts accordingly 6. Group related upgraded Projects in a Single Composite Application (wherever applicable) 7. Create configuration plan for SOA 11g composites (10g deployment plans will not be upgraded) 8. Create Partitions to group 11g composites (similar to domain in 10g) Adapter 1. Recreate adapters 2. Update 10g JCA adapter header variable to 11g invoke adapter property 3. File adapter- Chunk read logic has to be changed 4. Add validateXML property to partner link that requires request message validation and set the value to ‘true’ Function/Preference property 1. getDomainId() – BPEL domain concept is no longer applicable in 11g. Remove/modify the function in 11g code 2. Modify the XPath function namespace. (check the <JDEVELOPER_HOME>/integration/seed/soa/configuration folder for prefixes) 10g: ora:parsexml() 11g: oraext:parsexml 3. setCompositeInstanceTitle/getCompositeInstanceId Function(to customise the instance id) has to be changed if it is used in 10g 4. Modify any custom property in composite.xml10g: <property name=”retryInterval”>60</property> (Check 10g bpel.xml) 11g: <property name=”jca.retry.interval”>60</property> 5. Modify BPEL preference property names if it contains space. 6. Modify ora:getProcessID condition. Process name gets renamed (sometimes) after migration10g: ABC 11g: ABCProcess Thus, ora:getProcessID() = ‘ABC’ condition which is valid in 10g code, will fail in 11g. 7. Check for data type of variables. In 10g, we can use the string type in place of integer type (like in index variable) but not in 11g.
- 5. 8. Modify xsd:date to xs:dateTime if input contains time as well (10g accepts both date and time for xs:date function) MDS 1. Move the common artifacts (XSD/WSDL/ DVM files) to MDS. Accordingly change local reference to oramds reference(oramds://location_of_resource) 2. For BPEL xmllib reference files, change the http URL to MDS URL DVM 1. DVM – remove duplicate rows. 10g fetches the last updated value for duplicate key. but 11g throws error. 2. Modify DVM lookup function and location of file.10g: orcl:lookup-dvm(“Currency “, ” Country “, ” US “, ” Currency “, ” USD “) 11g: dvm:lookupValue (” oramds:/apps/CustomMetaData/dvm/Currency.dvm “, ” Country “, ” US “, ” Currency “, ” USD “) Fault Handling 1. Create fault binding/policy files if not implemented in 10g 2. Edit composite.xml file to add composite preference property “oracle.composite.faultPolicyFile” and “oracle.composite.faultBindingFile” (should be manually added, since there is no concept of global fault policy in 11g) 3. Fault binding Migration: 1. Change the version in fault-bindings.xml from “2.0.1” to “3.0” 2. Change the <process> element to <composite> 4. Fault policy Migration: 1. Rename the 10g fault policy file to fault-policies.xml 2. Change the version from “2.0.1” to “3.0” 3. Add a higher level <faultPolicies> node above <faultPolicy> element. ANT Script for migrating BPEL project(s) ant -f %ORACLE_HOME%binant-sca-upgrade.xml bpel -Dsource “C:projects10gEmployeeEmpSalary;C:projects10gEmployeeEmpInfo” -Dtarget C:projects11g -DappName Employee ANT Script for migrating DVM
- 6. 1. In 10g, Export DVM metadata to archive <Oracle_Home>/export.sh metadata10g.zip 2. Convert zip to Oracle SOA Suite archive file ant -f %ORACLE_HOME%binant-sca-upgrade.xml upgrade-xrefdvm -Dsource=zip_file_location -Dtarget=new_soaArchive_location 3. Output will be saved as sca_XrefDvmFiles10g_rev1.0.jar 4. Create a new application in Jdev11g and import the SOA Archive into SOA project 5. Create jar file with DVM metadata and deploy to MDS Summary SOA 10g to 11g migration requires lot more to do than simply executing migration script/wizard. You can use these best practices as a reference.
- 7. 1. In 10g, Export DVM metadata to archive <Oracle_Home>/export.sh metadata10g.zip 2. Convert zip to Oracle SOA Suite archive file ant -f %ORACLE_HOME%binant-sca-upgrade.xml upgrade-xrefdvm -Dsource=zip_file_location -Dtarget=new_soaArchive_location 3. Output will be saved as sca_XrefDvmFiles10g_rev1.0.jar 4. Create a new application in Jdev11g and import the SOA Archive into SOA project 5. Create jar file with DVM metadata and deploy to MDS Summary SOA 10g to 11g migration requires lot more to do than simply executing migration script/wizard. You can use these best practices as a reference.