2Configuration Life Cycle

This chapter contains the following:

Overview of Configuration Life Cycle

Always make your configurations in a separate environment, called the test environment, and then migrate them to the production environment, which is the one you use for your everyday business. You must never make these changes directly in the application instance you use for your business needs. This is very important because any incomplete, flawed, or unvalidated configuration you make can disrupt your business.

You need to create and enter a sandbox before you can start using configuration tools such as Page Composer and Application Composer to modify your application. Changes you make with these tools are stored in the sandbox as XML files. These changes are then merged with the mainline metadata when you publish your sandbox.

Note: Changes you make in one sandbox aren't available in another one.

In essence, here's what a typical configuration life cycle looks like:

  1. An administrator configures the application in a sandbox in the test environment.

  2. Administrator validates the changes in the sandbox.

  3. The sandbox is published.

  4. Quality Assurance validates the whole environment after all configurations are complete and published.

  5. Configurations are migrated from the test environment to the production environment.

Image depicting the workflow of a typical configuration
life cycle, as described in the preceding list.

Configurations and Extensions

Configuration Workflow

While using Application Composer and Page Composer to make changes to your application, use sandboxes to save your changes in a segregated environment. For example, before making application changes, suppose you create a sandbox named MySandbox, and then make your changes in that sandbox. Now, if others want to see your changes, 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.

After you complete your application changes, others can review and approve your changes, and then publish to the test environment.

Note that a flexfield sandbox is for testing only and can't be published. Instead, you can deploy a flexfield to the test environment using the flexfield UI. To test a flexfield configuration before deploying it to the test environment, deploy it to a flexfield sandbox. The changes that you deploy to a sandbox are isolated from the 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 test environment.

You can also use the Manage Configurations dialog box to:

  • View others' configuration metadata files

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

Considerations for Viewing and Diagnosing Application Changes

Use the Manage Configurations dialog box to view and diagnose changes made to application pages. Application changes are role-dependent and by default, the Manage Configurations dialog box displays the changes that the signed-in user had performed.

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

  1. Click your user image or name in the global header, and select Manage Configurations from the Administration menu.

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

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

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

Page-Level Changes

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

Sandboxes

You use sandboxes to make application changes and test them without impacting other users in the environment. Wherever possible, make changes to the application in a sandbox rather than making direct changes in the mainline environment. Sandboxes set apart untested configuration changes from the mainline environment. So you can test your changes in the sandbox and then publish it. After publishing, your changes become available in the mainline metadata or other sandboxes after they're refreshed. So everyone can then see your changes in the environment. Mainline metadata is the primary branch of metadata a sandbox is published to.

Why You Need Sandboxes

Today's business landscape is quite dynamic. Companies are expected to respond quickly to address both customer and market needs. So multiple teams need to make application changes at the same time while sharing the same data model and configuration starting point. But you may get conflicts between teams working that way. To avoid such conflicts, sandboxes come in handy.

Unified Sandboxes

You can either use the Unified Sandboxes UI, which is the default feature you get, or opt out of it using the Offerings work area to get the Classic Sandboxes feature.

With Unified Sandboxes, you can refresh your sandboxes to bring in the latest changes from the mainline metadata to your sandboxes, and do many other new and versatile sandbox activities. You get a consistent sandbox experience across all configuration tools and a more robust user interface with this feature.

With Unified Sandboxes, you can do these additional sandbox activities:

  • Select the configuration tools to enable for your sandboxes while creating them.

  • Enable all configuration tools in the same way using the Sandboxes UI. So you get a consistent sandbox experience across tools.

  • Restrict access to various sandbox activities for users. For example, you can specify these access rights for your sandboxes:

    • Full access

    • Edit and preview access

    • View only access

  • View just your application changes without having other context layers hide your content.

  • Test your changes in a preview mode that shows you exactly how your application changes would appear in a published sandbox.

  • Refresh and merge sandboxes with latest changes in mainline metadata from other published sandboxes. After merging all changes, you can publish your sandbox.

  • After opting in to the Unified Sandboxes feature, if you register your target environment in your source environment, you can do these additional migration tasks using the Migration UI:

    • Migrate your changes from the test environment to the target environment without manually downloading and uploading the configuration set file.

    • Move only new changes from the source environment to the target environment.

Sandbox Usage

You typically use sandboxes for either of these purposes:

  • Test-Only: You can make application changes using test-only sandboxes, which you don't want to publish to the mainline code.

  • Publish: Once satisfied with the application changes made in the test-only sandbox, you can replicate these changes in a sandbox that you want to publish. And then publish your changes to the mainline code. This sandbox type is also known as the integration sandbox, because teams working in parallel use this sandbox as the final staging point before publication to the mainline code.

Note: Before each patch or upgrade, publish or delete your sandboxes. If you haven't yet completed your work, restart with a new sandbox.

Unified Sandboxes

You get to use Unified Sandboxes by default. But if you want to use Classic Sandboxes instead of the default sandboxes, opt out of the Unified Sandboxes feature.

Before you start, consider these points:

  • Make sure you totally understand what it means to opt in to or opt out of the feature and what impact that would have.

    • When you use Application Composer in your Unified Sandbox, an object can only be edited in any one sandbox in the environment at a time.

    • You can't deploy your flexfields to a sandbox after you opt in to Unified Sandboxes. You must deploy them directly to the mainline environment.

  • You must publish or delete any sandboxes that are open right now. Use the Manage Sandboxes dialog box to do these tasks. You can open this dialog box by clicking your user image or name in the global header and selecting Manage Sandboxes under Administration. Once you opt in to Unified Sandboxes, you can no longer see the published Classic Sandboxes.

