Adventures in Groovy – Part 34: Getting Started With Groovy in ePBCS, Implementation Methods, an ODTUG Webinar
I was fortunate enough to speak for ODTUG a few weeks ago and really excited that my discussions around Groovy are getting some of the most attended and most interactive ODTUG webinars. If you have put any of these presentations together, you know how much time it takes to do the research, consolidate the information, make it presentable, and spend the time to hopefully make it fluid. So, when you provide feedback, I really appreciate it.
The Webinar
There were some questions I wasn’t able to answer, so here goes.
Can the dataCellIterator take functions like @IDESC, @CHLIDREN, etc?
The iterator iterates through the grid, so it doesn’t have the ability to do this directly. I am not sure of the question, but you could iterate through the grid and for each cell use these functions in other classes/methods to do things like see if it has children, or check to see if it is a child of something.
Is there a way to have a groovy business rule to call a non-groovy business rule – for example if cells were edited then run BR1 else return?
Yes and no. There is no way to execute another rule. But, you can embed it into the script like you can in any other rule or script. You can neither write the string or drag and drop the rule into the Groovy rule. It doesn’t always put it where the cursor is, but you can cut and paste it to wherever you need it. It basically is like an include and just embeds the script text, so it would need to be in a string builder.
Can We improve the Aggregations with Groovy?
Yes and no. If you dynamically create an aggregation script that is the exact same as a normal rule, the same time would result. Where you do get a benefit is that you can only consolidate the impacted members and dimensions based on what has been edited. You can also move the data from the BSO to the ASO cube and eliminate the need to aggregate, which would obviously improve the perception of speed.
Does groovy interact with workflow, valid intersection, copying attached documents / supporting detail?
Workflow is in the roadmap. I confirmed last week with development, so it is coming. Attachments and supporting detail can be copied by executing smart pushes.
Can grids be generated on the fly using groovy?
They sure can, but they aren’t visible to the user. There are two grid builders for retrieving and submitting data.
Is there any documentation available to give performance comparisons between business rule/calc and groovy?
Not that I know of, but as previously stated, Groovy doesn’t make Essbase faster. The perception to users will be that it does, but it is only because we have the ability to isolate what we calculate more than we did before. That said, if you use the grid builders to do the calculations and submit the results rather than use BSO calculations, you might see different results. There are some things (allocations) that I think is faster in BSO. I think using the grid builders on ASO – I do see improvements in performance using Groovy over procedural calculations. But, I want to emphasize that the majority of the time the speed is improved because of the ability to calculate only what we need to.
is there a way using groovyy i calculate the whole data base for only changed cell not from the imput form
Not that I know of. I have seen people replicate scenarios or version to check this, but I think it is a poor way to do it. You could update an account, like edited, to a 1 or something, every time data is changed for that block. You could use a formula to do that, obviously. Then Groovy would be able to use a data grid builder to pull that account and suppress missing. You would then know the combinations of other dimensions that have been edited. I don’t know how well that would work from a performance perspective, but you could use what the grid returns to dynamically write an Essbase calc. That would definitely make it faster. If you go that route, why not just use the option to only calc dirty blocks?