Guide - Intershop Application Server Settings

Table of Contents

Product Version

7.7

Product To Version


Status

final

1 Introduction

Info

This guide outlines the general configuration options with respect to the Intershop Application Server. This document is addressed to system administrators or DevOps who configure, maintain and monitor Intershop Commerce Management instances.

Info

Prior to Intershop version 7.7 the information provided in this document were part of the Administration and Configuration Guide that can be found in the Knowledge Base.

The Intershop Application Server comprises an instance of the Apache Jakarta Tomcat application server loaded with the ORM engine, the core cartridge and the Intershop Commerce Management business logic cartridges.

The basic settings that apply to the Intershop Application Server in the cluster are stored in the appserver.properties file located in <IS.INSTANCE.SHARE>/system/config/cluster/. The appserver.properties file is processed on server startup. When changing application settings, you have to restart the application server for the changes to take effect.

Note

All relevant setup options are to be configured in advance via dedicated deployment script files, before actually executing the deployment. So be aware that if you modify the Intershop Commerce Management configuration after it is deployed, the next deployment will override all changes with the settings specified for your deployment.

1.1 Glossary

TermDescription
Intershop Application Server (IAS)The "Intershop Application Server" is an Intershop Commerce Management setup component. It is an instance of the application server that automatically loads the Intershop Commerce Management application cartridges from the Intershop Shared Files instance. It can be installed individually for a distributed deployment.
application serverThe Apache Jakarta Tomcat application server makes the operating environment for all Intershop Commerce Management applications. It provides (at least) the JSP and servlet engine and HTTP(S) connectivity. The application server comes out of the box with Intershop Commerce Management and is installed with every Intershop Application Server.
Intershop Shared Files (ISF)"Intershop Shared Files" is an Intershop Commerce Management setup component. It is an instance of the file-based data storage system, which can be installed individually for a distributed deployment. In its system area, the ISF instance holds the cartridges that provide the business logic of Intershop Commerce Management.

1.2 Reference

You should be familiar with the main concepts of the Intershop Commerce Management infrastructure.

2 Global vs. Instance-Specific Configuration

By default, the global properties file (<IS.INSTANCE.SHARE>/system/config/cluster/appserver.properties) controls the behavior of all application instances in a cluster. Server instance specific settings, however, are stored in dedicated local configuration files such as appserver0.properties, appserver1.properties for each existing application server, and are located in <IS.INSTANCE.LOCAL>/config.

If you want to change a certain setting for a single server instance, copy the corresponding property from the shared file appserver.properties in <IS.INSTANCE.SHARE>/system/config/cluster/ to the configuration file of the server instance in <IS.INSTANCE.LOCAL>/config and edit it as needed. The settings in the local properties file will override the global application settings.

Technically, all properties can be set as server instance specific.

3 Sensitive Properties Settings

Intershop Commerce Management can exclude sensitive properties from being displayed in the administrative UI clients, like, for example, the monitoring module of the System Management application. This behavior is controlled by the monitoring cartridge. The configuration file monitor.properties (located in <IS.INSTANCE.SHARE>/system/config/cartridges) includes the property intershop.cartridges.monitor.sensitiveProperties, which lists the properties to be hidden.

The actual location of the properties listed in intershop.cartridges.monitor.sensitiveProperties is irrelevant, that is, they may reside in any of Intershop Commerce Management's *.properties files.

The default setting for sensitive properties is:

intershop.cartridges.monitor.sensitiveProperties= \
  intershop.encryption.passphrase \
  intershop.jdbc.user \
  intershop.jdbc.password \
  intershop.cartridges.bc_organization.organization.default.adminUserPassword \
  intershop.jdbc.ucp.User \
  intershop.jdbc.ucp.Password

4 Fail-Over Settings

An IAS process sends out event messages (default multicast) regarding its own status every couple of seconds and receives similar data from the other IAS instances in the cluster. In this way, each IAS is able to track all running IAS instances in the cluster and maintain a list of known instances. To remove server instances that have become unavailable, this list is cleaned up regularly by an expiration thread. Each registered IAS that does not re-register itself within a certain time-out period becomes unknown and is removed.

The fail-over timing can be configured in the appserver.properties file. The following options are available:

PropertyDescription
intershop.registration.registrationTimeThe time in seconds after which each IAS repeats the broadcast of its own registration event, that is, the multicast message containing the host IP, port and server groups. The default value is 10.
intershop.registration.expirationTime

The time in seconds after which a registration at another application becomes invalid. The default value is 30.

This value must be larger than the value for intershop.registration.registrationTime .

The Web Adapter regularly updates its configuration by querying the configuration servlet and thus controls the time after which an "expired" IAS is unregistered. This poll interval is configured in the global webadapter.properties file. The default setting is

#  Configuration Servlet Communication Options
cs.poll.interval = 10

This means, that with a registration interval of 10 seconds, an expiration interval of 30 seconds, and a Web Adapter poll interval of 10 seconds, the maximum time needed for a fail-over is 40 seconds. This assumes that the IAS crash happens immediately after sending its registration event and that the Web Adapter updates its configuration immediately before the registration expires, as shown in the following figure.

5 Startup Retry Settings

In case of exceptions on IAS startup, e.g., due to a slow database startup, the server can retry to startup. The following table lists the properties that control this behavior:

Property

Type

Description

intershop.startup.retryOnError

Boolean

Enables the startup retry in case of exceptions. The default value is false .

intershop.startup.retryCount

Integer

Limits the number of retries (1...maxint). If the value is out of that range, missing or invalid, then the retries are executed endlessly until the server starts without error or is stopped manually.

intershop.startup.retryInterval

Integer

Defines the waiting time (in seconds) between subsequent server startup attempts.

6 Graceful IAS Shutdown

Intershop Commerce Management provides a graceful IAS shutdown mechanism that makes sure that no request gets lost when shutting down an application server. According to this mechanism, the system first unregisters the application server from the cluster to which the application server belongs when receiving a shutdown request. However, the actual shutdown is initiated only after a certain time period. Due to the time period, the application server can finish any active request it is currently serving. In addition, the Web Adapter can recognize that the application server is unavailable, hence stop forwarding new requests to this server.

The time period between unregistering an application server from a cluster and actually shut down can be configured using the property

intershop.shutdown.gracePeriod

The value must be provided in seconds. Note that the value should be at least as large as the value for cs.poll.interval (which controls the interval in which the Web Adapter checks for available application servers in a cluster, see Fail-Over Settings), plus some additional time to complete any active request it may have received from the Web Adapter. For example, if cs.poll.interval is set to 10 seconds (which is the default setting), intershop.shutdown.gracePeriod might be set to 30 seconds.

7 CPU Affinity Settings

If Intershop Commerce Management resides on a multi-core/multi-processor machine, you can individually bind each server process to a specific "logical CPU" before you start the system.

CPU binding applies to "logical CPUs" as recognized by the operating system. With certain processor technologies, the number of logical CPUs does not necessarily have to match the number of physical processors or processor cores on your server. For the purpose of this description, the CPU affinity applies to a logical CPU, be it a processor, a processor core or a processor thread.

You must know the ID of each online logical CPU on the machine. Depending on the hardware configuration used, the IDs of the logical CPUs may not be allocated in consecutive order.

