Adding Drill Through to your Hyperion Implementation – Part 2

So I have been told I blog with the frequency of a solar eclipse, and with respect to this two-part series, several interested parties via e-mal have indicated I have done the equivalent of a network TV season ending episode – “just wait the whole summer folks for the answer to these questions”. Thanks to all of you who “gently” pinged me to remind me to complete the blog.

Implementation:

So for example, take the following view one might see at the bottom level (level zero, or base level members) of an Essbase cube:

Notice the accrual for Ranzal services that is visible, and multiple transactions are available at the weekly level. A further explosion into AP would reveal the identity of the vendors, and other relevant info looking something like this: 

So as can be seen from the above example, relevant data from multiple tables is required from the drill through view. With the accruals that are made, there is relevant information in the journal descriptions; for the AP system there is vendor detail that is valid. The solution to this drill through is the creation of a view (called VendorFact in the above schematic) that is a union of the two data sources, filtering on data source. The query might look something like this:

/**Begin pseudo-code***/
CREATE VIEW ‘VendorFact’ AS

SELECT
Company, Dept, FY, Per, Acct, JournalID, JournalDesc as Desc, PostingDate as MyDate, ‘00000’ as Vendor_ID, ‘00000 as Doc_Nbr, ‘0’ Line_Nbr, PostedBaseAmt as Amt
From
GLTRANS
WHERE
Source <> ‘AP’

UNION

SELECT

Company, Dept, Year(Trans_Date) as FY, Month(Trans_Date) as Per, Acct, ‘AP’ as Source, ‘NONE’ as JournalID, LineDesc as Desc, TransDate as MyDate, Vendor_ID, Doc_Nbr, Line_Nbr, Trans_Amt
From
AP
/**End pseudo-code***/

The following view might result:

With the required view in place, a drill through query could then be created in Hyperion Web Analysis, using the relevant GL chart fields (Company, Department, Fiscal Year, Fiscal_Period, and Account) as filters in the selection query as follows:

SELECT * from VendorFact
Where Company = [CompanyToken] and Dept = [DeptToken] and Account = [AccountToken] and FY = [FYToken] and Per = [Month]

Once this drill through query had been created, a drill-link could be added as a menu item on the Summary Expense analyzer view that was directly querying the Essbase database. When the user had drilled down to the bottom of the cube, the next action would open up the new Web Analysis report, pass the relevant parameters to the query, and display a relational grid like the one above.

To give you a flavor of what this might look like, check out the example below from another type of application…..

Step 1 – Create the Summary “Essbase” View, and establish Drill Links to target detail report

• The report is setup so that all dimensions except for currency must be selected at the lowest level. This is done as a sample and to put the constraint on the report so that it returns only expected rows.
• To drill through, first select data down to level 0 for all dimensions. Next double click the actual data cell you want to drill into.
• The drill through report will be initialized with the parameters passed. If dimensions are not at lowest level, a “no data available” message will appear on the drill through.
• Drill Link Options Configuration
  This is the configuration to point the report to the Drill Through Report. It is accessed by opening the report and right clicking in a cell selecting “Drill” and “Drill Link Options…”

• The drill link options page pops up. You specify the name of the report you want to open, and what to pass as the “WHERE” clause to the next report.

Step 2 – Create the detailed Web Analysis view accessing the relational data

• The drill through report is accessed by the FinPlan report based on the dimensionally that is picked. There’s a 10,000 row limit on drill-throughs, as any set of detailed transactions that can be drilled to should never exceed even a few hundred records. If this setting was not enabled, opening the drill through report directly would fail as too many records would be loaded.
• SQL Query Configuration
  This screen is accessed by right clicking on the Drill Through Report Grid and selecting “Edit Query…”
• The JDBC-ODBC bridge driver is used to connect back to the hyperion data mart housing the drill through data. Drill through users will leverage a shared drill through connection..The row limit and fetch size are also configured here.

