Author Archives: jason

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!

 

Hyperion Papercut: Cross-server cube copy in EAS doesn’t carry over data

So, this might not be a Hyperion papercut in the sense that I have been having some fun with. And it’s not something that I have even thought was an issue until it came up today. When you copy a cube onto the same server as the source cube, you get a full copy plus all the data. But when you copy the cube to a different server, you get everything excluding the data.

I’ve always assumed this was by design and have taken it as such. I mean, if the source cube is huge you could potentially do some bad things when you copy it to the target server. But wouldn’t it be nice if EAS just provided a checkbox to copy the cube with the data when you are going across servers? Obviously it knows how much space is available since the destination server can provide that information.

Of course, the process for getting over the data isn’t too onerous – you just export the data (raw) and load that up as-is to the target. All things considered, is this really a big deal? Of course not. But if you approach the construction of your software with a craftsmanship mentality, would the design be at least a little different? I think so.

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

SSD Upgrade (MOAR SPACE!) – for laptops and Essbase servers

Samsung 840 Pro 512GB SSD Upgrade for my MacBook Pro

Samsung 840 Pro 512GB SSD Upgrade for my MacBook Pro

This isn’t ostensibly Hyperion related, but I’m going to find a way to tie it back to Hyperion and Essbase. My main machine these days is a MacBook Pro. I love this thing. It’s not even the newest retina model (soon…) but it’s still a beast. Originally it came with a 128GB SSD. I quickly outgrew it – mostly owing to the VMs I store locally. I bumped up to a 256GB Samsung 830 SSD and enjoyed breathing room for awhile longer. Recently, though, I have even outgrown this, owing to various VMs and other files I need on a day to day basis.

I could run my VMs and store files on an external drive, of course. It wouldn’t be too hard to just plug a USB drive. Now, I’m not lazy, but it is just one more thing to deal with (I’m sure performance would be reasonable, but SATA beats USB). This machine has Thunderbolt, but again that’s just one more external thing to plug in and the Thunderbolt enclosures for drives are pretty expensive (i.e., they make more sense for an array of drives rather than just one drive). I could even replace the optical bay (a DVD-RW drive) with a hard drive. This is very tempting – to pop in a 1 TB laptop drive in place of the optical drive. I’m not ready to go there, just yet. After some deliberation, I decided to bump up this baby to a 512 GB Samsung 840 Pro SSD. It’s a little pricey but I’m not ready to commit to a new laptop just yet, gets me the space I need right now, doesn’t entail me having to worry about an external drive, and it is fast. I cloned my existing drive over so this isn’t even new install of the OS or anything. This thing just screams.

How does this relate to Essbase? Well, let me tell you.

Disk performance affects almost all major aspects of Essbase solutions: retrieval times, calc times, data load times, and more. We [database geeks] spend countless hours optimizing solutions or designing them around performance issues. Almost every client I go to with an existing solution has a performance issue somewhere.

Now, there is definitely an art and a science to getting those dense/sparse configurations just right, optimizing load rules, calcs, and so forth. I have spent countless hours investigating, researching, and testing these settings – understanding them, talking about them, presenting on them, and most importantly, comprehensively optimizing solutions to run faster.

That all being said (and this is hardly a new or insightful thought), SSD works extremely well with Essbase. SSD speeds up Essbase for the same reasons that an SSD speeds up using a laptop or computer.

That being said, faster hard drives and faster hardware should never be used to try and paper over a fundamental design or architecture problem. SSDs are very affordable now and will continue to get more affordable. So, to sort of complement and add a tiny bit of my own insight, such as it is, to the notion of bringing in SSDs for your organization, think about it from a simple business math perspective: A is the cost of new hard drives,  B is the benefit of the increased performance, C is the cost of someone (you or a consultant) performance tuning your system, and lastly D is the benefit of that tuning.

Now, quantifying B and D is subjective. The value in your system running processes faster can be based on the aggregate improved query response times for users plus some sort of benefit from being able to load up numbers faster (or perhaps more importantly, reload numbers when things don’t tie out). Let’s be very, very optimistic and say that the benefit of D can be equal to the benefit of B. In other words, I’m going to say that you can tune an Essbase solution so well on rotational media (traditional hard drives) that it rivals SSD performance. This is, I think, being quite generous, but let’s go with it. The cost to achieve this performance benefit from tuning  (C), particularly when done by a reputable consultant, can very easily exceed the cost of the SSDs, A. Obviously there are many other factors to take into account and this is a gross simplification. But the beauty of going to SSDs is that you leave the option to do deeper performance tuning on the table.

So anyway, think about it. A lot of us just have to deal with the environment we have and be thankful we even have what we do, but in my opinion, this paradigm shift in storage is an absolute no brainer from a time and money standpoint.

