Skip Headers
Oracle® WebCenter Content Application Administrator's Guide for Content Server
11g Release 1 (11.1.1)
Part Number E10978-02
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Master Index
Master Index		 Go to Feedback page
Contact Us
Go to previous page
Previous		 Go to next page
Next
PDF · Mobi · ePub

3 Managing Schemas and Profiles

This chapter discusses managing repository metadata with schemas, rules, and profiles. You can create metadata schemas to manage dependent lists that are localized for specific sites. You can create content profiles to customize what metadata fields appear on different screens.

This chapter discusses the following topics:

3.1 Using Schemas to Customize Metadata

To create custom metadata fields that present a list of values, use the Information Fields tab of the Configuration Manager. You can also make the associated list dependent on the value of another field. This organization is called a dependent choice list (DCL).

For example, assume there are Country and State information fields. The country you select determines the choices available in the State list.

You can also use metadata schema mapping to create field lists. With metadata schema mapping, you can easily adjust option list views to accommodate localization requirements.

This section covers these topics:

3.1.1 Schema Structure

A schema is a collection of related schema objects. The term schema also refers to a graphical depiction of the database hierarchy that is created to support the Oracle WebCenter Content Server metadata schema mapping feature. The schema hierarchical structure consists of tables and their respective columns (or fields), views of the data, and the relationships between them.

Let's add City, Region, and Area Code information fields to the Country and State example to illustrate a three-tiered dependency structure.

In Figure 3-1, the sample basic schema hierarchy, one independent field has two dependent fields. Each dependent field also has a dependent field. These dependencies are also referred to as Parent/Child relationships.

Figure 3-1 Basic Schema Hierarchy Example

Surrounding text describes Figure 3-1 .

This three-level schema hierarchy produces five distinct metadata fields: Country, State, City, Region, and Area Code. Each field presents a specific list to the user.

The contents of the lists are contingent on whether the information field is dependent or not. Thus, the following lists result from the sample basic Country/State/Area Code schema hierarchy:

  • The Country list is independent and the choices remain constant.

  • The choices available in the State list are variable and depend on which country the user selects from the Country list.

  • The choices available in the City list are variable and depend on which state the user selects from the State list.

  • The choices available in the Region list are variable and depend on which country the user selects from the Country list.

  • The choices available in the Area Code list are variable and depend on which region the user selects from the Region list

Schemas are comprised of Tables, Views, and Relationships, as discussed in the following sections.

3.1.1.1 Tables

Schema tables are database tables that store the choices displayed in information field (metadata) lists. Tables and their columns are created using the Tables tab of the Configuration Manager. You can have multiple columns in each table but at least two are essential for producing dependent choice lists:

  • The common column name used to create the dependency between one list and a second list that is dependent on the choice made from the first (for example, Country and State, respectively).

  • The column that stores the choices for metadata lists.

Figure 3-2 Schema Tables Example

Surrounding text describes Figure 3-2 .

Using the geographical example (Country, State, City, Region, Area Code) in the three-tiered schema hierarchy, a table must be created for each branch in the schema tree structure. Additionally, the dependent tables (child tables) must contain a column that corresponds to an identical column in the table to which it is subordinate (the parent table). These corresponding columns are used to create the dependencies between the two tables and are ultimately used to generate the dependent choice lists.

For example, the tables in Figure 3-3 illustrate how the Country and State table columns might be populated. The data in each name column provides the choices available on the lists. The relationship that is created between the corresponding columns in the Country and State tables (countryID) determines what choices are displayed in the State metadata list.

Figure 3-3 Populated Schema Tables

Surrounding text describes Figure 3-3 .

3.1.1.2 Views

A view is a tailored presentation of the corresponding table. Views do not contain data, but they derive data from their tables. Views are used to simplify a database for use and to present data in a different perspective.

A view consists of a list of properties and associated display rules. Each table in the schema must have an associated view. Views provide information about these items:

  • Specific columns in the table included in the schema. The selected columns are used to establish the dependencies between tables and also to generate the dependent choice lists.

  • Internal and external column names.

  • User interface display characteristics.

  • Editing and sort order criteria.

3.1.1.3 Relationships

Relationships define the dependencies between tables and are essential in generating the appropriate dependent choice lists. Each defined relationship establishes the correspondence between parent and child tables. This correspondence is created by specifying the column in the child table that is dependent on the column in the parent table. Thus, the choices displayed using column data from the child table are contingent on the choice made from the corresponding column data from the parent table.

Figure 3-4 Table and Column Relationships

Surrounding text describes Figure 3-4 .

For example, in Figure 3-4, the CountryView (Country table) and the StateView (State table) use the countryID column to create a relationship that generates a parent country list and a child state list. The choices available in the State metadata list are dependent on the choice made in the Country metadata list.

3.1.1.4 Schema Directory Structure

Three subdirectories are associated with the Schema function, located in the /weblayout/resources directory:

  • schema

  • schema.work

  • schema.old

The schema.work directory is usually not listed because it is a temporary directory. When the schema creation process completes, the working directory is renamed. If this directory exists it indicates one of the following:

  • A large schema rebuild is in progress

  • The schema is created, but there is a problem with the schema structure.

    Caution:

    If working inside the directory structure to review the Schema files and directories, be sure to close all open applications accessing these files. The directories are renamed on completion of processing. However, if external applications, such as text editors, are using these files the schema.work directory cannot be renamed.

3.1.1.5 Sample Schema-Based Lists

After the schema tables, views, and relationships are created and properly established, the lists display the appropriate choices. For example, in Figure 3-5, the Country list now displays two choices: United States and Canada.

Figure 3-5 List Example

Surrounding text describes Figure 3-5 .

Because the State metadata field is contingent on the Country field, the State list contains items based on the choice made in the Country list. In this case, if the United States choice is selected, the State list displays Minnesota and Wisconsin as choices. If Canada had been selected, then the State list would display Ontario and Quebec.

Figure 3-6 Dependent List Example

Surrounding text describes Figure 3-6 .

3.1.2 Creating Schemas

The Tables, Views, and Relations tabs in the Configuration Manager are used to create the schema structure.

  • The Table tab is used to select or create the database tables.

  • The Views tab is used to manipulate the views used in the schema.

  • The Relations tab is used to manipulate the dependencies.

The Information Fields tab is used to create the metadata fields used on Oracle WebCenter Content Server pages. The metadata fields must be correlated to the tables and views to properly display the lists.

New or modified schemas are automatically updated during each scheduled publishing cycle. Because the default interval between each publishing cycle is set to four hours, immediate results for new or modified schemas are not visible. To adjust the interval between each publishing cycle, change the default value of the associated configuration variable. For more information, see Section 3.1.2.6, "Modifying the Publishing Cycle Interval."

This section provides an overview of a simple sequence using the applicable Configuration Manager tabs to create a schema structure.

This section covers the following steps in creating a schema:

3.1.2.1 Selecting Tables for the Schema

To select tables for the schema:

  1. Choose Administration then Admin Applets from the Main menu. Click Configuration Manager then the Tables tab.

    The Configuration Manager: Tables Tab Screen opens.

  2. To add tables to the schema, click Add Tables and select the tables to add to the schema from the Select Table Screen. When creating a new table, click Create Table.

    Important:

    You can use core system tables such as Revisions, Alias, Documents, and Users, but you cannot edit them (remove columns, alter column length, and so on.)

  3. After you select tables, the Create/Edit Table 'name' Screen opens with Table Column names filled in.

  4. Select the column to be used as a primary key to establish a dependency and select Edit. The Add/Edit Column Screen opens.

  5. Select the box labeled Primary Key and click OK. Select Add Recommended to add recommended columns to the table.

Repeat these steps for all tables to be used in the schema. When finished, click OK.

3.1.2.2 Creating the Schema View

To create the schema view:

  1. Choose Administration then Admin Applets from the Main menu. Click Configuration Manager then the Views tab.

    The Configuration Manager: Views Tab Screen opens.

  2. To create a view, click Add to open the Add View Screen: Select Table Screen.

  3. Select the table to use in the view and click Next. The Add View Screen: Select Columns Screen opens.

  4. Choose the columns to include in the view, and click Finish. The Add/Edit View Screen opens.

  5. Select a name for the view and add information for the description. Choose the internal column (name in the database) to use in the view and choose the visible column that is displayed to end users. You can specify a display expression (text and Idoc script) that is displayed in place of the actual field value. When done, click OK.

  6. Repeat these steps for all tables to be included in the view.

3.1.2.3 Creating the Schema Relationships

To create the schema relationships:

  1. After the tables and associated views are completed, click Relationships to establish the dependencies between tables and columns. A list of the currently existing schema relationships is displayed.

  2. Click Add to set up a new schema relation. The Add/Edit Relationship Screen opens.

  3. Enter the name of the relationship (for example, Country_State to indicate the relationship between the Country and the State tables). In the Parent Info box, select the table where the parent information resides (for example, the Country table) and the column to be used to establish the dependencies (for example, the countryID). Do the same for the Child Info field (for example, select State as the table name and countryID as the relationship).

  4. Click OK when done. The new relationship is now displayed on the Relations list.

3.1.2.4 Adding Metadata Fields

The final phase in schema creation is to set up the metadata fields to use the columns and to configure them to use the Views and Relations created previously. For an overview of the procedure, see Section 2.2.2, "Adding or Editing a Custom Field" and Section 2.2.4, "Defining an Option List."

3.1.2.5 Enabling the Schema

After you configure the schema, the views, and the relationships, click the button on the Configuration Manager screen to update your database design. Click Options then Publish Schema from the Configuration Manager Page menu.

Republishing (updating) of schema takes place automatically based on these things:

Do not select Options then Publish Schema unless it is necessary to see the new Content Type quickly. The system can be overloaded when large lists are republished.

3.1.2.6 Modifying the Publishing Cycle Interval

New or modified schemas are automatically updated during the automatic schema publishing cycle. However, by default, the interval between publishing cycles is set to four hours. New schemas or changes to existing schemas are not seen in the corresponding menu lists until the completion of the next publishing cycle. Adjust the publishing cycle interval by changing the value of the SchemaPublishInterval configuration variable.