• Click the “Query Builder” button in the screen above and another dialog box opens. This is where the drill through mappings are configured. Click Mappings and notice that all dimensions are configured to their drill through counterparts in the vw_GL_Transactions_DT view.

• When executing the drill through, an output like this can be generated.

 

• As a final note, in constructing the view, particular care must be paid to the structure of the member names in the Essbase outline. For, example, core chart fields such as Departments and Accounts are often prefixed or suffixed to make them unique (e.g. instead of “000610” one might have “Dept_000610”). In constructing the drill through view, the member names must match those exactly as defined in Essbase, in order for the filtering aspects of the queries to execute properly.
• Other Drill Through Choices
  So one problem with Essbase is that it has multiple ways to do everything. For example, how many ways are there to load data? (Answer: For block storage cubes, flat file via rules file; sql interface with rules file; EIS data load via ODB connection; lock and send via Excel; lock and send via smartview; planning web forms; FDM adapter; DIM adapter; ODI apdater; HAL adapter; I am sure I missed a few). There are 2 command line automation interfaces for goodness sake (MaxL and Esscmd). Transaction drill through is no different. Approach wise, the one consistent thought is this: never drill back to the live transaction tables. Ok, so never is a pretty strong word, but let’s just say as a general rule of thumb, doing so is not a good idea for the following reasons: •
• Your Essbase cube is a snapshot of data from a load. Querying a live database for open periods implies the sum of your details may not equal your account balances
• Performance – transaction databases are optimized for write based operations, and highly normalized. As we have defined in the above example, creating denormalized views for specific queries will make your DBAs and end users happier.

Now, technology gets better (hardware and software), and with some of the new items coming from Oracle, out of the box, they are trying to get you to a place where EPM apps are more real time, so the rules above won’t always apply, but for now, it’s a good starting point.

In general when deciding on drill through options, you want to ask the following questions:

• What products do I need to drill through from?
       o Web Analysis
       o Interactive Reporting
       o Financial Reports o Excel Add-In
       o Smart View
       o OBIEE
• What is the type of content I want to drill through two?
       o Transactions in a relational database
       o Some other content served up via a URL (for example, very clever way to serve up document images)
• What level of the source cube do I need to drill through from?
       o Either level zero, or the top of a dimension
       o Every level of a non-ragged hierarchy
       o Custom groups and ragged alternate rollups
• What release of the software are you using (Fusion vs. 9 vs 7.x)

For example, if you want to enable drill through from every product, and need to support ragged or standard hierarchies, you are looking at an Essbase Integration Services or Essbase Studio solution. Ranzal has some creative techniques for enabling drill through via EIS on cubes not built with EIS (thanks to our handy outline extractor), which makes it useful for Planning, but once your concern over “newness” has abetted, Essbase Studio allows you to enable drill through the right way – build your cube first, then add the drill through later on. Not the other way around.

On the other hand, if you are looking at something quick and dirty, a Web Analysis or IR view in the short term can get you where you need to be.

Either way, Oracle, particularly with its continued emphasis on OBIEE/Essbase integration, is looking to provide more out of the box options to enable drill through. For example, if you haven’t seen it, check out the Ranzal webinar on Financial Data Management; the latest releases are geared to provide drill back from Planning to FDM, and then ultimately if you load from Oracle Financials, drill all the way back to the ERP.

Closing
This blog was meant to give you an idea of options and approaches for enabling drill through on your Hyperion application. While its great to have options, remember the golden rule – when you make your choice, know WHY you chose that path. Design is basically the optimization of an approach against one set of requirements over another.

Until next time, good luck.

Authored by:
Mike Killeen – Ranzal and Associates
mkilleen@ranzal.com

For more than eleven years, Mike Killeen has scoped, designed, and implemented Planning & Essbase applications for Ranzal & Associates, an award winning, preferred consulting partner of Oracle Hyperion. Currently serving as practice director, Mike provides guidance to Hyperion product management, Ranzal customers, and internal consulting resources alike on best practices related to the implementation of Hyperion System 9. Mike is a certified Hyperion Professional, with certifications in Essbase, Planning, and HFM. He graduated cum laude from Cornell University with a degree in engineering, and received his MBA from the University of Connecticut.

