I can’t believe I didn’t know about command-line utility until very recently. I was doing a little research on some text processing utilities and came across the “paste” command. As a Mac user I have this installed already, and this appears to be a fairly common LInux/Unix tool as well. It’s part of a suite of text processing utilities that are fairly standard. Oddly, I am very familiar with the likes of sed, grep, awk, and so on, and yet have not stumbled upon this.
Anyway, imagine the following files, starting with names.txt:
Then we just run paste:
paste names.txt numbers.txt
And we get this:
Paste just marries the files up by column, reading from each file. You can supply more than two files.
I don’t have an immediate need for this utility for processing Essbase data, but it just might come in handy someday, so I’m going to keep it in my back pocket. And for you Windows users out there, well, you know the deal: get cygwin or whatever the latest and greatest Unix-on-Windows environment is.
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!
I got a question from a reader about how to do this. Specifically, they were copying an application from one server to another and everything seemed to be going fine, except that there was no data in the resultant database on the target server. The reason for this is that when you copy Essbase apps between servers, the data does not get copied. If you copy the app on the server, it will copy the data. So, how do we accomplish this?
For BSO cubes, the easiest option to do a cross server data copy is to copy the application by right-clicking on it, selecting Copy, then choosing the target server. Then right-click on the database and select Export…. The export file will show up in your App folder were all of the Essbase applications are. On your new (but empty) database that you just created from a copy, you can load this data. If you have access to the File System locations, you can load the file across the servers, otherwise, you may have to copy/move the newly created export text file to a location that you can get to through the EAS Load file dialog box. You don’t need any load rules since the data is already formatted in a way that is native to the application (just don’t make any changes to the outline before you import the data).
As I mentioned, when you copy an application to a new name on the same server, it will take the data with it — and anything in same folder as the app, for that matter. So if you’re in the habit of storing gigs and gigs of text files in your database folder, get ready for a long wait as everything copies. At least in version 7 of Essbase, copying huge applications is not a very graceful operation — it can stall the server while files are copying. Even the best RAID setup can really take a pounding from all the reading and writing necessary to duplication an application.
For ASO databases, your options are a bit more limited since you can’t just do a database export. You can still copy the applcation (and all it’s rule files and report scripts and such) across servers, though. As I’m sure you’re aware by now, ASO databases can be quite a bit more fickle than BSO — and you’re quite used to ASO dumping all of your data when you even so much as look at the outline in the wrong way. But part of the reason you are using ASO in the first place is for the fast loading times, even with massive datasets. You can follow your same steps and load back data to ASO through EAS, or if you have setup your automation correctly, you can run your scripts and populate your new copy of the ASO application/database.