Monday, September 28, 2009

Powered by Dodeca

Although we don't advertise it heavily, Dodeca built on a framework that we spent years engineering. The engineering effort was extensive as we had many goals:
  • We didn't want to be tied to a specific grid control.
  • We didn't want to be tied, necessary, to a specific database.
  • We wanted to be able to quickly respond to the changing market and provide support for new and exciting innovations.
  • We wanted to provide a platform for other partners to build on.

To meet these goals, our architect spent nearly 18 months evaluating and designing the framework before there was anything to see. Dodeca has met all of those goals and is really now more than just the best user interface for Essbase. When combined with it's metadata-driven nature and smart client/web services implementation, it is a strong platform for building applications.

We are now seeing some of the fruits of our labor becoming utilized. A new software company, Real Sports Analytics, has built their product on the Dodeca framework. This gives them the ability to fully utilize the Essbase and relational functionality we have put into Dodeca and focus solely on implementing their business logic.

The object-oriented, modular, plug-in architecture of Dodeca is the key to their implementation as it allowed them to build some report views that are very specific to their business. As a result, they were able to reduce their development time by a factor of man-years at a savings of hundreds of thousands of dollars.

This same modular architecture is pervasive throughout Dodeca as, in fact, the core functionality users see in out-of-the-box functionality, down to the Essbase interaction itself, is actually a plug-in on our framework.

To see screenshots of the Real Sports Analytics implementation, visit their product page at http://www.realsportsanalytics.com/prod01.htm.

Be sure to watch this blog for another upcoming powered-by Dodeca announcement with screenshots.

Friday, September 25, 2009

Running Essbase on an Alternate Port

There have been some questions posted on the forums recently about running Essbase on alternate ports. You can run the Essbase agent on a port other than it's default port 1423 by changing the AGENTPORT configuration file setting. Frankly, I have never seen a good reason to run Essbase on an alternate port with the exception of when customers were running multiple instances of Essbase on the same machine. Further, nothing should interfere with port 1423 as it is registered with the Internet Assigned Numbers Authority at http://www.iana.org/assignments/port-numbers:

essbase 1423/tcp Essbase Arbor Software
essbase 1423/udp Essbase Arbor Software


The AGENTPORT setting is documented at http://download.oracle.com/docs/cd/E12825_01/epm.111/esb_techref/frameset.htm?agentport.htm. You can change the port in the essbase.cfg file by simply specifying the new port:

AGENTPORT 2600

That is the easy part; the harder part is on the client side. You basically have a couple of choices to let Essbase know to connect to an alternate port. Unfortunately, the easiest method for users is the hardest to deploy. That method is to add an AGENTPORT entry to a client side essbase.cfg file in the %ARBORPATH%\bin directory. This method allows users to login without entering a port number for Essbase but you have to get that file deployed first. That can be challenging if you have a hundred or a thousand users. Otherwise, the user must enter a port number after the server name. In the classic Excel add-in, it looks like this:



That format is consistent through the Java API as well. Here is a screenshot of the login dialog from our OpenOffice add-in, which is written in Java, showing the port. Note that this screenshot was done on a Windows 7 machine:



Finally, our Dodeca product hides that complexity from end users as the port is configured in our Essbase Connections metadata editor and stored in our server:



When a user logs into Dodeca, they simply enter their username and password as every other parameter is already mapped for them on our server:



Alternatively, Dodeca can be configured to hide the Essbase server, application and database:




I think Dodeca makes it easier.

Tuesday, September 15, 2009

Essbase 11.1.1.3 on Windows 7 x64

My team has been working getting Essbase 11.1.1.3, Shared Services, EAS and APS running on 64-bit Windows 7. It has not been a smooth process but we have it running.. Here is a quick synopsis of the issues we saw just to get it running:
  • OpenLDAP did not start. We had to manually add some registry entries.
  • The Java JRE did not install properly in the %HYPERION_HOME%\common directory structure. We had to manually copy that directory structure from a good install on a supported OS.
  • EAS client did not install; the Java Web Start version worked flawlessly.

Once we worked around these issues, we were able to run the basic Hyperion stack on Windows 7 and it performed normally. Of course, nobody in their right mind would run this in production, but us developer and consultant types like to stay up to date on the latest. Further, I have 4 Gb of RAM on my laptop but a full gig never gets touched with my current 32-bit XP setup.

