Technical

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 Technical Issue | Integration with EBS

Hi everyone!

We just stumbled upon an interesting change in the latest version (11.1.2.3) of Oracle Hyperion Data Relationship Manager (DRM). For performance reasons,
Oracle has decided to limit the number of tables Oracle Hyperion DRM can detect when you define an external connection to 2000.

This is usually not a problem. However, if you follow the DRM Oracle General Ledger Integration Guide you’ll see that you ‘must’ use the APPS schema to integrate DRM to E-Business Suite (EBS). This schema usually has more than 2000 tables associated. This means there is a risk that the two target tables used by DRM (GL_DRM_SEGVALUES_INTERFACE and GL_DRM_HIERARCHY_INTERFACE) will be missing from the list of tables for the external connection.

Despite what the integration guide says, however, you can in fact define a different database user with write access to just these two tables and gain access to them that way.

Note that Oracle has logged an enhancement request to remove this restriction, so future releases may not come with this limitation. We experienced this with DRM 11.1.2.3.303.

We hope this is useful.

Tagged , , ,

Oracle Hyperion DRM Tips & Tricks | Clearing a Property Value

If you ever need to clear all values of a defined property within a hierarchy (prior to blending in a completely fresh set of property values, say), it can be done in a few brief steps.

Firstly select the top node of the hierarchy and choose the tab the property is on. If the top node does not normally show this property, you will have to select Show All Properties on the property viewer. Only administrators can do this but then again, only administrators should be doing this.

Next, right-click on the property label and choose Clear All Below, followed by Save. This removes all explicitly defined values from each node below the selected node. (This is a useful little option in itself.)

131211_Seismi Blog_Clear Property Value in Oracle DRM

Finally, right-click on the property label and choose Remove Value, then Save. This removes the property value from the top node.

There are action script equivalents of these two commands, so if you have a whole set of properties to clear an action script is probably the way to go:

131211_Seismi Blog_Clear Property Value in Oracle DRM_2

Tagged , , , , ,

Oracle EPMA | Error on import

We are doing a fair amount of work with Oracle Enterprise Performance Management Architect (EPMA) application at the moment. We came across the following error message recently. (In the spirit of paying it forward we thought we should share it with you.)

“EPMA Error on import – Member cannot be inserted because the parent member has another child member with the same name.”

It took me some time to understand this one although in the end the cause was quite simple. I hope that this can save you some time…

One of my imports to EPMA was failing and returning the error “This member cannot be inserted because the parent member has another child member with the same name.”

130802_Seismi_EPMA Error on Import_1

 

130802_Seismi_EPMA Error on Import_2

 

At first this seemed like a simple mistake in my load file. After checking, I was disappointed to discover the error message was misleading. My file contained the correct structure:

#root|BALSHT

BALSHT|ASSET_ACC

The member ASSET_ACC was not repeated in the hierarchy section. The import profile was set to replace the current dimension so the fact that the member ASSET_ACC was already in EPMA should not have been an issue.

This article from Oracle’s Knowledge Base gave me a hint as to the source of the issue in the document EPMA Error “This member cannot be inserted because the parent member has another child member with the same name” [ID 1361635.1]

The issue was that in my current dimension, the member BALSHT was written BalSht. It looks like EPMA is only partially case sensitive so it was partly recognizing BALSHT and BalSht as being the same member but it was not updating that member correctly. As soon as I renamed BALSHT to BalSht in the file, the import worked.

The root cause to keep in mind is that EPMA does not handle subtle differences in cases well.

Tagged , ,

HFM Redeploy from EPMA – Unspecified Error

When redeploying an Oracle Hyperion Financial Managemenent (HFM) application from Oracle Enterprise Performance Management Architect (EPMA), the deploy operation can fail and return a very unhelpful error message “Unexpected Error”. Although not immediately obvious, this error usually indicates there is an issue within the outline however, if the application has data, it may simply be that the data is being reorganized.

The screen shot below shows the EPMA summary:

130726_Seismi_HFM Redeploy from EPMA_1

The EPMA error log only is not much help either.  It returns the following information:

Error Reference Number: {5AD32CB5-7E26-4A48-A98C-5DC4870698E7}

Num: 0×80004005;Type: 0;DTime: 05/07/2013 13:54:20;Svr: UK1WHYPAPP11Q;File: CHsvMetadata.cpp;Line: 1056;Ver: 11.1.2.1.600.3779;

Num: 0×80004005;Type: 0;DTime: 05/07/2013 13:54:20;Svr: UK1WHYPAPP11Q;File: AgentHelper.cpp;Line: 1237;Ver: 11.1.2.1.600.3779;

Num: 0×80004005;Type: 0;DTime: 05/07/2013 13:54:21;Svr: UK1WHYPAPP11Q;File: CHfmAwbAgent.cpp;Line: 665;Ver: 11.1.2.1.600.3779;

To solve this, in the deploy screen uncheck the “Check Referential Integrity” option and check the “Full Deploy”.

130726_Seismi_HFM Redeploy from EPMA_2

Changing these options should allow you to deploy the HFM Application.