Thoughts on my Kscope Session ‘Practical Essbase Web Services’

My session went alright. I asked the audience to please be gentle on account of my first time presenting the deck and the material. They were quite gentle. I’d like to give a big huge shout out to my favoritest Essbase peeps in the world on Team Kroger for all coming and cheering me on.

My big takeaway from the audience was that a demo would have been helpful. Duly noted. I didn’t think there’d be time but the session actually came in a bit under time so there’s definitely a way to retool it and include a demo with real code and a real working example. So if I run this deck again I’ll be sure to incorporate that.

Many people were also very thankful for my apparent candor about the technology. I start off with a high-level overview of the available technologies for practically getting data out of of Essbase and come to the conclusion that while Essbase Web Services have a use case, it’s not one that I will personally be likely to use. This is largely due to my large investment in the infrastructure for Saxbi Server, which is based on the Essbase Java API.

One of my more recent thoughts about EWS is that it’s probably something that is largely intended to be used internally by Oracle and was something they knew they could clean up a bit and toss over the fence for other people to leverage. As I mentioned in the presentation, I hit some bumps in my research and will hope to see them cleaned up in future releases. Now that I have names with faces of a few more Oracle folks from the conference I’ll be looking forward to providing actual feedback to them instead of just bitching writing about it on my blog.

Anyway, as promised, here is the presentation for those of you that want to skim it. The bullets might be too high-level to be incredibly insightful but if you have any questions please feel free to mail me! I am happy to help and for extensive development needs I am available to consult through my firm.  I have some related code I will clean up and get into a GitHun repository as time permits.

Kscope 13 Day 1 – Deep Thoughts, part 2 of 2

I thought I’d be having a little more time to write things during the conference, and yet here I am sitting at the airport after a long and eventful week. Well, I had good intentions, at least. For those interested, I had a few other thoughts to go along with part 1 of my recap of the first day.

Cross-pollination of ODTUG sessions as an indicator of broader convergence in the Oracle space

Although I didn’t have a chance to attend them, this year at ODTUG featured some cross pollination sessions where an EPM guy could see what it’s like on the other side and an Oracle guy could see what it’s like on the EPM side. I thought this was a really cool idea but also sort of interpreted it in another way. More so than any other ODTUG I’ve been to, there were sessions available that were not ostensibly in the EPM track that appealed to me. And this isn’t necessarily because the scope of my interest has miraculously increased, either: it’s simply due to the fact that Essbase is being leveraged as the heart of other tools and the way that our tools work and we provide solutions to customers are converging. My prediction (one that is hardly insightful) is that the convergence continues to the point where the line between the different camps is almost non-existant.

Vanilla Essbase Shops Seem on the Decline

I was in a session where the presenter asked for a show of hands regarding who had Essbase, Planning, and other tools. One of the questions was “Who has just Essbase and nothing else?”  and given the sizable crowd, just a few hands went up. I can’t say I was surprised but I can say that I was… disappointed. I’ve been pretty vocal (though not on this blog I suppose) about my qualms with the way Oracle bundles and sells Essbase and other products. To be succinct, I find it regrettable that we are operating in a context where Essbase is arbitrarily bundled with other products in such a way so as to benefit Oracle’s bottom line first and its customers needs second. This is not to say that Essbase exists in a vacuum and that there are no other tools to go with it, just that I would challenge Oracle to explain that the current way of doing things is the best or even a good way.

WaMu is a Hyperion Customer

At some point during one of the presentations I was in I saw a slide with a list of dozens of company logos including one for the now defunct Washington Mutual. I had a brief conversation in my head with a fictitious Oracle marketing person about whether it makes sense or not to leave this logo on a customer slide. In any case, it’s just mildly amusing to think about.

“Finance is Still Stuck in Spreadsheets”

I hear this at some point. This is true, but I don’t believe the negative connotation is necessary. My real takeaway is this: spreadsheets are ubiquitous and useful. Many of them evolve into complex tools with mazes of VLOOKUps and byzantine logic. One wonders how much better these organizations might fare if they recognized their homegrown spreadsheet mazes evolving into something complex and unwieldy and then had a tool to use that had lower barriers to entry than, say, Planning, but with less onerous administrative requirements and an economic model that makes sense for less than 25 users or so.

Closing Thoughts

These are just some of my high-level thoughts to go with part 1 that I have taken from my notes. This rounds out my summary of things from the first day. As time permits I’ll post some thoughts on specific sessions and even my own session!

A lot of you – an incredibly and surprisingly high number of you – came up to me and said that you read my blog. I really appreciate the kind comments. As I’ve mentioned before I just find this to be an increasingly quasi-therapeutic place to post my inane thoughts on whatever, which is reason enough to do it. The fact that some of you out there enjoy this is just icing on the cake. Please don’t be a stranger in the comments section.

