DRM Basics

Oracle Hyperion DRM Tips & Tricks | Quicker Navigation

A quick one this week we just thought we should share a small Oracle Hyperion DRM (Data Relationship Manager) feature that can be helpful and most importantly save time and raise your productivity.

Whenever you are working within a tab, you can right-click on the tab bar and see the different sections of the Home menu. This allows you to navigate directly from one module of Oracle Hyperion DRM to another, rather than having to click on Home then the name of the module you want. In the long run, this sav

140122_Seismi Blog_DRM Tips & Tricks_Quicker Navigation

es not just time but also frustration…

Tagged , , ,

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.


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 , , ,

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:


My hierarchy;TopNode;This is a new hierarchy


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 , , , ,

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 , , , ,

Oracle Hyperion DRM Basics | Queries

We mentioned last week that we were going to work on exports next. However, before using export you must start to understand the use of queries. So this week, we are going to have a look at property queries.

A property query is as its name indicates a tool to query the hierarchies according to properties. I’m sure I don’t need to explain how this can come in handy.

To start working with queries, navigate to the query page of the home tab. The home tab will show you a list of saved queries (if you have any) and some options like “New Query” or “Open Query”. If you see some saved queries you will noticed that they are grouped by access level. There can be up to three groups:

  1. User – Objects under this group are specific to the user. This means that any other user will NOT be able to see, execute or modify it;
  2. Standard – Objects under this group are standard to all users. They are shared; or
  3. System – Objects under this group are only available to administrators.

You will see the same type of groups in exports, blends or imports.












To start creating your own query, click on “New Query”. A New Query tab will appear. On top of the tab you will see three buttons:

Save – Save your query;

Save As – Save your query under a new name or group;

Run – Run the query and retrieve the results.

Under these buttons are four tabs. These four tabs are the four steps to defining your query. First, define the source. Select the version, the hierarchy and the top node to define the scope of your query.

Then select the style. You can select to see the results in a list, by marking the nodes in the hierarchy, or both.







Then comes the useful part: the filter. Use this tab to define the criteria of your query.

Click on the “Add” button to insert the first line.

For simple queries, focus on the columns “Property”, “Operator”, “Value” and “Join”. The property column allows you to select the property you want to filter on; then select the operator and the value. For example, by selecting the system property “#Children” (calculates the number of children), the operator “Equal” and entering the value 1, DRM will return only the nodes that have only one child.

Operators available for the query depend on the type of the property selected. Independent of the property, the available operators are:

  • Equal – True if the value stored in the property is equal to the value in the query;
  • NotEqual – True if the property stores a different value;
  • GreaterThan – True if the property stores a value greater than the value of the query;
  • GreaterThanEqual – True if the property stores a value greater or equal than the value of the query;
  • LessThan – True if the property stores a value lesser than the value of the query;
  • LessThanEqual – True if the property stores a value lesser or equal than the value of the query;
  • In – True if the value stored in the property is one of the values stored in the list of values in the query (values should be separated by commas);
  • NotIn – True if the value stored in the property is not one of the values of the list;
  • Contains – True if the property value contains the value of the query;
  • NotContains – True if the property value does not contain the value of the query;
  • Above – True for all nodes that are above a node that has the value stored in the property equal to the value in the query;
  • NotAbove – True for all nodes that are not above a node that has the value stored in the property equal to the value in the query;
  • Below – True for all nodes that are below a node that has the value stored in the property equal to the value in the query;
  • NotBelow – True for all nodes that are not below a node that has the value stored in the property equal to the value in the query;
  • IsBlank – True if the property is blank;
  • IsNumeric – True if the property is numeric;
  • IsNotNumeric – True if the property is not numeric;
  • IsNotBlank – True if the property is not blank;
  • LenEqual – True if the length of the string stored in the property is equal to the value of the query;
  • LenNotEqual – True if the length of the string stored in the property is not equal to the value of the query;
  • LenGreaterThan – True if the length of the string stored in the property is greater than the value of the query;
  • LenGreaterThanEqual – True if the length of the string stored in the property is greater or equal than the value of the query;
  • LenLessThan – True if the length of the string stored in the property is lesser than the value of the query;
  • LenLessThanEqual – True if the length of the string stored in the property is lesser or equal than the value of the query; and
  • IsDefined – True if the property is defined. A property is defined if a user has entered a value against this property, even if it is a blank.

The “Join” column will allow you to specify the join between two lines. The join can either be “And” or “Or”.

In this example, the query will return the nodes that have one child or two children. You will see a summary of your filter below the criteria table.



Below the filter, some additional options are available. Usually, queries are defined to return only the nodes that match the filter, but you can change the query to retrieve the nodes and their ancestors or the nodes and their descendants.





The final tab is the “Columns” tab. It will allow you to define the columns you want to see in the list result. This isn’t useful if you chose to see the results marked in the hierarchy.

Once you have selected your columns, you can save the query or execute it immediately without saving.

If you choose to execute without saving, you can always return from the results to the query definition by using the
return button.

In this example, I chose to see the data both in a list and marked in the hierarchy. So I have two tabs presenting the results: the list and the tree. In the list, I can always press the “Go” arrow for a node to open the hierarchy and expand it to that specific node.

Quite a lot of detail this but important stuff. Next week we’ll have a look at the exports and you’ll see why talking about queries first was necessary. In the meantime you know where we are

Tagged , , , ,

Oracle Hyperion DRM Basics | Node types

Now we are getting into what makes Oracle Hyperion Database Relationship Management (DRM) so flexible: node types. As we explained in an earlier blog, nodes in a hierarchy can be assigned a node type. Node types allow you to filter properties and validations that will be available for the node. Node types will also allow you to assign a different icon to your nodes.

There are three steps that you need to follow to assign node types. First you create the node types you need; second you create a property to assign the node type to a node, and thirdly, you associate this node type property to the relevant hierarchies.

1. Create a node type

Log in to Oracle Hyperion DRM then navigate to Administer > New >  Node Type. Oracle Hyperion DRM will open a tab similar to the following:


You must give the node type a name and a description. You can also assign a glyph to the node type. The glyph is an icon that will be shown against the nodes. In this example, I will not be associating any glyph to the node type, but to do so, all you have to do is load the icon by creating a new glyph then select it in the node type definition.



Once the node type has a name and a description you can associate properties and validations using the lower part of the screen. Only the properties that are associated to the node type will be visible against a node with that node type. Similarly, only validations associated to the node type will be executed against nodes with that node type. Once you have associated the properties and validations, you can save the node type.

2. Create the property to associate node types to nodes.

In the following example, we are just going to create a simple defined local string property with a list. Let’s say we only have two node types, “Account node type” and “Other”, we create and configure this list property with only two valid values “Account node type” and “Other”. This way, we are sure that users will only select a valid node type.


Note: The property must always store the exact name of the node type. If the property stores a value that does not correspond to any existing node type, Oracle Hyperion DRM will assign the default node type to the node, so all properties and validations will be assigned to the node.

Since we have just created this property and we want it to be visible against the node type we created, we have to go back to our node type definition and associate it to the node type.


3. Associate property to a hierarchy

Navigate to the version and right click on the hierarchy then select properties.


In the system property labelled “Hierarchy Node Type”, select the property you have just created then save.











Now nodes in the hierarchy will assume the node type you select in this property.

Hopefully this will have helped you understand how to work with node types but do contact us if you want any further clarification. In our next technical blog we will review exports.

Tagged , , , ,