Kaleidscope 2010 Registration Is Open

The ODTUG Hyperion SIG has worked hard this fall to put together a terrific agenda and it is now available for you to explore. Thanks to Hyperion SIG President, fellow Oracle ACE, and friend Gary Crisci for posting the agenda to Google docs. Keep in mind the presenters have not all confirmed their presentations and the hands-on labs have not been finalized, so there will be minor adjustments to the agenda, but click on the picture to see the Hyperion agenda as it stands right now.

The conference is scheduled for June 27- July 1, 2010, at the Marriott Wardman Park Hotel in Washington, D.C. Be sure to register before January 21, 2010 to receive an ODTUG commemorative T-shirt and be given first priority to sign up for the hands-on training.

As I am heading up the work on the hands-on labs, let me know in the next week or two what hands-on labs you would be interested in participating in and we will use your feedback in determining the labs that are available. 

Dodeca Earns Windows 7 Certification

We have put Dodeca through the official Microsoft Windows 7 compatibility testing and it passed with flying colors.  Given our .Net Smart Client architecture, it was actually quite easy to pass the necessary tests.

Since we have passed that testing, we can now display the Microsoft Compatible with Windows 7 logo with the product.  I don't know for sure, but my guess is Dodeca is the first and only Essbase aware user interface certified and supported on Windows 7.  That may not seem that important now, but according to Microsoft, computer system builders will no longer be able to sell new systems with Windows XP starting in an little over a month from now (http://www.microsoft.com/windows/lifecycle/default.mspx).  Corporate users may have extended license agreements but the writing is on the wall that Microsoft is committed to Windows 7 adoption much more than their commitment to Vista a couple of years ago.  Dodeca, which is also supported on Windows 2000, Windows XP and Windows Vista, is ready for Windows 7 whenever you are.

Debugging the EPM Configurator

I installed WebLogic today and ran the EPM Configurator to deploy APS in WebLogic.  Unfortunately, it didn’t work the first few times I tried.  It seemed to work except it finished very, very quickly. I never before had a problem with the Configurator so it was a bit surprising, as well as a bit perplexing, as to where to turn next. I did a little Googling and didn’t find anything so I turned to the last resort for us geek-types, ‘reading the instructions’.

Somewhere in the docs I found a reference to the %HYPERION_HOME%\logs\config directory. A quick check of that directory and, sure enough, there were some files with a new timestamp including the configtool_err.log. Here is the entry that logged the error that was causing me problems:

(Dec 17, 2009, 04:37:42 PM), com.hyperion.cis.config.Configurator, ERROR, Error:
java.lang.ClassNotFoundException: com.hyperion.ess.APSAppServerConfigurator

ClassNotFoundException is almost always caused by an incomplete CLASSPATH. It took me a while to find the class. What I finally found was the %HYPERION_HOME%\common\config\9.5.0.0\product\aps\9.5.0.0\aps_1.xml file.  It contains information the Configurator uses to understand how to configure APS. This file contained, among other things, the following entries:

<classpath>
 C:\Hyperion\products\Essbase\aps\lib\essconfiguration.jar
</classpath>
<productappserverdeployer>
 com.hyperion.ess.APSAppServerConfigurator
</productappserverdeployer>

Bingo! A quick check of that directory showed the essconfiguration.jar file was not there. Fortunately, that jar file was present in a number of other Hyperion directories. I copied the jar file to the proper location and I was off and running.

When I get a chance, I am going to go explore those xml’s more to see what I can learn..

Dodeca Architecture, Part 2

In this part of the series, I am going to focus on the Data Tier and, more specifically, what interactions Dodeca has on this tier. Just a word of warning though; this article gets a bit technical as it digs into the details of the how Dodeca uses the Data Tier.

Legal Notice: This post includes some details that are the subject of our pending patents.

There are two commonly accessed data servers in a typical Dodeca implementation:

• Essbase Servers
• Relational Servers

The data servers are accessed from the Middle Tier via TCP/IP. Many of our customers have multiple Essbase servers and multiple Relational Servers. We also have Dodeca customers running every version of Essbase from 6.5.7 through 11.1.1.3. The common version at this time seems to be 9.3.1. On the relational side, we have customers using Dodeca to access Oracle, SQL Server, DB2, Teradata and MySQL.

In Dodeca, the Essbase server is used, obviously, to get Essbase data. It is also used as a source to drive member selectors. Optionally, the Essbase server is used to authenticate system users and filter the views or reports available to a user.

All communication to Essbase is via the Essbase Java API calls from the middle tier. One primary reason we use that API is that it features the Essbase Grid API which is the special sauce in Essbase that sets it apart from its competitors. The Grid API enables both Dodeca and the classic Excel add-in to have the Query-By-Example functionality so popular with users. If you don't know what Essbase Query-by-Example is, here is a blog post series I wrote that explains it:

