PBJ 1.0.4 – New password options and start of CLI

The PBJ library has been getting a lot of attention lately from various developers using it to integrate with their own software and projects. Francisco Amores did a great blog post about using PBJ to help with data loading in an FDMEE project. Probably the coolest thing about his efforts is that it’s  use-case I never imagined: using PBJ in Jython to access PBCS.

One of the things that has been so great about collaborating with Francisco is getting targeted, useful, and practical comments on how he’s using the library and how it can be made better. And I have found time to make various improvements, enhancements, and fix bugs to address his feedback. This is one of the greatest things about open source software.

While Oracle provides some workable Java code in the PBCS REST API documentation, it’s akin to the old Java examples that ship/shipped with the Essbase Java API – they get the job done, but most people are going to copy and paste them, and end up reinventing the wheel in the process. Since day one, PBJ has striven to be a single, high-quality library that fits in well with enterprise Java (or Jython in the case of the FDMEE integration scenario), and is completely open-source with a license that is very well suited to giving businesses the flexibility they need.

Latest Improvements

Some bugs related to loading/importing data have been fixed. Additionally, new options are available for signing on to a PBCS instance. You can now create a connection object using a Base64 encoded password. Note that this isn’t meant to be an incredibly secure password storage mechanism. Mostly what it buys you is that if you have a raw script in something like FDMEE, you can avoid having a totally clear password. Of course, all communication with the REST API itself is over HTTPS, so you’re secure there as always.

One of the coolest improvements I was able to make lately to PBJ was to package the library as a single JAR file that makes it even easier to integrate into other projects. It turns out that PBJ uses some of the same Java libraries that FDMEE does and there was a conflict, but with Francisco’s feedback I was able to adjust things to avoid the conflict.

CLI Anyone?

There’s just one other really, really, cool (in my opinion) thing I started implementing in the PBJ library: a CLI. Now that PBJ is packaged as a single JAR file (if you want), it’s also a runnable JAR file (my preferred method of deploying Java applications that run on the command-line as it prevents a lot of hassle with classes, the class path, batch files, and other things). I’ve implemented a couple of really basic commands and can add more as time permits.

Here’s an example:

java -jar pbj-pbcs-client-1.0.4-SNAPSHOT.jar \
--conn-properties=/Users/jasonwjones/pbcs-client.properties \
--no-logging \

This can be entered as a single line on the command line, but I have broken it up into multiple lines by using backslashes. If you’re not familiar, the backslash is used in many environments to “escape” the following character. Typically this is a newline or another backslash, but if it’s the last thing on the line, then it’s literally escaping the newline itself, meaning that an interpreter or the shell will treat multiple lines as a single line.

To avoid having to put the username/password/server on the command line, a simple properties file is used to provide that information. Then the command list-applications is given.

Here’s the output:


Here’s the full output when run without any parameters, which explains the usage:

Usage: <main class> [options] [command] [command options]
    --conn-properties, -C
       Default: false
       Default: false
    list-applications      List available applications
      Usage: list-applications [options]

    encode-password      Encode a password for use in a connection
      Usage: encode-password [options]
        * --plain-password

    get-member      Get information on a member in an application
      Usage: get-member [options]
        * --application
        * --dimension
        * --member

But I can do that with EPMAutomate, right?

Absolutely. This shell isn’t meant to be a replacement for EPMAutomate, but in theory it can do everything that EPMAutomate can do. And more commands can be easily implemented. This is one of the beautiful things about Oracle having published a REST API that anyone can use. One of the potentials for this library that I can see is that since the project is completely open source, the community could easily add convenience methods or commands to work with PBCS. This could lead to the ability to cleanup on automation that uses batch/shell scripts and instead just add a couple of handy options to the CLI here. In fact, I even have an ad hoc grid library for PBCS that could be integrated with this client and expose some functionality that isn’t even in EPMAutomate.

As you can see, not too many options are implemented right now, just some proof of concept items with “get-member” and “list-applications“. But others can easily be added in. All of the new source code is available in the PBJ GitHub repository for anyone to clone, edit, use, or whatever. The GitHub repository has instruction son how to build but I think next week I’ll try and post a quick video showing how you can clone the code, build it locally, and use it in your own projects.

Leave a Reply

Your email address will not be published. Required fields are marked *