Tag Archive for: PBCS

I am currently working on a migration of on-premise to cloud project (going GREAT by the way).  One of the things we are working on is the change with the data integration.  One of the processes loads the number of working days to the application from a source that provides it.  “Why not use Groovy,” I ask?  It turns out to be a great question. Read more

 

I know many people complain that the same speakers present every year.  I can tell you I get rejected more than I get accepted.  The last few years ODTUG added the option for members to vote on speaker abstracts.  I want to thank all of you that voted for me because the only reason I am honored with this opportunity is because of the great feedback you provided.  I was on the content selection committee and there was a concerted effort to have new speakers.  No, I couldn’t vote for myself!

I really hope the following will be beneficial.  You all pay to attend and I take that responsibility of participating very seriously.  If you plan on attending, please make your way to the Accelytics booth and introduce yourself.  I am really looking forward to meeting you.

Hidden Gems in PBCS – The Benefits They Don’t Tell You About

Tue, Jun 25, 2019 (02:15 PM – 03:15 PM)
602/603, Level 6

Session Summary for Attendees
There are a million reasons to move to the cloud, but these enhancements are not marketed. From somebody that fought the drawbacks, I now cringe when I have a client that is still using the on-premise version of Planning.
This session will provide an administrator 5 to 10 hidden secrets that you won’t hear from your Oracle sales rep. Unless these are pointed out, or you go to training and they are discussed, they will likely never be found. We will discuss foundational improvements like how to evaluate where to focus your time on calculation performance issues, debugging calculations by stepping through the calculation, and stress testing your application. This presentation will include hands on demonstrations of all the functionality and features discussed.
Attendees will leave this session with the knowledge and examples that will allow them to go back to their workplaces and use them to improve their applications. Users looking to move to the cloud will learn about some of the hidden gems that often go forgotten.

Detailed Abstract for Review
This presentation will walk attendees through multiple features that they may not be aware of if they are using PBCS and functions they don’t have access to if they are using the on-premise version. It will begin with an overview of these. It will demonstrate the functions with live demonstrations that will allow participants to make an immediate impact in performance and improve the user experience.

The presentation will be structured as follows:
• Introduction
• Basic Navigation in the cloud UI
• Demonstrate the options to debug calculations
• Demonstrate the option in calculation manager to find and improve time intensive calculations
• Discuss the option of stress testing PBCS
• Provide a checklist for administrators to take with them and implement improvements

Getting Started with Groovy for the Non-Technical Superstars

Mon, Jun 24, 2019 (11:45 AM – 12:45 PM)
602/603, Level 6

Session Summary for Attendees
Groovy calculations are not just accessible to those with lots of experience writing Java, Groovy, or other coding languages. With a little guidance, you can become extremely productive and add some world class functionality to your applications. This session will be delivered with both the experienced, and non-experienced, by a person with a finance degree that learned it on the fly.
This session will provide an administrator with the knowledge needed to get started writing Groovy calculations immediately. We will introduce how to get started with Groovy and use it to interact with PBCS via the API. Three to four key concepts will be covered for you to leave understanding the possibilities. We will discuss where and how to get help, learn from examples, and avoid spending time going down some of the wrong paths like I did.

Attendees will leave this session with the knowledge to implement basic Groovy calculations, examples of more complicated solutions, and the foundation to grow on. They will take home working examples, and references to all the concepts needed to go from 0 to 60 in 4 seconds.

Detailed Abstract for Review
This presentation will walk attendees through multiple features that they may not be aware of if they are using PBCS and functions they don’t have access to if they are using the on-premise version. It will begin with an overview of these. It will demonstrate the functions with live demonstrations that will allow participants to make an immediate impact in performance and improve the user experience.

The presentation will be structured as follows:
• Introduction
• Understand how to get started
• Demonstrate and break down how to add user functionality
• Demonstrate and break down how to add pre-save validation
• Demonstrate and break down how to add real time data model synchronization on data form save
• Where to go to get help

If you haven’t signed up, please go out and do that today I hope to see you at one of my sessions.

 

Changing application settings was always a little bit of a pain with an on-premise Planning application.  It was a time intensive task of recreating the application, artifact groups at a time.  If you were a little bit of a risk taker, you might have figured out that there were fields in the relational repository that could be updated.  Is there an easy way to do this with PBCS?  Read more

 

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 can’t tell you how many times I have been at a client and they wanted to replicate eliminations at the first common parent like HFM, or some other consolidations system.  Maybe there is a good way to do this, but I could never find an efficient and effective way to accomplish it with Essbase calculations.  Well, that is history.  This is yet another example of how to solve an historically complex problem very simply. Read more

 

I had a great question today so challenge accepted!  A reader asked if it was possible to run a data export and have the system date in the file name.  The answer is very simply, yes.  I don’t have any content around the question, so I will answer it in two ways. Read more

 