Business Intelligence Technology Environment – Welcome to the Buffet

Business Intelligence Technology Environment or BITE is my own little tag line and acronym (maybe I should copyright it) to express the host of solutions available in the Business Intelligence application world today. (It could also be used as a verb to describe the plethora of poorly designed solutions… ahh but that is another story.)

My current blog series will be Oracle EPM/BI+ solution centric while remaining Oracle EPM/BI+ application agnostic (now dictionary.com is paying off). I hope that you will enjoy this real life approach to the process of decision making on software solutions interspersed with some genuine tips and tricks of the trade — some that you have seen before and some you have never imagined.

In other words, I hope that you will not find this blog to be represented by my newly coined acronym — BITE.

Rules of conduct while at the Buffet

First we need a definition. Yes a definition! Don’t be afraid, definitions are a good thing, they keep us grounded, they set limits and finally they determine if we are true to our mission. I define BITE as processes, software and goals needed to precisely solution the business data critical to the legal, accounting and business decision needs of a specific entity.

Inventive techno junkies, single tool consultants and one track sales people – CLOSE YOUR EYES / SHEILD YOUR COMPUTERS for this next statement else you might go blind. “Precisely Solution” in the definition of BITE includes the moral imperative of not misusing software for intent other than its design and picking software that fits the current business life cycle of a company. (Those of you with Software Misuse problems, I will be posting a number you can call to get help. Remember the first step is admitting you have a problem.)

The application stack for EPM / BI+; HFM, Essbase (with all its add-on modules), Smart View, OBIE, OBAW, FDM, DRM, ODI and a few products you might not have heard about or you’ve heard about but never assessed for your purposes. NO, NO, No, no folks this is not a software sales blog, it’s a solutions blog and in our solutions toolbox we need to do more than use a single hammer creatively to remain competitive from an efficiency and business life cycle standpoint.

The Personalities in the Buffet Line

Now that we have some parameters (and I know it was painful for you left brainers) by which we can solution, we need some realistic company situations to solution. Let’s start with four companies each different in their business life cycle, staff sizes and demands for a BITE at success. You can email me if you will absolutely die without a very specific company example however, I cannot boil the ocean here in this blog (small ponds are all that will be possible).

Our four companies need to be different to see solutions in the work. Let’s pick a manufacturer, a technology company, a retailer and a commodity group. In my next addition we will outline the companies, their mission, their needs and their resources.

Creating an OBIEE Repository for Relational Data Source

OBIEE (Oracle Business Intelligence Enterprise Edition)

In this part of my OBIEE blog, I’ll guide you through basic steps to create an Oracle server repository and use it to bring over a relational data source for use in OBI Answers. As of OBIEE version 10.1.3.3.2, Essbase is supported as an OBI data source allowing the user to integrate Essbase data with OBI Answers, OBI Interactive Dashboards, and OBI Publisher. The latest version of OBIEE is 10.1.3.4x. Refer to my part 2 blog (OBIEE and Essbase – Defining OLAP Integration) for importing Essbase content into OBIEE.

For the below steps, I will be using SQL Server 2005 relational database as my source but you can use Oracle 10g or older versions of either tool.

To create an Oracle repository, open the Oracle BI Administration Tool and select File | New and name your new repository.

Set security by selecting Manage | Security. Assuming you are the admin, select Users | Administrator. Right click Administrator, select Properties to enter an admin password and confirm the password. Close out Security Manager.

To import a relational data source, select File | Import | from Database.

Select a connection type.

Select the relational data source, enter login credentials and click OK.

Enter the relational table to import. Deselect all but Tables, Keys, and Foreign Keys and click Import. If you are using Views instead of Tables, change accordingly.

The relational table will import into the Physical layer of the Administration Tool.

Test the import by right clicking a column (Branch_Name is selected in this example) and select View Data. Values for the selected column should populate in a view data table.

