Database Reference
In-Depth Information
someone else's code, or even one's own code a few weeks after writing it. These accusa-
tions can be exaggerated, but they contain truth. generally speaking, it is easier with
Perl to write unreadable and unmaintainable code than it is with rival languages. It is
also generally harder for a novice to learn enough about Perl even to understand well-
written code that a veteran would easily grasp.
While Perl 5 is stable, it has not changed much over the past 10 or 15 years. other
scripting languages have come out that share Perl's power, among them JavaScript,
ruby, Python, and the subject of this chapter, groovy. These languages add newer, more
modern features and capabilities while avoiding Perl's sometimes cryptic and often con-
fusing syntax. (As it so happens, groovy also offers a few key features that make it a
perfect choice for creating Essbase scripting solutions. more on those in a bit.)
Some readers may feel Perl is getting a bit of unfair treatment here, and, truth be told,
they may have a case. The purpose of this chapter is, after all, to promote groovy as a
superior alternative, so it stands to reason Perl would get beat up on a little along the
way. In the interest of fairness, it seems appropriate to set the record straight about what
we are really saying about Perl. Perl is fun and powerful and weird and byzantine and
old and cool. given the shortcomings listed above, it is not recommended as a language
to learn starting from square one in order to accomplish our Essbase scripting goals.
There is a better way. however, if an organization has thoroughly addressed each of
these shortcomings, has the right programmers on hand, and also knows how to lever-
age Java objects within their chosen language (as we will be doing in this chapter), then
Perl plus maxL plus the Essbase Java API would be a powerful, capable solution, which
may be a good choice for that organization. The rest of us will be best served by looking
to something more appropriate.
one final automation option we need to look at is direct API development. Essbase
has a few APIs: one for C, one for visual Basic, and one for Java. We are going to dismiss
the first two out of hand as inappropriate for our purposes. C itself and the C API are
too hard to work with for scripting. Pointers, preprocessors, and explicit memory man-
agement are not for us. The visual Basic API works only with vB6, which is long dead.
It can still be used inside of microsoft office visual Basic for Applications modules, but
that is not appropriate for daily automation work.
We are left, then, with Java. This comes with its own set of problems and advantages.
While compiling the interface module is not needed, compiling everything else is. Java
is not a scripting language, and so building full programs—executable classes, main
methods and all—is required in order to do anything. This is not what we have in mind.
on the other hand, the Java API is the most viable API option, and there are dozens,
perhaps hundreds of Java programmers for every Perl programmer in the world. This
means hiring, succession, and learning curve issues are greatly reduced. The Java option
warrants a closer look.
This option has been around for quite some time, yet has not seen widespread adop-
tion by the Essbase community. This is for good reason. For routine daily maintenance
tasks, it takes too much work. many discussions between Essbase developers about cool
and useful things we could do with Essbase have ended with the words: “It would take
an API app for that.” The perception has been that the gap between regular scripting and
full Java development is too wide, and that is a pretty valid point of view. Programming
in Java is serious programming. It takes a lot just to get off the ground. There is a need
for “scaffolding” in many places, which are the bits of code that need to be in place
before we can write the interesting parts. Energy has to be expended considering the