To change the interval of schema publishing cycles:

  1. In a text editor, open the IntradocDir/config/config.cfg file.

  2. Add the following configuration variable and value:

    SchemaPublishInterval=300

    The value is specified in seconds. In this configuration example, the lists are republished every 300 seconds (that is, 5 minutes).

    Note:

    Depending on the number of lists in addition to the size and complexity of each list, automatically republishing (updating) your schemas frequently can have a significant impact on your system's performance.

  3. Save and close the config.cfg file.

  4. Restart Oracle WebCenter Content Server to apply the changes.

The queries for schema publishing are cached for up to five minutes. Publishing more frequently does not retrieve new values until the current cache expires.

If a new value is added to a metadata field, that value is not displayed on the content item's Content Information page until the next publishing cycle is complete.

If one content item is checked in with a unique value in a dynamic list and a second item is checked in with the same value but using a different case, the value is treated as one value in the list. The case used is dependent on the database sorting scheme.

For more information about creating dynamic lists, see Section 3.1.3, "Schema Example: Dynamic Lists."

3.1.3 Schema Example: Dynamic Lists

Creating a dynamic list enables users to add values to metadata lists. For example, if a value exists in a list, users can select the value from the list. However, if it is a new value, users can enter the value into a text field and it becomes available as an option following the next publishing cycle.

To create a dynamic list, first create a view into the table in the database. The list values are pulled directly from the metadata columns where they are stored. As content items are checked in, revised, and removed, the list values change or are updated accordingly.

The following is an example of creating a dynamic list:

  1. Choose Administration then Admin Applets from the Main menu. Click Configuration Manager then the Information Field tab.

    The Configuration Manager: Information Field Tab Screen opens.

  2. Click Add.

    The Add Metadata Field Name Screen opens.

  3. Enter the name of the metadata field that has the dynamic list. For example, TestMetadata.

  4. Click OK.

    The Add/Edit Metadata Field Screen for TestMetadata opens.

  5. Complete the fields as necessary but do not select Enable Option List.

  6. Click OK.

    The screen closes and the Field Info list on the Configuration Manager: Information Field Tab Screen shows the added metadata field.

  7. Click Update Database Design.

    The Update Database Design Screen opens and lists the TestMetadata field to add.

  8. Click OK.

  9. Open the Configuration Manager: Views Tab Screen and click Add.

    The Add View Screen: Select Table Screen opens.

  10. Click Add Table.

    The Select Table Screen opens.

  11. Select the DocMeta table.

  12. Click OK.

    The Select Table screen closes and the DocMeta table is added to the Tables list on the Add View Screen: Select Table Screen.

  13. Click Next.

    The Add View Screen: Select Columns Screen with column names opens.

  14. Select the column to use to create the list for TestMetadata.

  15. Click Finish.

    The Add/Edit View Screen page opens.

  16. Enter a view name. For example, TestMetadata_view.

  17. Click OK.

  18. Open the Information Fields tab on the Configuration Manager: Information Field Tab Screen and select TestMetadata.

  19. Click Edit.

    The Add/Edit Metadata Field Screen for TestMetadata opens.

  20. Select Enable Option List.

  21. Click Configure.

    The Configure Option List Screen for TestMetadata opens.

  22. Select Edit and Select List from the Option List Type list.

  23. Click Use View and select a view from the list. For example, TestMetadata_view.

  24. Click OK.

    The Configure Option List Screen closes.

  25. Click OK.

    The Add/Edit Metadata Field Screen closes.

  26. Select Publish schema from the Options menu on the Configuration Manager: Information Field Tab Screen.

Test this list by checking in a document and entering a value into the new dynamic metadata field. Initially, the list is empty because no documents have been checked in that contain data in the TestMetadata field. However, as documents are checked in with values entered in TestMetadata, the list includes the specified values.

3.1.4 Schema Example: Recursive Table for Multiple Trees

Creating a recursive table enables the use of the data for multiple schema trees.

  1. Choose Administration then Admin Applets from the Main menu. Click Configuration Manager then the Information Field tab.

    The Configuration Manager: Information Field Tab Screen opens.

  2. Create a database table with two columns (id,parent):

    1. Open the Tables tab and click Create table.

      The Create/Edit Table 'name' Screen opens.

    2. Enter the table name. For example, TreeTest.

    3. In the Columns pane, click Add.

      The Add/Edit Column Screen opens.

    4. Enter the first column name (id) and its length. Click OK.

    5. Enter the second column name (parent) and its length. Click OK.

    6. Click OK to create the table.

  3. Create a view on the table that includes both columns:

    1. Open the Views tab and click Add.

      The Add View Screen: Select Table Screen opens.

    2. In the Tables pane, select TreeTest and click Next.

    3. In the Columns pane, select the id and parent check boxes and click Finish.

      The Add/Edit View Screen opens.

    4. Enter the view name. For example, TreeTestView. Add display, options, and security configurations as applicable.

      Display tab: used to create rules for the relationship.

      Option tab: used to establish the sort order and criteria for the data in the schema.

      Security tab: used to define security rules for the schema.

    5. Click OK to create the view.

  4. Create a relationship on the view:

    1. Open the Relations tab and click Add.

      The Add/Edit Relationship Screen opens.

    2. Enter the relationship name. For example, TreeTestRecursive.

    3. From the Parent Info table list, select TreeTest and in the corresponding column list, select id.

    4. From the Child Info table list, select TreeTest and in the corresponding column list, select parent.

    5. Click OK to create the relationship.

  5. Open the Information Fields tab and click Add.

    The Add Metadata Field Name Screen opens.

  6. Enter the custom metadata field's name and click OK.

    The Add/Edit Metadata Field Screen opens.

  7. Select Enable Option List and click Configure.

    The Configure Option List Screen screen opens.

  8. Click Use Tree and click Edit Definition.

    The Edit Tree Definition Screen opens.

  9. In the Building level pane: Select view for level1 list, select TreeTestView.

    TreeTestView is entered as Level 1 in the Tree Definition pane.

  10. In the Building level pane: Select relationship between the 1st and 2nd level list, click TreeTestRecursive.

    TreeTestRecursive is added under TreeTestView in the Tree Definition pane.

  11. In the Building level pane: Select view for level 2 list, click TreeTestView (recursive to level 1).

    TreeTestView (recursive to level 1) is entered as Level 2 in the Tree Definition pane and the Select root button is added.

  12. Click Select root.

    The Select Tree Root dialog opens.

3.2 Using Profiles to Customize Content Screens

Administrators can use Content Profiles to selectively include or reorder metadata fields to produce targeted Check In, Update, Content Information, and Search pages.

Content profiles do not create or modify any Oracle WebCenter Content Server tables. They are simply used as a type of filter for what information is displayed. All information for the Content Profile is stored in the IntradocDir/data/profiles/document/ directory.

After you create a content profile, it is always active. You can disable the link on the user interface, but the profile rules remain functional unless the profile is deleted.

This section covers these topics:

3.2.1 Content Profile Elements

A profile is composed of rules and a trigger value, which are set up on the Profiles and Rules tabs of the Configuration Manager screen. Administrators can create multiple content profiles and all are available to the end user. For each profile, the end user has a distinct check-in page and search page available. Although all profiles are visible to all users, each user can configure their user interface to hide or display links to specified profiles.

Note:

Documents cannot be associated with multiple profiles in the system.

Content profiles are composed of the following:

  • Rules: A rule consists of a set of metadata fields that determine if fields are editable, required, hidden, excluded, or read-only based on their criteria when specific conditions are met. You can change a rule's behavior based on an input, or activation condition. You can evaluate a rule for every profile (global), or you can evaluate the rule for specific profiles. For ease of use, you can use rules to group metadata fields under an optional header.

    For example, a profile's rules can determine the user type and, depending on the document type being checked in, ensure that only specific metadata fields are displayed. Rules must be established before a profile is created.

  • Triggers: A trigger field is a metadata field that is defined on the Configuration Manager: Profiles Tab Screen. If a document matches a trigger value for a profile, then that profile is evaluated for the document. There can be an unlimited number of profiles, but only one trigger value per profile.

    Although you create rules before you create triggers and profiles, it is necessary to know what your trigger is before creating rules.

3.2.1.1 Using a Profile Link

When a profile is enabled on the Edit Content Profile Links page, the profile is available from the Search and New Check In menus on the toolbar. If no profiles are enabled for display, the Search and New Check In menus become direct links to the Advanced Search page and standard Content Check In Form, respectively.

After a profile has been created, it appears in the Search and New Check In menus on the toolbar after refreshing the browser session. By default, all profiles are listed as options under both menus. However, not every user is authorized to use all of the listed profiles. On the Edit Content Profile Links page, select or clear applicable check boxes to specify the profiles to display.

For example, a marketing employee does not have the necessary privileges to use an accounting profile. In this case, the user can clear the check boxes for the accounting profile and it does not display under Search and New Check In menus. For more information about the user interface in general and the content profile links in particular, see the Oracle WebCenter Content User's Guide for Content Server.

3.2.2 Content Profile Rules

Note:

Although you create rules before you create triggers and profiles, it is necessary to know what your trigger is before creating rules.

A profile consists of one or more rules and a trigger value. The rules determine how metadata fields are displayed on the Check In, Update, Content Information, and Search pages and if a rule is used (depending on how it is evaluated). Each rule consists of the following:

Global rules are always 'on' (always evaluated). A global rule automatically affects the metadata fields displayed on the Check In, Update, Content Information, and Search pages even if it is not included in a profile or even if no profiles have been created. It is not necessary for a profile to exist in the system for any defined global rules to take effect and be applied to events, actions, or workflow states. However, you cannot preview the effects of a global rule unless it is associated with a profile.

Global rules are evaluated first and can be superseded by specific profile rules. The priority for the global rule can be set to increase its precedence. It can then have a higher priority than specific rules and produce different profile results. View those results by previewing the profile and seeing the consequence of rule selection.

A global rule obeys the following guidelines:

  • It is always on, is independent of a profile, and is always evaluated.

  • For documents and searches with profiles, the global rule is evaluated first. The specific profile rules are evaluated after the global rule. Global rules have a lower priority than profile rules.

  • Global rules have a priority number. The priority determines the order in which the rule is evaluated. Lower priority rules are executed earlier and rules with higher priority can override changes made by rules with lower priority.

