Category Archives: java

Kscope13 Session Thoughts: Joe Aultman sprinkles magic Groovy dust on the Essbase Java API

There were lots of great sessions this year, as always. I tried to get outside my comfort zone a little bit and take in some new content. I thought over the next few posts I’d shine a little bit of light on a few of the sessions that were notable to me.

Fixing What’s Broken in the Essbase JAPI and Reaching New Heights with Groovy

As a programmer, this was right up my alley, naturally. This session was presented by Joe Aultman. Joe is using Groovy to do some automation that would otherwise be done with the venerable Java API. Joe, if you’re reading this, super cool presentation. In my mind I saw this presentation as being about two things: issues with a particular API and issues with a language – namely a lot of “boilerplate” Java code.

As an aside, there is something of a renaissance happening in the Java world with respect to the JVM. As a computer science guy (go Dawgs!) and general purpose programming nerd I have been keeping abreast of this language and several others, particularly Clojure. In a nutshell, what’s going on is this: Sun (now Oracle, of course) created Java many years ago. Java runs inside the JVM, or Java Virtual Machine. Whereas with a language like C or C++ you might compile your C source code into an executable meant to run on a particular system, in Java you just always compile down to the same code that in turn runs on a JVM. In other words, in theory, as long as you have a JVM available for a platform (Windows, Linux, OS X, etc), then you should be able to run the same old byte code. Hence the original notion, “Write once, run everywhere.” In practice there were and are many quirks to this, but by and large the statement is true – which is why generally speaking you are able to download Java JAR and class files that work irrespective of the underlying operating system (rather than separate downloads for Linux, OS X, and so on).

As it turns out, the JVM is useful for more than just Java. New languages that are able to compile down to code than runs on the JVM are able to stand on the shoulders of giants and leverage an incredible amount of infrastructure that has already been written and battle tested. Some of the more notable languages running in the JVM are Groovy, Scala (kind of a streamlined Java), Clojure (a “Lisp” dialect), and Jython (Python running inside of a JVM).

Getting back to Joe’s presentation, I think it’s fair to say that Joe is enamored with what’s called “syntactic sugar” in the programming world. This essentially means that a language provides features or inherent abilities that reduce the need for verbose boilerplate code. Groovy more or less delivers the goods in this regard. Furthermore, Joe has created some idiomatic Groovy enhancements specifically for the Essbase Java API that reduce the need to include some “clutter code”.

I definitely liked what I saw, although as an apparently diehard Essbase Java API guy I don’t think I’ll be switching anytime soon (you’ll convert me yet, Joe!). If you didn’t make the presentation then definitely give his slides a look. Joe is working through the red tape in his legal department to be able to post his code under an open source license. Joe, if you haven’t picked a license yet, give me a call and I’ll help point you in the right direction if I can.

In any case, nice job on the presentation, man.

In other news, I have been working a little bit on the side on a wrapper for the Essbase Java API that repents for some of its sins and modernizes the usage a bit more. This is tentatively called Java Essbase Antikythera Layer (JEAL). If you use the Essbase Java API at all you might really like how this simplifies your life. It’s unfortunately a labor of love that I can’t dedicate a lot of time to so if you want to help please drop me a line!

 

Contribute to Open Source Hyperion Utilities and Ideas

Open Source Logo

Open Source Logo

Would you like to contribute to open source Hyperion utilities, or maybe just provide ideas for some? There is a small but growing number of third-party tools and utilities available in the Hyperion ecosystem. The most well known is probably the Outline Extractor.

But there are several others Hyperion tools – many written by yours truly. Many of these tools you can find under the Projects section of this website. These include such fun items as a way to generate test data for a cube, a hack for loading Essbase data without a load rule (even from any JDBC source!), a method for generating substitution variables based on time and date, summarizing rejected records from a reject file, and more.

At the moment, all of these tools are written in Java. It’s the language I am strongest with and fits very well within typical enterprise architectures. I am even working on a few more goodies that will be released in the upcoming weeks and months. Generally speaking, most of the utilities I have written are cleaned up versions of tools that I have created during the course of my work that I thought someone else might benefit from.

Once again, I have returned from another awesome Kscope armed with dozens of other ideas for utilities that the greater Hyperion community can benefit from. Many of these ideas are driven by other people expressing a pain point they have or starting off a sentence with something like, “Wouldn’t it be nice if…?”

That all being said, I just wanted to throw out there to the Hyperion technical community and world at large that if you are interested in helping create these kinds of things to benefit the community, please let me know! If you have your own ideas, I’d love to hear about them. You don’t even have to be a programmer! In fact, if you are a business person (who happens to read this geeky blog), but have an idea for some utility that would benefit Hyperion users and administrators, get that idea out there. There are many ways to help open source projects – testing, documentation, support, marketing, and so on.

Work comes first, of course. Generally speaking these tools and utilities get my attention on an “as possible” basis, so projects, such as they are, are released when they can be. I just want to get a feel for who is out there in the community and interesting in hacking on a few things.

Thanks,

Jason

My ODTUG Kscope13 presentation: Practical Essbase Web Services

