2 Perform Production-to-Test Data Movement

"Production-to-test" is the movement of application data from a source to a target Fusion Applications installation. Although a common use case is the refreshing of a test database with production data, the same tools could be used to move data between any two environments (production, staging, testing, etc.). Throughout this document, "production" is assumed to be source, and "test" is assumed to be the target.

There are two phases in moving data in a Fusion Applications installation: 1) moving the Identity Management Identity and Policy Store data, and 2) moving data from the Fusion Applications transaction database(s). At a high level, the following are moved:

• Identity Management Policy Store data (application and system policies, but not credentials and keys)

• Identity Management Identity Store data (not including AppID and user passwords)

• Fusion Applications transaction data and the crawl index stored in SES

• File attachments stored in UCM (such as orders, agreements)

• ADF Customizations (such as Flex Fields), SOA and ESS customizations stored in MDS

• Business Intelligence (BI) Web Catalog and RPD

• ODI repository

• WebCenter contents

Production-to-test movement replaces most of the target database with production data; a small category of data on the test/target system is preserved, as required by the system. When the content is moved, the target environment is reconfigured and rewired. All long-running processes on the target are stopped and purged, in order to prevent the non-production system from sending emails and alerts to real users, as if it were the production system.

Production-to-test data movement requires the following high-level steps:

• Fulfill Prerequisites and download the production-to-test tools. See Prerequisites and Assumptions.

• Complete Discovery: Execute discovery phase.

• Move Identity Management data using a five-step process.

• Move Fusion Applications data from production to test, while also exporting and re-imported selected test data that must be preserved. See Import Application Data to the IDM and FA Target Systems.

The following assumptions are made for production-to-test data movement:

• Source and target systems must be identical in terms of product version, initial patches, deployment topology, and configurations. The same applies to their respective databases. Note: There are required patches for production-to-test that need to be applied only to the target system. At that point, the patching for the two systems will no longer be identical.

• Both systems were set up following the same set of instructions.

  Note:

  The procedures in this book are NOT designed for Oracle Fusion Applications systems that were installed using OVM templates. If your source system was installed in this way, contact Oracle Support for the correct production-to-test documentation and procedures.

  If you used virtualization technology, such as Oracle Virtual Machines, to host an operating system, but performed full standard provisioning into that virtualization layer, then the procedures in this book CAN be used. Both source and target systems must match.

• The OS version and configurations are identical in both environments.

• Internal host names are identical in both environments.

• The directory paths and structures are identical in both environments.

• Both source and target environments are available for access over SSH.

• The host and port of both OID stores are accessible for data movement.

• The name values for "IDM_JPSROOT" and "FS_JPSROOT" values must be identical between source and target systems.

The discovery phase may be the most important part of the data movement process. Here you determine all the relevant details of your source and destination environments, and record them. Note that the details required for production-to-test data movement are different than those for Cloning.

Refer to the following section to help validate the response files:

• Generating the P2T Response Files