Everything Oracle

Home

Everything Oracle

 

 

 

 

 

 

Overview

 

How easy is it to use Oracle’s BI Publisher?  How productive would your developers be if they were to use this product? 

 

BI Publisher’s design paradigm for transforming data from disparate sources into disparate output formats is the standard one adopted by EIA applications: convert the data to a canonical form via a centralised hub.  Input data is converted into an XML format and the instructions to format that data are converted into an XSL-FO format before report generation takes place.  This reliance on standards is to be welcomed, and it will ensure that new data sources and new output formats can be accommodated within BI Publisher at a modest cost to Oracle, future-proofing your investment.  So far, so good.

 

However, if your developers have to work directly with XML and XSL-FO it will result in a very poor level of productivity.  Ease of use in report development demands a WYSIWYG interface, with all non graphical functionality implemented cleanly by means of property sheets.  So, the productivity afforded by BI Publisher depends on how closely Oracle has come to achieving this design goal in the interface that it exposes to report designers.

 

Now, if Oracle’s marketing spin is to be believed, when it comes to productivity, BI Publisher is “the best thing since sliced bread”.  However, the reality is rather more nuanced.  Unfortunately, BI Publisher has a less than satisfactory implementation.  While some reports can be produced quickly, others may well see your developers leaving urgent messages on Internet bulletin boards in a search for some critical XSL or BI Beans formatting tags that are needed to customize the report output.  While simple reports can be produced easily, there will be a long learning curve before your developers are able to fully customize BI Publisher reports to match complex reporting requirements.

 

In the rest of this article I’ll try to justify these assertions, and I’ll suggest what Oracle needs to do to remedy the matter.

 

 

BI Publisher Components

 

The key flaw in the implementation of BI Publisher is that from a developer’s perspective it is not an integrated product with a single consistent interface.  Instead, it consists of four disparate components.  And to make matters worse, three of these components have been “outsourced” to MS Word, so what Oracle can do by way of implementation is constrained by what’s possible within MS Word.  While integration with MS Office is to be welcomed when it comes to delivering an application’s output – as is the case with the MS Office Add-in for BI Answers/BI Dashboards – to rely on a competitor’s product to implement a core design tool is certain to result in many unsatisfactory compromises.

 

The four components that a BI Publisher developer has to work with are illustrated in the following diagram (see the grey blocks):

 

Only part of the task of report development, and a relatively minor part at that, takes place within BI Publisher.  The rest takes place under the umbrella of MS Word.  Within MS Word, some tasks make use of Word’s native formatting capabilities.  In addition, some tasks make use of Oracle’s BI Publisher Desktop Add-in for MS Word.  This add-in contains wizards that speed up the definition of fields and charts within a template.  And, as a fall back position, for functionality not supported by the wizards direct editing of XSL and BI Beans formatting tags is available to fully customize a template.

 

BI Publisher report definitions are stored in a repository, either on a file system or within an XML DB datastore.  A report definition consists of a SQL query, or equivalent information, that defines the data to be used by the report; one or more templates that define how that data is to be formatted; together with configuration information that defines any parameters that are to be passed to the report, and any report bursting that may be required.

 

BI Publisher itself is an easy product to use, and handles the tasks of:

 

  Query Definition,

  Parameter Definition,

  Scheduling,

  Bursting, and

  Administration.

 

The report production process proceeds as follows.  First, an outline report and its associated query are defined:

 

Then the query is tested in BI Publisher to ensure that the query can retrieve some sample data in XML format from the relevant datasource:

 

This sample data preparation occurs automatically without any coding on the part of the developer.  Then the outline report is saved to the repository.

 

Now the developer moves on to the task of template creation.  The developer opens up MS Word, and uses the Oracle BI Publisher Desktop Add-in to logon to BI Publisher:

 

Then the developer opens the report that was previously created within BI Publisher:

 

Opening a report downloads sample XML data automatically into MS Word.  This sample data provides both an XML Schema to work with in defining the output mapping, together with data with which to preview the report.

 

The wizards within the BI Publisher Desktop Add-in are used to create the fields and charts that define the report structure:

 

And then MS Word’s formatting features are used to add boilerplate and to format fields.

 

So far so good, as far as productivity is concerned – it’s far from the clean and elegant design environment that developers are accustomed to working with in other reporting tools, but it’s still a reasonably productive development environment.  If the work done thus far has been sufficient to produce the final version of the template, then all is well, and the developer just has to upload the template to BI Publisher where it will be stored in the repository along with the query definition.  However, if further customization is needed and the direct insertion/editing of XSL and BI Beans formatting tags are required, then productivity begins to drop off sharply – as we shall see below.

 

Partly as a result of the constraints imposed by the MS Word implementation and partly due to inadequate product testing, developer productivity will suffer due to:

 

  No Property-Sheet Support for common Functionality,

  Poor Integration of Components,

  Inconsistent Rendering of Data in different Output Formats, and

  Lack of a common Interface with BI Answers.

 

These issues will be illustrated by way of examples in the following sections.

 

 

