This guide also applies to on-premises implementations

2Customization Life Cycle

This chapter contains the following:

Customization Life Cycle: Explained

All customizations and extensions to your application must be done in a full test environment. Typically, this environment contains one or more applications that will be moved to a production environment after you complete and test all customizations and extensions.

While using tools such as Page Composer, you can make application customizations in a sandbox. Sandboxes store customizations in Extensible Markup Language files in a separate Oracle Metadata Services repository that's available only when you work in that particular sandbox. You can make the changes in either of the following:

  • A test-only sandbox (that is, the code in the sandbox is for testing only, and is never deployed)

  • A sandbox that's then published to the full test 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. For more information on design time customization workflow, see the Oracle Fusion Applications Extensibility Guide for Developers.

Note: Design time customizations aren't available in Oracle Cloud implementations.

Project managers can monitor, import, and export customizations. Then, users can test the entire environment with all customizations, as shown in the figure below.

Customization workflow in a full test environment
Tip: For on-premise implementations, developers may allow users, having access to the Setup and Maintenance work area, to configure the customizations and extensions made to the application.

Run Time Customizations

Run Time Customization Workflow: Explained

While using Application Composer and Page Composer to make run time customizations to your application, use sandboxes to save your changes in a segregated environment. For example, before making customizations, suppose you create a sandbox named MySandbox, and then make your customizations in that sandbox. Now, if others want to see your customizations, they can use MySandbox.

Note: If you have multiple users working on the same sandbox, then conflicts may arise within a sandbox. Hence, users must adhere to the prescribed guidelines to avoid such conflicts.

You can also use a sandbox while defining security policies for custom objects that you have created using 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, others can review and approve your customizations, and then publish to the full test environment.

Note that a flexfield sandbox is for testing only and can't be published. Instead, you can 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. The changes that you deploy to a sandbox are isolated from the full test environment. Users who make the flexfield sandbox active in their session can only see these changes. After you're satisfied with the changes in the sandbox, you can deploy the changes to the full test environment.

You can also use the Manage Customizations dialog box to:

  • View others' customization metadata files

  • Download others' customization metadata files for manually moving them to another environment or diagnosing any issues

You can also upload others' customization metadata files to your environment.

This figure illustrates the use of sandboxes while:

  • Customizing pages, objects, and security using Page Composer and Application Composer

  • Configuring flexfields

The run time customization workflow

Viewing and Diagnosing Run Time Customizations: Points to Consider

Use the Manage Customizations dialog box to view and diagnose run time customizations made to application pages. Customizations are role-dependent and by default, the Manage Customizations dialog box displays the customizations that the signed-in user had performed.

Before you begin viewing customizations, ensure that you have administrative privileges to access the Manage Customizations dialog box. If you're unable to display the page that contains the customizations:

  1. Click your user name in the global area, and select Manage Customizations from the Administration menu.

  2. Use the Search text field on the Manage Customizations dialog box to search for the page, page fragment, or task flow.

You can view the customizations for a user under the Current Context column on the Manage Customizations dialog box. On this dialog box, you can change the page, page fragment, or task flow for which you're viewing customizations using the Search field.

Developers too may be assigned to specific roles and can view only those customizations that are permitted for the specific roles. However, administrators can view all customizations made at the site level, and for any user, under the All Layers column on the Manage Customizations page. To view customizations made by more than one user, administrators can select multiple users.

Sometimes, an administrator may need to view a personalization that was made by another end user. For example, suppose a user made an error while personalizing a page and that page is no longer displayed for the user. Because the user can't open the page, the user can't 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.

Page-Level Customizations

To diagnose customization issues, determine whether customizations have been applied to a page. Use the Manage Customizations dialog box to determine if page-level customizations exist. If a page customization causes problems, such as a user interface component disappears from a page, you can export the customizations and examine the document file.

Sandbox Manager

Managing Customizations Using Sandboxes: Explained

