DRM

Oracle Hyperion DRM Tips & Tricks | Save Your Work

Oracle Hyperion Data Relationship Manager (DRM) has a somewhat unorthodox interface, which can lead the unwary into losing their work. Grizzled Oracle Hyperion DRM veterans will have discovered these traps the hard way, but if you are relatively new to the product this blog post might spare you some pain, we hope.

Items Displayed in Tabs

Oracle Hyperion DRM uses tabs to display the details of queries, compares, imports, blends, exports and all the objects managed by a system administrator. When you have one of these open, as the image below shows the only indication that you have unsaved changes is an asterisk next to the item name (and even this cannot always be relied on).

130425_DRM Tips and Tricks_Save your work

 

If you close an item after making changes, you don’t see the Save / Don’t Save / Cancel dialog box that most programs would display – Oracle Hyperion DRM simply closes the item and discards any unsaved work. It is thus important to get into the habit of being conscious of whether you need to click the Save icon towards the top left before closing a Oracle Hyperion DRM tab.

Versions

When an Oracle Hyperion DRM version is created it starts in an unsaved state. Unsaved versions are deleted whenever the Oracle Hyperion DRM service is restarted (which happens every night at some sites). New versions are often used for importing data to blend into other versions, so are legitimately temporary. However, if you have created a version you want to keep, it does not matter how often you clicked Save after adding or moving nodes or updating properties. If the Oracle Hyperion DRM service is restarted you will lose everything.

You should save a version you want to keep as soon as you have created it, by right-clicking on its name and selecting Save. 

130425_DRM Tips and Tricks_Save your work_2

 

Once a version has been saved, all confirmed node changes and property updates are preserved without you having to save the version again.

Hopefully that should save you some time and stress!

Tagged , , ,

Oracle Hyperion DRM Tips & Tricks | Query Limitations

This is the first item in an on-going series of blog posts designed to help our readers get the most out of Oracle Hyperion DRM (Database Relationship Manager).

This post addresses a limitation in the way Oracle Hyperion DRM allows users to define queries. Specifically, Oracle Hyperion DRM allows you to structure queries using parentheses but does not allow you to put a NOT in front of criteria grouped in this way.

What if you were making a complex query and wanted to exclude nodes that meet two conditions? For instance you want to select all nodes that are below the top node, except leaf nodes if they are also linked in from another hierarchy. In Oracle Hyperion DRM terms what you are trying to achieve is:

  • Level Greater Than 1 And Not (Leaf Equal True And Linked Equal True)

You cannot code this as it stands in an Oracle Hyperion DRM query. However, the following rule of logic can help:

  • not-(A and B)     is logically equivalent to     (not-A or not-B)

Our example now becomes:

  • Level Greater Than 1 And (Leaf Equal False Or Linked Equal False)

Which as the screenshot below shows can be implemented in Oracle Hyperion DRM in the following way:

130417_Seismi_DRM Tips & TricksIf you have anything you want to add please do post a comment. Until next time….

 

Tagged , , ,

Issue with remove level validations in Oracle Hyperion DRM

We recently encountered a small problem with the “remove validations” functionality in Oracle Hyperion DRM (Data Relationship Manager). As the screenshot below shows, we had set up a validation to prevent the deletion of certain nodes.

This is an important issue as most finance applications need to be assured that no nodes can be deleted to ensure no historical data is deleted. Disappointingly, when we assigned this validation to a hierarchy, it was ignored.

This problem affects release 11.1.2.1 of Oracle Hyperion DRM and is fixed in the latest release (11.1.2.2.300). Fortunately, for clients still on the earlier release, Oracle has provided a workaround. As the screenshot below shows this is simply to define the validation as both real time and batch:

Once assigned to a hierarchy as both a real time and batch validation, it successfully prevented nodes from being deleted.   This is only a small bug, but it could have had a wide impact.  We hope you have found this useful and we’ll be back next week!

 

Tagged , , ,

Financial Intelligence | think before you jump…...

What is financial intelligence, I hear you say? Well it goes by many names and comes in many shapes…

Example 1: You have a single intercompany account in your ledger, but you need to present this in your consolidation and/or reporting solution as either an asset or a liability, depending on whether the balance this month is a debit or credit.

Example 2: You have 20 sales tax (VAT) accounts in your ledger. You need to evaluate the sum of all the accounts and present the entire amount as either an asset or liability in your consolidation and/or reporting solution, depending on whether the cumulative balance is a debit or a credit.