We also tested the install on 32-bit Windows 7 and saw exactly the same results. We tried setting the OS compatibility on the install programs and didn't see much difference either. Finally, we installed a baseline on a supported Windows 2003 Server OS. In the near future, I will post a table of all of the things that did not install on Windows 7 along with, hopefully, step by step instructions of how to get Essbase to work on Windows 7.

As expected, Dodeca ran as expected on Windows 7 due to the abstraction layer the .NET Framework provides over top of the OS.

Thursday, September 10, 2009

Star Analytics Patent Award

Congratulations to my friend Quinlan Eddy at Star Analytics for being awarded a patent on some of the technology underlying their Star Integration Server product:

http://www.staranalytics.com/news/news_items/2009_08_12_PR_SFCC.htm

I wonder how many patents applications they have filed on their Star Finance Command Center?

We have multiple patent applications filed for technology we developed for the Dodeca Platform that is the foundation of our Dodeca product. Perhaps in the future, we will join Quinlan as patent holders as well.

Wednesday, September 9, 2009

Fun with Excel

At the recent Kaleidoscope Conference, one of the Oracle speakers asked how many people in the room used Smart View. Of the 200 or so people in the room, about 10 raised their hand. When he asked how many used the classic Essbase Excel add-in, everyone raised their hand. I think this small poll is representative of the community as a whole.

As the classic Excel add-in is not the strategic direction for Oracle, there hasn't been much incentive over the years to improve it and it shows as the bugs have been accumulating. Here is one pretty egregious bug that is so bad, I find it shocking that customers continue to put up with it. The bug occurs when the Essbase add-in gets confused when a user has two instances of Excel open (like no accountant would ever do that, right?) It is very easy to replicate as shown in this brief video:


By the way, the airplane on the screen is not mine (but my Cessna 210 is one year newer than the one in the picture!)

For what it is worth, Dodeca does not suffer from the same issue (nor any of the dozens of other Excel add-in issues Essbase users often see).

Tuesday, September 8, 2009

Essbase 11.1.1.3 Support Announced

We recently announced support the Essbase 11.1.1.3 for our entire product line including:

  • Dodeca
  • ActiveOLAP for Essbase
  • OpenOffice Add-in for Essbase
  • OlapUnderground Outline Extractor
  • OlapUnderground Advanced Security Manager
  • OlapUnderground SubVar Manager

I can tell you how valuable our heavy investment in automated build processes is to our company but the proof lies in our ability to quickly provide support for new Essbase versions as they become available while continuing to support and enhance the functionality of our products against previous versions.

Additional value lies in the engineering of our Dodeca product where we have taken Essbase compatibility to a whole new level with our database abstraction layer. The abstraction layer allows us to target a single version of the Dodeca client to every version of Essbase from 6.5.3 to the latest 11.1.1.3. Further, the abstraction layer gives us the unique ability to retrieve data from multiple versions of Essbase into the same spreadsheet 'side-by-side'. Think about that the next time you have to roll out the latest patch of the Excel add-in to a thousand users spread around the world!

Tuesday, September 1, 2009

Little Nitpick on VBA - Continued

Here is a comment on was posted on my 'nitpick' blog post by 'Jared'; I thought it would be better as a separate post:

Speaking of lost productivity...one thing that has thrown me off in VBA (with Essbase or not) is the syntax for calling functions and procedures--when to use parentheses or not. For example, every Essbase VBA programmer has used EssVRetrieve, probably in the format:

dim sts as long


'Retrieve data from the current sheet
sts=EssVRetrieve(Null, Null, 1)

The function runs and its return value is assigned to the variable sts.

Now, in some cases, I want to call functions and I don't care about a return code. Or, I want to call a procedure (which you cannot assign to value, of course). But if you do this:

EssVRetrieve(Null,Null,1)

...or this, for example:

CheckCellValue(Activesheet.Name,
5, FALSE)


...you'll get a syntax error. And since function syntax in most documentation includes the parentheses, you may have a hard time figuring out the error. Even the auto-complete in the VBA editor seems to indicate that the parentheses are OK: type a left paren after the
function/sub, and it will list the arguments for you, as if everything is just fine.


Unfortunately, it isn't. :)
So the rule is this: only use parens with a function call if you are assigning a value to the function; and if it's a sub procedure, you never use parens. So you would have:

EssVRetrieve Null,Null,1 'Retrieve data, don't worry about return code


...or:

CheckCellValue Activesheet.Name, 5, FALSE 'Call "CheckCellValue" proc, passing parms

Hope this isn't too much of a derail, but it just came to mind...

Not too much of a derail at all Jared as I think it will be useful information for a number of blog readers.