Monthly Archives: May 2012

Oracle Hyperion DRM Basics | Exports (1 of 2)

In our last technical post we saw how to create a query. We are now going to look at creating exports so that you can extract masterdat, which is a large topic that will require a couple of posts. Technically, exports are the tool you must use to send the masterdata out to the other systems. Oracle Hyperion DRM (Data Relationship Management) exports can only write to database tables or text files, so you should consider this when designing your solution.

Let’s start by opening Oracle Hyperion DRM Data Relationship Management (DRM) and navigating to the “Exports” section of the home tab. You will see some export options and a list of saved exports. As there were with queries, exports are grouped by access level (user, standard and system). In the following screenshot, there are no exports yet.

So we can create an export by clicking on “New export”.  Oracle Hyperion DRM will immediately start by giving you the choice between different export types.

 

 

 

 

 

 

 

 

 

 

 

The most useful and the one we are going to look at in more detail is the Hierarchy export. This feature allows you to export nodes and property values in a table format according to a given query. Selecting the Hierarchy Export option and Oracle Hyperion DRM opens a new tab. As for queries, you will notice the “save”, “save as” and “run” buttons on the top and some configuration tabs below.

The first configuration tab is the source. In this tab, you must select the version that will be the source of the masterdata, then the hierarchies and top node. You can select as many hierarchies as you need. Remember that the export will only return masterdata from the selected hierarchies.

The second configuration tab is the style. In this tab you can tweak some of the export options like only consider leaf or limb nodes. Leave these options as they are by default. The next tab is the filter tab.

The first filter you can set is a validation. This is a feature that justifies a blog of its own and we will do this this shortly. The second filter is a property query. You can select a query you have saved or create a new query. Have a look at our post on queries if you haven’t seen it yet. If you do not include a query, the export will return all the nodes of the hierarchy. If you include a query, the export will only include the nodes that respect the query criteria. Finally, if necessary you can also use a text file to include or exclude nodes.

We’ll build on this introduction to Exports from Oracle Hyperion DRM in the next blog post. In the meantime you know where we are if we can help.

 

Tagged , , , ,

Preserving the Audit Trail in Oracle Hyperion FDM

Given our focus on masterdata and integration we get to understand how a wide range of clients solve the problem of transforming data between their general ledger, consolidation, reporting and forecasting systems. These domains have very different business requirements which are often reflected in different structures and levels of detail. Inevitably some form of mapping process is required. So far so good; there are many solutions to govern the mapping between financial applications.  If you use the Oracle Hyperion product for your EPM (Enterprise Performance Management) layer, there is a high chance you will be using Oracle Hyperion Financial Data Quality Management (FDM) for an element of this mapping.

FDM is a great tool when used correctly. It acts as a gate keeper to other Hyperion applications ensuring that all data is mapped and validated according to pre-defined business rules or “validations”.  This audit trail is invaluable and needs to be retained at all costs.

There are, however, two areas of FDM functionality where this audit trail can be jeopardised.  Firstly, FDM contains the ability to run “import” scripts.  These scripts can modify the content and structure of the initial import files.  If they are not used correctly they can create a “disconnect” between the source application and FDM.  Changes of this nature can become very difficult to trace and thereby undermine the comprehensive audit trail provided by FDM. Secondly, FDM also provides the flexibility to create new financial totals based on rules contained in the application.  These rules, or “Logic Groups”, can be difficult to understand and are not traced in the audit trail.  Whilst powerful, they should be used with caution and not without a full understanding of their limitations.

There is one final area of FDM that needs careful consideration.  It is imperative that you perform regular housekeeping on your mapping tables.  A key advantage of FDM is the flexibility offered by the mapping tables.  Your approach to mapping will change over time and it is very important that you delete mappings that are no longer used. If you do not, your mapping approach will become increasingly difficult to understand over time.

A final word: when implementing any form of ETL (Extract Transfer Load) process it is imperative that your implementation partner demonstrates that the audit trail is complete and easy to use.  We suggest that your test strategy always includes tests that trace values from target application to the original source.  Until next time….

Tagged , ,