Kscope 13 Day 1 – Deep Thoughts, part 1 of 2

My previous post contained general thoughts on the conference so far, but nothing about the content so far. So I’ll now share some high-level thoughts on the content of what is going on. Oracle has respectfully requested that we not divulge some of the sensitive particulars and roadmappy stuff, so I’ll gloss over that a bit and just say that maybe you should just come to these things if you want to be in the cool kids club, but I digress.

Essbase is in good hands

My first thought of the day was that anyone who thought that when Oracle bought Hyperion they would take Essbase out back and shoot it had nothing to worry about. Oracle is quite clearly putting tremendous resources into seemingly all facets of the product. Furthermore, it wouldn’t have been a bad strategy (but definitely not a good strategy) to put Hyperion on cruise control, throw a few resources at it to keep the lights on and then some, and keep it there. But Oracle quite obviously has some big thinkers and perhaps more importantly, big thinkers that Get Shit Done that zoomed out and strategized how they could effectively leverage, break down, take apart, and combine the good technology they bought into a comprehensive suite of tools.

Predictive Analytics & Exalytics

Years ago, a light bulb went off for me when I started to think of Essbase and multidimensional tools as not merely a way of seeing how an organization performed, but rather to predict how it would perform. To that end, Essbase is recognized as a critical tool for organizations to look ahead. For Oracle’s part, they recognize this and are acting accordingly. Despite my interest and recent exposure to big data and cloud computing I haven’t had a chance to touch the likes of Exalytics yet, and I haven’t gone out of my way to get involved with it. But after hearing more about all that is going on with it and where it is headed, I am going to move it up on my priority list. Despite the title of this section, I’m not saying that anything to do with predictive analytics is automatically correlated to Exalytics. I am saying, however, that if you want to model the future with many variables and dimensions, you need something that can crunch a crapload of data.

ADF Love

ADF is getting a ton of love. I am more of an Eclipse guy and the tooling for ADF in Eclipse has left me wanting in the past, and furthermore I have tended to stick with other technology stacks (even within the Java ecosystem), but as a developer that does a lot in the Oracle world I am going to give ADF a much, much stronger look in the upcoming year. There are some very interesting things going on with ADF Mobile that I was previously unaware of that are worth a look.I have a bias towards native apps as they seem to fit more into my view of apps being crafted with precision, fluidity that at present HTML5 can’t quite seem to beat. However, it is very compelling to be able to easily deploy to multiple disparate platforms with one code base. I have some colleagues, though, that lament the need to write once and fix everywhere, almost as if they reliving the initial and somewhat dishonest promise of early JVMs (“write once, crash everywhere” or thereabouts).

Modules Everywhere – There’s a module for that!

There’s no shortage of Oracle developing modules for this and that. Planning modules, modules for other things, and so on. These modules tend to be quite specific in nature, such as for dealing with workforce, capex, tax management, and so on. Architecturally, it’s good that these are modules because from a design standpoint you don’t want a huge monolithic product that tries to be all things to all people. Modules aren’t a bad thing. I just find the juxtaposition between a generic platform and domain specific modules on top of it to be amusing for technical and geeky reasons.

For example, think of a normal relational database server that only has the notion of numbers, strings, references to other columns, and so on. This generic database has no notion of taxes, employees, and whatnot. Those things can all be modeled within the technology itself, of course, and the database will happily comply. It’s within the purview of the developer to utilize the technology to solve the problems and provide for the needs of the business – the database or the cube become the blank slate upon which we paint the solution, adding semantics to abstract concepts. Like I said, it’s not a bad thing, I just find it a little amusing since I’m a geek. You’ve undoubtedly heard of “There’s an app for that.” – in my mind I picture the Oracle folks saying, “There’s a module for that!”

LCM

What used to be a vengeful, impossible-to-please digital bag of spite has evolved into an essential tool in the toolbox. So, yeah. Yay Oracle.

Onward to Part 2

I am absolutely spent. I have a few more thoughts that I’ll wrap up tomorrow. If you read this and are at the conference, please say hi!

Kscope13 Day 1 – General Thoughts

Kscope13 Day 1 is in the books, or at least, almost in the books. I am positively beat after attending sessions, eating great food, networking, tweeting, and so on. My style for these Kscope recaps has been to focus less on summarizing the the content of them and instead try to think about the content with respect to how I see it fitting into a broader context.