No Property-Sheet Support for Common Functionality

 

Let’s start with an example of one of the commonest chart types, a pie chart, and let’s assume that HR wants a pie chart that shows employee salary by department.  Now as part of the BI Publisher Desktop Add-in, Oracle provides the BI Publisher Chart editor:

 

This editor is easy to use.  But, unfortunately, there is no help available, so your developer will have to resort to trial and error to determine what some of the properties mean – not a good start.  So your developer sets the properties available within the editor and a preview reveals the following chart:

 

This chart, of course, is unacceptable.  Three decimal places for the percentage occupied by each slice of the pie chart is totally unwarranted, and in some places the over generous format causes neighbouring values to overlap – in percentage type displays, like this, the number of decimal places required is almost always either zero or one, making three a very poor choice for the default.

 

Also note that the algorithm used to automatically allocate colours to the pie slices has been badly designed.  It attempts to avoid allocating the same colour to neighbouring pie slices, but fails to appreciate that the first slice allocated is a neighbour of the last slice allocated, so that Accounting and Shipping slices neighbour one another, and end up sharing the same colour.  Do Accounting salaries amount to 3.8% or 11.1% of the total?  It’s possible to work it out from the ordering of the items on the legend – it’s 11.1% – but your end users won’t expect to have to carry out such “detective work”, and, even worse, they might easily misconstrue such a chart, leading, perhaps, to some unfortunate decisions – if Shipping is costing us 11.1%, we’d better cut some jobs from Shipping!

 

Let’s suppose your developer decides to reduce the number of decimal places shown on each pie slice from three to one.  He opens up the chart editor and examines the properties, expecting to find one that dictates the number of digits after the decimal point, but he’s disappointed.  Even a basic property like the number of decimal places to display is missing from the editor.

 

So, instead, he has to add a new set of tags to the underlying XML on which the chart is based.  Now, because Oracle has no control over the design of MS Word, in order to store the XML it has had to find some field that can contain a substantial amount of text and which is not used for any other purpose.  In this case, Oracle has used the “alternative text” field – a field that normally contains the text displayed when images are disabled within a web browser.  If your developer selects “Format Picture => Web” he’ll discover where Oracle has “shoehorned” the XML for the chart:

 

Now, your poor developer is supposed to understand this jumble of tags, and to insert new tags in the appropriate place.  Note, that no help is available to explain what the existing tags mean, and what other tags might be available to change the number of decimal places displayed.  The BI Publisher Desktop Add-in menu does sport a help facility, but this facility provides no guidance as to the meaning of these formatting tags.

 

If your developer is prepared to work through the 426 page “Oracle Business Intelligence Publisher Report Designer’s Guide” he will discover that the formatting tags used in BI Publisher charts are defined in the “BI Beans Graph DTD”.  But Oracle does not even have the foresight to include this document as an appendix to the Report Designer’s Guide.  Instead, all your developer is offered is a web link.

 

Your developer perseveres, and downloads the 23 page document, only to find it far from informative.  Here’s a small sample:

 

Extracting the relevant information from the “BI Beans Graph DTD” is largely a matter of trial and error.  In the present case, the BI Beans formatting tags that are needed to change the display are as follows:

 

<SliceLabel>
   <ViewFormat decimalDigit="1" decimalDigitUsed="true"
      decimalSeparatorUsed="true" />
</SliceLabel>

 

So now your developer has to insert them into the “tag jungle” at the appropriate location:

 

and, at last, the chart is displayed with one decimal place for each pie slice, as required:

 

Perhaps the most pertinent comment that can be made on the difficulty of tracking down the correct formatting tags is that many developers find it faster to post a request for help on an Internet bulletin board and wait for a reply, rather than trying to work their way through Oracle’s torturous documentation.

 

What Oracle needs to do here is to extend the chart editor to include properties for all possible BI Beans formatting tags, and to supplement these additions with help text that clearly explains what these properties mean.

 

 

Poor Integration of Components

 

The way in which some of the components of the BI Publisher Desktop Add-in are integrated would be deemed “slipshod” had the vendor been a small start-up company.  To illustrate this issue let’s follow on from the previous example, and assume that your users decide that the colours of the Regatta style of pie chart display are too dull, and that some bright April style colours would be more appropriate.  The change request is duly allocated to one of your developers, who opens the BI Publisher Chart editor, and selects the new style from the drop-down list.  A preview reveals a brighter set of colours:

 

All seems well, except that “our” three places of decimals has now mysteriously reappeared.  If your developer looks at the underlying XML he’ll see that the style has indeed been changed to April (see line 2), but that the custom tags added by the developer who first created the chart have been lost in the editing process:

 

Unfortunately, when your developer exited the BI Publisher Chart editor there was no message along the lines of “Do you wish to preserve the custom changes that have been made to this chart?”

 

So, in general, your developer will need to take the original copy of the report out of version control, determine what tags in the “tag jungle” were customized by previous developers, excise them, repeat the work he has already done, and then reinsert the custom tags.  Note, the above assumes that you’ve version controlled the BI Publisher repository in some manner, and that your developers have been instructed to add comments to the “tag jungle” to allow the customized formatting tags to be identified.

 

