Introduction

Intershop Commerce Management provides a unified interface for administrators to get and load configuration settings to installations at system-level to application-level (i.e., preferences) from multiple sources. The central entry point is the configuration engine that reads the configuration.xml files where the reader, writer, finder, and scopes are defined for (and comprise) the ConfigurationSets. These files are searched in all cartridges in reverse order as resource  /resources/CARTRIDGE_NAME/config/configuration.xml.

Glossary

The following components comprise the framework for loading configuration settings:

<scope name="system" />
<scope name="ish" depends="system" />
<set finder="system" scope="system,ish,startup,instance,cluster,server,domain" />
<set finder="file" scope="instance,cluster,server,domain" fileName="${IS_CLUSTER_CONFIG}/environment.properties" priority="60"/>

References

• Concept - Configuration

• Overview - Infrastructure, Scaling and Performance

• Cookbook - Gradle Deployment Tools (7.4 CI - ICM 7.7)

Defining Configuration Sets

For every configuration set the finders and writers must be registered and the reader classes must be declared within configuration.xml. If a class is declared and the requirement is set to true and none is found, an exception will be thrown.

The order of configuration sets is important. Within configuration.xml, the sets must be ordered in the sequence they are loaded. This also means that the first value for a specific key is applied. If the same key is found later in the list of configurations, the value is discarded. See Arranging Configuration Sets for a list of where to place your configurations. Configurations should be loaded in the following sequence:

(1) System properties, define properties from the system.

(2) <IS.INSTANCE.LOCAL>/intershop.properties, for <IS.INSTANCE.DIR> properties.

(3) <IS.INSTANCE.SHARE>/system/config/cluster/environment.properties, defines one value for the current environment.

(4) <IS.INSTANCE.LOCAL>/config/[environment]_[feature].xml, defines the instance-specific (local) configuration.

(5) Preference table, defines properties in the database that can be read from/written to in the back office.

(6) <IS.INSTANCE.SHARE>/system/config/domains/[domain]/[environment]_[feature].xml, defines domain-specific business configuration.

(7) <IS.INSTANCE.SHARE>/system/config/cartridges/[environment]_[feature].xml, defines the default configuration of the cartridge.

(8) <IS.INSTANCE.SHARE>/system/config/cluster/[environment]_[feature].xml, defines the configuration for this cluster.

For every configuration set the finders and writers must be registered and the reader classes must be declared within configuration.xml.

The writer saves the configuration. You must define at least one writer that will retrieve the values of your configuration set. Below is the syntax for writer registration and a list of available writers:

Arranging Configuration Sets

The range or extent of the configuration is determined by the configuration scope where the configuration sources are located. Scopes are defined in the configuration.xml file and are dependent on scopes higher up in the scope hierarchy. If the configuration you want to load depends on values of a broader scope, these must be loaded first.

For example, if you load a configuration for a specific instance (scope="instance"), you must first load the startup configuration (the startup scope), which in turn depends on the system properties (contained in the <IS.INSTANCE.DIR> directory) contained in the startup scope. Thus, a configuration for the instance scope cannot be properly loaded unless the configuration values on which it depends (derived from startup scope, higher in the hierarchy) are loaded first.

Another thing to keep in mind is the use of *.properties files and the use of preferences. Preference databases hold values that tend to be applied to business data (e.g., data centers) across an installation, and are generally not application-specific. Property files on the other hand are typically system processes (e.g., services for a single location) where a single property file holds settings, or an XML file that contains all of the property files handles the settings. Depending on the order of the configuration sets using their order in the configuration.xml file and the priority attribute, you should save your configurations as designated by the table below.

Managing your Configurations

It is very important that the administrator clearly understand the location of the configuration sources, and the environment of the configuration source. A source located in a system folder is in most cases applied to a specific instance configuration in a particular environment. It should also be noted that some configuration sources are best managed with a *.xml file or a preference table, while for others it makes more sense to read a single or a set of property files.

The file environment.properties defines the environment for the ConfigurationSet with respect to the following characteristics:

• Process
  A process environment must have a "default" set of values; these values are then overwritten by other environments such as development, test (QA, customer, etc.), and production.

• Application
  An application environment denotes the type of Intershop Commerce Management installation, such as edit, live or both.

The system ships with build in configuration sets which define values in properties files inside cartridges. In order to allow to distinguish between different environments (like “production“ or “test“) file and domain-based configuration sets are supported.

Note