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?
Database notes are surprisingly under-utilized, and as you say, lots of people don’t even know they exist. I’ve used them for end-users to indicate when a cube was last updated rather than for documentation purposes, but they could definitely help with keeping track of all those copies on the Dev server too. It didn’t help the cause that Smart View did not support viewing Notes until 11.1.2.2.300!
Hi Tim, that’s exactly what I have used database notes for in the past and it was absolutely awesome to have a simple built-in way to provide that information. I would just update them as part of the automation. I also stuck in some quick metrics (number of records loaded, rejected, duration, etc) for myself to check in on since we would load stuff all day. I didn’t know that notes made a comeback in SmartView… sounds like I need to investigate. Thanks for the tip!
Your thoughts are well and very comprehensible. Thank you for making it known to the public!
I often had this kind of wishes in the past.
Clearly this would mean a big step in many (positiv) ways.
It would requires a very tight connection to a relational database in order to store the infos- much more tight than the current binding to the shared services repository.
How many people would consider this a benefit? However even interesting – how many not?
I think before oracle will walk this stony way it will take awhile.
What about a smaller step first – and finally raise the antiquated eight character limitation for file names in particular for rules, calcscripts and reports?
The (as I think) well and wise chosen max lengt of 30 for tables, columns and other objects woul be a great deal for the first step.
Andre, point well taken on the load rule names. It’s probably well past time to give us more than 8 letters on calc names, load rules, and report scripts (for the few of us that still use report scripts, that is). I suspect that there isn’t a strong business case to enable this as it would mean going into a very deep part of the C API and changing the possible sizes of data structures and such. Also, given the numerous ways of getting data out of Essbase and the shift towards Calculation Manager, the benefits of extending the file name length start to really diminish. A guy can hope, though. Thanks!