This section covers these topics about rules:

3.2.2.1 Metadata Fields and Attributes in Rules

Each metadata field in a rule has the following attributes:

  • Field position (required): Adjusts the general placement order of the metadata field. Values are top, middle, and bottom.

  • Display type (required): Determines how the metadata field is displayed on the Check In and Search pages.Values can be Edit, Info Only, Hidden, Excluded, or Required. If required, a message is also required.

  • Use Default value (optional): Displays a default value for the metadata field.

  • Is Derived value (optional): Enables the metadata field to be set to a specified value on update or check in.

  • Has Restricted list (optional): Allows the list metadata field to be restricted to either a specific list of values or to a filtered list of values.

3.2.2.2 Activation Conditions in Rules

An activation condition allows a change in the profile behavior based on different inputs. For example, a rule is not active for the search page or for a contributor, or certain fields are hidden or overridden on check in. Also, because profiles are activated during any check-in process, distinctions are made between a browser check in and a batch-load check in.

You can preview profiles to assess the validity of the activation conditions. The previewing screen is used to check the existing profile and perform what-if scenarios by changing activation condition choices and evaluating the results.

You can base an activation condition for a rule on:

  • A system event: These include on-request events, on-submit events, and on-import events.

  • A user action: These include check in new, check in selected, content information, content update, and search.

  • A workflow state: These are contingent on if the content item is in a workflow.

  • A document type: These can use components based on document metadata fields.

  • A user type: These can use components based on user metadata fields.

    Caution:

    Be very careful when using activation conditions that include one or more combinations of condition choices. Not all combinations of activation condition choices are valid and some can be mutually exclusive. For example, if an activation condition requires the event to be an import and the action to be a document information page request, the activation is never true and the rule is never active.

3.2.2.3 Restricted Lists in Rules

The restricted list is an optional attribute for a metadata field in a rule. You can modify the user interface for metadata fields defined as lists in two ways:

  • Specifying a fixed list: An explicit set of values that override the actual master list for the metadata field that was defined as a list. Only those items in the master list are displayed in the user interface list.

  • Using regular expression evaluation: The list can include wildcards and other special characters for string pattern matching and evaluation processes. The items displayed in the user interface list are those values satisfying the regular expression.

3.2.2.4 Regular Expressions

Regular expressions are ideal for text manipulation and describe the format of strings. In its simplest form, a regular expression specifies the text to match.

For example, the regular expression 'ABC' matches the string ABC but not the string DEF. You can use wildcard characters, such as the asterisk (*), to match more strings. The asterisk (*) specifies zero or more instances of the preceding character or characters. For example, the regular expression 'A*B' matches the strings B, AB, AAB, AAAB, and so on.

This section provides a brief overview of using regular expression evaluation to generate modified user interface lists. Because of the complexity of regular expressions, system administrators must be familiar with regular expressions, building patterns, and implementing regular expression methods. If not, use Oracle Consulting Services to assist in defining restricted lists.

The following table lists the most commonly used modifiers, metacharacters, and special characters used in building patterns for regular expression evaluation.

Modifiers

Element Definition

g

Global pattern matching.

i

Case-insensitive pattern matching.

m

Allows the special characters ^ and $ to match multiple times within a string.

s

Allows the special character . to match newlines.

x

Ignores whitespace within a pattern.

Metacharacters

Element Definition

\s

Matches whitespace (including tabs and newlines).

\S

Matches anything that is not whitespace.

\b

Matches only a word boundary.

\B

Matches only nonword boundaries.

\d

Matches digits 0 through 9.

\D

Matches only nonnumeric characters.

\w

Matches only letters, numbers, or underscores.

\W

Matches only characters that are not letters, numbers, or underscores.

\A

Matches the beginning of a string only.

\Z

Matches the end of a string only.

Special Characters

Element Definition

*

Matches zero or more occurrences of the preceding character.

+

Matches one or more occurrences of the preceding character.

?

Matches zero or one occurrence of any character.

.

Matches any one character, except newlines.

^

Matches the beginning of a string, like the \A metacharacter.

$

Matches the end of a string, like the \Z metacharacter.

|

Imposes either, or.

The following examples illustrate the results displayed in the user interface lists depending on how the Edit Restricted List Screen is completed. The restricted lists being defined use a metadata field defined to be a list. Its master list values are the US states in alphabetical order. The two dependencies include:

  • The items or expression entered into the text pane.

  • The Allow Java Regular Expressions check box (selected or unselected).

Example 1

In this example, text values are entered into the text pane and the Allow Java Regular Expressions check box is not selected. In this case, the options 'NoState' and 'Carolina' are not included in the resulting list because they are not full names of states. Note that the order is maintained as typed into the text area.

If the following values are entered into the text pane:

  • Alabama

  • Minnesota

  • NoState

  • Utah

  • Carolina

The results displayed in the user interface list are:

  • Alabama

  • Minnesota

  • Utah

Example 2

In this example, the same text values are entered into the text pane as in Example 1. However, the Allow Java Regular Expressions check box is selected.

If the following values are entered into the text pane:

  • Alabama

  • Minnesota

  • NoState

  • Utah

  • Carolina

The results displayed in the user interface list are:

  • Alabama

  • Minnesota

  • Utah

  • North Carolina

  • South Carolina

In this case, both 'North Carolina' and 'South Carolina' are included in the resulting list because they match the regular expression 'Carolina'.

Example 3

In this example, the Allow Java Regular Expressions check box is selected and instead of entering similar text values (as in the previous examples) the ^ special character is used with alphabet characters.

In this case, there are two regular expressions. The first expression specifies choosing everything in the master list beginning with C and the second expression specifies choosing everything beginning with Al. Notice that the results order is dictated by how the list was entered in the text pane.

If the following values are entered into the text pane:

  • ^C

  • ^Al

Then the results displayed in the user interface list are:

  • California

  • Colorado

  • Connecticut

  • Alabama

  • Alaska

Example 4

In this example, the same values are entered into the text pane as in Example 3. However, both values are entered on the same line and separated with the pipe ( | ) special character which is evaluated as 'or'. In this case, the expression retains the values in order because the list is filtered exactly one time for values that begin with either Al or C.

If the following values are entered into the text pane:

  • ^C | ^Al

The following results are displayed in the user interface list:

  • Alabama

  • Alaska

  • California

  • Colorado

  • Connecticut

3.2.2.5 Using Rules to Group Metadata Fields

You can group and arrange metadata fields and label them with an appropriate header. The fields are shown on the Check In, Update, Content Information, and Search pages as specified in the group.

To create metadata groups, select Is Group on the Add/Edit Rule Screen. Use the Fields tab to add metadata fields to the group. Use the Up and Down buttons to rearrange the fields.

For example, Figure 3-7 shows a rule on the left that results in the metadata field list on the Check In page on the right. In this example, Content ID is the group leader because it is the first element in the group list. The metadata fields included after Content ID are the group associates.

Figure 3-7 Metadata Fields Generated from Rule

Surrounding text describes Figure 3-7 .

Figure 3-8 shows the same rule but the metadata fields in the group have been rearranged using the Up and Down buttons. This reorganization results in a different listing of the same metadata fields on the Check In page. In this case, Security Group becomes the group leader and the other fields are now the group associates.

Figure 3-8 Reorganized Metadata Fields

Surrounding text describes Figure 3-8 .

In Figure 3-9, a single profile contains three rules that have grouped metadata fields. Each group has one field that belongs to another group. In this situation, the system uses resolution rules to reconcile any conflicts.

Figure 3-9 Profile with Rules Grouping Metadata Fields

Surrounding text describes Figure 3-9 .

Caution:

System evaluation and implementation of additional profile and global rules that contain one or more of these metadata fields can cause grouping conflicts. Some rules executed later can override earlier rules and affect how grouped metadata fields are resolved.

The following rules resolve conflicts between metadata fields that belong to groups in multiple rules:

  1. The first element in the list is the group leader.

  2. All elements following the first element are the group associates.

  3. If the group leader is not a group leader in another group listing, then assign any group associates to the group, below the group leader.

  4. If a group leader is a group associate in a prior group listing, then the new group listing is merged with the prior group listing as follows:

    1. Find the main group leader (the group leader in the prior group).

    2. Insert the new group associates after the group leader in the main group leader's group associates list.

  5. Ensure that no group associate has multiple group leaders. If so, remove the associate from the prior group leader's list.

  6. If a grouping has a group associate that is a group leader in another later grouping, then this rule is invalid, an error is reported, and the rule is not evaluated. (If this were to be allowed, the result would be a non-group leader (a group associate) being promoted to a group leader.)

Example 1

  1. IF: A,B,C is a metadata group

    WHERE: A is the group leader and B and C are group associates to A

  2. AND: B,D,E is another metadata group

    WHERE: B is the group leader and D and E are group associates to B

  3. RESULT: A,B,D,E,C

Example 2

  1. IF: A,B,C is a metadata group

    WHERE: A is the group leader and B and C are group associates to A

  2. AND: A,D,E is another metadata group

    WHERE: A is the group leader and D and E are group associates to A

  3. RESULT: A,D,E,B,C

    Example 3

Example 3

  1. IF: A,B,C is a metadata group

    WHERE: A is the group leader and B and C are group associates to A

  2. AND: C,B,D is another metadata group

    WHERE: C is the group leader and B and D are group associates to C

  3. RESULT: A,C,B,D

Example 4

  1. IF: A,B is a metadata group

    WHERE: A is the group leader and B is a group associate to A

  2. AND: B,A,C is another metadata group

    WHERE: B is the group leader and A and C are group associates to B

  3. RESULT: Theoretically, this situation can resolve to B,A,C but this makes the A,B grouping irrelevant. To avoid confusion for other groupings, this is treated as an error case.

Example 5

  1. IF: A,B,C is a metadata group

    WHERE: A is the group leader and B and C are group associates to A

  2. AND: D,A,E is another metadata group

    WHERE: D is the group leader and A and E are group associates to D

  3. RESULT: Error. It is impossible to resolve this grouping conflict.

