Creating a custom profile in Oracle UCM
Today, I was working with a client who wanted to create a custom “type” of document, with specific metadata, in their content management system, Oracle Universal Content Management 10gR3.
This seems like a fairly generic requirement, so I thought it would be good to capture the process here.
For this scenario, let’s say we want to create a new content type called “Controlled Document.” The special metadata we want to capture are as follows:
- author – who wrote the document,
- title – the title of the document,
- security classification – who is allowed to access the document,
- project code – the code number of the project that owns the document,
- embargo date – the date until which the document must be kept confidential,
- IP clause – any special rules around IP ownership and usage,
- keywords – search terms to help find this document.
Some of these (author, title and keywords) are provided “out of the box” with Oracle UCM, so we will reuse those. For the others, we will add our our custom metadata fields.
To start, we need to log on to UCM web interface as an administrator. In a default installation, this would be the user sysadmin, with password idc. The web interface is usually at http://yourserver/idc.
Open the Administration menu group and then Admin Applets. Click on the icon to open the Configuration Manager admin applet.
The Configuration Manager Admin Applet is used to define custom metadata, content types and so on, as we will see as we continue.
The first step is to create the new metadata fields, i.e. the ones which do not already exist. We will create the following fields, with the types listed:
Field Type --------------- --------------- xSecClass Text xProjectCode Text xEmbargoDate Date xIPClause Text xKeywords Text
We will use the prefix ‘x’ so that we can easily identify these metadata items as extensions.
We will create the metadata fields using the Information Fields tab in the Configuration Manger (as shown below).
Click on the Add… button to add a new field. In the popup box, we enter the name of the field, e.g. xSecClass, and then press OK.
Another dialog box is displayed, where we can enter additional information. In the example below, you can see that I have entered a Field Caption, and I have ticked theOption List checkbox, because I want this field to hold one of a defined set of values. Next, we click on the Configure… button to set up the allowable values.
In the dialog box that appears, we can accept the default values, including the name for our new option list, and click on the Edit… button to type in the actual values.
Each value is entered on a separate line. You can just type them in normally, pressing Enter between each one. In the example below, I have entered four different security classifications. You will notice that it is possible to have them sorted in various ways if you wish to.
We have now finished setting up the Security Classification metadata field. You can press OK several times to return to the main Configuration Manager applet. You can now use this same process to create the other metadata fields. You do not need to create an option list for the other fields. Be sure to select the type Date for the xEmbargoDate field.
When you are finished, the Configuration Manager applet should look something like this, with you new fields listed. Now we press the Update Database Design button to save our changes to the database.
You will get a popup message telling you that your fields will be added. Press OK.
You may ask “what actually happens in the database?” Good question! If you are using an Oracle database, then new columns will be added to the DOCMETA table to store our new metadata fields. You can take a look at them using the DESCRIBE command in SQLPlus. If you are using SQL Server, the table is called COLMETA.
SQL> DESC DOCMETA (some lines omitted here) XXDATECREATED TIMESTAMP(6) XXBPELSTATUS VARCHAR2(30 CHAR) XXDESIREDFOLDER NUMBER(38) XXSECCLASS VARCHAR2(30 CHAR) XXPROJECTCODE VARCHAR2(30 CHAR) XXEMBARGODATE TIMESTAMP(6) XXIPCLAUSE VARCHAR2(30 CHAR)
SQL>
Now that we have defined our metadata, we are ready to set up our profile. A profile is basically a set of rules about what metadata items are required for a particular type of content, in our case it is our “Controlled Document.”
So our next step is to set up a rule, to include all of the metadata fields that we want in our profile. This is done in the Rules tab in the Configuration Manager. Again, we click on the Add… button to create a new Rule.
In the popup box, name the rule ControlledDocumentRule. We will use the Fields tab to set the fields we want.
In the Fields tab, click on the Add… button to bring up a popup box where we can select the field we want to add. Scroll down to the bottom of the list to find your new fields, and add each of them one at a time.
For now, we will accept the defaults for each one, apart from the Use custom Label which you can set to something meaningful.
When you are finished, the Fields tab in your ControlledDocumentRule rule should look something like this (remember to add the out of the box fields too, not just your custom ones):
The next step is to create the profile itself. But first, we need to check one thing. If you have not created any profiles before, we may need to do an extra step. Go to the Profiles tab in Configuration Manager. Have a look to see if you have a field listed as your Trigger Field. If you do, then remember the name of this field. If you don’t, we need to create one.
If you don’t have the field, go back to the Information Fields tab, and create a new metadata field (just like we did earlier) called ProfileTrigger with type Text and use and option list (like we did for xSecClass). Add two entries to the option list:
- Standard
- Controlled Document
If you did have the field, you will need to add an entry to its list of options. Select the field in the list, press the Edit Tree button, and add “Controlled Document” to the end of the list.
Remember to Update Database Design after making these changes. Once you have done this, you can go back to the Profiles tab and click on the Select button next to Profile Trigger. Select your new field, that you just created. Now you are ready to continue.
Now we are ready to create the profile by pressing the Add… button and entering the name of the profile as shown.
Type in a Display Label and press the Add… button to add your ControlledDocumentRule by selecting it in the pulldown box in the popup window:
Then press OK to return to the profile definition. Select your trigger value Controlled Document from the Trigger pulldown and select the checkbox for Exclude non-rule-fields. When you are done, your profile should look like this:
You can now press OK to save your work, and then close the Configuration Manager and return to the Content Server web interface.
You may need to refresh your browser by pressing Ctrl-F5 (or equivalent) before the profile check in menu will display correctly in this step.
In the Content Server web interface, you should have a New Check In menu item, which will give you a pull down menu with a list of your profiles. You should now see your new profile in this list. Click on it to open the standard check in page for your new profile.
The next image shows the standard check in page that has been created for your profile. Yours probably looks a little different to this one – that’s ok, don’t worry! If you scroll through it, you should be able to find your fields in there, with the custom labels you gave them. If you did not set a custom label, the field name is shown instead (as in this example – to make it easier for you to spot them).
But you will probably notice that there a whole heap of other fields that you may not actually want on there. In the example we see things like Account, Content ID, Folder and Revision. If you want to suppress these fields, you need to add them to your ControlledDocumentRule rule in the Configuration Manager, but change the display type from Edit to Hidden.
Some of these fields may require a value in your environment. If so, you will have to check in a test document, and then look at the document information to see the default value, and add it in to your rule.
To do this, you select the field in question, go to its properties, select the Use default value checkbox, click on the Edit… button, click on the Add… button, give it a name (e.g. defaultValue) and type the value in the value box as shown.
Well, that’s it! We have created a custom profile for handling our Co