WORKING COPY Procedures in Oracle APEX

 

Introduction
You're an Oracle APEX developer. When you want to make significant changes to an existing application without interrupting the live version, the Working Copy feature is your best option. It provides a safe space to build, test, and refine changes before merging them back into production. This approach supports agile development and promotes application stability, especially when working in teams or deploying new features.

Understanding and Using the Working Copy in Oracle APEX

What is a Working Copy?
A Working Copy is a cloned version of your APEX application that exists independently from the live version. It allows you to make updates, perform testing, and evaluate changes without affecting users. Once you're satisfied with the updates, you can merge the Working Copy into the production application.

Steps to Create and Use a Working Copy

1. Creating a Working Copy

• Log into your Oracle APEX workspace.

• In the App Builder, locate the application you want to work on.

• Click on the application to open it.

• In the right menu, go to Manage and choose Create Working Copy.

• Enter a name for your Working Copy. This should be descriptive, such as "Customer Portal Redesign July 2025".

• Click Create. APEX creates a full clone of your application, which you can modify separately from the production version.

2. Editing the Working Copy
Once created, the Working Copy will appear in your App Builder list alongside your live applications. Open it just like any other application. You can:

• Add or remove pages

• Modify page layouts and logic

• Adjust authentication and authorization schemes

• Change data source settings

• Add new plugins or shared components

Any changes made here do not affect the production application until you explicitly merge them.

3. Testing Changes
Use the Run Application button from within the Working Copy to preview and test your updates. Because the Working Copy uses the same data as the live app (unless otherwise configured), it's an excellent environment for realistic testing.

4. Merging the Working Copy
When you're ready to deploy the changes:

• Open the live application in the App Builder

• Go to Manage and select Merge Working Copy

• Review the list of modified components and differences

• Select which changes to merge (you can choose to exclude certain items)

• Complete the merge to apply updates to the live application

5. Deleting a Working Copy
If you decide not to move forward with changes, you can safely delete the Working Copy:

• In the App Builder, select the Working Copy

• Go to Manage, then click Delete Working Copy

• Confirm deletion. This action does not affect the live app

Example Use Case
Suppose your team wants to redesign the dashboard of your Sales application. You create a Working Copy called "SalesApp New Dashboard", build the new layout, add charts, remove unused regions, and integrate a new REST data source. After full testing and approval, you merge the Working Copy back into the live version. This entire process happens without disturbing users.

A Working Copy enables developers to create a special copy of an application, make changes in the copy, and then merge those changes back into the main development application (or Main application). Similarly, you can also merge changes from the Main application back into the Working Copy. During the export process, you can view a comparison (or diff) of the Working Copy and the Main application and then select which changes to merge.

A common use case for this feature is when you want to test some changes on a page first and then merge them back into the Main application later.

About the Comparison Process

When you compare a Working Copy to the Main application, a split YAML export is taken of both applications and a checksum is generated on the individual files. The working copy is exported with original IDs to ensure that the IDs are the same between both applications. The checksums are then compared to identify the differences between the two applications.

About the Merge Process

The merge process takes a subset of pages and shared components from a Working Copy and imports them back into the Main application. If the page or shared component exists, it is replaced. Therefore, changes in your Main application that are not in your Working Copy will be overwritten by the Working Copy merge.

Unsupported Component Types

Working Copies do not support the automatic merging of the following component types:

• Translations

• Themes

• Theme Templates

• Supporting Objects

• Application Properties

• Workspace-level components (such as App Groups, Credentials, and Remote Servers)

For unsupported component types, Oracle suggests developers merge the working Working Copy, delete it, and then manually apply the additions or changes for the unsupported component types.

Limitations of Working Copies

Limitations of Working Copies include:

• You cannot create a Working Copy of a Working Copy.

• Deleted working copy pages or Shared Components must be manually deleted in the Main application.

• Components listed as Missing may have been removed in the Working Copy or may only exist in the Main application.

Best Practices

• Always name Working Copies clearly (include date or purpose)

• Use only one Working Copy at a time per developer to avoid conflicts

• Communicate with your team to coordinate Working Copy usage

• Test all functionality thoroughly in the Working Copy before merging

• Export your application before merging as a precaution

• Avoid editing the live app while changes are underway in a Working Copy

Oracle APEX Documentation
For full guidance from Oracle, visit:
https://docs.oracle.com/en/database/oracle/apex

Conclusion
Working Copies in Oracle APEX offer a controlled, professional approach to application development. Whether you are refining UI elements, integrating new features, or restructuring core components, using a Working Copy ensures your changes are tested, validated, and safely merged. It is a fundamental part of a stable and maintainable APEX development workflow.