3.2.3 Display Results of Reordered Metadata Fields

You can use content profiles to reorder metadata fields on the Check In, Update, Content Information, and Search pages. You can reorder custom metadata fields and system-specific information fields.

This section provides information about the display results of reordered custom and system information fields.

You can position metadata fields, as described in the following sections:

3.2.3.1 General Sequence of Grouped Metadata Fields

The positioning of grouped system and custom metadata fields on Oracle WebCenter Content Server pages is determined by the priority of the first metadata field in the group. When adding a custom metadata field to the system, its positioning sequence (field order) is set.

Add custom metadata fields using the Configuration Manager: Information Field Tab Screen and assign the sequence number in the Order field on the Add/Edit Metadata Field Screen.

When a custom metadata field is the first field in a group, that group is positioned on the page according to the field order assigned to the custom metadata field. When a system metadata field is the first field in a group, that group is positioned according to their established precedence.

Depending on the specific Oracle WebCenter Content Server page, you can include or exclude specified system metadata fields in the general display order. For example, the Search page displays the Release Date and Expiration Date system metadata fields but excludes Revision.

By default, the general order for system metadata fields is as follows:

  • Content ID (dDocName)

  • Type (dDocType)

  • Title (dDocTitle)

  • Author (dDocAuthor)

  • Security Group (dSecurityGroup)

  • Account (dDocAccount)

  • Revision (dRevLabel)

A group with a system metadata field as the first field is usually displayed in default order. For example, if Author is the first field in a group of custom metadata fields, that group is displayed below any group containing Content ID, Type, or Title as its first field.

3.2.3.2 Positioning Metadata Fields Within a Group

Section 3.2.2.5, "Using Rules to Group Metadata Fields" describes how to define rules to conveniently group custom and system metadata fields on the Check In, Update, Content Information, and Search pages. You can also order metadata fields using the following methods:

  • Option 1: Field Position: Use the Field Position list, available when adding metadata fields to rules using the Add Rule Field Screen. This option works in a relative manner. For example, you might add the following metadata fields:

    • xRegion (Top position)

    • xSubDept (Bottom position)

    If you add xDept with a field position of Middle, it is added as follows:

    • xRegion (Top position)

    • xDept (Middle position)

    • xSubDept (Bottom position)

    If you then add xContinent with a field position of Top, it is added as follows:

    • xRegion (Top position)

    • xContinent (Top position)

    • xDept (Middle position)

    • xSubDept (Bottom position)

    Similarly, if you add xManager with a field position of Middle, it is added as follows:

    • xRegion (Top position)

    • xContinent (Top position)

    • xDept (Middle position)

    • xManager (Middle position)

    • xSubDept (Bottom position)

    This option produces these display results on the Check In, Update, Content Information, and Search pages if the fields are grouped. When adding the fields to a rule, select Is Group on the Add/Edit Rule Screen.

  • Option 2: Up and Down buttons: Use the Up and Down buttons to reorder fields. This option is available when adding metadata fields to rules using the Fields tab. It is often useful to reorder fields after they are added, or to reorder fields with the same field position.

    For example, if you added three fields with a field position of Top, they are positioned in the order they were added to the rule. However, you can use the Up button to move a field to the absolute top. Similarly, if any field is not positioned properly when it was added, you can use the Up and Down buttons to reposition them.

3.2.3.3 Display Results of Grouped Metadata Fields

The following rules specify how metadata groups are displayed on the Check in, Update, and Check in Selected pages.

  • If the first field in a group is a system field (such as Content ID, Type, Title, and so on), the group is always displayed above the Primary File field.

  • If automatic Content ID generation is disabled, then the Content ID field is always listed as the first field on the page followed by the remaining fields in the group. Also, if a separate group includes other system fields like Title and Type, that group is listed after the Content ID group but above the Primary File field.

  • If automatic Content ID generation is enabled, then the Content ID field functions like a custom metadata field with 1 as its field order. In this case, if Content ID is the first field in a group, then the group is displayed immediately below the Primary File and Alternate File fields. Also, the Revision system metadata field is displayed after the last field in the Content ID group. (Note that, by default, Revision is displayed below the Alternate File field.)

  • If the first field of a group is a custom metadata field, then the group is ordered by the field order number of the lead metadata field relative to the lead metadata fields in other groups, even if there are system metadata fields in the group.

  • The Release Date and Expiration Date fields are always listed last on the page unless they are grouped with a custom metadata field that has a higher (that is, smaller number) field order value. Or, if Release Date and Expiration Date are grouped with a system metadata field, then they are listed above the Primary File field.

The following rules specify how metadata groups are displayed on the Search page.

  • The Content ID field is always positioned first unless it is part of a group and it is not the first field. However, if Content ID is the first field of a group, then that group is listed first.

  • If a system metadata field (other than Content ID) is the first field in a group, that group is listed after the Content ID field or Content ID group.

  • All other groups with custom metadata fields as the first fields are displayed after groups with system metadata fields as the lead fields. When groups have a custom metadata field as the first field, the ordering of these groups is determined by the field order numbers of the lead metadata fields of groups in relation to each other.

In order for a metadata field to be displayed on a search page, the Enable for Search Index must be set on the Add/Edit Metadata Field Screen.

The following rules specify how metadata groups are displayed on the Content Information page.

  • The Content ID field is always positioned first unless it is part of a group and it is not the first field.

  • The Checked Out By, Status, and Formats fields are always listed at the bottom.

  • The Security Group field, or any group with Security Group as the first field, is listed above the Checked Out By, Status, and Formats fields unless:

    • The account is disabled. If the account is enabled, then Security Group is displayed above the Checked Out By field. Security Group is displayed above the Account field.

    • The Security Group field is part of a group where it is not the first field, and the lead metadata field has a field order number that positions it above other custom metadata fields. In this case, the Security Group field is displayed in the order that is determined by the field order number of the group's lead metadata field.

  • The Release Date and Expiration Date fields are listed as part of the Revision History table at the bottom of the page.

  • All other groups with custom metadata fields as the first fields are displayed in the order that is determined by the field order numbers of the lead metadata fields of groups in relation to each other.

The following rules specify how metadata groups are displayed on the Folder Information page.

  • The Content ID field is not displayed unless it is part of a group. Currently, any group with Content ID as the first field is not displayed. Counteract this by defining another system or custom metadata field in the group as the lead field.

  • All the groups are listed that have system metadata fields as their lead field (provided their assigned display attribute is Edit, Label, or Required). If any system or custom metadata field is assigned a Hidden or Excluded display attribute, it is not displayed.

  • All other groups with custom metadata fields as the first fields are displayed in the order that is determined by the field order numbers of the lead metadata fields of groups in relation to each other.

3.2.3.4 Moving Fields

Follow these steps to force any custom metadata field to display above the Primary File field:

  1. Add the custom metadata field to a group that includes system metadata fields.

  2. Make the first field in the group a system metadata field. Group position is based on which system metadata field is the lead field.

To force any system metadata field to display below the Primary File field:

  1. Add the system metadata field to a group that includes custom metadata fields.

  2. Ensure that the first field in the group is a custom metadata field.

    The group is displayed below the Primary File field based on the field order number of the lead field.

3.2.4 Managing Rules

The following tasks are included in rule management:

3.2.4.1 Creating or Editing a Rule

To create a rule:

  1. Choose Administration then Admin Applets. Click Configuration Manager then the Rules tab.

    The Configuration Manager: Rules Tab Screen opens.

  2. Click Add.

    The Add/Edit Rule Screen opens. Click the General tab.

  3. Enter the name and description information about the new rule.

    Click OK.

To edit a rule, select the rule from the list on the Configuration Manager: Rules Tab Screen and click Edit. Edit the field values and click OK when done.

To delete a rule, select the rule from the list on the Configuration Manager: Rules Tab Screen and click Delete. Click OK to verify the deletion.

3.2.4.2 Creating, Editing, or Deleting a Global Rule

To create a global rule:

  1. Choose Administration then Admin Applets. Click Configuration Manager then the Rules tab.

    The Configuration Manager: Rules Tab Screen opens.

  2. Click Add to create a global rule or highlight a rule and click Edit to change a rule to a global rule or edit an existing global rule.

    The Add/Edit Rule Screen opens. Click the General tab.

  3. Select Is global rule with priority.

  4. Change the default priority number (optional). By default, 10 is the priority number listed. If editing a rule, change other information as needed. A lower priority rule is executed before higher priority rules which higher priority rules to override the changes made by lower priority rules.

  5. Click OK.

To edit a rule, select the rule from the list on the Configuration Manager: Rules Tab Screen and click Edit. Edit the field values and click OK when done.

To delete a rule, select the rule from the list on the Configuration Manager: Rules Tab Screen and click Delete. Click OK to verify the deletion.

3.2.4.3 Adding Metadata Fields in a Rule

