OBIEE Step by Step Guide

March 5, 2010

Combining OBIEE Answer Requests in Presentation Layer

Often, the OBIEE repository development is run in one phase and any presentation layer changes and creating new OBIEE requests/ answers is done in the next phase. Does this raise any problems? Of course, Yes. BI is supposed to be developed iteratively and it makes great sense for BI projects. Reason being business often doesnot conform to the final format of how their reports should like. Business Analysts are more concerned about data collection, data modeling and less concerned about presentation in your first phase. Business Stakeholders often does not know the capabilities of your BI tool. We can find multiple reasons to blame each other but one thing for sure is that the business stakeholders will finally look at your iteration 1 reports and likes to add some new features (nice to have) and you are back modifying the reports that you thought are complete.

Lets get back to our initial discussion; Doing iterative development in OBIEE makes sense in multiple ways. Often, the complexity in representing data is handled in your presentation/answers. Is this good? No. Often the business logic should be pushed to your business layer. It makes complete sense.

With a recent review of one of my colleague’s project which was done in traditional waterfall SDLC methodology, the Reports Developer was banging his head to get all the business logic embedded in the answers request. The repository developer finished developing his repository, creating aggregates, creating time awareness and creating hierarchies. RPD developer is out in phase 2 of the project and no repository changes were allowed in this phase. Being an 75/25   onsite/offsite project with resources across the world and everyone being consultants, no body cared about performance, database loads and dashboard performance for the long run.  

Finally, this situation lead to a peculiar situation of how do we combine various answers requests. Lets start looking at different ways OBIEE answers can be combined together to make meaningful business reports.

1. In one of my previous blogs, we talked about how we can use one OBIEE answers request to help the other OBIEE answers request either to display or not using OBIEE feature of Guided Navigation. Follow this link

2. This is done at the report level while creating your answers request. Lets go through this exercise together. Create an OBIEE answers request as shown below.  There are some pre-defined conditions based on which a report has been developed. Lets look at those conditions.

If you look in here, we are looking at DW_Insert_date to be in top 10 percent and plant code starting with ‘FW’ and base product codes ending with ‘P’ and formula number between 100 and 500. These ae maintained as constants. Consider this as your base report and we shall refer this as base report from now on.

The requirements for the second report always happens to be picking up the formula numbers that are in base report. The question comes down to why not replicate the filters that are in report 1 into report 2. But what if the report 1 is a easy maintenance report where the numbers (constants used in filters keeps changing). So, lets think that there is no other go. In such a situation, we are bound to build our second report based on results in first report.

Follow the diagrams below and you will get there…. take my word for it 🙂

Choose the first option “Filter based on Results of another request” in the below diagram.

I have chosen the scenario where the formula number is equal to any values from base report. In the “Saved Request”, browse to the base report and once you browse the base report, your drop down for “Use Values in Column” will be populated with all columns of base report.

As always, kudos to all OBIEE evangelists and report your comments below if this is helpful.

Any further tips you can add in comments is also welcome 🙂

Also, if you have few more seconds, can you answer this poll..

Older Posts »

Blog at