• How Does the Essbase Excel Add-in Work, Part 1
• How Does the Essbase Excel Add-in Work, Part 2
• How Does the Essbase Excel Add-in Work? (Part 3: Why Dodeca is Easier and Better)

Dodeca uses, by default, Essbase security to authenticate users and to control access to data and metadata. Another option in Dodeca allows administrators to map the views or reports available to users based on their Essbase group memberships. This makes it easy for customers who have built robust security models in Essbase to leverage their work in the user interface.

There are two primary uses for relational servers in Dodeca. First, all configuration settings for Dodeca are stored in a relational database. Further, many systems need some relational component for controlling the system and/or for providing information beyond the Essbase data.

The configuration settings for Dodeca are stored in a fairly simple schema. When I was architecting the schema, I initially designed a highly complex, highly normalized schema. Before I completed that work, I decided the complexity would be hard to manage, particularly when we wanted to build more functionality into our product. I tried looking at the problem from many different perspectives and had a great idea. I asked myself, “Why not store everything in one table?” I asked myself. In the end, this simplified metadata storage approach was the one we chose and, in fact, became the subject of one of our patent filings.

There are multiple benefits to Dodeca customers using this approach. The schema is very easy to understand as there are only few tables. The design also makes upgrades very easy as most upgrades do not change the structure of the metadata storage even as we add significant new functionality to the product. As such, some of our customers have done significant Dodeca upgrades in less than an hour. The simplified design also makes backup and migration extremely easy; you can backup an entire Dodeca application, or individual configuration settings, into a zip file in a couple of minutes. You can then migrate your application to a new server, say your production server, by restoring from the backup zip file.

Here is a listing of the tables in the schema as they appear in Oracle Enterprise Manager.


The Dodeca tables fall into a few categories. Those categories and their purpose are listed in the table below.

Artifact Storage	Stores all system configuration information.
Commentary	Stores commentary entered by users along with accompanying key structures and file attachments.
Usage Log	Logs usage of artifacts used by users.
Data Audit Log	Logs changes to Essbase data.
Metadata Audit Log	Logs changes to configuration data.

The key table in the schema is the BINARY_ARTIFACTS table. This single table is used to store all configuration information including view/report definitions, Excel templates, Essbase connection information and literally everything else a Dodeca administrator can configure. Here is a listing of the columns in the table as they appear in Oracle Enterprise Manager.

The table has four columns in the primary key. The ARTIFACT_TENANT code enables customers to have several separate Dodeca instances deployed in the same database. A customer may have an application for Finance and an application for Marketing that never share any reports. In this case, the tenant code enables customers to use the same Dodeca instance to serve both user communities.

The ARTIFACT_CATEGORY identifies the type of metadata stored in a particular row. For example, a row with the category ESSBASE_CONNECTION is, obviously, metadata related to a defined Essbase connection used in the Dodeca system.

The ARTIFACT_ID and ARTIFACT_VERSION column values complete the unique identification of the metadata within a row. As the name implies, Dodeca supports multiple versions of certain types of metadata. Multiple versions are most typically used with Excel spreadsheet template artifacts during development. This capability allows administrators/developers to store multiple versions of a spreadsheet template and, with a mouse click, rollback to a previous version.

The most important column in this table is the ENCODED_ARTIFACT column. This column stores the real metadata in a zipped, encoded string format. Though most configurations stored in this column are actually XML files, Excel files and extension modules written in VB.Net or C# are also stored this way in Dodeca. The CHECKSUM of the encoded artifact is also stored and is used as part of the bandwidth efficiency algorithms in the product. As a result, we believe Dodeca uses a fraction of the bandwidth consumed by other products in our space.

Here is a screenshot showing a few columns of data from the BINARY_ARTIFACTS table.



The first row contains an Essbase connection definition. In this case, the ENCODED_ARTIFACT column contains XML that describes an Essbase connection. The decoded XML from that record is shown below.


As you can see, the XML includes the normal information you need to connect to an Essbase database: server, application and database. All you have to provide is the username and password (and those items can optionally be stored in TripleDES encrypted format). It also has a value for the ServletPath. The ServletPath is the URL the Client Tier uses to connect to the Dodeca Essbase services running on the middle tier.

You may be asking yourself if you have to understand and edit XML files to configure Dodeca. Absolutely not! The administrator edits the metadata on the client tier in our metadata editor forms. The forms write the XML on the fly when the administrator saves their changes.

Another artifact category stored in the table represents a special type of metadata called a SQLPassthrough Dataset. This category of metadata configures SQL connections and SQL statements that are used in Dodeca to bring any relational data, whether it is part of the Hyperion stack or not, into Dodeca. For example, many of our customers drill-through directly from Essbase to their general ledger system. We are currently working on some enhanced functionality in this area. I will post a more detailed blog entry on the SQL Passthrough functionality once the enhanced functionality is released.

