Technical Overview

Saxbi is actually two things: an app (the client), and a server (Saxbi Server). Saxbi Server acts as an intermediary for the app and your Essbase servers, and the Saxbi App communicates solely with the Saxbi Server. Although the app may eventually show data that comes from an Essbase cube, that data is actually pulled by the Saxbi Server and sent back to the app. The app itself does not communicate directly with any of the underlying databases. Saxbi Server handles incoming requests and delegates them appropriately. To understand how the Saxbi App and Saxbi Server work together, it is important to understand the basic terminology for Saxbi as whole:

View

A view can be thought of as a template for a particular report. Think of it as a recipe for what to show, and how to show, but doesn’t contain any business data itself. For example, one might have a View available called “Sales by Department and Time”. The type of this vie could be a “Fixed Essbase Grid View”. A Fixed Essbase Grid View is very similar to a report generated in Excel using the Hyperion add-in, where all of the members are laid out in a particular way, and then data is retrieved to populate that view with data.

Selector

A view contains one or more selectors. Selectors are configured to fill in parameters for the view. For example, in the View mentioned above (the “Sales by Department and Time” which is a “Fixed Essbase Grid View”), one might have to choose which Year (a member from the Year dimension) is to be used to build the report. In other words, the grid layout of the view doesn’t change, we’re just making a selection for what is in the point of view (POV). A selector would be defined that details which choices can be made and how many can be selected. The simplest type of selector is the “Defined List Selector”, which simply allows for choices to be made from a list of choices. If we wanted the user to be able to choose which Year to use to build the view, then we could make a selector with the choices “2010″, “2011″, “2012″, and so on.

Report

A Report is the result of a View being chosen, selectors being configured, and a request for it to be built. Going with our earlier example above, the “Sales by Department and Time” view may be built using “2012″ as the year, and the result is a particular type of report, in this case, a Fixed Essbase Grid View would generate a report of type Olap Report.

Connection

A connection is simply a mapping to a data source. Usually this will be an Essbase connection which includes the URL to the APS/EDS server, the name of the OLAP server, the application, and the database. A connection is specified in a view to determine where to pull data from.

Repository

The repository is where Saxbi Server stores all of its objects — Views, Selectors, Reports, Connections, and others. Every object in the repository has unique name that identifies it and can be referenced by other objects.

Putting it all together

Saxbi has been carefully architected in order to achieve a high level of flexibility, reusability, and ease of administration. Quite often, different reports coming out of the same cube are very similar to each other. In order to reduce the administrative burden, Saxbi components are designed to be reused as much as possible. For example, once a Connection object has been setup, it can be simply referenced by name in any View. Once a selector is setup, it can be referenced by multiple views. Views can be put together by grabbing “off the shelf” components and putting them together. Even better, when a change is made to the reference selector (for example, to add a year to the Years selector), it is automatically “seen” by any views that reference it.