This section discusses the HDA file type and the component definition (glue) file in more detail. The following topics are discussed:
The information in this chapter is intended as reference material and should not be used to create files manually. You should always use the Component Wizard to create your component files.
The idc_components.hda file tells the Content Server which components are enabled and where to find the component definition (glue) file for each component. With 11g Release 1 (11.1.1) this file has three forms, one for each of the UCM products: idccs_components.hda (for Content Server), idcibr_components.hda (for Inbound Refinery), and idcurm_components.hda (for Universal Records Management). The file is always stored in the IntradocDir/data/components/ directory.
The file always includes a ResultSet called Components that defines the name and file path of each definition file. You can use the Component Wizard or the Component Manager to make changes to the components HDA file. See "Enabling and Disabling Components" for more information.
In the following example of an idccs_components.hda file, two components called "My Component" and "CustomHelp" are enabled.
<?hda version="5.1.1 (build011203)" jcharset=Cp1252 encoding=iso-8859-1?>
@Properties LocalData
blDateFormat=M/d{/yy} {h:mm[:ss] {aa}[zzz]}!tAmerica/Chicago!mAM,PM
blFieldTypes=
@end
@ResultSet Components
2
name
location
MyComponent
custom/MultiCheckin/my_component.hda
CustomHelp
custom/customhelp/customhelp.hda
@end
The order that components are listed in the Components ResultSet determines the order that components are loaded when you start the Content Server. If a component listed later in the ResultSet has a resource with the same name as an earlier component, the resource in the later component takes precedence.
A Components ResultSet has two columns:
The name column provides a descriptive name for each component, which is used in the Component Wizard, Component Manager, and Content Server error messages.
The location column defines the location of the definition file for each component. The location can be an absolute path or can be a path relative to the Content Server install directory.
Note:
Always use forward slashes in thelocation path.A component definition file, or glue file, points to the custom resources that you have defined. The definition file for a component is named component_name.hda, and is typically located in the DomainHome/ucm/short-product-id/custom/component_name/ directory. The Component Wizard can be used to create and make changes to a definition file.
A definition file includes a ResourceDefinition ResultSet, and may contain a MergeRules ResultSet, a Filters ResultSet or a ClassAliases ResultSet or both.
The following example shows a typical component definition file.
@ResultSet ResourceDefinition 4 type filename tables loadOrder template dcl_templates.hda DCLCustomTemplates 1 resource dcl_resource.htm null 1 resource dcl_upper_clmns_map.htm DCLColumnTranslationTable 1 resource dcl_data_sources.htm dclDataSources 1 service dcl_services.htm CustomServices 1 query dcl_query.htm CustomQueryTable 1 resource dcl_checkin_tables.hda null 1 @end @ResultSet MergeRules 3 fromTable toTable column DCLCustomTemplates IntradocTemplates name DCLColumnTranslationTable ColumnTranslation alias DCLDataSources DataSources name CustomDCLServiceQueries ListBoxServiceQueries dataSource @end @ResultSet Filters 4 type location parameter loadOrder loadMetaOptionsLists intradoc.server.ExecuteSubServiceFilter GET_CHOICE_LIST_SUB 1 @end
The ResourceDefinition ResultSet table defines the type, file name, table names, classpath, library path, features, and load order of custom resources. The following example shows the structure of a ResourceDefinition ResultSet.
@ResultSet ResourceDefinition 4 type filename tables loadOrder template dcl_templates.hda DCLCustomTemplates 1 resource dcl_resource.htm null 1 resource dcl_upper_clmns_map.htm DCLColumnTranslationTable 1 resource dcl_data_sources.htm dclDataSources 1 service dcl_services.htm CustomServices 1 query dcl_query.htm CustomQueryTable 1 resource dcl_checkin_tables.hda null 1 @end
A ResourceDefinition ResultSet consists of four columns:
The type column defines the resource type, which must be one of the following values:
resource, which points to an HTML include (HTM), string (HTM), dynamic table (HDA), or static table (HTM) resource file.
environment, which points to an environment resource (CFG) file.
template, which points to a template resource (HDA) file.
query, which points to a query resource (HTM) file.
service, which points to a service resource (HTM) file.
The filename column defines the path and file name of the custom resource file. This can be an absolute path or a relative path. Relative paths are relative to the DomainHome/ucm/short-product-id/custom/component_name/ directory.
The tables column defines the ResultSet tables to be loaded from the resource file. ResultSet names are separated with a comma. If the resource file does not include ResultSets, this value is null. For example, HTML include resources do not include table definitions, so the value for the tables column is always null for an HTML include file.
The loadOrder column defines the order in which the resource is loaded. Resources are loaded in ascending order, starting with resources that have a loadOrder of 1. If multiple resources have the same loadOrder, the resources are loaded in the order they are listed in the ResourceDefinition ResultSet. If there are multiple resources with the same name, the last resource loaded is the one used by the system. Normally, you should set the loadOrder to 1, unless there is a particular reason to always load one resource after the others.
The MergeRules ResultSet table identifies new tables that are defined in a custom component, and specifies which existing tables the new data is loaded into. MergeRules are required for custom template resources but are optional for custom dynamic table and static table resources. MergeRules are not required for custom service, query, HTML include, string, and environment resources.
The following example shows a MergeRules ResultSet.
@ResultSet MergeRules 4 fromTable toTable column loadOrder DCLCustomTemplates IntradocTemplates name 1 DCLColumnTranslationTable ColumnTranslation alias 1 DCLDataSources DataSources name 1 CustomDCLServiceQueries ListBoxServiceQueries dataSource 1 @end
A MergeRules ResultSet consists of three columns:
The fromTable column specifies a table that was loaded by a custom resource and contains new data to be merged with the existing data. To properly perform a merge, the fromTable must have the same number of columns and the same column names as the toTable.
The toTable column specifies the name of the existing table into which the new data is merged. Usually, the toTable value is one of the standard Content Server tables, such as IntradocTemplates or QueryTable.
The column column is the name of the table column that the Content Server uses to compare and update data.
The Content Server compares the values of the specified column in the fromTable and toTable. For each fromTable value that is identical to a value currently in the toTable, the row in the toTable is replaced by the row in the fromTable. For each fromTable value that is not identical to a value currently in the toTable, a new row is added to the toTable and populated with the data from the row of fromTable.
The column value is usually name. Setting this value to null defaults to the first column, which is generally a name column.
The Filters ResultSet table defines filters, which are used to execute custom Java code when certain Content Server events are triggered, such as when new content is checked in or when the server first starts. The following example shows a typical Filters ResultSet.
@ResultSet Filters 4 type location parameter loadOrder loadMetaOptionsLists intradoc.server.ExecuteSubServiceFilter GET_CHOICE_LIST_SUB 1 @end
The ClassAliases ResultSet table points to custom Java class files, which are used to extend the functionality of an entire Content Server Java class. The following example shows a typical ClassAliases ResultSet.
@ResultSet ClassAliases 2 classname location WorkflowDocImplementor WorkflowCheck.CriteriaWorkflowImplementor @end