Set the affinity of a server process to a logical CPU in the server instance specific configuration file appserver#.properties, located in <IS.INSTANCE.LOCAL>/config. The according key is

intershop.cpu.id=

If this line is commented out or no value is set, the server process will run unbound, i.e., on all logical CPUs. Otherwise, the server process will run on the specified logical CPU. However, if the specified logical CPU does not exist or is switched off, then the server process will run unbound to ensure that Intershop Commerce Management continues running uninterrupted.

Binding a server process of the Intershop Commerce Management application to a specific logical CPU moves this IAS process to the specified logical CPU. This means that this server process will no longer reside on any other logical CPU.

Depending on the Intershop Commerce Management license you have acquired, CPU binding may be necessary in order to meet the license conditions. For example, if you have acquired a single CPU license for Intershop Commerce Management, you have to bind Intershop Commerce Management to a single logical CPU on a multi-core/multi-processor machine.

Contact Intershop if you have questions regarding the number of (logical) CPUs supported by your Intershop Commerce Management license.

8 Servlet Engine Settings

The IAS provides its own engine for servlet and JSP processing, including running configuration and request handler servlets. The internal servlet engine is based on Apache Tomcat. This section discusses important parameters to configure the internal servlet engine.

It is not possible to configure the internal servlet engine directly via a server.xml file.

PropertyDescription

intershop.servletEngine.connector.port

This defines the port which the internal servlet engine opens to handle incoming traffic from the Web Adapter. This port must be unique for each application instance on a host. The installation default setting, as defined in the localappserver#.properties, for one application in the first Intershop Commerce Management instance is 10054 .

intershop.servletEngine.connector.minProcessors


Each incoming request requires a thread to process it for the duration of that request. Upon server startup, the internal servlet engine creates a number of request processing threads, based on the value configured for the minProcessors attribute. In a standard installation, the value should be set to 10.

intershop.servletEngine.connector.maxProcessorsIf more simultaneous requests are received than can be handled by the currently available request processing threads, additional threads will be created up to the configured maximum (the value of the maxProcessors attribute). In a standard installation, the value should be set to 75.
intershop.servletEngine.connector.acceptCountIf still more simultaneous requests are received, they are stacked up inside the server socket, up to the configured maximum (the value of the acceptCount attribute). Any further simultaneous requests will receive "connection refused" errors, until resources are available to process them. In a standard installation, the value should be set to 300.
intershop.servletEngine.connector.addressThis property can be used to define a specific IP address from which requests are accepted. This can be used, for example, to route traffic for ORM cache synchronization and web front traffic through separate interfaces (see Application Configuration on Multihomed Hosts). If no address is provided (default), the servlet engine accepts requests from all available network interfaces.

9 Application Configuration on Multihomed Hosts

Depending on your installation scenario, the expected traffic or security requirements, it may be necessary to separate the network traffic of the application server machines and to direct it to a dedicated network interface. Thus, you can separate, for instance, ORM cache synchronization from Web front traffic.

The following example illustrates the necessary configuration. Assuming your application server machine provides two network interfaces (192.168.2.1 and 192.168.3.1), you can handle the ORM cache synchronization via 192.168.2.1, and the web front traffic and event multicast traffic via 192.168.3.1. To do so, edit the following properties:

PropertyDescriptionExample Value

intershop.cacheSync.multicastInterface

Specifies the IP interface to be used for ORM cache synchronization (see Guide - ORM Engine Administration).

Note that this property is part of the orm.properties file (in <IS.INSTANCE.SHARE>/system/config/cluster/), which defines settings applicable to all hosts in a cluster. However, to define a machine-specific interface address, you have to add this property to the corresponding local appserver#.properties file in <IS.INSTANCE.LOCAL>/config. This overloads any cluster-wide setting in the orm.properties.

192.168.2.1
intershop.event.multicastInterface

Specifies the IP interface to be used for event multicast (see Guide - Messaging).

Edit the property in the corresponding local appserver#.properties file in <IS.INSTANCE.LOCAL>/config.

192.168.3.1
intershop.servletEngine.connector.address

Specifies the IP interface to be used for Web Adapter traffic (see Servlet Engine Settings).

Edit the appserver.properties file in <IS.INSTANCE.SHARE>/system/config/cluster/.

192.168.3.1

10 Managing Process Chains

Intershop Commerce Management implements a mechanism for creating and executing process chains. Process chains help to automate the sequential execution of interdependent scheduled jobs or pipelines.

Defining a process chain involves, basically, the following tasks:

  • Specifying the chain elements, i.e., the jobs or pipelines to be processed
  • Creating a scheduled job that triggers the execution

10.1 Specifying Process Chain Elements

Administrators can define process chains using XML files to be located in <IS.INSTANCE.SHARE>/system/config/cluster. Note that the default installation includes an example file, processchain.xml.example.

The main configurable elements include:

ElementDescription
<chain>The root element of the process chain XML file. Important attributes include name (used in the System Management module Monitoring|Locking|Processes) and keepAliveTime, which defines the time that threads that exceed the core pool size may remain idle before being terminated.
<concurrent>Child element of <chain> or <sequence>. Includes jobs or pipelines to be executed in parallel. The attribute name is used in the System Management module Monitoring|Locking|Processes.
<sequence>Child element of <chain> or <concurrent>. Includes jobs or pipelines to be executed sequentially in the given order. The attribute name is used in the System Management module Monitoring|Locking|Processes.
<job>

Child element of <sequence> or <concurrent>. Specifies a job to be executed within the chain. The attributes for <job> include

Attribute

Description

job

Specifies the name of the job as defined in the System Management Schedules module (mandatory).

name

Specifies a display name for this job to be used in the Monitoring|Locking|Processes module.

domain

Can define a specific domain for the job execution (optional). By default, the chain element job is executed in the domain of the process chain.

allsites

Can specify whether the job executes in all domains (true|false), default is false.

concurrent

With allsites=true, can specify whether the job executes in parallel in all domains (true|false), default is false.

<pipeline>

Child element of <sequence> or <concurrent>. Specifies a pipeline to be executed within the chain. The attributes for <pipeline> include

Attribute

Description

pipeline

Specifies the name of the pipeline to be executed.

name

Specifies a display name for this pipeline to be used in the Monitoring|Locking|Processes module.

domain

Can define a specific domain for the pipeline execution (optional). By default, the chain element pipeline is executed in the domain of the process chain.

startnode

Can define a specifc pipeline start node (optional), default is Start.

login

Can define the login name that the pipeline to be executed may require.

password

Can define the password if the pipeline to be executed requires a specific login.

<error>

Optional child element of <sequence>. Specifies a dedicated <job> or <pipeline> that is to be executed in case the preceding jobs or pipelines within the <sequence> have failed.

Make sure that <error> is the last element within the corresponding <sequence>.

<parameter>Optional child element of <pipeline>. Can specify the parameter that the pipeline to be executed may require.
<description>Optional child element of <sequence>, <concurrent>, <job> or <pipeline>. Specifies a description to be displayed in the System Management module Monitoring|Locking|Processes.
<ignore>Optional child element of<sequence>, <concurrent>, <job> or <pipeline>. Can specify status codes (SUCCESS|WARNING|FAILURE|ERROR|NOTFOUND| INTERRUPTED) returned from the corresponding chain element on execution that should be ignored for rest of the process chain execution. This way, the process chain execution can continue in case of errors in one of its sub tasks.

