Daniel Villani: 00:04
Now let’s take a look at the DRM user interface. So first I’m going to log into my DRM application. So I have my username, my password, and the application. If you have multiple applications in a set up, these will show as two or three or four. We just have one application set up here. So DRM app will be the only item and will be the default selection. So I’m just going to click log on after entering my user name and password. And this is the main screen that we are located. So off to the left hand side is our main panel where all of our different components of DRM exist. So work list is the first item. I’m just going to click on that real quick and we see that we have a bunch of different sub options over here. So we’re not going to go through all these in great detail since this, the focus of this video is on DRM and not DRG.
Daniel Villani: 01:15
But if you have the data relationship governance module set up and you’d like to set up workflows, this is where a user would, or an administrator would go in order to view the different workflows. See what state that, that they’re in. So you see assigned, this is where you can see any workflows that are assigned to you. Workflows can be marked as urgent and they go into a different queue there. You can set up timelines so that you can Mark when a request is overdue after, you know, X amount of time has elapsed. Claimed is any workflow that’s, you know, claimed by you. ,Submitted is the workflow. Once you submitted the request, I hate to use the same definitions as the the actual word there. ,But once you filled out all the information and you click the submit button, that’ll go in the submitted queue, a drafts or any workflows that you’ve started but not yet submitted. Maybe you’re waiting to find out some of the required information and you just have to wait for someone to get back to you. So you can save it but not submit it, the participated or any workflows that you are a participant. So whether that’s as a submitter and approver in your enricher notified and then, and then also this is where, where that queue is from a DRM perspective. If you’re not using the data relationship governance module you won’t be in this interface at all.
Daniel Villani: 02:58
Browse is the screen that you’ll see after logging in. This is where all of your hierarchies are, are present. So hierarchies are collected within snapshots or, or versions. And the versions are at the top of the screen here. So as you can see, we only have one and it’s the the working version. And you can have different versioning strategies for your organization. So some organizations like to put all their hierarchies within a single version. That way when you take snapshots of them you have a point in time view of all the hierarchies. Others like to have a version for every hierarchy there, pros and cons to that. We’re not going to talk through those at the moment. But all of your versions will exist up at the top here. So you can have a name, description type status, saved and loaded.
Daniel Villani: 03:59
And just a, a, a reminder that DRM versions exist in memory first when you create them. So unless you right click and hit the save button, if you restart your services, that version will get wiped out. So it’s a onetime thing. Once you create a version, you can just save it and then you see the little checkbox here and that means that it’s a, that it will exist even after you restarted services. All your hierarchies within that version exists at the bottom here. So, you know, we’ll go more in depth on versions and hierarchies in, in future videos, but just want to give you an overview of what the interface looks like. So once you double click on a, on a hierarchy, you’ll go to this screen where you can see the hierarchy, you can drill into the different levels there. We have a very simple one. We’ll build out a more complex example in a later video. But each of the nodes within the hierarchy exist here. Your properties, which we’ll talk about in a future video as well will be on the right hand side. So they’re grouped into, into different categories and you can see the different values for them over there. So stay tuned for our later video on properties and setting property values and so forth. So I’m just going to close out the stamp.
Daniel Villani: 05:36
The next item here are queries. So like any database, if you wanted to come up with a custom query to answer a question, you may have, you can create a query and that query will allow you to show all nodes with property value ofX for example. So you can do very simple things with queries. You could do more complex things with queries. It’s a graphical interface, so you don’t have to worry about knowing sequel or knowing how to write. Database queries compares, allow you to look at the difference between to hierarchy. So you can see a structural differences. So, for example, you can say, show me all changes to a hierarchy between, you know, two months ago and today or yesterday and today. ,So that’s the structural aspect of it. There’s also a property aspect of it. So show me all changes to the property value or show me what the property value was, you know, this time last month versus today.
Daniel Villani: 06:49
So we’ll have some future videos on you know, queries and compares in each of these and really deep dive into them. But just wanted to give you a high level picture of, of what they are. Scripts. DRM has a component called action scripts and action script essentially simulate what users would or administrators would do in the system. So anything that you can click on and do by hand, you can also have an action script. Do it. So whether that’s adding nodes to hierarchies, changing property values of hierarchies, you can even execute workflows through through action scripts. So we’ll talk through this in, in greater detail and show you some examples of building out hierarchies, using action scripts and, and so forth. So stay tuned for, for that imports deal with how do you get hierarchies and their property values into DRM from a source system.
Daniel Villani: 08:00
So as your designing and developing DRM, you can use it as a hub where DRM is not the source of your master data. It’s consolidating your master data or you can use it as a source where DRM is the origination point for your hierarchies and their property values. So if you’re using DRM as a hub and it’s consolidating the hierarchies and properties from source systems, you may be using imports where you define a file or a database connection and use that to pull in hierarchies and properties into DRM. Just a quick note on imports that you cannot import to overwrite an existing version. All imports have to occur in a, in a brand new version and you’ll use this blend tool once it’s in that new version to merge it into your main version. And this may not make sense now, but as we show a more in depth example of imports and blends, we will make it even clearer for you.
Daniel Villani: 09:18
Exports are how you would get your hierarchies and related properties and mappings. Anything else that you’re using DRM, how do you pull it out of DRM and send it to your target system? So there are some templates that as you can see, we have some of these items populated. There are some templates that you can pull into DRM to use. CRM as a starting point to Oracle provides templates for Essbase and planning on EPMA, PBCS, FDMEE if you want to have a starting point rather than starting from scratch. That’s what these are here. And we’ll talk through those in more detail when we get to the export. , Sction audit. So everything in DRM is auditable, so you can see who added a node or deleted a node on what date, at what time, who changed a property, what it was changed from, what it was changed to.
Daniel Villani: 10:26
And you can use this to reconstruct any hierarchy with any property value at any point in time. So I think you could go down to the the minute or even the second and reconstruct DRM hierarchies using the audit history. This is also a great way if you want to be able to see changes over time and just have an inventory of, you know, who did what when, if there are any questions on you know, who initiated this workflow you know, just to say who requested this member in the first place. You can use the audit history for that purpose. You can also see changes over time and so forth. So the audit capability is really, really powerful within DRM. We’ll have a separate video just on, on that when we, when we get there.
Daniel Villani: 11:25
The last section is the administer menu. So this is where you’ll create the DRM components such as you can create domains. We’ll talk about that a little bit more in more detail in another video properties and property categories. So for example, if your creating a hierarchy that you’re exporting to Essbase, you’ll have a property that says, what’s my Essbase data storage? What’s my Essbase formula? Et cetera. Are there any UDA [inaudible] so that’s where the property definitions can, will come into play. Property categories allow you to group properties together. So if I wanted to have all my Essbase properties, for example, in an Essbase category I can do that. So that way I’m not jping around between different different properties and scrolling down a list of, you know, a hundred, I can just see the, the 10 or 20 that are, that are relevant to me. Hierarchy groups allow you to group hierarchies together. So if I wanted to have separate hierarchies for a mean roll-up and an alternate roll up, but be able to see them together as my account, a hierarchy group, I can create that group to do so.
Daniel Villani: 12:45
Validations are very important in DRM because they allow you to get ahead of issues before they occur. So for example, if I am typing in a member formula into a, an account member, let’s just say I can create a validation to make sure that that member formula ends in a semi-colon. Otherwise when I go to load the formula into, into Essbase it, it can, it would fail and then I would have to look at it and try to figure out why it would fail versus being able to build a validation directly within DRM to be able to allow that. So you can, you build validations to check for special characters in, in member names and aliases. You can use it to make sure that I’m inputting only valid data. So we’ll have a whole video just on validations alone because they’re, they’re very important in how to proactive, proactively determine issues before they even get to the target system.
Daniel Villani: 13:57
Node types allow you to restrict properties for specific hierarchies. So for example, there may be some properties that are account specific, like account type. I wouldn’t expect to see, you know, account type on my scenario hierarchy or a year’s hierarchy. I would only expect to see it on my account hierarchy. So you can use node types to be able to filter out certain properties dependent on the type of hierarchy it is based on the level within the hierarchy. So maybe certain properties only exist at the higher levels and not the lower levels. So these are really powerful tools to be able to ensure that whoever’s maintaining the hierarchy only sees what they need to maintain.
Daniel Villani: 14:51
Glyphs allow you to have different icons for different members within hierarchies. I can tell you I don’t use them too much when when building out hierarchies for, for our clients. Cause many times they, you know, they don’t care what the, with the logo or you know, picture is next to it. But you can, for example, have a picture of, you know, dollar sign next to a cash account or you know, you can use different pictures to be able to graphically represent the, the type of account system preferences are the built in options that you can use to, to configure DRM. So we won’t go through this massive list here in this video, but these are where you can apply certain tweaks to how DRM behaves.
Daniel Villani: 15:52
External connections are where you define a connections to your source and target systems. So these can be file-based connections, like an FTP connection, connection to a shared drive. They can be database connections where you can connect to a relational database. They can also be web service connections where you can make a rest calls to you know, from a source or to a target system. Workflow is where if you have DRG and enabled and are looking to build a workflow model to have submissions, enrichment approval type capabilities to DRM, this is where you would build the workflow tasks and the workflow models. So the workflow tasks are the individual steps within your workflow. So I want to submit a new account. Here are the properties that I want to submit here is the member I want to submit here. That would be like a, an example of a submit step and enrichment.
Daniel Villani: 17:07
Let’s just say somebody submits a, an account and somebody else has to fill in the Essbase related properties to it. That person that fills out the Essbase related properties to it could be an enricher who would, you know, add to the workflow request and then you would have an approver. So an approval step where that approver would look in review at all the information provided and say, yes, this is good to commit to DRM a. Once they approve it, then it will get saved into the DRM database. So you can have multiple enrichment steps. You can have approvers based on different conditions, but the actual steps themselves are the workflow tasks. The workflow model would then be how, what steps you’re going to use and what are the conditions for. If you have conditional workflows and you want to branch for, for different reasons, security, you have a few different ways to grant security.
Daniel Villani: 18:14
So security can be creating individual users and giving them different roles. It can be a no to access groups which allow control within DRM for those particular users. So what nodes within the hierarchies they have access to, whether it’s read, access, write access, et cetera. We’ll go through the different security roles in a, in a subsequent video here. And then object access groups allow you to control who has access to specific components. So just to give you a quick example of this, if I go to exports, you see that we have standard exports and system exports. The system exports can only be viewed and run by system administrators, whereas the standard exports can be viewed by, by, by all. There are also a user exports where it’s only viewable to whoever the user is that created it. And you can create custom object access groups.
Daniel Villani: 19:22
If you wanted to restrict access, say you have exports that only the Essbase team can access. You can create an Essbase category where only the people that you’ve defined to have access to that group can, can run those exports. So those object access groups exist for most of the components that, that we have. But we’ll have a separate video on security where you, you can see here are all the different options that are available. And here is you know, what it, what it does. Well, I hope you found this helpful and stay tuned for the next video and we will show you more.