To add metadata fields to a rule:

  1. Choose Administration then Admin Applets. Click Configuration Manager then the Rules tab.

    The Configuration Manager: Rules Tab Screen opens.

  2. Click Add to create a global rule or highlight a rule and click Edit to change a rule to a global rule or edit an existing global rule.

    The Add/Edit Rule Screen opens.

  3. Click the Fields tab and click Add.

    The Add Rule Field Screen opens.

  4. Select the following information:

    • Display Information Field check box and Display Application Fields check box: if selected, lists metadata fields in the field names list, making fields available for display on standard check-in and search pages.

    Note that if an application field is selected for display in a rule, the field's behavior (as defined for the application that normally uses the field) is changed.

  5. Select a field name from the list.

  6. Select a general placement choice for the metadata field from the Field Position list for each metadata field added. The selected option adjusts the general placement order of the metadata fields in the list on the Add/Edit Rule Screen, Field Tab. The position of each field is relevant to its priority in the evaluation process. You can use the Up or Down buttons to further refine the placement.

    • Top: Moves the metadata field to a relatively higher position.

    • Middle: Moves the metadata field to a relatively central position.

    • Bottom: Moves the metadata field to a relatively lower position.

  7. Click OK.

    The Add/Edit Rule Field 'name' Screen opens.

  8. Enter the following display information about each metadata field which determines how the metadata field is displayed on Check In and Search pages:

    • Edit: The field is editable even if a default value is provided.

    • Label: The field is read-only (fixed but displayed).

    • Hidden: The field does not display but when the user submits a content item, this metadata field value remains on the source page.

    • Excluded: The field does not display. Unlike a hidden metadata field, an excluded value does not remain on the source page.

    • Required: A required field. If this is used, a message is also required.

  9. Custom Label: Specify a label for the field. You can use different labels in different profiles.

  10. Use Custom Include: Used to reposition standard fields. For example, creating a group that includes a placeholder field and the title field moves the title field below the other standard fields on the page. A custom include can then be used for the placeholder field to control how or if it is displayed. Provided files are:

    • Standard Separator: Places a standard horizontal rule on the page where the field otherwise would be.

    • Display Nothing: hides the field when the page opens.

    If checked, allows the use of custom fields. Default: deselected.

    The standard include options listed in the Start Include and End Include lists are defined in the DpDisplayIncludes table of the std_resources.htm file. To add additional include options, a custom component must be written defining the new includes and merging them into the DpDisplayIncludes table.

  11. Exclude field from the group count: Prevents the group header from being displayed while keeping the presentation properties of the placeholder field. If the number of fields in a group is greater than zero, then the group header is displayed. For example, a placeholder field used for presentation purposes is the only field in a group that is displayed. Default: deselected.

  12. Use Default Value: Allows display of a default value on the Content Check In page or the Search page. Default values are computed for On Request events. You can use Idoc Script, or schema values if the metadata field is associated with a schema view.

    If selected, the Edit button is activated and the text pane becomes active, displaying the computed Idoc Script for the field (automatically generated after the default value is added and its properties defined). If unselected, (default), default values cannot be used.

  13. Is Derived: Enables the field to be set to a specified value on update or check-in. Values are computed for On Submit and On Import events. You can use Idoc Script, or schema values if the metadata field is associated with a schema view.

    If selected, the Edit button is activated and the text pane becomes active, displaying the computed Idoc Script for the field (automatically generated after the value is added and its properties defined). If unselected (default), default values cannot be used.

  14. Has Restricted List: Enables the field to be restricted to either a specific list of values or to a filtered list of values.

    If selected, the Edit button is activated and the text pane becomes active, displaying the computed Idoc Script for the field (automatically generated after the list is added and its properties defined). If unselected (default), default values cannot be used.

  15. Click OK when done specifying the attributes of the rule.

  16. For each metadata field to be added to the rule, repeat steps 4 through 15.

To group metadata fields and add a header to a group:

  1. Choose Administration then Admin Applets. Click Configuration Manager then the Rules tab.

    The Configuration Manager: Rules Tab Screen opens.

  2. Highlight a rule and click Edit.

    The Add/Edit Rule Screen opens.

  3. On the General tab, select Is group.

  4. Select Has Group Header.

  5. Click Edit.

    The Edit Group Header Screen opens. Provide the following information:

    • Enable Hiding: If selected, group metadata fields are hidden and a link appears on the page instead of the fields. Pressing the Show link shows the fields. The default is to display the pages with a Hide link, meaning all fields are displayed by default.

    • Start and End Include: Specifies how to display the group. Options include:

      • Standard Separator: Inserts a rule above or below the group

      • Start/End HTML Table: Displays the group in an HTML table with borders for each row and the header.

      • Display Nothing: (default): No distinction is made for the group.

    • Header Text: The header string associated with the group of fields.

  6. Click OK when done.

3.2.4.4 Adding, Editing or Deleting Activation Conditions in Rules

Follow these steps to add an activation condition to a rule:

  1. Choose Administration then Admin Applets. Click Configuration Manager then the Rules tab.

    The Configuration Manager: Rules Tab Screen opens.

  2. Highlight a rule and click Edit to add a condition to a rule or click Add to add a new rule.

    The Add/Edit Rule Screen opens.

  3. Click the General tab then select Use Rule Activation Condition.

  4. Click Edit. The Edit Activation Condition Screen opens.

  5. Click Add. In the dialog that opens, enter the name and click OK. The General tab opens.

  6. Enter the following information using the General pane and Clauses pane. For details, see Section 3.2.4.5, "Custom Conditions and Side Effects."

    The following options are available on the General pane:

    • Use Event check box: If selected, rules can perform differently when events are detected. Events include the following:

      • On Request: Includes an event that results from a user request to view an Oracle WebCenter Content Server page.

      • On Submit: Includes an event that results from a contribution action.

      • On Import: Includes an event that results from a batch loading or archive procedure. The rule is only active for archiver, batch loading, or any other process that uses a special check-in service (for example, Content Publisher).

    • Use Action: If selected, rules can perform differently when user actions are detected by the system. User actions include the following (for example, when new contributions are checked in or when a content item is revised):

      • Check in new: Includes the user action of contributing a new content item.

      • Check in selected: Includes the user action of submitting a revision to an item.

      • Content information: Includes the user action of requesting to view the document information page.

      • Content update: Includes the user action of submitting revisions to the document information page.

      • Search: Includes the user action of requesting to view the search page.

    • Workflow flag: Enables a rule to perform differently based on the workflow state of a document. For example, when a document is in a workflow, it displays a different Content Information page.

    The following options are available on the Clauses pane. This pane is an Idoc Script wizard used to automate the process of creating Idoc Script statements:

    • Field List: A list of metadata options.

    • Operator List: The method used for searching metadata fields, including the following:

      • Matches: The entire text within the specified metadata field contains the specified metadata Value.

      • Contains Word: The text within the specified metadata field contains the metadata Value.

      • Begins With: The text within the specified metadata field starts with the metadata Value.

      • Is Date Before: The date in the specified metadata field occurs before the Value date.

      • Is Date After: The date in the specified metadata field occurs after the Value date.

    • Value Field: You can select an editable field to enter data, a list of options, or an editable field that activates the Select button. If the field value is Content ID, pressing Select opens the Custom pane. If the field is author, a selection screen of users opens.

  7. When done configuring the conditions, click Add to add the condition to the Clause pane.

  8. Click OK.

To edit an activation condition, follow the previous steps and on the Conditions tab, select the activation condition to edit from the list. Edit the field values and click OK when done.

To delete an activation condition, follow the previous steps and on the Conditions tab, select the activation condition from the list and click Delete. Click OK to confirm the deletion.

3.2.4.5 Custom Conditions and Side Effects

The Custom tab of the Edit Activation Condition Screen is used to define specific conditions for a rule that, when met, affect the behavior of the profile.

To use this screen, click the Custom tab then enter customized text in the text pane. Information that is entered is displayed in the text pane on the Add/Edit Rule Screen.

To define side effects, click the Side Effects tab on the Edit Activation Condition Screen. The Side Effects screen is used to:

  • Easily add name-value pairs as Idoc Script variables that get pushed to local data using Idoc Script if the activation condition is true.

  • Add custom Idoc Script to a rule that is only evaluated if the activation condition is true.

Because the side effect is Idoc Script and evaluated when a rule is activated, you can also include logical statements such as like if, elseif, and else, and can execute any Idoc Script function. For example, you can establish a rule that can control the activation of other rules. For more information scripting in Idoc Script, see the Oracle WebCenter Content Idoc Script Reference Guide.

Add the following information on this screen:

  • Key: the name used as the Idoc Script variable.

  • Value: a literal string that equates to the variable.

Click Add when done. The key and value are converted to Idoc Script and are displayed in the editing pane, where you can edit the text.

3.2.4.6 Setting Default Values, Derived Values and Restricted Lists

Follow these steps to set a default value field or a derived value field:

  1. In step 12 or step 13 of the Adding Metadata Fields in a Rule task, select the appropriate check box. Click Edit.

    The appropriate screen opens.

  2. On the Conditions tab, click Add.

    In the screen that opens, enter a name for this value attribute and click OK. The name is added to the Conditions list.

  3. Select a Field value and Operator from the lists. Depending on the selected value from the Field list, the Value field provides:

    • An editable field to enter the data.

    • A list of appropriate options.

    • An editable field with a corresponding Select button.

  4. Enter or select a value for the upper Value field, as applicable:

    1. Click Select. If:

      The Field value is Content ID, the Edit Default/Derived Value: Select Field Screen opens. Select a field for use.

      The Field value is Author, the User View Screen opens. Select a user.

    2. Use the filters to select content. When finished, click OK.

    The screen closes and the selected content value is added to the upper Value field on the default value Conditions tab.

  5. Click Add.

    The statement is added to the expression pane.

  6. Click Compute.

    The Edit Default/Derived Value: Select Field Screen opens.

  7. If the field is linked to a schema view, select a column. Otherwise, click OK.

    The Select Field screen closes and the computed value is added to the lower Value field on the default value Conditions tab.

  8. Click OK.

    The screen closes and the Idoc Script statement is displayed in the default value text pane on the Add/Edit Rule Field 'name' Screen.

  9. If finished adding metadata field attributes, click OK. Otherwise, continue to include additional attributes.

To use a restricted list for the metadata field:

  1. In step 14 of the Adding Metadata Fields in a Rule task, select Has Restricted List. Click Edit.

    The Edit Restricted List Screen opens.

  2. To use a list of values directly associated with rules, select Is Filtered List. To use a list of specific values, select Is Strict List and enter the specific items in the Restricted Value text pane.

  3. Click OK.

    The Edit Restricted List screen closes. If the strict list option is used, the items are displayed in the text pane on the Add/Edit Rule Field 'name' Screen.

3.2.4.7 Editing Default or Derived Values and Restricted Lists