You can apply different types of customizations to an application. For example, you can apply changes to an application's metadata stored in the metadata services repository or changes related to data security of the application. All such customizations are stored in sandboxes and are validated before applying them to an application.

Types of Customizations in Sandboxes

Sandboxes can contain the following types of customizations:

  • Metadata changes - These changes (such as non-flexfield user interface (UI) page customizations) are captured in a metadata sandbox.

  • Data security changes - These changes are additionally captured in a data security enabled sandbox.

  • Changes in the generated flexfields business components - These changes are captured in a flexfield that's deployed as a single flexfield sandbox.

Once you're ready to make sandbox changes available in the mainline metadata, either publish the metadata or data security sandbox, or deploy the flexfield. You can download only metadata and data security sandboxes as a sandbox file for import to another application instance.

The following table lists the differences among the types of sandboxes.

Type of Changes Type of Sandbox Method for Making Changes Available in Mainline Metadata Downloadable?

Metadata

Sandbox

Publish sandbox

Yes

Data security

Sandbox enabled for data security changes

Publish sandbox

Yes

Flexfield

Flexfield deployed as a flexfield-enabled sandbox

Deploy flexfield

No

Only one sandbox can be active at a time. All changes made in an active sandbox are captured in that sandbox.

Environment

To customize your application in run time, you must first create a sandbox and then use tools, such as Page Composer to make the customizations. These changes remain within the sandbox and don't affect the mainline metadata. You can test and validate the changes by publishing the sandbox to a full test environment. After testing the application, you can move to the production environment. The customizations created in the sandbox will be migrated to the production environment and will be available to the users.

Don't make customizations directly in the mainline metadata. Make all customizations first in the sandbox. When you make changes to an application at run time in a sandbox, you isolate the changes from the mainline metadata. After completing the changes in the sandbox, verify them. When you're ready to save the changes, publish the metadata or security-enabled sandbox to the mainline metadata.

When you create a sandbox, you can only see the customization information of the existing customizations in the current mainline metadata. For example, suppose you do customization in a sandbox and publish it. Then, on creating another sandbox for the next customization, you will see customization1 in the new sandbox because customization1 exists in the current mainline metadata.

Flexfield sandboxes are for testing only and can't be published. Make flexfield configurations that are stored in a database. Then, deploy those configurations to a sandbox to see the resulting deployment artifacts in a sandbox environment. Flexfields are deployed directly to the mainline metadata using the flexfield user interface.

Tools

You can use several run time tools to customize the application. For example, you can customize objects and pages using Page Composer, which uses sandbox manager. Oracle Business Process Composer and Oracle SOA Composer are also run time customization tools, but they don't use sandbox manager. They have their own mechanisms for handling customization changes.

Metadata sandboxes that you create using sandbox manager are available in Oracle JDeveloper while creating and deploying customizations for a deployed application in Oracle WebLogic Server. During deployment, the available sandboxes (except security sandboxes) appear in a selection list in Oracle JDeveloper. Oracle JDeveloper is not available in Oracle Cloud implementations. You can save, download, and import the metadata sandbox sessions as files into other applications.

Managing a Flexfield Sandbox

To create a flexfield-enabled sandbox, deploy one flexfield to a sandbox using the Manage Flexfield task flow. The flexfield sandbox gets its name from the flexfield you deploy. You can't test two flexfields in the same sandbox. After deploying a flexfield as a sandbox, sign out and sign in again to view how the sandbox run time reflects the flexfield changes, such as new segments. You can redeploy the same flexfield to the same sandbox repeatedly as you make incremental changes to the flexfield setup. A flexfield sandbox can't be published. So, when the flexfield is deployed to the mainline metadata, any page customizations or data security in the flexfield sandbox can't reach the mainline metadata. If you're entitled to do so, manage flexfield-enabled sandboxes in the Sandbox Manager.

