16 Moving Components for Oracle Fusion Applications Across Environments

This chapter provides an overview of moving Oracle Fusion Applications components from one environment to another. It contains the following topic:

• Introduction to Moving Oracle Fusion Applications

The procedures for performing this movement are not available at this time.

16.1 Introduction to Moving Oracle Fusion Applications

Replicating an Oracle Fusion Applications environment requires moving Oracle Fusion Applications components from one environment to another. The task of moving Oracle Fusion Applications components from one environment to another is simplified by movement tools (scripts for moving binary and configuration information). These tools minimize the amount of work that would otherwise be required to reapply all the customization and configuration changes made in one environment to another.

Typically, Oracle Fusion Applications is installed, configured, customized, and validated in a test environment. Once the system is stable and performs as desired, the production environment would then be created by moving all the components from the test environment, instead of redoing all the changes that were incorporated into the test environment.

The movement of Oracle Fusion Applications components from one environment to another can be achieved in several different movement scenarios, but this chapter focuses on the full-movement scenario.

In a full-movement scenario, the target environment does not exist. First, the source environment is created, configured, customized, and tested. Then, the target environment is created by moving all the components along with their configurations from the source environment.

When moving Oracle Fusion Applications components from one environment to another, you must adhere to the following guidelines:

• The source and target environments must share the same operating system and the same platform architecture (in terms of number of bits). For example, you cannot move components and their configurations from a source environment that is running Microsoft Windows to a target environment that is running UNIX. Similarly, you cannot move components and their configurations from a source environment with a 32-bit platform to a target environment with a 64-bit platform.

• The source and target environments must have identical topologies. (Any changes to the target environment topology can be done post movement).

• The Oracle Fusion Applications domain name must not be changed in the provisioned environment or while performing the full-movement tasks.

• The path relative to APPLICATIONS_CONFIG that is used while moving the domain and system component should be the same as the path used in the provisioned source environment.

• The Common domain should be moved to the target environment first because Metadata Services (MDS) operations for Oracle Fusion Applications partitioning is handled in the Common domain.

With the completion of the full-movement tasks, the following artifacts are moved from the source environment to the target environment:

• Seed data (created with Oracle Fusion Middleware Repository Creation Utility (RCU) in the target environment)

• Oracle WebLogic Server domain configuration, stored in the file system

• System component configuration, stored in the file system

• Configuration and metadata stored in MDS, such as Oracle Application Development Framework (Oracle ADF) connections, service-oriented architecture (SOA) composites, and so on

• Configuration and metadata stored in component-specific schemas outside of MDS

• Non-user layer customizations, such as Site and Enterprise Layer, in MDS

• Security artifacts created by the Oracle Fusion Applications Provisioning framework, such as application IDs, policies, and so on

• Functional setup data

Following are some of the artifacts that are not moved to the target environment:

• Transactional data, which is assumed to be test transactions

• Transient data, such as job status, process status, and so on

• Content data, such as Oracle Universal Content Management data, wiki pages, discussion forums, and so on (which can be moved using data movement tools if necessary)

  Note:

  In the case of Oracle HTTP Server (OHS), the contents of document root are moved as part of OHS movement, as they are part of application data.

• Any configuration or metadata associated with users, such as:

  • Users in the identity store

  • User layer customizations in MDS

  • Component configurations associated with specific users, such as Oracle Human Workflow work groups associated with users

  Users are assumed to be test users, and they may not be present in the target environment.

• MDS sandboxes