APEX Application Export: Supporting Objects and Static File Parity

Repeatable Environment Configuration

Oracle APEX application exports provide the primary mechanism for migrating page definitions, shared components, and Supporting Objects scripts between environments. However, maintaining parity across workspace and schema boundaries involves several non-deterministic behaviors regarding object installation and asset capture.

Asset and Metadata Constraints

Static Application Files are embedded as BLOBs within the export, which limits version control visibility. Furthermore, Static Workspace Files are not included in individual application exports, requiring separate workspace-level actions to ensure full environment synchronization.

Execution Order and Identifiers

The execution of Supporting Objects scripts during import depends on the "Install Supporting Objects" setting and the current state of the target schema. This can lead to inconsistent results if the target already contains partial objects. Additionally, metadata such as security group IDs and owner references are baked into the export, and major version upgrades may reset internal component identifiers.

What is the supported method for ensuring deterministic execution of Supporting Objects when the target schema contains existing objects? Which configuration or API flags reliably include Static Workspace Files to achieve full workspace parity? Does alias-based import prevent the reset of internal component identifiers during major version migrations?