Drag the imported relational table folder from the Physical layer to the Business Model and Mapping (BMM) layer. In the BMM layer, here you can create logical tables and joins to develop the type of model needed for presentation.

Next, drag the relational table from the BMM layer to the Presentation layer to finalize its presentation for the user. Manipulation by presentation can be performed in this layer for Subject Area use in OBI Answers.

For your reference and as a recap from my part 2, here is the significance of each layer:

1. Physical layer – imported tables and views come from the relational data source; physical joins can be performed here

2. BMM layer – this layer organizes imports from the physical layer into logical categories

3. Presentation layer – BMM entities are organized for user presentation

Once your Presentation layer is complete, it can be made available for OBI Answers to create dashboard content bringing both relational and multidimensional data sources into one view. A sample of an Answers view is displayed below combining both relational and multidimensional data sources into a combo box allowing for choice among regions. Any selection of region updates both relational and multidimensional tables for view.

This is just one simple example of the product’s capabilities. OBIEE is redefining how we approach BI with the evolution of this product improving on how we develop it. There is a great deal of flexibility within OBIEE for relational and multidimensional reporting and those who understand how to leverage this tool will see its impact upon their organization for the better.

Structuring Flexibility in Your EPM Project: A Guide for Maximizing Project Value

The goal of Enterprise Performance Management (“EPM”) software is to drive profitable growth by delivering predictable results, improving transparency and compliance, and increasing business alignment. However, the competitive environment is hardly predictable and business objectives change based on environmental feedback. As projects are typically linked to business objectives, functional requirements and needs may change even during the project implementation cycle. If business alignment is a primary objective, then the software must be adaptive enough to accommodate the changes in order to maximize value.

Based on the results of a recent survey of IT Software Project Failures, the second highest ranked reason given for project cancellations was too many requirements and scope changes. Project management is often seen as the solution for achieving project success. The traditional approach is predominantly taught and utilized in most organizations. However, this approach has its limitations. The traditional project approach is best used when

· The solution and requirements are clearly defined

· You do not expect too many scope change requests

· Prior EPM knowledge is available in-house

· You can utilize existing templates.

Given the unpredictability within the competitive environment, and the dynamic discovery and delivery processes inherent in an EPM project, a more flexible project approach that allows for changes in scope is required. This flexible approach works best when

· The solution and requirements are only partially known

· There may be functionality that is not yet identified

· There may be a number of scope changes from the customer

· The project is oriented to new product development and/or process improvement

· The development schedule is tight and you can’t afford rework or re-planning.

Although scope changes are necessary evils within an EPM project, too many scope changes without a surrounding process can lead a project to failure. From the view of a business stakeholder, implementing an EPM project is partly getting what you want and partly discovering what you really need. The more transparency obtained, the more likely business stakeholders will attempt to enable discoveries via new or modified requirements. Not having the appropriate boundaries or structure in place can easily lead to exceeded budgets, delayed timelines, and ultimately a solidly implemented solution with not enough business value.

The key components required are adequate levels of flexibility and structure (otherwise known as structured flexibility).

As the diagram represents, structured flexibility provides project stakeholders with a wide range of flexibility to aid the discovery and delivery processes. However, a boundary exists that allows the project to remain structured and meet the project time, budget, scope, and quality objectives. The points where structure meets flexibility should be determined jointly by the project stakeholders. Effective methods should be used to ensure adequate communication within and about the structure. The following seven (7) steps, when used appropriately, can serve as a guide for achieving the structured flexibility that can maximize project value:

1. Develop the initial ground rules for maintaining structure at the very start of the project;
2. Obtain buy-in for the ground rules from all project stakeholders and modify if necessary to create a common language;
3. Ensure all project members are aware that a structure exists and what the protocol for operating within that structure will be;
4. Allow project members to be flexible in their thinking and approach;
5. Document and prioritize changes and new ideas;
6. Focus on the highest value items first  (needs not wants); and
7. Enforce ground rules where and when flexibility meets structure.