To edit the attributes of a metadata field:

  1. Choose Administration then Admin Applets. Click Configuration Manager then the Rules tab.

    The Configuration Manager: Rules Tab Screen opens.

  2. Click Add to create a global rule or highlight a rule and click Edit to change a rule to a global rule or edit an existing global rule.

    The Add/Edit Rule Screen opens.

  3. Open the Fields tab and select the metadata field with attributes to edit. Click Edit.

    The Add/Edit Rule Field 'name' Screen opens.

  4. Click the corresponding Edit button of the attribute to edit. The appropriate screen opens.

  5. For either the default value or derived value, select the value to edit in the Conditions text pane.

    1. Select the new Field, Operator or both field values.

    2. To edit the upper Value field value without deleting and redefining the clause, highlight the clause in the Clause pane. Edit the value in the upper Value field, then click Update.

    3. Click Compute.

    4. Click OK.

      The screen closes and the revised values are displayed.

  6. For the restricted list attribute, on the Edit Restricted List screen, select the list option and edit the text pane as needed. Click OK.

    The screen closes and the revised list information is displayed.

  7. Click OK.

3.2.4.8 Setting the Display of a Required Field

Two configuration variables control how required metadata fields appear on the Check In page. For more information, see the Oracle WebCenter Content Idoc Script Reference Guide.

  • To use red lettering for a required field, use the following configuration variable and value:

    StyleForRequiredFields=requiredField

  • To mark the required field with any symbol, use the following configuration variable and value:

    NotationForRequiredFields=*

    Note: In this example, an asterisk is used to mark the required fields.

3.2.5 Content Profile Triggers

A trigger field is a metadata field defined on the Configuration Manager: Profiles Tab Screen. If a document matches a trigger value for a profile, then that profile is evaluated for the document.

An unlimited number of profiles can exist, but only one trigger value per profile is allowed. For example, if the trigger field is dDocType, Profile1 can use the trigger value of ADACCT and Profile2 can use the trigger value of ADSALES.

The following are true for the selected trigger:

  • The trigger field must be a list metadata field. Metadata fields defined as lists are included in the trigger field list.

  • After you define the trigger field, you cannot delete it from the system. An Administrator can reset the trigger field to 'none specified', however this disables all profiles.

  • If you can change the trigger field, you may invalidate some profiles and have to resolve the situation. User interface hints are provided concerning which profiles are invalid.

    Note:

    Although you create rules before you create triggers and profiles, it is necessary to know what your trigger is before creating rules.

3.2.5.1 Selecting a Profile Trigger Field

You can select only one trigger field for each Oracle WebCenter Content Server instance.

Follow these steps to select or change the current profile trigger field:

  1. Choose Administration then Admin Applets from the Main menu. Click Configuration Manager then the Profiles tab.

    The Configuration Manager: Profiles Tab Screen opens.

  2. Click Select.

    The Edit Trigger Field Screen opens.

  3. Select a new trigger field from the list in the Field Name field.

    Click OK.

If you change the trigger field after one or more profiles are created, the new trigger field could cause the existing profiles to become invalid.

3.2.5.2 Disabling a Profile Trigger Field

Follow these steps to completely disable the trigger field (essentially disabling all profiles as well):

  1. Choose Administration then Admin Applets from the Main menu. Click Configuration Manager then the Profiles tab.

    The Configuration Manager: Profiles Tab Screen opens.

  2. Click Select.

    The Edit Trigger Field Screen opens.

  3. Select none specified from the list in the Field Name field.

  4. Click OK.

3.2.6 Creating and Using Content Profiles

This section discusses the tasks involved in creating and using a profile. It covers these topics:

3.2.6.1 Creating, Editing, or Deleting a Profile

Follow these steps to create a new profile:

  1. Choose Administration then Admin Applets from the Main menu. Click Configuration Manager then the Profiles tab.

    The Configuration Manager: Profiles Tab Screen opens.

  2. Click Add. A dialog opens where you can add a name.

  3. Enter the name of the new profile and click OK.

    The Add/Edit Profile Screen opens.

  4. Enter the following information:

    • Display label: Text for the profile on the My Checkin and My Search menu options.

    • Description: brief description of the profile.

    • Trigger list: the list values associated with the trigger.

    • Exclude non-rule fields: Select to exclude all metadata fields that do not belong to the rules included in the profile.

    • Restrict personalization: Select to suppress checkin or search links to a particular user or group of users. Idoc Script code based on user information is entered into the Profile Links Screen and must evaluate to true before a link is displayed. If deselected (default), all links are displayed for all users by default unless evaluated by another profile. Click Edit to customize the list of users.

  5. Click Add to include rules in the new profile.

    The Add Rule in Profile Screen opens.

    Note:

    You cannot add rules to the profile until you create and define them using the Configuration Manager: Rules Tab Screen.

  6. Select rules from the list and assign them a general placement priority value.

    Adjust the placement order of the rules in the list by pressing the Up or Down button. The position of each rule in the list is relevant to its priority in the evaluation process. The general position (top, middle, or bottom) in the list is established when the rule is initially added to the profile. The buttons further refine the placement by moving the rule to a more precise position.

  7. Click OK.

    The new profile is included in the Profiles list on the Profiles tab.

To edit a profile, select the profile on the Configuration Manager: Profiles Tab Screen and click Edit. Change the fields as needed and click OK.

To add or edit rules to a profile, select the profile on the Configuration Manager: Profiles Tab Screen and click Edit. Click Add and select a rule and rule placement from the Add Rule in Profile Screen. Click OK when done.

To delete a profile, select the profile on the Configuration Manager: Profiles Tab Screen and click Delete. Click OK to verify the deletion.

3.2.6.2 Previewing a Profile

Follow these steps to review a profile:

  1. Choose Administration then Admin Applets from the Main menu. Click Configuration Manager then the Profiles tab.

    The Configuration Manager: Profiles Tab Screen opens.

  2. Select the profile to be previewed from the Profiles list, and click Preview.

    The Preview Profile Screen opens.

  3. Select options for use in the profile:

    • Event list: Specifies when an event is included in the profile evaluation.

      • none specified: An event is not included.

      • On Request: Includes an event that results from a user request to view an Oracle WebCenter Content Server page.

      • On Submit: Includes an event that results from a contribution action.

      • On Import: Includes an event that results from a batch loading or archive procedure. The rule is only active for archiver, batch loading, or any other process that uses a special check-in service (for example, Content Publisher).

    • Action list: Specifies when an action is included in the profile evaluation.

      • none specified: A user action is not included in the profile evaluation.

      • Check in new: Includes the user action of contributing a new content item.

      • Check in selected: Includes the user action of submitting a revision to an item.

      • Content information: Includes the user action of requesting to view the document information page.

      • Content update: Includes the user action of submitting revisions to the document information page.

      • Search: Includes the user action of requesting to view the search page.

    • Is workflow list: Specifies when a workflow is included in the evaluation.

      • none specified: A workflow state is not included in the evaluation. The document is or is not in a workflow, but its workflow state is not specified.

      • Yes: The document is in a workflow.

      • No: The document is not in a workflow.

    • Content ID: The content used in the evaluation based on the filter criteria.

    • User name: The user name used in the evaluation.

  4. To review the compiled results of the current profile, do not change any field values on the Preview Profile screen. Click Compute results.

    The Preview Results Screen opens.

  5. To view the page as an end user sees it, make the following selections:

    • Select On Request as the Event field value

    • Select an Action value

    • Leave the User Name field blank

    Click Show.

  6. Review the computed results and click OK.

3.2.6.3 Troubleshooting a Profile

The Preview Profile Screen is also used to troubleshoot invalid profiles and perform analysis on any profile.

Troubleshooting using what-if scenarios is an iterative process, composed of trying combinations of inputs to evaluate the profile's rules. In addition to using different input values, you can also use filtered selections of documents.

Changing the different criteria (with or without filters) and computing the results shows how various input combinations affect the evaluation of rules. When the system evaluates the profile's rules, the computed results are displayed either as script string statements (SQL or Idoc Script) in a standard dialog text pane or as simulated Check In or Search pages (if you select On Request as the Event field value). Using the flexibility of the what-if analysis process helps to debug and optimize profiles.

To perform what-if scenarios using diverse combinations of inputs and filters:

  1. Select the profile to be reviewed and tested from the Profiles list, and click Preview.

    The Preview Profile Screen opens.

  2. Select field values, as applicable, from the Event, Action, and Is workflow lists.

  3. To include filtered choices for the Content ID field, click the corresponding Select button.

    The Content Item View Screen opens.

  4. Select content item filter options, as applicable, and click OK. The Preview Profile screen opens.

  5. To include filtered choices for the User Name field, click the corresponding Select button.

    The User View Screen opens.

  6. Select user filter options, as applicable, and click OK. The Preview Profile screen opens.

To view the evaluated rules as coded statements, click Compute Results.

To evaluate results as a simulated page in a browser window, click Request in the EVent field. Select other field values then click Show on the Preview Profile Screen. The system launches a browser window that displays the resulting metadata fields in a simulated Check In or Search page. This window provides a graphic view or what the end user sees.

3.2.7 Content Profile Examples

The following profile examples illustrate several scenarios in which profiles are useful:

3.2.7.1 Department-Based Content Profile

This example shows how to plan and create a department-based profile that includes one global rule and one regular profile rule.

The goal is to control how the metadata fields governed by the rules are displayed on the Check In, Update, Content Information, and Search pages. Ideally, only department-specific fields are displayed to minimize the number of metadata fields that users see.

This example creates the applicable rules first then the profile because the rules are added to the profile during the process of creating the actual profile. It is divided into the following main steps:

  • Create a global rule with the following characteristics:

    • Ensure that all new and updated content items checked in have comments associated with them. The optional comments metadata field is revised to be a required field.

    • Allow the content item title metadata field to be editable.

  • Create a profile rule with the following characteristics:

    • Provide a default value for the comments metadata field but also allow it to be editable. The default message is triggered by marketing-specific documents.

    • Provide default values that are read-only text for the publish type and revision label metadata fields.

  • Create a department-based profile with the characteristics:

    • Organize the metadata fields that are hidden or displayed on the Check In, Update, Content Information, and Search pages.

    • Display only those fields that are relevant to the marketing department.

    • Group selected metadata fields using a marketing-based group heading.

