Oracle Hyperion DRM Basics | Versions

Last week we looked at how to navigate through Oracle Hyperion Data Relationship Manager (DRM). This week we are going to go to the “Browse” section of the Home Page.
http://69.195.124.204/~seismine/wp-admin/edit.php
The upper section lists all the current versions present in your application. As you can see, each version has a name, a description, a type, a status, a saved flag and a load status. These are system properties associated to a version. Additional properties can be created if necessary.

In order to create a new version, we must click on the “Versions” menu then on “New”. Alternatively, next to the “Versions” menu is a shortcut to the new button.

 

 

 

 

 

 

 

 

 

Once we select new, Oracle Hyperion DRM will ask us to give the version a name and a description.

 

 

 

 

 

By default, Oracle Hyperion DRM creates all new versions that are not saved as loaded versions, with a status of “Working”.

First, I have to explain what the “Saved” flag indicates. A version is saved when it is written in the database. Oracle Hyperion DRM allows you to create versions without saving them. If you delete them or stop the server, no record is kept of unsaved versions. Unsaved versions can be useful for quick what-if scenarios or demonstrations, but in general, I strongly recommend saving your version as soon as possible. To do this, right-click on the version and select  “Save”.

As you save, Oracle Hyperion DRM will create a baseline of the version. You can open the baseline by expanding the plus sign on the left of your version.

You can see that the baseline has the type “baseline”. The baseline is simply a copy of your version as it was when initially saved. Oracle Hyperion DRM will now start logging any modification in the live version. The baseline gives the starting point, and by combining the starting point and the logs, Oracle Hyperion DRM will be able to rebuild “As-Of” versions. We will examine “As-Of” versions in a later blog but, in essence, this will allow you to generate a copy of the version as it was at a certain date.

You can also see that the baseline has a status of “Expired”. A version can have one of the following statuses:

  • “Working” – all users with the appropriate security settings can edit the version;
  • “Submitted” – only the owner of the version or the users with the “Data Manager” role can edit the version;
  • “Finalized” – no user can edit the version. The version is read only; and
  • “Expired” – no user can edit the version. The version is read only.

We will also go into more detail on security in later blogs. The important thing to remember is that the status can allow you to freeze the version or to limit the users that can edit the version.

Finally, a version can be “loaded” or “initialized”. A version that is “initialized” is saved in the database but is not loaded in memory. You will only be able to view the hierarchies in a “loaded” version. From a performance perspective, we recommend only loading the versions that you need to navigate. Unloading versions that are not in use will save memory and therefore increase the general performance of Oracle Hyperion DRM.

In the next technical blog, we will start looking at hierarchies and nodes, the core of Oracle Hyperion DRM. In the meantime if you have any questions please do not hesitate to contact our team.

 

This entry was posted in Technical and tagged , , , . Bookmark the permalink.

Comments are closed.