To date, we have talked about the performance improvements Groovy introduces, as well as the creative validation we can add.  One thing that hasn’t been covered yet is the ability to add functionality to make the input easier for a planner.  Replicating changes through the months, resetting the values back to the defaults, and many other concepts can be developed to make the user’s lives easier. Read more

 

Manipulating dates is not something you may think is that useful, but there are a number of things that we have done in the past that are slow performing in Essbase, and others that were not possible or you may not have ever thought of.  This is going to walk visitors through ways to manipulate dates for all kinds of uses.  Hopefully it inspires some ideas for you to make your application a little more polished. Read more

 

There has not been alot of troubleshooting discussed in the adventures series.  Just like with most coding languages, you can gracefully handle errors resulting from actions (like divide by 0) and return descriptive information to the users and administrators in the job console.  There are several benefits that I see.

  • As previously stated, since the error is accounted for, the user doesn’t get a message that shows a failure with no context.
  • The error object will provide more information about what happened and what should be done to fix it in the future.
  • Predefined actions can take place since the error doesn’t interrupt the script, like returning an error message that tells the user to contact the administrator with an action

Error Handling Introduction

Try / catch / finally is a concept most development languages have.  Conceptually, you “try” some group of commands and “catch” any errors that might happen.  If you “catch” an error, you account for it by doing something.  “Finally,” you perform any closing actions.

try {
  def arr = 1/0
} catch(Exception ex) {
  println ex.toString()
  println ex.getMessage()
  println ex.getStackTrace()
}finally {
   println "The final block"
}

In this case, ex.toString() prints

java.lang.ArithmeticException: Division by zero

ex.getMessage() prints

Division by zero

and ex.getStackTrace()

[java.math.BigDecimal.divide(Unknown Source), org.codehaus.groovy.runtime.typehandling.BigDecimalMath.divideImpl(BigDecimalMath.java:68), org.codehaus.groovy.runtime.typehandling.IntegerMath.divideImpl(IntegerMath.java:49), org.codehaus.groovy.runtime.dgmimpl.NumberNumberDiv$NumberNumber.invoke(NumberNumberDiv.java:323), org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56), org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48), org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113), org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125), ConsoleScript11.run(ConsoleScript11:2), groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:263), groovy.lang.GroovyShell.run(GroovyShell.java:387), groovy.lang.GroovyShell.run(GroovyShell.java:366), groovy.lang.GroovyShell.run(GroovyShell.java:170), groovy.lang.GroovyShell$run$0.call(Unknown Source), groovy.ui.Console$_runScriptImpl_closure18.doCall(Console.groovy:1123), groovy.ui.Console$_runScriptImpl_closure18.doCall(Console.groovy), sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method), sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source), sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source), java.lang.reflect.Method.invoke(Unknown Source), org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98), groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325), org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294), groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:989), groovy.lang.Closure.call(Closure.java:415), groovy.lang.Closure.call(Closure.java:409), groovy.lang.Closure.run(Closure.java:496), java.lang.Thread.run(Unknown Source)]

The script in the final block is also written out.  It is intended for cleanup and tasks that run at the end of a script regardless of whether there is an error or not.

Handling Errors Uniquely

The catch command can be replicated to handle errors uniquely.  Let’s expand on the example above.  Assume the variable is coming from an RTP or cell value.  The following has a catch for a specific error.  The java.lang.ArithmeticException is equal to the output of ex.toString().  There are probably thousands of errors, if not more.  The easiest way for me to grab these is to use the ex.toString() and see what it produces.  I have no desire to remember or learn them all!

The following will do something different for the divide by zero error than all other errors.

try 
  {
  def denominator = 0
  println 1/denominator
  } 
catch(java.lang.ArithmeticException ex) 
  {
  println ex.getMessage()
  println "an action should be taken to account for the error"
  }
catch(Exception ex) 
  {
  println ex.toString()
  println ex.getMessage()
  println ex.getStackTrace()
  }
finally 
  {
  println "The final block"
  }

Finishing Up

This requires a little more effort, but once you get used to doing this, it can be reused.  I hear the argument that if you account for every possible situation, you don’t need to error trap.  That is true, and if you are smart enough to account for everything that can go wrong, don’t include this in your Groovy calculation.  I would argue that simple calculations probably don’t need this level of error handling, but more complex logic might be a candidate.  The example above could obviously be handled with an if statement, but put it in context.  It is used to illustrate the concept of try / catch / finally.

 

I had a very interesting thing happen today that tripped me up.  When loading data to a PBCS database through Planning (not as an Essbase file), I had two types of errors.  I have never seen this before and this could cause some serious heartburn for administrators and possibly waste a ton of time trying to resolve.  So, I am sharing for the sake of saving somebody some effort. Read more