This section describes how the content server behaves in the following situations:
The following steps occur during Content Server startup:
Internal initialization occurs.
Configuration variables load.
Standard templates, resources, and reports load.
Custom components load (templates, resources, configuration variables, and reports).
These steps are discussed in more detail on the following pages.
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.
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.
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.
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.
It is important to understand the effect of the load order of the different configuration files.
The IntradocDir/config/config.cfg file is loaded first, and the IntradocDir/data/components/component_name/config.cfg file is loaded last.
Therefore, if a variable is set in more than file, the last variable loaded takes precedence. Files are loaded in this order (not all files exist for each component):
DomainHome/ucm/short-product-id/custom/component_name/*_environment.cfg. Some components may not have this file or it may be named environment.cfg.
DomainHome/ucm/short-product-id/bin/intradoc.cfg is reread at the end of startup to allow overrides to other settings.
If, for example, a variable was set in each of the files listed previously, the variable in component_name/config.cfg takes precedence.
To view the configuration, use the GET_SYSTEM_AUDIT_INFO service to show all configuration entries and where they were set.
To change a component variable, use the Component Manager and select Update Component Configuration. This displays values in the component_name/config.cfg file that are editable. Make the desired changes, and click Update. You can also edit the configuration file manually.
If a component is not displayed in the drop-down list or if the variables displayed don't include the one to change, make the change directly in one of the configuration files.
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".
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".
Note:Content Server uses the Web server provided by Oracle WebLogic Server.
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:
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:
<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>
When a Web page is requested from the Content Server, one of the following page types is returned:
static page: The content of a static Web page is pre-formatted, and does not change from one request to the next. In some Content Server Web sites, the only static page is the guest home page (DomainHome/ucm/short-product-id/weblayout/portal.htm).
dynamic page: A dynamic Web page is assembled at the time of the Web server request, using Content Server services and templates to determine the content and formatting. For example, each user's portal design page is generated using a content server service called GET_PORTAL_PAGE and a template called PNE_PORTAL_DESIGN_PAGE.
When a Web browser requests a dynamic page from the Content Server, the browser is actually placing a request for a Content Server service.
When a user clicks the Administration link in the navigation area, a request for the GET_ADMIN_PAGE service is sent to the Web server.
The Web server recognizes this request as a Content Server function, and sends the specific request to the Content Server.
When the content server has processed the request, it passes the result back to the Web server. In the case of the Administration link, the GET_ADMIN_PAGE service:
Provides a login prompt if the user is not currently logged in.
Verifies that the user has admin permission.
Assembles the Administration page using the ADMIN_LINKS template.
Returns the assembled Web page to the Web server.
The Web server delivers the results of the Content Server service to the originating Web browser client.
A search request is a special kind of Content Server service. When the Content Server receives a search request, it sends the request on to the search engine using a search engine API. This allows different search engines to be used with the Content Server.
When a user clicks the Search button on the standard Search page, a request for the GET_SEARCH_RESULTS service is sent to the Web server.
The Web server recognizes the request as a Content Server function, and sends the specific request to the Content Server.
The Content Server passes the request to the search engine.
The search engine returns the search results to the Content Server.
Based on the user login and security permissions, the Content Server assembles the search results page and returns it to the Web server.
The Web server delivers the results to the originating Web browser client.
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:
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.
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.
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.