Skip to content

EBR Preparations for Reporting

Overview

IFS Cloud 25R2 introduces the Uptime Maximizer feature, which is designed to minimize application downtime during deliveries. To enable this, the databases must be Oracle Edition-Based Redefinition (EBR) compliant, ensuring seamless online upgrades.

With Oracle EBR, database objects are categorized as either:
- Editionable – such as Views and Packages, which can have multiple versions across editions.
- Non-editionable – such as Tables and Materialized Views, which remain common to all editions.

Adopting EBR allows IFS to introduce schema changes or update application logic without significant downtime, making systems more robust and flexible.

In the context of Reporting, this requires adjustments to RDFs (Report Definition Files) to comply with EBR standards.

For a full introduction to EBR and its concepts, see the Oracle Edition-Based Redefinition (EBR) in IFS Cloud.

EBR Preparations for Reporting

Required Adjustments to Manual RDFs

To align RDFs with EBR requirements and decouple them from deprecated components:

  • Identify the affected code blocks

Search for Report_SYS.Should_Generate_Result_Set('&VIEW') in your RDFs to locate the relevant logic.

  • Remove data insertions, updations and deletions (DML) into _RPT suffixed tables

Removed the located Report_SYS.Should_Generate_Result_Set method call in the rdf and Remove the entire code line including variable declaration, and initialization. Carefully remove only _RPT specific insertions. If additional custom logic is present, retain only what is needed. These tables were only used for Crystal Report integrations and should no longer be populated.

do_result_set_   BOOLEAN := Report_SYS.Should_Generate_Result_Set('&VIEW');

Remove any code blocks which are inserting,updating or deleting data into _RPT suffixed tables. These data insertions could be inside IF conditions as well.

IF (do_result_set_) THEN
  Insert into sample_rpt...

  ...
END IF;

Once all specified code blocks have been removed, the changes must be committed to the relevant source control repositories.

  • Product-specific data handling

If your product requires data storage outside reporting needs, create separate tables following the General EBR Guidelines without using report specific _RPT tables. Do not use _RPT suffixes for product-specific tables to avoid conflicts.

Required Adjustments to Model based RDFs

Model-generated RDFs (RDFs generated directly from a marble model without manual modifications) require the following adjustments:

  1. Regeneration from the Model: The RDF must be regenerated from the source marble model using Developer Studio. This ensures that the RDF reflects the latest schema and logic updates defined in the model.
  2. Source Control: Once regenerated, the RDF files must be committed to the relevant source control repositories.

Testing RDFs for EBR (NZD Focus)

Testing ensures that RDFs behave correctly across editions and the changes are isolated to the new edition.

For Manually Created RDFs

  • Step 1: Make a visible change in order to Test the changes between EBR editions

Example: update a column comment in the RDF so it reflects differently in the IFS Cloud Report UI.

  • Validation

In the Report Parameters page → the change should appear only in the new edition. The old edition should remain unchanged.

  • Step 2: Modify XML generation code

Example: add a static XML element (TEST_CYCLE = NZDCHANGEV1) or remove an existing element.

  • Validation

Generate and download XML via the Report Data Ordering process in IFS Cloud. Confirm that the new edition’s XML reflects the change, while the old edition’s XML remains unaffected.

For Model-Based RDFs

  • Step 1: Add a new attribute to a report aggregate and regenerate the code.

  • Step 2: Inspect the RDF to confirm correct XML element creation.

<!-- Example: Added new attribute -->
<NewAttribute>SampleValue</NewAttribute>
  • Validation

Ensure report ordering, previewing, and printing work correctly across both editions. The new edition should reflect the intended changes without affecting the old edition.

Important Notes

  • You have to ensure that no new data is inserted, updated or deleted from_RPT suffixed tables from RDFs. Validate this as part of your RDF compliance checks.
  • If temporary or custom tables are used in RDFs, handle them in accordance with the General EBR Guidelines.
  • for any customized customer specific reports a script should be written to disable to set do_result_set_ = FALSE.

Key Takeaways

  • Remove _RPT insertions, updations and deletions to _RPT suffixed tables and adjust RDF logic accordingly.
  • Follow the instructions provided above in the Testing RDFs for EBR (NZD Focus) section to ensure changes only affect new edition.
  • For specific needs (outside to reporting framework) create separate tables and follow the general EBR guidelines (Do not use_RPT as a suffix in the new table names).