In my experience, there are the following three approaches to solving this challenge:

  1. use the ledger to present the information in the required format. This can be done via an automated or manual month-end journal;
  2. use the ETL (Extract Transfer Load) process via a rule based mapping to transform the data; and
  3. load the data into the consolidation and reporting tools in the format of the ledger, and use scripts within these tools to copy this data into presentation accounts.

Which of these three options are right for you, depends on your business process. I thought it would be useful to share the following considerations when you are deciding which of the three options to use:

  • In my experience clients are often cautious about putting presentation journals in their ledger, because of the concern that these will not be visible or auditable in the consolidation and reporting solutions. There are effective solutions to this requirement via the ledger setup;
  • Rule based mapping solutions should be evaluated to confirm that they a) do not jeapodise the audit trail and b) will support solutions that allow you to drill from a consolidation or reporting tool back to your ledger. For example, logic groups in Oracle Financial Data Manager (FDM) can affect the audit trail and the ability to drill through;
  • If the mapping approach is selected, the mapping must be available to all the consolidation and reporting tools: say HFM (Oracle Hyperion Financial Management), Oracle Essbase and OBIEE (Oracle Business Intelligence Suite Enterprise Edition); and
  • The third option, using scripts to create the presentation data in the consolidation and reporting tool, has the obvious risk that if these multiple scripts fall out-of-alignment, the tools will not reconcile.

As a final comment, in my experience, regardless of which of the three approaches you decide to use, incorporating a masterdata governance tool can provide a robust as well as a flexible long–term solution…

Tagged , , , , ,

UK's Favourite Retailer selects Seismi and Oracle DRM!

Some good news to share! We have started a comprehensive BI (Business Intelligence) Finance initiative for the UK’s favourite retailer. We have been asked to design a solution to use Oracle Hyperion DRM  (Data Relationship Manager) as the single repository of all the retailer’s financial masterdata.  Oracle Hyperion DRM will provide them with a comprehensive governance solution enabling efficient maintenance of all their core financial masterdata.

Oracle Hyperion DRM’s scope will encompass Oracle EBS, ERPi (Enterprise Resource Planning Integrator), FDM (Financial Data Quality Management), HFM, Essbase and OBIEE (Oracle Business Intelligence Suite Enterprise Edition) applications and tools.

This represents another great opportunity to show how masterdata management (MDM)  should be a primary consideration at the start of any EPM (Enterprise Performance Management) initiative, not, an afterthought.

We look forward to sharing more over the course of the project. Off to celebrate!

Tagged , , , , , , , ,

Metadata vs masterdata | Are they the same thing?

We were recently asked by a client what the difference was between metadata and Masterdata. This got us thinking that it would be worthwhile digging into this a bit more. The term ‘metadata’ has two broad meanings. Though the word literally means ‘data about data’, it is often used to refer to data about the organisation of data, such as the columns and tables in a database and the relationships between them. The term is also used more strictly to refer to information about the content of data (also known as metacontent). Examples of this kind of metadata include summaries of contents, keywords for searching, and information on the source and owner of the data.

‘Masterdata’ refers to the non-transactional data that describes a business or other organisation. Typically this data covers:

  • Internal entities such as departments, employees and products;
  • External entities such as customers and suppliers; and
  • Organisational information such as reporting hierarchies and the chart of accounts.

Masterdata is required to support transaction processing, and to organise reporting and analysis.

A common problem with masterdata is that it is spread over the reference data contained in multiple, possibly inconsistent systems (particularly if a company has grown through mergers and acquisitions). Masterdata management (MDM) is the process of consolidating some domain of this information – customer information or account details, say – into a single authoritative source of data. Seismi focus on using MDM to drive business process change and create truly integrated financial processes. Seismi’s chosen tool for MDM is principally by deploying Oracle Hyperion DRM (Data Relationship Management).

We hope this has clarified the differences between metadata and masterdata. If not then please do get in touch and we can dicsuss it in more detail. At least we will be better prepared for when we are asked again!

Tagged , ,

Oracle Hyperion DRM Basics | Scripts

In this blog, we will have a look at Scripts which were called automators in some earlier versions. Scripts in Oracle Hyperion DRM (Data Relationship Manager) are a simple tool that execute sets of simple instructions in one bulk load. For example, if you need to change the value of one property against hundreds of nodes, the simplest way to do this is to create a Script. An effective way to increase productivity through the use of automation.

The basic rule in a script is that each line is a specific action. Each line also needs to be divided into columns by a delimiter. The first column should contain the action code. Oracle Hyerion DRM supports an important list of action codes that allow you to carry out a lot of different actions such as change property (“ChangeProp”), add a node (“Add”), insert a node (“Insert”), remove a node (“Remove”) and so on. The full list of actions available is described in the Oracle Hyperion DRM user guide. The following columns will contain the parameters for the action.

