25Importing and Exporting Setup Data

This chapter contains the following:

Exporting and Importing Setup Data: Overview

Almost all Oracle application implementations require moving functional setup data from one instance to another at various points in their life cycle. For example, one of the typical cases in any enterprise application implementation is to first implement in a development or test application instance and then deploy to a production application instance after thorough testing. You can move functional setup configurations of applications from one application instance into another by exporting and importing setup data.

You can export and import setup data for your implementation depending on your business needs using any of the methods described here. You must import the setup data in the same way that you export it.

  • Export and import an entire offering or any of its functional areas. This method is recommended when you want to make sure all the setup data for an offering or functional area is migrated as it currently configured.

  • Export and import an implementation project that contains a modified configuration or list of tasks. Use an implementation project as the source for exporting setup data when you require modifications to the list of tasks or the list of objects you want to export setup data for.

In the case of an offering or functional area, setup data is exported only for the tasks relevant to the features that are enabled for implementation in the offering or functional area. Unlike the case of export an offering or functional area, an implementation project may also include tasks for an entire offering or a functional area but the list of tasks may have been modified to specific needs by adding or removing some of the tasks.

Task CSV Export

Additionally, in some cases, you may have a substantial number of setup data records with few attributes to enter for a setup task. Entering this data using the UI may be cumbersome and in some cases prone to error. Functional Setup Manager provides you the ability to export and import setup data for a specific task that meet these requirements using a CSV file.

Note: Check with the product owner to validate if a task supports CSV export or import that you may require.

Offering Based Export and Import: Explained

It's strongly recommended you use this method for data export and import to ensure migration of all relevant setup data to the offering or functional area. This is especially useful when doing your initial implementation or moving your implementation or configuration across instances for the first time.

This method is advantageous over others because you do not need to choose the tasks or understand data relationships to ensure only setup data relevant to the selected offering or functional area is exported. At the same time, it gives you flexibility to filter the setup data for the offering or functional area, where applicable.

Export and import offering setup data processes are initiated from the Setup and Maintenance work area.

Export

During export, appropriate setup data will be identified as follows:

  • When you export setup data for an offering, the export definition will include setup data for all enabled functional areas and relevant features in the offering.

  • When you export setup data for a single functional area within an offering, the export definition will only include setup data for that functional area and relevant features.

Import

During import, a configuration package created by the export process is uploaded. All setup data contained in the configuration package is imported into the environment you initiate the setup data import from.

Similarly to the export process, you can import setup data for an entire offering or a specific functional area. The offering and functional area must already enabled for implementation before you can import setup data for it. However, the feature selection may or may not be selected. To ensure enabling of that the same functionality that existed in the environment where the setup data was exported from for the corresponding offering or functional area, use the option to import the feature selection at the time of importing the setup data. You must use a configuration package file that contains the setup data for the appropriate offering or functional area. You also have the option to compare the setup data prior to import to identify what setup data modifications will happen if the setup data is imported. You can also compare the setup data after it has been imported (rather than prior to import) in order to ensure that no differences exist. One you initiate the import process, you can monitor its progress and check its status from the Export Offering page. Once the process is complete you can review the reports. Similarly, use the Import Offering Setup Data page to upload and import previously exported setup data.

Implementation Project Based Export and Import: Explained

Use an implementation project as the source for exporting setup data when you are required to modify the list of tasks or of objects you want to export setup data for.

You must explicitly create a configuration package from the Setup and Maintenance work area to export setup data for an implementation project. You generate the setup export and import definition by selecting an implementation project and creating a configuration package. The tasks and their associated business objects in the selected implementation project define the setup export and import definition for the configuration package. Depending on your needs, when you create a configuration package based on an implementation project, you can also modify some additional aspects, as explained here.

  • Exclude some of the business objects from the configuration you selected to export setup data for.

    You should limit to use this option when the corresponding setup data is already available in the target instance and therefore no data dependency issues appear during import.

  • Change the default import sequence of the business objects

    It's strongly recommended that you limit using this option when you need to correct a data dependency issue and you fully understand the data relationships between the business objects of your configuration.

  • Filter the setup data to export

Export

During export, appropriate setup data is identified based on the tasks in the implementation project used as source for the configuration package. The setup data in the configuration package is a snapshot of the data in the source application instance at the time of export. Once export completes, you can download the configuration package file as a zipped archive of multiple XML files, move it to the target application instance, and upload and import it. After exporting the setup data you may continue entering new or modifying existing setup data for your configuration. Since the configuration package is a snapshot of the setup data taken at the time export is initiated, you may need to take another snapshot of the same configuration or set of data later. Although you can always create a different configuration package, Functional Setup Manager provides you the ability to take another snapshot of the setup data using the same modified export and import definition by exporting the configuration package multiple times and creating multiple versions. While the export definition remains the same in each version, the setup data can be different if you modified the data in the time period between the different runs of the export process. Since each version of the configuration package has a snapshot of the data in the source instance, you can compare and analyze various versions of the configuration package to see how the setup data changed.