10.2 Executing Process Chains

For process chains to be executed, administrators must create and configure a scheduled job that triggers the pipeline ExecuteProcessChain included with the Intershop Commerce Management core cartridge. This involves the following steps:

  • Creating a new scheduled job
    For details about scheduled job creation, refer to the System Management online help. Make sure to specify the pipeline ExecuteProcessChain and the start node Start.
  • Adding the XmlFileName attribute to the new job
    The pipeline ExecuteProcessChain requires the path to the process chain configuration XML file as the input parameter XmlFileName. That is why you must add an attribute XmlFileName to the job. Its value must be of the data type String, and must specify the complete path and file name of the configuration file relative to <IS.INSTANCE.SHARE>, e.g., system/config/cluster/processchain.xml.
  • Configuring the process chain execution
    Define the recurring interval, specific login and password, etc. as necessary. For details, see the System Management online help.

The process chain will be executed according to your settings.

11 Data Encryption/Decryption Options

In order to ensure PCI DSS compliance, Intershop Commerce Management features a key management framework. It allows, among others, for

  • handling multiple encryption/decryption phrases,
  • decrypting using a legacy phrase and re-encrypting using a new phrase,
  • defining various encryption/decryption algorithms.

Administrators can define passphrases, passphrase IDs, algorithms and a default option using the encryption.properties file, located in <IS.INSTANCE.SHARE>/system/config/cluster. The table below lists the corresponding properties. Note that <#> specifies the encryption/decryption settings count.

Property

Description

intershop.encryption.algorithms

