The Dev Donkey Blog

I posted this message today on the olap4j mailing list. In the interest of reaching a broader audience, I will copy it here as well.

Cheers!

Dear olap4j community members,

As we previously discussed on this mailing list, we are planning to make the final push towards a 1.0 specification. In order to perform those much needed changes and still maintain compatibility as much as possible, the olap4j team proposes the following transition plan.

• 4th week of July - Release of olap4j 0.9.8
  A first initial release, coded 0.9.8, will be performed during the days to come. This release is mostly a wrap-up of the unofficial releases we have put in the Maven repository. Notable changes include compatibility with SAP BW, contextual drill-through for the Query Model, along with various other compatibility fixes.
• Month of August
  During the month of August, the olap4j community will have a chance to comment the proposed changes to the 1.0 final draft. We will provide an updated functional specification document as well as a complete list of the changes that will be required. Should you judge that some items are still missing, or that some should be modified or removed altogether, you are encouraged to let us know. The mailing list is the best place to hold those discussions, or you can also use our forums.
• September 1st - Release of 0.9.9
  September 1st is the date that marks the end of our discussions. After that, all the changes that we agreed upon will be implemented in the API, as well as the Mondrian and XML/A implementations of the driver. The 0.9.9 release will include those changes, but will still maintain retro-compatibility. Some API calls will be marked for deprecation, new ones will be present as well. The 0.9.9 release will be the last available before 1.0. Everything that is marked for deprecation will be removed as of 1.0, so users will have a chance to convert their code base progressively.
• October 31st - Release of 1.0
  We are planning to release olap4j 1.0 on October 31st. All methods that have been marked as deprecated, whether by the 0.9.9 release or any other previous 0.X release will be removed.

A proposed updated functional specification document, as well as a detailed list of API changes will be sent in the following days, right after the 0.9.8 release. We strongly encourage the users of olap4j to express any concerns or ideas that might arise.

Sincerely yours

Luc Boudreau, for the olap4j development team

Last week I launched a spin off of the olap4j parser. Mdx4j wraps olap4j’s MDX parser and makes it available to code, without the need of an olap connection.

Why?

Although olap4j contains a SPI parser, we don’t want to promote any particular MDX syntax. I therefore packaged it as a separate project so that everyone can have a piece of the pie!

final String query =
“SELECT{} ON COLUMNS FROM CUBE”;

final MdxParser parser =
Mdx4jParserFactory.createMdxParser();

final ParseTreeNode tree =
parser.parseSelect(query);

http://code.google.com/p/mdx4j/

A colleague of mine once asked me if I knew a program that can connect to almost all relational databases and offers MsAccess like features to build queries. Sure thing says I. Wabit.

So he downloads it and installs it in 5 minutes. It’s free and open source. No hassle. He then creates his connections and manages to do everything he needs to fulfil his duties as a business analyst. Pretty kewl story, heh? Short too. But that’s a good sign because as a developer on this project, I can confirm first hand that this is exactly what we aimed for. Making business intelligence easy and painless.

The Wabit is more than that. It’s also an OLAP data warehouse browsing and reporting tool. It creates charts in 10 seconds and features a template engine for easy corporate branding. Version 1.0 will feature a server repository for multi-user collaboration and incremental saves, scheduling and fine grained security. The enterprise server is not open sourced though, but the Wabit client is a fully featured platform. You can still save all your queries and reports as an XML file for easy import and export and share it with your fellow co-workers.

The Wabit approaches 1.0 now. We need to reinforce the community around it and we need more feedback. The Wabit works on all platforms with a Java JVM, so whatever your background is, I’m sure that we can make good use of your comments or contributions. You are a GUI designer or a BI consultant or even just the regular Java developer, we have need of your help.

Wabit on Google Code
Wabit homepage

(more…)

During my monthly checkup of this blog analytics data (thank you Google Analytics), I discovered a new trend. More and more, people are searching for information on olap4j’s compatibility.Here are the interesting keywords used and the number of occurrences for the last month.

• “olap4j ruby” - 28 occurrences
• “olap4j oracle” - 3 occurrences

Oracle; I can understand. Olap4j is picking up momentum and is more widely adopted. We support both Microsoft Analysis Services and Mondrian via XMLA. Oracle does have an XMLA server, Hyperion Essbase, although we never tested it with olap4j. If one of you reading this post happens to be a Oracle wizard, please contact us so we can have a chat. The more OLAP servers we support the better.Ruby; now that’s intriguing. Ruby can run in a JVM thanks to the JRuby project. Would olap4j work well with JRuby? probably. Are there are any OLAP API for Ruby? Google says no. Digging further in the analytics data didn’t reveal to me the actual intent of those who are searching for “olap4j ruby” keywords. What a mystery… I therefore send out there a general call to anyone interested in using olap4j inside JRuby, for we might have common interests.

I’ve been very busy lately with the new job comming up and many other changes in my personal life, but fear not; I’m cooking something up for you people. I’m working on a comprehensive guide to olap4j. Many people have expressed a need for a more step-by-step introduction on olap4j, what it is, and how to unleash it’s raw power. In the next few weeks, I should be able to finally put some more time on it and release a first final draft. Until then, take care!

