Service module configuration

Configuration data for BOD service modules is organized into base, and custom configuration. Configuration files are loaded before the service module can process service requests. The configuration class loader automatically discovers the configuration directories, by following certain naming conventions. Base (or bootstrap) configuration enables basic service module functionality. It contains the configuration data provided with the WebSphere Commerce service modules. We can also create custom configuration to add new functionality or customize existing functions. To change or extend this configuration, we must place you configuration in the workspace_dir\WC\xml\config\servicemodulename-ext\ directory with the configuration files named as the same as those we want to change or extend.

Note: Whether the configuration overwrites the default configuration or extends it depends on the function that uses that configuration.

Configuration file loading

When resolving configuration, custom configuration always takes precedence over base configuration. Depending on the load policy (extend versus override), the base configuration is either parsed or skipped. The load policy is specified in the parser class implementation. We can check whether the policy is overridable by calling the isOverridable() method.

For more complex configuration data structures, that cannot easily be represented as name-value pairs (for example, heavily structured, nested data), we can provide our own configuration file and configuration parser. This requires more work from the developer, but is completely flexible - any kind of configuration file can be read, parsed, and retrieved in your service module Java code. If we are writing our own configuration parser, must extend from the AbstractConfigurationImpl abstract class.

Extend Policy

When the extend policy is used, the configuration information for both bootstrap and custom configuration is loaded and returned to the caller as a list of configuration objects. In the list, custom configuration precedes bootstrap configuration. The caller must traverse the list and pick the configuration.

Override Policy

If the override policy is used, the loading process only loads the custom configuration. The bootstrap configuration is ignored. Thus, any metadata placed in custom configuration files will completely override the metadata from the base.

During development, you may want to modify and reload configuration, without having to restart the server. To enable volatile reloading for all service modules, create an empty .reloadconfig file in xml/config/com.ibm.commerce.foundation/. This will cause every service module to check the timestamps on its configuration files, each time it is called. Configuration files that have changed from the time that they were last loaded will get re-parsed. Also, if a configuration file was added or removed, all files in the same directory are reloaded. To enable volatile reloading for a particular service module, create an empty .reloadconfig file under the service module configuration directory . For example, xml/config/com.myco.myservicemodule. Volatile reloading will only be enabled for that service module.

Naming conventions

The configuration loader uses directory names to discover a service module's bootstrap and custom configurations.

Bootstrap configuration

xml/config/servicemodulename/

Custom configuration

xml/config/servicemodulename-ext/

In both cases above, servicemodulename represents the name of your service module or the WebSphere Commerce service module we are configuring. Configuration file names follow a strict naming convention – these names are used by the configuration loader.

• All WebSphere Commerce default configuration file names are prefixed by wc-. For example, wc-query.tpl.

• Administration configuration file names begin with "wc-admin".

• Descriptive words are joined with dashes. For example, wc-business-context.

Every service module contains the following files:

wc-component.xml

Contains the development configuration of a component. It can occur in both the base and custom configuration directories.

wc-admin-component.xml

Contains the administration configuration of a component. It can occur in both the base and custom configuration directories.

wc-application.xml

Contains the development configuration information applicable to all components within an application. This file will only exist under the foundation component directory.

wc-admin-application.xml

Contains the administration configuration information applicable to all components within an application. This file will only exist under the foundation component directory.

SDO.properties

Used for loading the initialized logical SDO classes. Specifies a class that declares the logical SDO classes that need to be initialized. For example, the SDO.properties file for the Member component contains: com.ibm.commerce.member.facade.datatypes.impl.MemberPackageImpl.

wc-component-client.xml

Specifies the bindings from URL to Web services. For example, the component-client.xml for the Member service module is shown in the following XML sample:

<_config:DevelopmentClientConfiguration xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/config ../xsd/wc-component-client.xsd">
	<_config:invocationservice>
		<_config:invocationbinding bindingImpl="com.ibm.commerce.foundation.internal.client.services.invocation.impl.J2SEWebServiceInvocationBindingImpl">
			<_config:property name="url" value="http://hostname:5080/webapp/wcs/component/member/services/MemberServices"/>
		</_config:invocationbinding>	
	</_config:invocationservice>	
</_config:DevelopmentClientConfiguration>

wc-business-object-mediator.xml

Contains configuration information for the Business Object Mediator.

wc-object-relational-metadata.xml

Contains Object-relational metadata.

Note: The configuration files are guided by an XSD (XML Schema Definition). The XSD provides documentation describing the purpose of each configuration file. The XSD is located in the xml/config/xsd directory. By observing the XML file in an editor, we can use the XSD to determine the respective supported elements, as well as the annotation about the configuration.

Configuration files

The following configuration files are typically used for BOD-based services:

• SDO.properties

• wc-admin-component

• wc-business-context

• wc-business-object-mediator.xml

• wc-component.xml

• wc-component-client.xml

• wc-object-relational-metadata.xml

• wc-query-noun-get.tpl

• wc-query-noun-update.tpl

The following configuration files are typically used for SOI-based services:

• SDO.properties

• wc-component.xml

• wc-component-client.xml