Although these steps may appear simple, high levels of project management and leadership skills are required to implement them. Having an objective project management partner helps.

Smart View – Integration with Microsoft Office.

How many people take the time to read a product manual cover-to-cover?  For many, it feels like punishment, but for consultants it is a required duty.

Recently, I read about some of the latest features in the Oracle / Hyperion “Smart View” for Microsoft Office Add-In.  As I read the manual, I could not help being impressed by the all new features. 

“Smart View” is not a new product.  It was first provided with the release of Hyperion Financial Management (HFM) 4.0.x.  However, the pace of the development and enhancements has been incredible over the past four to five years, adding a laundry-list of new functions.

Soon after reading the documentation a client asked me to assist with planning a simple upgrade from HFM 3.5.1.  Their initial thought was to simply take a free upgrade to version 4.x in order to have access to the latest platform.

Like most companies, their users are most comfortable accessing data through Microsoft (MS) Excel. We reviewed the list of enhancements that are found only in the latest version of “Smart View”.  We touched on the availability of Data Forms, Import and Refresh of Workspace reports, Drag and Drop, and dynamic support of data within MS Word and MS PowerPoint. 

Their reaction made it clear that only the most current version would suffice.  I wanted to expand on other enhancements found in HFM such as the latest Calculation Editor, Minority Interest Module, Intercompany Transactions Module and Metadata Management, but they were almost sold on the Smart View enhancements alone.  A good salesman knows when to clam up.

Reflecting on the discussion, I discovered that what is really happening is the software functionality has matured to the point that it truly meets the users’ needs and then some. 

Not too long ago, a big part of a consultant’s time was spent managing a “work-around” to meet a client’s requirements. We don’t hear the phrase “work-around” too much anymore because the functionality is real. Today, a great deal of time is spent expanding upon the requirements with more uses of the inherent functionality and building integrations with other systems.

The embedded functionality is very user friendly in products such as “Smart View”.  One of my client’s reporting requirements was to incorporate their financial data with supporting commentary in MS Word and MS Power Point.  Rather than leading a demo myself, I passed my laptop across the desk to allow them to experience the ease-of-use first hand.

For example, to link financial system data into a Microsoft document or presentation with “Smart View” user would follow some basic steps:

1. Create an Ad-Hoc Analysis Grid in Smart View Excel.  Place the items you wish to display on the rows and/or columns.  The items that may need to change over time, such as the Month, Year or Scenario can remain as part of the point-of-view.
   

 

2. Format the Data. As data is moved between MS Excel, MS Word or MS PowerPoint, the data will retain its formatting.  Therefore, you can edit the formatting of the data.

 

3. Select the Area to Display.  The linked data can be displayed as only the amount field or can incorporate the row/column member labels by simply highlighting those cells on the worksheet.

 

4. Copy Data Points.  The Hyperion menu enables the data to be dynamically linked into other MS products by selecting Copy Data Points.
   

 

5. Open a MS Office Application.  Select the area in a document or presentation that requires the linked data.  Using the Hyperion menu choose, Paste Data Points.  For example, MS PowerPoint.

 

6. Refresh the Document. By choosing Refresh from the “Smart View” menu, the most current data will always be displayed as it is retrieved directly from an application such as HFM.

 

7. Account for Changes.  Depending on the design, the information can be updated for a change in the Month, Year and Period, Product or any dimension by simply changing the point-of-view setting in the “Smart View” menu item, POV Manager.  Simply change a parameter such as the current month and Refresh the document.

The results in the example above are a great indication on how easy it is to now incorporate financial system data into external applications.  Once applied, the data is able to be refreshed in order to display the most current data or alternate views.

Then enhancements made by Oracle / Hyperion to the entire Enterprise Performance Management suite of applications truly address the user’s need to collect and analyze data.   They also address the many issues surrounding the routine tasks when developing and maintaining financial documents.

Users new to Oracle / Hyperion, or those upgrading from earlier versions, will find the latest products really do live up to their expectations.  They will finally benefit from more flexible access to data and spend less time collecting and maintaining it.

 