Import

During import, you first upload a configuration package created by the export process and then import the setup data. All setup data contained in the configuration package is imported into the environment you initiate the setup data import from. In the target application instance, the setup import process inserts all new data from the source configuration package that does not already exist, and update any existing data with changes from the source. Setup data that exists in the target instance but not in source will remain unchanged.

Configuration Packages: Explained

A configuration package contains the setup import and export definition. The setup import and export definition is the list of setup tasks and their associated business objects that identifies the setup data for export as well as the data itself. When you create a configuration package only the setup export and import definition exists. Once you submit export, a snapshot of the appropriate setup data is added to the configuration package using the definition. You can continue making modifications to the setup data in the environment and create a new configuration package any time you need it.

You can generate the setup export and import definition implicitly or explicitly:

  • A configuration package is created implicitly when you export setup data for an entire offering or any functional area.

  • A configuration package is created explicitly when you export setup data based on an implementation project. This method enables further modification of the configuration packages.

You generate the setup export and import definition by selecting an implementation project and creating a configuration package. The tasks and their associated business objects in the selected implementation project define the setup export and import definition for the configuration package. In addition, the sequence of the tasks in the implementation project determines the export and import sequence.

The tasks and their associated business objects in the selected configuration (offering, functional area or implementation project) define the setup export and import definition for the configuration package. In addition, the sequence of the tasks in the implementation project determines the export and import sequence.

Once a configuration package is exported, the setup export and import definition is locked and cannot be changed. You cannot change the add or remove tasks and their associated business objects, change their export and import sequence, or change the scope value selection. However, you can create a new configuration package with such modifications at any time.

Moving Common Reference Objects

Moving Common Reference Objects: Overview

The common reference objects are used by several setup tasks in the Setup and Maintenance work area. The common reference objects become a part of the configuration package that is created for an implementation project. While moving the application content, for example, moving from test to the production phase of an implementation, attend to the nuances of these common reference objects.

Parameters

The common reference objects are represented as business objects. A single object can be referenced in multiple setup tasks with different parameters. In the configuration package created for the implementation project, parameters passed to a setup task are also passed to the business objects being moved. As a result, the scope of the setup tasks is maintained intact during the movement.

Dependencies

Common reference objects may have internal references or dependencies among other common reference objects. Therefore, you must note all the dependencies before moving the objects so that there are no broken references among them.

Business Objects for Moving Common Reference Objects: Points to Consider

Common reference objects in Oracle Fusion Functional Setup Manager are used to move application setup content from one environment to another. For example, from a test environment to a production environment.

Choice of Parameters

The following table lists the business objects, the movement details, and the effect of the setup task parameter on the scope of the movement.

Note:
  • You can move only the translations in the current user language.

  • You can move the Oracle Social Network business objects and the Navigator menu customizations using the customization sets on the Customization Migration page.

Business Object Name Moved Functional Item Effect on the Scope of Movement

Application Message

Messages and associated tokens

No parameters: All messages are moved.

Parameter moduleType/moduleKey: Only messages belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Parameter messageName/applicationId: Only the specified message is moved.

Application Taxonomy

Application taxonomy modules and components

No parameters: All taxonomy modules and components are moved.

Application Attachment Entity

Attachment entities

No parameters: All attachment entities are moved.

Parameter moduleType/moduleKey: Only attachment entities belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Application Attachment Category

Attachment categories and category-to-entity mappings

No parameters: All attachment categories and category-to-entity mappings are moved.

Parameter moduleType/moduleKey: Only attachment categories belonging to the specified module and its descendant modules in the taxonomy hierarchy along with the respective category-to-entity mappings are moved.

Application Document Sequence Category

Document sequence categories

No parameters: All categories are moved.

Parameter moduleType/moduleKey: Only categories belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Parameter code/applicationId: Only the specified document sequence category code is moved.

Application Document Sequence

Document sequences and their assignments

No parameters: All sequences are moved.

Parameter moduleType/moduleKey: Only document sequences belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved

Parameter name: Only the specified document sequence is moved.

Application Descriptive Flexfield

Descriptive flexfield registration data and setup data

No parameters: All descriptive flexfields are moved.