It has been a few years since I last presented at Kscope, but I am back this year! I will be presenting on “Practical Essbase Web Services” – this will be my take on the new web services features from recent Essbase versions, as well as drawing on my experience developing mobile solutions, developing Essbase middle tiers with the Java API, and other approaches to extracting data from Essbase. For those of you in C# shops or wanting to get at Essbase data from your other favorite languages (I’m looking at you, PHP, Python, and Clojure), this should be a fun overview of your options. I’ll look forward to seeing you there – and if you are interested in the presentation but aren’t going to ODTUG’s Kscope, let me know!

Hyperpipe updated (1.0.1) plus another tidbit

Due to all of my testing in H2 without a password I forgot to re-include the password parameter during execution — this should now be fixed. You could have still included it directly in a JDBC URL but it’s a little more convenient to just use a parameter. GitHub repository is here and has a link to the latest download jar.

In other news, my good friend/colleague Cameron Lackpour (link in sidebar) forwarded on a message about Hyperpipe to the fine folks at Oracle for their consideration, at least in terms of being a proof of concept. So who knows, maybe good things will happen. :D

Pump data into an Essbase cube directly from a relational database with just Java and no load rule using Hyperpipe

Kind of a wordy blog title. There is plenty of more information on the Github project page.

Based on a conversation with Cameron Lackpour, I wrote a small utility that can move data from any JDBC data source to an Essbase cube. You don’t need MaxL, a load rule, ODBC, ODI, or any of that stuff.  I mean, you might want to use those things instead of this odd little one-off utility, but if you like living on the edge you can give this a try.

Hyperpipe works by piggybacking off some functionality that is already in the Essbase Java API. Craft a SQL query in a particular format and you can load up an Essbase cube without having to make a load rule or jump through too many other hoops. This could be useful in some situations. Hyperpipe is believed to work with all Essbase versions 9.3.1 or higher but has not been extensively tested. Hyperpipe is an open-source project released under the liberal Apache Software License — a business-friendly license that you can do pretty much anything you want to.

Please try it out if you’re interested and let me know if you have any questions, comments, suggestions, or issues.

Happy cubing!

Install Essbase Java API (jar) files as a local Maven artifact

Maven is a comprehensive build system for Java projects. A lot of people, including myself, have a love/hate relationship with Maven. The reasons for this relationship can be discussed at another time. In any case, used judiciously, it can make managing dependencies in Java projects much easier than handling them by hand.

Eclipse has pretty good Maven integration. It’s possible to setup a new project and browse for dependencies and add them automatically to your project. Everything just works. I develop quite a few Java applications that rely on the Essbase Java API, so I have imported the Essbase jar files to my local repository (since they are not available from a central public repository) to make development a breeze.

Here’s how you can do the same. First, you need to go get your Essbase jar file. These are installed on the Hyperion server. You might have to search around a little bit since the directories seem to change from release to release, but in the case of this stock Hyperion 9.3.1 server (with Hyperion installed in C:\Hyperion) they can be found at C:\Hyperion\AnalyticProviderServices\lib.

Here’s what the directory looks like on one of my machines:

Hyperion Java lib folder screenshot

Hyperion Java lib folder screenshot

Right now we’re just interested in the ess_japi.jar file. We’re going to import this in to our local machine’s Maven repository. This assumes you have Maven installed locally, of course. If not it’s pretty straightforward. Just Google around and all will be clear.

Maven is very particular about the versions of everything. It allows you to store multiple versions of files. This means that our single repository can store the files for Essbase 9.3.1, 11.1.1.1.0, 11.1.1.3, and so on, all next to each other. Since we’re importing this resource manually we are going to tell it the version. First though, let’s rename this local file to something more consistent with Maven naming conventions. Let’s rename it from ess_japi.jar to essbase-japi-9.3.1.jar (since this is a file from a 9.3.1 server). Change it accordingly for other versions. If this were 11.1.1.3 then we would make it essbase-japi-11.1.1.3.jar. Note that Maven “prefers” a versioning scheme of major.minor.revision but not all software (particularly Essbase) adheres to this, so we’ll do our best.

So now we have essbase-japi-9.3.1.jar. A simple command line will import this. From a command prompt in the same folder as the jar file, execute this command:

mvn install:install-file -Dfile=essbase-japi-9.3.1.jar -DgroupId=com.essbase -DartifactId=essbase-japi -Dversion=9.3.1 -Dpackaging=jar

Each -D indicates a parameter we are filling out: the name of the file, a Maven group ID (which we’ll decide to make com.essbase), what the name of the artifact itself should be (essbase-japi), the version, and lastly that it is a jar file. You’d think Maven could infer some of this for us but we only have to do this once in a blue moon so it’s not so bad. Maven will copy the file to the local repository. To make it visible from Eclipse you will likely have to rebuild your Maven repository index which is no big deal.

Essbase Jar import success

Success importing Essbase jar file

Now when we are specifying the dependencies for our projects from Eclipse, we can easily browse it by name and add it in to our Maven POM file:

Eclipse Select Essbase Jar Dependency

Eclipse Select Essbase Jar Dependency

Now we’re good to go. We can easily include this artifact in future projects quickly and easily. This is particularly useful if you happen to download the source code for some of my Essbase-related open source projects, which as of late rely on Maven for dependency management.