I wrote this article several years ago for ODTUG when FDMEE was first introduced in 188.8.131.52. Since then we have seen tremendous improvements in the application in terms of new functionality, parity with FDM Classic and overall stability. Many organizations are considering an upgrade to 184.108.40.206 and given that FDM Classic is now officially sunset, the changes in FDMEE are more relevant than ever. I have updated this article and am sharing again as many organizations face this important decision.
For those organizations that are considering an upgrade from FDM Classic to FDMEE, the new scripting language (Jython) of FDMEE likely represents one of the most intimidating changes in the application. Let’s level set for a moment. Customers have a choice with FDMEE scripting – VBScript or Jython. I have spoken with a number of customers that have asked, “can’t I just stick with VBScript since it’s very similar to FDM [Classic] scripting.” The technical answer is, in most cases yes you likely could. The more thought out answer is, “have you considered what you are giving up by electing to use VBScript instead of Jython?” Well that it really isn’t an answer is it.
Let’s take a moment to understand why I ask that question. Let’s consider at a high level the differences in these 2 languages. From Wikipedia: VBScript (Visual Basic Scripting Edition) is an Active Scripting language developed by Microsoft that is modeled on Visual Basic. It is designed as a “lightweight” language with a fast interpreter for use in a wide variety of Microsoft environments. Jython, successor of JPython, is an implementation of the Python programming language written in Java.
Take a moment to consider the Enterprise Performance Management (EPM) stack at Oracle. Have you noticed any trends over the past 3-4 years? In 220.127.116.11, Oracle rewrote the UI for HFM using the Oracle ADF framework. In 18.104.22.168, Oracle removed all but the most basic functionality from the HFM Win32 client. In 22.214.171.124, HFM no longer requires any Microsoft components (bye bye DCOM) and for the first time ever can run on a non-Windows platform – albeit only Exalytics at this point. My point in this trip down memory lane is that Oracle is clearly moving away from any reliance on Microsoft technology in its product stack. Any time I have said this, the question inevitably is asked, “do you think we’ll still be able to run EPM on Windows servers?” My answer is a resounding YES. Oracle may not be the biggest fan of integrating Microsoft technology into its software solutions but they are smart enough to understand that failing to support Windows as a server platform would lock them out of too large of a share of the market. So breathe easily, I don’t see Oracle producing EPM software that won’t be able to be deployed on Windows servers. That said, the EPM stack is moving toward becoming fully platform agnostic and FDMEE is no exception.
Given this bit of background, let’s talk about why I firmly believe Jython is the better choice for your FDMEE application. Oracle rarely kills off products but instead focus development efforts on new and better technology. The result is that while the old application still works, it lacks all of the shiny new bells and whistles that the new product has (yes I’m talking to you folks that still run Hyperion Enterprise). I sometimes call this “letting something die on the vine.”
As the EPM stack moves toward being platform agnostic I believe that components of the application that are reliant on Microsoft technologies like VBScript will die on the vine. The application programming interface (API) will continue to be enriched for the Jython language set while the API for VBScript will stagnate. Please keep in mind, this is just my prediction/opinion at this point – no one at Oracle has given me an official or unofficial word of this as a strategy. But remember, Oracle is no different than any other organization that undertakes technology projects. They employ the same three levers that every project does – scope, time & budget. As a customer of EPM, you have noticed the speed at which new releases have been deployed. To continue to support two sets of APIs within these accelerated development timelines will require one of the remaining levers to be “pulled.”
That leaves us the scope and budget levers. To maintain complete parity (scope) with a fixed timeline, the remaining lever is budget. Budget for any technology project is heavily correlated to people/projects. Add more people to the project, the cost goes up. As I said before, Oracle is no different than any other organization. Project costs must be justified. So the development head of FDMEE would need to justify to his senior management the need to add additional resources to support having two sets of APIs – one of which is specifically for Microsoft technologies. One can imagine how that conversation might go.
So we’re left with the third and final scope lever – scope. There are two APIs – one to support Jython (JAVA on Python) and a second to support VBScript (a Microsoft technology). Let’s not forget that Oracle owns JAVA. Given that the organization owns the technology that is core to one of the scripting languages, which do you think will be more robust?
Ok, so you’re the type of person that doesn’t just listen to pseudo pundits pontificating. That’s good. In the words of Albert Einstein: “The important thing is to never stop questioning.” So let’s say that you believe my above predication is wrong or you need more evidence to support the recommendation to use Jython. Let’s focus on one key difference in these technologies – error handling. Throughout my years of developing scripts for FDM Classic, the reoccurring theme I heard from customers was when a process fails, can the system alert me. The technical answer is, most likely. The practical answer is no. While in a VBScript routine I can leverage the On Error Resume Next in conjunction with If Err.Number = 0, I would need to do this after every line of code and that is simply not realistic. The best solution I have found is writing scripting operations to a log file that can then be reviewed to identify the point at which a script fails. While this approach has helped, it’s not nearly as elegant as true error handling like what is available in Jython.
Jython provides error handling through the use of the Except keyword. If you have ever written (not recorded) Excel VBA macros, you may be familiar with this functionality. In VBA you would code On Error Goto ErrHandler and then have code within an ErrHandler section of the script that performs some operation in the event of an error. Within Jython, there is a similar albeit more robust concept with the Try…Except keywords. For example:
return ‘You cannot divide by zero, try again’
In the above example, the Except clause is used to handle division by zero. With Jython you can have multiple except clauses to handle different anticipated failures in a process. Likewise you can have a catch all (Finally) clause to handle any unexpected failures. A key functionality with the except clause is the ability to capture the line in the script which caused the failure. This is a key improvement over VBScript.
We could continue to delve further into the technical details of why Jython is a more robust language but when I think about this conversation in context of, why do I want to use Jython instead of VBScript for my application, I think the above arguments are compelling on their own. If you are interested in learning more about Jython scripting for FDMEE, check out my KScope presentation Jython Scripting in FDMEE, It’s Not That Scary which can be found on the Presentations page of the Knowledge section of this site.