DRM- How to Lock DRM Users Out of Applicaition for Short Periods of Time

What are the ways to lock DRM users out for short periods of time?

There is no one way to lock people out of DRM. Some workarounds would include the following depending on how DRM is configured:

1. If user are CSS ( shared service users) one could change the authentication mode of DRM to be just internal. Bounce DRM; Then use only an internal user to run the updates.

2. One could go through and change each user in DRM to Lock them out but this is very manual and if there are a lot of users , time consuming

3. If user are apart of NAG’s, then all of the roles could be revoked, then added back after the black out period is over




DRM – How to create a workflow model

The new request tab under worklist is greyed out for the user as workflow model was not created.

Scenario: Create a Workflow Model(WFM) which has two stages one is Submit and the other is Commit. This WFM is used for adding new base node.

1.Create users with the below roles:

Governance user, governance manager and workflow user

2.Create required Node Access Group(NAG).

3.Create the workflow task.

4.Create the workflow model.

–Click on Edit of Submit Stage in Action column and assign Workflow Task and Node Access Group to that Stage.

–Select the respective Workflow Task in the available list and push to selected list.

–Select the respective NAG in available list and push to selected list.

–Click on Save which is on the right-hand side

–Click on Edit of Commit Stage in Action column and assign Node Access Group to that Stage

–Select the respective NAG in Available list and push to selected list

Note: No Workflow Task will be there in Commit Stage.

–After completion of all Stages updates, Click on Save.

5.Assigning Hierarchy Node Access to NAGs
–Login to DRM.

–Select Version and open respective hierarchy.

–Go to Nodes->Assign->Node Access

–Select respective NAG group and select the appropriate access level and click on Save.


The new request tab in the work list will be available now.

DRM Learning – Export global nodes

Exporting global nodes is useful when you want to output a list of nodes from a version without specifying hierarchy information; for example, a master list of projects, a report of inactive customers, or a list of employees who are not assigned to a cost center.

For this type of export, configure the export wizard tabs as follows:

  • Source—Select a normal, baseline, or as-of version.
  • Style—Indicate whether to export all nodes or only limb or leaf nodes. You can include implicitly shared nodes, if necessary.
  • Filter—Define a query or validation. Only nodes that meet the query criteria or that fail the validation are exported.
  • Columns—Select properties, including version and global properties, for output columns in the export. You can include as many properties as needed. For example, you may want to include a node’s name, description, and parent node name.
  • Target—Specify whether to export results to a client file, a server file, or a database table. If you export to a database table, you must also specify the database table.

Begin by navigating to the Export task group. Use the Export task group to create and manage exports.

Screenshot for Step

Click the New Export () button.

Screenshot for Step

Use the Choose Export Type dialog box to select an export type (hierarchy, comparison, version, property, or log).

Click Version.

Screenshot for Step

Use the export wizard to define the source, style, filter, columns, and target for the export. You begin on the Source tab.

Use the Source tab to specify the version that you want to export. You can select a normal, baseline, or as-of version. In this example, you leave the [Default Current Version] – 2010 03 – Production normal version selected. Click the Style tab.

Screenshot for Step

Use the Style tab to specify the type of nodes to be included in the export and to specify whether to include implicitly shared nodes.

Perform the following actions on the Style tab:

  • Click the Leaf Nodes Only option.
  • Leave the Include Implicitly Shared Nodes option cleared. This option enables you to include descendant nodes below shared limb nodes that are explicitly shared. Implicit shared nodes are exported only if they are not filtered out by another option. If you use a query filter in the export, you must explicitly include the shared nodes.

Screenshot for Step

Click the Filter tab.

Screenshot for Step

Use the Filter tab to define filter criteria for the exported data. Only nodes that fail the validation or that meet the query criteria are included in the export results.

In the Query list, select North America Cost Centers.

Screenshot for Step

The Description field displays the query criteria.

Click the Columns tab.

Screenshot for Step

Use the Columns tab to select global properties for the export. In this example, you export Name, Description, and Region (in that order).