Using Sandboxes: Points to Consider

In the customization run time workflow, use sandboxes to isolate the changes from the mainline metadata for testing and validating. After you're satisfied with the changes, you can publish the changes back to the mainline metadata.

You can create two types of sandboxes:

  • Sandboxes that are intended for testing purposes only

  • Sandboxes that are intended to be published

The testing sandboxes are never published and therefore produce no concurrency conflicts between sandboxes. You can have several testing sandboxes at the same time. But if you have multiple users working on the same testing sandbox, then they must adhere to the prescribed guidelines.

Customizations in the sandboxes that are published are merged back to the mainline metadata. The following figure illustrates the two types of sandboxes and their relationship to the mainline metadata.

Types of sandboxes

Working with a Single Sandbox

When multiple users are customizing an application using the same sandbox at the same time, conflicts within a sandbox may arise. This conflict may arise because multiple users attempt to customize the same artifact or perform customization tasks that indirectly affect other shared files. For example:

  • A direct conflict arises when different users attempt to customize the same page, fragment, or metadata file within the same layer.

  • An indirect conflict arises when two users, each creating a different object, save their changes at the same time. This conflict occurs in the metadata file that tracks which new objects both users created while saving their changes.

Conflicts may also arise when users edit a shared artifact, such as when a user performs an operation that adds or edits a translatable string. For example, say:

  • One user edits a field's display label or help text, or a validation rule's error message. Whereas, another user performs an operation at the same time that similarly affects translatable strings.

  • Two or more users are working in navigator menus that are shared across applications. Whenever a customization conflict arises among users, the application displays concurrency warning messages.

Whether the sandbox is meant for testing or production, if multiple users work with a single sandbox, follow these guidelines to avoid conflicts:

  • 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 must not update object1. Suppose both modifications involve changes to translatable strings, and the users save changes to separate objects at the same time. Even then, a conflict can occur in the resource bundle that stores the translatable strings.

  • If multiple users update the same artifact (same object or same underlying frequently modified file) concurrently, then they'll get a concurrent update error. The second user's updates won't be saved (the Save button will be disabled), and one of the users will have to cancel and try again.

  • All users using the same sandbox should have the same application role. Users with different roles might not be able to see all content created by other users within the sandbox.

Working with Multiple Sandboxes

Multiple sandboxes are used when customizations are stored in testing as well as production sandboxes. Say, after you create a sandbox, a concurrent change is made in the mainline metadata. Now, when you attempt to publish that sandbox, the application detects such conflicts at publication time, and you get error messages.

Note: When you publish your sandbox, you may get a message showing a conflict on oracle/apps/menu/fnd/applcore/dataSecurity/dataSecurityService/mds/DSMO.xml. This message indicates that the security changes that you made in your sandbox conflict with other security changes in the mainline metadata. Delete the sandbox and recreate your changes in a new sandbox.

If multiple users are permitted to work in multiple sandboxes at the same time, follow these guidelines to avoid conflicts:

  • Any number of test-only sandboxes can operate 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 aren't published, cause no conflicts with each other. Be aware, however, that all modifications will be lost when the sandboxes are destroyed.

  • For sandboxes that aren't for test-only and will be published, users can use multiple concurrent sandboxes only if they operate on mutually exclusive artifacts. For example, you can have:

    • One sandbox that contains a page that a user is customizing to add a task flow

    • Another sandbox that contains a different page from a different application

    However, some objects might still share underlying artifacts, and thus it's not always obvious if two objects are truly mutually exclusive. Thus, proceed with caution when using multiple concurrent sandboxes that will be published. It's still possible that a conflict could occur, which would require the deletion of one or more sandboxes.

  • Suppose the users update an artifact in both, the mainline metadata and in one sandbox, or in two different sandboxes. Now, when you publish the sandbox, the application detects such conflicts and you get an error message. At this point, cancel publishing the sandbox to avoid overwriting previous changes.