Create the Global Rule

  1. Open the Rules tab on the Configuration Manager Page and click Add.

    The Add/Edit Rule Screen opens.

  2. On the General tab, enter the name of the global rule in the Name field (for example, CmtsRqd).

  3. Enter a description for the global rule (optional).

  4. Select Is global rule with priority. You can also change the priority number.

  5. Add and define the Comments metadata field as follows:

    1. On the Fields tab, click Add.

      The Add Rule Field Screen opens.

    2. Select Comments from the Field Name list.

    3. Select a general position from the Field Position list (for example, top).

    4. Click OK.

      The Add/Edit Rule Field 'name' Screen opens.

    5. Select Required from the Type list to ensure that users must enter a comment about the content item being checked in.

    6. Enter text in the Required Message field. This is optional for all rule field types except the Required type.

    7. Select Use default value and click the corresponding Edit button.

      The Edit Default/Derived Value Screens opens.

    8. On the Conditions tab, click Add.

      The Add Condition screen opens.

    9. Enter the name of the field condition (for example, UserMsg).

    10. Click OK.

      The screen closes and the clause-generating fields display on the lower pane of the Conditions tab.

    11. Enter a short statement in the lower Value field, at the far bottom of the screen near the Compute button. This statement becomes the default value for the Comment field.

    12. Click OK.

      The screen closes and the default value Idoc Script clause for the UserMsg field condition is added to the Default Value text pane.

    13. Click OK.

      The screen closes and the Comments metadata field is added to the Fields list.

  6. Add and define the Document Title metadata field as follows:

    1. On the Fields tab of the Add/Edit Rule screen, click Add.

    2. Select Title from the Field Name list.

    3. Select a general position from the Field Position list (for example, bottom).

    4. Click OK.

    5. Select Edit from the Type list to allow this metadata field to be editable on the Check In and Search pages.

    6. Enter a note in the Required Message field (optional).

    7. Click OK.

      The Title metadata field is added to the Fields list.

  7. Click OK.

    The screen closes.

Create the Profile Rule

  1. On the Rules tab, select Add.

  2. On the General tab, enter the name of the profile rule in the Name field (for example, DefaultMktComment).

  3. Enter a description for the profile rule (optional).

  4. Select Is group.

  5. Select Has group header, and click the corresponding Edit button.

    The Edit Group Header Screen opens.

  6. Enter the text to use as the header for the grouped metadata fields (for example, Marketing-Specific Information).

  7. Click OK.

  8. Add and define the Comments metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Comments from the Field Name list.

    3. Select a general position from the Field Position list (for example, top).

    4. Click OK.

    5. Select Edit on the Type list, allowing this field to be editable on the Check In, Update, Content Information, and Search pages.

    6. Enter a note in the Required Message field (optional).

    7. Select Use default value and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, CurrentMktgDocs).

    10. Click OK.

    11. Enter These are Current Marketing Docs into the lower Value field at the bottom of the screen (near the Compute button).

    12. Click OK.

      The default value Idoc Script clause for the field condition is added to the Default Value text pane.

    13. Click OK.

      The Comments metadata field is added to the Fields list.

  9. Add and define the Publish Type metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Publish Type from the Field Name list.

    3. Select a general position from the Field Position list (for example, middle).

    4. Click OK.

    5. Select Label from the Type list to make this a read-only field on the Check In, Update, Content Information, and Search pages.

    6. Enter a note in the Required Message field (optional).

    7. Select Use default value and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, MktgDocsOnly).

    10. Click OK.

    11. Enter @dDocName into the lower Value field at the bottom of the screen near the Compute button.

    12. Click OK.

      The default value Idoc Script clause for the MktgDocsOnly field condition is added to the Default Value text pane.

    13. Click OK.

      The Publish Type metadata field is added to the Fields list.

  10. Add and define the Revision Label metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Revision from the Field Name list.

    3. Select a general position from the Field Position list (for example, bottom).

    4. Click OK.

    5. Select Label from the Type list to make this a read-only metadata field on the Check In, Update, Content Information, and Search pages.

    6. Enter a note in the Required Message field (optional).

    7. Select Use default value.

    8. Click OK.

      The Revision Label metadata field is added to the Fields list.

  11. Click OK.

    The screen closes.

Create the Department-Based Profile

  1. Open the Profiles tab on the Configuration Manager Page and click Select.

    The Add Profile Screen opens.

  2. Select Type from the Field Name list.

  3. Click OK.

  4. Click Add on the Profiles tab.

    The Add Profile Screen opens.

  5. Enter the name of the profile (for example, MktgDoc).

  6. Click OK.

    The Add/Edit Profile Screen opens.

  7. Enter the profile description in the Description field (for example, Current Mktg docs).

  8. Enter a descriptive label for the profile (for example, MarketingSpecific).

  9. Select ADMKT (or an equivalent marketing option) from the Trigger list.

  10. Click Add to include the rules in this profile.

    The Add Rule in Profile Screen opens.

  11. Select DefaultMktComment from the Name list.

  12. Select a general priority placement from the Rule Priority list (for example, top).

  13. Click OK.

  14. Click Add.

  15. Click OK.

  16. Click OK.

The screen closes and the profile is added to the list of profiles on the Profiles tab.

3.2.7.2 Black-Hole Resume Check In

This example shows how to plan and create a black-hole check in profile used to submit resumes to Human Resources. The goal is to restrict the visible metadata fields available on the Check In, Update, Content Information, and Search pages when using this profile.

After a resume is initially checked in, the derived settings for all the potentially searchable metadata fields prevent unauthorized users from retrieving the document. This example creates the applicable rules first then the profile because the rules are added to the profile during the process of creating the actual profile.

This example is based on the default metadata fields displayed using a non-customized Oracle WebCenter Content Server instance. The visible metadata fields in this profile are limited to Type, Primary File, Alternate File, and Comments. The Type field uses a read-only label. On submission the value is reset to an HR-accessible value to ensure confidentiality of the document. Only the Comments field is editable. The remaining metadata fields are hidden and on submission also have their values reset. In this example, the hidden metadata fields include Title, Author, Security Group, Content ID, Revision, Release Date, and Expiration Date.

If selected, both the Hidden and Excluded display attributes conceal the defined metadata field. Using the Hidden type has the advantage of allowing the field value to remain on the source page. Thus, the contributor does not see the Hidden fields when checking in the document, but the assigned field values are still visible to an authorized viewer. The Excluded type precludes the field values on the source page.

In this type of profile, it is inadvisable to depend on the Exclude non-rule fields check box to hide unnecessary metadata fields. Contributors see only the fields included in the profile's rules, however, it does not prevent default values from being assigned and stored on the source page. Unauthorized users could find a black-hole document by searching on the excluded metadata fields.

This example is divided into the following main steps:

  • Create a profile rule that:

    • Hides non-essential metadata fields and does not display them on the Check In, Update, Content Information, and Search pages.

    • Resets the default values of each hidden metadata field to ensure that unauthorized users cannot search and retrieve documents using the hidden fields.

  • Create a profile rule that:

    • Allows the display of specific metadata fields related to checking in a resume.

    • Resets the values of each visible metadata field to ensure that unauthorized users cannot search and retrieve documents using these fields.

  • Create a black-hole check-in profile that:

    • Restricts the metadata fields that are hidden or displayed on the Check In, Update, Content Information, and Search pages.

    • Displays only those fields that are relevant to an employee who is checking in a resume for an internal company position.

Create Rule for Hidden Fields

Follow these steps to create a profile rule for hidden metadata fields:

  1. Open the Rules tab on the Configuration Manager Page and click Add.

    The Add/Edit Rule Screen opens.

  2. On the General tab, enter the name of the rule in the Name field (for example, NoExtraFields).

  3. Enter a description for the global rule (optional).

  4. Add and define the Title metadata field as follows:

    1. On the Fields tab, click Add.

      The Add Rule Field Screen opens.

    2. Select Title from the Field Name list.

    3. Select a general position from the Field Position list.

    4. Click OK.

      The Add/Edit Rule Field 'name' Screen opens.

    5. Select Hidden from the Type list to ensure this metadata field does not appear on the Check In, Update, Content Information, and Search pages.

    6. Enter text in the Required Message field (optional).

    7. Select Is derived field and click the corresponding Edit button.

      The Edit Derived Value: Conditions Tab opens.

    8. On the Conditions tab, click Add.

      The Add Condition screen opens.

    9. Enter the name of the field condition (for example, HRsEyesOnly).

    10. Click OK.

      The screen closes and the clause-generating fields appear on the lower pane of the Conditions tab.

    11. In the lower Value field, enter a confidential string (for example, No specific title) to help prevent unauthorized users from searching with the Title field to retrieve the documents checked in using this profile.

    12. Click OK.

      The screen closes and the computed Idoc Script clause is added to the derived field text pane.

    13. Click OK.

      The screen closes and the Title metadata field is added to the Fields list.

  5. Add and define the Author metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Author from the Field Name list.

    3. Select a general position from the Field Position list.

    4. Click OK.

    5. Select Hidden from the Type list (to ensure that this metadata field does not display on the Check In, Update, Content Information, and Search pages).

    6. Enter text in the Required Message field (optional).

    7. Select Is derived field and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly2).

    10. Click OK.

    11. Select Author from the Field list.

    12. Select Matches from the Operation list.

    13. Click Select.

      The User View Screen opens. Select the applicable user name. For example, select an HR employee authorized to view the documents checked in with this profile to ensure that unauthorized users cannot search and retrieve these documents using the Author metadata field.

    14. Click OK.

      The screen closes and the selected user is entered in the upper Value field.

    15. Click Add.

      The clause is added to the clause pane.

    16. Click OK.

    17. Click OK.

  6. Add and define the Security Group metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Security Group from the Field Name list.

    3. Select a general position from the Field Position list.

    4. Click OK.

    5. Select Hidden from the Type list to ensure that this field does not appear on the Check In, Update, Content Information, and Search pages).

    6. Enter text in the Required Message field (optional).

    7. Select Is derived field and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly3).

    10. Click OK.

    11. Select Security Group from the Field list.

    12. Select Matches from the Operation list.

    13. Select an applicable choice from the Value list. For example, select HR or any other department that is authorized to view the documents checked in using this profile.

    14. Click Add.

    15. Click OK.

    16. Click OK.

  7. Add and define the Content ID metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Content ID from the Field Name list.

    3. Select a general position from the Field Position list.

    4. Click OK.

    5. Select Hidden from the Type list to ensure that this field does not appear on the Check In, Update, Content Information, and Search pages.

    6. Enter text in the Required Message field (optional).

    7. Select Is derived field and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly4).

    10. Click OK.

    11. Select Content ID from the Field list.

    12. Select Begins With from the Operation list.

    13. Enter a confidential string or click Select.

      The Select Field screen opens. Select a content item from the list. For greater security, enter a unique string (for example, Res) to help ensure that unauthorized users cannot search and retrieve these documents using the Content ID metadata field.

    14. Click OK (if you selected a content item from the Content Item View Screen).

    15. Click Add.

    16. Click OK.

    17. Click OK.

  8. Add and define the Revision metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Revision from the Field Name list.

    3. Select a general position from the Field Position list.

    4. Click OK.

    5. Select Hidden from the Type list (to ensure that this metadata field does not display on the Check In, Update, Content Information, and Search pages).

    6. Enter text in the Required Message field (optional).

    7. Select Is derived field and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly5).

    10. Click OK.

    11. Select Revision from the Field list.

    12. Select Begins With from the Operation list.

    13. Enter a confidential string in the upper Value field (for example, Res) to ensure that unauthorized users cannot search and retrieve these documents using the Revision metadata field.

    14. Click Add.

    15. Click OK.

    16. Click OK.

  9. Add and define the Release Date metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Release Date from the Field Name list.

    3. Select a general position from the Field Position list.

    4. Click OK.

    5. Select Hidden from the Type list to ensure that this field does not appear on the Check In, Update, Content Information, and Search pages.

    6. Enter text in the Required Message field (optional).

    7. Select Is derived field and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly6).

    10. Click OK.

    11. In the lower Value field, enter a confidential string (for example, No specific release date) to prevent unauthorized users from using the Release Date field to retrieve the documents checked in using this profile).

    12. Click OK.

    13. Click OK.

  10. Add and define the Expiration Date metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Expiration Date from the Field Name list.

    3. Select a general position from the Field Position list.

    4. Click OK.

    5. Select Hidden from the Type list to ensure that this field does not display on the Check In, Update, Content Information, and Search pages.

    6. Enter text in the Required Message field (optional).

    7. Select Is derived field and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly7).

    10. Click OK.

    11. In the lower Value field, enter a confidential string (for example, No specific expiration date) to help prevent unauthorized users from using the Expiration Date metadata field to search for and retrieve the documents checked in using this profile).

    12. Click OK.

    13. Click OK.

  11. Click OK.

    The screen closes.