Parameter moduleType/moduleKey: Only descriptive flexfields belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Parameter descriptiveFlexfieldCode/applicationId: Only the specified descriptive flexfield is moved. Importing the metadata of a flexfield can change its deployment status. Therefore, you must redeploy if there are any affected flexfields. The import process automatically submits affected flexfields for redeployment. Also, only flexfields with a deployment status of Deployed or Deployed to Sandbox are eligible to be moved.

Application Extensible Flexfield

Extensible flexfield registration data and setup data, including categories

No parameters: All extensible flexfields are moved

Parameter moduleType/moduleKey: Only extensible flexfields belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Parameter extensibleFlexfieldCode/applicationId: Only the specified extensible flexfield is moved. Importing the metadata of a flexfield can change its deployment status and therefore, the affected flexfields must be redeployed. The import process automatically submits affected flexfields for redeployment.

Also, only flexfields with a deployment status of Deployed or Deployed to Sandbox are eligible to be moved.

Application Key Flexfield

Key flexfield registration data and setup data

No parameters: All key flexfields are moved.

Parameter moduleType/moduleKey: Only key flexfields belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Parameter keyFlexfieldCode/applicationId: Only the specified key flexfield is moved.

Importing the metadata of a flexfield can change its deployment status and therefore, the affected flexfields must be redeployed. The import process automatically submits affected flexfields for redeployment. Only flexfields with a deployment status of Deployed or Deployed to Sandbox are eligible to be moved.

Application Flexfield Value Set

Value set setup data

No parameters: All value sets are moved.

Parameter moduleType/moduleKey: Only value sets belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Parameter valueSetCode: Only the specified value set is moved.

Importing the metadata of a value set can change the deployment status of flexfields that use the value set. Therefore, you must redeploy if there are any affected flexfields. The import process automatically submits affected flexfields for redeployment.

Application Reference Currency

Currency data

No parameters: All currencies are moved.

Application Reference ISO Language

ISO language data

No parameters: All ISO languages are moved.

Application Reference Industry

Industry data including industries in territories data

No parameters: All industries are moved.

Application Reference Language

Language data

No parameters: All languages are moved.

Application Reference Natural Language

Natural language data

No parameters: All natural languages are moved.

Application Reference Territory

Territory data

No parameters: All territories are moved.

Application Reference Time zone

Time zone data

No parameters: All time zones are moved.

Application Standard Lookup

Standard lookup types and their lookup codes

No parameters: All standard lookups are moved.

Parameter moduleType/moduleKey: Only standard lookups belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Parameter lookupType: Only the specified common lookup is moved.

Application Common Lookup

Common lookup types and their lookup codes

No parameters: All common lookups are moved.

Parameter moduleType/moduleKey: Only common lookups belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Parameter lookupType: Only the specified common lookup is moved.

Application Set-Enabled Lookup

Set-enabled lookup types and their lookup codes

No parameters: All set-enabled lookups are moved.

Parameter moduleType/moduleKey: Only set-enabled lookups belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Parameter lookupType: Only the specified set-enabled lookup is moved.

Application Profile Category

Profile categories

No parameters: All profile categories are moved.

Parameter moduleType/moduleKey: Only categories belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

name/applicationId: Only the specified category is moved.

Application Profile Option

Profile options and their values

No parameters: All profile options and their values are moved.

Parameter moduleType/moduleKey: Only profile options and their values belonging to the specified module are moved.

Parameter profileOptionName: Only the specified profile option and its values are moved.

Application Profile Value

Profile options and their values

No parameters: All profiles and their values are moved.

Parameter moduleType/moduleKey: Only profiles and their values belonging to the specified module are moved.

Parameter categoryName/categoryApplicationId: Only profiles and their values belonging to the specified category are moved.

Parameter profileOptionName: Only the specified profile and its values are moved.

Application Reference Data Set

Reference data sets

No parameters: All sets are moved.

Application Reference Data Set Assignment

Reference data set assignments

Parameter determinantType: Only assignments for the specified determinant type are moved.

Parameter determinantType/referenceGroupName: Only assignments for the specified determinant type and reference group are moved.

Application Tree Structure

Tree structures and any labels assigned to the tree structure

No parameters: All tree structures (and their labels) are moved.

Parameter moduleType/moduleKey: Only tree structures (and their labels) belonging to the specified module are moved.

Parameter treeStructureCode: Only the specified tree structure (with its labels) is moved.

Application Tree

Tree codes and versions

No parameters: All trees are moved.

Parameter moduleType/moduleKey: Only trees belonging to the specified module are moved.

Parameter treeStructureCode: Only trees belonging to the specified tree structure are moved.

