2.3 Content Server Behavior

2.3.1 Startup Behavior

The following steps occur during Content Server startup:

1. Internal initialization occurs.

2. Configuration variables load.

3. Standard templates, resources, and reports load.

4. Custom components load (templates, resources, configuration variables, and reports).

These steps are discussed in more detail on the following pages.

Figure 2-1 Content server startup behavior

Description of "Figure 2-1 Content server startup behavior"

1. Internal Initialization Occurs: When the content server initializes internally, the Java class files from the content server are read and the Java Virtual Machine (JVM) is invoked. Any variables in the DomainHome/ucm/short-product-id/intradoc.cfg file initialize as well.

2. Configuration Variables Load: After initializing, the content server loads the config.cfg file from the IntradocDir/config directory. This file stores the system properties and configuration variables, which are defined by name/value pairs (such as SystemLocale=English-US).

   The default information contained within the configuration file was supplied during the content server installation process, but you can modify this file in several ways:

   • By using the Admin Server General Configuration page, accessible from the Administration menu.

   • By using the System Properties option, which is available from the Start menu (in Windows) or by running the SystemProperties script, located in the /bin directory of your installation (on UNIX).

   • By editing the configuration files directly.

   • By using a custom component.

   Any time changes are made to the config.cfg file, you must restart the content server for the changes to take effect.

3. Standard Resources, Templates, and Reports Load: For the Content Server to function properly, many standard resources, templates, and reports must be loaded. After the configuration settings have been loaded, the Content Server reads the entries in the IdcHomeDir/resources/core/templates/templates.hda file and the IdcHomeDir/resources/core/reports/reports.hda file.

4. Custom Components Load: The content server loads custom components in the order specified in the IntradocDir/custom/components.hda file. As each custom component is loaded, any resources defined for that component override any resources with the same name. For example, if two components are enabled that both use a resource called my_resource.htm, the resource definition for the component that is loaded last takes precedence.

2.3.2 Resource Caching

• When the content server loads template pages and resources, they are cached in memory to accelerate page presentation.

• If you change a template page, report page, or HTML include resource, or you check in a revision to a dynamic server page, your changes go into effect immediately—the next request for the associated Web page or refresh of the page reflects the changes and the new information is cached. This occurs because pages are assembled dynamically for each page request. You can disable this behavior to improve performance by setting the config variable DisableSharedCacheChecking.

• If you change any other component files (including services, queries, environment variables, tables, components.hda file, and template.hda file), you must restart the content server before the changes go into effect. This is because such changes could cause the content server to malfunction if they were implemented immediately. You do not need to restart the content server when changing strings, however, you must republish the ww_strings.js files by selecting Publish dynamic files from the Admin Actions page. For more information see Chapter 3, "Working with Components".

2.3.3 Content Server Requests

When a Web browser client sends a Content Server request to the Web server, the instructions are typically communicated through URLs or form fields. The Web server routes the request to the content server, which then performs one or more of the following actions:

• Retrieves pages—See "Page Retrieval".

• Runs a content server service—See "Content Server Services".

• Runs a search engine service—See "Search Services".

When a content server Web page is requested, all of the necessary information can be sent to the content server through the URL. The following is a typical content server URL; in this case, it is the URL for the Home page:

http://cs.company.com/instancename/idcplg?IdcService=GET_DOC_PAGE&Action=GetTemplatePage&Page=HOME_PAGE

• http://cs.company.com and instancename is the Web address of the content server instance.

• IdcService=GET_DOC_PAGE tells the content server to execute the GET_DOC_PAGE service.

• Action=GetTemplatePage tells the content server to return the results using a specified template page.

• Page=HOME_PAGE tells the content server which template page to use.

• The question mark (?) indicates the end of the Web server path and the beginning of content server instructions.

• Ampersands (&) are used as separators between content server instructions.

• You can include some Idoc Script variables in a URL to affect page display at the time of the page request. This is useful for troubleshooting or for temporary. For example, the following variables can be used for customization:

  • &StdPageWidth=1000

  • &dDocAuthor:isHidden

  • &dDocType=HRForm

Necessary information can also be sent to the content server through form fields on the page. The following is a typical Content Server form:

<form name=SubscriptionForm action="<$HttpCgiPath$>" Method="GET"">
<input type=hidden name=dID value="<$dID$>">
<input type=hidden name=dDocName value="<$dDocName$>">
<input type=hidden name=subscribeService value=SUBSCRIBE>
<input type=hidden name=exitUrl value="<$HttpCgiPath$>?IdcService=DOC_INFO&dID=<$dID$>&dDocName=<$dDocName$>">
<input type=hidden name=title value="Subscriptions">
<input type=hidden name=unsubscribeService value=UNSUBSCRIBE>
<$if ClientControlled$>
<input type=hidden name=ClientControlled value="<$ClientControlled$>">
<$endif$>
<$if DocHasSubscription$>
<input type=hidden name=IdcService value="UNSUBSCRIBE_FORM">
<input type=submit value="<$lc("wwUnsubscribe")$>">
<$else$>
<input type=hidden name=IdcService value="SUBSCRIBE_FORM">
<input type=submit value="<$lc("wwSubscribe")$>">
<$endif$>
</form>

2.3.4 Page Assembly

The Content Server uses information from the files in the IdcHomeDir/resources directory to assemble dynamic Web pages.

• The structure and format of a Web page is defined by a particular HTML template file in either the /templates or /reports directory.

• The template file references resources, which are located in .htm and .idoc files in the /resources directory. Resources can include HTML and Idoc Script markup, localized strings, queries to gather information from the database, and special code to conditionally format the information.

As a rule, each Web page includes the following resources:

• A standard page header

• A standard page beginning

• A standard page ending

Because all of the Content Server resources are cached in memory at startup, the Content Server has a definition for the standard pieces that appear on the page. The Content Server then combines the standard resources with the unique resources specified in the template to create the Web page.

For dynamic server pages, the template page and custom resource files are checked into the Content Server. When one of these pages is requested by a Web browser, the Content Server recognizes the file extension as a dynamic server page, which allows special processing to occur. At that point, the page assembly process is the essentially the same as the standard process, except that the page can use both the standard resources in the resources directory and the custom resources that are checked in to the Content Server.

2.3.5 Database Interaction

Some databases, such as Oracle Database, return all column names as uppercase. Therefore, when Content Server receives query results from these databases, column names must be mapped from uppercase to the values used in the Content Server.

Because of this case mapping issue, custom components created for a Content Server using one database might not work correctly on a Content Server using a different database.

To map column names, the IdcHomeDir/resources/core/resources/upper_clmns_map.htm file contains a mapping table named ColumnTranslation. Add the query values to this file when you create a component that accesses non-content server database fields (for example, if you create a component that accesses a custom table within the Content Server database).

See "Modifying System Functionality" for information about using the upper_clmns_map.htm file.

2.3.6 Resolving Localized Strings

Localized strings are the means by which the user interface and error messages are presented in the language specified by the user's locale. The Content Server loads the string resource files for a base language and also loads resource files for every supported language. Instead of presenting hard-coded text, the template pages, applets, and error messages reference string IDs in these resource files, which are then resolved using the ExecutionContext that contains the locale information for the user.