Note: For a sandbox that contains ADF Business Components customizations, sign out and sign in again after switching in or out of this sandbox. This process ensures avoiding any inconsistencies between the run time caches and the ADF Business Components definitions.

Setting Up Sandboxes: Procedure

To make customizations to the application artifacts, you need to first store them in an active sandbox. You can either create a sandbox or select an existing sandbox, and designate it as an active sandbox. The active sandbox holds the context for all the changes. The sandbox uses a database to store the actual changes. After testing your changes, you can publish the sandbox, or deploy the flexfield, and the changes are merged into the mainline metadata. Eventually, the sandbox is archived.

The following procedure is for setting up non-flexfield sandboxes. For flexfields, use the Manage Descriptive Flexfields task or the Manage Extensible Flexfields task.

Caution: Do not import or delete metadata files. These operations modify sandbox contents and could cause issues with the sandbox functionality.

To create a sandbox and set it up:

  1. Click your user name in the global area, and select Manage Sandboxes from the Administration menu.

  2. Use the Manage Sandboxes dialog box to create a sandbox.

  3. Click Save and Close.

  4. On the Manage Sandboxes dialog box, select the new sandbox or an existing one, and click Set as Active. The sandbox is designated as the active sandbox.

  5. Close the Manage Sandboxes dialog box.

Publishing Sandboxes: Procedure

After completing the customizations in the sandbox, publish them to make them available in the application.

Prerequisites

Before publishing the customizations, test or validate the changes at run time using test systems and any combination of the validation setups.

If there are changes to the mainline metadata from another source and you publish your sandbox data, then the mainline metadata isn't overwritten. However, if you get error messages notifying about conflicts, then you must fix the conflicts before publishing.

Publishing Sandboxes

To publish a sandbox:

  1. Click your user name in the global area, and select Manage Sandboxes from the Administration menu.

  2. On the Manage Sandboxes dialog box, select the sandbox and click Publish. The Publish confirmation message box appears.

  3. Click Yes. The sandbox is published to the mainline metadata.

  4. Close the Manage Sandboxes dialog box.

Moving Customizations

Using Customization Migration to Move Customizations: Points to Consider

Use the Customization Migration page to create a set of all customizations and extensions made to an application environment. Then, download the customization set and upload it into another environment. The customization set includes customizations across all product families. To open the Customization Migration page, select Tools - Migration from the Navigator menu.

Contents of the Customization Set

The customization set includes:

  • Customizations done using Application Composer, except the following customizations:

    • Object artifacts that were generated from the Import and Export page in Application Composer to make extensions available for importing and exporting

    • User names and passwords for secured SOAP web service connections

    • The enabled attachment feature for custom objects

  • Customizations done using:

    • Page Composer

    • Appearance page

    • Structure page

    • User Interface Text page

    • Page Integration Wizard page

  • Changes in the following artifacts of the Applications Core Setup application:

    • Messages

    • Lookups

    • Data security

    • Descriptive, extensible, and key flexfields, and value sets

    • Attachment categories and entities

  • Changes in scheduled processes

  • Customizations done using the Manage Oracle Social Network Objects task

  • Changes in security settings made in Application Composer

    Note: Enterprise roles, new duty roles, and role hierarchy changes, which are made directly in Security Console aren't migrated.
  • Customizations done using Oracle Business Intelligence Enterprise Edition, including but not limited to:

    • Oracle Business Intelligence Answers

    • Oracle Business Intelligence Delivers

    • Business Intelligence Composer

    • Dashboard Builder

    • Oracle Business Intelligence Publisher

    Note: You can move the customizations done using the business intelligence tools only if the Disable BI for Customization Set Migration profile option is set to No.

The customization set doesn't include personalizations.

