Introduction

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.

Glossary

Reference

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

• Overview - Infrastructure, Scaling and Performance
• Concept - Technical Architecture of Intershop 7

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.

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

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:

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.

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:

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.

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.

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.

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.

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.

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:

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

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:

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.

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.

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:

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.

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.

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.

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.

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.

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

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

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:

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

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.

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:

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.

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.

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:

<domain>.ParentRuleOwner = <domain>

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

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

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.

General Cookie Settings

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

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.

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

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.

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.

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

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

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.

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].

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).

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
...

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.

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 (valid to 7.7) 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.

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

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}

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>

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 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.

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

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.

Configuration Context

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

To configure the allowed parameters, use the following syntax:

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

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.

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.

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.

General Template Options

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.

----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-------------------

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.

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.

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.

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.

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:

Messenger Thread Count

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.

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.