But before all that I just want to shill for thank and recognize ODTUG for a moment. This is actually only my third ODTUG: I came in 2008 (also in New Orleans). I have been absent for several of the intervening ODTUGs, owing to various reasons – but it feels very, very good to be back. These people seriously know how to put on a conference and they just simply get better each year. This conference is incredibly well organized, well executed, and relevant. If you’ve ever been to an event where everything felt like a cluster, you didn’t know where to go, and there was mass confusion, then imagine the opposite of that.

Additionally, ODTUG has a well earned and well deserved reputation for having good food. We are only one day in and I am not disappointed in the least. I am not much of a sweets person but I couldn’t resist the giant, soft, delicious cookies that showed up after lunch. I am going to have to find some time to workout so I don’t come back heavier than when I left. My only complaint about the whole trip so far is that I couldn’t find a direct flight here from Seattle.

The Hyperion/Essbase content at Kscope has grown tremendously. What started out as a sidetrack of sessions that felt bolted on has blossomed into a vibrant and sizable content track. Hyperion is also quite well represented in the exhibitors hall.

I have, surprisingly, bumped into a fair number of people that admit to reading my blog. My typical retort is “So, you’re the one!” What started out as me just wanting to document some of my own issues (for my own future reference, and others if Google turned it up for them) has turned into a somewhat whimsical and almost therapeutic outlet. I seem to be a little feast or famine with the articles, depending on how heads down I am on mobile development and other goodies, but I’m on a good run right now and having some fun with it. So hang around and you might read something useful one of these days. *wink*

Kscope is off to an awesome start. Check back shortly for my thoughts on the actual content.

 

Essbase/EAS feature request: Metadata and description fields on Essbase objects

As a programmer, I find it imperative to document code as part of the coding process itself. I have learned to treat the construction of good code as a process that includes the documentation as part of the code. One of the things I love about ODI is the ability to add a description to many objects such as interfaces. Even within a single interface you can document individual elements. This is incredibly useful to provide context around why something is designed the way it is designed, to remind yourself of something, or for the next person to use/edit the code (which could be many years in the future as well as after you have moved on).

Essbase is no different. One of the most important things to document and that quite frequently get good documentation are calc scripts. We have the ability to write documentation in them, as much or as little as we want (hopefully we write as much is as needed and no more). We can add documentation to report scripts (of course, while still useful these seem to have fallen quite out of favor, given all of the tools that can move Essbase data around). We can add comments to individual members in an outline. We can add comments to our batch files and MaxL scripts. We can add notes to databases (did you know that? You can set a note on a database… I have used these quite successfully but they seem to be a quite seldom used feature despite how useful they can be, or were at least).

I wish we had more though. I’d like to be able to at least have a Description field that I could fill in for applications, databases, load rules, outlines, calc scripts (beyond the inline documentation), and any other object. I could see a lot of uses for this. Making notes on temporary databases or other temporary files, explaining the purpose of a particular load rule, quirks in an outline (notes to a future admin), and so on. Of course, it’s possible to document this in a separate document, but as we all know, these get stale and go out of date. Furthermore, they frequently neglect to document everything. So new features or files pop up and they are not included in the documentation.

Come to think of it, more metadata than even just Description would be useful: last person to edit, create time, edit time, basically all the usual stuff. As a bonus feature, the ability to associate some arbitrary files with a server or application would be nice so that we could upload a Word doc or PDF or something to its associated cube/server and have it available as a quick reference.

Anyone else think enhanced metadata and associated functionality would be useful?

Papercut: Calc script verification with FDM tokenization

Here’s a papercut I’d like to present in the context of my thoughts on papercuts in the Essbase ecosystem. I’ve recently been doing a bit more work with FDM. After an FDM data load you need to calc data (related to what you just loaded, although I suppose you could just calc the whole thing if you wanted to) related to the intersections you just loaded. In other words, if you are loading data for a certain time period or location or whatever, you’ll want to roll that data up. Nothing special there. So you have a normal calc script except it has been parameterized for FDM – it searches for tokens in the script, such as in FIX statements, then replaces a template variable with the real variable. So it’s like [T.Location] gets replaced with the actual location. But guess what, when you go to validate the calc script now (and you do always validate your calc scripts, right?), it doesn’t validate.

Hmm.

So, I’m not an FDM expert. Maybe there’s an option to work around this that I don’t know about. Maybe you can stuff these tokenized names into a dummy alias table so that you can at least validate. But it seems like the “right” way to handle this would be to find a solution where you can still validate the calc. I guess one straightforward way to do this might be an option to ignore values with brackets around them that are enclosed in quotes. But it feels wrong that using FDM and tokenizing your calc script leads you down this path. If you have worked with this and have a solution that I don’t know because I’m not an FDM expert and you are, please let me know. But right now it’s just one of those quirky little less than ideal issues that I consider an Essbase Papercut.