In the Available list, click Description.

Screenshot for Step

Click the Select () button.

Screenshot for Step

The Description property is displayed in the Selected list.

In the Available list, click Name.

Screenshot for Step

Click the Select () button.

Screenshot for Step

The Name property is displayed in the Selected list.

Click the Category drop-down list.

Screenshot for Step

In the Category drop-down list, select Location.

Screenshot for Step

In the Available list, click Region.

Screenshot for Step

Click the Select () button

Screenshot for Step

The Region property is displayed in the Selected list.

Make the Name property the first in the Selected list. Click 2 – Name.

Screenshot for Step

Click the Move Up () button.

The Name property is displayed first in the Selected list.

Click the Target tab.

Screenshot for Step

Use the Target tab to configure where the data is to be exported and the format of the exported results.

In the Device drop-down list, select Client File to export data to a client file.

Screenshot for Step

In the Field Delimiter drop-down list, select (Comma) to indicate the field delimiter character and record delimiter character. In this example, you use commas for the field delimiter.

Screenshot for Step

Click the Save As () button to save the export to the repository .

Screenshot for Step

Use the Save Export As dialog box to specify a name, a description, and an access level for your export.

In the Save Export As dialog box, perform the following actions:

  • In the Name field, enter North America Cost Centers.
  • Optional. In the Description field, enter a meaningful description of the new export. For example, enter North America Cost Centers.
  • In the Object Access Level drop-down list, select Standard. The Object Access Level field assigns one of the following access levels:
    • User—Enables only you to run and edit the blender
    • Standard—Enables all users to run the blender, but only users with the Data Manager role can edit it

Screenshot for Step

Click OK. The tab name is displayed as North America Cost Centers.

Screenshot for Step

Click the Run () button to process the export.

Screenshot for Step

The File Download dialog box is displayed. Use the File Download dialog box to open or save the export results. You can also cancel the export, if necessary.

Click Open.

Screenshot for Step

The export results are displayed in Notepad.


DRM- Cross Referencing Nodes in Another Hierarchy

I am getting a lot of questions now a days on DRM cross referencing nodes and how to achieve this.

let’s say we want a property to hold a comma-separated list of nodes in the Accounts hierarchy where a certain property value matches one in the current node.

For example, a list property has certain values, e.g. HR, Finance, Legal, etc. Nodes in the Services hierarchy need a list of nodes in Accounts where this value matches.

Any solution that traverses a whole hierarchy for each execution of a formula, i.e. for every node in another hierarchy, would have performance implications once the number of nodes rose above a few thousand.

Here we describe how to use a lookup table for the list. A property (e.g. ‘AccountLookup’) needs to be created with a lookup table pre-populated with the list of those nodes in the Accounts hierarchy that have each possible entry, e.g.

HR – 001,002,003,…
Finance – 004,005,006,…
Legal – 007,008,009,…

The cross reference property should be a string lookup property, with AccountLookup as the lookup property and the value the list property.

Populating the lookup table is not so straightforward. My proposal is this:

1. Create an export for each possible value of the list property (‘ListProp’). The first export, ExportHR, has the top of hierarchy Account as its top node, recurses, has a single column, NAME, and an in-line query filter: “ListProp Equal HR”. On the Target tab, export to client file with the Field Delimiter set to None and record delimiter set to comma. This produces a file with a single line. In the Header field enter HR. The result is this:
2. Copy this export to ExportFinance, replace the filter value with  “ListProp Equal Finance” and put Finance in the Header field
3. Repeat for Legal and all other members of the list.
4. Combine these exports into a book, exporting to client file and selecting ‘Include Combined Export Output File’ with Combined.txt as the filename. This book now produces a zip file, which if you open it in Windows Explorer can be drilled down into to find Combined.txt, which looks like this:


5. If you use the Migration Utility to export the ISSrelatedCoA property, it contains a section like this:


