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…
The venerable Tim Tow and his crew have recently released a next generation version of the Essbase Outline Extractor. As many of you know, this is a tool that has been around for years and is used to ransack a Hyperion cube’s outline an generate a text file. I have talked to people for years that absolutely swear by this tool and attest to it saving their lives.
And yet, I’ve never used this tool in a professional context. I mean, I’ve used to the tool to see that it works and otherwise experiment with it, but I’ve never had an occasion where I had to use this tool to unlock some of my outline data on my Hyperion servers.
Generally speaking when I have been in situations where I needed the data that was in an Essbase outline, there has been some upstream system that had the data that I really wanted and could be used to build the dimension I needed. So from where I sit (which is apparently an architectural ivory tower, but I digress), the use case for needing the outline extractor is that metadata is trapped in the outline itself.
Business metadata being trapped in the outline isn’t inherently bad. However, I suspect that the propensity to manage the system this way has a strong correlation to the slow and steady migration of Hyperion system management from the laissez-faire finance department to the fortress of the IT department. In other words, finance users had the Hyperion server at their knees and could manage it by shooting from the hip, wild west style – meanwhile, IT wants forms filled out in triplicate in order to dole out EAS access.
A question for my Hyperion readers and enthusiasts
That all being said, I am curious to hear about your real world and practical usage of the tool. I am very curious to hear about the context you are using it in, such as:
- Is it part of the normal automation process?
- Did you use it to import the data into some other system that would then be used to update the outline (EIS, Studio, etc.)
- Did you just need the data for something else?
- Was ODI available, if it was, why didn’t you use it?
I don’t need any particulars unless you care and are able to share them. I am just very curious about the context that you use or have used this tool in. And for the record, there’s nothing wrong or indicative of a bad environment if you have used this tool, it’s just that I haven’t personally been able to use it, owing to having other options available. Please leave comments or email me, thanks!
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?
Sometimes you need to delete an Application but you can’t. You still see it in Essbase Administration Services or even Application Manager (hey, there’s nothing wrong with still being on 6.5.x, if it ain’t broke…), but the app is broken or doesn’t exist. The simplest cause of this is that someone [probably you] deleted the folder that contained the app, but you didn’t delete it through EAS. And now, paradoxically enough, when you go in to EAS to delete the app, you can’t, because it can’t be started, because it doesn’t exist. So essentially, the Essbase server tracks databases based not just on the existences of their folder, but also via some other means.
The easiest and most consistent method that I’ve come up with to kill the unruly app is this (assuming you have an extra Essbase server laying around):
- On a separate Essbase server (your test server, for example), create an app of the same name, then create a database of the same name (you just have one database to an app, right? No? Well, go ahead and create the same-named databases — and shame on you, for cramming more than one database in an application). If you already had a copy of the app/database on your test server, you can skip this part and just use the existing files.
- Unload/stop the application you just created.
- Stop the Essbase service on the server giving you troubles.
- Copy the entire folder containing the new app to the proper location on the server that is messed up. For example, if using Windows, if the name of your bad application is BadApp, right click on this folder from Windows Explorer and select Copy, then paste it into the app/folder on the server with the messed up app. Use the appropriate cp -R command for Unix variants.
- Restart the Essbase service, if necessary.
- Start the App that was giving you problems.
- Delete it (and make sure when you right click on Delete, you press it with authority. You show that Essbase server who the boss is.)
This approach has always worked for me. If you don’t have access to another Essbase server, you may be able to get away with following these steps, to an extent, using the same server — I think I got that approach to work once but I really had to play with it and create the app with a different name, then go in and edit some of the files.
In any case, I hope this helps someone out there that is sick of looking at non-existant apps in their EAS view or just needs to fix something that went corrupt on them — so good luck y’all.