Last week during a client meeting to evaluate a new project, a question came up — “If JPivot does all the MDX generation/parsing,   provides the UI components for charts and grahps and tables — what is it that OpenI does that’s different from JPivot?”

A legitimate question indeed.

First off — this is not attempt to trivialize what JPivot does. We wouldn’t be here without JPivot – period.  This post is more about what OpenI does to improve certain JPivot functionality and what OpenI adds in terms of its own features to deliver OpenI as a complete web application.  Here’s my assessment:

JPivot is a component (JAR file), OpenI is a complete deployable web application (WAR). JPivot is one of the many components that OpenI uses
JPivot provides the following key features
o UI components for tables and charts using OLAP data, and specifying reporting parameters
o MDX query generation based on UI events like drill up/down, filter, sort, etc.
o Representing the results from an OLAP server in an object model
OpenI makes the following significant improvements to JPivot
o JPivot is built for open source OLAP server Mondrian. It CAN NOT communicate with Microsoft OLAP server out-of-the-box. OpenI extends JPivot to enable this feature.
o JPivot’s native UI is not so clean and pretty archaic (See screenshots here – http://jpivot.sourceforge.net/temp-N101F1.html). OpenI improves on this quite a bit (see OpenI screenshots here – http://sourceforge.net/project/screenshots.php?group_id=142873)
OpenI adds following key features for a complete BI app that are not in JPivot
o Security – either via its own user management, or by integrating to existing OLAP or custom authentication. Enabling restrictions to analyses based on user permissions
o Dashboard – Jpivot doesn’t have one, OpenI has complete dashboard creation and management
o Create/Save reports– Jpivot doesn’t have a way to persist reports. OpenI provides a well defined XML structure (.analysis files) that works as a report definition language (RDL) to save and manage reports. Also supports the notion of public vs private reports
o Navigation – OpenI provides a full file-explorer like UI to navigate through multiple analyses and manage them in folders
o Report customization by dragging/dropping attributes to columns, rows, and filters
o Tabbed view of tables and charts
o Provides results of an OLAP drillthrough as a text file dump (JPivot can’t), or publish result set to a custom web API
o Explore data feature – lets you “eyeball” data in a cube without having to create individual reports, very handy for exploratory analysis
o Concept of “projects” to enable multi-tenant reporting, i.e. same application can serve multiple clients. Responsys leverages this to have multiple client accounts served separately from a single web application instance
o Administration UI to manage accounts, application, data sources, and many other tasks that you’d otherwise have to do by hand-editing a configuration file
  • JPivot is a component (JAR file) that you can embed in a J2EE application, OpenI is a complete deployable web application (WAR). JPivot is one of the many components that OpenI uses
  • JPivot provides the following key features:
    • UI components for tables and charts using OLAP data, and specifying reporting parameters
    • MDX query generation based on UI events like drill up/down, filter, sort, etc.
    • Representing the results from an OLAP server in an object model
  • OpenI makes the following significant improvements to JPivot
    • JPivot is built for open source OLAP server Mondrian. It CAN NOT communicate with Microsoft OLAP server out-of-the-box. OpenI extends JPivot to enable this feature so users can report on data from both Microsoft Analysis Services (all 3 versions – 2000, 2005, and 2008)
  • OpenI adds following key features for a complete BI app that are not in JPivot
    • Security – either via its own user management, or by integrating to existing OLAP or custom authentication. Enabling restrictions to analyses based on user permissions
    • Dashboard – Jpivot doesn’t have one, OpenI has complete dashboard creation and management
    • Create/Save reports– Jpivot doesn’t have a way to persist reports. OpenI provides a well defined XML structure (.analysis files) that works as a report definition language (RDL) to save and manage reports. Also supports the notion of public vs private reports
    • Navigation – OpenI provides a full file-explorer like UI to navigate through multiple analyses and manage them in folders
    • Report customization by dragging/dropping attributes to columns, rows, and filters
    • Tabbed view of tables and charts
    • Provides results of an OLAP drillthrough as a text file dump (JPivot can’t), or publish result set to a custom web API
    • Explore data feature – lets you “eyeball” data in a cube without having to create individual reports, very handy for exploratory analysis
    • Concept of “projects” to enable multi-tenant reporting, i.e. same application can serve multiple clients. An on-demand  can leverages this to have multiple client accounts served separately from a single web application instance
    • Administration UI to manage accounts, application, data sources, and many other tasks that you’d otherwise have to do by hand-editing a configuration file
While thinking about JPivot, it is important to realize it is performing 2 key, yet different, aspects of dealing with OLAP data – one is UI, and the other more understated part is the bit about MDX generation, parsing, and providing an object model for OLAP result set. If you look at how JasperReports and Pentaho deal with OLAP data, they leverage JPivot as well. This poses a problem that if we want to improve or replace our UI layer with something else, it is not as clear cut since the layers are not clearly separated. Ideally, we would like to have the option of replacing the UI portion of JPivot, while preserving its MDX generation/parsing features.
Julian Hyde, the project lead of Mondrian project, has started a new project Olap4J that builds on this concept, so that could be the next step in this evolution, which we are considering as we plan the roadmap for OpenI 3.0. Stay tuned for more on that.
Sandeep