It should be possible to merge Combined.txt with XML like above to create Migration Utility import. You might use a utility or XSLT for this. Note that the XML file must be complete, i.e. not only contain the above!

The lookup table must be refreshed whenever the Accounts hierarchy or its ListProp values change.

— Comments and questions welcome.



What caused the Data Relationship Management (DRM) Environment to Restart Reboot Suddenly

The IIS Application pool Recycling was not configured or is miss-configured . Without this configured IIS will continue to use memory for the web application until its allotted memory is full. It will then recycle to clear the memory. This happens all existing session are terminated. Since DRM work primarily in memory all data not saved to the database will be lost.

To configure this parameter follow these steps:

To open IIS Manager from the Start menu

Click System and Security, and then click Administrative Tools.

In the Administrative Tools window, double-click Internet Information Services (IIS) Manager.
To open IIS Manager from the Search box

Click Start.
In the Start Search box, type inetmgr and press ENTER.

In the Connections pane, expand the server node
Click Application Pools.
On the Application Pools page, select an application pool generally drm_pool,
Click Recycling in the Actions pane
Click the box next to Specific time
In the box below enter a non business time ( IE 2:30 AM)
Click next
Click Finish
Click Recycle on the right hand side ( this will activate the changes)

Close IIS Manager

Saving DRM as-of-version

As-Of versions can not saved directly because they are intended for temporary analysis.

Indirectly, however, in the DRM interface, copy the As-Of version with a new name and the newly created copy can be saved.

Via the batch client :

Use the batch client to export an as of version to file.

Please see https://docs.oracle.com/cd/E40248_01/epm.1112/drm_user_11123500/frameset.htm?ch16.html for the parameters that can be used in the Export Section of Configuration File


Data Relationship Management Best Practices


Use default values for properties. When a value is used often, defining it as the property default helps reduce database size.

Use inheritance for the same reason. (Local inheriting means from the hierarchy you are looking at; Global means from the node’s position in a specific hierarchy, the Controlling Hierarchy.)

Use Global Properties unless

– the value must be different for the same node in different hierarchies or

– the value for shared nodes must be different from the primary node in the same hierarchy

Consider the performance implications of derived properties. Functions that are recursive, such as NumDescendantsWith, are much slower than simple functions. The order of items in, say, IF functions can affect performance too.

Do not delete properties once the system is live. You will lose historical data and it may have unexpected effects if anything else uses the property, such as exports, queries and derived properties. To deprecate a property, hide it instead.


Define a naming standard for versions so that it is easy to determine what is what in the future.

Baseline versions, together with the Transaction History, are used to create As-Of versions. If you do not require this functionality, you can turn off Baseline versions using the System Preference AllowAsOf. After setting this to false and restarting the DRM application, you will find they are no longer created when you create a new version.

Copy versions on a periodic basis. For example, start each month with copies of the previous months’. If you do not, the Transaction History for the version will eventually become unmanageable. Employing DRM’s versioning functionality gives the following benefits:

– allows the use of version status to lock older versions

– enables you to delete older versions and their transaction history

– permits easy comparisons with prior business states

– ensures the As-Of capability performs well.


It is best practice to use separate hierarchies rather than shared nodes if possible. For example, instead of having one Organization hierarchy that contains Legal, Managerial and Line of Business, separate them into three separate hierarchies and put them back together when exporting to downstream systems.


Creating properties with the validation logic (i.e. placing the logic inside a single derived boolean property rather than having complex tests in the validation itself) permits re-use of the properties in Queries, Exports and other Validations.

Real time validations have significant performance cost, especially complicated ones, because all of them are run on each change, including every line of Action Scripts. Use them wisely!

Note that Real Time usage does not protect against changes in values from inheritance or derivation. Consider whether certain validations should also be run as batch validations before performing exports etc.

Node Types

Once Node Types are in use, any new validations or properties must be added to the appropriate node types or they will not visible to users.


