Well, I’m at it again releasing another open-source project. I work with Hyperion and the Essbase Java API extensively, so it’s not uncommon for me to be doing things with grids and working on a command-line. I frequently write lightweight command-line clients to test things out. I didn’t love the options I was able to find in Java that would help print/format a text-based table. The ones I did find were clunky and hard to use.
So, you guessed it, I rolled my own. Jolo is a small and lightweight Java library with two goals: print out text-based tables, and have a tight and clean, yet flexible API. So let’s say we want to print out names, cities, and states in a three column table. The code looks like this:
public void testPrintTableWithColumns() { // setup table definition with column names/widths TableColumnList tcl = new TableColumnList.Builder() .add("Name", 40) .add("City", 15) .add("State", 2) .build(); // createRandomRows is a helper function in this case but would otherwise // be your data that is an Iterable<List<Something>>. Iterable<List<? extends Object>> data = createRandomRows(10, 3); // create the printer and print the data TablePrinter tp = new TablePrinter(); tp.outputTable(tcl, data); }
Having the TablePrinter separate from the concept of a TableColumnList is nice because we can plug-in different TablePrinter implementations if we want to. In the above example I have a helper method creating the data for me (createRandomRows()) but in your program this would be something that implements the Iterable interface and contains a List of something that extends Object. In Java parlance that means you can print anything that’s Iterable<List<? extends Object>> – note that the toString() method will be called, so you can pass anything in. If I get time I’ll enhance the API a bit to provide some convenience functions and syntactic sugar. Given some data, the above code generates this table:
+----------------------------------------+---------------+--+ |Name |City |St| +----------------------------------------+---------------+--+ |Jason Jones |Seattle |WA| |Cameron Lackpour |Philadelphia |PA| |Tim Tow |Huntsville |AL| +----------------------------------------+---------------+--+
Note that with a simple parameter in the builder we were able to constrain the width of a given column.
The Hyperion Connection
This isn’t ostensibly Hyperion- or Essbase-related (save for the names in my table, hehe), but if you work on the things that I work on then this might be up your alley. The Jolo page has more information including a link to the Github repository. I will likely push this to Maven Central as time permits to make its inclusion in anyone’s projects all the easier. Unlike many of my other projects, this one is not incredibly commented [yet], so that will be coming in the future weeks as time permits. The API is pretty clean though so you shouldn’t have a hard time using it. Licensed under the very business-friendly Apache Software License.
Jason,
Okay Mr. JAPI Smarty-Pants, now write a utility that takes MDX output and writes it out *quickly* to disk. MaxL is pretty bad at this. Surely you can beat it?
:)
Cameron Lackpour
So, hypothetically speaking: What output format would you want, and are you sure that MaxL is the weak link or is it the network/cube/query?
Well, I think what CL is trying to say is the output of an MDX Query is wierd with all those baces around ” () “.
This is the output of sample MDX Query
(Actuals, June, FY13, LL<1yr) 6395879.7
Wouldn't it be nice to have the format similar to a loadable format?
Just like report script that give a pretty nice format
Jason,
Read this post on data extraction:
http://camerons-blog-for-essbase-hackers.blogspot.com/2013/07/what-makes-essbase-data-extraction-fast.html
It isn’t Essbase that is the slow bit, it’s the way MaxL spools data out to disk. It is slow, slow, slow. Not that it was designed for this kind of thing to begin with, but it’s the only *easy* scriptable way of getting data out. MDX vs. report scripts — from an Essbase perspective, it beats report scripts every time. But maybe only because it doesn’t have to write content to disk whereas report scripts do. I was certainly surprised by the results of my testing.
Part of what would be _nice_ would be getting rid of that horrible all-columns-are-the-same rule that Amarnath refers to in his comment. Part of what would also be _nice_ would be a faster way of writing the content out. And maybe then we’d know which routine is really faster — MDX or report scripts.
Regards,
Cameron Lackpour
P.S. I think the ASO world+dog developer community would embrace a utility that made MDX data extraction better. Maybe even the BSO world+dog.