The EBR Compliancy Tool¶

Note: This feature will be available with IFS Cloud 25R2 GA. However, any preparation work required needs to be done starting from EA.

This tool ensures that the database always remains in an EBR-complaint state.

The Key Rules¶

Every table must have an Editioning View (EV)¶

Editioning Views act as a stable API layer between application code and underlying tables.
This ensures schema changes (adding/removing columns, renaming, etc.) can be managed without breaking dependent objects or application code.

Only Editioning Views can reference real tables¶

No PL/SQL, views, or other objects should directly reference a physical table.
This rule enforces strict decoupling and allows us to evolve the table structure without invalidating dependent objects.

Every Materialized View must have a synonym¶

Synonyms provide an indirection layer, allowing us to seamlessly replace or redefine materialized views across editions without impacting application code.

All editionable objects must be created as editionable.¶

Objects such as PL/SQL packages, functions, procedures, views, synonyms, and triggers should always be created with the EDITIONABLE keyword.
This ensures they can safely exist in multiple editions, supporting rolling upgrades.

The EBR Compliancy tool is integrated into the Build Place processes. It will be run as part of the cleanup stage of every installation. This guarantees that our database consistently adheres to EBR compliance.

Identifying and Fixing EBR Compliancy Issues¶

In the Build Place, if compliancy issues are detected, it will result in build failures. To identify this, you need to get the build logs and navigate to the database_cleanup folder. Here, you can view the _ERROR_cleanup_install.log and _ebr_compliance.log files.

In the _ERROR_cleanup_install.log, you will see the error shown below.

The _ebr_compliance.log that has information on any compliance issues, will map to the rules mentioned above. You need to then address them in your current pull request.