While an upload or restore activity processes Presentation Services customizations, the following can occur:

  • Reports that were submitted by Oracle Enterprise Scheduler to Oracle Business Intelligence Publisher and were scheduled to execute during the process, will fail.

  • The Reports and Analytics pane doesn't display.

  • Oracle Business Intelligence Publisher reports may not display on Oracle Business Intelligence Presentation Services analyses or dashboard pages.

  • Users may not be able to access Oracle Business Intelligence Enterprise Edition features, such as:

    • Oracle Business Intelligence Answers

    • Oracle Business Intelligence Delivers

    • Business Intelligence Composer

    • Oracle Business Intelligence Interactive Dashboards

Some important points to consider are:

  • The customization migration doesn't include code extensions, such as managed beans, that you implement in Oracle JDeveloper using the applications developer role. These code extensions are stored in the app-inf/lib and web-inf/lib directories and you must manually move the extensions.

    Note: Oracle JDeveloper isn't available in Oracle Cloud implementations.
  • The type of customizations across all applications that will be added to the customization set are selected by default on the Customization Migration page. You can't change this selection.

  • To prevent including in-progress customizations in the customization set, make your customizations in a sandbox. The customization set doesn't include customizations from a sandbox until the sandbox is published.

You can use the Customization Migration page to move customizations and extensions from any source environment to any target environment. However, you must always perform your customizations and extensions in a full test environment. Then use the Customization Migration page to move these changes to a production environment. As customization set migration doesn't provide a merge capability, never customize or extend a production environment. When you import a customization set, the rows in the database that are not preconfigured are updated if a matching record exists. Otherwise a record is inserted.

The customization set doesn't include all deletions. For example, the set does not include the removal of a customization document using the Manage Customizations dialog box. After you import a customization set into the target environment, you must examine the environment for any deletions that you must make manually. Similarly, the customization set does not include roles or role hierarchy changes. Changes made to Security Console have to be manually updated in the target environment.

Creating and Applying Customizations Using a Customization Set: Procedure

Create a customization set to move customizations across all the product families of the application from one environment to another. You can export all customizations, such as those stored in Oracle Metadata Services repository, JEDI, CRM, and BI using the Outgoing tab of the Customization Migration page. You can then import them to the target environment using the Incoming tab. You can use a customization set to move customizations in a batch instead of moving them one by one.

Prerequisites

Before creating a customization set, ensure that:

  • The source and target application environments are of the same release and the same standard and one-off patches are applied to both environments.

  • All Page Composer and Oracle JDeveloper (not available in Oracle Cloud implementations) customizations made in sandboxes are complete before they're published. Before starting the export process, you must publish all complete customizations. All customizations and extensions made using the Structure page, the Manage Standard Lookups task, and Security Console, are complete.

  • To move content created using Oracle Business Intelligence Enterprise Edition features, the Disable BI for Customization Set Migration profile option is set to No in source and target environments. To view this profile option, open the Manage Profile Options task in the Setup and Maintenance work area.

  • You have been granted the following privileges, which enable you to access the Customization Migration page:

    • FND_MANAGE_OUTGOING_CUSTOMIZATION_SET_PRIV

    • FND_MANAGE_INCOMING_CUSTOMIZATION_SET_PRIV

    Contact your security administrator for details.

  • You never make customizations in the target or production environment while applying customizations.

Note: If you make customizations to the production environment in emergency circumstances, you must make the same customizations to the test environment. Making the customizations to the test environment ensures that the customizations are included in the next customization migration.
  • You don't perform customizations in the source environment during the export process.

Creating Customizations

To create customizations:

  1. In the source environment, select Tools - Migration from the Navigator menu.

  2. From the Outgoing tab of the Customization Migration page, click Create Customization Set.

    Tip: If the Delete button appears for an existing customization set, click the button. This action removes the temporary files that are on the server from the previous customization set creation. You can't create a customization set until the previous set has been deleted.
  3. Provide a name for the customization set.

  4. Optionally, type a description of the set.

  5. Click Save and Close.

  6. Periodically, click Refresh to view the current status of the set creation. Eventually, the status changes to Ready for Download.

    To see the detailed status of each customization type, expand Customization Details.

    The process runs asynchronously. You can close the dialog box and return to it later.

  7. Click Download, and specify the name and location for the file, and click Save. Ensure that the downloaded file is a JAR file.

  8. After you download the file on your local file system, click Delete to remove the temporary files that were created on the server.

