The Essbase Administration Services console has an ostensibly nice feature: custom views. Instead of having to navigate from the top of the hierarchy down to the thing you want to see, you can create a custom view at a lower level in the navigation tree. This is a custom view and it gets its own tab along with the normal enterprise view.
So… nice feature in theory. I used it a few times but now never really mess around with it. This is probably more to do with the fact that I jump in and out of a multitude of environments much more quickly these days than I ever used to.
In any case, it’s clear that EAS stores this setting in a database and on the server. This is also nice in theory because it means the settings you set aren’t locked to a particular machine and that you’d have to set everything back up if you ever installed EAS elsewhere. The console, however, takes its sweet time relaying your settings up to the server, though. In fact, it waits until you exit to sync things up.
In a perfect world, I am opening up EAS, doing what I need to do, then closing it right away. And perhaps this is how the creators envisioned it being used. But we don’t live in a perfect world, and I have a tendency to leave EAS and many other programs open indefinitely. For one reason or another I might lose my network connection and connection to EAS. Then I want to exit EAS, which is EXACTLY when it wants to talk to the EAS server… which it can’t. And EAS gleefully tells me that it can’t save my custom views. Even if I don’t have any. Which I don’t (see above).
As a software developer this absolutely kills me on several levels. One being why don’t we just relay the preference at the time it’s set rather than on exit (which statistically is a very likely time for not having a connection to the server). Two, when I want to close a program I generally want to close-it-n0w-thankyouverymuch. Finally, three, there’s nothing I can do about the lack of setting saving going on anyway – so just silently log it, if you must, shut up, and shut down.
As I said, this is pedantic, but that’s the very definition of the notion behind this papercuts: no single one is bad but put together… ugh.
While I’m at it, a fresh coat of paint on EAS wouldn’t kill anyone either. Actually, last time I looked under the hood a bit I noticed that EAS was using some pluggable “LAF” (look and feel) architecture and I was able to tweak the colors a bit, away from “Interdimensional Irrelevance Grey” and “Low Block Density Cyan” but it’s been awhile since I played with things…
Raise your hand if you’ve ever blown away your admin password when doing an LCM security migration. You there, in the back. I’m aware of this one because various of my colleagues are aware of it and they have told me to watch out.
Cameron Lackpour sent this one my way, though I was aware of it. Basically the issue is that you are migrating from server to server, presumably from development to production, and this includes user names and passwords (at least for native users). So if you migrate the development admin account to production, you blow away your production password.
So I guess you can say the tool is just doing what it’s supposed to do… but you’d think there’d be some provision on the target system that goes “Hey, maybe let’s not pave that really critical production admin user password with crap from somewhere else, mmkay?”
Anyone else out there shoot themselves in the foot with this? Or I am just missing something incredibly obvious?
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.
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.
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.
I am a software developer who regards the output of the software development process as skin to the woodworker making a fine jewelry box, the master chef perfecting a plate, or the musician crafting a song. I believe solutions should be elegant, robust, deceivingly simple, and polished. I take the same approach to code with my various open source Essbase related Java projects, GitHub projects, and perhaps more importantly, the critical filter through which I see and use Hyperion, Essbase, and related software.
To that end and just for my own amusement, I will be henceforth be writing about various “Essbase and Hyperion papercuts” that I see and perceive. This is in similar spirit to the Ubuntu Papercuts project that occurred some time ago. The idea was that in the aggregate, a lot of little issues start to become troublesome and lead to a worse user experience. As with many pieces of software, Essbase in general has this problem. It’s an awesome piece of software, but then has all these little warts and quirks. It’s like NASA puts a man on the moon (this is the scientific equivalent of Essbase at its heart) and then when stepping out of the lander on the surface of the moon, trips on a faulty stair leading to the surface (this is like any number of little Essbase quirks I run into).
That being said, if there is some small, seemingly trivial and inconsequential Essbase/Hyperion (or Planning, or FDM, or ODI, or…) issue that just really grinds your gears, let me know about it! This blog gets a few hits from Oracle headquarters, so maybe, just maybe, someone will see it and we can all make the world’s best EPM software just a little bit cooler.