As an example in this blog, I am going to add a node into a hierarchy then change its description. This will require two actions and my Script will need two lines:

  1. First add the node using the “Add” action code. This code takes 5 parameters:
    1. Version – This is the name of the version in which the node will be added.
    2. Hierarchy – Name of the hierarchy in which the node will be added.
    3. Node Name – Name of the node to be added.
    4. Parent name – Name of the parent of the node.
    5. Leaf – Flag indicating if the node is a limb or a leaf.
    6. In the second line we use the action code “ChangeProp” to modify the description. This action also takes 5 parameters:
      1. Version
      2. Hierarchy
      3. Node Name
      4. Property – Name of the property to be modified.
      5. Value – New property value.

So the file looks like this:

You can build this file using a simple text editor or Excel. In Excel, just save the script as a .csv file.

To execute the Script, navigate in Oracle Hyperion DRM to the Script section.

Specify the file characteristics like the column order, the column delimiter or the encoding in the “Source” section. Then browse to your file and press “Load”. Once the file is loaded, you will see the list of actions Oracle Hyperion DRM has recognized in the bottom section. Any action code that was not recognized will be ignored.

In the menu called “Script” there are some additional options. For example, you can substitute the versions in the Script for a different version present in Oracle Hyperion DRM. You can also select only a subset of lines you which to execute. Once you are ready, press the play button. This will execute all the selected lines.

Once the Script has been executed, you can see the result in the “Status” and “Return Value” columns.

“Status” will flag any error and “Return Value” will return the error message if there was an error or any other return value depending on the action code. These results can be saved by navigating into the Script menu then selecting download then the format.

While this was a simple example we hope that it was clear and useful. If you have any questions you know where we are and we would be delighted to help.

 

Tagged , , , ,

Oracle Hyperion DRM Basics | Imports (2 of 2)

In last week’s first post on importing into Oracle Hyperion DRM (Data Relationship Management) we looked at how to build a file to import master data into Oracle Hyperion DRM. Now we will create the import in DRM. Browse to Oracle Hyperion DRM, then go to imports and click on “New Import”.

The first step when users configure Oracle Hyperion DRM to import requires selecting the file to be imported, specifying the character encoding, the field delimiter and the sections present in the file. You can also customize the headers for each section.

 

The second step when customising Oracle Hyperion DRM for imports is deciding what style to use for the import.

 

In this step you can configure the import so that it populates sort relations, leaf or limb as well as customising how it handles duplicate nodes. I will spare you too much details for this post. You can always play around with these options to understand how they impact the result of your import. So for our example, we will elect to leave everything to default and go to the next step.

Next you must select the columns for each section. In this example, I have a hierarchy section and a relation section so I must configure the columns for these two sections. First select the hierarchy section.

 

In this file I have three fields, the hierarchy name, the top node and the hierarchy description. So I select these columns by placing them in the box on the right. (Columns noted with a star are required in any hierarchy sections). The second section is the relation section. In my file, I had three columns: parents, child and description. So I select these columns as shown here:

 

Please note you need to be careful with the order of the columns, they need to be selected in the same order as they appear in the flat file.

The fourth configuration step is the filters. Filters will allow you to define the behaviour for properties. It allows you to configure the import to skip blank values and skip default values if that is required. For this example, I am going to leave all the filters to the default values.

The final step is to define the target. As I have no version section, I must define the target version name and description. In this step you can also define the “Max Errors” number. This number defines how many errors can occur before the import is aborted. I’ll leave it to 20.

 

Now you have defined your import. You can save it using the usual save button. Execute it with the green arrow. Once you execute the import, Oracle Hyperion DRM will show a log for the import. The log will return an error message for each error, which allows you to correct your file or import.

 

Now you can navigate to “Browse” and see your new version with the imported hierarchies.

 

These last two posts on the basic requirements for Importing, intended to give you the basics on how to import into Oracle Hyperion DRM but there is much other functionality that it is worth exploring and utilising in your deployments of Oracle Hyperion DRM. If you would like to Seismi to look at anything specifically in future blog posts then please let us know.
 

Tagged , , , ,

Oracle Hyperion DRM Basics | Imports (1 of 2)

So now you know how to extract or export data from Oracle Hyperion DRM (Data Relationship Management) a logical next step is to understand how we get data into Oracle Hyperion DRM. Imports and scripts (or automators) are the two main tools available to get large amounts of data into Oracle Hyperion DRM. Imports are the best method if you need to import complete hierarchies with properties. Scripts are better to load specific property values, or changes, to a hierarchy that already exists. We will focus on imports in this post and then we will look at scripts in a future post.

