| Oracle® Fusion Applications Extensibility Guide for Business Analysts 11g Release 7 (11.1.7) Part Number E16691-12 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Extensibility Guide for Business Analysts 11g Release 7 (11.1.7) Part Number E16691-12 |
|
|
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 an environment that is separate from the full test environment, publish the changes to a full test environment, and move the changes to other environments.
This chapter includes the following sections:
Note:
For Oracle Cloud implementations, check the Oracle Cloud documentation to determine which Oracle Fusion Applications versions are supported by that Oracle Cloud implementation.
All customizations and extensions to Oracle Fusion Applications should be done in a full test environment, as shown in Figure 2-1. 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 Oracle Fusion CRM Application Composer (Application Composer) make their application customizations in a sandbox. Sandboxes store the customizations in isolated, protected Oracle Metadata Services (MDS) labels that are 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 full test environment.
After testing, you can then move the customizations to the mainline code as described in Section 2.3, "Exporting and Moving Customizations."
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 task flows for setup activities for extensions, see the Oracle Fusion Functional Setup Manager Developer's Guide.
When you use Application Composer and Page Composer to make runtime customizations to Oracle Fusion applications, you use sandboxes to save your changes in an isolated 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 also use a sandbox when you define 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 validate the sandbox. Then you can publish the sandbox 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:
A flexfield sandbox is 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 4.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 as described in Section 2.1.1.1.3, "Backing Out Customizations."
You can also use the Manage Customizations dialog to view others' customization metatdata files, and to download those files to diagnose any issues. For more information, see Section 2.1.1.1, "Viewing and Diagnosing Runtime Customizations."
Note:
The navigator menu, Business Process Modeling Notation (BPMN) process flows, and report customizations do not use an MDS repository. See Chapter 5, "Customizing Menus," Chapter 6, "Customizing and Extending BPMN Processes ," and Chapter 7, "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 Application Composer and when configuring flexfields.
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 export customizations for diagnostic purposes. For more information, see Section 2.3.3, "Using the Manage Customizations Dialog to Download Customizations."
You must do the following before you can use the Manage Customizations dialog:
You must have specific privileges to access the Manage Customizations dialog. 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-3 shows the Manage Customizations dialog on a desktop page with all artifacts related to the CustomerCtrWorkarea.jsp file.
Note:
When viewing the Manage Customizations dialog from a simplified page, you can see only the top-level nodes and you cannot expand them.
As shown in Figure 2-3, a customization was made to a page fragment file in the site layer, and a customization was made to the UIShell Page Template in the external layer (the external layer is a layer that is specific to Oracle Fusion Customer Relationship Management applications). 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 a personalization that was made by another end user. For example, a user might have made an error while personalizing a page and that page is no longer displayed for the user. Because the user cannot access the page, the user cannot 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.
Select the task flow or page fragment that contains the 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, page fragment, or task flow 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 making that label become the latest version. This action is often referred to as promoting the label to the tip.
Note:
You cannot promote design time customizations. If a design time customization is causing a problem, you must undeploy the changes, fix the issues, and then redeploy to a sandbox.
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.
Note:
WLST is not available in Oracle Cloud implementations.
To roll back 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 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.
Note:
The functionality described in this section is not available in Oracle Cloud implementations.
For information about the design time customization workflow, see the Oracle Fusion Applications Extensibility Guide for Developers.
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 4.7, "Deploying Flexfield Configurations."
To customize an Oracle Fusion application in runtime, you must first create a sandbox and then use Page Composer or 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. The customizations created in the sandbox will be migrated to the production environment and will be available to users of the system.
You 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. 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. If customizations existed in the mainline code before the sandbox was created, you will see the customization information in the sandbox. If you add customizations to the mainline code after a sandbox has been created, you will not see the newly added customizations in the sandbox. You will need to exit, publish, or destroy the sandbox and create a new sandbox to see the customizations that were newly added 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 4.7, "Deploying Flexfield Configurations."
You can use runtime tools to customize the application. The sandbox manager works with Application Composer and Page Composer to customize objects and pages:
For information about using Application Composer, see the "Application Composer: Introduction" chapter in the Oracle Fusion Applications CRM Extensibility Guide.
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 6, "Customizing and Extending BPMN Processes ."
For information about using Oracle SOA Composer, see the "Customizing and Extending SOA Components" chapter in the Oracle Fusion Applications Extensibility Guide for Developers.
For non-Cloud implementations, a metadata sandbox that you create using the sandbox manager is 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 the "Deploying Oracle ADF Customizations and Extensions" section in the Oracle Fusion Applications Extensibility Guide for Developers. Note that the security sandboxes created using the sandbox manager are not available in JDeveloper.
In Application Composer, you 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 that 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, you use sandboxes 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."
Note:
Features or functionality described in this note are not available in Oracle Cloud implementations.
When a sandbox intended for publishing is active, do not use Oracle Enterprise Manager Fusion Applications Control or Oracle WebLogic Scripting Tool (WLST) commands to import any metadata documents into the mainline code. The imported metadata may be in conflict with the changes made in the sandbox. For more information, see the "Transferring Metadata Using Fusion Middleware Control" section of the Oracle Fusion Middleware Administrator's Guide.
If you need to import multiple customizations available in the metadata repository for an application, you can use the exportMetadata WLST command. For more information, see the "Application Metadata Management Commands" section of Oracle Fusion Middleware WebLogic Scripting Tool Command Reference. This command saves the customization files in a JAR file that you can import into your workspace. For more information about procedures, see the "Viewing ADF Library Runtime Customizations from Exported JARs" section of the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
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, you must 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 "A Few Notes About Concurrent Users" section of the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.
When you are using Application Composer, you must also use a sandbox. 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 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. For example, these types of conflicts can also occur with shared metadata files such as a resource bundle that stores translatable strings.
Note:
You should force-publish a sandbox only when there is no other option available. Typically, if you encounter a conflict during publishing, you should delete the sandbox, create a new sandbox, re-enter your changes and try publishing again.
If there is a concurrent change made in the mainline code after the sandbox was created and the user attempts to publish that sandbox, then such conflicts are detected at publication time and error messages occur.
Tip:
If you encounter a message showing a conflict on oracle/apps/menu/fnd/applcore/dataSecurity/dataSecurityService/mds/DSMO.xml when you publish your sandbox, this means the security changes that you made in your sandbox conflict with other security changes in the mainline code. Abort the sandbox and recreate your changes in a new sandbox.
Regardless of whether the sandbox is intended for publishing or for test-only, if multiple users are allowed 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.
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 commit operations 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 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 Application Composer UI. However, if there are ADF Business Components customizations, then users might need to sign out and sign back in to see those changes reflected in the UI.
If multiple users are permitted to work in multiple sandboxes, the guidelines in Section 2.2.1.3, "Guidelines for One Sandbox, Multiple Users," and follow 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, multiple concurrent sandboxes can be used 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 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, cancel publishing of the sandbox to avoid overwriting previous changes.
Note:
For a sandbox that contains ADF Business Components customizations, sign out and sign back in after switching in or out of this sandbox to avoid any inconsistencies between the runtime caches and the ADF Business Components definitions.
Sign out and sign 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 nonflexfield 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 database and are available to users only when the flexfield is deployed, as described in Section 4.7, "Deploying Flexfield Configurations." Thus for flexfields, the remaining steps 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 Application Composer. Allow sufficient time for the process to be completed and do not terminate it early. You may want to defer customizing security and enabling the security sandbox until you are sure that customizations are required.
When the sandbox has been created successfully, a confirmation dialog appears. 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 application 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 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 objects. For more information about making changes to the page, see Chapter 3, "Customizing Existing Pages." For more information about making changes to objects, see the "Defining Objects: Explained" section in the Oracle Fusion Applications CRM Extensibility Guide.
You make security changes by applying your changes to a security-enabled sandbox. Test your security changes and policies in the sandbox before you commit the changes by publishing the sandbox. For more information about customizing security policies, see the "Securing Custom Objects: Explained" section in the Oracle Fusion Applications CRM Extensibility Guide.
For more information about security in custom business components in non-Cloud implementations, see the "Customizing Security for Oracle ADF Application Artifacts" chapter in the Oracle Fusion Applications Extensibility Guide for Developers.
Test or validate the changes at runtime using test or production systems and any combination of validation setups.
In the Manage Sandboxes dialog, click the sandbox link to open 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 code.
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 code.
There are several tools available for exporting and moving customizations. These tools enable you to perform the following tasks:
Move customizations and extensions to another Oracle Fusion Applications environment, such as the production environment.
Diagnose issues seen in the test environment.
Send files to Oracle Support Services for further diagnosing.
Import a customization into another environment. For example, a customization developer using JDeveloper might need to see customizations done by someone else.
Table 2-1 lists the tools to use to export and move customizations and extensions.
Note:
Oracle WebLogic Scripting Tool (WLST) and Oracle Enterprise Manager Fusion Applications Control (Fusion Applications Control) are not available in Oracle Cloud implementations. For Oracle Cloud implementations, to complete the tasks in Table 2-1 that require use of WLST commands or Fusion Applications Control, log a service request using My Oracle Support at https://support.oracle.com.
Table 2-1 Tools to Use for Exporting and Moving Customizations
| Task | Tools to Use |
|---|---|
|
Move all customizations described in Section 2.3.1, "Using Customization Set Migration to Move Customizations" to another Oracle Fusion Applications environment. |
Customization Set Migration. |
|
Move only MDS customizations made to pages and the user interface to another Oracle Fusion Applications environment. |
WLST commands or Fusion Applications Control. |
|
Move only descriptive flexfield configurations to another Oracle Fusion Applications environment. |
Oracle Fusion Functional Setup Manager (Functional Setup Manager). Moves configurations for a specified module. To move configurations for all modules, use Customization Set Migration. |
|
Move only extensible flexfield configurations to another Oracle Fusion Applications environment. |
Functional Setup Manager. Moves configurations for a specified module. To move configurations for all modules, use Customization Set Migration. |
|
Move only value set configurations to another Oracle Fusion Applications environment. |
Functional Setup Manager. Moves configurations for a specified module. To move configurations for all modules, use Customization Set Migration. |
|
Move only lookups to another Oracle Fusion Applications environment |
Functional Setup Manager. Move application standard lookups, application common lookups, or both. |
|
Move only data security policies to another Oracle Fusion Applications environment. |
Functional Setup Manager. Note that this does not move Oracle Fusion Human Capital Management roles. |
|
Export customizations to a file to help diagnose an issue. |
WLST commands or Manage Customizations dialog. |
|
Export customizations for import into an application workspace in JDeveloper. |
WLST commands or Manage Customizations dialog. |
The Customization Set Migration dialog enables you to move customizations and extensions from one Oracle Fusion Applications environment to another. You create a set of all customizations and extensions that have been made to the source environment, download the customization set, upload it into another (target) environment, and then apply the customizations that are in the set to that environment. Should you need to back out the customizations that you have applied, you can restore the environment to the state that it was in before you applied the customizations.
Note:
The Customization Set Migration dialog is to be used to move customizations from one environment to another. It is not a tool for backing up and restoring customizations in the same environment.
After you have downloaded a customization set from the source environment, you must compact the set to remove the temporary files that were created during the create process. After you apply a customization set on the target environment, you must compact it to remove the temporary files that were created when you uploaded it into the target environment.
The customization set includes customizations across all Oracle Fusion Applications product families, such as Oracle Fusion Financials, Oracle Fusion Customer Relationship Management (Oracle Fusion CRM), and Oracle Fusion Human Capital Management (Oracle Fusion HCM).
The customization set includes only the customizations and extensions that you make using the following tools and features. Personalizations are not included in the set. (For the definitions of customization, extension, and personalization, see Section 1.1, "Understanding Customizing and Extending Oracle Fusion Applications.")
Application Composer, with the exception of 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 as described in the "Importing and Exporting Custom Objects: Explained" section in the Oracle Fusion Applications CRM Extensibility Guide.
Email templates, as described in the "E-Mail Templates: Explained" section in the Oracle Fusion Applications CRM Extensibility Guide
Submitted custom subject areas that are available from Oracle BI Composer and Oracle Business Intelligence Answers, as described in the "Publishing Custom Subject Areas: Explained" section in the Oracle Fusion Applications CRM Extensibility Guide.
User names and passwords for secured SOAP web service connections.
The enabling of the attachment feature for custom objects.
Note:
The steps in this section include steps for manually moving the customizations and extensions that are described in the preceding bulleted list.
Page Composer
Tasks and dialogs for configuring descriptive and extensible flexfields and value sets
Manage Menu Customizations task
Manage Oracle Social Network Objects task
Manage Standard Lookups task
Data security policies created or customized using Oracle Authorization Policy Manager
For non-Cloud implementations, customization metadata that is created from JDeveloper using the Oracle Fusion Applications Administrator Customization role and then packaged and deployed to the source Oracle Fusion Applications environment as described in the "Using Oracle JDeveloper for Customizations" chapter in the Oracle Fusion Applications Extensibility Guide for Developers.
Notes:
The Customization Set does not include code extensions, such as managed beans, that you implement in JDeveloper using the Oracle Fusion Applications Developer role. These code extensions are deployed into the application as a library JAR file and must be redeployed manually into each target environment.
Tip:
To prevent including in-progress customizations in the customization set, always make Application Composer, Page Composer, and JDeveloper customizations in a sandbox. The customization set does not include customizations that are in sandboxes.
WARNING:
During the time that an apply or restore is processing Oracle Fusion CRM customizations and extensions, the following issues can occur for approximately 5 minutes of the processing time:
End users can sign in, but they might receive page-not-found (404) errors when they access dashboard and work area pages.
Oracle Enterprise Scheduler jobs that are running or scheduled to run during that time might fail. For information about viewing scheduled processes, see Before you begin: in this section.
While you can use the Customization Set Migration dialog to move customizations and extensions from any source environment to any target environment, you should always perform your customizations and extensions in a full test environment and use the Customization Set Migration dialog to move these changes to a production environment, as illustrated in Figure 2-1 and Figure 2-2. Because customization set migration does not provide a merge capability, never customize or extend a production environment unless you are performing steps in this section that explicitly instruct you to manually move certain customizations and extensions. 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.
Note:
The customization set does not include all deletions. For example, the set does not include the removal of a customization document using the Manage Customizations dialog. After you import a customization set into the target environment, you must examine the environment for any deletions that you must make manually.
Before you begin:
You will need to do the following before you can begin migrating a customization set:
Ensure that the source and target Oracle Fusion Applications environments are of the same release and that the same standard and one-off patches have been applied to both environments. For Oracle Cloud implementations, log a service request using My Oracle Support at https://support.oracle.com and request a production-to-test movement, a reprovisioning of the test environment, or an upgrade of the production environment, whichever is appropriate.
If you are moving Oracle Fusion CRM customizations, ensure that there are no Oracle Enterprise Scheduler jobs that are running or scheduled to run during the time that customizations are being applied to the target environment. The apply process takes approximately 25 minutes. To view the Oracle Enterprise Scheduler jobs choose Tools from the Navigator menu, and then choose Scheduled Processes. If there is a job that is running or is scheduled to run during the apply process, either cancel the job or put it on hold, as shown in Figure 2-12.
To prevent the movement of incomplete customizations, perform the following tasks:
Ensure that all Application Composer, Page Composer, and JDeveloper customizations are made in sandboxes and are not published until they are complete, as described in Section 2.2, "Using the Sandbox Manager."
Ensure that all other customizations and extensions, such as customizations made using the Manage Menu Customizations task, the Manage Standard Lookups task, and Oracle Authorization Policy Manager, are complete.
Do not allow customizations in the source environment during the export process.
Do not allow users to publish sandboxes during the export process.
Ensure that users do not make customizations in the target environment during the apply process because the results of doing so are unpredictable. As stated previously, with the exception of customizations that must be moved manually, never make customizations in production environments. However, if you must make emergency customizations to the production environment, you must also make the same customizations to the test environment to ensure that they are included in the next customization set migration.
Ensure that you have been granted access to the FND_CUSTOMIZATION_SET_MANAGEMENT_DUTY role, which enables you to access the Customization Set Migration dialog. Contact your security administrator for details.
For the following reasons, ensure that you apply and restore customizations only when few people are signed in:
The users might encounter the problems listed in the warning at the beginning of this section.
Anyone who is signed in when the migration occurs must sign out and sign back in to see the changes that are made by the process.
To migrate customizations using the Customization Set Migration dialog:
From the source environment, choose Customization Migration from the Tools section in the Navigator menu.
Click the Outgoing tab.
If the Create Customization Set button is disabled as shown in Figure 2-13, click the Compact button for the previous customization set. This removes the temporary files that are on the server from the previous customization set creation. You will not be able to create a customization set until the previous set has been compacted
From the Outgoing tab of the Customization Set Migration dialog, click Create Customization Set.
Provide a name for the customization set.
Optionally, type a description of the set.
Click Save and Close.
(Optional) Click Log to view the process status details as shown in Figure 2-14.
Periodically, click Refresh to view the current status of the set creation. When the status changes to Ready for Download, proceed to the next step.
This process takes approximately 15 minutes. If, when you click Refresh, the export has not progressed for over one hour, a dialog box appears with the following message. If there is a reason for the stalled process, such as a slow server, click Continue. Otherwise, click Restart to restart the export process.
The process might have stalled due to unexpected issues, possibly with the server. Do you want to restart the process or continue with this process?
Note:
The process runs asynchronously. You can exit the dialog and return to it at a later time.
When the customization set is ready for download, click Download, specify the name and location for the file that will be created, and click Save.
After the download file is successfully created on your local file system, click Compact to remove the temporary files that were created on the server.
Open the Customization Set Migration dialog in the target environment.
From the Incoming tab, click Browse, specify the name and location of the customization set file, and click Open.
Note:
If the Browse button is not enabled, you must first apply the previously uploaded customization set, or, if you do not intend to apply the set, you must first compact it to enable the Browse button.
WARNING:
Always upload the most recent customization set from the source environment. Never upload a customization set into the same environment from which it was created.
When the status for the customization set is Ready to Apply Customizations as shown in Figure 2-15, click Apply.
(Optional) Click Log to view the process status details as shown in Figure 2-16.
Periodically, click Refresh to view the current status of the apply action. When the apply process has completed, proceed to the next step.
This process takes approximately 25 minutes. If, when you click Refresh, the process has not progressed for over one hour, a dialog box appears with the following message. If there is a reason for the stalled process, such as a slow server, click Continue. Otherwise, click Restart to restart the apply process.
The process might have stalled due to unexpected issues, possibly with the server. Do you want to restart the process or continue with this process?
Tip:
The process runs asynchronously. You can exit the dialog and return to it at a later time.
Note:
For Oracle Cloud implementations, if problems occur during an apply action, log a service request using My Oracle Support at https://support.oracle.com. For non-Cloud implementations, if problems occur, see Section A.2.3, "Troubleshooting Customization Set Migration Issues" for information about diagnosing issues.
Access the target environment and examine the environment for any deletions that you must make manually.
Deploy all flexfields that have a status of Patched as described in Section 4.7, "Deploying Flexfield Configurations."
Tip:
Click the header in the Status column to sort the flexfields by status.
In non-Cloud environments, you can also use the deployPatchedFlex WLST command as described in the "Deploying Flexfields Using the Command Line: Explained" section in the Oracle Fusion Applications Common Implementation Guide.
Complete the following substeps to send the newly created and newly updated Oracle Social Network definitions to the Oracle Social Network server:
Access the Manage Oracle Social Network Objects task by choosing Setup and Maintenance from the Administration menu in the global area of Oracle Fusion Applications and searching for the task.
For each object that was created or updated by the apply process, if its Enabled value is other than No, trigger the sending of its definition to the Oracle Social Network server by changing its Enabled value, resetting it back to the original Enabled value, and then saving the change. For example, if the Enabled value is Manual, click Disable Object, click Enable Object, select Manual, click OK, and then click Save.
If you applied Oracle Fusion CRM application customizations, you must submit all custom subject areas for publishing as described in the "Publishing Custom Subject Areas: Explained" section in the Oracle Fusion Applications CRM Extensibility Guide. Note that you must submit all custom subject areas, including those that were previously published after applying earlier customization migration sets.
If you applied Oracle Fusion CRM application customizations, perform the following tasks from Application Composer to complete the movement of Oracle Fusion CRM customizations and extensions:
Generate the artifacts that are required to register the migrated extensions by clicking Import and Export in the Common Setup pane and then clicking Generate. This makes the migrated extensions available for importing and exporting. For more information, see the "Importing and Exporting Custom Objects: Explained" section in the Oracle Fusion Applications CRM Extensibility Guide.
Create the same email templates that were created in the source environment. For information about creating email templates, see the "E-Mail Templates: Explained" section in the Oracle Fusion Applications CRM Extensibility Guide.
From the Common Setup region, click Web Services and complete the following substeps for every secured SOAP web service connection that uses either of the following authentication schemes to manually migrate the user names and passwords:
Invoke with separate user credentials over SSL
Invoke with separate user credentials and message protection
Make a note of the name and WSDL URL for the web service.
Delete the secured web service.
Click the Create icon to re-create the secured web service that you just deleted.
In the Create SOAP Web Service Connection dialog, type the name and WSDL URL for the service that you just deleted. These values must match the values that you noted in Step a.
Click Read WSDL.
Ensure that the appropriate authentication scheme is selected.
Click the New icon for the Credential Key field.
In the Create Key dialog, type the credential key, user name, and password, and then click OK.
Click Save and Close.
If attachments were enabled on runtime pages using Application Composer, complete the following steps to enable attachments for those pages in the target environment:
From the source environment, choose Setup and Maintenance from the Navigator menu.
In the Tasks region, click Manage Implementation Projects.
On the Manage Implementation Projects page, choose Create from the Actions menu.
On the Enter Basic Information page, specify the project details.
You can accept the defaults that are supplied. If you change the Code value, you must specify a unique code. Use the default value for the Start Date and leave the Finish Date blank. The Assigned To user must have access to Customization Set Migration.
Tip:
Use the Name field to specify a meaningful project name. When you change the name, the code and description fields change automatically.
Click Save and Open Project.
On the Implementation Project page, choose Select and Add from the Actions menu.
Select Tasks from the Search dropdown list.
Search for and select the Manage Attachment Categories task and the Manage Attachment Entities task, as shown in Figure 2-17, and then click Apply.
Click Done and click Done again.
In the Tasks region on the Setup and Maintenance page, click Manage Configuration Packages.
On the Manage Configuration Packages page, choose Create from the Actions menu.
From the Name dropdown list in the Source Implementation Project region on the Create Configuration Package page, select the implementation project that you just created.
Click Next and click Next again.
On the Create Configuration Package: Schedule and Notifications page, click Submit.
When the Warning dialog appears, click Yes to continue the export process.
Periodically, click the Refresh icon to display the current status.
After the process has completed, download the configuration package.
On the target environment, create an implementation project that is similar to the one that you created on the source environment.
Create a configuration project similar to the one that you created on the source environment. Do not submit the project. Click Save and Close.
On the Manage Configuration Packages page, select the configuration package that you just created, and click Upload.
Select the configuration package that you just downloaded from the source environment and click Open.
Click Details and then click Submit.
Select the configuration package and click Import Setup Data.
Click Submit.
Periodically, click the Refresh icon to display the current status.
After the job completes, click Done.
(Optionally) From the Navigator menu, choose Tools and then choose Scheduled Processes to identify and reschedule any Oracle Fusion CRM processes that failed during the apply process. Look for processes with the following statuses:
Blocked
Error
Error Auto-Retry
Error Manual Recovery
Paused
Validation Failed
As shown in Figure 2-18, you can choose a value from the Status field in the Search region to filter the search results by status. Alternatively, you can click the Status column header in the Search Results table to sort the search results by status.
Perform functional testing to verify the changes. If testing exposes problems with the customizations, such as importing more than you intended, or the changes were not what you expected, access the customization set in the Incoming tab of the Customization Set Migration dialog, and click Restore to revert back to the state before the customization set was applied. Skip the next step.
WARNING:
All user personalizations that are performed after a customization set is applied are lost when you perform a restore on that customization set.
Figure 2-19 shows the Log dialog box for a restore that is in progress.
Broadcast information to the users that they must sign out and sign back in to see the changes.
You can use the Functional Setup Manager to move common reference objects, such as application data security policies, application extensible flexfields, application descriptive flexfields, and application value sets from one Oracle Fusion Applications environment to another. For more information, see "Importing and Exporting Setup Data" in the Oracle Fusion Applications Common Implementation Guide.
The Manage Customizations dialog enables you to download customization files for a given page. You can use this downloaded file for diagnosing customization issues.
To download customizations using the Manage Customizations dialog:
Go to the page for which you wish to download or upload customizations.
Select the page, task flow, or page fragment that contains the 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, task flow, or page fragment 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.
Note:
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.
Note:
WLST is not available in Oracle Cloud implementations.
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 move customizations as described in Section 2.3.5, "Using Fusion Applications Control to Move Customizations."
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 layer customizations of the navigator menu.
Example 2-2 WLST Command to Export Site Layer 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')
Tip:
If you are not sure of the document name, append '/*' to the path in the docs argument to include all customization documents in the directory. Append '/**' to the path in the docs argument to also include the customization documents in the subdirectories. For example, use '/oracle/apps/hcm/dashboard/hrSpecialist/publicUi/**' to import or export all documents under the publicUi directory and its subdirectories.
For more information about uploading and downloading customization files, see the "Importing Customizations into Your Application Workspace" section in the Oracle Fusion Applications Extensibility Guide for Developers. For information about uploading and downloading the customizations of resources, see the "Translating Resource Bundles from an MDS Repository" section in the Oracle Fusion Applications Extensibility Guide for Developers
For more information about the exportMetadata command, see the "Managing the Metadata Repository" chapter in the Oracle Fusion Middleware Administrator's Guide.
Note:
Fusion Applications Control is not available in Oracle Cloud implementations.
Use Fusion Applications Control to move MDS customizations made to a page or other UI from one environment to another. 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, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
