Add complex calculations in ASO without changing or adding to the existing architecture. Groovy calculations enable improved performance and reduce complexity of calculation logic by bypassing Essbase. Taking advantage of new technology and adding creativity reduced the development timeline significantly.
Check out this success story. Download the printable version.
Success Story - HFM Adjustments - web
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.
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.
KScope has concluded, and what a fantastic week it was. I love the years I get the feedback that I have an abstract selected so I can attend. This year, I was awarded Oracle Ace, so it was really nice to be nominated and recognized for my contributions to the community.
I tried to record the sessions and unfortunately, only 1 worked. All of my presentations were recorded through the event and will be released in the coming months. When they are, I will share the links. Until them, I hope the visual presentations will inspire you to take a look at Groovy, if I haven’t already pushed you in that direction.
Now that my time has been spent building these decks is over, look forward to more Groovy Adventures!
Chris Hull has been kind enough to partner with us to present how the methods available in Groovy calculations have made a huge impact in their budgeting and reporting process using PBCS.
One of the biggest user complaints about their first budgeting process in PBCS was that they had to wait to get their consolidated reporting until an admin ran the process or a scheduled consolidation ran. Thanks to what Groovy offers, this is no longer going an issue.
For those of you that participated, I have added some additional content. I know we were limited on time. I skipped a few examples and rushed through diving into the actual steps and Groovy processes. I included additional examples and more information on the process below. If you didn’t attend, I would encourage you to walk through the items in the order they are presented.
If any of this is of interest to you and you would like to speak further about the capabilities, please send an email.
Thanks for everybody that participated and supported this event.
There were a few questions after we signed off. I will do my best to answer them below.
Question: How can internal IT team support this solution? Does Huron train them on how to to write Groovy, change code in Groovy? Demo shows only 3 cells were changed, how is performance if all products were changed? Doesn’t it hit MDX error limit anyways? Does Oracle SR team support issues/bugs related to Groovy?
Answer: Most of our solutions are not maintained by IT, but by finance. Huron certainly can train administrators on how to maintain the Groovy calculations. As far as performance, I changed 75 products and it took 14 seconds to push the data from GP to the GP reporting application, and .4 seconds to synchronize it to the Fin cubes. MDX isn’t used to do the synchronization so the MDX text limit is irrelevant. Oracle does support the product and they support issues related to the API, which Groovy uses. I have seen some issues resolved in weeks, and others that are still being addressed months later.
Question: What capabilities does the tool have to track changes to the budget?
Answer: PBCS, when turned on, has auditing at the cell level. Every time data is changed, the user, date/time, old value, and new value are recorded. At any point a user can look at that and see the change history.
Thanks again. I hope to do more of these in the future and will make sure you are included in the invitation.
On March 22, 2018, I am hosting a webinar featuring the work delivered at Breakthru Beverage Group in Chicago, Illinois. Breakthru had the traditional challenges, but it had some additional obstacles other don’t. With requirements of entering budget at any level, complex allocation and seeding logic, and the need for consolidated reporting in real time, we had to get creative. Welcome, Groovy Calculations! Groovy calculations were released in June of 2017, just in time to be a key resource to solve the previously stated problems. This application will highlight solutions like changing a product price at a consolidated level, and seeing it allocated down to delivery channel, material group, and company. It will show how we consolidated and pushed to results to the P&L applications in seconds.
It is easy to participate, you can RSVP TODAY.
I will discuss the architecture, the challenges, and how we used Groovy to do things never before possible in Hyperion Planning.
Although we will be discussing the technology used, this is not a technical discussion on how to write Groovy calculations. If you are an administrator, user, or owner of PBCS, we will highlight challenges you are likely facing, and how to overcome them using Groovy at a more functional level. If you are looking to purchase or move to the cloud, this presentation will educate you on the possibilities now available with the new functionality of Groovy calculations.
Top Down and Bottom Up Planning at Breakthru Beverage Group
Planners are always looking for real time reporting and faster feedback. They are looking to make the forecasting and planning process faster by using historical trends and the ability to enter data at any level, enter growth factors, and drive the results down to the lowest level of the business. They want instant feedback on consolidated results.
Join this webcast and hear from the VP of Financial Planning & Analysis at Breakthru Beverage Group on how they are using Oracle Planning and Budgeting Cloud Service (PBCS) integrated with game changing technology, Groovy, to improve speed and performance across planning processes.
Leave this session with an understanding on how Breakthru Beverage:
RSVP today and learn how you can take advantage of Groovy.
I was lucky enough to be invited to talk about the new Groovy Calculation in PBCS and ePBCS at the Ohio Valley OAUG meeting today. If you have read the Groovy series, you know how strongly I feel about the advancements in Hyperion Planning with the addition of Groovy Calculations. I want to share the presentation with a wider audience. This is a functional overview for those who are new to the concepts. This also introduces readers how to develop their first Groovy Calculation, and provides some examples.
The results are back, and our session at Collaborate 2011 was very well received. We would like to thank all of those who attended and provided feedback. The presentation and white paper are available below. Thanks to the folks at Abercrombie & Fitch for their involvement with the presentation.
We met a lot of great people in Orlando. Thanks to all of you for the kind words and thank yous for the In2Hyperion effort.