WARNING – Deploying without the option “Check Referential Integrity” means that data can be affected. Before doing so, be sure you have a backup of the application and a point of comparison to review any changes.

 

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.

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

Oracle Hyperion DRM technical issue | Application Restart Failure

We’re back blogging again!

Firstly, please accept our apologies for the lack of submissions over the last few months. It has been a busy time for Seismi. We have had major implementations underway with a number of our clients that has distracted us from this blog! It is only now that we have time to draw breath.

I thought that it would be useful to report back an issue that we recently experienced with Oracle Hyperion Database Relationship Manager (DRM) in a client’s development environment. Hopefully this blog will achieve two objectives.

• help you understand this particular issue; and
• explain the process we went through to diagnose and fix the issue.

The issue

During our development cycle we needed to restart our DRM server. The server stopped fine, but refused to start again. A review of the Windows event viewer showed us that two errors had been produced. The first related to a validation incorrectly referencing a global property and the second, showed the DRM application was shutting down. Our immediate thought was that the two must be related and so we raised an service request with Oracle. Oracle gave us a fix to allow us to change the property used in the validation to a global property. With much anticipation we ran the fix and then tried to bring up the application. Unfortunately, it still would not start. A further review of the Windows event log now showed a different error message.

System.ArgumentException: An item with the same key has already been added.
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
at Oracle.Drm.Engine.Core.VersionMgr.b__9a()
at Oracle.Drm.Engine.Core.VersionMgr.Write(Action func)
at Oracle.Drm.Engine.Core.VersionMgr.b__b6()
at Oracle.Drm.Engine.Core.VersionMgr.Write(Action func)
at Oracle.Drm.Engine.Core.Engine.Start()
at Oracle.Drm.Engine.Host.Program.Main(String[] args)

We notified Oracle that their fix had not resolved the issue. We also felt it was necessary to restore the DRM database from the last back up prior to the issue occurring (i.e. the day before). Disappointingly this restore did not resolve the issue, implying that the issue had been lying dormant for an unspecified period of time.

With very little information to go on we revisited the Windows event viewer and, starting from the first time we experienced the issue, we worked backwards through all the DRM messages to identify any unexpected entries. After a few hours of (mind-numbing!) analysis, we discovered the following entry dated three days prior to the eventual problem:

Oracle.DataAccess.Client.OracleException ORA-03114: not connected to ORACLE at Oracle.DataAccess.Client.OracleException.HandleErrorHelper(Int32 errCode, OracleConnection conn, IntPtr opsErrCtx, OpoSqlValCtx* pOpoSqlValCtx, Object src, String procedure) at Oracle.DataAccess.Client.OracleTransaction.Rollback()
at Oracle.Drm.DalFramework.DatabaseContext.Rollback()
at Oracle.Drm.DalFramework.DataAccessLayer.Rollback()
at Oracle.Drm.DalFramework.DataAccessLayer.ExecuteTransaction(Action codeBlock, Action afterCommit, Action afterRollback)
at Oracle.Drm.Engine.Core.VersionMgr.DeleteVersionFromDB(Int32 versionID)
at Oracle.Drm.Engine.Core.ReaderWriterLockSlimExtensions.WriteLock(ReaderWriterLockSlim rwLock, Action action)
at Oracle.Drm.Engine.Core.VersionMgr.DeleteVersion(String versionAbbrev, Action`1 updateProgress, Action fireEvent)
at Oracle.Drm.Engine.Core.ReaderWriterLockSlimExtensions.ReadLock(ReaderWriterLockSlim rwLock, Action action)

Please note that this entry was not logged as an “Error”, but as a “Warning”. Looking at these two messages side-by-side we saw that both errors mentioned the “Oracle.Drm.Engine.Core.VersionMgr”. The “Warning” suggested a loss of connectivity during the delete of a DRM version (“Oracle.Drm.Engine.Core.VersionMgr.DeleteVersionFromDB”) and the error at start-up suggested some form of duplication with the versions (“System.ArgumentException: An item with the same key has already been added.”). At this point we decided to connect directly to the DRM database to have a look at the version table. When we queried the table we saw two versions with identical names, aside from case. One was called “LIVE” and the other “Live”. This seemed unusual and so we used a different DRM server to try and replicate the issue. The DRM interface prohibited it.

We suspected that if we changed the name of one of the versions, the duplication issue would be resolved and the server would restart. With the upmost caution, and only as a last resort, we manually updated the RM_VERSION table to remove the duplicate names and restarted the server successfully. We are still in the process of trying to identify why the database allowed this issue to occur. The RM_VERSION table has a unique that should have prevented this and so we are starting to look at the schema settings. If we track anything down, we will publish an update to this blog.

Hopefully this has helped those of you trying to diagnose this particular issue. We also hope that it has given you some guidance on how to diagnose an issue with DRM. Remember that some issues only become apparent after an application restart and can be hidden by other errors. Always concentrate your analysis on the period between the last successful restart and the failure. Finally, remember that you need to review all log entries, not only those that are tagged as “Error”.

Until next time – hopefully next week….

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

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