"GREPort" Script Is Depreca-Dead!

This post is about how Groovy can give your EPM application a significant competitive advantage

If you, cow boy or cow girl from the EPM space, are not aware of one of the previous posts related to extracting data using alias names, you can still catch up here.

I was recently spending some time on reading past release notes from January 2023, just in case I have not seen any interesting released feature. And guess what I found in the 23.05 montlhy update:

Oh my, that means the “Greport” script has been relevant for only 8 months!

Let us imagine each version of the Planning version as a circle, and that each monthly release makes it grow bigger and bigger. All the features available would be in the circle, all the features unavailable would be out of the circle. Simple. Right?

Now, specifically on version 22.09, when I shared the Groovy code on Greport script, the functionality to “Export data with alias” – something that was possible On-Prem thanks to report scripts – was not out there. When migrating to the cloud, no obvious solution was answering that requirement. Unless I’ve miss something somewhere.

So yay! 71 lines of Groovy code later, we could achieve this:

This is precisely the strength of Groovy: it allows to go beyond native functionalities of the tool.

Were we in a position to predict that this would be someday included in a future monthly update release? Maybe. In my head it was more like:

My only certainty was clearly “it might or might not be part of the roadmap someday”. As you all know, as always for any tech vendor: safe harbor applies.

This is only after a new functionality has been delivered, or when the release note is officially shared, that we can say: “Ok, release 23.05 now includes the export data with alias names!”

This is getting interesting!

So now, the situation as of today is the following, and it’s getting interesting:

Fair question would be: is it worth keeping the custom code, or is it worth using the new DataExporter class? Tough question…

Let’s have a look at the DataExporter class, as it is in the current version (24.12). We can see interesting methods, that allows:

• to export to a file or a zip file
• to set a custom delimiter
• to filter the exported data based on member names and/or data values
• to transform the data during data export (not advised unless very good reason! to avoid discrepancies between data in application and data in exported file)

My answer is: it depends!

If the functionality developed in the first place is still working fine and needs no evolution, it’s better to keep it as is. No rework, no regression. Better resource allocation on other higher-priority tasks.

If the EPM Center of Excellence (in big organizations) or EPM Functional Admin/Product Owner (in smaller organizations) has plans for deploying similar features, that would need to duplicate artifacts, then my recommandation would be to do it using the native way.

Any architecture choice at a given time, can be deprecated the moment a new feature has been released. It does not mean it was a bad choice. With the right expertise, it could have been the best choice. With less expertise, it could have been a bad choice. We always make decisions based on the information we have at any given moment.

A situation I wouldn’t wish on anyone would be to have started a custom development, and in the middle of its development phase realize a new feature of the product is getting released.

To conclude, I do think that this new feature that allows to export data with alias names is a great thing. We, as Oracle EPM practitioners, must follow closely the pace of the monthly updates, to be in a position to decide wisely when it’s about EPM architecture or design.