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 file where the reader, writer, finder, and scopes are defined for (and comprise) the ConfigurationSets. The file is found in <IS.INSTANCE.SHARE>/system/config/cluster and the source file in <core-cartridge-source>/staticfiles/share/system/config/cluster.

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="property" scope="ish,startup,instance,cluster,server,domain" required="true" filename="${system.intershop.HomeDirectory}/intershop.properties" />

References

• Concept - Configuration (valid to 7.10.11)
• 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 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 data base that can be read from/written to in the backoffice.

(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 is dependent 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 in the configuration.xml file, 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 environment for your configurations must be placed in the file name of the configuration files. The file environment.properties defines the current environment that you are in (for example, datacenter1). Within this file, there is the key-value pair environment = <value>.

You can view the the configuration for a specific scope (Application Server in our example) in the System Management application. Refer to its online help for details.