Database Reference
In-Depth Information
While a complete exploration of the language is beyond the scope of this topic, it will
serve our purposes to take a closer look at the features listed above and see how they
make our jobs easier.
9.4.1 Writing Scripts or Full-Blown Programs
groovy is not strictly a scripting language. It is a full Java-like application program-
ming language that can also be applied effectively for scripting. This is good news for us
as Essbase administrators. We can stay within the same language for both disciplines.
most of us just want to make our backups, dimension builds, data loads, and such better.
We can use groovy for powerful, flexible scripts that leverage the JAPI for automation
requirements we cannot otherwise meet. Some of us are application and Web developers
with larger, more robust programs in mind. Why go anywhere else? With the full power
of Java behind it, plus its tools for building user interfaces more easily, groovy offers
the opportunity to write complete applications in the same language as our automation
scripts.
9.4.2 Running from Script or Compiling
groovy can be, and very often is, launched from source code. This is especially true in
scripting scenarios. The developer simply writes code, runs it, modifies it, and runs it
again. The launcher program does a fair bit of invisible magic behind the scenes to aug-
ment, compile, and execute the code. This is all hidden from the developer, who only
sees how easy it is to get the script running.
There is another option available to the developer, however, and that is compiling
groovy source into executable classes. groovy comes with its own compiler, groovyc,
which works basically the same as Java's javac. It turns groovy scripts into class files that
can be launched with the native Java launcher (java). The only wrinkle is that groovy
'jar' files need to be included in Java's class path, either on the command line or through
an environment variable. This example shows how to write, compile, and run a program
from a Windows command prompt. For simplicity, it is assumed the current directory
is the groovy 'lib' directory.
> echo println 'Hello World' > hw.groovy
> groovyc hw.groovy
> java -cp ".;.\groovy-xxx.jar;.\asm-3.2.jar" hw
normally, we would use the run-from-source option for running our nightly back-
ups, hourly data loads, and such, but the compile-to-classes option adds some interest-
ing possibilities. It may be a path to overcome resistance from server admins who do not
wish to install full Java and groovy development kits on production servers. (These are
required for the run-from-source model.) An Essbase server will have a Java runtime
environment installed, so deploying compiled executables should not be problematic.
Additionally, precompiling the scripts for deployment could be considered an extra layer
of obfuscation to help keep user names and passwords away from prying eyes, though
additional steps should certainly be taken, and these strings should never be written
into the scripts themselves. Also, binary distributions can mitigate a potential problem
where scripts can get out of sync between environments if they are modified directly in
production instead of having changes written and tested in development first. This is no
substitute for genuine version control and change management, but it could be helpful.