Specifies a (comma separated) whitelist of all supported encryption algorithms. If not set, all algorithms are enabled. If a requested algorithm ( intershop.encryption.<#>.algorithm ) is not listed, a NoSuchAlgorithmException is thrown.

intershop.encryption.<#>.id

Specifies the ID of the encryption/decryption passphrase.

intershop.encryption.<#>.algorithm

Specifies the algorithm used for encrypting/decrypting sensitive data.

intershop.encryption.<#>.default

Specifies whether the current encryption/decryption settings constitute the default (true|false).

intershop.encryption.keystore.provider

Specifies the name of the provider class that manages the encryption key.

intershop.encryption.keystore.filename

Specifies the name of the Java keystore file. Its base directory is <IS.INSTANCE.SHARE>/sytem/config/cluster , and the default value is intershop.keystore .

intershop.encryption.keystore.password

Specifies the variable part of the current keystore password, intended to be modified by Intershop Commerce Management administrators. Can contain up to 90 alphanumeric characters.

intershop.encryption.keystore.password.change

Specifies the variable part of the new keystore password in case it is modified.

intershop.encryption.keystore.create

Controls whether Intershop Commerce Management does create (true ) or does not create ( false ) a new keystore file on server start if there is none available.

intershop.encryption.random.filename

Specifies the name of the file that contains the random part of the keystore password. Its base directory is <IS.INSTANCE.SHARE>/sytem/config/cluster , and the default value is random .

intershop.encryption.random.filename.change

Specifies the name of the new file that contains the random part of the keystore password in case it is modified.

intershop.encryption.random.create

Controls whether Intershop Commerce Management does create (true) or does not create (false) a new random part file on server start if there is none available.

12 Mail Server Settings

Intershop Commerce Management can be configured to send various notifications to users by e-mail. For these notifications to work, the appserver.properties file must specify a mail server and a number of corresponding settings.

For simple scenarios, you can use the following Intershop Commerce Management-specific properties:

Property

Type

Description

intershop.SMTPServer

String

Specifies the SMTP (outgoing) mail server, which is used for the notification mechanism.

intershop.mail.messageID.setByAppserver

Boolean

Specifies whether or not (true|false) to include the Message-ID header from outgoing mails.

intershop.mail.messageID.domain

String

Specifies the domain used in the Message-ID header of outgoing mails.

For more complex scenarios that require authentication, secure transport etc., use the properties listed in the table below. These properties are supported by the standard javax.mail.Session implementation.

Property

Type

Description

mail.smtp.host

String

Specifies the SMTP (outgoing) mail server, which is used for the notification mechanism.

mail.smtp.port

Integer

Specifies the port of the SMTP server to be used. The default is 25, the preferred port, however, is 587 (RFC 2476).

mail.transport.protocol

String

Specifies the mail transport protocol, the default for outgoing mail is SMTP.

mail.smtp.auth

Boolean

Specifies whether or not (true|false) to use mail user authentication. If true, mail.smtp.user and mail.password must be set.

mail.smtp.starttls.enable

Boolean

Specifies whether or not (true|false) to use the STARTTLS command (if supported by the server) to switch the connection to a TLS-protected connection before issuing any login commands.

mail.smtp.tls

Boolean

Specifies whether or not (true|false) to attempt TLS negotiation.

mail.smtp.user

String

Specifies the SMTP user name.

mail.password

String

Specifies the password of the SMTP user.

13 Search Engine Settings

To provide powerful storefront search options, like full-text search or dynamic navigation, Intershop Commerce Management integrates third-party search engines via dedicated adapter cartridges. Intershop ships Apache Solr as the standard search option.

The settings discussed in this section do not refer to SEO-specific properties. For SEO settings, refer to Web Search Engine Optimization.

13.1 Multi-Threaded Search Index Creation

With an integrated external search engine, Intershop Commerce Management creates search indexes using multiple threads. This helps to improve the performance when large amounts of data are to be processed.

The multi-threaded search index creation is enabled by default and configured using reasonable default settings. System administrators can, however, overwrite the default settings via corresponding properties in <IS.INSTANCE.SHARE>/system/config/cartridges/bc_search.properties.

PropertyDescription
intershop.search.indexcreation.network.corePoolSizeDefines the number of threads that are kept in the pool, even if they are idle. The default value is 30.
intershop.search.indexcreation.network.maximumPoolSizeDefines the maximum number of threads allowed in the pool. The default value is 35.
intershop.search.indexcreation.network.keepAliveTimeDefines the time (in seconds) that threads that exceed the core pool size may remain idle before being terminated. The default value is 1.
intershop.search.indexcreation.source.queueLengthDefines the length of the queue that feeds the retriever, that is, the queue to which the source worker writes. The default value is 1000.
intershop.search.indexcreation.retriever.workerCountDefines the number of threads initially created for retrieving the information that will be indexed. The actual number will be automatically adjusted to the workload. As one worker is needed for unpacking and another one for retrieving the data, make sure that retriever.workerCount is less or at least equal to <corePoolSize> - 2. The default value is 15.
intershop.search.indexcreation.retriever.queueLengthDefines the length of the queue that feeds the unpacker, that is, the queue to which the retriever writes. The default value is 1000.
intershop.search.indexcreation.unpack.queuelengthDefines the length of the queue that feeds the index writer, that is, the queue to which the unpacker writes. The default value is 1000.
To allow for a search feature-specific configuration, the global values can be overwritten. To this end, system administrators can define properties that contain the FeatureID (as set by the search engine adapter cartridge), like, for example, intershop.search.SFProductSearch.solr.indexcreation.network.corePoolSize.

13.2 Oracle Text Search Options

In case no external search engine is integrated, Intershop Commerce Management Web front applications use the Oracle Text Search. The global appserver.properties file contains additional properties that control the treatment of escaped characters in the Oracle Text Search.

PropertyDescription
oracle.context.enclosingChars.removeIf set true (default), multiple enclosing characters are removed to prevent "DRG-50937: query too complex" errors (with enabled or forced substring search only.)
oracle.context.enclosingCharsContains a list of the removable enclosing characters.

14 Web Search Engine Optimization

Intershop Commerce Management storefront pages are optimized for internet search engines by means of specific title and meta tags. Generally, SEO is managed by users in the Commerce Management application. For detailed information about SEO attribute handling in Commerce Management, please consult the user guide Managing Online Shops or the Commerce Management online help.

The settings discussed in this section do not refer to the integrated search engine. For the Intershop Commerce Management search engine settings, refer to Search Engine Settings.

There are dedicated properties files that define default values for the automatically generated SEO-specific meta texts, MetaTexts.properties. There may be individual files for each application or site and, for unknown applications or sites, for the entire cluster. These files are located in

  • <IS.INSTANCE.SHARE>/sites/<site>/<version>/applications/<application>/seo for individual applications,
  • <IS.INSTANCE.SHARE>/sites/<site>/<version>/units/<site>/seo for individual sites,
  • <IS.INSTANCE.SHARE>/system/config/cluster/seo for the cluster

The lookup (or fallback) path is

(1) application-specific properties

(2) site-specific properties

(3) cluster-specific properties

You can pre-define language-specific meta texts using language-specific meta text properties MetaTexts_<language>.properties.

By default, Intershop Commerce Management provides the following keys (and example values for the reference storefront) in the MetaTexts_*.properties:

CategoryTitleSuffix=\ always special prices for\
CategoryDescriptionSpecial=\ always special prices for\ 
CategoryDescriptionAnd=\ and\ 
CategoryKeywordsSuffix=\ Buying online, shop, PrimeTech
ProductTitleSuffix=\ favourable buying at PrimeTech
ProductKeywordsSuffix=\ Buying online, shop, PrimeTech

15 Object Locking Settings

Intershop Commerce Management provides a correlated locking mechanism for objects that can be locked by users in the Commerce Management application. This mechanism allows to prevent conflicts between editing operations in Commerce Management, publish-to-live processes and mass data operations like import processes or data replication. Currently, this feature is used for product objects and content-related objects (pages, page variants, components, etc.) only.

The following settings in the appserver.properties file control specific aspects of the locking mechanism:

PropertyDescription
intershop.locking.correlatedLockingEnabledSpecifies whether the correlated locking of instance resources and named resource is enabled or not (true|false). The default value is true. Note that if set false, Commerce Management does not display the corresponding warnings and the lock conflict resolution options.
import.locking.acquisition.timeoutSpecifies the acquisition timeout (in seconds) for import processes started via Commerce Management. The default value is 60. Note that this property is evaluated only if intershop.locking.correlatedLockingEnabled=true, and if the import processes are started via Commerce Management (otherwise the import-specific timeouts configured via the impex framework are used).

In addition, the file <IS.INSTANCE.SHARE>/system/config/cluster/staging.properties includes object locking-relevant settings:

PropertyDescription
staging.objects.locking.acquisition.timeoutSpecifies the acquisition timeout (in seconds) for publish-to-live processes started via Commerce Management. The default value is 60. Note that this property is evaluated only if intershop.locking.correlatedLockingEnabled=true.
staging.objects.locking.acquisition.namedResourceThresholdSpecifies the threshold to switch from instance resource acquisition to named resource acquisition for publish-to-live processes. The default value is 150 (a sensible value depends on your system performance). Note that this property is evaluated only if intershop.locking.correlatedLockingEnabled=true.

16 Multi-Threaded Export Settings

The export framework of Intershop Commerce Management generally allows for executing multiple export threads in parallel in order to improve the performance when exporting large amounts of data. Currently, the user profile export and the product export are prepared and configured to make use of the multi-threaded export capabilities by default.

On a project-specific base, you can implement the multi-threaded export capabilities in other areas as well.

Once prepared, system administrators can then switch on or off this feature, and set specific performance parameters. The corresponding configuration is defined in

  • <IS.INSTANCE.SHARE>/system/cartridges/bc_foundation/release/impex/config/UserExport.properties for user profile data exports, and
  • <IS.INSTANCE.SHARE>/system/cartridges/cartridges/bc_mvc/release/impex/config/ExportCatalog.properties for product data exports.

The following settings control the multi-threaded export behavior:

Property

Type

Description

Export1.MultiThreading.Enabled

Boolean

Enables or disables (true|false) the multi-threaded export.

Export1.MultiThreading.MaxThreadCount

Integer

Limits the maximum number of threads when multi-threading export is enabled. The recommended default value is <number_of_CPUs>*2.

Export1.MultiThreading.BatchSize

Integer

Specifies the number of export objects that are provided to a single export thread when multi-threaded export is enabled (default 15).

Export1.MultiThreading.HeaderTemplateName

String

Specifies the name of the template to be used to create the export header.

Export1.MultiThreading.FooterTemplateName

String

Specifies the name of the template to be used to create the export footer.

Export1.MultiThreading.CopyPipelineDictionary

Boolean

Specifies whether or not (true|false) to copy the pipeline dictionary to each export task (default false). Should be active in case the export works on additional dictionary values besides the export data iterator.

Export1.MultiThreading.ExportIteratorName

String

Specifies the name of the iterator that holds the export data in multi-threaded mode.

17 User Login and Password Rules

In Intershop Commerce Management, the system administrator can centrally configure domain-specific login and password rules using the configuration file usercredentialrules.properties, located in <IS.INSTANCE.SHARE>/system/config/cluster. The system checks this configuration file on IAS startup. In case new settings are detected, or there are changes to existing ones, the system automatically triggers the necessary updates, inserts, or deletions in the database.

Check the example file <IS.INSTANCE.SHARE>/system/config/cluster/usercredentialrules.properties.example.

The system domain settings, as listed below for illustration purposes, are enabled with the Intershop Commerce Management core. They serve as a fallback, but they can, however, be customized using the usercredentialrules.properties file.

system.PasswordValidators = PasswordExpressionValidator, PasswordHistoryValidator
system.PasswordExpirationNotificationPeriod = 5
system.PasswordExpirationPeriod = 90
system.LoginFailureLockoutCount = 6
system.LoginFailureLockoutDuration = 30
system.UserLoginExpression = 1,256,^\\S+$
system.UserLoginDescription = The login name must be between 1 and 256 characters long and can contain any characters with the exception of whitespace characters.
system.PasswordLoginExpression = 5,256,^\\S+$
system.PasswordLoginDescription = The password must be between 5 and 256 characters long and can contain any characters with the exception of whitespace characters.
system.PasswordRepeatPreventionCount = 4
system.PasswordRepeatPreventionDescription = The password must not repeat the previous 4 passwords.

For sales channel storefronts, only PasswordExpressionValidator is used as password validator by default.

By default, Intershop Commerce Management does not define domain-specific login and password settings. To enable them, create a corresponding usercredentialrules.properties file, and specify the rules for your domains. You can use <IS.INSTANCE.SHARE>/system/config/cluster/usercredentialrules.properties.example as an example.

The usercredentialrules.properties file can specify the applicable login and password rules with respect to the login name and password length and the allowed characters, as well as a parent rule domain and a rule description. In addition, this file can define password expiration rules and user account lockout settings. Generally, the available properties include:

PropertyDescription
<domain>.ParentRuleOwner

Specifies the domain where rules will be searched if no rules are found for the specified domain.

<domain>.ParentRuleOwner = <domain>

If no parent domain is specified, the system domain is used as a fallback.

<domain>.PasswordValidatorsSpecifies possible validators that will be used to validate the password, using provider names delimited by comma. Intershop Commerce Management includes two providers, PasswordExpressionValidator and PasswordHistoryValidator. Note that custom providers must implement the interface com.intershop.beehive.core.capi.user.PasswordValidator.
<domain>.PasswordExpirationNotificationPeriodSpecifies the number of days a user is warned before the password expires. During this period, the user can choose whether to update the password or to continue without changing the password on login.
<domain>.PasswordExpirationPeriodSpecifies the number of days a password is valid. After this period has expired, the user is prompted to change the password immediately upon a login attempt.
<domain>.LoginFailureLockoutCount

Specifies the maximum number of login attempts a Commerce Management user can make using a wrong password. After this number is reached, the user account is locked for the period defined in <domain>.LoginFailureLockoutDuration.

A locked user account can be unlocked manually via the User Manager in the Commerce Management application.

<domain>.LoginFailureLockoutDurationSpecifies the time (in minutes) a user account is locked after the number of failed login attempts (<domain>.LoginFailureLockoutCount) has been reached.
<domain>.UserLoginExpression

Specifies the rules to apply for the minimum and the maximum login length as well as the allowed characters, using the following syntax:

<domain>.UserLoginExpression = <minimum length>,<maximum length>,<regular expression>

<minimum length> and <maximum length> are positive integers, <regular expression> is an expression that defines the characters allowed for login names.

<domain>.UserLoginDescription[_Locale]Specifies a (locale-specific) description of the defined login name rules, which is displayed to the user.
<domain>.PasswordLoginExpression

Specifies the rules to apply for the minimum and the maximum password length as well as the allowed characters, using the following syntax:

<domain>.PasswordLoginExpression = <minimum length>,<maximum length>,<regular expression>

<minimum length> and <maximum length> are positive integers, <regular expression> is an expression that defines the characters allowed for passwords.

<domain>.UserPasswordDescription[_Locale]Specifies a (locale-specific) description of the defined password rules, which is displayed to the user.
<domain>.PasswordRepeatPreventionCountSpecifies the number of previous passwords a user cannot reuse. That is, a value of 4 would prevent a user from reusing one of his four last passwords.
<domain>.PasswordRepeatPreventionDescription[_Locale]Specifies a (locale-specific) warning, which is displayed to the user stating the number of previous passwords not to be reused.

18 User Tracking Options

By default, an Intershop Commerce Management web front sends a cookie to the client browser in every session. These cookies can be used to identify users when they return to the application.

18.1 General Cookie Settings

This section lists the user tracking properties as included with the global appserver.properties file.

Property

Type

Description

intershop.user.cookie.enabled

Boolean

Sets an extra cookie to track the user ID; the default value is true.

intershop.user.cookie.name

String

The ID of the cookie at the client browser; the default is userid.

intershop.user.cookie.comment

Text

A description of the cookie. This is displayed if users ask to accept each cookie manually.

intershop.user.cookie.maxage

Integer

The expiry time of the cookie in milliseconds. Set the value to -1 (default) for the cookie to expire when the browser is closed; a value of 86400000 lets the cookie expire after one day.

18.2 Cookies for Multiple Sub-Domains

By default, cookies are set to the domain for which the request has occurred. A request to the domain www.example.com, for example, would result in cookies that are only valid for the domain www.example.com. Since merchants may run their site on mobile.example.com and www.example.com, they have to share the cookies. To this end, the domain field for the cookie must be set to .example.com.

Some core features of Intershop Commerce Management support the configuration for the domain field of a cookie. This is done via cookie-specific domain settings to be specified either in the global appserver.properties file or in application-specific *.properties files (in (<IS.INSTANCE.SHARE>/system/config/apps/<APP.ID> ). The following table lists these options.

Property

Type

Description

intershop.user.cookie.domain

String

Defines the domain for which user cookies are valid.

intershop.basket.cookie.domain

String

Defines the domain for which shopping cart cookies are valid.

intershop.abtest.cookie.domain

String

Defines the domain for which A/B test cookies are valid.

intershop.recentlyvieweditems.cookie.domain

String

Defines the domain for which recently viewed items cookies are valid.

Following the example above, these properties could look like this:

intershop.user.cookie.domain=.example.com
intershop.user.authenticationstatetokencookie.domain=.example.com
intershop.basket.cookie.domain=.example.com
intershop.abtest.cookie.domain=.example.com
intershop.recentlyvieweditems.cookie.domain=.example.com

In addition to these cookie domain settings in appserver.properties , the Web Adapter must be configured accordingly. To do so, the corresponding Web Adapter session handling settings, as explained in Guide - Web Adapter Settings, must set the domain field in the PGID and SID cookie generation in the webadapter.properties file.

session.SIDCookie = Set-Cookie: sid=%v; Path=/; \
                    Domain=.example.com; Version=1
session.PGIDCookie = Set-Cookie: pgid-%s=%v; Path=/; \
                     Domain=.example.com; Version=1

19 Session Handling Options

Session handling is a task shared between Web Adapter and IAS. The Web Adapter generates the session ID and keeps track of the session ID when interacting with clients (for example, by encoding the session ID in the URL or using cookies, see Guide - Web Adapter Settings.) The IAS creates a session object for each generated session ID, which makes it possible to store session data or for other processes to access session data.

Intershop Commerce Management features several options that determine how the IAS deals with sessions. These options, as set in the global appserver.properties file, are detailed in the following table.

Property

Type

Description

intershop.session.TimeOut

Integer

Time-out of an application server session object in minutes after the last request.

intershop.session.AllowPersistent

Boolean

Allows the persistent storage of session information in the database. This is necessary if you want to continue a session after a server has become unavailable (session fail-over), the default value is true.

intershop.session.RestoreExpiredSessions

Boolean

Allows to restore a session that has timed out. The default value is false.

intershop.session.CheckRestoredSessions

Boolean

In fail-over scenarios using multiple application servers, this setting forces re-reading of recovered session information from the database on subsequent requests. Commented out by default.

20 Schedule Execution Options

Intershop Commerce Management supports the automatic, recurrent execution of business workflow processes, or pipelines. At defined dates and times, the job processor triggers the scheduled pipeline.

For an overview of pre-configured jobs in Intershop Commerce Management, refer to Reference - Intershop 7.6 Jobs.

Irrespective of the settings made in the System Management application, the appserver.properties file contains the master control for automatic schedule execution. The property intershop.job.enabled controls whether schedules are processed or not. By default, it is set true.

intershop.job.enabled=true

For server maintenance or troubleshooting, you may wish to disable the automatic schedule execution. In this case, edit the property intershop.job.enabled and set it to false.

The maximum number of schedules that can be run in parallel is controlled by the property intershop.job.maxJobNumber . A schedule is locked and marked as "running" in the database before execution; and the scheduled pipeline itself may open another database transaction. This means, a schedule needs at least one and may have at most two database connections. Therefore, intershop.job.maxJobNumber is limited to the maximum number of server database connections divided by two. The installation default is

intershop.job.maxJobNumber=5

If the number of database connections of your Intershop Commerce Management installation differs from the default value 10, change intershop.job.maxJobNumber accordingly.

A higher number of parallel schedules increases demands on the Intershop Commerce Management system resources.

The number of days that a finished scheduled job will be available is controlled using intershop.job.history.expiration . The installation default value is

intershop.job.history.expiration=2

21 Web Server URL Settings

The Intershop Commerce Management application must know the host name and port of its corresponding web server when the information used in the original request is not available. The host-specific URL settings are stored in the appserver.properties file, and the corresponding values are set during Intershop Commerce Management installation. The defaults are:

intershop.WebServerURL=http://<SYSTEM.HOST.NAME>:80
intershop.WebServerSecureURL=https://<SYSTEM.HOST.NAME>:443

Note that in the example above, <SYSTEM.HOST.NAME> refers to the URL that is visible externally. In typical deployment scenarios using multiple Web Adapters connected to a load balancer, <SYSTEM.HOST.NAME> therefore refers to the DNS name and port belonging to the virtual IP of the load balancing device, and not to the DNS name and port of the machine hosting the web server. This would only be the case if only one web server is used, without an additional load balancer.

For multi-channel environments or data replication environments, you may have to define multiple host names. In a data replication environment, the live servers may use more then just one host name (e.g., for replicating XML sitemaps). In multi-channel environments, each channel may have an individual DNS host name, which is reflected by different individual URLs.

To support this, you can configure domain-specific or application-specific host names for URLs. The configuration is stored in url.properties files that are located in the <IS.INSTANCE.SHARE>/system/config/domains/<domain> or, respectively, <IS.INSTANCE.SHARE>/system/config/apps/<application> . The following example illustrates domain-specific host names for "example":

intershop.WebServerURL=http://edit.example.com:81
intershop.WebServerSecureURL=https://edit.example.com:444
intershop.WebServerURL.live=http://www.example.com:80
intershop.WebServerSecureURL.live=https://www.example.com:443

22 URL Handling

Generally, there are four options for modifying Intershop Commerce Management URLs:

  • URL configuration
    URL configuration (or URL renaming) enables you to configure the first part of the URLs that comes immediately after the host name. Additionally, you can adjust the mapping parameters to specify the content that is triggered, such as pipelines, static resources (images) and so on.
    URL configuration is enabled and configured in the global appserver.properties file. For more details, see URL Configuration.
  • URL rewriting
    URL rewriting is a mechanism that enables Intershop Commerce Management sites to publish search engine friendly URLs. URL rewriting is only available for pipeline calls. For example, you can define rules so that you can predefine parameters like locale or currency for specific domains and exclude them from the visible URL.
    The rules to be applied for rewriting the URLs are set in cartridge-specific urlrewrite.properties files. For more details, see URL Rewriting.
  • URL parameter whitelisting
    Dubious web sites or users may intend to infect Intershop Commerce Management URLs with bad parameters. This would lead to a massive downgrade of the cache hit ratio for the page cache and to an increased page cache size, which could finally result in a bad application server performance due to unnecessary requests.
    URL parameter whitelisting is a mechanism that allows Intershop Commerce Management to restrict URL requests to an allowed set of URL parameters. In the context of URL rewriting (see above), incoming requests can be checked for the valid set of parameters. As a result, invalid parameters are dropped and ignored.
    URL parameter whitelisting is enabled using the cartridge-specific urlrewrite.properties files. The set of allowed parameters can be defined upon development at the pipeline start node or using a specific pipelinewhitelistparameters.properties file. For more details, see URL Parameter Whitelisting.
  • Short links
    Short links are "hard-coded abbreviations" for complete Intershop Commerce Management URLs, which are used to map target URLs to short, search engine-friendly URLs. Short links are managed by users in Commerce Management. For more information, refer to the user guide Managing Online Shops or the Commerce Management online help.
With respect to URL handling, make sure to procure the intended DNS name entries.

22.1 URL Configuration

By default, the Intershop Commerce Management URL is structured as shown in the following:

http[s]://[servername]:[port]/[individual part]/[indvidual mapping parameter]/[servergroup]/[site id]/[locale]/[application URL identifier]/[currency]/[pipeline to call]

With the default parameters in an Intershop Commerce Management installation, it might look like this:

https://myserver:443/INTERSHOP/web/WFS/PrimeTech-PrimeTechSpecials-Site/de_DE/-/USD/ViewUserAccount-Start?

Within appserver.properties , the following parameters control the [individual part] and the [indvidual mapping parameter].

22.1.1 Individual Part

intershop.urlmapping.urlPrefix specifies the [individual part] of the URL, for example

intershop.urlmapping.urlPrefix=/INTERSHOP

The first character of the prefix must be a forward slash ("/"), the allowed characters include a-z,A-Z,0-9,-,_,/. The prefix must contain at least two characters, the maximum number is 64 (including the start slash).

Note

Do not uncomment this key. To disable the prefix, leave the value empty.

22.1.2 Web Adapter Mapping Parameters

intershop.urlmapping.*.webadapter keys specify the Web Adapter mapping parameters for individual request types, for example

intershop.urlmapping.pipeline.webadapter=${intershop.urlmapping.urlPrefix}/web
...
intershop.urlmapping.static.webadapter=${intershop.urlmapping.urlPrefix}/static
...

Parameter

Description

intershop.urlmapping.urlPrefix

Default value is set to either /INTERSHOP or /is-bin/intershop, and can be changed.

/INTERSHOP/web

Calls a pipeline.

/INTERSHOP/wsrp

You can set this parameter for WSRP (portal) requests.

/INTERSHOP/rest

Set this parameter for REST requests.

/INTERSHOP/static

Set this parameter for static content such as images.

/INTERSHOP/dist

Set this parameter for static system resources.

/INTERSHOP/servlet

Calls a servlet.

/soap

Set this parameter for SOAP requests.

/INTERSHOP/wastatus

Set this parameter for Web Adapter status requests.

/INTERSHOP/wastatistics

Set this parameter for Web Adapter statistics requests.

22.2 URL Rewriting

As already mentioned, URL rewriting provides one of several means that help optimizing Intershop Commerce Management sites for search engines. The default implementation of Intershop Commerce Management's URL Rewrite Handler uses cartridge-specific configuration files to retrieve the rules that define how Intershop Commerce Management URLs are transformed into search engine friendly URLs.

URL rewriting is only available for pipeline calls, not for static content like images.

These files, urlrewrite.properties , are stored for every concerned cartridge in <IS.INSTANCE.SHARE>/system/cartridges/<cartridge_name>/release/urlrewrite . To edit the rule settings, a sound knowledge of regular expressions is required. For details about actual rule configuration, examples, etc., refer toConcept - URL Handling and Cookbook - URL Handling (valid to 7.7).

URL rewriting is enabled individually per site via the Site Management module of the System Management application. The properties

intershop.urlrewrite.CheckSource
intershop.urlrewrite.CheckSourceInterval

as included in the global appserver.properties file, control the monitoring status and refreshing behavior for the URL rewriting (see also Miscellaneous Options).

The global urlrewrite.properties file, located in <IS.INSTANCE.SHARE>/system/config/cluster , allows for defining general rules that apply to the entire Intershop Commerce Management cluster. The following sections outline how these general rules may be used.

22.2.1 Mapping URL Parameters to Host Names

You can remove the default URL parameters domain , group , locale , appurlid and currency by defining an appropriate mapping to one or multiple host names. Assuming, for example, that the US/Dollar version of the PrimeTechSpecials reference storefront is running on www.primetech.com and www.techshop.com , the corresponding host name parameter settings would be:

domainsplitting.host_1.host = www.primetech.com www.techshop.com
domainsplitting.host_1.currency = USD
domainsplitting.host_1.appurlid = -
domainsplitting.host_1.locale = en_US
domainsplitting.host_1.domain = PrimeTech-PrimeTechSpecials-Site
domainsplitting.host_1.group = WFS

22.2.2 Specific URL Patterns

You can define specific URL patterns using the shortpathpattern property. In case you want the URL to include, for example, an application ID segment and a locale segment after the domain name (and followed by the rest of the Intershop Commerce Management URL path), use

domainsplitting.host_1.shortpathpattern = /${appurlid}/${locale}${PATH}

If you want, as an alternative example, just a locale segment after the domain name and before the rest of the Intershop Commerce Management URL, use

domainsplitting.host_1.shortpathpattern = /${locale}${PATH}

22.2.3 Specific URL Segments

In combination with specific URL patterns, you can define alternative (shorter) values for locale , appurlid and/or currency . If you want to replace, for example, the complete appurlid with a shorter one, use

domainsplitting.host_1.appurlid.1.value = mobileapp
domainsplitting.host_1.appurlid.1.replacement = m

Together with

domainsplitting.host_1.shortpathpattern = /${appurlid}${PATH}

from the examples above, this would make a URL like

www.primetech.com/m<path>

22.3 URL Parameter Whitelisting

URL parameter whitelisting is a mechanism that allows Intershop Commerce Management to restrict URL requests to an allowed set of URL parameters. In the context of URL rewriting (see URL Rewriting), incoming requests can be checked for the valid set of parameters.

URL parameter whitelisting only works with requests that are rewritten using Intershop Commerce Management's URL rewriting mechanism.

URL parameter whitelisting is enabled individually for each cartridge using the cartridge-specific urlrewrite.properties file located in <IS.INSTANCE.SHARE>/system/cartridges/<cartridge_name>/release/urlrewrite . The corresponding switch is rules.restrictToWhitelistedParameters , which is set false by default.

In case mandatory parameters are missing, Intershop Commerce Management writes an entry into the ERROR and WARN log files, but continues processing the request with the available parameters.

The following sections outline the two options for setting the allowed parameters.

22.3.1 Development Context

As a developer, you can set the pipeline start node to be strict and add the allowed URL parameters as start node parameters in Intershop Studio.

22.3.2 Configuration Context

As a system administrator, you can define the allowed optional and mandatory URL parameters using specific pipelinewhitelistparameters.properties configuration files.

Note

This option overrides any URL parameter configurations made at the pipeline start node.

To configure the allowed parameters, use the following syntax:

pipelinewhitelistparameter.<Pipeline>-<StartNode>.parameters[.mandatory|.optional] = <parametername1>[/<parametertype1>], <parametername2>[/<parametertype2>]

Parameter type checking is controlled by the configuration option intershop.pipelines.strict.CheckParameterTypes , which is disabled by default. For details, see Pipeline Processing Options.

There is one globally valid pipelinewhitelistparameters.properties file, located in <IS.INSTANCE.SHARE>/system/config/cluster. In addition, there can be cartridge-specific pipelinewhitelistparameters.properties files, located in every concerned cartridge in <IS.INSTANCE.SHARE>/system/cartridges/<cartridge_name>/release/config. These files can add new parameters or overwrite global settings.

23 Pipeline Processing Options

The appserver.properties file includes options that control certain aspects of the pipeline processing behavior. Generally, these settings are relevant for development purposes only and should not be altered in production systems.

Property

Type

Description

intershop.pipelines.CheckSource

Boolean

Checks the modification time of pipelines and reloads them if necessary. If set true, the check is enabled and changed pipelines are loaded dynamically; if set false, pipeline files are not checked and changes are enabled upon server restart.

intershop.pipelines.LoadLocalizedPipelineDescriptors

Boolean

Specifies whether the localized descriptor files for pipelets and pipelines are loaded (true|false). The default is false.

intershop.pipelines.strict.CheckParameterTypes

Boolean

Specifies whether the pipeline is checked for the strict node parameter, i.e., where both start and end nodes are set strict (true|false). The default is false.

intershop.pipelines.PreloadFromCartridges

String

Used to preload the pipelines from the specified cartridges upon server start to accelerate the application's responsiveness. Supported values are cartridge names or all; if left blank, no pipelines are preloaded.

intershop.pipelines.PreloadFromSites

String

Used to preload the pipelines from the specified sites upon server start to accelerate the application's responsiveness. Supported values are site names or all; if left blank, no pipelines are preloaded.

intershop.pipelets.PreloadFromCartridges

String

Used to preload the pipelets from the specified cartridges upon server start to accelerate the application's responsiveness. Supported values are cartridge names or all; if left blank, no pipelets are preloaded.

intershop.pipelines.transaction.DefaultSynchronizationScope

intershop.pipelines.transaction.DefaultSynchronizationObject

String

Used to switch on the pipeline transaction synchronization. The default values are CurrentSession for the scope and CurrentStartNode for the object. This will synchronize incoming requests at transaction boundaries within one session if the same initial pipeline start node was called. Sub-pipeline calls are not considered.


24 Template Processing Options

The application server pre-compiles *.isml files, i.e., Web front templates, into *.jsp files, which are then processed by the JSP engine. The following settings in appserver.properties control this feature.

24.1 General Template Options

PropertyDescription

intershop.template.WebRootURL and intershop.template.HttpsWebRootURL

Specifies the URL path prefix for static HTML content. These values are used to create links to static content, for example, images, in the Web front pages.

intershop.template.MaxIncludeDepth

Specifies the maximum depth for local template includes to impede recursive includes. The default value is 10 .

24.2 Template Update Options

Three additional properties are available that control whether and in which interval the server checks for updates to *.isml templates for a requested page. When checking for updates, the server compares the *.isml templates and the corresponding *.jsp files. If an *.isml template is newer than the corresponding *.jsp file, the template will be compiled again. Otherwise, the page is served using the *.jsp file in order to reduce the response time.

PropertyDescription

intershop.template.CheckSource

This property is evaluated first. Setting the value to false means that the server checks for updated *.isml templates only the first time a page is requested, but not if the page is requested again at a later point. Setting the value to true means that the server can perform checks for updated *.isml templates at later points also. How often and exactly how this check is performed is determined by the properties CheckSourceInterval and CheckSourceModified.

If the value for CheckSource is false, the settings for CheckSourceInterval and CheckSourceModified have no effect.

To accelerate the performance of production systems in the area of template processing the file %IS_SHARE%\share\system\config\servletEngine\conf\web.xml of the inner Tomcat can be adjusted.

  • By default the property 'development' is set 'true' -> change this to 'false'.
  • By default the property 'reloading' is set 'true' -> change this to 'false'.


----example------------------- 
<init-param>
	<param-name>development</param-name>
	<param-value>false</param-value>
</init-param> <init-param>
	<param-name>reloading</param-name>
	<param-value>false</param-value>
</init-param> 
----example-------------------

These configuration properties disable the property 'checkSource' in file %IS_SHARE%\share\system\config\cluster\appserver.properties. The JSP files are still compiled, but Tomcat does not check this anymore.

Warning

Use these settings at your own risk. Perform extensive testing and make sure that everything works as it should. Intershop takes no responsibility for any defects or problems that may occur since Apache Tomcat is a 3rd party product that is not under Intershop's control.

Do not use these settings in a test or development environment.


intershop.template.CheckSourceInterval

This property determines in which interval (in seconds) the server checks whether the *.isml template of a requested page has been updated. If the interval is over, the server will search all possible locations for relevant *.isml template, following the standard lookup hierarchy. Hence, the server first checks the current site (for a site-specific version template version), then all cartridges in the order set for the site. This behavior makes sure that major changes are detected, in particular updates that make use of the Intershop Commerce Management overload mechanism.

A value of 0 means that a complete lookup is performed on each request. In this case, the setting for CheckSourceModified has no effect.

intershop.template.CheckSourceModified

As has been described in the context of the CheckSourceInterval, the server performs a complete lookup to check for updated or new *.isml templates whenever the configured interval is over. With the property CheckSourceModified set to true, it is possible to enforce a limited check for updated *.isml files on each request within the configured time interval. The check is limited in the sense that the server only considers the current known location of the template. Hence, the server will specifically check the template that has been used when serving the page the last time, but not other possible locations (such as sites or cartridges higher in the cartridge hierarchy).

24.2.1 Sample Configuration 1

intershop.template.CheckSource=true
intershop.template.CheckSourceInterval=0
intershop.template.CheckSourceModified=true

On each request for a page, the server performs a complete lookup to check for updates to the respective *.isml templates. This configuration imposes considerable demands on server resources and can have a negative impact on the overall performance of your system, in particular if the ISF is located on a remote host.

24.2.2 Sample Configuration 2

intershop.template.CheckSource=true
intershop.template.CheckSourceInterval=3600
intershop.template.CheckSourceModified=true

The server performs a complete lookup for updated templates if the interval between two requests to the same page exceeds an hour. If the page is requested again at an earlier point (e.g., after 10 minutes), the server only checks the current known location of the template for updates.

24.2.3 Sample Configuration 3

intershop.template.CheckSource=true
intershop.template.CheckSourceInterval=3600
intershop.template.CheckSourceModified=false

The server performs a complete lookup for updated templates if the interval between two requests to the same page exceeds an hour. No checks are performed if the page is requested again at an earlier point.

24.3 Character Encoding and Template Conversion

Intershop Commerce Management provides a property to govern character encoding for ISML pages: intershop.template.DefaultContentEncoding

The parameter determines the character encoding used during the template conversion process, i.e., the process which converts ISML templates to JSP and Java classes, and finally compiles the Java classes into class files. Consequently, this property also determines the encoding of the HTML page which is sent back to the client browser when serving a request. Moreover, the default encoding is used to interpret post data that may be transmitted by the client. If no value for the parameter intershop.template.DefaultContentEncoding is provided, the default value UTF-8 is assumed, which is the recommended character encoding for Intershop Commerce Management to work with.

The property intershop.template.DefaultContentEncoding complements the charset attribute of the <ISCONTENT> tag. While the property intershop.template.DefaultContentEncoding specifies the encoding used during the actual template conversion process, the charset attribute of the <ISCONTENT> tag specifies the character encoding used when the ISML-to-JSP compiler reads the ISML template before starting the conversion. This makes it possible to use special character encodings for managing and writing ISML templates, while still using UTF-8 during template conversion.

For additional information on character encoding during template conversion, refer to the Application Programming Guide.

25 Query File Options

Intershop Commerce Management features a powerful, file-based query framework. The queries are defined using XML-based query files that contain query templates in the native language of the associated search/query engine.

The following properties in appserver.properties control the treatment of query files:

PropertyDescription
intershop.queries.CheckSourceEnables a check for the modification time of query files and triggers a reload if necessary; the default value is false. Changing this setting requires a server restart.
intershop.queries.PreloadSpecifies whether the query files of all cartridges and sites are preloaded on server startup; the default value is true.

26 Messenger Thread Count

Info

This section applies from Intershop Commerce Management 7.10.

The Intershop Commerce Management sends events. These can be send synchronous or asynchronous. 
For the sending of asynchronous events, the number of threads to use can be determined. If no value is determined, the number of available processors is used.

PropertyTypeOptionalDescription
event.async.threadcountIntegerOptionalNumber of threads used for sending asynchronous events.

27 Miscellaneous Options

The appserver.properties file offers some additional options that determine certain aspects of the IAS server behavior. The following table lists and explains these settings.

Property

Type

Description

intershop.user.AllowMixedCaseLogin

Boolean

Enables case sensitivity for login names. If set false, login names are always converted into lower case. Do not change this setting in a productive system.

intershop.server.assignedToServerGroup

String

In an Intershop Commerce Management deployment with multiple application servers, this setting allows to assign a single application server to certain server groups, for example, WFS for web front requests or BOS for Commerce Management requests. (Server group names for storefront use can be added as desired.)

intershop.servletEngine.connector.maxHttpHeaderSize

Integer

If the Saferpay payment method is used, the server that hosts the Intershop Commerce Management application and the Saferpay client exchanges data with a Saferpay server via HTTPS. To allocate the necessary information (redirect, service call), the HTTP header size for the local application server must be set to 16380.

intershop.fileservlet.maxBufferedFileSize

Integer

Defines at which file size (in bytes) the Web Adapter switches to the streaming mode. That is, all files that are smaller than the specified value are buffered, whereas larger files are directly streamed.

intershop.fileservlet.registerCachedFiles

Boolean

With selective page cache deletion, specifies whether static Web content is registered in the database. Default is true; false prevents the corresponding table from growing increasingly and allocating too much database space.

intershop.urlrewrite.CheckSource

Boolean

Specifies whether to monitor the urlrewrite.properties files for modifications and triggers a refresh if needed.

intershop.urlrewrite.CheckSourceInterval

Integer

Specifies the time interval in seconds after which the urlrewrite.properties files are to be checked for modifications if CheckSource = true. (The value 0 – always – is not recommended).

intershop.webservice.soap.allowedSiteStatuses

String

Specifies the site statuses (see the System Management online help) that allow for web service execution in a semicolon-separated list. The available values include LIVE, MAINTENANCE and DISABLED (case-sensitive). The default value is LIVE;MAINTENANCE.

intershop.xmlattributes.formatted

Boolean

Specifies whether to store (true|false) the XML of custom XML attributes with white spaces, line feeds and indentations in the database. The default is false. Note that if set true, the database needs more space.

intershop.xmlattributes.computedlineitems.compressed

Boolean

Specifies whether to compress the XML of ComputedLineItems in baskets and orders before storing. If set true, they are not human readable anymore, but smaller and faster, which can increase the database performance (less storage, faster read/write operations). The default is false.

Disclaimer

The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources
Support Tickets