Authored by:
Joseph Chimbolo
Ranzal Consulting
Sr. Consultant
Hyperion Enterprise Certified

Adding Drill Through to Your Hyperion Implementation

This is part one of a two part blog where I will discuss a general overview of how within the framework of a Hyperion Planning or Hyperion Essbase implementation, organizations may configure Hyperion to provide drill through to transaction details. In this first blog, I will discuss implementation background, and part two will provide information related to implementation approaches.

The final output of most Hyperion Planning implementations is the generation of a Financial Plan.  While various “sub-ledger” plan types may exist to support the generation of this plan (Revenues by Customer and Product; Salary Expense By Employee; Capital Expenditures by Asset Class), the fundamental level of granularity is usually equivalent to the various chart fields in the organization’s general ledger, summarized on a MTD basis.  For certain ERPs, this corresponds to the GL Account Balances table, or an aggregate of the transaction details. Depending on your ERP package, this can be one of the following:

• Lawson – gl_trans
• Oracle E-Business – gl_je_lines
• Peoplesoft – PS_Ledger
• JD Edwards – F0902
• SAP R/3 –
  o Profit Center Accounting – GLPCT
  o Cost Center Accounting – COSP
• Microsoft Great Plains – GL11110

For financial implementations, you are usually looking at the following standard chart fields:

• Account
• Fiscal Period
• Fiscal Year
• Currency
• Legal Entity or Company
• Management Chart Fields
  o Department or Cost Center
  o Product or Profit Center
  o Geography or Location

Inherent within the Hyperion environment is an ability to drill to a lower level of detail, usually to answer a question.  This type of functionality manifests itself in several forms, and the following terminology is used:

Drill Down:  Drilling from one level to another of more detail in one dimension of a cube (for example, expanding quarters into months)
Drill Up: Drill from one level to another of less detail in one dimension of a cube (for example, collapsing quarters into year)
Drill Thru: Drilling out of an Essbase cube into a RDBMS source system (for example, expanding months into days)
Drill Across: Drilling from one Essbase cube into another, normally to explode dimensionality that exists there (for example, on a MTD basis, while looking at Revenue in the Financial Cube, drilling across to expose Customer Detail in a Customer Cube)

The actual drill process from a user interface could be as simple as expanding the rows on the user’s grid (as in a drill down), to launching a new grid which creates a new point of view in a drill-thru and drill-across operation.

Much like the relationship between Planning sub-types and the primary financial cube, there is a relationship between the General ledger, and various sub-ledgers that feed it.  Primarily, detailed information is summarized prior to being posted. For example, individual employee payroll data may get aggregated by department and posted as one line into the ledger. Or Ship-To Customer and individual product SKUs may get aggregated into Channels and Profit Centers prior to be posted. In any event, when talking about exposing additional granularity in Financial cubes, it is critical to define what types of details the user wants to see, as there may be multiple steps in that process.  Because of this, it is very rare that a simple drill through into a general ledger will yield all of the results a user wants to see, since many of the results, while at least expanded from a monthly to a daily basis, will still be summarized across the other dimensions a user may wish to see (such as Vendor). This leads to the design of two new components:

1. Delivery of additional operational cubes, that expose details (such as Employee, Customer, and Vendor) for Drill-Across operations
2. Development of custom-data marts that create hybrid views integrating different levels of granularity of multiple data sources.

The overall schematic might look something like the workflow below:

 

 

In the example above, a new vendor “view” or table has been created to support the drill through view requested by the user, in a top down fashion.  Notice that the table actually pulls from two sources:

1. GL Trans – the general ledger transaction table where individual journals are posted
2. The Accounts payable table, where individual transactions exist

The need for both tables occurs because accruals may be made to the accounts in question, and those entries are generally made directly in the GL Transaction table.  So for the detailed drill through table to tie to the financials, it must contain both elements. However, since the AP element exists in both (detailed in AP, summarized in GL), special care must be made to avoid double-counting the entries that come back.  Since many GLs contain a field that identifies the source system (AP, AR, etc), or has a journal mask to accomplish the same, this is usually readily available.

