| Oracle® Fusion Applications Extensibility Guide 11g Release 1 (11.1.4) Part Number E16691-06 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Extensibility Guide 11g Release 1 (11.1.4) Part Number E16691-06 |
|
|
PDF · Mobi · ePub |
This chapter discusses the typical workflow for customizing and extending Oracle Fusion applications. It describes how to use sandboxes to perform customizations in a segregated environment, publish the changes to a full test environment, and export the changes to other environments.
This chapter includes the following sections:
Section 2.1, "Understanding Typical Customization Workflows"
Section 2.3, "Viewing and Diagnosing Runtime Customizations"
Section 2.4, "Downloading and Uploading Customization Files"
All customizations and extensions to Oracle Fusion Applications, whether done by business analysts or developers, should be done in a test environment. Typically, this environment contains one or more Oracle Fusion applications that will then be moved to a production environment after all customizations and extensions are complete and tested.
As described in Section 2.1.1, "Runtime Customization Workflow," business analysts using Page Composer and CRM Application Composer can make application customizations in sandboxes. Sandboxes store the customizations in Extensible Markup Language (XML) files in a separate Oracle Metadata Services (MDS) repository that is available only when you work in that particular sandbox. The changes can be done in a test-only sandbox (that is, the code in the sandbox is for testing only, and is never deployed), or they can be done in a sandbox that is then published to the environment.
Developers using design time tools, such as Oracle JDeveloper, can deploy their customizations directly to that environment, or they can publish to a sandbox, as described in Section 2.1.2, "Design Time Customization Workflow."
Project managers can monitor the customizations, and can also import and export customizations. The entire environment with all customizations can then be tested, as shown in Figure 2-1.
Tip:
When you extend Oracle Fusion applications, you might want users to be able to configure the extensions using Oracle Fusion Functional Setup Manager. For more information about creating setup flows for extensions, see the Oracle Fusion Applications Information Technology Management, Implement Applications Developer Guide.
When you use CRM Application Composer and Page Composer to make runtime customizations to Oracle Fusion applications, you can use sandboxes to save your changes in a segregated environment. For example, before you begin making customizations, you create a sandbox named MySandbox and make your customizations in that sandbox. If others want to see the customizations, then they would use MySandbox.
Note:
There are restrictions for when more than one user is working in a sandbox. For more information, see Section 2.2.1, "Sandboxes and Concurrent Usage."
You can also use a sandbox when you define security policies for custom objects that you have created using CRM Application Composer. A security sandbox stores the security information in new database tables that are available only when you choose to work in that sandbox.
After you complete your customizations, the sandbox can be reviewed and approved by others, and then published to the full test environment where your customizations become part of that repository. For more information about sandboxes, see Section 2.2, "Using the Sandbox Manager."
Note:
Flexfield sandboxes are for testing only and cannot be published. Instead, you deploy a flexfield to the full test environment using the flexfield UI. To test a flexfield configuration before deploying it to the full test environment, deploy it to a flexfield sandbox, as described in Section 5.7, "Deploying Flexfield Configurations." The changes that you deploy to a sandbox are isolated from the full test environment and can be seen only by those who make the flexfield sandbox active in their session. After you are satisfied with the changes in the sandbox, you can deploy the changes to the full test environment.
When you publish a sandbox, the published customizations are labeled. Labeling can act as a save point, meaning that if a future customization causes issues, you can use the Manage Customizations dialog to remove all customizations done after that point by promoting the last known good label back to the tip. For more information, see Section 2.3.3, "Backing Out Customizations."
You can also use the Manage Customizations dialog to view others' customization metatdata files, and to download those files to manually move them to another environment or to diagnose any issues. You can also upload others' customization metadata files to your environment. For more information, see Section 2.3, "Viewing and Diagnosing Runtime Customizations."
Note:
Navigator menu, BPMN process flows, and report customizations do not use an MDS repository. Refer to Chapter 6, "Customizing the Navigator Menu," Chapter 7, "Customizing and Extending BPMN Processes ," and Chapter 8, "Customizing Reports and Analytics" for more information.
Figure 2-2 illustrates the use of sandboxes when customizing pages, objects, and security using Page Composer and CRM Application Composer and when configuring flexfields.
As explained in Section 1.3.1, "What You Can Customize and Extend and with Which Tool," some types of customizations, such as user interface template customizations, must be made at design time using JDeveloper. After you create these customizations, you can test them locally in JDeveloper and then deploy them directly into the full test environment. You can also deploy your customizations to a sandbox. Note that security customizations done at design time are not saved to a sandbox. Additionally, you can use source control software to manage design-time customizations. For more information about what source control software JDeveloper supports, see the "Versioning Applications with Source Control" topic of the JDeveloper online help.
Because your customizations (other than security changes) are stored in customization XML files in an MDS repository, they can also be viewed and managed using the Manage Customizations dialog.
Note:
Unlike runtime customizations, you cannot promote design time customizations, as described in Section 2.3.3, "Backing Out Customizations." If a design time customization is causing a problem, you must undeploy the changes, fix the issues, and then redeploy to the test environment.
Figure 2-3 shows the flow for a typical design time customization process.
The sandbox manager is a tool for managing the different types of customization changes that can be applied to an application. The different types of sandboxes are:
Metadata
The metadata sandbox supports making changes to the application's metadata stored in the MDS repository.
Security
The security-enabled sandbox supports making data security changes.
Flexfield
The flexfield sandbox is not created using the sandbox manager. Use the flexfield UI to make changes to the flexfields and then deploy them to the sandbox. The flexfield deployment process manages the creation of the sandbox. For more information about flexfields, see Section 5.7, "Deploying Flexfield Configurations."
To customize an Oracle Fusion application in runtime, you first create a sandbox and then use Page Composer or CRM Application Composer to make the customizations. These changes will be contained within the sandbox so they do not affect the mainline code. You then test and validate the changes by publishing the sandbox to the full test environment. After the application has been tested, it can then be moved to the production environment where the customization changes will be available to users of the system.
You can make changes to an application at runtime in a sandbox so that the changes are isolated from the mainline code. The mainline code is a branch of data that serves as a single source of truth. After you are satisfied with the changes in the sandbox and want to commit them, you can publish the metadata or security-enabled sandbox to the mainline code. Flexfield sandboxes are for testing only and cannot be published. You make flexfield configurations that are then stored in a database, and then deploy those configurations to a sandbox to see the resulting deployment artifacts in a sandbox environment. Flexfields are deployed directly to the mainline code using the flexfield UI. For more information about flexfields, see Section 5.7, "Deploying Flexfield Configurations."
You can use runtime tools to customize the application. The sandbox manager works with CRM Application Composer and Page Composer to customize objects and pages:
For information about using CRM Application Composer, see Chapter 4, "Customizing Objects."
For information about using Page Composer, see Chapter 3, "Customizing Existing Pages."
Oracle Business Process Composer and Oracle SOA Composer are also runtime customization tools, but they do not use the sandbox manager. They have their own mechanisms for handling customization changes:
For information about using Oracle Business Process Composer, see Chapter 7, "Customizing and Extending BPMN Processes ."
For information about using Oracle SOA Composer, see Chapter 12, "Customizing and Extending SOA Components."
The metadata sandboxes created using the sandbox manager are available in JDeveloper when you are creating and deploying customizations intended for a deployed Oracle Fusion application in Oracle WebLogic Server. The available sandboxes will appear in a selection list in JDeveloper during deployment. For more information, see Section 11.14, "Deploying ADF Customizations and Extensions." Note that the security sandboxes created using the Sandbox Manager are not available in JDeveloper.
In CRM Application Composer, you can customize security policies using a sandbox specifically for editing them. When you enable the security sandbox, the operation will duplicate the schema for Oracle Fusion Data Security tables, which is a lengthy setup operation. Therefore, ensure that you are fully ready to customize the security policies before you enable the security sandbox.
The security policy customizations that you publish from a sandbox will be merged into the Oracle Fusion security policy repository as part of the native application, and will overwrite any previous customizations. Ensure that you are not editing the same object concurrently with another user to avoid inconsistencies can result when multiple users edit the security policies associated with the same object in different sandboxes.
The metadata and security sandbox sessions can be saved, downloaded, and imported as files into other Oracle Fusion applications.
In the customization runtime workflow, sandboxes are used to isolate the changes from the mainline code for testing and validating. After you are satisfied with the changes, you can publish the changes back to the mainline code. You can also create sandboxes for testing purposes only, and not publish them.
There are two types of sandboxes:
Sandboxes intended to be published.
These sandboxes will be merged back to the mainline code.
Sandboxes intended for test-only purposes.
These test-only sandboxes will not be published and therefore produce no concurrency conflicts between sandboxes. You can have many test-only sandboxes at the same time. But if you have multiple users working on the same test-only sandbox, then they must adhere to the guidelines described in Section 2.2.1.3, "Guidelines for One Sandbox, Multiple Users."
Figure 2-4 illustrates the two types of sandboxes and their relationship to the mainline code.
When multiple users can customize an application using sandboxes, there are two types of concurrency conflicts:
Conflicts within a sandbox: Users overwriting changes created by other users, either directly by changing the same artifact, or indirectly by affecting files that are shared between the artifacts. For more information, see Section 2.2.1.3, "Guidelines for One Sandbox, Multiple Users."
Conflicts between sandboxes (intended for publishing only): Multiple sandboxes with the same customized artifact publishing to the mainline code. For more information, see Section 2.2.1.4, "Guidelines for Multiple Sandboxes, Multiple Users."
An application artifact typically includes several metadata files. Therefore, creating or editing an artifact usually means making changes, whether directly or indirectly, to more than one file. Some of these metadata files may be shared between artifacts.
Note:
Many customization scenarios, including customizing security policies, involve editing the same underlying artifacts. The only way to be certain of eliminating the possibility of any concurrency conflicts is to allow only one user at a time in an active sandbox. If you must have multiple users or multiple sandboxes, then follow the usage guidelines described in Section 2.2.1.3, "Guidelines for One Sandbox, Multiple Users," and Section 2.2.1.4, "Guidelines for Multiple Sandboxes, Multiple Users."
Conflicts within a sandbox can arise when multiple users are customizing an application using the same sandboxes at the same time, because more than one user may be attempting to customize the same artifact, or performing a customization task that indirectly affects other shared files. An example of a direct conflict is when different users attempt to customize the same page, the same fragment, or the same metadata file within the same layer. An example of an indirect conflict is when two users, each creating their own object, cause a conflict in the metadata file that tracks which new objects have been created by both saving their changes around the same time.
Conflicts may also arise when users are editing a shared artifact, such as when a user performs an operation that adds or edits a translatable string. For example, a user edits a field's display label or help text, or a validation rule's error message, while another user performs an operation around the same time that similarly affects translatable strings. Another example of a shared artifact conflict is when two or more users are working in navigator menus that are shared across applications.
When you are using Page Composer, although you are not required to, you should use a sandbox. Page Composer provides concurrency warning messages when there is a potential customization conflict with another user. For Page Composer, these warning messages help prevent conflicts. For more information, see the "Editing Pages" section of the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.
When you are using CRM Application Composer, always use a sandbox. CRM Application Composer provides error messages when there is a concurrency conflict. If multiple users in a single sandbox attempt to edit the same artifact, then an error message is displayed. For example, if two users are editing the label of the same attribute, then CRM Application Composer will display an error message.
Conflicts between sandboxes can arise when there is more than one sandbox intended for publishing in use. If two sandboxes contain customization changes to the same artifact and both are being published, then the sandbox that is being published last is given an option (by the sandbox manager) to overwrite the changes for that artifact from the sandbox that was published first. If the user working in the second sandbox decides to force the publication of the second sandbox, then the changes published by the first sandbox are overwritten. These types of conflicts can also occur with shared metadata files such as resource bundles that store translatable strings.
If there is a concurrent change made in the mainline code after the sandbox was created and the user attempts to publish that sandbox, such conflicts are detected at publication time and errors messages occur.
Regardless of whether the sandbox is intended for publishing or for test-only, if you want to permit multiple users to work in a single sandbox simultaneously, follow these guidelines:
Multiple concurrent users in the same sandbox must operate only on different and unrelated objects.
For example, if user1 updates object1, then user2 can update object2 but should not update object1. Be aware that if both modifications involve changes to translatable strings, then saving changes to separate objects around the same time may still cause a conflict in the resource bundle that stores the translatable strings.
If multiple users update the same artifact concurrently (either the same object or the same underlying frequently modified file), then they will get a concurrent update error. In this case, the second user's changes will not be saved (the Save button will be disabled) and one of the users will have to cancel and try again.
CRM Application Composer retains any uncommitted changes in the UI. For example, if the user is editing a groovy expression when the error is encountered, then the expression is retained in the editor so the user can copy and paste the expression to try customizing again. (No metadata corruption or partial transactional commits will happen.)
Users in the same sandbox will see the changes created by one another. The latest version of each object gets loaded on-demand the first time it is viewed in CRM Application Composer. Users can refresh their view to the latest definition from MDS and see the changes listed in the tree structure at the left-hand side of the CRM Application Composer UI. However, if there are ADF Business Components customizations, then users might need to log out and log back in again to see those changes reflected in the UI.
If you want to permit multiple users to work in multiple sandboxes, follow the guidelines in Section 2.2.1.3, "Guidelines for One Sandbox, Multiple Users," and these guidelines:
There can be any number of test-only sandboxes operating concurrently. That is, multiple users can use multiple sandboxes concurrently for testing if these sandboxes will never be published. Sandboxes that are used for testing only, and that are not published, cause no conflicts with each other. Be aware, however, that all modifications will be lost when the sandboxes are destroyed.
Note:
Even though sandboxes that are for test-only cause no conflicts with each other because they are not published, multiple users who work in the same test-only sandbox still must follow the guidelines in Section 2.2.1.3, "Guidelines for One Sandbox, Multiple Users."
For sandboxes that are not for test-only and will be published, you can have multiple concurrent sandboxes only if they operate on mutually exclusive artifacts. For example, you can have one sandbox that contains a page that is being customized to add a task flow, and another sandbox that contains a different page from a different application.
Note:
For CRM Application Composer, use only one sandbox at a time that is intended for publishing. You cannot have multiple concurrent sandboxes that are intended for publishing. You can still have other sandboxes that are test-only.
If an artifact is updated in both the mainline code and in the sandbox (or in two different sandboxes), when the sandbox is published, such conflicts are detected and an error is raised. At this point, administrators should cancel the publishing of the sandbox to avoid overwriting previous changes.
Note:
For a sandbox that contains ADF Business Components customizations, log out and log back in again after switching in or out of this sandbox to avoid any inconsistencies between the runtime caches and the ADF Business Components definitions.
Log out and log back in when you are performing any of the following sandbox-related actions:
Before entering a sandbox
After exiting a sandbox
After publishing a sandbox
After destroying a sandbox
When you create a sandbox, the currently available metadata is gathered into a sandbox session. You designate a sandbox to be the active sandbox by choosing either the newly created sandbox or selecting from a list of existing sandboxes in a table. The active sandbox is the context for all changes. After you activate the sandbox, you can make customization changes to the application artifacts and these changes will be stored in the sandbox. The sandbox uses a database to store the actual change information. After you are satisfied with the changes, you can publish the sandbox, or deploy the flexfield, and the changes will be merged into the mainline code and the sandbox will be archived.
To set up a sandbox:
Access the sandbox manager.
For non-flexfield sandboxes, you can access the sandbox manager by selecting the Manage Sandboxes menu item from the Administration menu in the global area of Oracle Fusion Applications.
Figure 2-5 shows the Manage Sandboxes menu selection from the Administration dropdown list.
For flexfields, you must be in the Manage Descriptive Flexfields task or the Manage Extensible Flexfields task and then select the Deploy Flexfield to Sandbox menu item to deploy the customizations to a flexfield sandbox. Flexfield changes are stored in flexfield metadata in the mainline database and are available to users only when the flexfield is deployed, as described in Section 5.7, "Deploying Flexfield Configurations." Thus for flexfields, the remaining tasks in this procedure do not apply.
In the Manage Sandboxes dialog, you can create a new sandbox, select from a list of sandboxes in the Available Sandboxes page, import a sandbox as a file, or perform other sandbox functions. Figure 2-6 shows a Manage Sandbox dialog with one available sandbox.
Create a new sandbox by clicking the New icon or selecting Actions then New
In the Create Sandbox dialog, enter a name for the sandbox. If you want a security-enabled sandbox, then select Create Data Security Sandbox and click Save and Close. Figure 2-7 shows the dialog with security enabled.
Note:
Because setting up the security sandbox requires duplicating the schema for Oracle Fusion Data Security tables, this will always be a lengthy operation in CRM Application Composer. Allow sufficient time for the process to be completed and do not to terminate it early. You may want to defer customizing security and enabling the security sandbox until you are sure that customizations are required.
You will see a confirmation dialog when the sandbox has been successfully created. Click OK to dismiss the dialog.
Identify the active sandbox. You can make the newly created sandbox or an existing sandbox the active sandbox.
In the Manage Sandboxes dialog, in the Available Sandboxes page, select the sandbox you want to make active and click Set as Active as shown in Figure 2-8.
Only one sandbox can be active at one time. The customization changes are captured in the active sandbox.
Export a sandbox.
A sandbox can be exported as a file for transporting, sharing, and other uses where packaging it as a file is required. Consequently, a sandbox exported as a file can be imported.
In the Sandbox Details dialog, click Download All. Enter the location and file name for the exported sandbox.
Import a sandbox.
In the Manage Sandboxes dialog, click Import.
In the Import dialog, click Browse to navigate to the file or enter the fully qualified file name.
Exit the sandbox.
Mouse over the sandbox name next to the Session Sandbox label in the global area of the Oracle Fusion applications to open a popup dialog, as shown in Figure 2-9. Click Exit Sandbox.
In the Exit Sandbox dialog, click Yes, as shown in Figure 2-10.
If there are changes to the mainline code from another source and you publish your sandbox, then the mainline code is not overwritten. If there are conflicts, then you will be warned and given a chance to fix the conflicts.
To publish a sandbox:
Make the customization changes to the application by going to the various customization environments. For example, you can create new objects and customize the objects in CRM Application Composer.
You can make metadata changes in the sandbox. Metadata changes are usually associated with MDS. These include making changes to a page, to Oracle ADF customization, and to Oracle ADF business objects. For more information about making changes to the page, see Chapter 3, "Customizing Existing Pages." For more information about making changes to business objects, see Chapter 4, "Customizing Objects."
You can make security changes by applying them to a security-enabled sandbox. You can test your security changes and policies before you publish the sandbox to commit the changes. For more information about customizing security policies, see Section 9.2, "Defining Security Policies for Custom Business Objects." For more information about custom business objects, see Chapter 15, "Customizing Security for ADF Application Artifacts."
Test or validate the changes in runtime using test or production systems and any combination of validation setups.
In the Manage Sandboxes dialog, click on the sandbox link to launch the Sandbox Details dialog. You can view the layers and objects where you have made customization changes, as shown in Figure 2-11.
Publish the sandbox to the mainline.
After you are satisfied with the changes, select the sandbox and click Publish in the Manage Sandbox dialog or in the Sandbox Detail dialog to commit the changes to the mainline.
You use the Manage Customizations dialog to view and diagnose runtime customizations that have been made to application pages.
By default, the Manage Customizations dialog displays the customizations that have been performed by the logged-in user. Administrators can optionally see the customizations made by other users.
Tip:
You can also use the Manage Customizations dialog to move customizations to another environment, for example from one test environment to another. For more information, see Section 2.4.1, "Downloading and Uploading Customization Files Using the Manage Customizations Dialog."
You need to do the following before you can use the Manage Customizations dialog:
You need to have specific privileges to access the Manage Customizations dialog. Please contact your security administrator for details.
To access the Manage Customizations dialog, choose Manage Customizations from the Administration menu in the global area.
Figure 2-12 shows the Manage Customizations dialog with all artifacts related to the CustomerCtrWorkarea.jsp file.
As shown in Figure 2-12, a customization was made to a page fragment file in the Site customization layer, and a customization was made to the UIShell Page Template in the external layer. By default, the customizations in the Current Context column show the customizations that the currently logged-in user would see in a running version of the application. All customizations, including those the currently logged-in user might not see (perhaps because of security policies), are listed in the All Layers column.
For example, say you are a customization developer. Because you as a user have been assigned a particular role, the page that you see will display only those customizations appropriate for your role. Those customizations will be listed in the Current Context column (provided you chose the proper layer from the Layer Name dropdown menu). This helps you to determine what customizations are affecting what you are seeing. There may, however, be customizations that you do not see. You can view those customizations from the All Layers column.
Sometimes, an administrator might need to view personalizations that were made by other users. For example, a user might have made an error while personalizing a page and that page no longer displays for the user. Because the user cannot display the page, the user cannot access the page to correct the error. In this case, the administrator can access the page, request to see the user's changes, and delete those changes to restore the page to its original settings.
To view customizations:
Go to the page for which you wish to view customizations.
From the Administration menu in the global area of Oracle Fusion Applications, choose Manage Customizations.
Tip:
After you are in the Manage Customizations dialog, you can change the page for which you are viewing customizations using the Search field.
From the Layer Name dropdown list for the Current Context column, select the customization layer for which you want to see the customizations as the user (or users) see it. For more information about customization layers, see Section 1.2, "Understanding Customization Layers."
If you have administrator privileges and you want to see the customizations for a user other than yourself, then select Select User from the Layer Name dropdown list for the All Layers column, and select the user. You can select multiple users by repeating this step.
Metadata labels identify the state of the objects in an MDS repository at a given point in time. Labels can serve as save points to which you can roll back your customizations if the customizations create problems. You roll back to a label by promoting that label to the tip.
To create a label across the entire MDS repository, use the createMetadataLabel Oracle WebLogic Scripting Tool (WLST) command as described in the "Creating Metadata Labels" section of the Oracle Fusion Middleware Administrator's Guide. You can also create a label when you save a customization in Page Composer.
To roll back all customizations, use the promoteMetadataLabel WLST command as described in the "Promoting Metadata Labels" section of the Oracle Fusion Middleware Administrator's Guide.
To roll back only the customizations for a specific page, use the Manage Customizations dialog accessed from Page Composer as described in the following steps. Note that when you use the Manage Customizations dialog, you are rolling back only the customizations for the page and its pageDef file. You are not rolling back the the other customizations made at the label's save point.
Note:
Some labels are created automatically. For example, customizations that are created in a sandbox are automatically labeled when the sandbox is published. You can identify an automatically-created label by its prefix. For a list of these prefixes, see the "Managing Oracle Fusion Applications-Specific Labels in the Oracle Metadata Repository" section in the Oracle Fusion Applications Administrator's Guide.
To promote a page's customizations to the tip:
Go to the page for which you wish to view customizations.
From the Administration menu in the global area of Oracle Fusion Applications, choose Customize page_name Pages to open the page in Page Composer.
In the tool bar, click Manage Customizations.
To promote a customization to the tip, click Promote for the corresponding artifact.
In the Promote Documents dialog, select the label that you want to promote to the tip and click OK.
As explained in Section 1.2, "Understanding Customization Layers," customizations are stored in an XML file. You can download the customizations into an XML file on your local machine and you can upload that file into other environments. You may need to download or upload a customization file for the following reasons:
You need to diagnose issues seen in the test environment.
You need to send files to Oracle Support Services for further diagnosing.
You want to import a customization into another environment. For example, a customization developer using JDeveloper might need to see customizations done by someone else.
You need to migrate a customization into a production environment, such as the production environment.
There are three ways you can download and upload customization files.
Using the Manage Customizations dialog.
Using Oracle WebLogic Scripting Tool (WLST) commands.
Using Oracle Enterprise Manager Fusion Applications Control.
When working with a specific customization, use the Manage Customizations dialog. When working with a set of customizations, use either the WLST commands or Fusion Applications Control. When migrating from one environment to another, such as from the full test environment to production, use Fusion Applications Control.
The Manage Customizations dialog enables you to upload and download customization files for a given page. Use the Manage Customizations dialog to upload or download minor customizations that affect only the customization file, such as disabling or hiding a field. For example, dropping a data control on the page affects the CPX file and changing text on the page affects resource bundles. If there is a possibility that the customization affected other files, use the WLST commands as described in Section 2.4.2, "Downloading and Uploading Customization Files Using WLST Commands" or use Fusion Applications Control as described in Section 2.4.3, "Downloading and Uploading Customization Files Using Fusion Applications Control."
If you manually edit the customization file before uploading it, ensure that the syntax of the edited contents is correct. Otherwise the uploading might produce incorrect instructions.
To download and upload customizations using the Manage Customizations dialog:
Go to the page for which you wish to download or upload customizations.
From the Administration menu in the global area of Oracle Fusion Applications, choose Manage Customizations.
Tip:
After you are in the Manage Customizations dialog, you can change the page for which you are viewing customizations using the Search field.
To download a file, click the Download link for the corresponding customization. The file will be downloaded to your local machine.
To upload a file, click the Upload link for the corresponding customization. In the Upload Customization dialog, click Choose File and select the appropriate file. Click OK to upload the file.
Note:
The name of the file you upload must be the same as the name of the file you are replacing.
To download all customizations of the page for all layers, click the Download Customizations for All Layers link, located at the bottom of the window. This will download the AllCustomization.zip file, which contains all the customization XML files for the page.
You can use WLST commands to upload and download customization files for one page, multiple pages, the navigator menu, and Oracle Application Development Framework (ADF) Business Components.
Note:
You can also use Fusion Applications Control to upload and download sets of customizations, as described in Section 2.4.3, "Downloading and Uploading Customization Files Using Fusion Applications Control."
Example 2-1 shows how to export all customizations for a specific application.
Example 2-1 WLST Command to Export All Customizations for an Application
exportMetadata (application='application name', server='server name', docs='/**', excludeBaseDocs='true', toLocation='temp location')
Example 2-2 shows how to export the site level customizations of the navigator menu.
Example 2-2 WLST Command to Export Site Level Customizations of the Navigator Menu
exportMetadata (application='application name', server='server name', docs='oracle/apps/menu/mdssys/Site/SITE/root_menu.xml.xml', toLocation='temp location')
For more information about uploading and downloading customization files, see Section 10.2.4, "Importing Customizations into Your Workspace." For information about uploading and downloading the customizations of resources, see Section 16.2, "Translating Resource Bundles from Metadata Services Metadata Repository."
For more information about the exportMetadata command, see the "Managing the Metadata Repository" chapter in the Oracle Fusion Middleware Administrator's Guide.
Use Fusion Applications Control to migrate customizations from one environment to another, such as from the full test environment to production. You can also use Fusion Applications Control to download and upload a set of customizations. For more information, see the "Transferring Metadata Using Fusion Middleware Control" section of the Oracle Fusion Middleware Administrator's Guide. The referenced procedure describes using Fusion Middleware Control, but also applies to Fusion Applications Control.
|
 Copyright © 2011, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