In the Offerings work area, enable or disable the Unified Sandboxes feature:

  • Offering: Any with the Application Extensions functional area

  • Functional Area: Application Extensions

  • Feature: Unified Sandboxes

  • Opt In Task: Click Continue if you're sure about enabling or disabling this feature.

Create and Activate Unified Sandboxes

To make changes to the application, you must first store the changes in an active sandbox. You can either create a sandbox or select an existing one, and make it active. You must activate the configuration tools you want to use in your sandbox. If you plan to use Page Composer in your sandbox and need to edit pages at any layer, not just Site, create a separate sandbox just for using this tool.

Note: You can create up to 20 sandboxes. But, you can increase this limit using the Maximum Number of Sandboxes profile option. In the Setup and Maintenance work area, use the Manage Applications Core Administrator Profile Values task in the Application Extensions functional area.
Create and Activate Sandboxes

Follow these steps to create and activate sandboxes for most configuration tools. For flexfields, use the Manage Descriptive Flexfields task or the Manage Extensible Flexfields task instead.

  1. Click Navigator > Configuration > Sandboxes.

  2. On the Sandboxes page, click Create Sandbox.

  3. Enter a name and description for your sandbox.

  4. In the All Tools section, select the tools you want to activate for this sandbox. The context layers for all selected tools are set as Site by default. So the changes you make using these tools affect all users.

  5. If you select Page Composer, you can click the Edit Sandbox Context icon and change the context layer from Site to another layer, for example External. You can find the Edit Sandbox Context icon in the Support Context column.

    Note: If you want to use other tools along with Page Composer in your sandbox, don't change the context layer for Page Composer, even though you can. That's because all tools except Page Composer support only a single context layer, Site. If you change the context layer for Page Composer from Site to any other layer, you can't activate those tools in the same sandbox.
  6. Click Create to just create the sandbox, or Create and Enter to enter or activate the sandbox after creating it.

