Database Reference
In-Depth Information
object-oriented. Scripts are typically run (or at least appear to run) by reading through
and interpreting the source code at runtime. Application code, on the other hand, is
explicitly compiled into executable programs.
groovy lives in a hazy borderland between these programming modes, providing the
ease-of-use features of scripting coupled with the power and structure of application
programming. This position makes it a strong candidate to be the automation technol-
ogy of choice for Essbase administrators. Before we launch into adopting a new auto-
mation method, however, perhaps we should take a step back and re-evaluate the most
commonly used existing methods. Let's review them and see if groovy automation is
worth examining as a better way for you and your organization.
maxL is the dominant method for issuing programmatic commands to Essbase.
It is fairly comprehensive in functionality, and its documentation is pretty complete.
Between the two command languages, maxL is clearly the better choice. ESSCmD is
older, more cryptic, harder to write, harder to read, less complete, less well documented,
and does not support ASo (aggregate storage option). hyperion invested heavily in cre-
ating maxL, and oracle has moved it forward with each release of Essbase. A problem
with the language, however, is its inability to robustly handle error conditions. There is
no significant method of branching, either, so the only real way to check and react to
varying conditions is to embed commands in a script of another type.
The Windows'
®
command interpreter, PowerShell™, the various unIx™ shells, etc.,
can make calls to multiple maxL scripts and check for error code conditions after each
script. This allows a certain level of flow control if several workarounds are put in place.
Because maxL normally returns only its success or failure, a series of custom return
codes must be created, maintained, checked for line-by-line in the maxL code, and
returned to the calling code. Furthermore, the output from maxL commands is in the
form of strings that are formatted for human visual consumption, which makes them
hard to process in code. This output is typically spooled to a file on the operating system,
read back into the host script, and parsed. This is all really clunky and is not resilient to
change. A more flexible and powerful solution is called for.
using Perl and maxL together offers a key advantage over most other scripting solu-
tions. A module for Perl ships with Essbase and is part of every installation. This mod-
ule allows programmers to make maxL calls directly against Essbase and easily receive
back both the return code and the command output. however, the output still comes
back as one long string, and still must be parsed carefully to get any meaning out of it.
While this is not too hard, it is subject to changes in format from release to release, and
still this solution has other, more significant disadvantages. The maxL module is built
for Perl 5 and has to be compiled from source, using the right brand and version of C
compiler, which varies depending on how Perl was obtained. This can be a very difficult
task for some, and it must be repeated with every new release of Essbase. A very similar
module was released by a third party, this one for the Python language, that did not have
this cumbersome compilation requirement, but we do not feel it should be considered
seriously as an option. It is not maintained, distributed, or supported by oracle, so there
is no guarantee that it will be compatible with later releases of Essbase. We, therefore,
will stick with Perl as the sole option for employing this scripting technique.
once the technical hurdles have been cleared so that using Perl and maxL together
is even possible, we need to deal with certain issues involving the language itself. Perl
is considered by many to be a difficult language to learn and understand. In fact, it is
referred to by some as a “write-only” language because it can be so difficult to read