To build your import you must:

  1. Set the flat file in the correct format;
  2. Set up the import;
  3. Execute the import;
  4. Check the log; and
  5. Save the resulting version.

Getting the flat file in the correct format is quite simple. You can use whichever file editing tool you prefer, such as notepad++ or notepad. The first thing you must choose is your separating character. The typical choices are the comma or semi-colon. You can also choose tab, or any special character. Oracle Hyperion DRM is quite flexible so you should focus on choosing one that is never used in the masterdata you are importing. Second, you must start building your sections. Your flat file can be divided into up to 5 sections. Sections are delimited by headers.

The five sections that can be included in the import are:

  1. Version – This section should contain a line with the version name and any property value to be associated to the version (default header: [version]);
  2. Hierarchy – This section should contain a line for each hierarchy to be created. The required information is at least the name and the hierarchy top node (default header: [hier]);
  3. Nodes – This section allows you to import a list of nodes and values for global properties (default header: [node]);
  4. Relation – This section should contain the relation between nodes, in a parent child format and any additional property values. Any node in the child column that does not exist will be created (default header: [relation]); and
  5. Hierarchy Nodes – This section should contain nodes to be imported and associated to a specific hierarchy. This will allow you to import nodes and the value for local properties (default header: [hiernode]).

A simple import file can contain only two sections: the hierarchies and the relations. So here is an example of a very simple import file:

[hier]

My hierarchy;TopNode;This is a new hierarchy

[relation]

TopNode;A;Node A

TopNode;B;Node B

B;B1;Node B1

A;A2;Node A2

A;A1;Node A1

This import file will create a new version (the name of the version will be required during the import as it is not specified in the file) with one hierarchy called “My hierarchy”.

In our next technical blog we will continue to explore how to import and specifically how to import the file we have just created.

Tagged , , , ,

Oracle Hyperion DRM Basics | Exports (2 of 2)

In last week’s post we introduced the export feature for Oracle Hyperion Data Relationship Management (DRM).  Once you have configured your source, style and filter, you can select the columns of your hierarchy exports.

 

You can define the columns by selecting properties. The export will return a line for each node that meets the filter criteria and in each line, it will write the value of each selected property. In this example, we have selected the two basic system properties Name and Description.

There are some additional options per column in the tab Column Options.

The three options are:

  1. Pivot – If a property contains a comma separated list of values, pivoting the column will repeat the line for each value of the list;
  2. Skip Defaults – If a property has a default value that should be replaced by a blank, you can use this option; and
  3. Primary Key – DRM will validate that the property has no repeated value. This should be used if you are exporting to a table that has a primary key.

The final configuration tab is called “target” and allows targets to be selected.

You can select one of three targets:

  1. Client File – Oracle Hyperion DRM will send the result to the client that triggered the export;
  2. Database Table – Oracle Hyperion DRM will write the results to a database table according to the connection, the table name and the column. You can also configure Oracle Hyperion DRM to delete the previous content of the table or partially delete the content if necessary; and
  3. Server File – Oracle Hyperion DRM will write the results into a text file in a folder on the server. You will also need to configure a connection to the folder and set the file name. The other options are the same as for the client file.

In our case, we will use the client file. We would recommend that you always run an export to a client file first to review the results before writing to databases or server folders.

The options when writing to a file are:

  • Column Headings – this option will add a line at the top of the file with the name of the columns;
  • Quoted String – puts text in columns into quotes;
  • Fixed Width – sets the width of the columns;
  • Character Encoding – sets the encoding standard for the file;
  • Replace Options – offers the possibility to replace any character with another during the export process;
  • Header – the text written in the header section will be added at the top of the text file;
  • Footer – the text written in the footer section will be added at the bottom of the text file;
  • Field Delimiter – choose the character that Oracle Hyperion DRM will insert to separate columns; and
  • Record Delimiter – choose the character that Oracle Hyperion DRM will insert to separate records. The default is the line terminator CRLF which means that Oracle Hyperion DRM will start a new line for each record.

Now that we have configured everything, we can run the export. As we created a client file export, Internet Explorer will ask you where you want to save the file that was generated by the Export.

Save it and open with Textpad or Excel to have a look at the results. Exports do not modify data in Oracle Hyperion DRM and by exporting to your client file, you are not affecting any system, so you can play with the export types and options without any wider consequences!

In our next technical post we will talk about importing data into Oracle Hyperion DRM. If you would like to explore any of these points in more detail then do reach out.

Tagged , , , ,