2 Understanding the Customization Development Life Cycle

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:

2.1 Understanding Typical Customization Workflows

All customizations and extensions to Oracle Fusion Applications should be done in a full test environment, as shown in the following figure. 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 About the 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.

Developers using design time tools, such as Oracle JDeveloper, have the option to publish their customizations to a sandbox, as described in About the Design Time Customization Workflow.

After testing, you can then move the customizations to the mainline code as described in About Exporting and Moving Customizations.

Figure 2-1 Customization Workflow in a Full Test Environment

2.1.1 About the Runtime Customization Workflow

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.

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 About the Sandbox Manager .

2.1.2 About the Design Time Customization Workflow

After you create these customizations using JDeveloper, you can test them locally in JDeveloper and then deploy your customizations to a sandbox. Note that security customizations done at design time are not saved to a sandbox.

Additionally, you can use source control software to manage design time customizations.

Because your customizations (other than security changes) are stored in customization XML files in an MDS repository, they can also be viewed and managed using the Manage Customizations dialog.

Note:

Customizations can also be new Java artifacts, which would not be in XML and would not be stored in the MDS repository.

The following figure shows the flow for a typical design time customization process.

Figure 2-2 Typical Design Time Customization Workflow

2.2 About the Sandbox Manager

The sandbox manager is a tool for managing the different types of customization changes that can be applied to an application These changes that are contained within a sandbox do not affect the mainline code. You can 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.

There are three types of sandboxes:

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.

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.

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.

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. Note that the security sandboxes created using the sandbox manager are not available in JDeveloper.

The metadata and security sandbox sessions can be saved, downloaded, and imported as files into other Oracle Fusion applications.

If more than one person is using a sandbox, then you must take care to prevent conflicts.

2.3 About Exporting and Moving Customizations

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.