Of course, this scenario assumes that the developer recognizes that something is wrong with the chart, recognizes that some functionality has been lost.  In practice, developers will focus on the change that they’ve been instructed to implement, and there’s a good chance that a “botched” chart will go back into production, to be reworked yet another day.

 

 

Inconsistent Rendering of Data in different Output Formats

 

Let’s move away from charts, and focus on something as simple as boilerplate text.  When it comes to creating headers and footers the “Oracle Business Intelligence Publisher Report Designer’s Guide” tells your developer, “To create a header or footer, use the your [sic] word processing application’s header and footer insertion tools”.  So, let’s assume that your developer does just that and adds a header to the RFT template using MS Word’s “Header and Footer” toolbar:

 

This looks fine.  Then your developer previews the result in the PDF output format:

 

Again this also looks fine, so the modified report is placed back in the repository, and is scheduled to be burst to 10,000 shareholders worldwide, distributed in some regions by way of an attached PDF, and in others by way of HTML (both formats are valid for an RTF template).  Now, when your HTML shareholders open up their web browsers they are greeted with:

 

Needless to say, this faux pas says a great deal about your company, but, doubtless, it’s not quite what the authors of the shareholder report had in mind.

 

Now, of course, the report should have been inspected in all its variant formats before it was scheduled, but when a developer is asked to make a small change to a report, the temptation is strong to inspect just one variant, so errors like this one are bound to occur.

 

One of the “nice to haves” for software that offers bursting into multiple formats is some checking mechanism to ensure that whatever functionality is available to format a template will guarantee report consistency between different output formats – preserving tabs in a PDF output but losing them in an HMTL output is something that should never happen in well designed application.  Now the BI Publisher Desktop Add-in does contain a Validate Template menu item, but in the case of this report it offers up the falsely reassuring result of:

 

 

Lack of a Common Interface with BI Answers

 

Now, BI Publisher is supplied as part of OBIEE, and it is widely used along with the other OBIEE components, such as BI Answers.  If you think about it for a moment, using both of these products will require your developers to carry out very similar tasks, to format reports, to design charts, to specify report parameters, and to schedule batch jobs.  In fact, the only extra that is peculiar to BI Publisher is query definition (report bursting configuration is very similar to iBot configuration in terms of the multiplicity of destinations).  You might therefore expect that in the interests of minimizing the learning curve for your developers Oracle would, where possible, have implemented consistent sets of interfaces for carrying out similar tasks.

 

Now, to create a pie chart in BI Publisher your developers use this screen:

 

whereas to create a pie chart in BI Answers they use this screen:

 

To schedule a report in BI Publisher your developers use this screen:

 

whereas to schedule an iBot in BI Answers they use this screen:

 

Why, you might ask, should your developers have to learn how to use two different interfaces to carry out the same task, when, with some sensible consolidation, they would need to learn only one?

 

 

Summary

 

So, the conclusion to this sorry tale must be that BI Publisher and its “side-kick”, the BI Publisher Desktop Add-in, fall far short of providing a productive, developer-friendly environment.

 

While leveraging MS Word might have seemed like a good idea in principle, the fact that Oracle has no control over MS Word functionality is an Achilles heel as far as the BI Publisher Desktop Add-in is concerned.  But even taking this limitation into account, the BI Publisher Desktop Add-in remains a poorly implemented and far from productive application.

 

What Oracle needs to do here is clear.  It needs to integrate the BI Publisher / BI Publisher Desktop Add-in screens in with those of BI Answers to produce a consistent interface for common tasks, taking the best from both products.  Oracle has been careful to use the RTF format, rather than Microsoft’s “.doc” format, as the standard for converting report layouts to XSL-FO.  However, any editor that supports RTF (version 1.6 or later) will serve this purpose.  Oracle needs to incorporate such an editor directly into BI Publisher and abandon the troublesome Desktop Add-in (the editor could mimic the MS Word layout and functionality to leverage end user familiarity with Microsoft’s product).  Oracle would then be in full control of the interface: it could make the layout more developer-friendly and it could add checks to ensure consistency in the mapping to different output formats.  Above all, Oracle needs to ensure that editing of XSL and BI Beans formatting tags is rarely, if ever, required: a good set of property sheets accompanied by adequate help text is the answer.

 

While this article has been rather negative in its tone – and for very good reasons – it’s important not to lose sight of the benefits of BI Publisher.  It offers considerable flexibility when it comes to complex reporting and its standards-based design will make it easy to extend as new data sources and output formats become available.  Its faults – and they are many – lie in the current implementation.  We can but hope that Oracle will, in due course, see the error of its ways and address these issues by integrating the product more tightly into OBIEE.  We hope one day to be able to proclaim, “BI Publisher is dead.  Long live OBIEE!”

 

 

 

Everything Oracle

Home

Everything Oracle

 

Copyright © 2009 PWG Consulting, All Rights Reserved