For best performance use a recent version of a supported browser. At the time of writing the supported browsers are FireFox 17 ESR and Internet Explorer 7.0, 8.0 and 9.0, but we recommend Firefox or IE 9.0 for the best UI performance. “JavaScript performance has been much improved over older versions of Internet Explorer.


DRM application performance recommendation

Performance issues can arise by various factors/reasons.

Some known performance bottlenecks are:

1 – Number of direct children. If a node has more than two to three thousand direct children it may impact performance.
2 – Real Time Validations. If there are many real time validations that include complex or recursive formula properties then you will see performance issues
3 – Number of properties with defined values per node. When each node has a large number of values this can use up memory and can cause the system to page to virtual memory depending on the server setup

will add up more as and when it comes up on my mind.


Approval Change Tracking – DRM

DRM can be configured to warn administrators of certain changes, such as changes to specified properties or events like a node’s being moved, by resetting a flag. Several flags, each with different conditions, may be defined. The combination of flags and conditions (or ‘triggers’) is termed an Approval Group.

When an action requiring approval is made by an end-user, the approver will be alerted by the flag property (for which a query may be defined). The approver will acknowledge by setting the flag or taking corrective action if necessary. The convention is that the node is deemed ‘approved’ when the flag is true, and ‘requiring approval’ when false.

Approval Groups are complementary to Change Tracking in that they are configurable, whereas Change Tracking is triggered upon any change to a node. However, Change Tracking captures more detail including the ID of the person making the change and the time & date of the change.

Approval Tracking has been largely superseded by Transaction Requests (and now, Data Governance), which permit changes requiring approval to be grouped as a single entity and allow the request to be validated without committing changes to the Data Relationship Management version. In contrast, Approval Tracking only occurs after the changes have occurred.

1. Define the Approval Groups

2. Define the conditions and triggers for each Group

3. Specify the custom properties to be used as flags

4. Enable Approval Group Tracking

5. Restart the DRM Service

6. (Optional) Define Queries for Approvers’ Use
1. Define the Approval Groups

Determine how many Groups will be required and give each one a name, e.g. Sales, Treasury. These names should be entered as a comma separated list (no spaces) into the System Preference ApprovalGroups, e.g. Sales,Treasury

2. Define the conditions and triggers for each Group

The System Preference ApprovalGroupTrackProperties is used to set up the conditions and triggers for each group. For each group, give the Appproval Group name followed by a list of properties you wish to track (comma separated) enclosed by square brackets, e.g. Sales[Descr,Region]. Concatenate the group definitions with commas.

In addition to tracking property changes, Approval Tracking can be configured to react to certain events. A string like {NodeChanged} is added to the property list. The full list of triggers is:

{NodeAdd} – Triggers the Approval Needed mechanism on a node being added
{NodeInactivate} – Triggers the Approval Needed mechanism on a node being inactivated
{NodeReactivate} – Triggers the Approval Needed mechanism on a node reactivated
{NodeInsert} – Triggers the Approval Needed mechanism on a node inserted
{NodeRemove} – Triggers the Approval Needed mechanism on a node removed
{NodeMove} – Triggers the Approval Needed mechanism on a node moved

Example: Sales[SalesGroup,{NodeMoved}],Treasury[AccountDescription,{NodeAdded}],Admin[Descr,{NodeMoved},{NodeRemove},{NodeInsert}]
3. Specify the custom properties to be used as flags

For each Approval Group create a custom property with the following parameters:

DataType: Boolean
Property Level: Global Node
Property Type: Defined
Default Value: True
Then assign the flag to each group by entering a list of <group name>:<flag prop name> pairs as a comma separated list in the System Preference ApprovalPropertyByApprovalGroup

Example: Sales:SalesApprovalFlag,Treasury:TreasApprovedFlag,Admin:AdminApprovedFlag

4. Enable Approval Group Tracking

Set the System Preference UseChangeApproval to True.

5. Restart the DRM Service

6. (Optional) Define Queries for Approvers’ Use

For the convenience of Approvers, for each Approval Group define a Property Query to find the nodes where the relevant Flag property is false.