Oracle® Fusion
Applications Sales Implementation Guide 11g Release 1 (11.1.2) Part Number E20373-02 |
Contents |
Previous |
Next |
This chapter contains the following:
Importing and Exporting Setup Data
Exporting and Importing Setup Data: Explained
Moving Common Reference Objects
Almost all Oracle Fusion application implementations require moving functional setup data from one instance into another at various points in the lifecycle of the applications. 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 Configuration packages from the Manage Configuration Packages page.
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 export the configuration package appropriate setup data is added to the configuration package using the definition. Once a configuration package is exported, the setup export and import definition is locked and cannot be changed.
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 determine the export and import sequence.
A configuration package is required to export setup data. You can export a configuration package once you create it, or at any time in the future. During export, appropriate setup data will be identified based on the setup export definition and added to 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. After the export completes, you can download the configuration package as a zipped archive of multiple XML files, move it to the target application instance, and upload and import it.
You can export a configuration package multiple times by 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.
In the target application instance, the setup import process will insert 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.
You can review the results of the export and import processes using reports. The results appear ordered by business objects and include information on any errors encountered during the export or import process. If a setup export or import process paused due to errors encountered or for a manual task to be performed outside of the application, then you can resume the paused process.
These reports show what setup data was exported or imported and by which specific process. You can change the reports to validate the setup data as well as to compare or analyze it. A report is generated for each business object. These reports show the same information as the export and import results seen directly in the application.
Process status details are available as text files showing the status of an export or import process including the errors encountered during the process.
The common reference objects in Oracle Fusion Middleware Extensions for Applications 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, from the test phase to the production phase of an implementation, you must pay special attention to the nuances of these common reference objects.
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 that is 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.
Common reference objects may have internal references or dependencies among other common reference objects. Therefore, it is necessary that all the dependencies are noted before the movement of objects so that there are no broken references among the objects.
Common reference objects in Oracle Fusion Functional Setup Manager are represented by business objects. These business objects are the agents that contain the application content and carry them across whenever the application setup is moved from one environment to another, for example, test environment to production environment.
The following table lists the business objects, the corresponding movement details, and the effect of the setup task parameter on the scope of the movement.
Note
Only the translation in the current user language is moved.
Business Object Name |
Moved Functional Item |
Effect on the Scope of Movement |
---|---|---|
Application Menu Customization |
Customizations to the navigator menu |
Movement of navigator menu customizations requires manual effort. For details regarding the manual command, refer to the Oracle Fusion Applications Administrators Guide. |
Application Message |
Messages and associated tokens |
No parameters: all messages are 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.
|
Application Attachment Category |
Attachment categories and category-to-entity mappings |
No parameters: all attachment categories and category-to-entity mappings are moved.
|
Application Document Sequence Category |
Document sequence categories |
No parameters: all categories are moved.
|
Application Document Sequence |
Document sequences and their assignments |
No parameters: all sequences are moved.
|
Application Descriptive Flexfield |
Descriptive flexfield registration data and setup data |
No parameters: all descriptive flexfields are moved.
Note Importing a flexfield's metadata can change its deployment status and therefore, the affected flexfields must be redeployed. The import process automatically submits affected flexfields for redeployment. |
Application Extensible Flexfield |
Extensible flexfield registration data and setup data, including categories |
No parameters: all extensible flexfields are moved
Note Importing a flexfield's metadata can change its deployment status and therefore, the affected flexfields must be redeployed. The import process automatically submits affected flexfields for redeployment. |
Application Key Flexfield |
Key flexfield registration data and setup data |
No parameters: all key flexfields are moved.
Note Importing a flexfield's metadata can change its deployment status and therefore, the affected flexfields must be redeployed. The import process automatically submits affected flexfields for redeployment. |
Application Flexfield Value Set |
Value set setup data |
No parameters: all value sets are moved.
Note Importing a value set's metadata can change the deployment status of flexfields that use the value set, and therefore the affected flexfields must be redeployed. 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.
|
Application Common Lookup |
Common lookup types and their lookup codes |
No parameters: all common lookups are moved.
|
Application Set-Enabled Lookup |
Set-enabled lookup types and their lookup codes |
No parameters: all set-enabled lookups are moved.
|
Application Profile Category |
Profile categories |
No parameters: all profile categories are moved.
|
Application Profile Option |
Profile options and their values |
No parameters: all profile options and their values are moved.
|
Application Profile Value |
Profile options and their values |
No parameters: all profiles and their 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 |
|
Application Tree Structure |
Tree structures and any labels assigned to the tree structure |
No parameters: all tree structures (and their labels) are moved.
|
Application Tree |
Tree codes and versions |
No parameters: all trees 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.
|
Application Data Security Policy |
Database resources, actions, conditions, and data security policies |
No parameters: all database resources/actions/conditions/policies are moved.
Note
|
Application Activity Stream Configuration |
Activity stream options |
No parameters: all activity stream options are moved. |
Certain common reference objects may use other common reference objects creating dependencies among the objects. During the movement of common reference objects, these dependencies or references need to be taken care of.
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 choose 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 choose to move only value sets and not lookups, or you may choose to move both value sets and their lookups as part of the same package. Whatever be the combination, it is recommended 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 guidelines and exactly follow the order as listed below.
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.
Move created currencies before moving any objects that reference them, such as territories.
Move created territories before moving any objects that reference them, such as languages and natural languages.
Move created ISO languages before moving any objects that reference them, such as languages, natural languages, and industries.
Move created tree structures before moving any objects that reference them, such as trees or tree labels.
Move created profile options before moving any objects that reference them, such as profile categories or profile values.
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 being moved have dependencies on newly created security roles, you must move the security roles before moving the security policies.
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.
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 invoke 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 order given below.
Note
Only the translation in the current user language is moved.
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.
Move created currencies before moving any objects that reference them, such as territories.
Move created territories before moving any objects that reference them, such as languages and natural languages.
Move created ISO languages before moving any objects that reference them, such as languages, natural languages, and industries.
Move created tree structures before moving any objects that reference them, such as trees or tree labels.
Move created profile options before moving any objects that reference them, such as profile categories or profile values.
Move created attachment entities before moving any objects that reference them, such as attachment categories that reference them.
Move created reference data sets before moving any objects that reference them, such as reference data set assignments and set-enabled lookups.
Move created document sequence categories before moving any objects that reference them, such as document sequences.
Move created tree labels before moving any objects that reference them, such as trees.
Move created data security objects and policies before moving any objects that reference them, such as value sets.
Move created value sets before moving any objects that reference them, such as flexfields.
Move created trees before moving any objects that reference them, such as key flexfields.
The Bulk Export application provides a mechanism to extract large volumes of data from Fusion CRM objects. These extracts can be the full set of records for an object or incremental extracts. For example, data extracted for a specific period of time, from the hosted CRM system to an on-premise database that resides behind a user's fire-wall. The system will create comma separated variable or tab delimited files with the extracted data, which will be available to users as attachments to the batch records that have been executed.
The following figure depicts the process of selecting data for export, scheduling and finally delivering the exported data file.
This solution provides a mechanism to extract large volumes of data from Fusion CRM objects, both as extracts of a full set of records for an object as well as incremental extracts. The system will create comma or tab delimited files with the extracted data which will be available to users as attachments to the batch records that have been executed.
In order to create the extracts, two steps must be completed. First, mapping files for the full and incremental extract processes must be defined in the Fusion CRM system. These maps will specify which columns and filters will be applied to each export process for each export object. For the incremental extracts, filters can be created that leverage time stamps to determine which rows will be queried out of the system. All mapping files will be saved in the system and reused for each extract.
Next, the hourly and weekly data export processes
are scheduled in the Fusion export tool. For any required incremental
and scheduled export, the export task should either exist or created
through the UI. Oracle Web Services would only be used to schedule
the export and start it. After each export process executes and completes,
a comma or tab delimited data file will be created and stored in the
Fusion system as an attachment. The formatted file can be downloaded
by using the getAttachment()
web service
or by using the interactive UI in the export tool.
There are no transactional steps for this process in the Fusion CRM application, there are only prerequisite setup steps. Once these steps are complete the process should run automatically. The prerequisite steps in Fusion are to create an export map and export job schedule for each object to be extracted (this only needs to be done once).
The Bulk Export Process Definition is made up of the Export Map and the processing schedule. See the steps below.
The export object is the Fusion data base object where the data resides. It is made up of attributes. If you need to export data from a custom table, you must register the object as an export object. This is accomplished from the Manage Export Process UI, Manage Export Objects action. All the delivered tables and their attributes are available for export.
The export object is made up of attributes. These attribute may be selected for export or not included. You can edit the header text of the attribute to make its meaning more clear to other users of this process.
Each attribute may have limits or conditions enforced. Various operators are available for selecting the data to precisely select the data required for the export. You can save the filter criteria and then modify the criteria and save it under a new name. You can then change the filter by coming here to select an alternate filter name. Because the filters are related to the export object, if you reuse a map and change the filter, you are changing it for any Export Process Definition that uses that map. The attributes you use for the map have no bearing on what is available in the filter. All fields from the VO are available for use in the filter. For example, you can filter by TYPE but not show TYPE in the output.
Once defined, the export process is scheduled. You can run the process immediately or at the time and date of your choosing. If you decide to schedule the job at a later date you can also choose to set up a recurring schedule of extracts.
By clicking on the Activate button, you make the job available to be run. It does not start an export process.
In the two step process used by Oracle Fusion Bulk Export, the first is the mapping of files for the full and incremental extract processes. The second step is the scheduling of the export. You create a process definition that includes both of these steps.
The process definition has three components that together make exporting data easier by leveraging the export maps that you have already built. The process name, the export process ID and the export map ID all serve to identify the specific process definition as well as leverage your work with reusable export maps
A user-supplied, natural language way to refer to the Export Process Definition. This enables you to refer to the export process definition easily rather than using the machine generated ID. For example, use Customer or some other meaningful name as the export process name instead of the export process ID 100000019897192.
A unique, system generated identifier for the export process definition that ties together the export map, with its export objects and filters, and the defined export schedule.
A unique identifier for the export map itself. You can name the export map or leave the field blank for a system generated map name to be entered. You can reuse the export map in different process definitions. For example, you could create a process definition to export all the data from the Customer export object. You could then reuse that export map and apply a new filter on the data to create an incremental export, such as data accrued since the last export date.
Review the requirements for the data to be exported and determine the source view object that holds the attributes you want.
Full sets of data are not always required for export. To create a subset of data, use filter criteria to determine the time frame or scope of data, based on values of the attributes. For example, to find activities for a certain period, use a project start date from 1/1/11 through 3/31/11, navigate to the Export Objects Detail Sub Page and click the filter icon. Fill in the filter criteria dialog for the project start dates to select the data to be exported.You run the export by navigating to the Setup and Maintenance menu, selecting Manage Task Lists and Tasks. Then, search for Schedule Export Processes and click the Go to Task icon on the line for this task.
You can look on the Schedule Export Processes, Overview page to see the History subpage. The column Exported Data File shows a hyperlink to your output file This file will be a comma separated variable or a tab delimited file. Click that link to open the file and see the exported data.
You can use your own defined view objects as a source for Bulk Export. To register your view objects for export, select Setup and Maintenance from the Tools menu and search for the Manage Export Objects task. Click the Go to Task icon and on the Manage Export Objects page click the Create icon to add your View Object, making it available for use.
Changing the sequence number changes the order of the attributes in the exported data file. Changing the header text enables you to give a more intuitive meaning to the attribute and the associated data.
Select as many view objects as required to be export objects for the export process. Choose the individual attributes required from each export object.