In my next blog (part 2), I will discuss practical techniques for implementing the above.

Mike Killeen – Ranzal and Associates
mkilleen@ranzal.com

For more than eleven years, Mike Killeen has scoped, designed, and implemented Planning & Essbase applications for Ranzal & Associates, an award winning, preferred consulting partner of Oracle Hyperion. Currently serving as practice director, Mike provides guidance to Hyperion product management, Ranzal customers, and internal consulting resources alike on best practices related to the implementation of Hyperion System 9. Mike is a certified Hyperion Professional, with certifications in Essbase, Planning, and HFM. He graduated cum laude from Cornell University with a degree in engineering, and received his MBA from the University of Connecticut.

OBIEE and Essbase – Defining OLAP Integration

In this second part of our OBIEE series, the integration between OBIEE and Essbase is a seamless transition from our OLAP cube to the OBIEE suite managed by using OBIEE’s Administration Tool.

OBIEE Administration Tool view

This Administration tool has been designed with wizards, utilities, and interface design elements to help administrators work more efficiently.

Essbase test outline

Using an existing Essbase outline called ‘test’, this outline can be used to import an OLAP connection to OBIEE.

From the Administration Tool, select

File | Import | from Multi-dimensional

 
Enter the provider type, Essbase Server name, and its login credentials. The physical layer table, connection pooling, etc. will be automated and established once the import completes. You can also manually set each individual component in the physical layer if you want this level of control.

 

When the Physical layer has been established, simply drag and drop the folder of your Essbase outline from the Physical layer to the Business Model and Mapping layer to define a mapping between the business model and the physical layer schemas.

Physical Layer in Administration Tool

 

Once the business model mapping has been established, move the business model to the Presentation layer to make it available for user views.

Business Model & Mapping Layer in Administration Tool

 

This Presentation layer allows the Administration tool to present customized views of the business model to users. The business models can be managed in this presentation layer by removing unwanted or unneeded columns, restrict certain columns from view, or maybe rename a column to a more user-friendly name.

Presentation Layer in Administration Tool

 

Once adjustments to column views have been completed and ready in the presentation layer, it can be made available in the Subject Areas for users to develop reports using the Answers component of OBIEE.

OBIEE Subject Area in the Answers component of OBIEE

 

So the three layers within the OBIEE Administration tool are defined as follows:

• Physical layer – Represents the physical structure of the data sources to which the Oracle BI Server submits queries. This layer is displayed in the right pane of the Administration Tool.
• Business Model and Mapping layer - Represents the logical structure of the information in the repository. The business models contain logical columns arranged in logical tables, logical joins, and dimensional hierarchy definitions. This layer also contains the mappings from the logical columns to the source data in the Physical layer. It is displayed in the middle pane of the Administration Tool.
• Presentation layer - Represents the presentation structure of the repository. This layer allows you to present a view different from the Business Model and Mapping layer to users. It is displayed in the left pane of the Administration Tool.

 

Some of the features of the Administration tool make management of metadata and data much less complicated. The change management feature makes it easy to change multiple object names, text, case, and adding prefixes and suffixes. This allows for drag and drop capabilities from the physical to the business model layer.

Organization of metadata is straightforward using a feature called metadata administration. This feature grants users the ability to create folders to manage dimension tables and hierarchies.

The multi-user collaboration feature regulates the off-line/on-line modes for read only or to take effect immediately. This enables metadata repositories to be checked out or checked in and authorizes multiple administrators to work on a repository concurrently.

The Export/Import feature supports the export and import of metadata to move systems from staging to production and provide documentation.

Defining how OLAP is presented to OBIEE has been explained in basic format within this blog article but readers should know that this Administration Tool is much more powerful and can allow for more focused control within each of its layer process managing metadata and data. It is integrated and is flexible and its goal is to help move disparate source data to the OBIEE suite.

