Introduction

In one of the previous article (link here) we have learnt about Sandbox (Definition, Usage and Impact) in Oracle Fusion Applications. However, there are certain limitations with this and hence there is a new enhanced feature named “Unified Sandbox” which is available starting Release 13 19C (optional feature), the same feature becomes a delivered one starting 19D. In this article we would try to learn about Unified Sandbox.

Unified Sandbox

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.

Supported Sandbox Operations

Sandboxes support the following operations:

You must first sign out and then sign back into your application when you perform the following operations:

• Activating a sandbox.
• Exiting a sandbox.
• Publishing a sandbox.

Importing Sandboxes

Don't import sandboxes. This operation is reserved for Oracle internal development only.

Enable Unified Sandbox feature

To use Unified Sandboxes instead of the default sandboxes, opt in to the Unified Sandboxes feature.

Before you start, consider these points:

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

• When you use Application Composer in your Unified Sandbox, an object can only be edited in a   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.

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

• Functional Area: Application Extensions
• Feature: Unified Sandboxes

Create and Activate Unified Sandbox

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.

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.

• Click Navigator > Configuration > Sandboxes.
• On the Sandboxes page, click Create Sandbox.
• Enter a name and description for your sandbox.
• 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.
• 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.
• Click Create to just create the sandbox, or Create and Enter to enter or activate the sandbox after creating it.

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.

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.

Working Mechanism of Refresh and Merge Processes

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

If two users are working on two different sandboxes (say Sandbox1 and Sandbox2) at the same time then there are some changes which will be merged in Sandbox2 considering Sandbox1 is already published. To bring the changes made to second sandbox (Sandbox2 which is unpublished one) we would need to create another sandbox make the changes and publish it.

Options to Open Configuration Tools in 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.

Resolving 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.

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.

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).
• 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.
4. Click Continue to Publish. The sandbox is published to the mainline metadata.
5. Click Done.

Ashish Harbhajanka

Add comment