Confessions from a EPMA user

Confessions from a EPMA user

So this a confession from a consultant that has primarily used EPMA. So when I first learned Oracle EPM the Enterprise Performance Management Architect (EPMA) product had already had most of the kinks worked out. I never really understood why so many people had such a bad view of it. The shared library alone was more than enough for me to recommend it.

So until recently I have by pure accident never ended up doing metadata integrations on a Classic Planning application. I always knew this day would come and I figured anything with the word "Classic" in it was going to be arcane and full of nuance. However having used the ODI KM over the last couple months I now realize that EPMA was kind of a pain. Having said that I am using DRM so that probably makes things a little easier.

As an EPMA user one the things I regularly had to do was clear out a dimension so that I could build it from scratch. I always thought that was a glaring oversight in EPMA so when I started using the ODI Planning KM I was surprised that to find the Operation field. Being able to tell planning to delete descendants of a member before rebuilding the dimension has made automation quite a bit easier. Another huge improvement of Classic over EPMA is performance, I remember large dimension rebuilds taking hours via EPMA, watching the log process one member renames at sloth like speed. Classic I just rebuilt every dimension in an application (except for Period) in under four minutes. Granted my largest dimension was just over 1700 members its still impressive because I would expect EPMA to take at least 10 minutes.

There have been some subtle differences though. First I had wasted about a day trying to figure out how to clear an alias that had been removed in DRM. In EPMA I believe I would just pass an empty string to clear a value however for aliases in Classic we have to pass <none> in the alias field to clear value in the application. Another difference that took a while for me to grasp was that Periods couldn't be modified and Years couldn't be deleted via the ODI KM, I am kind of surprised this is still not allowed since EPMA has this ability.

The last major issue I ran into was how to control the order in which members were added to planning. In EPMA we had the load id which made sorting quite easy. In the Planning ODI KM however the only option to sort is by input which is great if you can guarantee your members come out in the order that you want to push them into the application. That generally requires creating views with underlying sorts or indexes. While I could have probably made that work it made more sense to add another option to the KM to allow for sorting on a particular field.

All in all I've been pleasantly surprised with Classic Planning. I still like the idea of a Shared Library which is why if I ever have to do another project without some kind of MDM (Metadata Managment) product I will probably cry a little.