This chapter describes how to change the basic functionality of Oracle Content Server.
This chapter includes the following sections:
Oracle Content Server has a number of features that you can set up to change features systemwide according to your needs. For example, you can use the following administration tools within Oracle Content Server to customize your content management system settings:
Admin Server: The Admin Server is a collection of web pages that you can use to configure systemwide settings for Oracle Content Server. To access these pages, click Admin Server from the Administration tray in the portal navigation bar to display the Admin Server main page. From this page, you can check the status of each server that is running, and you can check console output.
System Properties: The System Properties administration application is used to configure systemwide Oracle Content Server settings for content security, Internet settings, localization, and other types of settings. In the System Properties application, you can set these options:
Optional functionality for the Oracle Content Server instance
Options related to content item security
Options related to the Internet and web interaction
JDBC connectivity options
Functionality such as time zones and IP filters
Localization features
Directory paths
Oracle WebLogic Server is the primary tool for setting system properties for Oracle UCM; however, for some purposes you must use the System Properties application. You do not need administrative-level permissions to set these options; just access to the directory where the instance is installed.
Web Layout Editor: The Web Layout Editor is used to customize the Library and system home (portal) page. To access this editor, click Web Layout Editor on the Admin Applets page. With the Web Layout Editor, you can change the organization of local web pages in the Library and build new portal pages for your site. You can create links to web sites outside your local site. For detailed information, see Oracle Fusion Middleware Application Administrator's Guide for Content Server.
User administration: You can define security groups, aliases, roles, and accounts for the users at your site using the User Admin function. To access this screen, select Admin Applets from Administration tray or menu, then click User Admin on the Administration Applets for user page. Options on this screen are used to create aliases, set permissions for security groups, establish roles and permissions associated with those roles, and customize information that is stored about users.
Other administration customizations: In addition to the system settings that are discussed here, other settings can be changed to match your site's needs:
Workflows can be designed, customized, and implemented using the Workflow Admin tool available from the Admin Applets menu
New custom metadata fields can be created and default values set using the Configuration Manager
Customized action screens (such as check-in, search, and check-out) can be created using Content Profiles
Components are modular programs that are designed to interact with Oracle Content Server at runtime. The component architecture model is derived from object-oriented technologies, and encourages the use of small modules to customize Oracle Content Server as necessary, rather than creation of a huge, all-inclusive (but cumbersome) application.
Note:
You can create custom components by manually creating the necessary files and resources. However, the Component Wizard has no limitations compared to the manual method, and using it prevents many common mistakes.Any type of file can be included in a component, but the following file formats are used most often:
HDA
HTM
CFG
Java CLASS
Components are typically used to alter the core functionality of Oracle Content Server. For example, you could use a component could to perform any of these tasks:
Modify the standard security features
Change the way search results are requested and returned
Enable Oracle Content Server to work with a particular system (such as a Macintosh client or a proprietary CAD program)
Using component architecture with Oracle Content Server gives you these advantages:
You can modify source code without compromising the integrity of the product. Oracle Content Server loads many of its resources from external text files, so you can view the files to analyze how the system works, and then copy and modify the files to your requirements.
You can use a custom component on multiple instances across multiple platforms. When you have created a custom component, you can package it as a ZIP file and load it on other Oracle Content Server instances. Many custom components can work on Oracle Content Server platforms other than the original development platform.
You can turn individual components on and off for troubleshooting purposes. You can group customizations so that each component customizes a specific Oracle Content Server function or area. If you have problems, disabling components one at a time can help you quickly isolate the trouble.
You can reinstall or upgrade an Oracle Content Server instance without compromising customizations. Custom components override existing product resources rather than replace them. Replacing the standard Oracle Content Server files might not affect your customizations.
Keep the following constraints in mind when deciding whether to use custom components:
Custom components change behavior and look-and-feel systemwide. If you want your changes to apply only in limited situations, you might want to consider dynamic server pages.
Custom components can be affected by changes to the Oracle Content Server core functionality. Because new functionality may change the way your components behave, customizations are not guaranteed to work for future Oracle Content Server releases. Whenever you upgrade, you should review and test your custom components.
A component may not be necessary for simple customizations. A large number of simple components could become difficult to manage.
Components must be installed and enabled to be used by Oracle Content Server. Components provided with Oracle Content Server are automatically installed, and they are enabled or disabled by default. Custom components must be installed and enabled to be usable. Several tools are available for working with components:
The Component Wizard automates the process of creating custom components. You can use the Component Wizard to create new components, modify existing components, and package components for use on other Oracle Content Server instances. For more information, see Section 3.1.1, "Component Wizard."
The Advanced Component Manager provides a way to manage custom components in Oracle Content Server. By using the Advanced Component Manager, you can add new components and enable or disable components for Oracle Content Server. For more information, see Section 3.1.2, "Advanced Component Manager."
The ComponentTool is a command-line utility for installing, enabling, and disabling components for Oracle Content Server.
For information about component architecture and creation, see Chapter 3, "Working with Standard, Server, and Custom Components."
For advanced customizations and integration with other business systems, Oracle Content Server supports several development tools and technologies, such as the following:
VBScript
ASP
J++
JavaScript
ASP+
J2EE
Java
JSP
COM
Visual Basic
DreamWeaver
.Net
C++
Visual InterDev
In addition to these tools, the proprietary Idoc Script is a server-side custom scripting language for Oracle Content Server. It is used to reference variables, to conditionally include content in HTML pages, and to loop over results returned from queries.
Because Idoc Script is evaluated on the server side (rather than the client side), page elements are processed after the browser has made a request, but before the requested page is returned to the client.
Idoc Script is primarily used in the following situations:
For include code, an include defines pieces of code used to build Oracle Content Server web pages. They are defined once in a resource file then referenced by template files as necessary. Includes are used on almost every page of the Oracle Content Server web site.
A super tag can also be used, which defines exceptions to an existing include. The super tag tells the include to start with an existing include and add to it or modify it using the specified code.
For variables, you can use variables to customize the Oracle Content Server behavior. Variable values can be stored in an environment resource, such as the config.cfg file and many are predefined in Oracle Content Server. You can also define your own custom variables.
For functions, many built-in global functions are used in Oracle Content Server. These perform actions such as date formatting or string comparisons. Some functions return results and some are used for personalization functions, such as those found on the My Profile page.
For conditionals, you can use conditionals to test code and include or exclude the code from an assembled web page.
For looping, two types of looping are available using Idoc Script: ResultSet looping, in which a set of code is repeated for each row in a ResultSet that is returned from a query and while looping, which is a conditional loop.
In Administration areas, such as Workflow customization, web layouts, archiver and search expressions.
For information about usage, syntax, and configuration variables, see the Oracle Fusion Middleware Idoc Script Reference Guide.
Oracle Content Server services are functions or procedures performed by Oracle Content Server. Calling an Oracle Content Server service (making a service request) is the only way to communicate with Oracle Content Server or to access the database.
Any service can be called externally (from outside Oracle Content Server) or internally (from within Oracle Content Server). Client services are usually called externally while administrative services are called internally. The service uses its own attributes and actions to execute the request, based on any parameters passed to the service.
The standard Oracle Content Server services are defined in the StandardServices table in DomainHome/resources/core/tables/std_services.htm. A service definition contains three main elements:
The service name.
The service attributes. The attributes define the following aspects of the service:
the service class, which specifies which Java class the service has access to. This determines what actions can be performed by the service.
the access level, which assigns a user permission level to the service.
a template page that specifies the template that displays the results of the service.
the service type which specifies if the service is to be executed as a subservice inside another service
subjects notified, which specifies the subsystems to be notified by the service.
the error message that is returned by the service if no action error message overrides it.
The service action, which is a colon-separated list that defines the following aspects of the action:
action type
action name
action parameters
action control mask
action error message
Understanding and using services is an integral part of creating components and thus customizing Oracle Content Server. For more information, see Chapter 6, "Integrating Oracle UCM with Enterprise Applications."
In previous versions of Oracle Content Server, when a component writer wanted to create an HTML table like those used on the search results page, HTML code had to be copied and pasted. The information in the tables was mixed with the HTML, with no separation between data and display.
The same issue was true for action menus. Data and display for the tables and menus were tightly coupled, making it impossible to perform global changes to all tables in Oracle Content Server except for those changes done with CSS modifications. It was also difficult for components to target and modify specific aspects of both the tables and the menus.�
To customize a page's action menu, a developer can override one of the following include files then modify the PageMenusData resultset. These includes are all defined in the DomainHome/resources/core/resources/std_page.idoc file:
custom_searchapi_result_menus_setup
custom_docinfo_menus_setup
custom_query_page_menus_setup
custom_audit_info_menus_setup
In addition, tables like the one used on the search results page can be created by setting up result sets of data then calling specific resource includes which use that data to display the page. Result sets can also be used to create action menus like those found on the Workflow In Queue and Search Results pages.
The action menu and HTML table display frameworks allow developers to create quick and flexible web pages that match the look and feel of the rest of the system. They also allow component writers to easily extend, add to, and override any or all of the Headline View or Thumbnail View tables on the server, and any of the action menus.
Different display tables are used for the search results page for each display type (Headline or Thumbnail), with an API for each, as the following sections describe:
One of the first steps in any table setup is to retrieve documents to display, as in this example:�
<$QueryText = "dDocAuthor <matches> `sysadmin`"$>�
<$executeService("GET_SEARCH_RESULTS")$>�
The following example shows how to create a Headline View table. The concepts discussed here are also used to create the other table types.
The initial step in this process is to create a result set that describes the columns of the table, as in this example:�
<$exec rsCreateResultSet("ColumnProperties",
"id,width,headerLabel,rowAlign")$>
<$exec rsAppendNewRow("ColumnProperties")$>
<$ColumnProperties.id = "dDocName"$>
<$ColumnProperties.width = "150px"$>
<$ColumnProperties.headerLabel = lc("wwDocNameTag")$>
<$ColumnProperties.rowAlign = "center"$>
<$exec rsAppendNewRow("ColumnProperties")$>
<$ColumnProperties.id = "dDocTitle"$>
<$ColumnProperties.width = "auto"$>
<$ColumnProperties.headerLabel = lc("wwTitle")$>
<$ColumnProperties.rowAlign = "left"$>
<$exec rsAppendNewRow("ColumnProperties")$>
<$ColumnProperties.id = "actions"$>
<$ColumnProperties.width = "75px"$>
<$ColumnProperties.headerLabel = lc("wwActions")$>
<$ColumnProperties.rowAlign = "center"$>�
A result set called ColumnProperties is created. Each row in the table corresponds to a column on the table to be created. Each column can have several attributes associated with it. Some of the more common attributes are:�
id: This is a mandatory attribute. Each column in the table being created must have an ID associated with it. The ID is used later to determine what will be displayed in every row.�
width: The width of the column. This can be any CSS width declaration such as 100px, 15em, or auto, which causes the column to auto-size, filling as much of the table as possible.�
headerLabel: The text to be displayed in the header of this column.�
rowAlign: An indication of whether the contents should be left, right, or center aligned.
headerURL: Used to link the column header text to a URL�.
The next step is to determine what data will be displayed in each row of the table.�
<$exec rsCreateResultSet("RowData","dDocName,dDocTitle,actions")$>
<$exec rsAppendNewRow("RowData")$>
<$RowData.dDocName = "<$dDocName$>"$>
<$RowData.dDocTitle = "<$dDocTitle$>"$>
<$RowData.actions = "<$include doc_info_action_image$>"$>
The ColumnProperties result set technically has a row for each column in the table, while in RowData, there is only one row. Data entered into this result set is of the following form:�
<$RowData.%COLUMN_ID% = "%IDOCSCRIPT%"$>�
Each column in the RowData result set refers to an actual column that will appear in the final table. Each column in this result set has a corresponding "ID" in the ColumnProperties result set declared earlier. An Idoc Script expression is assigned to each cell in this result set. It will then be evaluated during the display of each row as it is written to the HTML document.
Next the resource include must be created to display each row in the table.�
<$include create_slim_table_row_include$>�
Calling this resource include creates the slim_table_row_include resource include. Instead of parsing and evaluating the RowData result set for each row in the table, it is done once.
Use the following steps to set multiple row includes (for example, for a single table which displays different rows for different types of items):
Delete and re-create the RowData result set.
Set rowIncludeName to the name of the resource include to create.
Include create_slim_table_row_include again�.
The following code displays the table:�
<$include slim_table_header$> <$loop SearchResults$> <$include slim_table_row_include$> <$endloop$> <$include slim_table_footer$>�
To make the table look like the table on the search results page, set the following in the script:
<$UseRowHighlighting = true$>�
One special customization with the Headline View table allows any component writer or administrator to easily override how the data in any column is presented. For example, a custom include similar to the following can be declared from in a component:
<@dynamichtml slim_table_title@> <b><$dDocTitle$></b> <@end@>
If dDocTitle:slimTableCellInclude=slim_table_title is added to the IntradocDir/config/config.cfg file or set from within a script, all Headline View tables with a column ID of dDocTitle are displayed using the defined custom include.� This overrides the RowData for these columns.�
The table for the Thumbnail View is created differently. The ColumnProperties or RowData result sets are not constructed. Instead, the number of columns are set and an Idoc Script include name is used to "paint" each cell. This is less easy to customize and less data-driven than the other methods, but this type of table is also much less structured.�
<$numDamColumns = 4$> <$damCellIncludeName = "my_sample_dam_cell"$> <$include dam_table_header$> <$loop SearchResults$> <$include dam_table_item$> <$endloop$> <$include dam_table_footer$>
The first step in customization is to add the action menu icon to the Actions column.� The following example incorporates an action menu into each row of the Headline View sample table used previously.
<$RowData.actions = "<$include action_popup_image$>" & " <$include doc_info_action_image$>"$>
This inserts the action image into the appropriate column. However, clicking it does nothing because the actual menu is not written to the HTML page.
The following code creates the data to be used to construct this menu:�
�<$exec rsCreateResultSet("PopupProps",
"label,onClick,function,class,id,ifClause")$>
<$exec rsAppendNewRow("PopupProps")$>
<$PopupProps.label = lc("wwCheckOut")$>
<$PopupProps.function = "<$HttpCgiPath$>?IdcService=CHECKOUT" &
"&dID=<$dID$>&dDocName=<$url(dDocName)$>" &
"&dDocTitle=<$url(dDocTitle)$>"$>
<$PopupProps.class = "document"$>
<$PopupProps.id = "checkout"$>
<$exec rsAppendNewRow("PopupProps")$>
<$PopupProps.label = lc("wwGetNativeFile")$>
<$PopupProps.function = "<$HttpCgiPath$>?IdcService=GET_FILE" &
"&dID=<$dID$>&dDocName=<$url(dDocName)$>" &
"&allowInterrupt=1"$>
<$PopupProps.ifClause = "showNativeFileLink"$>
<$PopupProps.class = "document"$>
<$PopupProps.id = "getNativeFile"$>
<$exec rsAppendNewRow("PopupProps")$>
<$PopupProps.label = lc("wwTest")$>
<$PopupProps.function = "javascript:alert('<$js(dDocName)$>');"$>
<$PopupProps.ifClause = "showTestAction"$>
<$PopupProps.class = "debug"$>
<$PopupProps.id = "alertDocName"$>
This code creates a result set called PopupProps, where each row corresponds to an action in the menu being created. Each action can have several attributes associated with it. Some of the more common attributes follow:�
�label: A string displayed as the label for the action.�
function: The URL or JavaScript method to be associated with this action.�
class: A classification for this action. It can be something as simple as "search", "document", "workflow", or even the name of your component. It places the action into a group so it can be quickly enabled or disabled with the rest of the actions within that same group.�
id: Another method of classification, much more specific than "class". This method should be unique to the application, and you can use it to hide certain actions from appearing within the menus.
ifClause: An optional attribute evaluated every time that action is about to be written to the HTML document. If the clause evaluates to FALSE, the action is not displayed.
isDisabled: If set to 1, the action is never displayed.
linkTarget: Used to make this link open a page in a different window. This attribute points to any anchor tag target.�
After the data is set, it can be used to create an Idoc Script resource that writes this action menu.�
<$include create_action_popup_container_include$>�
This resource works like create_slim_table_row_include. It constructs a new Idoc Script resource called action_popup_container_include. To rename it, set set <$actionPopupContainerIncludeName = new_include_name$> in the script.
Use the following code to have this include called for each row of the Headline View table.�
<$exec rsCreateResultSet("PopupData", "actions")$>
<$exec rsAppendNewRow("PopupData")$>
<$PopupData.actions="<$include action_popup_container_include$>"$>
�This code creates a PopupData result set similar to the RowData result set. It is structured in the same way, and is used as a location to print the action menu containers which are hidden until a user clicks on the action image.
The table created now has action menus, similar to those normally seen on the search results page whenever the appropriate image is clicked.�
Editing these actions is done by adding and deleting rows from the PopupProps result set or editing rows that already exist. In addition to this type of customization, actions can be hidden by setting the disabledActionPopupClasses and disabledActionPopupIds variables. These can be set in the config/config.cfg file or in the Idoc Script itself. For example:�
<$disabledActionPopupClasses = "workflow,folders"$> <$disabledActionPopupIds = "getNativeFile,alertDocName"$>
Setting these variables causes any actions whose class is either workflow or folders, or whose ID is getNativeFile or alertDocName, to always be hidden. Using these variables enable Oracle Content Server administrators and component writers to hide specific actions either globally or for specific pages.�
�Component writers also can override a number of Idoc Script resource includes to modify functionality in this area on either a global or targeted scale. The following includes are just a few of the available resource includes:
custom_add_to_action_popup_data
custom_modify_action_popup_data
classic_table_row_pre_display
slim_table_row_pre_display
custom_row_pre_display