In my department, we frequently have multiple teams working simultaneously on 2-3 features within the same APEX application, with each feature scheduled for release at different times. This results in maintaining multiple versions of the application across different environments. In the past, I've observed that teams often use Server-side Conditions to control feature visibility - specifically, APEX objects are hidden or shown based on the environment name (like DEV or TEST). I've show my colleagues that there is a better way to achieve the same result: using the Build Options and now everyone is using it.
What is this Build Options about?
It is an Oracle APEX feature that allows to conditionally include or exclude application components and functionality. One application can have as many Build Option as we want but only one can be assigned to a specific component or functionality.
We create / update /remove Build Options in Shared Components 🠆Application Logic 🠆 Build Options
Every Build Option we create must have a:
Name - should be meaningful for the purpose
Status - is referring to how the component is consider in an environment. It has two possible values: Include - meaning that the Application Express engine recognizes it as part of the application definition during runtime - and Exclude - meaning that the Application Express engine treats it as if it did not exist.
Default on export – is the status to be consider when application is exported and then imported in another environment.
On Upgrade Keep Status – indicate what is happening
when the application is upgraded: Yes - build option status in the
deployed application should be kept, No – build status is overwritten
with the specified status when the application is upgraded.
Application components and functionalities can be associated to a specific Build Option using ‘Configuration’:
The following components support Build configuration: Pages, Regions, Items (applications or page), Buttons, Menu entries, Processes (applications or page), Dynamic actions, List of Values
Note: Pre-APEX 23.x: List of Values did not support Build configurations.
Starting with APEX 23.x, there is a special Build Options named Comment Out, included by default in every new APEX application. We use Comment Out for the elements we want to exclude for good from application but we don't want to delete them yet. This is a very useful replacement of the Server-side condition "Never".
For a component "Commented Out" we can simply revert the setting with the "Uncomment" option.
Note 1: I did mentioned above that every new application created in APEX 23.x or above has the Comment Out created automatically. For applications created prior to APEX 23.1 the upgrade to a newer APEX version do not create automatically this Build Option. There is a simple trick we can do, to benefit the feature in applications developed in an older APEX version: we simply create a Build Option with the name "Commented Out" (pay attention at spelling!) and ...boom...the option appears like magic in the context menu.
Don't forget to set the correct status (exclude), the default setting to exclude on export and not to keep status on upgrade, as below:
Note 2: If an APEX component, configured with an Exclude Build Options, is referring a database object then the database object may not exist in the environment.
We may delete anytime the building option and/or the associated components.
"Delete" a build option removes the Configuration property from the Associated components.
"Remove Components" from a Build Option actually deletes the APEX objects which have set the configuration to that build option.
Important! Don’t Remove Components from an Include Build Option!
How we can use the build options?
Scenario:
The team develops new features which will be released in 2 steps: in Release_1 and in Release_2. The team is well ahead with the development, having everything for Release_1 finished, and are halfway done with the development for Release_2.
Steps
1. Create build options: We need to define as many build options as needed to cover the requirements: for our scenario, we need 2: Build_1 and Build_2
2. Set the configuration the components and features according to the release number they belong.
3. Set the proper status for the Build Option: for our Scenario, these will be:
Release_1: Build_1 Include; Build_2 Exclude
Release_2: Build_1 Include; Build_2 Include
Recommendation: to understand better how to correctly set the Build Options status and how to switch between Include and Exclude for different environments, create a simple demo application, follow a scenario that involves 3 different versions of the application in 2 environments and inspect the results.
Summary
Use Build Options every time you have in development at least 2 versions of the same APEX application. Don't use anymore the Server Side Condition " Never" to exclude components, use Comment Out Build Option instead.
Read more about: Using Build Options to Control Configuration
