Core Content Only

Content Profiles and Content Rules provide a mechanism for customizing a variety of pages within UCM.  Generally just referred to as Profiles, you can conditionally configure/customize the check-in, update, search and information pages as relates to the context of the content and user intent.

One of the often used by seldom explained parts of Profiles is something called Side Effects.  You will find the Side Effects tab on the Add/Edit Activation Conditions screen and it primarily allows you to accomplish two things:

1. Add name/value pairs as IdocScript that will then get pushed to local data if the activation condition is true.
2. Add custom IdocScript to a rule that is only evaluated if the activation condition is true and this can include logic like if and else statements or loops.  Basically all IdocScript is possible here (though all of it may or may not be useful).  As such, once a rule is activated, you can include logic, use includes from a component, etc.

What specifically might one use Side Effects for?  For a simple example let’s pretend we have a profile for some scanned content.  This content is checked in as an image based PDF (no OCR, no searchable text).  Your profile should not display the full text search box in this case.  There is no full text to be searched.  You can accomplish this with a Side Effect in your profile:

<$SearchEngineName="DATABASE.METADATA"$>

Let’s take another example.  Perhaps on the check-in page you want the alternate file field to be removed.  You could go into config.cfg and add this setting, but it would be universal.  More likely you want this to happen in a specific, conditional context.  Try adding this as a Side Effect to your rule:

<$suppressAlternateFile="1"$>

Want more examples of Profiles, Rules and Side Effects? See below:

1. Using Rules & Profiles To Drive Custom Pages
2. Suppressing Alternate File
3. Thumbnail search in Content Server
4. Thumbnail search in Content Server #2
5. Hiding the Primary File field in UCM
6. Metadata field tool tips

Running UCM admin applications directly from the server where Content Server is installed is called running them in stand-alone mode. No longer are they called applets, since the term “applet” is usually referred to a program which is included in a web page.

Stand-alone admin applications are located here: CS_INSTALL_DIRECTORY/bin/

Executable applications are listed in this folder. If an application is not listed, it can be entered as a parameter to the IntradocApp application, as in this example: % ./IntradocApp Workflow

In Windows, you can find the applications in your Start Menu: Start, Programs, Content Server, instance, Utilities, utility

In UCM 10g, you could run these stand-alone applications with no additional setup.

In UCM 11g, due to the advent of WebLogic, these applications need some setup. You need to setup a JDBC driver to talk to the database and you will need to login with a local user.

Below are 12 simple steps to get stand-alone admin applications running.

1. Login to UCM as an administrator.

2. Navigate to Administration > Admin Applets > User Admin.

3. Find the local user “sysadmin”.

4. Click “Edit”.

5. Change the password to something secure that you will remember.

6. Click “OK” and exit User Admin.

7. Navigate to MIDDLEWARE_HOME/user_projects/domains/DOMAIN/ucm/bin/

8. Open SystemProperties.

9. Go to the “Database” tab.

10. Select Oracle Thin JDBC Driver.

11. Click “OK”.

12. Now when you launch any of the stand-alone applications you will be prompted for a user name and password. Login with sysadmin and click “OK”. The application should now load.

The two stand-alone admin applications that do not need login credentials are SystemProperties and Component Wizard.

Oracle documentation on running UCM 11g stand-alone admin applications can be found here.

The first major patch set for Oracle UCM 11gR1 has been available on metalink for a few weeks now.  The official patch date is 20100901-1504 and the patch version is 9725318.  The steps for applying the patch are fairly simple:

1. Make sure ORACLE_HOME is set to the [ecmhome] directory.
2. Get the patch zip.Unzip said patch into a temporary directory.
3. Change into the patch directory.
4. It contains a top level directory, make sure you change into that as well.
5. Run OPatch apply: [ecmhome]/OPatch/opatch apply

There are a significant number of updates in the patch, especiallys as relates to URM.

So, for everyone waiting for the first patch before they take UCM for a test drive, you can stop putting it off.

This post demonstrates creating user-friendly URLs in Site Studio for secondary pages (think dynamic lists). When you execute the SS_GET_SEARCH_RESULTS service a resultset named SearchResults is returned.  While looping that resultset writing out URLs you should find a variable/column named SSUrl.  The default value for SSUrl will use the Content ID like this:

http://domain.com/NewsRoom/cpw000843

We can change this behavior by adding a configuration variable to the General Configuration section of Content Server named SSUrlFieldName.  We set this variable to the name of a metadata field we can use to control the end of the URL.  This enables us to construct URLs like this instead:

http://domain.com/NewsRoom/TimNewHire.htm

To enable this functionality we first need to create a metadata field that we can use to control the end of the URL.

1. Open the Configuration Manager Admin Applet (Administration > Admin Applets)
2. Make sure you have the Information Fields tab selected
3. Click Add
4. Supply a name for the field (note this name, we will use it later)
5. Click OK

On the edit Metadata Field screen set the Field Caption to Page Name, set Field Type to Long Text and Click OK.  Afterwards don’t forget to click “Update Database Design” and “Rebuild Search Index” if necessary.

Log into your Content Server and open Administration > Admin Server > General Configuration.  Add the following setting to the General Configuration and set it to the name of the new metadata field you created a moment ago.  Example:

SSUrlFieldName=SSPageName

Click save to persist your changes and then restart the Content Server.

Now, when you check in a piece of content you will be able to specify the page name for the content. Traditionally the URL will look like this:

http://domain.com/NewsRoom/cpw000843

But if I supply a value for our new Page Name metadata field like TimSmithNewHire the URL will now look like this:

http://domain.com/NewsRoom/TimSmithNewHire

I can also add a “.htm” or “.html” to the value in my field to give the URL a more traditional look and feel like this:

http://domain.com/NewsRoom/TimeSmithNewHire.html

Finally, if you want, you can add a little IdocScript to the derived value for the field in a profile and do things like drop out spaces or ensure that the contributor added htm or html to the end fo the supplied page name.  Here is a sample:

<$pagename = #active.xSSPageName$>
<$pagename = strRemoveWs(pagename)$>
<$dprDerivedValue = pagename$>
<$if not (pagename like "*htm|*html")$>
   <$dprDerivedValue = pagename & ".htm"$>
<$endif$>