Complex   Reports:   Cell-Level Commentary     
       
          A Guide for IT Managers and Business Analysts  

 

 

 

Introduction

 

Cell-level commentary within reports is become increasingly popular within many larger businesses as the “modus operandi" of social media begins to have an ever increasing impact within the corporate world. The range of functionality that users request typically includes a means to:

 

*  Easily determine whether a cell in a particular report already has a comment, without the presence of a comment intruding unduly on the display of the data;

 

*  Quickly review the text associated with a comment;

 

*  Create, or add, text to an existing comment and associate a priority or category with it, together with the automatic identification of the cell value, dimension members, timestamp, data version, and originating query (if the report is customizable);

 

*  Store the comment in a platform agnostic manner - most corporates will host multiple reporting suites from different vendors and will wish to view comments by business area irrespective of the platform used to create them; and

 

*  Search the commentary store using various attributes, such as commentary category, date range, report name, or author.

 

 

Cell-Level Commentary within Answers & Dashboards

 

OBIEE does offer some rather unfriendly “write-back” functionality that allows a user to change the value displayed in a report field and write it back to the data source, but few organizations would find it adequate for the purposes of developing a system for cell-level commentary. While various other mechanisms are available for transferring data to a commentary store, such as an “Evaluate” call to a PL/SQL stored function or the use of the PL/SQL gateway, here, we’ll focus on what’s possible using JavaScript when it comes to commentary creation and review.

 

A cell with a comment needs to be distinguished in some manner; for example, by font colour and the underlining of the cell’s contents.

            *
      Identifying Cells with Comments

 

For commentary review, the most common method is to move the mouse over a cell with a comment, so that the “onmouseover” event causes the associated comment to be displayed, with a suitable offset from the cell as in the following example.

            *
      Comment Review

 

To create a new comment, or review an existing one, the most common method is to click on the cell value, so that the “onmousedown” event raises a pop-up window, as in the following example.

            *
      Comment Creation

 

In this case the cell value has been automatically transferred to the comment window, obviating the need for the user to cut and paste the value. The value can then be automatically stored against the comment. Other information, such as the associated dimensional members, “Brand” and “Product Type” in this instance, could also be collected automatically, as could the timestamp and the user identifier. To record the version of the data in the database, ETL processes would need to update some database table column following each update, and that column value would need to be exposed in the report (perhaps as a hidden field). In the case of a parameterized report, the data displayed will depend on the filter values selected by the user (usually by means of a set of dashboard prompts). In most cases it should be possible to use JavaScript to automatically capture all the relevant information needed to determine the context of a comment, so that the underlying raw data that has been summarized in the cell value can be identified and analysed if deemed necessary.

 

The downside to implementing cell-level commentary is that the JavaScript required can become very complicated as the web page events that are used to manipulate commentary are also used by OBIEE for other purposes. It will be necessary to reverse engineer the in-built and undocumented JavaScript functionality that OBIEE uses to facilitate user interactivity (such as that used for highlighting, sorting of table rows, and the moving of table columns). The cascading and bubbling of JavaScript events will then need to be interrupted and overwritten in an appropriate manner (using event handler functionality such as “stopPropagation” or “cancelBubble” according to which vendor’s browser is in use and its version).