Applying Customizations

After you apply customizations, end users must sign out and sign in again to see the changes. Hence, apply customizations when a few people are signed into the environment. To apply customization to the target environment, follow these steps:

  1. Open the Customization Migration page in the target environment.

  2. From the Incoming tab, click Browse, specify the name and location of the customization set file, and click Open.

    If the Browse button appears disabled, click Delete to remove the previously uploaded customization set from the environment and enable the Browse button.

  3. When the status for the customization set is Ready to Apply Customizations, click Apply.

  4. Periodically, click Refresh to view the current status of the Apply action.

    The process runs asynchronously. You can close the dialog box and return to it later.

    For Oracle Cloud implementations, if problems occur during an Apply action, log a service request using My Oracle Support at https://support.oracle.com.

  5. Access the target environment and examine the environment for any deletions that you must manually make.

  6. Deploy all flexfields that display a Patched status.

  7. Perform the following steps to send the new and updated social network definitions to the social network server:

    1. In the Setup and Maintenance work area, open the Manage Oracle Social Network Objects task.

    2. As part of the applying customizations process, some objects are created or updated. If the Enabled value of such an object is anything other than No, trigger the process of sending its definition to the social network server. You can do it by disabling the object and enabling it again with its original status. For example, if the Enabled value is Manual, then:

      1. Disable the object.

      2. Enable the object, and select the value, Manual.

      3. Click OK and save the changes.

  8. Manually migrate all business processes created in the source environment to the target environment.

  9. After applying customizations, perform functional testing to verify the changes. Suppose testing exposes problems with the customizations, such as importing more than you intended, or the changes weren't what you expected. In such cases:

    1. Open the customization set in the Incoming tab of the Customization Migration page.

    2. Click Restore to revert to the state before the customization set was applied.

      Skip the next step in such cases.

    You can view the process log to monitor the progress of the download or the applying process. This process takes approximately 15 minutes. If it takes any longer and you don't see any progress, click Refresh. You can either let the server take its time and click Continue, or click Restart to restart the export process.

    Following are some important points regarding customization import and export:

    • After an environment upgrade, any previous imports which were performed in an earlier release can't be reverted. However if a new import is submitted in the upgraded instance, then the most recent import can be reversed.

    • Lookup values for lookup fields that exist in both source and target aren't overwritten during the customization import. The lookup values from source are added to the target and all the lookup values coexist for the same field. For example, the Status field in its source environment has values, Open and Closed. In the target environment this field has values, Yes and No. After the import, the Status field in the target environment has values, Open, Closed, Yes, and No.

    • After importing, perform the following steps in the target environment to send the new and updated social network definitions to the social network server.

      1. In the Setup and Maintenance work area, open the Oracle Social Network Objects task.

      2. On the Oracle Social Network Objects page, click Synchronize to synchronize a selected object, or click Synchronize All to synchronize all objects together.

    • During customization import, the data security privileges aren't automatically revoked in the target environment. For example, say a specific privilege is granted in the target environment, but the corresponding privilege doesn't exist in the source environment. During import, the privilege in the target environment won't be automatically revoked. To address this issue manually, add such a privilege to the source environment and revoke it. The revoke action is picked up as a customization instance during the customization import process and applied to the target environment.

    • You can create custom reports directly in the target environment. However, ensure that you create the custom reports and reference them to the existing custom subject areas. Don't create the custom subject areas directly in the target environment.

    • You can initiate customization export and import tasks only from the mainline metadata. If you initiate customization from a sandbox, the process doesn't execute.

    Caution: All user personalizations that are performed after a customization set is applied are lost when you perform a restore action on that customization set.
  10. Broadcast information to the users that they must sign out and sign in to view the most recent changes.