As you can see, Dodeca has some unique features on the Data Tier. In the next posting in this series, I move the focus to the Middle Tier.

Dodeca Architecture, Part 1

In my last post, I talked a bit about the Dodeca architecture and the patents pending on our design. I had our graphics designer come up with some nice looking graphics so I can talk a bit more about our design and expand on why architecture makes a difference. In the first post of this series, I am going to discuss the general architecture.

Dodeca has a three tier architecture.
The first tier, the Client Tier, is the Dodeca user interface. The user interface of Dodeca is built using Microsoft .NET technology. We chose this technology due to the strength of Windows on the desktop and the strategic importance that Microsoft has attached to .NET. Technically speaking, the user interface is classified as a .NET Smart Client. This means that the interface is highly interactive like a normal Windows application, however, all communications with the middle tier are via web services (xml transported via http). The Smart Client is delivered to the desktop via Microsoft ClickOnce technology which makes it easy to deploy to the desktop.

The Dodeca middle tier consists of two services, the Dodeca service and the Dodeca-Essbase service. The Dodeca service is responsible for handling metadata requests from the Dodeca client along with facilitating relational data transactions. The Dodeca-Essbase service is responsible for all Essbase interaction.

Finally, the data tier is typical in all modern systems. In Dodeca, the data tier stores not only the data that is displayed to the user, but it also stores all of the metadata that configures the application. All configuration settings including view/report properties, Essbase and SQL connections, point of view selectors, toolbars and even Excel templates, are literally stored in a relational database on the data tier.

In other posts in this series, I will expand on more of the architecture and benefits of each tier.

Dodeca Patent Progress

The thing that sets Dodeca apart from all of our competitors is architecture. We spent much time and effort looking at the problems potential customers were seeing with the products they were using. Based on what we learned, we engineered Dodeca to minimize or eliminate those issues. Our primary goal was to create a software product that would be so flexible and functional that we would rarely need to say no to even the most extraordinary user requests. Believe me, some of those requests can be very extraordinary! After man-years of work, I am glad to report that we have met this goal and increased ease of use.

Ease of use means different things to different people. For end users, ease of use means they can explore their data and get the information they need in very obvious ways with only the slightest bit of training. For administrators, it means they can configure the system easily and quickly deliver applications to their users. Finally, for IT departments, the deployment and on-going maintenance of an application must be painless.

One key feature of the Dodeca architecture is the modular design that allows us to very easily plug in new functionality. This modular concept runs deep within Dodeca. In fact, Essbase functionality in Dodeca is a plug-in module. The plug-in concept also allows customers to remove functionality from their distribution. For example, if a customer wants to use only relational databases with Dodeca, they can simply delete the Essbase module files in their deployment.

A second key design aspect of Dodeca is its metadata driven nature. Everything that can be configured within Dodeca is stored as metadata, in a relational database, on our server. When a piece of metadata is required at runtime, it is requested by the Dodeca client via web services and returned, as XML, over the network via HTTP. Metadata transmitted this way includes report definitions, spreadsheet templates, Essbase connection information and toolbars. Similarly, relational data and Essbase data, including outline information, is transmitted via web services.

The use of XML adds significant flexibility to Dodeca. As an added benefit, it makes in-place upgrades easy. We have customers with thousands of users who have upgraded their Dodeca version in about 15 minutes. XML also gives Dodeca flexibility on the Essbase side. A single version of Dodeca works with every version of Essbase from 6.5.3 to the latest 11.1.1.3; we even support multiple retrievals, from any supported version, into the same report.

The modular architecture and the metadata driven aspects of Dodeca also work together. Some customers and partners, such as greenEPM, have leveraged our modular architecture to build extended functionality on the Dodeca Framework. Extensions are built in Visual Studio using C# or VB.Net and packaged using XML descriptors. Custom modules in Dodeca are treated as metadata and are delivered to the client via web-services. We believe this is a unique aspect of our product and is the subject of one of our pending patents.

This week, we received notice from our Intellectual Property attorneys that our patent application has been published; it will be quite a while before it is rewarded. It was a large time investment to complete the patent application, but, hopefully we will be patent-holders in the near future.

How Much Work Has Gone Into Dodeca?

So, exactly how many man-years have gone into creating Dodeca? A lot as evidenced by a look at the keyboard of Amy Tate, the Dodeca Architect. This is a relatively new Dell Latitude D830 laptop but she has polished off some of the letters in our quest to create great software..


Obviously you can see how hard we have worked on the product. If you want to really find out how we hit the mark on the greatness aspect, just ask our customers. After all, some of our customers may be your competitors!