Here are a few things to know about activating tools in your sandbox.

  • If you try to use a configuration tool in a sandbox without activating the tool in it, you get a message prompting you to activate the tool. You can add more tools to your sandbox later also.

  • To create and manage saved searches and make UI adjustments (for example, change a table's column width) just for yourself, you must leave your sandbox before making these changes. But if you want to make these changes for others too, then make the changes with Page Composer open, in which case you also must be in a sandbox.

Activate Existing Sandboxes

You can activate only one sandbox at a time.

  1. Click Navigator > Configuration > Sandboxes.

  2. From the list of sandboxes, if available, find the one you want to activate, and click the Enter Sandbox icon for that sandbox. Your sandbox is activated, and you can see its name on the sandbox bar above the global header. You can use the options available on the sandbox bar to quickly do some activities, such as view sandbox details, publish the sandbox, or leave the sandbox.

How to Resolve Conflicts in Unified Sandboxes

When you're in a sandbox, if other users publish their sandboxes, you get refresh notifications on the sandbox bar above the global header. At this time, it's a good practice to refresh your sandbox. When you refresh, all changes published in the mainline environment are brought into your sandbox. You get sandbox merge conflicts in the merge log when different users change a specific file using different sandboxes. If the changes are made to different files, they're automatically merged, and aren't even reported in the merge log.

Note: In some configuration tools, for example Application Composer, an object gets automatically locked when you create it or modify it in a sandbox. So in such cases, an object can only be edited in any one sandbox at a time. If the sandbox is published or deleted, the lock is removed.

You must resolve all conflicts flagged in the merge log so that you can publish your sandbox. To review the merge log, on the Sandbox Detail: <Sandbox Name> page, click the Merge Log tab. The log displays details about the sandbox merge statuses. Let's understand what these statuses mean and how we can resolve the sandbox merge conflicts based on their statuses.

Merge Status Icon What It Means How I Can Resolve Merge Conflicts

Automatically Merged Content

Auto Merge

Different users changed different attributes of the same file using different sandboxes.

These changes are merged automatically.

Resolvable Conflicts

Resolvable

Different users changed the same attribute of the same file using different sandboxes.

These changes can be merged to the mainline environment. On merging, the changes in the mainline environment overwrites your sandbox changes. So review the merge actions and accept or reject them.

  • If you accept, you can later redo any changes that were overwritten and then publish your sandbox.

  • If you reject, your sandbox remains untouched, but you still need to accept a merge before you publish your sandbox.

Unresolvable Conflicts

Unresolvable

Different users changed files in different sandboxes, but the merge conflicts can't be automatically resolved.

Do any of these tasks:

  • Undo your sandbox changes.

  • In your sandbox, make the same change, which the other user made in the published sandbox, and try to resolve the conflict.

  • Create another sandbox and make your changes in that one.

How the Refresh and Merge Processes Work in Unified Sandboxes

Sandbox changes are refreshed and merged when two different users make changes to the same file using two different sandboxes. Let's look at an example. Suppose your manager creates a sandbox named Sandbox1 and you create another sandbox named Sandbox2. Your manager then makes a change to a file using Sandbox1 and publishes it to the mainline environment. Now if you make changes to the same file and refresh Sandbox2, all changes published in the mainline environment are merged into Sandbox2. What if both you and your manager entered different values to the same attribute of the file? In that case, the value that your manager entered using Sandbox1 persists because Sandbox1 is published to the mainline metadata. To bring back the changes that you made in Sandbox2, you need to reenter the sandbox and make the changes again.

Application Changes That Can or Can't be Merged

Let's again take the same example of Sandbox1 and Sandbox2. Here's a list of application changes made in Sandbox2 that can merge with the mainline environment, when the same file is changed in both sandboxes.

Application Changes Tools Used to Make the Changes

Changes in business objects and their related fields

Application Composer and Configure Business Objects

Changes in data security

Data Security

Changes in lookups

Lookups

UI text changes

User Interface Text

Changes to messages, such as warning messages and information messages

Messages

Note: Flexfields and setup tasks, apart from the ones listed in the table, aren't supported in Unified Sandboxes. So changes in these artifacts aren't merged when Sandbox2 is refreshed.

And here's a list of changes made in Sandbox2 that can't merge with the mainline environment when the same file is changed in both sandboxes. To bring back those changes, you can create another sandbox, make the changes in it, and publish that sandbox.

Application Changes Tools Used to Make the Changes

Changes to the appearance of the application

Appearance

Changes in pricing configuration

Manage Service Mappings

Changes to the page content

Page Composer

Changes to global page template

Page Template Composer

New pages created

Page Integration

Options to Open Configuration Tools from Unified Sandboxes

In Unified Sandboxes, after activating the configuration tools, you can also use shortcuts to quickly open some of these tools and make your changes. But you can't open all tools from there. In which case, you can get to those tools using regular navigation.

Use Shortcuts in Sandboxes

After you activate a sandbox, all tools activated in it are listed on the sandbox bar and the Sandbox Details page. You can open these tools from either of these locations:

  • The Tools drop-down button on the sandbox bar above the global header

  • The Active Tools section of the Sandbox Detail: <Sandbox Name> page

In this list, you may notice that some tools are available, while others, for example, Lookups and Messages are grayed out. You can click the available tools to open them directly from the Sandboxes UI.

Use Regular Navigation

This table lists the regular navigation options to open all tools that you can activate in your sandboxes. It also indicates whether you can open the tools from the Sandboxes UI.

Tool Name Can Open Using the Sandboxes UI? Regular Navigation

Application Composer

Yes

Click Navigator > Application Composer.

Configure Business Objects

Yes

Click Navigator > Business Objects.

Appearance

Yes

Click Navigator > Appearance.

Manage Service Mappings

No

Click Navigator > Pricing Administration, and then on the Tasks panel tab, click Manage Service Mappings.

Page Integration

Yes

Click Navigator > Page Integration.

Structure

Yes

Click Navigator > Structure.

Lookups

No

In the Setup and Maintenance work area, use the lookup tasks, such as:

  • Manage Standard Lookups

  • Manage Common Lookups

  • Manage Set Enabled Lookups

User Interface Text

Yes

Click Navigator > User Interface Text.

Messages

No

In the Setup and Maintenance work area, use the messages tasks, such as:

  • Manage Messages

  • Manage Messages for General Ledger

Data Security

No

Click Navigator > Security Console, and then click the Administrator tab, and click Manage Database Resources.

Page Composer

Yes

Click your user image or name in the global header and select Edit Pages under Administration.

Global Page Template

No

Click your user image or name in the global header and select Edit Global Page Template under Administration.

Object Locking in Application Composer

The automatic object locking ability in Application Composer avoids the risk of conflicts between multiple users working on objects in parallel and prevents any sandbox merge conflicts that may arise when different users change a specific object using different sandboxes.

Application Composer automatically places a lock on a business object when you create or modify it in a unified sandbox. The locked object displays a lock icon next to its object name in Application Composer's object navigation tree. A gold lock indicates that the object is locked in the current sandbox. A gray lock indicates that the object is locked in a different sandbox. Hover over a locked object's name in the navigation tree to display the name of the sandbox that holds the lock.

Application Composer displays and enforces object locks across all unified sandboxes. You can only edit a locked object in the sandbox that holds the lock. For example if the Service Request object is modified in Sandbox A, only Sandbox A holds the lock and anyone using Sandbox A can modify Service Request. Any other sandbox displays a gray lock on Service Request in Application Composer, and prevents users from modifying it.

The lock status of objects changes each time you publish or delete a sandbox, or when a new object lock is established. Collapse and then expand Application Composer's object tree to update the lock status of all objects. Any action that causes the object tree to be refreshed will update the lock status, including when you exit and reenter a sandbox, or refresh a sandbox. If an object is locked and that lock is not yet visible in the current sandbox, a new lock is not allowed to be placed on that object and an error message appears while saving the changes.

For more information on how object locking works in unified sandboxes, see the FAQs on Object Locking.

Best Practices for Preventing Object Locking

Here are some tips on how you can prevent or work around object locking:

  • Plan your object model and user interface configurations, and divide the work to prevent two users requiring the same object or objects locked.

  • Name sandboxes clearly with appropriate names or initials, so when a lock is in place, it's easy to identify who to contact to release the lock from the sandbox holding the lock.

  • Perform configurations in smaller increments. Test and publish more frequently to prevent holding locks.

  • Delete test sandboxes created to try out new configurations after they are no longer needed to prevent unnecessary locking.

Publish Unified Sandboxes

After you're done making changes to the application, publish the sandbox to make your changes available to all users. You must have the Administer Sandbox (FND_ADMINISTER_SANDBOX_PRIV) privilege to publish sandboxes. Remember, you can't make further changes in the sandbox once you publish it.

Before you start, do these tasks:

  • Test or validate your changes in the sandbox in preview mode before actually publishing it. If you made changes using Page Composer, don't forget to close it before testing. To preview your changes, click the Sandbox Mode drop-down button on the sandbox bar above the global header, and select Preview as if Published (Context: All).

    Note: You can see the sandbox bar only when you're in an active sandbox.
  • Resolve all conflicts flagged in the merge log of your sandbox.

To publish a sandbox:

  1. Click Navigator > Configuration > Sandboxes.

  2. On the Sandboxes page, click the name of the sandbox you want to publish.

  3. Click Publish.

    Note: The Publish button might be disabled for your sandbox because of various reasons. For example, you haven't yet made any changes in your sandbox, or the Control Publish Sandbox Action in Production Environment profile option (FND_ALLOW_PUBLISH_SANDBOX) is set to No.
  4. Click Continue to Publish. The sandbox is published to the mainline metadata.

  5. Click Done.

FAQs for Unified Sandboxes

Who can preview, edit, and publish sandboxes?

Users with the Administer Sandbox (FND_ADMINISTER_SANDBOX_PRIV) privilege can preview, edit, and publish sandboxes. This privilege is assigned by default to the administrators for product families. Your security administrator can define which users have job roles with this privilege.

Note: With other sandbox privileges, users can only do some tasks. Users having the Manage Sandbox (FND_MANAGE_SANDBOX_PRIV) privilege can edit but not publish sandboxes. While those having the View Sandbox (FND_VIEW_SANDBOX_PRIV) privilege can view sandboxes in read-only mode.

Why can't I create more sandboxes?

Probably, you have reached the limit for the maximum number of sandboxes. But don't worry, try any of these solutions:

  • Increase the limit using the Maximum Number of Sandboxes profile option. In the Setup and Maintenance work area, use the Manage Applications Core Administrator Profile Values task in the Application Extensions functional area. The default value set for this profile option is 20.

  • Delete an unused sandbox.

  • Publish a sandbox.

Why is the Publish button on my Sandbox Detail page disabled?

That could be because of one or more of these reasons:

  • You haven't yet made any changes in your sandbox. The Publish button is enabled only after you make a configuration change in the sandbox.

  • Another sandbox is currently being published in this environment. Try publishing your sandbox again later.

  • Your mainline metadata has changes from other published sandboxes. You must refresh your sandbox and then publish it.

  • You don't have the Administer Sandbox (FND_ADMINISTER_SANDBOX_PRIV) privilege, which is required for publishing sandboxes. To get this privilege, contact your security administrator.

  • You just had a release update or upgrade, and all sandboxes that were available at the time now can't be published. In the future, publish your sandboxes before release updates or upgrades happen.

  • A configuration set was just migrated into the environment, and now all sandboxes in the environment can't be published. In the future, publish or delete sandboxes in an environment before migrating configurations there.

  • The Control Publish Sandbox Action in Production Environment profile option (FND_ALLOW_PUBLISH_SANDBOX) is set to No. To enable publishing, set this profile option to Yes. In the Setup and Maintenance work area, use the Manage Applications Core Administrator Profile Values task in the Application Extensions functional area.

  • The application is in maintenance mode. Try publishing your sandbox again later.

Why doesn't the page I am editing with Page Composer work with the sandbox context?

Let's see why you might get errors about the page not supporting the context layer of the active sandbox, and how you can resolve them.

  • Maybe the context layer of your sandbox isn't a layer that your page supports. Context layers vary based on the category you select for the sandbox. For example, the Customer Relationship Management category supports certain layers that apply to certain pages, and the Human Capital Management category supports other layers and pages. You can activate a sandbox with the appropriate layer and try editing the page again.

  • You might not have a role that gives you access to what the sandbox layer covers. For example, if the Internal context layer requires a role with back-end access, you can edit pages at that layer only if you have the role. For more information, contact your security administrator.

Why are the lookup, message, and data security changes appearing in my Unified Sandbox even though I haven't yet refreshed my sandbox?

Lookups, messages, and data security records are values stored in tables. These records aren't copied to your sandbox until you make changes in these artifacts in your sandbox. But what if another user changes these artifacts in a different sandbox and publishes it before you make changes in your sandbox? In that case, the other user's changes show up in your sandbox as soon as you make changes to these artifacts, even before you refresh your sandbox.

How can I deploy flexfields to a Unified Sandbox?

You can't deploy your flexfields to a sandbox if you have opted in to Unified Sandboxes. You must deploy them directly to the mainline environment.

How does object locking impact object workflows?

When you create an object workflow for an object that is not currently locked, a lock is created for that object.

You can create a new object workflow for a locked object in the sandbox that holds the lock. However, an object locked in a different sandbox is disabled for selection in Application Composer's list of available objects while creating an object workflow. Hover over the name of the disabled object in the list to identify which sandbox has a lock on that object.

When are object locks released?

An object lock exists until the sandbox that holds the lock is published or deleted. A lock is not removed when the change that caused the lock is deleted or reverted. For example, adding a new page layout creates a lock on an object if the object is not already locked, but deleting the layout will not release the lock.

Does importing and exporting configurations impact object locks?

Importing configurations can impact sandboxes. You must delete existing sandboxes before importing new configurations to release all locks and to prevent users from thinking that they can refresh and publish after an import.

How does object locking affect parent and child objects?

An object is locked only when it is directly modified. Modifying a child object will not result in a lock on the parent object.

For example, consider a Custom Context subtab (a subtab that displays content of a different object), which is added to the Premium Accounts object. The Custom Context subtab displays the Accounts object, which is the parent object of Premium Accounts. The object lock is placed on Premium Accounts and not Accounts, because Accounts (the parent object) was not modified.

How does object locking work for dynamic choice lists?

When you create a custom dynamic choice list, a lock is placed on the object that the custom dynamic choice list is created for. The data source object (the object that the dynamic choice list pulls data from) is not locked.

Can I manually set or remove object locks?

No, you can't manually set or remove object locks. Locks are automatically set when you create or modify objects in a unified sandbox, and automatically released when you publish or delete the sandbox that holds the locks.

Classic Sandboxes

You can apply different types of configurations 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 configurations are stored in sandboxes and are validated before applying them to an application.

Types of Configurations in Sandboxes

Sandboxes can contain the following types of configurations:

  • Metadata changes - These changes (such as non-flexfield user interface (UI) page changes) 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 make application changes, you must first create a sandbox and then use tools, such as Page Composer to make the changes. These changes remain within the sandbox and don't affect the mainline metadata. You must test and validate your changes in the sandbox. After testing, you can publish your sandbox to make the changes available in the production environment for other users.

Don't make application changes directly in the mainline metadata. Make all application changes in the sandbox first. When you make changes to an application 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 see the information pertaining to only the existing application changes in the current mainline metadata. For example, suppose you make an application change in a sandbox and publish it. Then, on creating another sandbox for the next change, you will see the previous change in the new sandbox because that change 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 configuration tools to make application changes. For example, you can modify objects and pages using Page Composer, which uses sandboxes. Oracle Business Process Composer and Oracle SOA Composer are also tools used for making application changes, but they don't use sandboxes. They have their own mechanisms for handling application changes.

Managing a Flexfield Sandbox

To create a flexfield-enabled sandbox, deploy a 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 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 changes 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 Sandboxes UI.

Guidelines for Working with Classic Sandboxes

In the runtime configuration 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.

The testing sandboxes are never published and therefore produce no concurrency conflicts between sandboxes. You can have several testing sandboxes at the same time.

Application changes in the sandboxes that are published are merged back to the mainline metadata. This figure illustrates the two types of sandboxes and their relationship to the mainline metadata.

Types of sandboxes
Working with a Single Sandbox

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

  • 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 conflict arises among users, the application displays concurrency warning messages.

Working with Multiple Sandboxes

Multiple sandboxes are used when configurations are stored in testing as well as production sandboxes. Suppose, 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. For example, when you try to 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 deleted.

  • 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 modifying 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 configurations pertaining to ADF Business Components, sign out and sign in again after switching in or out of this sandbox. This process ensures avoiding any inconsistencies between the runtime caches and the ADF Business Components definitions.

Create and Activate Classic Sandboxes

To make changes to the application artifacts, you must 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.

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

To create and activate a sandbox:

  1. Click your user image or name in the global header, 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.

    Only one sandbox can be active at a time. Once a sandbox is active for your session, the sandbox name is displayed on the sandbox bar above the global header.

After completing the application changes in the sandbox, publish them to make them available in the application for all others.

Before you start publishing your sandbox, test or validate your changes. If you made application changes using Page Composer, don't forget to close it while testing.

  1. Click your user image or name in the global header, 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.

Migration

Overview of Migration

You can move your configurations from the test environment, which is the source, to the production environment, which is the target. You use the Migration page to create a migration set and export it from the source environment, and then import it into the target environment. A configuration set is a JAR file that contains all your configurations across all product families, such as those stored in Oracle Metadata Services repository, JEDI, CRM, and BI. Changes you export from the source environment can't be merged with any changes you manually make in the target environment. As such, it's very important that you never configure the target environment directly.

You can use either Classic Migration or Unified Migration to move your configurations. Classic Migration is the default migration you can do, and you can use Unified Migration after you opt in to the Unified Sandboxes feature. Both the appearance and behavior of your Migration page changes when you enable Unified Sandboxes.

Note: In Unified Migration, the configuration set is called migration set.

Classic Migration

Here's what you do in a classic migration:

  • You always need to migrate all configurations in the source environment.

  • You have to manually download the configuration set from the source environment, and manually upload it into the target.

  • You can't preview configurations in the target environment before applying them.

Unified Migration

Here's what you can do in a unified migration:

  • You can register the target environment in the source environment.

  • You have the option to migrate only new changes if both environments are synchronized.

  • Your migration set is automatically sent to the target environment for import, if the target is registered and available.

  • Your migration set is imported into a sandbox instance before it's applied to the target environment. You can preview your configurations in this sandbox instance before applying them to the mainline.

Here's a diagram that shows what you can do with classic and unified migrations.

An architectural diagram that shows different options
available in classic and unified migrations.

You use the Migration page to create a set of configurations and extensions made to an environment, download the set, and then upload it into another environment. This configuration set includes configurations across all product families.

Note: In Unified Migration, the configuration set is called migration set.

What It Includes

The configuration set includes, but isn't limited to these changes:

  • Application changes done using Application Composer. However, not all changes made using Application Composer are migrated.

  • Changes made to application artifacts using these tools:

    • Page Composer

    • Appearance

    • Structure

    • User Interface Text

    • Page Integration

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

    • Messages

    • Lookups

    • Data security but not the ones created by the HCM Profiles UI

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

    • Attachment categories and metadata

    • Deep links

  • Changes in Reports and Analytics, such as regeneration of SOAP services, including user-defined attributes

  • Changes done using the Manage Oracle Social Network Objects task

  • Changes in functional security settings made in Application Composer, including functional privileges that control access to custom objects. However, not all security changes are migrated

    Note: If you migrate any functional security associated with roles in the source to a target instance, and the corresponding role doesn't exist in the target instance, an error will occur on import. To avoid these errors, you can selectively create these roles in the target environment when you import your configuration set.

What It May Include

Depending on what modules you select during export, your configuration set may include these changes:

  • Changes in CRM email templates created in Application Composer

  • Changes in Enterprise Scheduler Service (ESS) module:

    • Job definitions

    • Job sets

    • Job schedules

    • Incompatibilities

    • Work shifts

    • Work assignments

    • Work assignment schedules

    • Job request parameters

  • Changes in Service Oriented Architecture (SOA) artifacts, such as configurations done using SOA Composer

  • Changes done using Oracle Business Intelligence Enterprise Edition, including but not limited to these features:

    • Oracle Business Intelligence Answers

    • Oracle Business Intelligence Delivers

    • Business Intelligence Composer

    • Dashboard Builder

    • Oracle Business Intelligence Publisher

    Note: You can move configurations done using business intelligence tools only if the Business Intelligence in Configuration Set Migration Disabled profile option is set to No.

What It Doesn't Include

Your configuration set doesn't include these items:

  • The following Application Composer changes:

    • 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

  • Personalizations

  • Unpublished configurations within a sandbox

  • Deletions, for example, the set doesn't include the removal of a custom object. After you import a configuration set into the target environment, you must examine the environment for any deletions that you must make manually.

  • Roles or role hierarchy changes

  • Custom roles created outside of Application Composer

  • Entitlements or privileges created outside of Application Composer

  • Security Console changes, including these changes made directly in the security console:

    • Enterprise roles

    • New duty roles

    • Role hierarchy changes

    You must manually update the target environment with any Security Console changes.

Using a configuration set, you can move your configurations from a test environment, which is your source, to a production environment, which is your target.

Before You Start

Before creating a configuration set, make sure you meet these conditions:

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

  • All Page Composer configurations made in sandboxes are complete and published.

  • All configurations 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, set the Business Intelligence in Configuration Set Migration Disabled profile option to No in source and target environments. You can find this profile option in the Manage Administrator Profile Values task in the Setup and Maintenance work area.

  • You have the following privileges to access the Migration page:

    • Manage Outgoing Configuration Set

    • Manage Incoming Configuration Set

    Contact your security administrator for details.

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

Note: If you make changes to the production environment in emergency situations, you must make the same changes to the test environment. Making the changes to the test environment ensures that these changes are included in the next configuration migration.
  • Don't make any changes in the source environment during the export process.

  • You delete any temporary files on the server from previous migrations. If there are temporary files on the server, click the Delete button next to your previous import and export records.

Create Configuration Sets

  1. In the source environment, click Navigator > Configuration > Migration .

  2. On the Outgoing tab of the Migration page, click Create Configuration Set.

  3. Provide a name for the configuration set.

  4. Optionally, type a description of the configuration set.

  5. Select the content you want to migrate. The choices available on this dialog box are filtered by the offerings you have opted in for.

    Note: The Industry solution extensions module is for Oracle's internal use only and has no impact on migration.
  6. Click Save and Close.

  7. Click Refresh periodically to see the current status of the set creation because creating a configuration set can take a few minutes. You can click Log to review the process log, which provides more details about the configurations that are being compressed. If an error or exception occurs during this process, the log will give you information about the configurations that failed to compress. The process runs asynchronously, so you can close the page and return to it later.

  8. Eventually, the status changes to Ready for Download, which means that the configurations are ready for you to download. Before downloading the configurations, you can click Content Read Me to download the Readme file listing all the configurations you exported.

  9. Click Download to download your configuration set. Ensure that the downloaded file is a JAR file.

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

Apply Configuration Sets

After you apply configurations, end users must sign out and sign back in to see the changes. So apply configurations when fewer people are signed into the environment. To apply configurations to the target environment, follow these steps:

  1. Open the Migration page in the target environment.

  2. Click the Incoming tab.

  3. Click Browse, specify the name and location of the configuration set file, and click Open.

  4. Once the status for the configuration set on the Incoming page is Ready to Apply Configurations, review the roles in your configuration set that are missing in your target environment. Create any missing roles as required. To review and create these roles, follow these steps:

    1. Click Details.

    2. Select an application.

    3. Select the roles you want to create.

    4. Click Create Role, and click Yes.

    5. Click OK after the roles are created.

    6. Click Save and Close.

  5. Click Apply to apply the configuration set to your target environment.

  6. Periodically, click Refresh to view the current status of the Apply action. When the configuration set is successfully applied to the target environment, the status is displayed as Applied and Deleted. You can review the process log, if required. The process runs asynchronously, so you can close the page and return to it later. If problems occur during an Apply action, log a service request using My Oracle Support at https://support.oracle.com.

Post Migration Tasks

Do these tasks after you apply your configuration set to the target environment:

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

  2. Delete and recreate any web service connections in the target environment, using the target environment URL and credentials.

  3. Deploy all flexfields that display a Patched status.

  4. Do the following tasks 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 configurations 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 this by disabling the object and enabling it again with its original status. For example, if the Enabled value is Manual, then you can do these tasks:

      1. Disable the object.

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

      3. Click OK and save the changes.

    3. On the Manage Oracle Social Network Objects page, click Synchronize to synchronize a selected object, or click Synchronize All to synchronize all objects at the same time.

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

  6. If a new theme was created and applied in the source environment, and you want to use that theme in the target environment, then go to the Appearance work area and manually apply that theme.

  7. After applying configurations, do functional testing to verify the changes. Suppose testing exposes problems with the configurations, such as importing more than you intended, or the changes weren't what you expected. In such cases, restore your environment to its pre-migration configuration.

    1. Open the configuration set in the Incoming tab or infotile of the Migration page.

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

  8. Finally, broadcast information to the users that they must sign out and sign in to view the most recent changes.

Things to Know About Migration

  • You can't restore your environment to an earlier configuration if the environment is upgraded after your previous migration. But 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 configuration 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.

  • During configuration 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 configuration instance during the configuration import process and applied to the target environment.

  • You can create reports directly in the target environment. However, make sure that you create the reports and reference them to subject areas that were created in the source environment. Don't create subject areas directly in the target environment.

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

  • While an upload or restore activity processes Presentation Services changes, these things can happen:

    • 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 may not 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 these Oracle Business Intelligence Enterprise Edition features:

      • Oracle Business Intelligence Answers

      • Oracle Business Intelligence Delivers

      • Business Intelligence Composer

      • Oracle Business Intelligence Interactive Dashboards

  • When you restore your environment to an earlier configuration, you lose all personalizations you made after the previous migration.

Migrate Configurations Using Unified Migration

Use a migration set to move your configurations from the source environment to the target environment. With Unified Migration, you can import your configurations into a sandbox in the target environment before you apply them to the mainline. And if you register your target environment in your source environment, you can do these additional migration tasks:

  • Migrate your changes from the test environment to the target environment without manually downloading and uploading the migration set file.

  • Move only new changes from the source environment to the target environment. This type of migration is called delta migration. However, only sandbox aware modules support delta migration. All other modules move all changes every time they're migrated, even in delta migrations.

Before You Start

Before creating a migration set, make sure you meet these conditions:

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

  • Both source and target environments have Unified Sandboxes feature enabled. You can't migrate your configurations if only one environment has this feature enabled in it.

  • Delete or publish any sandboxes in the target environment that have Application Composer enabled, before you begin your migration.

  • All Page Composer configurations made in sandboxes are complete and published.

  • All configurations and extensions made using the Structure page, the Manage Standard Lookups task, and the Security Console, are complete.

  • To move content created using Oracle Business Intelligence Enterprise Edition, set the Business Intelligence in Configuration Set Migration Disabled profile option to No in both the source and target environments. You can find this profile option in the Manage Administrator Profile Values task in the Setup and Maintenance work area.

  • You have the following privileges to access the Migration page:

    • Manage Outgoing Configuration Set

    • Manage Incoming Configuration Set

    Contact your security administrator for details.

  • Never make changes in the target or production environment while applying configurations.

    Note: If you make changes to the production environment in emergency situations, you must make the same changes to the test environment. Making the changes to the test environment ensures that these changes are included in the next configuration migration.
  • Don't make any changes in the source environment during the export process.

  • Delete any temporary files on the server from previous migrations. If there are temporary files on the server, click the Delete button next to your previous import and export records.

Register the Target Environment

  1. In your source environment, open the Manage Configuration Set Migration Target Security Policy task in the Setup and Maintenance work area.

  2. Enter the URL of your target environment. Use the full URL, including host and protocol information.

  3. Enter your user name and password.

  4. Click Save and Close.

Verify the Target Environment

  1. In the source environment, click Navigator > Configuration > Migration.

  2. Click the Environment Info infotile.

  3. Verify that the page displays the same URL as the target instance.

If you don't see the correct target instance, try registering it again.

Create Migration Set

  1. In the source environment, select Configuration > Migration from the Navigator menu.

  2. Click Create Migration Set from the Outgoing infotile. If you want to migrate all configurations instead of just the new changes, click the Create Full Set link for a full migration.

  3. Provide a name for the migration set.

  4. Optionally, type a description of the set.

  5. Select the content you want to migrate.

    Note: The Industry solution extensions module is for Oracle's internal use only and has no impact on migration.
  6. Click Save and Close.

  7. Click the Refresh icon periodically to see the current status of the set creation. You can click the Log icon to review the process log, which provides more details about the configurations that are being compressed. If an error or exception occurs during this process, the log gives you information about the configurations that failed to compress. The process runs asynchronously, so you can close the page and return to it later.

  8. Eventually, the status changes to Ready for Download, which means that the migration set is complete. You can click Content Read Me to download the Readme file listing all the configurations you exported.

    If you have registered the target environment, you don't need to manually download the migration set from the source environment and upload it to the target environment. You can sign in to the target environment, go to the Incoming infotile on the Migration page, and skip to step 4 of the next subsection. However, if you didn't register the target environment, or if the target was unreachable during export, continue to step 9 of this section.

  9. Click the Download icon to download your migration set. Ensure that the downloaded file is a JAR file.

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

Apply Migration Set

After you apply configurations, end users must sign out and sign back in to see the changes. So, apply configurations when fewer people are signed in to the environment. To apply configurations to the target environment, follow these steps:

  1. Open the Migration page in the target environment.

  2. Click the Incoming infotile.

  3. Click the Upload Migration Set link. Then, browse for your migration set file, and click OK.

  4. Review the roles in your migration set that are missing in your target environment, and create them if required. To review and create these roles, follow these steps:

    1. Click the Details icon.

    2. Select an application.

    3. Select the roles you want to create.

    4. Click Create Role, and click Yes.

    5. Click OK after the roles are created.

    6. Click Save and Close.

  5. Click Import to import your migration set into a sandbox instance in the target environment.

  6. Wait for the status to change to Successfully Imported.

  7. Optionally, click Preview to view your configurations in the sandbox preview mode.

  8. Click Apply when you're ready to apply your configurations to the target environment.

  9. Periodically, click the Refresh icon to view the current status of the apply action. You can review the process log, if required.

    The process runs asynchronously, so you can close the page and return to it. If problems occur during an Apply action, log a service request using My Oracle Support at https://support.oracle.com.ter.

  10. The migration set is successfully applied to the target environment when the status changes to Applied and Deleted.

Post Migration Tasks

Do these tasks after you apply your migration set to the target environment:

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

  2. Delete and recreate any web service connections in the target environment, using the target environment URL and credentials.

  3. Deploy all flexfields that display a Patched status.

  4. Do 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 configurations 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 this by disabling the object and enabling it again with its original status. For example, if the Enabled value is Manual, then you can do this:

      1. Disable the object.

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

      3. Click OK and save the changes.

    3. On the Manage Oracle Social Network Objects page, click Synchronize to synchronize a selected object, or click Synchronize All to synchronize all objects at the same time.

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

  6. If a new theme was created and applied in the source environment, and you want to use that theme in the target environment, then go to the Appearance work area and manually apply that theme.

  7. After applying configurations, perform functional testing to verify the changes. Suppose testing exposes problems with the configurations, such as importing more than you intended, or the changes weren't what you expected. In such cases, restore your environment to its pre-migration configuration.

    1. Open the migration set in the Incoming infotile of the Migration page.

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

  8. Finally, broadcast information to the users that they must sign out and sign in to view the most recent changes.

Things to Know About Migration

  • You can't restore your environment to an earlier configuration if the environment is upgraded after your previous migration. But 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 configuration 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.

  • Lookups can be migrated with both configuration migration, and setup data migration. However, once you use one of these methods, you should use the same method for all subsequent lookup migrations. Don't use both methods to migrate lookups between the same set of environments.

  • During migration, 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 configuration instance during the configuration import process and applied to the target environment.

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

  • You can't initiate a migration if you're in an active sandbox.

  • While an upload or restore activity processes Presentation Services changes, these things can happen:

    • 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 may not 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 these Oracle Business Intelligence Enterprise Edition features:

      • Oracle Business Intelligence Answers

      • Oracle Business Intelligence Delivers

      • Business Intelligence Composer

      • Oracle Business Intelligence Interactive Dashboards

  • When you restore your environment to an earlier configuration, you lose all personalizations you made after the previous migration.

Preview Mode in Unified Migration

After you import your configurations into the target environment, you can preview them in a sandbox instance before you apply them. But you can't preview all your configurations. You can only preview those configurations that are sandbox aware, and have no dependency on non-sandbox artifacts.

Note: When migrating configurations, make sure you have the appropriate administrator roles to view and test all your changes in preview mode.

What You Can See

The ADF module is the only module that's sandbox aware. As such, these MDS artifacts from ADF are available for preview:

  • Changes to existing custom objects

  • Pages

  • Workflows

  • Groovy scripts

  • Triggers

  • Lookups

  • Attachments

  • Data security

  • Strings

  • Web services

    Note: Though visible, these web services won't be functional because their connections aren't migrated.

However, if any of these artifacts have any dependency on non-sandbox aware artifacts, they won't show up in your preview.

What You Can't See

Artifacts that aren't part of the ADF module aren't visible in preview mode. Here are a few of those non-sandbox aware artifacts:

  • BI reports

  • BI custom subject areas

  • Functional security

  • New custom objects

  • Email templates

  • Workspace configurations

  • Notification preferences

  • ESS artifacts

  • SOA artifacts

  • Industry extensions

  • Analytics

FAQs for Migration

A delta migration moves only those changes that were made to an environment after the last migration was performed.

On the other hand, a full migration moves all changes made to an environment.

For instance, let's say Alpha is your source environment, and Beta is your target environment. You create object X in Alpha environment and perform a migration. Then, you create object Y in Alpha environment and perform another migration. If the second migration is a delta migration, only the object Y is moved. However, if it's a full migration, both the objects X and Y are moved.

You can do a delta migration if you meet these three conditions:

  • You have registered your target environment in your source environment, without any issues.

  • You have enabled Unified Sandboxes feature in both source and target environments.

  • Both of your environments are still synchronized.

Why aren't my environments synchronized?

Your environments may not be synchronized if you did either of these things:

  • Directly configured the target environment.

  • Upgraded one of the environments or both of them.

If your source and target environments aren't synchronized, you need to do a full migration to synchronize them again.

Configuration Management

Considerations for Exporting and Moving Configurations

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

  • To move configurations 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.

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

Tasks Tools to Use

Move all configurations to another application environment.

Configuration Set Migration.

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 Configuration Set 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 Configuration Set 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 Configuration Set 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 configurations to a file to help diagnose an issue.

Manage Configurations dialog box.

Downloading Configurations

You can download all configurations of a page for all layers using the Download Configuration for All Layers link in the Manage Configurations dialog box. To open Manage Configurations dialog box, click your user name in the global header, and select Manage Configurations. The file you download contains all the configuration XML files for the page. However, you can't upload this file anywhere.

Downloading Configuration Set Reports

After exporting configurations, you can view and download a configuration set report that contains a list of all configurations available in a configuration set. To do so, click Content Read Me from the Outgoing tab of the Configuration Set Migration page. To open the Configuration Set Migration page, select Configuration > Migration from the Navigator menu.

This report includes all new or updated:

  • Objects

  • Fields

  • Pages

  • Business intelligence (BI) changes

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

Download Configurations From a Page

Let's say the configurations you made to a page resulted in an error. You need to download the configurations you made to that page to diagnose what went wrong. You can use the Manage Configurations dialog box to download all the configuration XML files for that page. The downloaded files contain the changes made to all the layers of that page, and you can use them to diagnose configuration issues.

Download Configuration Files

Do you know the file path to the page you want to download configurations from? If you do, then follow these steps:

  1. Click your user image or name in the global header, and on the Settings and Actions menu, select Manage Configurations.

  2. In the Search field, enter the file path to your page and click the Search icon.

  3. Click Download Configuration for All Layers.

If you don't know the file path, then follow these steps:

  1. Create and activate a sandbox.

  2. Go to the page you want to download configurations from.

  3. Click your user image or name in the global header, and on the Settings and Actions menu, select Edit Pages.

  4. Click the Structure tab.

  5. Click any component on the page.

  6. In the confirmation window, click Edit.

  7. Go back to the Add Content tab.

  8. Click Manage Configurations.

  9. Scroll down and click Download Configuration for All Layers.