Create Rule for Visible Fields

Follow these steps to create a profile rule for visible metadata fields:

  1. On the Rules tab, select Add.

  2. On the General tab, enter the name of the profile rule in the Name field (for example, VisibleFields).

  3. Enter a description for the profile rule (optional).

  4. Add and define the Type metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Type from the Field Name list.

    3. Select a general position from the Field Position list.

    4. Click OK.

    5. Select Label from the Type list to make this a read-only metadata field on the Check In, Update, Content Information, and Search pages.

    6. Enter text in the Required Message field (optional).

    7. Select Use default value and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, ResumeType).

    10. Click OK.

    11. In the lower Value field, enter Resume.

    12. Click OK.

    13. Select Is derived field and click the corresponding Edit button.

    14. On the Conditions tab, click Add.

    15. Enter the name of the field condition (for example, ResumeType2).

    16. Click OK.

    17. In the lower Value field, select an appropriate document type from the Value list (for example, HRresumes).

    18. Click OK.

    19. Click OK.

  5. Add and define the Comments metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Comments from the Field Name list.

    3. Select a general position from the Field Position list.

    4. Click OK.

    5. Select Edit from the Type list to allow this metadata field to be editable on the Check In, Update, Content Information, and Search pages.

    6. Select Use default value and click the corresponding Edit button.

    7. On the Conditions tab, click Add.

    8. Enter the name of the condition (for example, PositionAppliedFor).

    9. Click OK.

    10. In the lower Value field, enter an appropriate statement (for example, Please specify the position title).

    11. Click OK.

    12. Click OK.

    13. Click OK.

Create the Profile

To create the black-hole checkin profile:

  1. Open the Profile tab on the Configuration Manager Page and click Select.

    The Add Profile Screen opens.

  2. Select Type from the Field Name drip down list.

  3. Click OK.

  4. Click Add on the Profiles tab.

    The Add Profile Screen opens.

  5. Enter the name of the profile (for example, BlackHoleResumeCheckIn).

  6. Click OK.

    The Add/Edit Profile Screen opens.

  7. Enter the profile description in the Description field (for example, For internal user resumes only).

  8. Select HRresumes (or the equivalent option) from the Trigger list.

  9. Click Add to include the rules in this profile.

    The Add Rule in Profile Screen opens.

  10. Select the NoExtraFields rule from the Name list.

  11. Select a general priority placement from the Rule Priority list.

  12. Click OK.

  13. Click Add.

  14. Select the VisibleFields rule from the Name list.

  15. Select a general priority placement from the Rule Priority list.

  16. Click OK.

  17. Click OK.

    The screen closes and the profile is added to the list on the Profiles tab.

3.2.7.3 Global Rule to Restrict Content Check-In Based on User Role

This example illustrates how to create a global rule that can validate metadata fields when users check in content. The global rule validates the data in a request and returns an error message if the data is incorrect. This example shows how to allow only an administrator to check in content that specifies ADACCT as the Content Type.

Enable Fatal Error for a Global Rule Violation

  1. In a text editor, open the IntradocDir/config/config.cfg file.

  2. Add the following configuration setting:

    IsDpSubmitErrorFatal=true

  3. Close and save the file.

  4. Restart the Oracle WebCenter Content Server.

Create Global Rule Restricting Content Type Check-ins

This global rule validates the value for dDocType and ensures that an administrator is checking in an ADACCT document. However, the rule is configured to affect only the Check In and Update pages.

  1. Open the Rules tab on the Configuration Manager Page, and click Add.

    The Add/Edit Rule Screen opens.

  2. On the General tab, enter the name of the global rule in the Name field (for example, FailOnCheckInError).

  3. Enter a description for the global rule (optional).

  4. Select Is global rule with priority and change the priority number if needed.

  5. Select Use rule activation condition and click the corresponding Edit button.

    The Edit Activation Condition Screen opens.

  6. Click Add.

    The Add Condition Screen opens.

  7. Enter the name of the condition in the Name field (for example, CheckIn).

  8. Click OK.

    The screen closes and the General tab opens. The clause-generating tabs display on the lower pane.

  9. Select Use event.

  10. Select On Submit.

  11. Select Use action.

  12. Select Check in new, Check in selected, and Content update.

  13. Click OK.

    The screen closes and the activation condition clause is entered into the Use rule activation condition text pane.

  14. Click the Fields tab.

    The Add/Edit Rule Field 'name' Screen opens.

  15. Click Add.

    The Add Rule Field Screen opens.

  16. Select Type from the Field Name list.

  17. Select a general position form the Field Position list (optional).

  18. Click OK.

    The Add/Edit Rule Field 'name' Screen opens.

  19. Select Is derived field and click the corresponding Edit button.

    The Edit Derived Value: Conditions Tab opens.

  20. Click the Custom tab.

    The Custom screen opens.

  21. Select Custom and enter the following Idoc Script:

    <$if dDocType like "ADACCT" and not userHasRole("admin")$>
<$abortToErrorPage("Only administrators can use ADACCT.")$>
<$endif$>

  22. Click OK.

  23. Click OK.

  24. Click OK.

    The rule is added to the list of Rules.

3.2.7.4 Global Rule Restricting Content Type Metadata Changes

This example shows how to create a global rule that can validate metadata fields when users check in content. The global rule validates the data in a request, and returns an error message if the data is incorrect. Specifically, this example shows how to allow only an administrator to change the content type of a checked-in document.

Enable Fatal Error for a Global Rule Violation

  1. In a text editor, open the IntradocDir/config/config.cfg file.

  2. Add the following configuration setting:

    IsDpSubmitErrorFatal=true

  3. Close and save the file.

  4. Restart the Oracle WebCenter Content Server.

Create Global Rule to Restrict Content Type Changes

This global rule validates the value for dDocType and ensures that an administrator is changing the content type of a checked-in document. It is configured to affect only the Check In page.

  1. Open the Rules tab on the Configuration Manager Page and click Add.

    The Add/Edit Rule Screen opens.

  2. On the General tab, enter the name of the global rule in the Name field (for example, FailOnCheckInError).

  3. Enter a description for the global rule (optional).

  4. Select Is global rule with priority and change the priority number if needed.

  5. Select Use rule activation condition and click the corresponding Edit button.

    The Edit Activation Condition Screen opens.

  6. Click Add.

    The Add Condition Screen opens.

  7. Enter the name of the condition in the Name field (for example, CheckIn).

  8. Click OK.

    The screen closes and the Edit Activation Condition opens. The clause-generating tabs display on the lower pane.

  9. Select Use event.

  10. Select On Submit.

  11. Select Use action.

  12. Select Content update.

  13. Click OK.

    The screen closes and the activation condition clause is entered into the Use rule activation condition text pane.

  14. Click the Fields tab.

    The Fields Tab opens.

  15. Click Add.

    The Add Rule Field Screen opens.

  16. Select Type from the Field Name list.

  17. Select a general position form the Field Position list.

  18. Click OK.

    The Add/Edit Rule Field 'name' Screen opens.

  19. Select Is derived field and click the corresponding Edit button.

    The Edit Derived Value: Conditions Tab opens.

  20. Click the Custom tab.

    The Custom Screen opens.

  21. Select Custom and enter the following Idoc Script:

    <$oldType = getValue("DOC_INFO", "dDocType")$>
<$newType = getValue("#local", "dDocType")$>
<$if not (newType like oldType) and not (userHasRole("admin"))$>
<$abortToErrorPage("Only administrators can change dDocType.")$>
<$endif$>

  22. Click OK.

  23. Click OK.

  24. Click OK.

    The rule is added to the list of Rules.

Go to previous page
Previous		 Go to next page
Next
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Master Index
Master Index		 Go to Feedback page
Contact Us