Browsing my Google Analytics statistics, I realized there is a lot of people out there that are searching for ways to connect Microsoft SQL Server with olap4j.

Here is a nice example.
// We must use the XMLA driver.
Class.forName("org.olap4j.driver.xmla.XmlaOlap4jDriver");

// This code is for Java 5. With Java 6, you can directly
// unwrap the underlying connection with the .unwrap() call.
OlapConnection connection =
(OlapConnection) DriverManager.getConnection(

// This is the SQL Server service end point.
"jdbc:xmla:Server=http://example.com/olap/msmdpump.dll"

// Tells the XMLA driver to use a SOAP request cache layer.
// We will use an in-memory static cache.
+ ";Cache=org.olap4j.driver.xmla.cache.XmlaOlap4jNamedMemoryCache"

// Sets the cache name to use. This allows cross-connection
// cache sharing. Don't give the driver a cache name and it
// disables sharing.
+ ";Cache.Name=MyNiftyConnection"

// Some cache performance tweaks.
// Look at the javadoc for details.
+ ";Cache.Mode=LFU;Cache.Timeout=600;Cache.Size=100",

// XMLA is over HTTP, so BASIC authentication is used.
"username",
"password" );

// We can execute a query. MDX of course.
CellSet set = connection.createStatement().executeOlapQuery(
"SELECT {} ON COLUMNS FROM CUBE");

Update : Some useful links

• How to: Install Analysis Services by Using Setup
• SSAS Clients Architecture
• Olap4j latest builds

Pentaho Analysis Tool sprint 2 is now over and released since a few weeks. We’re currently in the process of wrapping up the third sprint. What’s new? What new features will there be?

Nothing very spectacular really. Yet there are a few nice features worth mentioning.

• Integration with the Pentaho BI server
  PAT can now run embedded in the Pentaho User Console and be configured remotely. It only supports XMLA connections for this first draft, but don’t worry; more compatible connection types are to be supported in the medium term. This also means that you can seamlessly use any XMLA provider. Sql Server? Essbase? Mondrian? You choose. All that thanks to olap4j. If you want specific details on this, Gretchen Moran has written a bunch of documentation on this. Congratulations to Paul Stoellberger and Gretchen Moran for this feature.
• Create multiple queries at once
  This was a requirement that was passed to us by Pentaho’s engineering team. People want to build and use more than one query at a time without concurrency issues. That was not properly supported by the age old JPivot application. Now and then we encountered some problems with multiple queries, so this was something pretty high on our features list. The backend supported that since sprint 1 , but there was higher priorities for the GUI components.
• OlapTableModel first draft
  The Java API doesn’t include a proper TableModel for OLAP data, so we’re planning to write one. We still have lots of things to figure out on this subject, but we’re planning to mock a draft specification before the sprint 3 deadline.

Our initial intent for the third sprint was to make the GUI nicer, but we’re still trying to figure out if XUL would be a better generation tool than SWT. We are waiting for developments between the GWT-Mosaic team and Nick Baker of Pentaho and hope that all those nice gents would team up and cook something up to their talent. Fingers crossed here.

Also worth mentioning,  we started talks to review the Query model currently residing in olap4j. This is a soon to be major component as it will provide developers and GUI enthusiasts with a properly abstracted API to build queries against a data warehouse. Olap4j is  very great API for low level stuff, but it still needs an abstraction layer for the common folks. Building queries should not require in-depth knowledge of MDX, for you cannot expect all business analysts to master MDX anyways. Anyone who wants to participate in the process is warmly invited to manifest himself. We are really looking for input on this, whatever your background is. (As long as it’s related to BI I guess…)

I’ve been really busy lately working on sprint 2 of Pentaho Analysis Tool. We almost reached all our goals for this sprint and are hoping to wrap it all up in the next two weeks. There is still time to add a few late requirements in this sprint so if anyone has a very special wish, now is the time to express it.

About Pentaho Analysis Tool (PAT)

PAT is an attempt to replace the good ol’ JPivot application, widely used in the Java world, as a web based browser for OLAP data. There are quite a few similar projects out there, yet none of them quite make the cut in terms of enterprise requirements.

• Ad-hoc connections
• ACL management
• User defined connections saved for later use
• Saved queries
• Multiple queries editing at once
• [ insert even more entreprise software mumbo jumbo here]

We’re writing a Google Web Toolkit (GWT) front-end and a Spring based backend as a core. All data manipulations are possible thanks to the Olap4j API. There was talk of a Json bridge later on in development, but this requirement is not part of any sprint planning for now.

The project is hosted on Google code and all the project management is done in the Jira tracker. If you have any further questions about our project or want to chat for whatever reasons, we can be reached via the mailing list or ##pentaho.pat on freenode.