Parameter TreeStructureCode/TreeCode: Only trees belonging to the specified tree structure and tree code are moved.

Application Tree Label

Tree structures and any labels assigned to the tree structure

No parameters: All tree structures (and their labels) are moved.

Parameter moduleType/moduleKey: Only tree structures (and their labels) belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Parameter treeStructureCode: Only the specified tree structure (with its labels) is moved.

Application Data Security Policy

Database resources, actions, conditions, and data security policies

No parameters: All database resources/actions/conditions/policies are moved.

Parameter moduleType/moduleKey: Only database resources/actions/conditions/policies belonging to the specified module and its descendant modules in the taxonomy hierarchy are moved.

Parameter objName: Only the specified database resource along with its actions/conditions/policies is moved.

If the policies being moved contain reference to newly created roles, move the roles before moving the policies. If the source and target systems use different LDAPs, manually perform the GUID reconciliation after moving the data security policies.

Moving Related Common Reference Objects: Points to Consider

Certain common reference objects may use other common reference objects creating dependencies among the objects. During the movement of common reference objects, ensure that these dependencies or references aren't broken or lost.

Dependencies

The dependencies among the common reference objects may be caused by any of the following conditions.

  • Flexfield segments use value sets

  • Value sets may make use of standard, common, or set-enabled lookups

  • Key flexfields may have an associated tree structure and key flexfield segments may have an associated tree code

  • Tree codes and versions may be defined over values of a value set

  • Data security policies may be defined for value sets that have been enabled for data security

You may decide to move one, some, or all of the business objects by including the ones you want to move in your configuration package. For example, you may decide to move only value sets, or move both value sets and their lookups as part of the same package. Whatever be the combination, Oracle recommends that during the movement of objects, you follow an order that maintains the dependencies among the objects.

While moving the business objects, adhere to the following order:

  1. Move created taxonomy modules before moving any objects that reference them, such as flexfields, lookups, profiles, messages, and so on.

  2. Move created currencies before moving any objects that reference them, such as territories.

  3. Move created territories before moving any objects that reference them, such as languages and natural languages.

  4. Move created ISO languages before moving any objects that reference them, such as languages, natural languages, and industries.

  5. Move created tree structures before moving any objects that reference them, such as trees or tree labels.

  6. Move created profile options before moving any objects that reference them, such as profile categories or profile values.

  7. Move created attachment entities before moving any objects that reference them, such as attachment categories that reference them.

Note: In scenarios where there may be dependencies on other objects, you must move the dependencies before moving the referencing object. For example, if data security policies have dependencies on newly created security roles, you must move the security roles before moving the security policies.

Using Seed Data Framework to Move Common Reference Objects: Points to Consider

To move the common reference objects, you can use the Seed Data Framework (SDF). You can also use the command line interface of SDF to move the object setup data. For more information about seed data loaders including common reference object loaders, see Oracle Fusion Applications Developer's Guide.

Movement Dependencies

The seed data interface moves only the setup metadata. For example, if you use SDF to import flexfield metadata, the flexfield setup metadata is imported into your database. However, you must initiate the flexfield deployment process separately after seed data import to regenerate the runtime flexfield artifacts in the target environment. Similarly, if you use SDF to import data security metadata, you must first move any new referenced roles and then manually run the GUID reconciliation where required.

To ensure that the reference data is not lost during the movement, certain guidelines are prescribed. It is recommended that you perform the movement of object data exactly in the following order:

Note: Only the translation in the current user language is moved.
  1. Move created taxonomy modules before moving any objects that reference them, such as flexfields, lookups, profiles, attachments, reference data sets, document sequences, messages, and data security.

  2. Move created currencies before moving any objects that reference them, such as territories.

  3. Move created territories before moving any objects that reference them, such as languages and natural languages.

  4. Move created ISO languages before moving any objects that reference them, such as languages, natural languages, and industries.

  5. Move created tree structures before moving any objects that reference them, such as trees or tree labels.

  6. Move created profile options before moving any objects that reference them, such as profile categories or profile values.

  7. Move created attachment entities before moving any objects that reference them, such as attachment categories that reference them.

  8. Move created reference data sets before moving any objects that reference them, such as reference data set assignments and set-enabled lookups.

  9. Move created document sequence categories before moving any objects that reference them, such as document sequences.

  10. Move created tree labels before moving any objects that reference them, such as trees.

  11. Move created data security objects and policies before moving any objects that reference them, such as value sets.

  12. Move created value sets before moving any objects that reference them, such as flexfields.

  13. Move created trees before moving any objects that reference them, such as key flexfields.