The end result can be a visual dashboard that makes sense of data utilizing charts, graphs, stop lighting, embedded images, tickers, etc. to organize and present data in a manner your audience will embrace and use.

Dashboard created with Answers from Essbase test outline

 

This concludes part 2 of the OBIEE & Essbase integration. Keep an eye out for my next article where I’ll review RDBMS integrated with OBIEE and how it can be used in conjunction with Essbase in Answers reporting.

Oh, The Good Old Days…

Who among us has not heard about the “good old” days?  My grandmother regularly peppered my Sunday dinner with stories, sometimes lectures, on how life was a little simpler way back when. However, if you apply some logic, it may be apparent that the premise might not hold water. 

Technology is our revolution which has freed us from monotonous tasks, as well as provided new opportunities for insight and growth. Surprisingly, we need to learn how to free ourselves from our old ways.

So do you still have this on top of your television?

Take the “Betamax” player.  Aside from taking the space of a small loveseat, it was pretty simple to use.  Press the “on” button, insert the tape and press play. Soon consumers demanded a few more features and we were all graced with the latest and greatest invention of all time, the programmable VCR.

What more could I want in life?  I now had the opportunity to record the debut of the “Thriller” music video while in detention room 101.  However, we all know life is not that simple.  I had to first learn to program the clock, channel and record time.  Those benefits came with a small price to pay.

As a veteran Oracle / Hyperion Instructor, I could train our Oracle / Hyperion Enterprise clients how to press the “on” button, insert the tape and press play in about a week. Following the incredible success of Oracle / Hyperion Enterprise, Pillar and Essbase, clients wanted more features and functionality. 

Oracle / Hyperion Solution’s met the challenges presented by their customers.  With the acquisition of Hyperion by Oracle, the Oracle / Hyperion suite of Enterprise Performance Management (EPM) products merges a host of financial, reporting and analysis, and data integrations tools.  These tools have refined how people work and interact with business information.  It has also changed how we must provide training in order to prepare project teams, administrators and end users.

The System 9 and Fusion generation of products touch a much more diverse population of users.  The products range from Executive Dashboards, to administrative budget collection forms and into the Information Technology (IT) back-office environment. 

A one-size fits all training solution is no-longer as effective as it once was, like in the “old days” of desktop reporting.  Now, we need to think about tailored training to meet the needs of each group of users and instruct them on how to most effectively incorporate the technology into their user-specific work day tasks. 

The stepchild of training is managing change. Everyone is “fired-up” during the implementation phase.  Each person striving to learn and understand all there is to know about the new system.  But what happens when some people move on and others move in?   Again, the scope of the latest products demands tailored training to meet the needs of the users, but also a plan to cover the entire cycle of ownership.

The challenge of providing training to an incredibly diverse user base, preparing users for multiple phases of projects, and how to live with and maximize their investment in technology has been exciting.  Training solutions now weave together, printed materials, customized courses; web-based training seminars and re-usable recorded instruction.  Training has become a separate and distinct project unto itself.

The products are not difficult to use, the challenge is ensuring people know how to thoroughly utilize all of the features and functions. Second, to make sure they understand how the technology fits into their daily tasks.

An Oracle / Hyperion competitor used to boast that one of their products was more user-friendly than HFM, and therefore required little training.  That should throw a warning flag to the consumer.  As the Oracle / Hyperion suite is an EPM set of applications, there must be an “enterprise” plan how to manage the needs of the users that the system will touch throughout the cycle of ownership. 

A well-defined training plan must address educational needs across all phases of an implementation.  It cannot be overemphasized that effective preparation can truly play a key role in keeping a project on schedule and budget.  The results are that project leaders can more effectively communicate and understand design decisions.  The members of the project team are able to test, validate and troubleshoot tasks more efficiently.  Lastly, users understand the purpose of the project and how it fits into their daily tasks.

You will find that having a comprehensive training plan will be invaluable when you need to prepare new employees, manage employee movement, and preparing everyone for software upgrades and enhancements.