In these times of economical crisis, many companies will turn to business intelligence (BI) as a source of wisdom and counsel. Millions of dollars will be invested in an effort to understand the extend of their respective problems and find solutions based on accurate and decision oriented datasets.

Since I have a fairly good amount of experience with work in heterogeneous environments and tackling data integration challenges, I thought I’d pitch in my two cents.

Why developers and project managers will have a hard time

The root of the problem is this. The Microsoft OLAP toolkit does not integrate so well with anything else than .NET technologies. SAS offers a Java API, yet it is not ready for production. (I worked with it for two years, and believe me, they are still a fairly long way to production quality code.) As a matter of fact, most software vendors in the OLAP world distribute some API to integrate their technologies, but you often end up with black boxes of questionable quality, flexibility or performance. Some even go as far as to obfuscate their libraries… this really doesn’t help in the end.

Some vendors like Oracle went for the all-in-the-box solution. They offer a “complete” solution that can fit every possible need. Then again, what they are telling you is: if we don’t have it, you probably don’t need it.”Probably”? You got to be kidding. Since when does software vendors know what you need and what your future will be? Better switch probably for hopefully.

In the best case, in order to meet your needs, you’ll hack your way through at the expense of your project specifications. The final result can be nothing but deceiving. Your celebration will be bitter and probably short lived, I fear.

About the importance of collective work

You have a brand new application. Hooray! This is where the production phase kicks in.

What if you need to move your datamart to another OLAP server? What if there are not enough connections licenses to allow both production connections and all of your maintenance personnel on the OLAP server and they are forced to take turns to debug? What if the CEO decides to migrate to a new platform? What if [insert random but oh so frequent unforeseen event here]? Your thousand dollar code is now rendered useless; you can start crying now, you deserve it. In your quest for more money making, you’ve created a monster that was expensive and will continue to pump the money out of your institution pockets.

If you were good enough in systems design, you thought about a data layer. The data layer still remains to be rewritten entirely and it often represents at least a third of the overall effort. Close, but no cigar. This might sound like a catastrophic scenario, but it is oh so frequent.

Many people got tired of all this non-sense we decided to work together. We decided that enough time and money was wasted on individual efforts that were ruined in the end.  It was time to agree on standards and share the product of our collective effort.

Take Hibernate for example. It is now a de facto standard when it comes to data mappers. For the Java version alone, it represents 859 thousand lines of code worth 12.8 million dollars in work hours. Think you can top that with your in-house data layer in times of economical crisis?

About Java OLAP

OLAP is a world in itself. You can’t take relational paradigms and apply them to the multidimensional world. The .NET toolbox does have very nice libraries to do some neat OLAP stuff, then again, you’re locked-in with SSAS. This is a no-no.

On the Java side, things are even worse. There is currently a big void in the Java OLAP market. No OLAP standard emerged at all. Thanks to the selfishness of the big players of the industry, the JOLAP initiative was a total failure. It never reached the final version, so the JSR-69 specification died quietly.

We at Olap4j tried to fill that gap with an open initiative. Everyone can pitch in. And I mean EVERYONE.

What makes Olap4j so kewl

You know the expression vendor lock-in? I hope you do, I *really* do, or else you’ll learn it the hard way. Olap4j aims at solving exactly this problem. You can develop applications on it’s API and switch the underlying OLAP engine without rewriting a single line of code. Not bad heh? Olap4j is more than a database driver. It is an open API built right on top of the JDBC industry standard where everyone collaborates to specify a common base onto which to build.

It even includes transformation libraries and testing facilities.

I want to kick the tires and use it right now

So far, it has two implementations ready to use. The Mondrian driver allows you to run the much acclaimed Mondrian open source OLAP engine as an in-process data provider.

There is also the XML/A generic driver that can connect to pretty much anything that talks XML/A, whether it’s over HTTP or anything else you fancy using. This particular driver allows you to build applications that can switch to and from any of these OLAP engines :

• Hyperion Essbase
• Microsoft SQL Server Analysis Services
• Infor
• Mondrian
• Palo

The Olap4j project is gaining momentum and we truly hope to see it become the standard in the Java world.

I’ve been working for a month now on some enhancements to the Olap4j project to make it more powerful and compatible. The good news is, I succeeded. The previous version, 0.9.5, lacked some basic functionalities which you would expect from a production ready XML/A driver.

For one, it’s HTTP proxy didn’t support cookies. his was a big problem since the myriad of requests required to populate Olap4j’s meta data objects each created a new user session on the web service back-end. This was a no-no, but now it’s fixed and kicking ass.

I also worked on a SOAP query cache. This is was a big piece of software engineering, since I’m not used to thread safe coding. Thread safe thignys are usually in the lower levels of BI application servers and those issues are tackled from the start. Thanks to Java’s java.util.concurrent package, this was a breeze.

Those changes are not part of any release nor in the SVN yet. I’m still waiting for peer review before the whole commit, but for people eager to see what it looks like, I’ve created a neat little package for y’all.

Now I can move back to my next release of the University of Montreal’s Pentaho platform… all work and no play makes Luc a dull boy.

Cheers !