One of the main drawbacks of earlier versions of Oracle DRM was the fact that you need significant efforts to build work-flow into your metadata management. Oracle ships with DRM a basic work-flow development kit, using which the developers are expected to write Java code to build any meaningful work-flow. The effort required for this is not trivial either, with Oracle’s own product developers claiming it takes nearly as much or perhaps even more time as it took to develop the DRM application itself. Most companies bite the bullet and spend time and effort on building their own work-flow. Now with the release of DRM it’s all a thing of the past.

Oracle have come through on their promise of delivering an integrated work-flow solution that requires no additional programming. The work-flow delivered with DRM is more in line with other Hyperion products such as Hyperion Planning with its well designed work-flow.

The following are the main features of workflow in DRM

  • Integrated workflow with the core application
  • Common user interface for workflow and the core application
  • Workflow development based on configuration, not programming
  • Node Access groups has a new “group type” for workflow.
  • Node access contains workflow related actions

Shown below is a very basic introduction to the integrated work-flow being shipped with DRM. I suppose you could still go out and build your own complex flows if your business requirements demand it, but I have a feeling that for most situations, the built-in options will be sufficient. What Oracle have done is basically to convert the problem of work-flow development from programming into configuration. A job well done, by the way.

Step 1:n Right off the bat, you will see that there is an additional section in the navigation menu to the left as soon as you login. This screen shows the current and past workflow requests organised as categories. The work area in the middle shows the actual requests and the additional details about the requests.
1-opening screen

Step 2: The next thing you’d notice is the two additional options avaialble in the admin menu, namely “workflow task”, and “Workflow Model”. These two new constructs form the building blocks of our workflow processes.
2-New workflow task

Step 3: Let’s jump headfirst into creating a new workflow. Mind you, this is overly simplified approach meant as an example only, and you can build fairly complex flows using these basic building blocks. Select “New workflow task” from the admin menu, and the follow screen appears. We are going to create a simple workflow, where requestors will be creating a new leaf node, and approvers will decide whether to approve the request or reject it, among other things.
3-Create New Account

Let’s also create a couple of node access groups as shown below.

Step 4: Once the workflow task is created, the next step is to create a workflow model. Click on “new workflow model” as shown below.
4-New Workflow Model

Step 5: A new workflow model screen appears containing options similar to the ones below. A workflow model must have a “Submit” step, and either an enrich step, and/or an approve step. Commit step is also added by default. Give the model a meaningful name, and a label. For the submit step, pick a workflow task from the dropdown. Leave the other options for this step as default values.( you can change them if you know what you are doing)
5-Account Approval process

Step 6: I have created two node access groups, called “account requestors” and “account approvers”. As the names indicate, requestors will be given access to the submit request option, and approvers will be able to action those requests. The screen below shows that the “Account” node in the accounts dimension used to provide the necessary access. Notice the two options used here are also new to this version of DRM, and are meant specifically for workflow.
6-Account Node Access

Step 7: The following screen shows the completed workflow model from step 5 above. Note that I added an “Approve” step with the workflow task “Approve”. I haven’t shown the creation of this task, but it is simply the “update” option from the dropdown menu.
14-workflow model

Step 8:Let’s go ahead and create a “Requestor” type user. Note that the only roles assigned this user are both workflow related. This is quite significant because it forces them to only use workforce option in DRM, without being able to create or edit data directly. Assign the “AccountRequestor” node access group to this user. Other roles can be granted to workflow users but care should be taken on the hierarchy nodes they were given access to. I am not going into those details for this tutorial.

7-Access Requirements

Step 9: Let’s go ahead and login as the user we just created. You’ll see that the users homepage will show the workflow options in the navigation menu. These options will not be available to a non workflow user. The new request button on the menu bar of the work area will allow users to create new requests. For this example, I am going to add a top level child to the account hierarchy.
8-workflow user screen

Step 10: Fill out the details required for creating a new request as shown below. You will be able to select the workflow tasks we have created in steps above.

Step 11: Select the parent under which this new node is being created.
10-Add New Account Details

Step 12: After filling in the relevant details, click on the submit button as shown below. It asks you to enter a name for this specific request ( as opposed to the generic workflow task) and it’s a good idea to add some meaningful detail to the name.
11-Submit Request

Step 13: Once submitted, the request appears under the “submitted” category in the navigation menu.

Step 14: Now let’s go ahead and create a user, this time with workflow approval access. The screen doesn’t show it, but you need to assign the node access group “AccountApprover” to this user.

Step 15: Let’s login as the user we have just created. We can see right away that there is a workflow item for this user in the notified category.
14-workflow model

Step 16:Before an approver can do anything with a request, the approver must claim the request. Click on the “notepad” icon and select “Claim” to take ownership of this request.
16-Claim the request

Step 17:Once the request is claimed, a variety of options are made available. The request can be accepted, sent back to the originator, rejected, etc. For the sake of this tutorial, lets just select the approve option as shown below.
17-options available

Step 18: Depending on the complexity of the request and the speed of the servers, the approval process will take a minute or two and we see the following screen while that happens. Note that the message shows “pending” while the process is running.
18-pendingshowsapproval in process

Step 19: Once the process completes, you can navigate to the hierarchy to verify that request has been processed.

Step 20:Another great feature of the integrated workflow is the ability to view the current and past requests. This will enable the data managers and the administrators to keep track of metadata changes in the organization.

Step 21: A number of alerts are available to the administrators to keep them informed of pending requests and the approval processes.

As I have said repeatedly, this is an overly simplified example of the integrated workflow. Needless to say, the potential here is tremendous, and given that all the work is “configuration” as opposed to “Programming” a great many benefits can be realized using this version of DRM

Rajesh Valluri is a Hyperion consultant based out of Sydney, Australia. He can be reached at, or by visiting his website Trending Thoughts.
  If you like the blog entry please share it with your colleagues. Please do let me know if you have any suggestions regarding the content of this post.

Facebook Comments Box