This proposal is inspired by two core functionalities. First, the robust Project functionality in the legacy OBIEE RPD (Administration Tool), which allowed for object-based organisation and logical isolation of metadata. Second, the Tagging capability within the previous Branching Framework, where developers could tag up to a specific set of steps to identify distinct changes from the branch merge. The goal is to evolve these concepts into a unified governance tool that persists after merging, allowing the system to treat a group of changes as a single, removable sandbox "Project" entity rather than just a linear list of steps.
Problem Statement
The current FDI Sandbox Framework allows for parallel development, but once a sandbox is merged into the Main branch, its unique identity is lost. The metadata changes become part of a linear, "tangled" sequence of steps in the Main model.
The Pain Point: The Failed UAT update.
In a multi-developer environment (e.g., Developers A, B, and C working in separate sandboxes), Sandbox A and B may be merged to Main and promoted to UAT. If UAT for Project A fails, there is no automated way to "decouple" Project A from the code.
Currently, this requires manual decoupling exercise and fixing forward. A tedious, difficult, and slow manual process of identifying and deleting every logical column, join, and calculation associated with the failed test which is part of merged custom sandbox development feature.
Manual deletions often leave orphaned objects or potentially dependencies or code removal could be missed. The risk is unwanted code in to Production. This increases the risk of breaking something else that was working before.
Proposed Solution - Universal "Sandbox Tags" & Automated Decoupling..
Oracle should introduce a Global Sandbox Tagging mechanism that functions as a "DNA strand" for every change made across the platform:
- Mandatory Sandbox Tagging: When creating a Sandbox or a Security Configuration step update, developers assign a Project ID. Every metadata object addition or update (Semantic Model) and every data filter (Security Tab) created or update within that scope inherits this tag.
- Persistent Object Identity: These tags must persist after the merge. The system should "remember" that Logical Column X and Security Filter Y both belong to PROJ_FIN_001, even when they sit in the Main branch. And Calc X update is part of PROJ_FIN_001
- One-Click Decoupling (The "Un-Merge"): Provide a "Decouple Project" utility. If a project fails UAT, an admin can select the Project Tag, and the system automatically identifies and removes all associated metadata steps AND security filters in one unified action.
- Security-Metadata Lockstep: Ensure that if a metadata object is decoupled, any associated security filter tagged to that same project is automatically deactivated or removed, preventing orphaned references.
There is an additional topic of the External Application RPD, but as is managed separately and can be deployed independently, it's less of a concern of me at the moment. It can be tied to the Bundle Export to be conscious of during deployment.
