When using Conditional Formatting in Answers I was unable to refer to repo vars

Is it possible to refer repository variables in filters of conditional formatting?


Can use presentation variables only for filters in conditional formatting as per the following bookshelf guide:

Oracle Business Intelligence Answers, Delivers, and Interactive Dashboards User Guide > Basics of Working with Requests in Oracle BI Answers > Using Variables to Display Values in Request Results, Dashboards and iBots

Turned out to be a bug.

Workaround using Bins:

Say you had a dollars measure column in your request. And you wanted to add a conditional formatting to set it to green if it was greater than or equal to repository variable repvar1:
– Create a duplicate column dollars in the request and name it dollars_duplicate.
– Set the column format for dollars_duplicate to hidden
– Set the custom heading for dollars_duplicate column formula to ‘dollars_duplicate’
– Create a bin e.g. ‘b1′ based on a filter condition where dollars_duplicate is >= repvar1 – Then go to your required column e.g. dollars and add conditional formatting based on dollars_duplicate column. And in the filter condition set it to the bin name ‘b1′ and specify the ‘edit format’ as green in colour.

You can similarly add all the required conditions as bin condition first and then reference the respective bin name for conditional formatting.

AGO bug on OBIEE – very annoying

There’s a bug in OBIEE that renders time-series OBIEE function AGO useless if you’re using Filter on Logical Table Source (Content – WHERE). Apparently, the query generating AGO doesn’t pick it up and as a result – you will not see correct report. It might affect you in many ways if you’re using the LTS filters. The fix that Oracle suggested was to upgrade to, however, it’s not possible at the moment. We’ve created database views applying necessary filters there. Performance-wise we got a hit, but our business intelligence server is showing correct data.

Using aggregate tables produce incorrect Year-to-date at the lowest levels.

Applies to:
Business Intelligence Server Enterprise Edition – Version: 7.9.5 [AA 1900] – Release: V7
Information in this document applies to any platform.
The user is modelling Time Series functionality (Todate) with aggregated dimensions and aggregated facts using BI Server

You have created aggregate tables. You have both Logical Dimension and Fact tables mapped to the Aggregate tables.
In Answers you have built a report using the Dimension Hierarchy, which has the measures Sales and Sales YTD. When you drilldown in the report, the measures show the correct figures, until you get to the lowest level where the Sales YTD results are incorrect.

The cause of this incorrect aggregation when you drilldown to the lowest level of the hierarchy has been determined to be an incorrect sql being generated. The incorrect sql generated lacks the

The main difference is that when you are at the lowest level of the aggregate table it doesn’t use “SUM..GROUP BY” in it’s core query.

The issue has been determined to be a Bug, as per Engineering who reviewed the issue.


However a workaround was provided for this specific customer scenario that resolved the issue. With the implementation below which engineering tested and verified the SUM and Group by was generated in the sql when drilling into the lowest level of the hierarchy.

I created a dimension that I just created in the business model and added the additional dimension to the content filter for the problem fact source. That resulted in SQL generation with a SUM clause. My workaround was used just for the problem query submitted. I did not even join the new dimension to the fact table.

So I would recommend creating a virtual dimension in the physical and business model layers. It should not be exposed in the presentation catalog.