Exporting and Moving Customizations: Points to Consider

Customizations are stored in XML files. You can use these XML files to export customizations for the following reasons:

  • To move customizations and extensions to another environment, such as the production environment.

  • To diagnose issues noticed in the test environment.

  • To send files to your help desk for further diagnosing.

  • To import a customization into another environment. For example, a customization developer using Oracle JDeveloper may see customizations that other users do.

The following table lists the tools to use to export and move customizations and extensions.

Tasks Tools to Use

Move all customizations to another application environment.

Customization Migration.

Move only Oracle Metadata Services customizations made to pages and the user interface to another application environment.

Enterprise Manager Cloud Control.

You can also use Enterprise Manager Cloud Control to download and upload a set of customizations.

Move only descriptive flexfield configurations to another application environment.

Setup and Maintenance work area. Moves configurations for a specified module.

To move configurations for all modules, use Customization Migration.

Move only extensible flexfield configurations to another application environment.

Setup and Maintenance work area. Moves configurations for a specified module.

To move configurations for all modules, use Customization Migration.

Move only value set configurations to another application environment.

Setup and Maintenance work area. Moves configurations for a specified module.

To move configurations for all modules, use Customization Migration.

Move only lookups to application environment.

Setup and Maintenance work area. Move application standard lookups, application common lookups, or both.

Move only data security policies to another application environment.

Setup and Maintenance work area.

It doesn't move Oracle Fusion Human Capital Management roles.

Export customizations to a file to help diagnose an issue.

Manage Customizations dialog box.

Export customizations to import them into an application workspace in Oracle JDeveloper.

Manage Customizations dialog box.

Note: Enterprise Manager Cloud Control isn't available in Oracle Cloud implementations. Therefore, in Oracle Cloud implementations, to perform tasks that require use of Enterprise Manager Cloud Control, log a service request using your help desk at https://support.oracle.com.

Downloading Customizations

Use the Manage Customizations dialog box to download customization files for a given page. You can also upload the files into the Oracle Metadata Services repository using the same dialog box. To open Manage Customizations dialog box, click your user name in the global area, and select Manage Customizations from the Administration menu. You can use these files for diagnosing customization issues.

You can also download all customizations of a page for all layers (AllCustomization.zip) using the Download Customizations for All Layers link. This link is located at the bottom of the Manage Customizations dialog box. The AllCustomization.zip file contains all the customization XML files for the page. However, you can't upload this file anywhere.

Downloading Customization Set Reports

After exporting customizations, you can view and download a customization set report that contains a list of all customizations available in a customization set. To do so, click Content Read Me from the Outgoing tab of the Customization Migration page. To open the Customization Migration page, select Tools - Migration from the Navigator menu.

The customizations in this report include all:

  • Custom objects

  • Custom fields

  • Custom pages

  • Business intelligence (BI) changes

Business logic changes such as Groovy scripts and triggers aren't included in the customization set report.

Viewing and Deleting Customizations: Procedure

Use the Manage Customizations dialog box to view the customizations made to the application pages and to delete unwanted customizations. Click your user name in the global area, and select Manage Customizations from the Administration menu.

Deleting Customizations

To delete customizations:

  1. On the page that contains the customizations, select the page fragment or task flow, and then select Manage Customizations from the Administration menu.

  2. In the Name list, select the correct layer, and find the page, task flow, or fragment that contains the customizations.

  3. Click Delete for the customization document that you want to delete.

Advanced Customization Life Cycle Tasks: Highlights

You can perform design time tasks as part of the customization life cycle.

Note: These customization tasks aren't available in Oracle Cloud implementations.

Customization Tasks