Finally the day arrived.
Some years ago, FDMEE was introduced into our lives with lot of nice and new functionality. Jython is probably one the most important ones. Why? That's an easy one. With Jython, FDMEE opened itself to the Java world.
If you haven't read it yet, there is a must-read chapter about Jython and Java Integration at Jython's site. I'd like to highlight the following phrase:
Java Integration is the heart of Jython application development...The fact is that the most Jython developers are using it so that they can take advantage of the vast libraries available to the Java world, and in order to so there are needs to be a certain amount of Java integration in the application.
Most of the key Oracle EPM and non-EPM products have their own Java API (JAPI). During this blog series, I'm going to focus on the EPM ones. In a nutshell, the integration of FDMEE with the Java APIs for products like Essbase or HFM, gives us freedom to implement additional functionality to enhance our EPM integration solutions.
Using Java from within Jython
One of the goals of Jython is to use existing Java libraries straight forward. It's as simple as using external Jython modules (PY files) within a Jython script:
- Import the required Java classes and use them directly in your code
- Call the Java methods or functions you need
What about Types? well, here the good thing comes. Usually, you don't need to worry at all about them. There is some automatic type coercion (conversion of one type of object to a new object of a different type with similar content) either for parameters passed and for the value returned by the Java method.
Basically, when it gets a Java numeric type, or a Java string, Jython automatically converts it into one of its primitive types.
Let's have a look at the following example:
As you can see, the ArrayList object (which is an object from the Java Collection Framework) has been coerced into a Jython list. We can use methods from ArrayList Class (like add) and iterate the object as it would be a proper Jython list.
We will see more examples for coercion when using the Essbase and HFM JAPIs.
BTW, what is Foo?
Using Java from within FDMEE Scripts (Jython 2.5.1 and Java 1.6)
When writing your Jython scripts, don't forget that:
Essbase Java API
When writing your Jython scripts, don't forget that:
- FDMEE latest version (11.1.2.4) uses Jython 2.5.1
- FDMEE uses Java 1.6 (as EPM system)
In other words, you are restricted to use classes available in Java 1.6. Also, if you use 3rd party Java libraries, they must be compatible with 1.6.
Regarding the different approaches to implement the Jython script:
- Build the custom functionality in a Java library that you can later import into your scripts
- Cast Java code as Jython within your script
Option 1 requires a deeper knowledge on Java programming. I'd recommend this option only if you know Java programming and your customization is a good candidate for being reused in other implementations. On the other hand, option 2 is quicker and probably a better option for one-time customization.
Essbase Java API
FDMEE comes with functionality that is commonly use:
I wish the product would provide this functionality but unfortunately it doesn't. However, it provides a powerful scripting engine which enables us to extend its functionality.
- Extract data
- Run calculation scripts before/after loading data
- Pass parameters to the scripts
- Create drill regions
- Among others...
But, what about?
- Run calculation scripts before extracting data
- Validate target data before is loaded
- Load new metadata before loading data
- Execute MaxL scripts
- Using substitution variables in FDMEE artifacts like period mappings
- Among others...
Going back to the list above, you have probably met some these requirements in one of your projects. What did you do? Create a MaxL script and run it from script using subprocess module? Or, did you leverage the Essbase JAPI?
That probably depends on many other factors...do we have time for implementation? do we know how to do it? do they have existing batches doing the work?...
To me, using the Essbase JAPI is not only about having seamless integration but capturing errors in an elegant way. Something that you can hardly get by running batches from external scripts.
Spoiler!!! see how simple would be to execute a MaxL script or statement:
I will cover more details about using the Essbase JAPI and some examples in upcoming posts.
Spoiler!!! see how simple would be to execute a MaxL script or statement:
I will cover more details about using the Essbase JAPI and some examples in upcoming posts.
HFM Java API
What about HFM?
- How can we extract Cell Texts?
- Extract and Load Metadata?
- Translate data before extracting it?
- Run custom consolidation/calculation/translation logic?
- Among others
HFM also has a JAPI! Actually, in the same way that happens with Essbase integration, FDMEE uses these APIs behind the scenes.
Spoiler again!!! extracting cell texts:
Other Java APIs
Spoiler again!!! extracting cell texts:
Other Java APIs
Besides the HFM and Essbase JAPIs, there are other products and components having their own API. Some of them such as LCM's one are documented, some others are not. In example, OLU's API (Outline Load Utility).
In the next posts, I will show some examples for customization implemented with the Essbase and HFM APIs. If you can't wait, my colleague John already published a very cool one.
I haven't forgotten about Planning. It does not have any published Java API but you should have a look at REST API.
Take care!
In the next posts, I will show some examples for customization implemented with the Essbase and HFM APIs. If you can't wait, my colleague John already published a very cool one.
I haven't forgotten about Planning. It does not have any published Java API but you should have a look at REST API.
Take care!
No comments:
Post a Comment
Thanks for feedback!