Is7.4 Admin Admin

Administration and
Configuration Guide
Intershop 7
Administration and Configuration Guide
Document ID: ENF7-45-03-02
Publication date 2014-01-06

These materials are subject to change without notice. These materials are provided by Intershop Communications AG
and its affiliated companies ("Intershop Group") for informational purposes only, without representation or warranty
of any kind, and Intershop Group shall not be liable for errors or omissions with respect to the materials. The only
warranties for Intershop Group products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional
warranty.
This document and all of its parts are protected by copyright. All rights, including those of duplication, reproduction,
translation, microfilming, storage on electronic media and processing in electronic form are expressly reserved.
Intershop® and Enfinity™ are trademarks or registered trademarks of Intershop Communications AG. All other company,
product and brand names are trademarks or registered trademarks of their respective owners.
Copyright © 2005-2014 Intershop Communications. All Rights Reserved.
Table of Contents
Chapter 1: System Administration Overview ...................................... 11
About This Guide .................................................................................... 11

Knowledge Assumed ................................................................................. 11
Typographical Conventions ........................................................................ 11
Chapter Overview ..................................................................................... 12
Main Software Components ..................................................................... 12

Web Server and Web Adapter ..................................................................... 13
Application Server ..................................................................................... 14
Intershop 7 Application .............................................................................. 15
Internal Servlet Engine ........................................................................... 15
ORM Engine ......................................................................................... 15
Core Cartridge ...................................................................................... 15
Business Component and Application Cartridges ....................................... 16
Oracle Client ........................................................................................ 16
Application Initialization ............................................................................ 16
Data Storage and Database ........................................................................ 16
Relational Database System .................................................................... 17
Intershop Shared Files (ISF) .................................................................... 17
Administration Overview ......................................................................... 18

Administration Interfaces ........................................................................... 19
Task Overview .......................................................................................... 20
Chapter 2: Intershop 7 Administration ................................................ 21
Intershop 7 Configuration Framework ...................................................... 21

Defining Configuration Sets ........................................................................ 22
Arranging ConfigurationSets ................................................................... 24
Managing your Configurations ................................................................ 25
Web Server Settings ................................................................................ 25

SSL Support ............................................................................................. 26
Internal SSL Encryption .......................................................................... 26
SSL Box Support ................................................................................... 26
SSL and Multiple DNS Domains ................................................................... 27
Fail-Over Support for Load Balancing ........................................................... 27
Web Adapter Settings ............................................................................. 28

Web Adapter Configuration Files ................................................................. 28
Configuration Servlets ............................................................................... 29
Web Adapter Logging Options ................................................................... 29
Request Log ......................................................................................... 29
Administration and Configuration Guide iii

Error Log ............................................................................................. 33
Web Adapter Error Pages ........................................................................... 34
Web Adapter Statistics ............................................................................... 35
Web Adapter Statistics Log ..................................................................... 35
Configuring the Statistics Log ................................................................. 36
Web Adapter Control Interface ................................................................... 37
Web Adapter Session Handling ................................................................... 38
Session Cookie Settings ......................................................................... 38
Robot Detection ................................................................................... 38
Page Cache Options .................................................................................. 39
Page Cache Management at Application Level .......................................... 39
Page Cache Settings .............................................................................. 39
Page Cache Invalidation Settings ............................................................. 41
Pragma No-Cache Requests .................................................................... 42
Page Cache Pre-Fetching ........................................................................... 42
General Web Crawler Control .................................................................. 42
Web Crawler Configuration .................................................................... 42
Server Group Definition ............................................................................. 44
HTTP Status Response Configuration ........................................................... 45
SSL Box Support ....................................................................................... 45
Load Balancing Between Application Servers ................................................ 45
Response Time-Based Load Balancing ...................................................... 46
Weight-Based Load Balancing ................................................................. 47
Intershop 7 Application Settings .............................................................. 48

Server Instance Specific Configuration ......................................................... 49
Event Settings .......................................................................................... 49
Multicast Messaging Setup ..................................................................... 50
JGroups Messaging Setup ...................................................................... 50
JMS Messaging Setup ............................................................................ 51
Application Server Event Settings ................................................................ 52
Fail-Over Settings ...................................................................................... 53
Servlet Engine Settings .............................................................................. 54
Application Logging .................................................................................. 55
Application Logging: Basic Concepts ........................................................ 55
Application Logging: Configuration ......................................................... 56
Application Logging: Default Log Output ................................................. 58
Application Logging: Simple Back-Office Auditing ...................................... 59
User Tracking Options ............................................................................... 60
General Cookie Settings ......................................................................... 60
Cookies for Multiple Sub-Domains ........................................................... 60
Session Handling Options .......................................................................... 61
Authentication Security Options .................................................................. 61
iv Administration and Configuration Guide

Schedule Execution Options ....................................................................... 62
Web Server URL Settings ............................................................................ 63
URL Handling ........................................................................................... 63
URL Configuration ................................................................................. 64
URL Rewriting ....................................................................................... 65
URL Parameter Whitelisting .................................................................... 66
Template Processing Options ..................................................................... 67
General Template Options ...................................................................... 67
Template Update Options ...................................................................... 67
Character Encoding and Template Conversion .......................................... 69
Pipeline Processing Options ....................................................................... 69
ORM Engine Options ................................................................................. 70
Database Connection Settings ................................................................ 70
Basic Cache Settings .............................................................................. 77
PO Cache Synchronization Settings ......................................................... 77
Search Engine Settings .............................................................................. 79
Multi-Threaded Search Index Creation ...................................................... 79
Oracle Text Search Options .................................................................... 80
Query File Options .................................................................................... 80
Cache Engine ........................................................................................... 80
Cache Engine Messaging Settings ........................................................... 81
Monitoring Cache Activity ...................................................................... 81
CPU Affinity Settings ................................................................................. 82
Application Configuration on Multihomed Hosts ........................................... 83
User Login and Password Rules ................................................................... 83
Object Locking Settings ............................................................................. 86
Startup Retry Settings ................................................................................ 86
Graceful Application Server Shutdown ......................................................... 87
Data Encryption/Decryption Options ........................................................... 87
Web Search Engine Optimization ................................................................ 88
Mail Server Settings ................................................................................... 89
Multi-Threaded Export Settings ................................................................... 90
Miscellaneous Options ............................................................................... 91
Sensitive Properties Settings ....................................................................... 92
Prepare Locales, Tax Data, Currencies and Exchange Rates ......................... 92

Configure Server Start Pipeline ................................................................... 92
Prepare Locales ........................................................................................ 92
Locale Configuration Files ...................................................................... 92
Locale Update Process ........................................................................... 94
Prepare Tax Data Sets ................................................................................ 94
Tax Data Configuration Files ................................................................... 94
Tax Data Update Process ........................................................................ 97
Administration and Configuration Guide v

Prepare Currencies .................................................................................... 97
Currency Configuration File .................................................................... 97
Currency Update Process ....................................................................... 97
Prepare Exchange Rates ............................................................................. 98
Exchange Rate Configuration File ............................................................ 98
Exchange Rate Update Process ............................................................... 98
Data Replication ..................................................................................... 98

Understanding the Data Replication Process ................................................. 99
What Is Data Replication? ....................................................................... 99
Basic Architecture ................................................................................ 100
Local and Remote Data Replication ........................................................ 101
Data Replication Chains ....................................................................... 101
Data Replication Workflow ....................................................................... 102
Role Concept ...................................................................................... 102
Data Replication Tasks ......................................................................... 102
Data Replication Processes ................................................................... 103
What Happens During Data Replication? ..................................................... 104
Data Replication Phases ....................................................................... 104
Full Replication and Delta Replication ..................................................... 105
Data Replication Types ......................................................................... 105
Data Replication and Channel Structure ...................................................... 106
Data Replication Versus Product Data Feeds ................................................ 107
Preparing for Data Replication or Product Data Feeds ................................... 108
Step 1: Preparing the Database Connection ............................................. 108
Step 2: Configuring Source and Target cluster ......................................... 110
Step 3: Database Initialization ............................................................... 112
General Data Replication Configuration ...................................................... 112
General System Configuration ............................................................... 113
Timeout Settings ................................................................................. 113
Processors and Decorators .................................................................... 113
Data Replication Jobs .............................................................................. 113
Jobs on Source System ........................................................................ 114
Jobs on Target Cluster ......................................................................... 114
Logging ................................................................................................. 114
Chapter 3: System Management ....................................................... 116
Overview .............................................................................................. 116
Navigate the SMC .................................................................................. 116

Access and Log In to the SMC ................................................................... 117
Navigate the SMC .................................................................................... 117
Change the SMC Password ....................................................................... 118
vi Administration and Configuration Guide

Schedule Management .......................................................................... 118
Enable/Disable the Job Processor .............................................................. 119
List Scheduled Jobs ................................................................................. 119
Create a New Scheduled Job ..................................................................... 120
Edit a Scheduled Job ............................................................................... 122
Run a Scheduled Job Manually .................................................................. 122
Delete a Scheduled Job ............................................................................ 123
Manage Process Chains ............................................................................ 123
Specifying Process Chain Elements ........................................................ 123
Executing Process Chains ..................................................................... 125
Logging Options ................................................................................... 125

View Logging Status ................................................................................ 125
Available Logging Settings ....................................................................... 126
Settings Scope .................................................................................... 126
Additional Logging Configuration Files ................................................... 127
Appender Options: Level Filters and Categories ....................................... 128
Changing the Logging Settings ................................................................. 128
Selecting the Settings Scope ................................................................. 129
Setting the Level Filter ......................................................................... 129
Managing Categories ........................................................................... 129
File Browser .......................................................................................... 131
License Auditing ................................................................................... 132
Site Management .................................................................................. 133

Access and Navigate the Site Management Module ...................................... 133
General Site Preferences ........................................................................... 134
Page Cache Preferences ........................................................................... 135
Application Settings ................................................................................ 136
Monitor the System State ...................................................................... 137

Access and Navigate the Monitoring Module ............................................... 137
Monitoring Sub-Modules ...................................................................... 138
Sub-Module Overview Page .................................................................. 138
Sub-Module Detail Page ....................................................................... 138
Monitoring Options ................................................................................. 139
JMX and MBean Support .......................................................................... 142
What is JMX? ...................................................................................... 142
MBean Registration ............................................................................. 143
Intershop 7 Sample MBeans .................................................................. 145
Installation Maintenance ....................................................................... 146

Access and Navigate the Installation Maintenance Module ............................ 146
Generating Cluster Information Reports ...................................................... 146
Administration and Configuration Guide vii

Generating Java Dumps ........................................................................... 148
Managing Information Files ...................................................................... 148
Viewing and Downloading Files ............................................................ 149
E-Mailing Files ..................................................................................... 149
Chapter 4: Reference ......................................................................... 151
Appendix A: Command Line Tools and Scripts ......................................... 151
Appendix B: Summary of Placeholders ................................................... 154
Appendix C: Tomcat and Node Manager Settings .................................... 155

Big Picture ............................................................................................. 156
Shared Cluster Management Settings ......................................................... 157
Local Cluster Management Settings ........................................................... 158
Node Manager Settings ............................................................................ 158
Node Manager Configuration ................................................................ 158
Node Manager Startup Command ......................................................... 159
Application Server Configuration ............................................................... 159
Application Server Shutdown ................................................................ 159
Application Server Network Settings ...................................................... 160
Tomcat Logging Options ...................................................................... 161
Cluster Management ............................................................................... 161
Access the Cluster Management Console ................................................ 161
Control Server Processes ...................................................................... 163
Create or Delete Server Processes .......................................................... 164
Control Applications ............................................................................ 166
Managing Tomcat Server Instances Across Intershop 7 Clusters .................. 167
Intershop 7 Command Line Client ........................................................... 168

Running Jobs .......................................................................................... 168
Running Imports ..................................................................................... 169
Appendix E: Enabling Optional Components ........................................... 170

Intershop Studio ..................................................................................... 171
Web Analytics Services ............................................................................. 171
eCircle E-Mail Marketing ........................................................................... 172
SoQuero Data Feed FTP Upload ................................................................ 172
Recommendation Engine Integration ......................................................... 173
Back Office Localization ............................................................................ 174
Generating Standard Template Set for Other Locales ................................ 174
Translating Localization Properties Files for Other Locales .......................... 176
viii Administration and Configuration Guide

List of Figures
1 – Intershop 7 components ....................................................................... 13
2 – SSL box support. ................................................................................. 27
3 – Fail-over time line of a crashed server ..................................................... 54
4 – Data Replication Architecture ............................................................... 100
5 – Simple Replication Chain ..................................................................... 101
6 – Defining data replication tasks ............................................................. 103
7 – Defining Data Replication Processes ...................................................... 103
8 – Replication phases ............................................................................. 104
9 – SMC main screen ............................................................................... 117
10 – Changing the SMC password ............................................................. 118
11 – Job processor statuses in the cluster .................................................... 119
12 – Schedules overview page .................................................................. 120
13 – Specifying schedule details ................................................................ 121
14 – Logging module overview ................................................................. 125
15 – Application server logging status ........................................................ 126
16 – Application server logging settings ..................................................... 126
17 – Selecting a level filter ........................................................................ 129
18 – Assigning a category to an appender .................................................. 130
19 – Automatically included sub categories ................................................. 131
20 – SMC file browser .............................................................................. 131
21 – Generating a license report ................................................................ 132
22 – Submitting the license report ............................................................. 133
23 – SMC sites overview ........................................................................... 133
24 – General site preferences .................................................................... 134
25 – Page cache settings .......................................................................... 135
26 – A site's application list ....................................................................... 136
27 – General application data ................................................................... 136
28 – Application cartridges ....................................................................... 137
29 – Application REST ressources ............................................................... 137
30 – Monitoring Cluster Overview page ...................................................... 138
31 – Application Server overview page ....................................................... 138
32 – Application Server process details ....................................................... 139
33 – Installation Maintenance overview ...................................................... 146
34 – Information Files manager ................................................................. 149
35 – E-mailing an information file .............................................................. 150
36 – Tomcat cluster management overview ................................................ 156
37 – TCC Cluster overview ........................................................................ 162
38 – Changing the password for the TCC .................................................... 162
39 – TCC Cluster Servers module ............................................................... 163
40 – Creating a new application server process ............................................ 164
41 – Control applications in a single server instance ..................................... 167
Administration and Configuration Guide ix

42 – Control applications in the entire cluster .............................................. 167
43 – Sample scenario with two Intershop 7 clusters accessing joint TCC
configuration files ................................................................................... 168
44 – Managing server instances from different Intershop 7 clusters in the same TCC
.............................................................................................................. 168
x Administration and Configuration Guide

Chapter 1
System Administration
Overview
About This Guide

This guide is intended for system administrators who have to keep an Intershop 7
installation running smoothly. It covers configuration, administration and
maintenance tasks for Intershop 7, independent of the operating system on which
it is running. It describes Web Adapter control, application server control and
monitoring, Intershop 7 application control, and common maintenance activities.
Knowledge Assumed
This guide assumes familiarity with:
n The system structure of your enterprise
This includes existing network systems and servers, including any hardware and
software elements of your system which are integrated with Intershop 7. You
should be familiar with the basic concepts and tasks of system administration.
n Basic Intershop 7 architecture
This includes the Intershop 7 architecture in terms of its business applications,
software components and processes.
n Your enterprise's Intershop 7 installation
If you are not responsible for your enterprise's Intershop 7 installation, contact
the person responsible to learn about its structure.
Typographical Conventions
The following typographical conventions are used throughout the document:
• blue color
Highlights cross-references to other parts of this guide or links to external
resources, such as other documents of the Intershop Knowledge Base or other
web sites.
• italic typeface
Highlights special words, e.g., names of files and directories, cartridges, and
packages, as well as references to external resources that are not directly linked.
Administration and Configuration Guide 11

Chapter 1: System Administration Overview Main Software Components
• monospaced typeface
Highlights commands to be typed at command prompts as well as example

code. This also includes attribute names, Java classes or methods and database
table names.
• Hash symbol (#)
Refers to the number of an Intershop 7 instance. If # precedes a shell prompt, it
indicates that the current user is root.
• <placeholder>
Designates text in path names or code examples that depends on the given
context and is to be replaced with a real name or value, e.g., <IS.INSTANCE.DIR>
or <current-date>.
Chapter Overview
This guide is divided into the following chapters:
n Chapter 1: System Administration Overview (this chapter)
Gives a general overview of the Intershop 7 components and administration
tasks.
n Chapter 2: Intershop 7 Administration
Outlines the configuration framework, Web server and Web Adapter
configuration, the application server configuration, and the Intershop 7
application configuration, including ORM and data source setup. It details
the logging options for each server, and gives an overview of data replication
concepts and processes.
n Chapter 3: System Management
Details the functionality of the System Management Console (SMC) and
describes how to use it for system administration tasks in Intershop 7.
n Chapter 4: References
Summarizes command line tools, Intershop 7 placeholders as well as important
Tomcat and node manager settings, and outlines how to enable optional
Intershop 7 components.
Main Software Components

This section provides an overview of the main software components of Intershop 7.
As shown in the following figure, Intershop 7 features a layered component
architecture, comprising a Web layer, an application server layer, and a data storage
layer.
12 Administration and Configuration Guide

Main Software Components Chapter 1: System Administration Overview
Figure 1. Intershop 7 components
NOTE: On Web gateway and application server layer, multiple server instances forming a so-called
cluster are possible.
The subsequent sections discuss these layers and their components in more detail.
Web Server and Web Adapter

The Web Gateway consists of the Apache HTTP Server and the Intershop 7 Web
Adapter. The Intershop 7 Web Adapter is realized as a plug-in to the Apache Web
server. The Web Adapter is complemented by the Web Adapter agent.
NOTE: Intershop 7 is shipped with the Apache HTTP Server. Support for other Web servers can be
acquired on request.
The Web Adapter

• Dispatches HTTP client requests to an application server, based on intelligent
load balancing (see Load Balancing Between Application Servers.)
• Generates session IDs (SIDs). Depending on the configured session handling
mode, the session ID may be part of the URL or be included with a cookie (see
Web Adapter Session Handling.)
• Caches responses from the application server and checks for cached pages (see
Page Cache Options.)

The Web Adapter agent, which is running on every Web Gateway host as a daemon
process,
• Invalidates pages in the page cache based on pre-defined keywords (see Page
Cache Options),
• Removes invalidated pages from the cache,
• Generates request logs and error logs (see Web Adapter Logging Options),
• Requests, typically after data replications, Intershop 7 pages to fill the page
cache (see Page Cache Pre-Fetching)
• Sends statistical data to the application servers. By default, these statistics are
written to Web Adapter log files (see Web Adapter Statistics.
The Web Adapter is configured using two different configuration files:

n A global webadapter.properties file
This file is located in <IS.INSTANCE.SHARE>/system/config/cluster/ (Windows)
or /etc/opt/intershop/eserver# (Linux). It is used to provide global configuration
information which applies to all Web Adapters in a cluster. The Web Adapter
accesses this file through an HTTP call to a configuration servlet. Information on
available configuration servlets is obtained from the local webadapter.properties
file (see below).
n A local webadapter.properties file
Each Web Adapter has a local webadapter.properties file, located in
<IS.INSTANCE.DIR>/webadapter/. This file can be used to overload any parameter
setting from the global Web Adapter configuration file, for example to
set individual logging or tuning parameter values. In addition, the local
webadapter.properties file contains information on available configuration
servlets.
Note that the Web Adapter does not need to access static content locations within
the Intershop 7 shared file system. Requests for static content are forwarded to and
resolved by a special resource servlet running on the application servers. To resolve
the request for static content, the resource servlet uses the cartridge configuration
of the site to which the request is addressed.
Application Server
The application server provides the operating environment for the Intershop 7
application and any custom cartridge providing business logic.
Apart from default applications, the application server deploys two additional web
applications:
n Intershop 7 Loader Application
This application loads and initializes the Intershop 7 application.
n Cluster Management Console (Administration Console)
This is a Web frontend application used to manage the application server
instances in an Intershop 7 cluster.

Intershop 7 Application
The Intershop 7 application itself consists of the internal servlet engine, the ORM
engine and the core cartridge providing the necessary technical functionality and
basic business logic, as well as business component and application cartridges
providing the framework for any business logic built on top of Intershop 7. These
sub-components are discussed below.
Internal Servlet Engine

The Intershop 7 application 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. The parameters to configure the internal servlet
engine are part of the appserver.properties file.
ORM Engine
The ORM engine (Object-Relational Mapping engine) forms the persistence layer.
It consists of multiple sub-frameworks that perform tasks like loading and parsing
of deployment descriptors, providing meta-information for the generation of SQL
statements or switching between different transactional and non-transactional
states of an object.
The features of the ORM engine include:
• Object-Relational Mapping (inheritance between persistent objects with
abstract superclasses, mapping of concrete leaf classes to tables)
• Caching of persistent objects and relations between them
• Transaction handling (begin, commit, rollback, store, object lock)
• JDBC functionality (Oracle 11g JDBC driver)
• Logging of SQL statements and transaction boundaries
Core Cartridge
Each server process deploys the core cartridge. The functionality provided by the
core cartridge can be split into two groups, one with more technical functionality
and one with basic business logic. The technical features include:
• Logging
• Request processing
• Template processing
• Pipeline execution
• Mail sending
• Search framework
• Cache management
• Configuration framework
• Job Scheduler
• Import/Export framework

• Data replication
The business logic features are:

• Site and unit framework
• Basic user and permission handling
• Authentication mechanisms
• Basic classes for values (money, quantity, etc.), and value formatters
• Currency and locale handling
Business Component and Application Cartridges

In addition to the core cartridge, application servers deploy cartridges which
contribute frameworks and business logic developed on the basis of these
frameworks, covering, for example, product and catalog handling (implemented
in the xcs cartridge), multi-vendor catalog handling (implemented in the bc_mvc
cartridge) or transaction and pricing (implemented in the bts and bc_pricing
cartridge). How many and which business logic cartridges the application server
contains depends on the specifics of the business scenario implemented by
Intershop 7. However, note that all application servers run the same set of business
logic cartridges.
Oracle Client
To complete the functionality of Intershop 7, an Oracle Client must be installed
along with the Intershop Application Server. The Oracle Client provides necessary
features for, e.g., import/export processes.
Application Initialization
The Intershop 7 application is started inside the underlying application server by
means of a special loader application (EnfinitySuite). The loader application, which
is deployed as a *.war file, is J2EE compliant and independent from the application
server used.
Main purpose of the loader application is to load and initialize the application
resources. Loader application and Intershop 7 application run inside the same JVM.
Due to the loader mechanism, the Intershop 7 application itself does not need to be
packaged and deployed as a *.war file. Intershop 7 cartridges are stored in the ISF
instance.
Note that Intershop 7 runs autonomously inside the application server, providing all
the services which the application needs for execution. The Intershop 7 application
also provides its own engine for servlet and JSP processing.
Data Storage and Database

Two different locations are used to store data within an Intershop 7 system:
• Relational database system
• File system

Relational Database System

The relational database system is used to store data whenever a transactional
access or search capability is required. As a rule of thumb, all business data and
some of the system configuration data is stored in the relational database system.
Access to the database system happens primarily via the object-relational mapping
mechanism of the ORM engine, which internally uses the native client drivers to
access the database server.
NOTE: Intershop 7 supports Oracle 11gR2 database systems only.
Intershop Shared Files (ISF)

The file system is used as storage system whenever file-based data is stored,
transactional access is not required and whenever the data is to be edited by a file-
based tool. Some artifacts stored in the ISF are shows in the list below:
• Configuration and property files
• ISML templates
• Static HTML pages
• Static images for the HTML clients
• Pipelines
• Queries
• Webforms
The file system storage is split into two main areas:

n "sites" area:
Contains all site-specific data, such as subdirectories for the units of a site and
their content, e.g., import source data, HTML files, ISML templates, images and
other data separated for each site.
n "system" area:
Contains standard cartridges, log information and some global configuration
data such as the server configuration and the license information.
On Windows, you must share the ISF directory when using the ISF in a distributed
installation where it is accessed from a remote IAS host. By default, the share
is available to members of user group "Everyone" with full control. For security
reasons, it is recommended to restrict availablity of the share to the application
server user only.
The share directory contains the Intershop Shared Files, a component providing
resources that are shared between different Intershop 7 servers belonging to a
cluster. The table below gives an overview of the share directory.
Table 1. ISF directory structure
Shared Directory Structure Description

<IS.INSTANCE.DIR> Home directory of a particular Intershop 7 instance
share Main share directory
docs Starting point for the Javadoc

Chapter 1: System Administration Overview Administration Overview
Shared Directory Structure Description

reportingrepository Contains data files used by the Intershop 7 reporting
framework
sites Top-level directory for site-specific resources. Every site
will create such a directory upon development.
system Top-level system directory related to cartridge and
cluster configuration information
cartridges Cartridge main directory containing cartridge-specific
(and therefore shared) pipelines, templates and
resources
config Main configuration directory
config/ Cartridge configuration directory
cartridges
config/cluster Cluster configuration main directory, including, e.g.,
staging.properties, orm.properties, appserver.properties
config/oracle Oracle configuration main directory
config/servers Application server specific configuration information
config/ General Tomcat deployment files
servletEngine
impex Sample files, DTDs and schema files for import and
export tasks.
license License information
log Application server log information
servletEngine Tomcat web-inf directory
tcm Contains files for the Tomcat Cluster Management
Console
In addition to the main and share directories, a number of files are created during
the installation of Intershop 7.
Table 2. Files outside the installation directory
Directory Description
/var/opt/intershop Main directory of the system registry
eserver.conf Instance registration file used for startup/shutdown
setup Installation directory of the system registry
uninstall Contains the Java Runtime Environment and the
uninstall Java class file.
log Setup log directory
Administration Overview
This section gives a general overview of maintenance tasks, which will be further
detailed in the following chapters.

Administration Overview Chapter 1: System Administration Overview
Administration Interfaces
Intershop 7 system administration and configuration is performed using the
following tools:
n The system configuration files
Most options that control the Intershop 7 system behavior are stored in
*.properties files. To customize Intershop 7 options, i.e., to actually change the
Intershop 7 configuration, edit these configuration (*.properties) files using a
plain text editor. The *.properties files resemble the key = value notation as
defined in the standard Java class java.util.Properties. Properties can model the
following types of values:
• Integer: A positive or negative integer
• String: Text without blank spaces
• Text: Text with or without blank spaces
• Boolean: Either true (enabled) or false (disabled)
It is generally a good idea to make a backup copy of the file before making
changes.
n The Configuration Framework
The Configuration Framework provides Intershop 7 administrators with an
interface (like getstring(), integer(), properties()) for loading configurations across
installations via the Configuration Manager. The data source(s) can be anything
from which a configuration can be loaded (such as a file, database table, external
resource, etc.).
Intershop 7 behavior settings are set by means of key = value pairs (found in
property files, preference tables, etc.), within ConfigurationSets (data stores)
defined in configuration.xml. The context (e.g. a domain, an instance, or server
cluster specific settings) determines the values that are returned by the set. The
Configuration Manager:
• Set-up is defined by the configuration.xml file, the central component of the
framework. This file contains the instructions for the configuration engine
instance (including the scopes and the configuration set URI)
• Assembles the configuration engine instance that locates the URI (via the
Finder) and creates ConfigurationSets (via the Reader)
For more information see Configuration Framework.
n The Cluster Management Console (Administration Console)
This is a Web frontend application used to manage the application server
instances in an Intershop 7 cluster and the applications running on them.
n The System Management Console
The System Management Console is an ISML-based Web front application used
to manage scheduled jobs, and to monitor certain application functionality in
Intershop 7.

Chapter 1: System Administration Overview Administration Overview
Task Overview
Basically, the Intershop 7 administration comprises the following main tasks:
n Component Configuration
For Intershop 7 to function properly in your environment and according to
the intended business scenario, you may have to adjust the settings for the
individual components. See
• Web Server Settings
• Web Adapter Settings
• Intershop 7 Application Settings
n System Control and Monitoring
System control and monitoring with respect to the Intershop 7 application is
generally performed via the System Management Console (SMC), see Schedule
Management, Logging Options, License Auditing, Site Management, Monitor
the System State, and Installation Maintenance.
n Logging
The logging options are configured for each Intershop 7 component separately.
Refer to the sections Web Adapter Logging Options, or Application Logging (or
the SMC section Logging Options), respectively.
n Data Replication Administration
Basic administration tasks related to data replication include connecting source
and target system and executing an initial data replication process. For details,
see Preparing for Data Replication. Once the basic configurations are in place,
the system administrator creates and monitors data replication processes in
the central administration front end. For more information, refer to the "Central
Administration User Guide".
This guide also addresses some Tomcat-specific topics, including:

• Node Manager Settings
• Application Server Configuration
• Cluster Management.

Chapter 2
Intershop 7 Administration
Intershop 7 Configuration Framework

Intershop 7 provides a unified interface for administrators to get and load
configuration settings to installations at system-level to application-level (that is,
preferences) from multiple sources. The central entry point is the configuration
engine that reads the configuration.xml file where the reader, writer, finder, and
scopes are defined for (and comprise) the ConfigurationSets. The file is found in
<eserver-installation>/share/system/config/cluster and the source file in <core-
cartridge-source>/staticfiles/share/system/config/cluster.
The following components comprise the framework for loading configuration
settings:
n The configuration.xml file
This file contains all finders, readers and writers that will construct your
ConfigurationSets. The configuration scopes and ConfigurationSets are defined
here.
n ConfigurationSet
The ConfigurationSet is the store for configuration settings. Defined in the
configuration.xml file, the ConfigurationSet is a grouping of sources, locations
and access to read from or write values to a source. A ConfigurationSet can
belong to more than one scope.
n Configuration Manager
Provides an entry point to get configuration objects. The Configuration Manager
parses configuration.xml, and places any readers, finders and scopes into the
engine.
n Configuration Engine
Retrieves the URI's from the finders which are then used to get
ConfigurationSets from the readers. These are then added to a ConfigurationSet
manager as ConfigurationSets.
n Finder
Resolves the URI of the ConfigurationSet source.
n Reader
Reads the source provided by the finder and returns the ConfigurationSet.

Chapter 2: Intershop 7 Administration Configuration Framework
n Configuration Scope
Each configuration source (a file, database, etc.) belongs to a special scope. If the
Scope is dependent on a higher-ranking Scope, configuration values are taken
from the higher-ranking scope. The values are then applied to initializing the
Finder and Sets.
You can use placeholders in the attributes defined in the configuration.xml file.
<scope name="system" />
<scope name="ish" depends="system" />

<set finder="system" scope="system,ish,startup,instance,cluster,
server,domain" />
<set finder="property" scope="ish,startup,instance,cluster,
server,domain" required="true" filename="${system.intershop.HomeDirectory}
/intershop.properties" />
The scope ${system.intershop.HomeDirectory} is only possible because the

system scope is loaded. The scope attribute of the set shows the sets that are
used. The placeholders serve an essential role because they allow the specific
configuration for the environment and/or data center to be applied.
n Writer
Writes to the URI provided by the finder in the ConfigurationSet.
Scopes specify where to look for configurations (or rather, the context of
application for the writer, reader and finder) across an entire system or within a
specific domain. Some scopes have dependencies on other scopes higher up in the
heirarchy. For example the instance scope configuration depends on some startup
scope properties that must first load some system scope properties. Therefore in
our example, the instance scope has a dependency on the system scope. The scope
defines the extent of application for the configuration.
Defining Configuration Sets

For every ConfigurationSet the finders and writers must be registered and the
reader classes must be declared within configuration.xml. If a class is declared and
the requirement is set to "true" and none is found, an exception will be thrown.
NOTE: A Finder returns a list of URIs. Each URI will be converted to a ConfigurationSet.
The order of configuration sets is important. Within configuration.xml, the sets must
be ordered in the sequence they are loaded. This also means that the first value for
a specific key is applied. If the same key is found later in the list of configurations,
the value is discarded. See Table 5, “Configurations Locations” for a list of where
to place your configurations. Configurations should be loaded in the following
sequence:
1. System properties
Define properties from the system.
2. <IS.INSTANCE.DIR>/intershop.properties
For IS_HOME properties.
3. <IS.INSTANCE.SHARE>/system/config/cluster/environment.properties
Defines one value for the current environment.

Configuration Framework Chapter 2: Intershop 7 Administration
4. <IS.INSTANCE.SHARE>/system/config/servers/[IP]/[INSTANCE_ID]/
[environment]_[feature].xml
IP configuration is assigned to instances; this only includes the parameter(s) for
a single machine.
5. Preference table
Defines properties in the data base that can be read from/written to in the
backoffice.
6. <IS.INSTANCE.SHARE>/system/config/domains/[domain]/
Defines domain specific business configuration.
7. <IS.INSTANCE.SHARE>/system/config/cartridges/
Defines the default configuration of the cartridge.
8. <IS.INSTANCE.SHARE>/system/config/cluster/[environment]_[feature].xml
Defines the configuration for this cluster.
For every ConfigurationSet the finders and writers must be registered and the
reader classes must be declared within configuration.xml.
Table 3. List of Finders
Finder File Location Description

app-folder <IS.INSTANCE.SHARE>/ Looks into the apps-folder for the fully
system/config/apps qualified <filename> and extension to be
read.
system - Returns a URI with the scheme "ish-
system." Reads the system environment.
cartridge <IS.INSTANCE.SHARE>/ Returns a URI with the scheme "ish-site
system/config/cartridges/ cartridge." Returns a list of cartridges.
cartridge-folder <IS.INSTANCE.SHARE>/ When enabled, returns the configuration
system/config/cartridges/ filename.
applicationprefs* - Searches for the application preference
and domain preferences as fallback.
defaultprefs - Returns a URI with the scheme "ish-
defaultPreference." Default values are
dereived from PreferenceDefinitionPO.
preference - Returns a URI with the scheme "ish-
preference."
domain-folder <IS.INSTANCE.SHARE>/ Returns a URI with the scheme "ish-
system/config/ domainFolder." Reads settings with
domains/[domain]/ domain-specific dependencies.
instance <IS.INSTANCE.SHARE>/ Looks into the server directory and returns
system/config/servers/ an instance as a configuration. Reads the
[IP]/[INSTANCE_ID]/ network interfaces to define an instance
[environment]_[feature].xml specific file.

Chapter 2: Intershop 7 Administration Configuration Framework
Finder File Location Description

property - Finds the fully qualified <filename> to be
read. If set as "true", raises an exception if
the file does not exist.
xml - Finds the fully qualified <filename> to be
read. If set as "true", raises an exception if
the file does not exist.
transient - Returns a URI with the scheme "ish-
transient."
NOTE: Promotion preferences are not supported.
The Writer saves the configuration. You must define at least one writer that
will retrieve the values of your configuration set. Below is the syntax for writer
registration and a list of available writers:
Table 4. List of Writers
Writer Description
transient Updates the given configuration set.
property Writes the configuration set to the given URI as a property file,
subsequently updates the given configuration set.
Arranging ConfigurationSets
The range or extent of the configuration is determined by the configuration
scope where the configuration sources are located. Scopes are defined in the
configuration.xml file and are dependent on scopes higher up in the scope
hierarchy. If the configuration you want to load depends on values of a broader
scope, these must be loaded first.
For example, if you load a configuration for a specific instance (scope="instance"),
you must first load the startup configuration (the startup scope), which in turn
is dependent on the system properties (contained in intershop.HomeDirectory)
contained in the startup scope. Thus, a configuration for the instance scope cannot
be properly loaded unless the configuration values on which it depends (derived
from startup scope, higher in the hierarchy) are loaded first.
Another thing to keep in mind is the use of *.properties files and the use of
preferences. Preference databases hold values that tend to be applied to business
data (e.g. data centers) across an installation, and are generally not application
specific. Property files on the other hand are typically system processes (e.g.
services for a single location) where a single property file holds settings, or an XML
file that contains all of the property files handles the settings. Depending on the
order of the ConfigurationSets in the configuration.xml file, you should save your
configurations as designated by the table below.
Table 5. Configurations Locations
Configuration is Location
applicable to...
Domain or site-specific IS_SHARE/system/config/domains/<domain-name>
Domain or site/cartridge IS_SHARE/system/cartridges/<cartridge>/release/config or
specific IS_TARGET/<cartridge>/release/config (depends on the
cartridge location)

Web Server Settings Chapter 2: Intershop 7 Administration
Configuration is Location
applicable to...
Cartridge configuration IS_SHARE/system/config/cartridges
Instance or server specific IS_SHARE/system/config/servers
Managing your Configurations

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

The file environment.properties defines the environment for the ConfigurationSet
per the following:
n Process
A process environment must have a "default" set of values; these values are then
overwritten by other environments such as development, test (QA, customer,
etc.), and production.
n Application
An application environment denotes the type of Intershop 7 installation, such as
edit, live or both.
The environment for your configurations must be placed in the filename of the
configuration files. The file environment.properties defines the current environment
that you are in (for example, datacenter1). Within this file there exists the key =
value pair environment = <value>.
You can view the the configuration for a specific scope (Application Server in our
example) by doing the following:
1. Open the SMC
2. Select Monitoring
3. Application Server
4. Select Configuration Values
5. Select the Scopes drop-down where you can view the properties that
belong to the scope
Web Server Settings

Intershop 7 is shipped with the Apache HTTP Server 2.2.19. The basic configuration
including the Intershop 7 Web Adapter integration, internal SSL encryption and
vanity domain support, is performed automatically upon installation. Other features
supported by Intershop 7 (SSL box support and load balancer support) are prepared
but not enabled yet.

Chapter 2: Intershop 7 Administration Web Server Settings
NOTE: Support for other Web servers, such as Netscape Enterprise/iPlanet or IIS, can be acquired
on request.
SSL Support
Intershop 7 requires SSL support. Basically, there are two ways to enable SSL
support. One option is to encrypt/decrypt SSL communication within the Web
server itself (internal SSL encryption), the other option is to use an external
hardware unit (SSL box).
Internal SSL Encryption

The Apache HTTP Server distributed with Intershop 7 is prepared for internal
SSL encryption. Internal SSL encryption is enabled in the default configuration.
To complete the default configuration, you have to install your own certificates.
To provide your own certificates, change the file httpd-ssl.conf (Windows:
<IS.INSTANCE.DIR>/httpd/conf/extras, Linux: /etc/opt/intershop/eserver#/httpd/conf/
extras) according to your needs. For additional information, refer to the Apache
HTTP Server documentation.
To modify the SSL support settings for the Web server itself:
1. Open the httpd.conf file to edit it.
On Windows, the file is located in <IS.INSTANCE.DIR>/httpd/conf, on Linux in /
etc/opt/intershop/eserver#/httpd/conf.
2. Edit the corresponding module settings.
Find the line
LoadModule ssl_module modules/mod_ssl.so
and use a "#" sign to comment out and, consequently, disable the SSL module.
3. (Re)start the Web server.
Use a Web browser to check whether the Apache HTTP Server cannot serve
https requests anymore.
NOTE: Intershop 7 requires SSL support. If you disable internal SSL encryption in the Web server,
you must use an SSL box instead.
SSL Box Support

You may chose to encrypt and decrypt SSL communication using an external
hardware unit. In this case, the SSL box must be configured to send plain http to
a different Web server port than original http requests. The Web server and the
Intershop 7 Web Adapter must be configured to recognize this port number and to
use it internally as indicator for https.
The figure below illustrates this mechanism.

Web Server Settings Chapter 2: Intershop 7 Administration
Figure 2. SSL box support.
To enable the SSL box support with Intershop 7, make sure to configure the Web
server and the Intershop 7 Web Adapter as follows:
• Web server
Create multiple "Listen" directives and a virtual host for the new port. Refer to
your web server documentation for details.
• Intershop 7 Web Adapter
For each Web Adapter, configure the port for decrypted https and the original
SSL port in the respective webadapter.properties file.
sslbox.webserver.port=81
sslbox.public.port=443
The application server does not need to be configured for this; it can rely on
correct X-IS-SERVER_PORT_SECURE and X-IS-HOST headers for its operation.
SSL and Multiple DNS Domains

Basically, there are two ways to enable SSL support for multiple DNS domains.
n IP based virtual hosts
When serving multiple DNS domains from one Web server, you can set up a
network interface (virtual or physical) for each domain and configure IP based
virtual hosts. Each advertised DNS domain needs a dedicated SSL certificate.
NOTE: See your operating system documentation for setting up multiple network interfaces
and your Web server documentation for configuring virtual hosts.
n Multiple Web servers

Alternatively, you can set up a Web server for each DNS domain and provide it
with the needed SSL certificate.
Fail-Over Support for Load Balancing

Intershop 7 fully supports the configuration of more than one Web server/Web
Adapter instances within a cluster. To distribute requests between multiple Web
Adapters, load balancer hardware must be installed.
The Web Adapter provides an easy fail-over mechanism that load balancers can
use to check whether the Web Adapters are still in contact with their application
servers. For this mechanism to work, the httpd-webadapter.conf file (Windows:

Chapter 2: Intershop 7 Administration Web Adapter Settings
<IS.INSTANCE.DIR>/httpd/conf/extra/, Linux: /etc/opt/intershop/eserver#/httpd/conf/

extra/) includes the following setting:
<LocationMatch /wastatistics>
Require ip 127.0.0.1/32
</LocationMatch>
<LocationMatch /wastatus>
Require all denied
</LocationMatch>
This adds the wastatistics handler, enabling the Web Adapter to accept requests
like http://<host>:<port>/INTERSHOP/wastatistics.
The Web server responds to such requests with either an HTTP response code "200
(OK)" displaying a single-line HTML page "Up" if this Web Adapter can contact an
application server's configuration servlet, or an HTTP response code "500 (Internal
Server Error)" displaying a HTML page "Down" if no configuration servlet could be
contacted.
NOTE: The response statuses can be configured using the Web Adapter configuration file. See
HTTP Status Response Configuration.
Load balancers can be set up to send such requests periodically and thus, exclude
unreachable or "Down" state Web Adapters from the normal request distribution.
For more detailed information on those scenarios, refer to your load balancer
documentation.
Web Adapter Settings

The Intershop 7 Web Adapter (WA) is a Web application that distributes client
requests from public Web servers to the Intershop 7 application servers, and
implements a specialized HTTP proxy cache for application server responses. The
Web Adapter is implemented as a plug-in for the Apache HTTP Server.
NOTE: For changes to the Web Adapter setting to become effective, the Web Adapter must be
restarted.
Web Adapter Configuration Files

The Web Adapter is configured using two different configuration files:
n A global webadapter.properties file
This file is located in <IS.INSTANCE.SHARE>/system/config/cluster/. It is used to
provide global configuration information which applies to all Web Adapters
in a cluster. The Web Adapter accesses this file through an HTTP call to a
configuration servlet. Information on available configuration servlets is obtained
from the local webadapter.properties file.
n A local webadapter.properties file
Each Web Adapter has a local webadapter.properties file, located in
<IS.INSTANCE.DIR>/webadapter/. This file can be used to overload any parameter
setting from the global Web Adapter configuration file, for example to
set individual logging or tuning parameter values. In addition, the local
webadapter.properties file contains information on available configuration
servlets.

Web Adapter Settings Chapter 2: Intershop 7 Administration
The location of the local webadapter.properties file can be customized. To specify a

custom location, modify the WebAdapterProperties directive within the httpd.conf
file (Windows: <IS.INSTANCE.DIR>/httpd/conf/, Linux: /etc/opt/intershop/eserver#/
httpd/conf/) of the Web Server. Changes to the property files are effective
immediately without the need for a restart of the application server or the web
server.
Configuration Servlets
Central WA configuration data, such as timeout settings, servlet names and
dynamic registration information about available server groups (see Server Group
Definition), sites and application servers, is provided by configuration servlets.
Every application server runs a configuration servlet. In order to query the required
information, the Web Adapter periodically performs HTTP calls to an available
configuration servlet.
The local webadapter.properties file in <IS.INSTANCE.DIR>/webadapter/ must
list all configuration servlets in the cluster. The Web Adapter cannot process
requests without at least one responsive configuration servlet and a valid
property file. Contact with one configuration servlet is sufficient because every
configuration servlet is capable of providing the necessary configuration data
about the entire cluster. Fail-over functionality, however, is only available if the local
webadapter.properties file lists all the configuration servlets available in the cluster. If
one configuration servlet fails, the Web Adapter tries all other configuration servlets
to find a responsive configuration servlet.
The cs.url.<n> properties in the webadapter.properties file specify the access URLs
of each application server's configuration servlet, for example:
cs.url.0=http://<host1>:10054/servlet/ConfigurationServlet
or
Web Adapter Logging Options

In the local webadapter.properties file you can set the path and specify the file name
of the Web Adapter's request log and error log. Logging behavior can be controlled
using the central or the local webadapter.properties file.
Request Log
The request log contains information
• about incoming client requests
• about requests issued by the Web Adapter
NOTE: The request log also traces requests with errors. However, erroneous requests are logged
only if they contain "socket receive errors" (e.g., receive timeout), "application server errors" (e.g.,
HTTP status code 40x) or "depth errors" (if the maximum nesting level of includes was reached).

Request Log Configuration

The content of the request log can be processed by other tools. The log directory
can be configured via the local webadapter.properties file. The installation default is
#requestlog.dir=/<IS.INSTANCE.DIR>/webadapter/log
If you want to supply a different path, change the setting as needed and remove
the '#' character to enable this property.
For efficiency, the log entries are not written separately with each request. Instead,
they are buffered in memory until a configurable size or interval is exceeded. The
default settings are:
requestlog.enabled = true
requestlog.buffersize = 500000
requestlog.flushinterval = 10
requestlog.switchinterval = 86400
where buffersize defines the size (in bytes) of the memory where log entries are
buffered before they are written to disk, and flushinterval specifies the time
(in seconds) between flushes of the buffer to disk. The property switchinterval
specifies the interval (in seconds) when a new log file is created.
In addition, the following properties are available to control the request log
behavior, in particular, to reduce the log file size:
Table 6. Additional request log settings
Property Default Description

requestlog.includes true Controls the logging of <wainclude> requests.
requestlog.sparse true Specifies whether redundant log entries for
<wainclude> requests are skipped.
requestlog.binary true Specifies whether responses with X-IS-BINARY:1 header
are recorded.
Request Log Content

The statistical information contained in request log files is arranged in columns,
separated by the character '|'. Each request entry terminates with the character '\n'.
The column separator character '|' is replaced by '%7C' if it occurs in the logged
data.
All request log lines produced by a single client request (nested <wainclude>
requests, the client request itself and business events) are written in an
uninterrupted sequence of lines. They cannot be mixed line-by-line with other
requests or split by log rotation.
NOTE: Check the Intershop Support Knowledge Base for a complete description of the log file
format including most recent enhancements.
The following table describes the columns in detail:

Table 7. Request log content
Column Description
1 Request start time in milliseconds after 1970-01-01
2 Remote IP number (content of the CGI variable REMOTE_ADDR)
3 Remote user (content of the CGI variable REMOTE_USER)
4 Server name (content of the CGI variable SERVER_NAME)

Column Description
5 Server port (content of the CGI variable SERVER_PORT)
6 Runtime of the request in milliseconds, measured from the incoming request
until the response is sent to the Web server API
7 Request path information followed by the (optional) query-string
(<PATH_INFO>[?<QUERY_STRING>])
8 User agent (content of the CGI variable USER_AGENT)
9 Cookie(s) that were sent along with the request (content of the HTTP header
COOKIE)
10 Referrer of the requested page (content of the HTTP header REFERRER)
11 Session ID used for the request (may differ from the SID in PATH_INFO or Cookie
if the Web Adapter has assigned a new one)
12 Request ID, built as <key>-<level>-<index>, where <key> is a unique identifier
for the request and all its <wainclude>s created from host ID, process ID, time
and counter <level> is the current <wainclude> recursion depth; starting with
0 for a client request; 1 or more decimal digits <index> is the serial counter to
distinguish subsequent <wainclude>s at the same recursion level; starting with 0;
2 or more decimal digits
13 Source of the response, either: <host>:<port> – indicates that an application
server response was received and delivered from this server pc – indicates that
a pagecache response was delivered <host>:<port>:pc – indicates that an
application server response was received and delivered from this server and that
it was written into the pagecache for later reuse
14 Response status; values < 100 indicate a "200 OK" application server response
with the "X-Error" header value set; values >= 100 && < 1000 indicate the HTTP
status code, if a "X-IS-HTTPResponseStatus" response header is present, its
value wins over the actual HTTP status code; values >= 1000 indicate a handled
processing error, hence a error message is also written to the webadapter.log,
1013 (RECV_ERROR) means no response received due to socket timeout etc.,
1015 (DEPTH_ERROR) means a <wainclude> tag in the response cannot be
resolved since "include.maxdepth" is already reached
15 Time to receive the request from the client (in milliseconds). Includes the time
required to receive POST content and to parse the URL and HTTP headers.
16 Waiting time in the request's queue to get an application server thread or to find
a valid cache file (in milliseconds)
17 Time (in milliseconds) to send a request to the application server and receive a
valid response back. If the response is already present within the page cache, the
time for opening and reading the cache file is logged.
18 Time to parse the response and resolve all contained includes (in milliseconds)
19 Time (in milliseconds) required for transferring the response to the Web server.
Determined by the length of the response, the Web server buffer size to cache it,
and the connection speed between the client browser and the Web server.
20 Request method, such as GET or POST
21 The PGID, which was internally used during request processing. The column will
be empty if no personalization is involved in request and response.Note: This is
not necessarily the PGID, which is present in the client request URL. In the case
that the WA has thrown away an invalid SPGID or the AS has assigned a new
PGID to the session, the new value wins.
22 PGID state, single letter code to keep track of personalization state changes:
n -> new: no valid PGID in request; a new one is used in response URLs u -
>unchanged: request PGID used unchanged in response URLs c -> changed:

Column Description
valid PGID in request; but a new one is used in response URLs r -> removed:
valid PGID in request; none is used in response URLs empty: no personalization
is involved in request and response. Note: c and r imply that an AS request
is executed and that the response is not cached. n in conjunction with pc in
column 13 indicates an "PGID distribution page" case.
23 personalized flag, 0|1 according to <iscontent personalized="false"|"true" >, and
empty if no personalization is involved in request and response.
24 Single letter to tag the request type: p: pipeline request s: .servlet request
25 Response size as indicated in the HTTP headers. For includes the content-length
of the received response is logged. For top-level requests, the content length of
the aggregated, outgoing client response is logged, followed by a colon (":") and
the content length of the internally received response. For <wainclude>s, the
content length of the internally received response is logged. -1 if no response
size is available with streamed responses or in error conditions.
26 For top-level requests, the number of bytes transmitted to the hosting web
server API. -1 indicates an error. For <wainclude>s, always 0.
27 Secure flag, 0|1 - this flag is set to 1 if the request was detected as secure request,
otherwise it is set to 0.
28 Robot flag, 0|1 - this flag is set to 1 if the request was detected as originating from
a robot, otherwise it is set to 0.
29 Binary flag, 0|1 - this flag is set to 1 if the response has set the header X-IS-BINARY,
otherwise it is set to 0. This facilitates page impression tracking, for example,
when images are delivered via pipelines.
30 For top-level requests, the HTTP status code sent to the client with the outgoing
response. This status code may be passed as is from the response, set via a "X-IS-
HTTPResponseStatus" response header or set by the WA with its own error pages.
For <wainclude>s, always empty.
31 Page name, the value of the "X-IS-PageName" HTTP response header (or empty).
Request Log Upload Settings

The request log upload behavior is controlled by the Web Adapter Agent. The
corresponding settings are stored in the Web Adpater Agent section of the global
webadater.properties file.
The following properties are available:
Table 8. Web Adapter Agent: Request log upload behavior
Property Description
webadapterAgent.log.level Controls the logging verbosity (DEBUG, INFO,
WARN, ERROR, FATAL). Default: INFO.
webadapterAgent.requestLog. Specifies the target pipeline for uploading
upload.pathInfo the access log files. The default value
should not be changed: /BOS/root/-/-/-/
WriteFileFromRequest-Start.
webadapterAgent.requestLog. Specifies the target pipeline for clearing
serverTest.pathInfo the upload. The default value should
not be changed: /BOS/root/-/-/-/
WriteFileFromRequest-CheckServerAvailability.
webadapterAgent.requestLog. chunkSize Specifies the chunk size (in Byte) for log file
uploads. Default: 2000000.

webadapterAgent.requestLog. pushInterval Specifies the time interval (in seconds)
between upload operations. Default: 10.
Error Log
The error log will be written by the Web Adapter to indicate error situations. The
name of this file is configurable in the local webadapter.properties file. The default is
#errorlog.file=/<IS.INSTANCE.DIR>/webadapter/log/webadapter.log
In addition, errorlog.file can be configured with strftime() conversion specifiers
for time-based rotation, like .../webadapter-%Y-%m-%d.log.
The overall log level is configured using the property errorlog.level. The value can
be one of OFF, FATAL, ERROR, WARN, INFO, VERBOSE or DEBUG. The default value is
#errorlog.level = INFO
NOTE: It is not recommended to use VERBOSE or DEBUG log levels with production systems.
Runtime Log Level Configuration

Besides overriding a log level configuration in the global webadapter.properties
file with a configuration in a local webadapter.properties file, it is also possible to
override the setting of errorlog.level with specific settings for individual log scopes.
This makes it possible, for example, to obtain detailed log messages for certain
functional domains of the Web Adapter, without having to deal with the same log
detail for other domains which are of less interest for a certain purpose.
For example, with settings as below, log messages of level ERROR are recorded for
configuration service messages, and messages of level VERBOSE to trace external
HTTP traffic. For all other domains, log messages of level INFO are included with the
error log file.
errorlog.level=INFO
errorlog.level.config=ERROR
errorlog.level.httpexternal=VERBOSE
The following log scopes are available:

Table 9. Web Adapter log scopes
Log Scope Description

errorlog.level.log Messages of the log class. Only used to debug the
logging mechanism itself.
errorlog.level.fileutils Messages related to file handling operations, such as
opening, closing or deleting files.
errorlog.level.utils Messages related to parsing operations.
errorlog.level.socket Messages related to socket I/O.
errorlog.level.response Messages related to HTTP responses from the
application server.
errorlog.level.webserver Messages related to the Web Server API (e.g., queries for
request header, post content, etc.)

Log Scope Description

errorlog.level.httpexternal Messages related to external responses as passed to the
Web Server. This log scope can be used with log level
VERBOSE.
errorlog.level.httpinternal Traces communication with application server. This log
scope can be used with log level VERBOSE.
errorlog.level.main Messages related to loading the modules into the Web
Server, including checks performed on startup.
errorlog.level.request Messages related to general request processing tasks.
errorlog.level.properties Messages related to reading global and local Web
Adapter properties.
errorlog.level.session Messages related to session ID and PGID handling.
errorlog.level.pagecache Messages related to cache operations.
errorlog.level.config Traces communication with configuration service.
Log Entry Structure

Each entry in the error log file consists of a single line with the following basic
format:
<date> <time> (<hostname>) [<process-id>/<thread-id>/request-id]
<log level> <text>\n
Note that the process-id/thread-id entries may differ according to the environment.
These entries provide a unique identifier for a request handler within the machine.
For the multiprocessed Apache Web server, it is actually a combination of parent-
process-id/process-id; multithreaded servers use process-id/thread-id.
The request-id is assigned to every incoming request. It is also used in the Web
Adapter request log and in the application server error log.
NOTE: The Web Adapter opens and closes the log output file with each logged message. It is
possible to remove or rename the log file of a running Web Adapter.
Web Adapter Error Pages

The Web Adapter stores several public pages which are returned in case of general
errors, e.g., to indicate URL errors or system overload. By default, error pages are
stored in <IS.INSTANCE.DIR>/webadapter/public. Using the property errorpage.dir
of the local webadapter.properties file, it is possible to store error pages in a different
location.
NOTE: When changing the value of errorpage.dir, make sure to also adjust the Web Server directive
for the waroot alias, contained in the httpd.conf, which is used to resolve the path to images
contained in Web Adapter error pages.
Intershop 7 supports site-specific error pages. To this end, the Web Adapter looks
up error pages in the following sequence until it finds a valid page:
(1) <errorpage.dir>/<site>/<page>
(2) <errorpage.dir>/<hostname>/<page>
(3) <errorpage.dir>/<ip>/<page>
(4) <errorpage.dir>/<page>

where
n <errorpage.dir>
is the error page base directory as configured in the property errorpage.dir of
the local webadapter.properties file
n <site>
is the Intershop 7 site name of the request
NOTE: In some cases, the Web Adapter does not know the site name, e.g., in short URL requests.
n <hostname>
is the host name taken from the Host HTTP request header or – as a fallback –
from the HTTP server configuration (with Apache, ServerName)
n <ip>
is the resolved IPv4 address of the host
n <page>
is majorerror.html, overload.html, or url_error.html, depending on the error
condition.
Intershop recommends to create error pages in <errorpage.dir>/<site> with

absolute path references to this site in the ISML templates, e.g.,
<img src="/waroot/<site>/site_error_image.gif">
Symbolic links from <host>/<ip> to <site> can be used to provide the correct error
pages in case the site context is unknown but a dedicated host name exists.
Web Adapter Statistics

In order to facilitate monitoring of activity within an Intershop 7 cluster, the Web
Adapter tracks statistical data and sends these data to a configurable pipeline in
regular intervals.
With the default implementation, the Web Adapter statistics are sent to the pipeline
WebadapterStatistics-Push, which is part of the monitor cartridge. It is possible to
configure a different pipeline, in order to implement custom monitoring solutions.
The default pipeline (WebadapterStatistics-Push) writes the statistical data to a log
file in the Intershop Shared Files. The log file content is optimized for easy parsing.
Web Adapter Statistics Log

If not otherwise specified, the Web Adapter statistics is written into Intershop 7's
default log directory <IS.INSTANCE.SHARE>/system/log. The log file names
correspond to the following pattern:
<IS.INSTANCE.SHARE>/system/log/wastatistics-<instance-ID>-<date>.log
for example,
/eserver1/share/system/log/wastatistics-10.0.20.1-2010-03-25.log

Configuring the Statistics Log

To configure the Web Adapter statistics log, adjust the following properties:
n Global Web Adapter Properties File
In the global webadapter.properties, specify
n monitor.pathinfo
Configures the pipeline to which the statistics data will be sent. The default
configuration is:
monitor.pathinfo = /BOS/SMC/-/-/-/WebadapterStatistics-Push
n monitor.pushinterval
Configures the time (in seconds) between transmissions of statistics data

from the Web Adapter to the application server. The default value 0 disables
the transmission of statistics data.
monitor.pushinterval = 0
n monitor.propertyInterval
Configures the time (in seconds) between transmissions of the full set of
Web Adapter properties to the application server. Additional transmissions
(pushes) within this interval do not contain these properties. The default
value is 600. If set to 0, the properties are sent only in case the Web Adapter
properties have changed.
monitor.propertyInterval = 600
n Local Web Adapter Properties File

In the local Web Adapter properties file <IS.INSTANCE.DIR>/
webadapter/webadapter.properties, specify the Web Adapter instance
(<IS.WA.INSTANCE.ID>), for example:
monitor.instance.id = WA0
Setting this property allows to overwrite the value of <IS.WA.INSTANCE.ID>

that is sent within the statistics data. This may be necessary, for example, to
distinguish different Web servers that share the same IP address.
n Pipelet Properties of StatisticsWriterPipelet
Specify the following properties for the StatisticsWriterPipelet in the pipeline
WebadapterStatistics:
n LogDirectory
Defines the directory where the log file will be stored. Make sure that the
specified directory exists. Default:
LogDirectory = <IS.INSTANCE.SHARE>/system/log
n DatePattern
Defines the file name and the rollover of the log file. DatePattern must
match a pattern as defined in java.text.SimpleDateFormat. Default:
DatePattern = yyyy-MM-dd

Web Adapter Control Interface

Intershop 7's Web Adapter features a control interface that allows to trace and to
modify certain aspects of the Web Adapter's internal operation. It is realized as a set
of optional, "magic" request parameters, which can be appended as path segment
parameters to URLs to be finally handled by the Web Adapter.
To enable this tracing and control functionality, add the following line to either the
global or the local webadapter.properties file:
ctl.commandPrefix = wa_
The command prefix wa_ can be modified to match your preferences. Intershop,
however, recommends to use a prefix that is simple, short and unique enough.
When enabled, the interface supports URLs like
http[s]://.../<url-path>[;<prefix><cmd>[=<args>][;...]][?<url-query>]
The following table lists the available commands.

Table 10. WA control interface commands
Command Description
<prefix>help Writes the general help or the first given command's help
[;<prefix><cmd>...] message, if any.
<prefix>keep Stores the given commands in the requesting HTTP user-agent.
[;<prefix><cmd>...] These commands will apply to all subsequent requests without an
URL command parameter.
<prefix>source= Overrides the automatic server selection or session/server
<addr>:<port> affinity and uses the given application server. If applicable,
generates a new session ID, which stores this server assignment.
This command implies <prefix>flags=no-pc. Add
<prefix>flags=pc to use the pagecache in its normal way; add
<prefix>flags=pc_write to update the cache from the given
server's response. Responds with 503 Service Unavailable
if the given server is not present at all or not assigned to the
request's server group.
<prefix>flags= Skips or forces the selected features while processing the request.
<flag>[,<flag>...]
• [no-]pc_read controls the pagecache filesystem look-up
• [no-]pc_write controls the pagecache filesystem update
• [no-]pc shortcut for [no-]pc_read and [no-]pc_write
<prefix>trace[=plain| Writes a "request processing trace" instead of or into the outgoing
comment|markup] response:
• plain delivers the trace as "text/plain" message instead of the
actual response (default)
• comment inserts the trace as an HTML comment to be
displayed using the user agent's "View source" function
• markup appends the trace to the visible HTML markup
To restrict the control interface access for a defined IP range, for example, edit the
Web server configuration accordingly. That is, in <IS.INSTANCE.DIR>/httpd/conf/
extra/httpd-webadapter.conf, add something like
<LocationMatch ;wa_>
Require ip 10.0.0.0/8
</LocationMatch>

NOTE: Intershop recommends to restrict the access to the control interface for production systems.
Web Adapter Session Handling

Web based applications use session IDs (SIDs) to overcome the limitations of the
HTTP. As a stateless protocol, HTTP needs a session ID to assign certain activities to
a specific user.
Each user entering a site for the first time starts a new session and gets a unique
session ID. From that point, this SID will be used in all subsequent requests.
Depending on the lifetime value specified for a session, the IDs remain valid for a
few minutes, hours, or even days.
NOTE: The session also stores the information whether a user is logged on or not. In order
to prevent that session IDs from users currently logged on are abused by unauthorized clients,
Intershop 7 provides a complementary security mechanism based on authentication tokens. When
a user logs on, a random authentication token is generated which is stored at the session. In
addition, the authentication code is sent back to the client using a secure cookie. With each new
request within the same session, the client passes the authentication token which is then compared
with the token stored at the session. For more information, see Authentication Security Options.
Session Cookie Settings

When using the CookiePreferred mode or the CookieOnly mode, you can
define how the session tracking cookies are set in the client. To this end, the
webadapter.properties file includes the two settings
session.SIDCookie[.<site>] = <Set-Cookie>
session.PGIDCookie[.<site>] = <Set-Cookie>
where session.SIDCookie defines the SID cookie generation, and

session.PGIDCookie defines the PGID cookie generation. The default values are:
#session.SIDCookie = Set-Cookie: sid=%v; Path=/; Version=1

#session.PGIDCookie = Set-Cookie: pgid=%v; Path=/; Version=1
The placeholder %v is to be used "as is" as the actual SID or PGID cookie value.
Another placeholder, %s, expands to the request's site name (or an empty string),
which is useful in the PGID name definition.
For detailed information about the <Set-Cookie> syntax, refer to RFC 2109 (http://
www.ietf.org/rfc/rfc2109.txt).
Robot Detection
The Web Adapter can be configured to render responses without session ID or
personalization group ID occurences if the client is recognized as a robot. This
detection can be based either on the user agent request header or on a client IP
address.
session.skipForUserAgent.0=googlebot
session.skipForUserAgent.1=spider
session.skipForRemoteAddr.0=10.0.*
session.skipForRemoteAddr.1=127.0.0.1
If the client address cannot be determined from the connection (because of proxies,
load balancers or SSL boxes, for instance), it can be read from the HTTP request
header using

request.remoteAddrHeader=X-Forwarded-For
If a client is recognized as a robot via session.skipForUserAgent or

session.skipForRemoteAddr but sends requests with a session ID, it can be
redirected via 301 Moved Permanently to the session-less version of the request
using
session.skipByRedirect = <true|false>
where the default setting is false.

For easier maintenance, the list of user agents and addresses can also be kept in
plain text files. The configuration service is configured to support the following files:
• <IS.INSTANCE.SHARE>/system/config/cluster/robot-agents.txt
# comment
googlebot
spider
• <IS.INSTANCE.SHARE>/system/config/cluster/robot-addresses.txt
# comment
10.0.*
127.0.0.1
NOTE: These files are not present in the default installation, but are intended to be created
manually.
Page Cache Options

The Web Adapter can be seen as a specialized HTTP caching proxy. Whenever
possible, it stores application server responses in a cache in the local file system
and tries to respond to subsequent requests for the same resource by reading the
stored response from the cache instead of forwarding the request to an application
server.
The page cache is not session-dependent, which means that all session use
the same set of pages in the cache (unless the pages are personalized via a
personalization group ID).
Page Cache Management at Application Level

The page cache can be enabled or disabled individually for each sales channel
storefront application. The page cache options are accessed via the channel
management plug-ins for sales channels in the Intershop 7 back office. The back
offices also provides the possibility to invalidate the entire page cache manually,
and to submit pre-defined keywords in order to delete only pages from the page
cache that are marked with this keyword. See the respective channel user guides for
details.
NOTE: Enable the page cache whenever possible. Using the page cache significantly improves
storefront response times.
Page Cache Settings

The general naming scheme for locally cached static responses is:
<pagecache.dir>/<site>/static/<version>/

hh/hh/hhhhhhhhhhhhhhhhhhhhhhhhhh
The format for locally cached pipeline-generated, or dynamic, responses is:

<pagecache.dir>/<site>/pipeline/<version>/
hh/hh/hhhhhhhhhhhhhhhhhhhhhhhhhh
<pagecache.dir> is taken from the local webadapter.properties file and can be

controlled by the user. The default entry is
#pagecache.dir=/<IS.INSTANCE.DIR>/webadapter/pagecache
CAUTION: Do not store the page cache in a networked Intershop Shared Files instance, such as a ISF
connected via NFS. The increase in network traffic resulting from such a configuration significantly
reduces overall system performance.
<site> is taken from the request URL, <version> is a site attribute retrieved from the
configuration servlet. It is a timestamp that increases whenever the page cache of
a site is invalidated. After page cache invalidation, the Web Adapter will start to use
the new directory and after a while there will be no more open handles in the old
one, allowing the old directory to be removed completely.
The last two sub-directories and the filename itself are created from a hash value
printed in hex-format. The hash value is derived from a unique key string built from
the following request data (some verbatim and some shortened to internal codes):
<siteStatus>#<method>#<SERVER_PORT_SECURE>#<Host>#<serviceType>#
<PATH_INFO>[;pgid=<pgid>][?<QUERY_STRING>][#<postContent>]
Responses that depend on other request attributes, such as special headers or

cookies, cannot be cached. The <postContent> data is only appended if it does
not exceed a configurable maximum size defined in the Misc section of the global
webadapter.properties file. The default value (in bytes) is
post.cachesize = 16000
Larger POST requests are not cacheable.

The following table lists basic page cache control settings defined in the global
webadapter.properties file (Page Cache Options section).
Table 11. General page cache control settings
pagecache.static.enabled [.<site>] Enables (true) or disables (false) the static or, respectively,
pagecache.pipeline.enabled pipeline response cache. Default: true.
[.<site>]
pagecache.pageRegeneration Unix systems only: If a page is found in
Maxage the cache, which has expired less than
pagecache.pageRegeneration pagecache.pageRegenerationMaxage
Phase seconds ago, it is made valid for the next
pagecache.pageRegenerationPhase seconds before the
request is forwarded to the application server.
pagecache.ignore.# Defines a list of query attributes which are to be ignored
in the page cache lookup, mainly intended to ignore
unwanted x/y coordinates included with image button
clicks.

pagecache.allowAuthorization Enables the Web adapter to read/write its page cache
with the Authorization header. For security reasons, false
is the default value.
pagecache.monitor Enables the request/hit accounting in .wastatistics.
shm.key Unix systems only: Settings to control the shared
memory setup for multiprocessed Apache HTTP servers.
shm.size
Specify the unique identifier, the shared memory
shm.crashRecoveryLimit segment size, the access lock file and the shared
memory reinitialization behavior.
Page Cache Invalidation Settings

The page cache invalidation is triggered by the Web Adapter Agent. The
corresponding settings are stored in the Web Adapter Agent section of the global
webadater.properties file.
The following properties are available:
Table 12. Web Adapter Agent: Page cache invalidation behavior
webadapterAgent.pageCache. Specifies the server group intended to handle page
invalidationList.serverGroup cache invalidation requests. The default value should not
be changed: BOS.
webadapterAgent.pageCache. Specifies the servlet intended to handle page cache
invalidationList.servlet invalidation requests. The default value should not be
changed: /Pagecache.
webadapterAgent.pageCache. Specifies the time interval (in seconds) between requests
pageClearInterval to invalidate expired pages. Default: 60.
webadapterAgent.pageCache. Specifies the time interval (in seconds) between requests
siteClearInterval to delete deprecated page cache directories. Default:
86400.
webadapterAgent.pageCache. Can specify a comma seperated list of time intervals
siteClearForbidden (hh:mm-hh:mm), in which the page cache clearing
is forbidden. Commented by default (cache clearing
possible).
webadapterAgent.pageCache. Specifies the page cache index processors to use
index.processors globally.
webadapterAgent.pageCache. Can specify site-specific page cache index processors.
index.<site>.processors
webadapterAgent.pageCache. Can enable or disable (true|false) page cache indexing
index.<site>.enabled for a specific site.
webadapterAgent.pageCache. Switches the deletion of outdated page cache files on
expiredFiles.delete (true, default) or off (false).
webadapterAgent.pageCache. Specifies a time in seconds (default: 300) after which
expiredFiles.deletionDelay outdated page cache files can be deleted (to avoid Web
Adapter access conflicts).
webadapterAgent.pageCache. Specifies a time interval in seconds (default: 1800) after
expiredFiles.deletionInterval which outdated page cache files are searched and
deleted.

Pragma No-Cache Requests

When the Web Adapter receives client requests containing a Pragma or
Cache Control header, it will bypass its own cached pages, send the
request to an application server, and respond and update its page cache
with the new response that results from this request. This behavior can
be disabled via the pagecache.ignoreGetCacheControlHeaders and
pagecache.ignorePostCacheControlHeaders properties in the global
webadapter.properties file. The default is
pagecache.ignoreGetCacheControlHeaders = true
pagecache.ignorePostCacheControlHeaders = true
The default value is true for both properties which is the recommended value
for production systems. This ensures that it is always the application itself which
determines the caching behavior (via enabling or disabling the page cache at
application level), and not the clients. In a development environment, it may be
advisable to set the properties to false. This way, developers can verify changes
immediately by simply using the browser's refresh function, without having to
disable the page cache.
Page Cache Pre-Fetching

The Web Adapter agent features a recursive Web crawling functionality. It is
intended to refill the Web Adapter's page cache after page cache deletions,
typically after data replications. By default, the Web crawler is started and stopped
automatically based on defined schedules, or explicitly from the SMC (see Page
Cache Preferences).
NOTE: Explicitly started Web crawler runs have priority over scheduled Web crawler runs.
This means, if a crawler run is started explicitly from the SMC while a scheduled
crawler is already running, the previous process is stopped immediately, and the
new crawler request is processed.
In custom projects, any pipeline can trigger the Web crawler using the
PrefetchPageCache pipelet from the core cartridge.
General Web Crawler Control

By default, the Web crawler is enabled and sends the page requests to the IP
address of the Web Adapter. Using the local webadapter.properties file, however,
the general control settings can be changed.
Table 13. Web crawler control in the local webadpater.properties
webadapterAgent. true disables the Web crawling functionality for the local host. The
crawl.disabled default value is false.
webadapterAgent. Defines the IP address of the Web Adapter. The default value is
crawl.localaddress 127.0.0.1.
Web Crawler Configuration

The Web crawler, as part of the Web Adapter agent, retrieves its configuration
via the configuration servlet. The configuration settings are stored in

a global crawler_defaults.properties file and one or more site-specific

crawler_<site_name>.properties files, each of them located in <IS.INSTANCE.SHARE>/
system/config/cluster.
NOTE: The site-specific properties overwrite the global settings.
The following table lists the possible Web crawler configuration properties.
Table 14. Web crawler configuration
webadapterAgent. Intended to be used in the crawler_<site_name>.properties,
crawl.starturl as it defines the URL where to start to crawl the Intershop 7
pages. Multiple start URL are possible using the pattern
webadapterAgent.crawl.starturl.1=http://...
webadapterAgent.crawl.starturl.2=http://...
webadapterAgent. Specifies the maximum duration of a crawler run in milliseconds.
crawl.maxduration When the specified time is reached, the crawler run is stopped.
If the value is not set or set to -1, the maximum duration is not
limited. The default value is -1.
webadapterAgent. Specifies a time when running crawlers are stopped to give
crawl.crawluntil way to usual business traffic. The allowed format is HH:MM, e.g.,
06:30.
webadapterAgent. Specifies the maximum number of requests per minute issued
crawl.maxrate by the crawler. If the value is not set or set to -1, the requests are
sent as fast as possible. The default value is -1.
webadapterAgent. Specifies the number of links followed, starting from the start
crawl.maxdepth URL. With crawl depth 0, for example, only pages from the start
URL will be fetched, with crawl depth 1, pages are fetched from
the start URL and all links included in the start URL response, etc.
If the value is not set or set to -1, the maximum crawling depth is
not restricted. The default value is -1.
webadapterAgent. A crawling run can be distributed over multiple threads. Note
crawl.threadcount that crawling is always anonymous, i.e., no state information
is kept between single requests, and cookies are disabled. The
default value is 5.
webadapterAgent. Specifies a URL pattern (regular expression) that
crawl.denyurl prevents a link to be followed. Several patterns can be
specified appending number suffixes to the property
name, like webadapterAgent.crawl.denyurl.1=
webadapterAgent.crawl.denyurl.2=
webadapterAgent. Specifies a URL pattern (regular expression) that must be
crawl.allowurl matched for a link to be followed. Several patterns can
be specified appending number suffixes to the property
name, like webadapterAgent.crawl.allowurl.1=
webadapterAgent.crawl.allowurl.2=
webadapterAgent. Specifies a link text pattern (regular expression) that
crawl.denytext prevents a link to be followed. Several patterns can be
specified appending number suffixes to the property
name, like webadapterAgent.crawl.denytext.1=
webadapterAgent.crawl.denytext.2=
webadapterAgent. Specifies a link text pattern (regular expression) that must
crawl.allowtext be matched for a link to be followed. Several patterns can
be specified appending number suffixes to the property
name, like webadapterAgent.crawl.allowtext.1=
webadapterAgent.crawl.allowtext.2=

webadapterAgent. Specifies the maximum time (in milliseconds) for waiting for
crawl.sockettimeout socket reads. If the value is not set or set to -1, the timeout check
is disabled. Note that in case of a timeout, only the concerned
request is cancelled. The default value is 0.
webadapterAgent. Specifies the maximum time (in milliseconds) for obtaining a
crawl.connectiontimeout connection. If the value is not set or set to -1, the timeout check
is disabled. Note that in case of a timeout, only the concerned
request is cancelled. The default value is 0.
webadapterAgent. Specifies the user agent header to allow for the Web crawler to
crawl.useragent be detected as a Web robot.
webadapterAgent. Specifies the types of the response content that will be parsed
crawl.contenttypes for further links. Note that content of the default types will be
parsed in any case, even if no value is set. The default values is
text/html application/xhtml+xml.
webadapterAgent. Specifies the tag attributes that are considered as links. Note that
crawl.linktagattributes the default tag attributes are considered in any case, even if no
value is set. The default value is A/href AREA/href LINK/
href EMBED/src FRAME/src IFRAME/src INPUT/src
IMG/src SCRIPT/src BODY/background.
webadapterAgent. To be used in conjunction with .replacetemplate, can
crawl.replacepattern specify, for example, JavaScript link patterns (as regular
expressions) that must be replaced to be followed.
webadapterAgent. To be used in conjunction with .replacepattern, specifies
crawl.replacetemplate the URL template that replaces the given link pattern. For
example, with webadapterAgent.crawl.replacepattern=
[Jj]ava[Ss]cript:goSH$'(.+)'$
webadapterAgent.crawl.replacetemplate=
http://www.myshop.com/shops/$1/, the link
JavaScript:goSH('music') will be replaced with http://
www.myshop.com/shops/music/.
webadapterAgent. Can specify crawler start times. Four fields, separated by spaces,
crawl.starttime define minute, hour, day of week and day of month using a
cron-like syntax (each field can contain multiple values or value
ranges separated by commas, asterisks mean 'any', the first day
of week is Sunday = 1.) For example, 0 23 start any day at 23:00;
0 23 * * start any day at 23:00; 0 1 2-6 start from Monday to
Friday at 01:00; 0 6,22 * 1,5,15-17 start at the 1st, 5th, 15th,
16th and 17th of each month at 06:00 and 22:00
Server Group Definition

In an Intershop 7 deployment with multiple application servers, you can assign
a single application server to certain server groups in a default installation. The
default server groups are WFS for Web front requests or BOS for back-office requests.
You can also add server group names for exclusive Web front application use or
data replication processes as required.
To add a server group to the server group list, open the global Web Adapter
configuration file <IS.INSTANCE.SHARE>/system/config/cluster/webadapter.properties

and add the intended value to server.groups. For example, to set up a server
group for Data Replication processes:
• Edit the global property file and add Data Replication, making the configuration
available to all web adapters.
server.groups = WFS, BOS, DataRep
• Assign the web adapters (see Web Adapter Configuration Files) to a particular
server group by editing the property file.
NOTE: The more server groups are used, the longer the session IDs generated by the system will be.
HTTP Status Response Configuration

The instance-specific Web Adapter configuration file <IS.INSTANCE.DIR>/
webadapter/webadapter.properties can control the response status to be
returned by the Web server upon a wastatus request. To this end, the property
wastatus.defaultResponse is used.
#####################################################################
## service control
##
## Configures the regular HTTP response status of the 'wastatus'
## handler. This could be useful to exclude a running WA instance
## from load-balancing (before planned HTTP server maintenance).
## Set:
##
## 200 - to report a 'up' state (default)
## 500 - to report a 'down' state (not distinguishable from real failure)
## 503 - to report a 'down' state (with a distinct 'maintenance' code)
##
## Requires an appropriate front-end load-balancer configuration
## to be recognized - and a reset to "200" to resume operation!
#wastatus.defaultResponse = 200
SSL Box Support

If you use an external hardware unit to encrypt SSL communication, the port
for decrypted https and the original SSL port must be propagated to the Web
Adapter. In this case, edit the following lines in the <IS.INSTANCE.DIR>/webadapter/
webadapter.properties file according to your needs:
sslbox.webserver.port=81
sslbox.public.port=443
For more information on SSL box support, see SSL Box Support.
Load Balancing Between Application Servers

The Web Adapter features two load-balancing algorithms for distributing HTTP
requests between multiple application servers, a response time-based algorithm
and another one that is based on a configurable server process weighting. These
algorithms try to find the best server for each request. They distinguish between
session-bound .enfinity/.servlet requests and requests that do not rely on session
affinity, such as requests resolved by the .static handler.

Response Time-Based Load Balancing

Since there is no server load information available to the Web Adapter, it measures
the request response time of each application server and uses this data as the
quality indicator of an application server. The load-balancing achieves the best
performance of a cluster by allocating more load to machines whose response
times are shorter. All requests made as part of one session are routed to the same
application server regardless of response time. This is known as session affinity and
always applies, except in fail-over situations. Session affinity improves performance
because there is a better chance that session-related data will still be in the server's
cache, ensuring faster response times than those possible on other servers, which
would need to load this data from the database first.
The behavior of the load-balancing algorithm can be controlled by four properties,
all stored in the global webadapter.properties file.
CAUTION: Default settings for these parameters should not be changed without extensive testing.
n lb.filterperiod
The default setting for session-bound requests is:
session.lb.filterperiod = 120
and for sessionless requests:

request.lb.filterperiod = 30
As a rule of thumb, a small lb.filterperiod makes the Web Adapter react more
quickly to server performance (load) changes but also makes it more sensitive
to disturbance. Fewer requests are used to compute the quality indicator, so it is
more likely that a few expensive requests in close succession would degrade the
apparent server performance.
n lb.qualityweight
The default setting for session-bound requests is:
session.lb.qualityweight = 1
and for sessionless requests:

request.lb.qualityweight = 1
lb.qualityweight controls how much preference a faster server is given over

a slower one. With the default value of 1, a server measured as responding at
twice the speed of another server would receive twice as many sessions as the
slower server; with lb.qualityweight = 2, the faster server would receive 4 times
as many sessions, with lb.qualityweight = 3, 8 times as many and so on.
n lb.initialTimeFactor
Each newly registered application server starts with a processing time measure
determined by the filtered response time of the application server that is
currently fastest, multiplied with the value of the property lb.initialTimeFactor.
A larger property value means that the request load for this application server
increases slower after server startup to avoid server overload due to initially
short response times. If the value is too large however, the application server
might stay idle for a longer period of time. The default value is 5.0.

n lb.connectPenaltyFactor
If an application server request fails temporarily due to a connect error or
timeout, the application server is charged with a penalty time to decrease
its probability to get new sessions or requests. The lb.connectPenaltyFactor
controls the penalty time. The default value that is suitable for most situations
is 1.5. Larger values lead to a larger adjustment of the application server
probability, so that multiple connect problems have a higher impact on the
number of sessions and requests that will get assigned to this application
server. They may be used in deployments with many application server threads
where a connect error indicates serious or rare overload situations. However,
in high-load situations larger values can also cause an unstable, uneven load
distribution due to over-reaction to single connect problems.
Change the default settings only if necessary, as they are sensitive. An indication
for load balancing problems might be a very uneven and unstable workload
distribution among the application servers over a longer period of time. Keep in
mind that there might be a number of other issues that lead to uneven application
server load, for example single sessions that introduce an exceptional high load
on the system, or back office activities like data updates as well as Intershop 7 jobs
running on certain application servers.
Weight-Based Load Balancing

With this mechanism, each application server process is configured with a weight
value. The value is supposed to indicate this server's theoretical request processing
capacity in relation to the other servers. The server usage probabilities - as derived
from the average response time measure - are corrected with the relative weight of
the server within all available servers.
Assume one 4-core and one 8-core server with equal CPU clock-frequencies and
response times. Normally, they share the load 50:50, maybe leading to a 80% host
utilization of the smaller server and a 40% utilization of the larger one. To have a
larger share of the load in the larger server, we have to "overload" the smaller one:
Response times will increase, the usage probability will decrease. With the new
weight setting, this can be done without reaching the "beginning overload" state,
as illustrated below:
Table 15. Weighted load balancing effects
Server Average Original Weight Weighted

response time probability probability
4-core 100 ms 0.5000 40 0.3333
8-core 100 ms 0.5000 80 0.6667
Each application server process (not host) - uniquely known to the Web Adapter
by <IP>:<port> - is assigned exactly one weight value. The built-in default weight
is 1. Custom values are specified using the lb.serverWeight* settings in the
webadapter.properties file. These settings can be either global or specific per
netmask, host or server process, using
lb.serverWeight = <weight>
lb.serverWeight.<CIDR> = <weight>
lb.serverWeight.<IP> = <weight>
lb.serverWeight.<IP>.<port> = <weight>

Chapter 2: Intershop 7 Administration Intershop 7 Application Settings
where <CIDR> is the netmask in CIDR notation, <IP> is the IPv4 network address
in decimal dotted notation, <port> is the TCP port number, and <weight> is the
integral weight value (0..99999). The last matching setting - the most specific one -
wins.
NOTE: Settings in the local <IS.INSTANCE.DIR>/webadapter/webadapter.properties file will win over
<IS.INSTANCE.SHARE>/.../webadapter.properties only if they provide an equal or better match. A local
lb.serverWeight = 10 will not override a shared lb.serverWeight.10.0.0.1 = 20.
When using this load-balancing algorithm, keep the following issues in mind:
• Choose your (integral) weight values so that you can adjust their relations
exactly enough: Use "10/20" instead of "1/2". Later, if you see that the "double
capacity" assumption is wrong, you can adjust it to "10/18".
• Check the webadapter.log. Invalid settings are ignored with a warning here. You
do not want a flooded log and an incomplete cluster setup in production.
• A weight of 0 can be used to exclude a server from getting new sessions or new
single requests. However, it will still receive requests from the existing sessions,
which are bound to it. But it could help to exclude a server from production
load, e.g., for an upcoming local patch testing.
• The effective server weight configuration can be monitored in the
.wastatistics dump. If the feature is in use, there is a new "weight" column in
the per-server statistics. Also, the successfully parsed lb.serverWeight* settings
are reported. The "( <n> matches)" output indicates how many servers got
their actual weight setting from this particular rule. This may help in complex
configurations like determining, for example, if a new rule exactly selects the 16
servers that were intended.
webadapter.properties settings:
lb.serverWeight = 40
lb.serverWeight.10.0.29.64/26 = 80
/is-bin/INTERSHOP.wastatistics output:
single: server ... ms_f weight WFS BOS TEST
0 10.0.29.19:10099 1 40 0.1667 0.3333 -
1 10.0.29.20:10099 1 40 0.1667 - -
2 10.0.29.64:10099 1 80 0.3333 0.6667 1.0000
3 10.0.29.65:10099 1 80 0.3333 - -
...
properties:
...
lb.serverWeight = 40 ( 2 matches)
lb.serverWeight.10.0.29.64/26 = 80 ( 2 matches)
Intershop 7 Application Settings

The Intershop 7 application comprises the ORM engine, the core cartridge and the
Intershop 7 business logic cartridges.
The basic settings that apply to the Intershop 7 applications in the cluster are stored
in the appserver.properties file located in <IS.INSTANCE.SHARE>/system/config/
cluster/.
NOTE: The appserver.properties file is processed on server startup. When changing application
settings, you have to restart the application server for changes to take effect.

Intershop 7 Application Settings Chapter 2: Intershop 7 Administration
Server 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.SHARE>/system/config/
servers/<HOST.ID>/<INSTANCE.ID>. <HOST.ID> is the IP address of the hosting
machine, and <INSTANCE.ID> identifies the Intershop 7 instance. This value is
defined in the intershop.properties file of the Intershop 7 instance.
A sample structure is shown below:
<IS.INSTANCE.SHARE>/system/config/servers/10.0.33.33/ES1
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.SHARE>/system/config/servers/<IS.AS.HOSTNAME>/
<IS.INSTANCE.ID> and edit it as needed. The settings in the local properties file will
override the global application settings.
NOTE: Technically, all properties described in this section can be set as server instance specific.
Event Settings
The messaging cartridge is the Intershop 7 component used to send event
messages inside an Intershop 7 cluster. It implements an API that integrates simple
multicast messaging in addition to an extensible framework for adapting external
messaging systems to Intershop 7. Currently, JMS and JGroups are supported out of
the box; additional systems can be implemented on a project-specific base.
There are four types of events that are distributed. Each type uses a dedicated
messaging channel. The name of the messaging channel is identical with the prefix
of its corresponding configuration properties:
• General application server events (event manager of the core cartridge)
intershop.event, to be configured in <IS.INSTANCE.SHARE>/system/config/
cluster/appserver.properties.
For details about configuring general event messaging, see Application Server
Event Settings.
• Cache engine message events (cache cartridge)
intershop.cacheengine.wrapped, to be configured in <IS.INSTANCE.SHARE>/
system/config/cluster/cache.properties.
For details about configuring cache engine messaging, see Cache Engine
Messaging Settings.
• ORM cache synchronization events (orm cartridge)
intershop.cacheSync, to be configured in <IS.INSTANCE.SHARE>/system/config/
cluster/orm.properties.
For details about configuring ORM cache synchronization events, see PO Cache
Synchronization Settings.
• Tomcat cluster management events (TCM module)

intershop.tcm.event, to be configured in <IS.INSTANCE.SHARE>/system/tcm/

config/tcm.properties.
For details about configuring TCM event messaging, see Table 73, “Cluster
management settings”.
NOTE: If there are several Intershop 7 clusters in one subnet, a cluster may receive events from a
foreign cluster if both clusters happen to be using the same messaging channel (address) and port.
In this case, you have to specify a unique messaging channel and port for each cluster.
Depending on the used messaging system (multicast, JMS, JGroups or a custom

implementation), the set of specific properties may vary. But for convenience and
compatibility reasons, the configuration of the existing messaging channels reside
in the same properties files and start with the same prefix. That is, when configuring
event messaging in your Intershop 7 systems, you can select one of the three
available messengers, where multicast is the default, by enabling and adjusting the
corresponding pre-configured settings, or you can implement a custom solution
using the pre-configured systems as a blueprint.
The following sections list the messaging system-specific properties.
Multicast Messaging Setup

Multicast communication is the default method used for sending event messages
between applications. Its configuration options are listed below.
Table 16. Multicast configuration options
messengerClass Sets the messenger class to be used (required), the
default is com.intershop.beehive.messaging.internal.
multicast.MulticastMessenger.
multicastAddress Sets the class D IP address of the multicast group
(required).
multicastPort Sets the UDP port for the multicast group (required).
multicastInterface Sets the IP of the nework interface for outgoing packets.
multicastTimeToLive Sets the time to live for the multicast socket, used for
multicast routing.
multicastReceiveBufferSize Sets the size of the ReceiveBuffer for packets, should be
configured in the underlying operating system as well.
multicastListenerThreads Sets the number of spawned threads for receiving
multicast packets.
multicastPacketSize Sets the size of the byte array for the receive()
method of the multicast listener threads and therefore
the maximum size of a packet, maximum is 64k.
JGroups Messaging Setup

With JGroups, sending and receiving occurs over a JGroups channel, the payload
is a byte array. There are three sending modes: no acknowledgement, async
acknowledgement, sync acknowledgement.
The configurable options for JGroups are listed below:

Table 17. JGroups configuration options
default is com.intershop.beehive.messaging.internal.
jgroups.JGroupsMessenger.
jgroupsChannelName Sets the JGroups channel (required), a message sent
to a channel is received by all clients registered to this
channel.
jgroupsProtocolStackConfigFile Optional configuration for the underlying protocol stack
used by JGroups.
jgroupsRequestTimeout Sets the request timeout for message sending. When a
message is sent and the client does not respond within
the request timeout, the delivery counts as failed. Setting
this to 0 means wait indefinitely.
groupsResenderRequestTimeout Sets the rquest timeout for the message resender.
jgroupsAcknowledge Enables message acknowledgements (true|false).
jgroupsSyncAcknowledge If message acknowledgment is enabled, specifies
whether to do it synchronously. If so, the message
sender thread waits for all acknowledgments to arrive
before continuing. Otherwise the acknowledgment is
delegated to a future listener.
jgroupsRunnerThreadSleep Specifies how long the run() method of the messenger
thread will sleep (0 = no sleep).
jgroupsResenderThreadSleep Specifies how long the message resender threads waits
between resend attempts.
JMS Messaging Setup

This service must be set up with a JMS server that provides the configured event
topics (event channel, tcm channel, etc.). This should be a stand-alone server for
optimal performance, though the amount of RAM is dependant on the number of
messages you expect.
The configurable options for JGroups are listed below:
Table 18. JMS configuration options
default is com.intershop.beehive.messaging.internal.jms.
JmsMessenger.
jmsBackend Sets the type of the JMS provider backend (hornetq|
activemq). This parameter is required.
jmsProviderURL Needed to lookup the JMS components with JNDI on
the JMS server. This parameter is required.
jmsTopicName Sets the name of the JMS topic the messages are sent
to / received from.
jmsReceiveMessagesSync Sets how the JMS messenger receives messages.
Synchronously means the receive() happens in the
messenger thread. Asychronously means a separate
listener thread is spawned.
jmsSessionAcknowledgeMode The mode JMS messages are acknowledged.

jmsPublisherDeliveryMode The deliveryMode for the topic publisher, sets if the
JMS server stores the messages in a database so they
could be redelivered after JMS server restart. If this is
wanted the JMS server has to be configured accordingly.
See javax.jms.MessageProduce.
jmsDisableMessageId Sets if a message id is added to the JMS message header.
Reduces the message size if not set.
jmsDisableMessageTimestamp Sets if a timestamp ID is added to the JMS message
header. Reduces the message size if not set.
jmsRunnerThreadSleep This sets how long the run() method of the messenger
thread will sleep (0 = no sleep). This is the fallback
configuration if values are not set in the configuration
(defined in the messenger class).
Application Server Event Settings

Event communication is widely applied in the cluster management. If there are
several Intershop 7 clusters in one subnet, a cluster may receive events from a
foreign cluster if both clusters happen to be using the same multicast IP and port. In
this case, you have to specify a unique multicast IP and port for each cluster in the
appserver.properties files, located in <IS.INSTANCE.SHARE>/system/config/cluster/.
To change the event communication settings:
1. Open the appserver.properties files.
In the Event
Options section, the parameters messengerClass,
multicastAddress and multicastPort are required. The default entries for
event multicast communication are
intershop.event.messengerClass=
com.intershop.beehive.messaging.internal.multicast.MulticastMessenger
intershop.event.multicastAddress=239.1.2.3
intershop.event.multicastPort=1234
#intershop.event.multicastInterface=
#intershop.event.multicastTimeToLive=
#intershop.event.multicastReceiveBufferSize=1048576
intershop.event.multicastListenerThreads=10
intershop.event.multicastPacketSize=65000
NOTE: If you intend to use other messaging systems than the default multicast, you must
enable and adjust the corresponding intershop.event properties (see Event Settings).
2. Enter a unique multicast IP and port for each cluster.

The property intershop.event.multicastAddress determines
the group address for multicast messages, hence identifies the
recipients of the multicast messages sent out for a specific cluster. For
intershop.event.multicastAddress, Intershop 7 supports values between
239.0.0.1 and 239.255.255.255; for intershop.event.multicastPort, any valid
port number above 1024 is allowed.
3. Specify, if applicable, the network interface for multicast communication.
By default, the network interface of a host is used to transmit multicast traffic.
If there are multiple network adapters installed, you can specify the IP of
the network interface to use for multicast messaging as value of property

intershop.event.multicastInterface. This makes it possible, for example,

to separate administrative traffic from Web front traffic. Note that machine-
specific interface configurations have to be defined in the appserver#.properties
file (located in <IS.INSTANCE.SHARE>/system/config/servers/<HOST.ID>/
<INSTANCE.ID>/) of the respective server instance. For an example scenario, see
Multihomed Hosts.
4. Specify, if applicable, the time-to-live of a multicast packet, the receive
buffer size, and the number of multicast handler threads.
By default, multicast messages are sent only to systems on a local network. If
the multicast messages are intended to be sent to distant networks, and if there
is a special multicast router on the local network, the application can increase
the scope of the multicast by using the intershop.event.multicastTimeToLive
property. The default time-to-live value is 1, which means the multicast is
limited to a local network. If the value is 2, the multicast can forwarded through
at most one gateway, and so forth. The maximum value is 255. Note again
that in this case, the routers must be configured to pass the IP multicast traffic
between the connected application server subnets.
5. Save the changes and restart the Intershop 7 cluster for the new settings to
take effect.
Fail-Over Settings
An Intershop 7 application process sends out event messages (default multicast)
regarding its own status every couple of seconds and receives similar data from
the other applications in the cluster. In this way, each application is able to track
all running applications in the cluster and maintain a list of known applications. To
remove applications that have become unavailable, this list is cleaned up regularly
by an expiration thread. Each registered application 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:
n intershop.registration.registrationTime
The time in seconds after which each application 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.
n intershop.registration.expirationTime
The time in seconds after which a registration at another application becomes
invalid. The default value is 30.
NOTE: 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" application 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 application 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.
Figure 3. Fail-over time line of a crashed server
Servlet Engine Settings

The Intershop 7 application 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.
NOTE: It is not possible to configure the internal servlet engine directly via a server.xml file.
n 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
local appserver#.properties, for one application in the first Intershop 7 instance is:
intershop.servletEngine.connector.port=10054
n 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.minProcessors=10
n intershop.servletEngine.connector.maxProcessors
If 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.maxProcessors=75
n intershop.servletEngine.connector.acceptCount
If 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.acceptCount=300

n intershop.servletEngine.connector.address
This 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
Multihomed Hosts). If no address is provided (default), the servlet engine
accepts requests from all available network interfaces.
Application Logging
The Intershop 7 logging framework is used to log application events. Intershop 7
sends logging messages via SLF4J, which interfaces to logback as logging system.
The combination of SLF4J and logback allows Intershop 7 to produce more detailed
log information and to integrate third-party APIs (log4j, Jakarta Commons Logging,
java.util.logging, etc.) into its logging framework.
The application log files are located in the directory <IS.INSTANCE.SHARE>/system/
log/. The available options are controlled via logback configuration files logback-
*.xml and the Intershop 7-specific logging configuration files. For details about the
configuration, refer to Application Logging: Configuration.
Application Logging: Basic Concepts

The main configurable components of the logging framework include:
n Logger
Generally, loggers are the central framework objects that provide the methods
for creating and sending log events. However, "logger" is also used to name the
log categories (see below).
n Category
Loggers are categorized by their name, based on a hierarchical naming rule.
They are usually named according to their corresponding classes. Thus, for
instance, the logger com.intershop is parent of com.intershop.adapter. At the
top of the hierarchy, there is always the root logger (or root category).
Categories are used to filter the log output. As the logger name corresponds to
the class name, it indicates the code location that produces a log message.
n Appender
Appenders are responsible for sending the log message to a target, i.e., an
output destination.
A logging request will be forwarded to all appenders specified for a logger as
well as to any appenders higher in the hierarchy, i.e., appenders are inherited
additively from the logger hierarchy. To limit this appender inheritance in a
certain category, you can explicitly set the additivity flag of that logger to false,
converting this category to a root category in the given context.
n Level
Levels are used to hierarchically catagorize log messages by severity. Supported
levels include ERROR, WARN, INFO, DEBUG and TRACE.
NOTE: The root category should always be assigned the TRACE level to enable child category
appenders to capture messages of any level.

n Filter
Adding filters to appenders allows for selecting log events according to various
criteria. With respect to filters, consider the following aspects:
n LevelFilter vs. ThesholdFilter
Fixed-level filters accept or deny events of the specified level, whereas
threshold filters can accept or deny events of higher or lower levels, too.
n EvaluatorFilter
Evaluator filters decide whether to accept or deny the log request based on
Java expressions that may check the logging event for specific criteria, like
levels, logger names, MDC contents, message texts, etc.
Evaluation expressions can be Java blocks, see http://logback.qos.ch/
manual/filters.html#evalutatorFilter.
n Turbo Filter
As opposed to filters assigned to appenders, turbo filters apply globally. They
preselect the output before the actual logging event is created. Intershop 7
generates a TurboThresholdFilter automatically based on the lowest level defined
for any appender.
n Layout
Layouts format the log output and return a string. In the initial configuration,
Intershop 7 uses PatternLayout, which allows for customizing the output string
based on a configurable conversion pattern.
<layout> must be enclosed in <encoder>, see http://logback.qos.ch/manual/
layouts.html.
n Mapped Diagnostic Context (MDC)
MDCs can be seen as additional logging context definitions that enrich the
logging events and, consequently, allow for further filtering options.
Intershop 7 provides a configurable mechanism to enrich the MDC API. These
customizations are configured in <IS.INSTANCE.SHARE>/system/config/cluster/
logging.properties. By default, the following MDC enhancements are avialable:
Table 19. MDC objects in Intershop 7
MDC Value Type and Description

Request com.intershop.beehive.core.capi.request.Request
Session com.intershop.beehive.core.capi.request.Session
User com.intershop.beehive.core.capi.user.User
JobConfiguration com.intershop.beehive.core.capi.job.JobConfiguration
Stack java.util.Stack
Process com.intershop.beehive.core.capi.locking.Process
Application Logging: Configuration

The logging framework options are controlled via a global logback configuration
file and cartridge-specific logback configuration files, as well as a global Intershop 7
logging configuration file and server-specific Intershop 7 logging configuration
files.

logback Configuration Files

Upon application server startup, Intershop 7 dynamically creates the internal main
logback configuration file. This file sets some basic properties and defines a list of
<include> elements, which, basically, constitute the logback-*.xml files as described
below.
The internal logback configuration could look, for example, like this:
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
<property name="intershop.logging.start" value="2012-07-12_12-59" />
<property name="intershop.InstallationID" value="ES1" />
<property name="intershop.HostName" value="localhost" />
<property name="intershop.ServerName" value="appserver0" />
<property name="intershop.serverlogfile.Directory"
value="/eserver1/engine/tomcat/servers/appserver0/logs" />
<property name="intershop.logfile.Directory"
value="/eserver1/share/system/log" />
<property name="intershop.logfile.NamePostfix"
value="localhost-ES1-appserver0" />
<include file=".../config/cluster/logback-main.xml"/>
<include file=".../config/cartridges/logback-bc_auditing.xml"/>
<include file=".../config/cartridges/logback-bc_pricing.xml"/>
</configuration>
The central logback configuration file <IS.INSTANCE.SHARE>/system/config/cluster/

logback-main.xml controls the cluster-wide appenders and loggers. Any cartridge-
specific configuration is passed via logback-<cartridgename>.xml files located in
<IS.INSTANCE.SHARE>/system/config/cartridges. In addition, Intershop 7 provides a
dedicated dbinit log configuration file (<IS.INSTANCE.SHARE>/system/config/cluster/
logback-dbinit.xml), which is added to the dynamically generated configuration if
the application server is started in dbinit mode.
Basically, the appender definitions in the logback-*.xml files specify
• an appender name for internal reference,
• a type (file or console) via the class attribute,
• a filter and an according level or filter expression,
• a rolling policy, e.g., for time-based or file size-based log file rolling,
• a layout and an according pattern to be used.
In addition, the logback-main.xml file defines

• levels for common logger categories, such as root assigned with the TRACE level
(which should not be changed),
• assignments of appenders to categories.
For information about creating project-specific appenders or customizing existing

ones, contact Intershop Support, or refer to the logback documentation.
The System Management Console provides an interface to upload and manage
additional logback configuration files, which allow for changing the logging details
at server runtime, e.g., for maintenance reasons. For details, see Additional Logging
Configuration Files.

Intershop 7 Logging Configuration Files

The file <IS.INSTANCE.SHARE>/system/config/cluster/logging.properties controls
the global, i.e., cluster-wide Intershop 7-specific logging settings. Intershop 7-
specific logging settings can be defined locally, i.e., on application server level,
using <IS.INSTANCE.SHARE>/system/config/servers/<HOST.ID>/<INSTANCE.ID>/
appserver#.properties.
Basically, the global logging.properties file defines
• MDC enrichment for certain object types used in the current Intershop 7
instance, using Java expressions
intershop.logging.mdc.types=<type>
intershop.logging.mdc.<type>.class=<fully_qualified_class_name>
intershop.logging.mdc.<type>.attr.<attr1_ID>=<Java_expression>
intershop.logging.mdc.<type>.attr.<attr2_ID>=<Java_expression>
• default categories, encoding and pattern for any dynamically created

appenders, to be used as fallback if not defined explicitly, for instance
intershop.logging.dynamictarget.categories=root
intershop.logging.dynamicfiletarget.encoding=
intershop.logging.dynamicfiletarget.pattern=
[%date{yyyy-MM-dd HH:mm:ss.SSS z}]
[%thread] %-5level %logger{36} - %msg%n
NOTE: If no encoding is specified, Intershop 7 uses the default platform encoding when writing
log output.
• default JDK logging adapter settings, namely

intershop.logging.javaloggingadapter.enable=true
intershop.logging.javaloggingadapter.exclusive=true
• level filters and category assignments for existing appenders as changed via the
SMC, see Changing the Logging Settings.
• appender settings that control specific appender behavior, like, for example,
intershop.logging.appender.buffer.flushInterval, which defines the
interval that appenders with <immediateFlush>false</immediateFlush> (as set,
for example, in logback-main.xml) are flushed.
• the level of logback status messages (ERROR, WARN, INFO) that are passed to
system.err and automatically appended to the application server log files, as
well as the number of status messages stored with each application server, e.g.,
intershop.logging.engine.statuslogging.level=WARN
intershop.logging.engine.statusbuffer.size=500
Application Logging: Default Log Output

The following table lists the columns of the log output as provided by the default
error and warn appenders defined in logback-main.xml. This information is
expected, for instance, by the Intershop CIC.

Table 20. Default log output
Column Description
1 Date, time and time zone (in square brackets), e.g., [2008-04-16 12:34:55.501 CEST
+0200]
2 Log level
3 Host name or IP address
4 Intershop 7 instance, e.g., ES1
5 Application server ID, e.g., appserver0
6 [Site name]
7 [Request application URL identifier]
8 Log category, i.e., the class name
9 [Marker], set by the log message author
10 Request type, e.g., storefront, job, backoffice, etc.
11 [Session ID]
12 [Request ID]
13 Java thread name (in double quotation marks)
14 Log message
Hence, a default log output could look as follows:

[2012-07-16 12:34:55.501 CEST+0200] WARN 127.0.0.1 ES1 appserver0 [] []
com.intershop.adapter.saferpay.AcSaferpayCartridge [] [] [] [] "main"
cartridge property: 'intershop.cartridges.ac_saferpay.sac.installation
.path' is *not* found!
Application Logging: Simple Back-Office Auditing

To support PA-DSS compliance for Intershop 7-based e-commerce applications,
Intershop 7 features a simple back-office logging system. It records payment-
relevant back-office user operations, including
• logging in,
• changing passwords,
• creating or deleting users,
• capturing or cancelling payments,
• changing order states
into the dedicated log file audits-PCI-<IS.AS.HOSTNAME>-<IS.INSTANCE.ID>-

appserver<ID>.log, located in <IS.INSTANCE.SHARE>/system/log. The messages states
the result of the performed operation (success or error), as well as any additional
data, if available.
The back-office auditing log is enabled by default. To this end, the standard logging
configuration file logback-main.xml includes a dedicated appender definition and
corresponding category assignments.

User Tracking Options

By default, an Intershop 7 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 contained in the global
appserver.properties file.
Table 21. User tracking properties
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. Text A description of the cookie. This is displayed if
comment users ask to accept each cookie manually.
intershop.user.cookie.maxage Integer The expiry time of the cookie in seconds. Set
the value to -1 for the cookie to expire when
the browser is closed; a value of 86400 lets the
cookie expire after one day.
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.myshop.com, for example, would result in cookies that
are only valid for the domain www.myshop.com. Since merchants may run their site
on mobile.myshop.com and www.myshop.com, they have to share the cookies. To this
end, the domain field for the cookie must be set to .myshop.com.
Some core features of Intershop 7 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.
Table 22.

intershop.user.cookie.domain String Defines the domain for which user cookies are
valid.
intershop.user. String Defines the domain for which authentication
authenticationstatetokencookie. state token cookies are valid.
domain
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. String Defines the domain for which recently viewed
cookie.domain items cookies are valid.
Following the example above, these properties could look like this:

intershop.user.cookie.domain=.myshop.com
intershop.user.authenticationstatetokencookie.domain=.myshop.com
intershop.basket.cookie.domain=.myshop.com
intershop.abtest.cookie.domain=.myshop.com
intershop.recentlyvieweditems.cookie.domain=.myshop.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 Session Cookie 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=.myshop.com; Version=1
session.PGIDCookie = Set-Cookie: pgid-%s=%v; Path=/; \
Domain=.myshop.com; Version=1
Session Handling Options

Session handling is a task shared between Web Adapter and application server.
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 Web Adapter Session Handling.) The application server 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 7 features several options that determine how the application server
deals with sessions. These options are also set in the global appserver.properties file,
as detailed in the following table.
Table 23. Session handling properties

intershop.session.TimeOut Integer Time-out of an application server session
object in minutes after the last request.
intershop.session. Boolean Allows the persistent storage of session
AllowPersistent information in the database. This is necessary
if you want to continue a session after a server
has become unavailable (session failover), the
default value is true.
intershop.session. Boolean Allows to restore a session that has timed out.
RestoreExpiredSessions The default value is false.
intershop.session. Boolean In failover scenarios using multiple application
CheckRestoredSessions servers, this setting forces re-reading
of recovered session information from
the database on subsequent requests.
Commented out by default.
Authentication Security Options

The session also stores the information whether a user is logged on or not. In
order to prevent that session IDs from users currently logged on are abused by
unauthorized clients, Intershop 7 provides a complementary security mechanism
based on authentication tokens. When a user logs on, a random authentication
token is generated, which is stored at the session. In addition, the authentication
code is sent back to the client using a secure cookie. With each new request

within the same session, the client passes the authentication token which is then
compared with the token stored at the session.
NOTE: The authentication security mechanism only works with clients allowing for cookies.
The authentication security mechanism is controlled via the property

intershop.AuthenticationSecurity.Mode
This property provides the following options:

n Standard
With the option standard, the system does not generate authentication codes.
This disables the authentication security mechanism. If an attacker hijacks a
session ID, the login state is hijacked as well. Hence, with a session ID of a user
currently logged on, the attacker can act on behalf of this user.
n Secure Cookie Preferred
With the option secure_cookie_preferred, the authentication security
mechanism is used in case the user's browser allows for cookies. If the browser
does not allow for cookies, the session proceeds without using the additional
authentication security mechanism.
When using this mode, all pages that a logged-in user can access must be
encrypted.
n Secure Cookie Only
With the option secure_cookie_only, the authentication security mechanism
must be used. A user can only log on in case the browser allows for cookies.
When using this mode, all pages that a logged-in user can access must be
encrypted.
Schedule Execution Options

Intershop 7 supports the automatic, recurrent execution of business workflow
processes, or pipelines. At defined dates and times, the job processor triggers the
scheduled pipeline.
Irrespective of the settings made in the Schedules Manager, 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 7 installation differs from

the default value 10, change intershop.job.maxJobNumber accordingly.
NOTE: A higher number of parallel schedules increases demands on the Intershop 7 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
Web Server URL Settings

The Intershop 7 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
URL settings are stored in the appserver.properties file, and the corresponding
values are set during Intershop 7 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.
URL Handling
Generally, there are four options for modifying Intershop 7 URLs:
n 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.
n URL rewriting
URL rewriting is a mechanism that enables Intershop 7 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.
n URL parameter whitelisting
Dubious web sites or users may intend to infect Intershop 7 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 7 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.
n Short links
Short links are "hard-coded abbreviations" for complete Intershop 7 URLs, which
are used to map target URLs to short, search engine-friendly URLs. Short links
are managed in the Intershop 7 back office. For more information, refer to the
Intershop 7 user guide Managing Online Shops.
NOTE: With respect to URL handling, make sure to procure the intended DNS name entries.
URL Configuration
By default, the Intershop 7 URL is structured as shown in the following:
http[s]://[servername]:[port]/[individualpart]/
[indvidual mapping parameter]/[servergroup]/[site id]/[locale]/
[application URL identifier]/[currency]/[pipeline to call]
With the default parameters in an Intershop 7 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 [individualpart]

and the [indvidual mapping parameter]:
n intershop.urlmapping.urlPrefix
Specifies the [individualpart] 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).
CAUTION: Do not uncomment this key. To disable the prefix, leave the value empty.
n intershop.urlmapping.*.webadapter
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
...
Table 24. Default mapping parameters
Parameter Description
intershop.urlmapping. Default value is set to either /INTERSHOP or /is-bin/intershop, and
urlPrefix can be changed.
/INTERSHOP/web Calls a pipeline.

Parameter Description
/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.
URL Rewriting
As already mentioned, URL rewriting provides one of several means that help
optimizing Intershop 7 sites for search engines. The default implementation of
Intershop 7's URL Rewrite Handler uses cartridge-specific configuration files to
retrieve the rules that define how Intershop 7 URLs are transformed into search
engine friendly URLs.
NOTE: 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 regulare expressions is required.
NOTE: For details about actual rule configuration, examples, etc., refer to the "URL Handling"
concept and cookbook articles on the Intershop Knowledge Base.
URL rewriting is enabled individually per site via the Site Management module
of the System Management Console (SMC, see General Site Preferences). 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 7 cluster.
These general rules may be used to:
n Remove default URL parameters by defining a mapping to (multiple) host
name(s)
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

n Define 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 7 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 7 URL, use
domainsplitting.host_1.shortpathpattern = /${locale}${PATH}
n Specify alternative values for 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 7 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.
NOTE: URL parameter whitelisting only works with requests that are rewritten using Intershop 7'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.
There are two options for setting the allowed parameters:

n Development
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.
n Configuration
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>]
NOTE: 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.
In case mandatory parameters are missing, Intershop 7 writes an entry into the
ERROR and WARN log files, but continues processing the request with the available
parameters.
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

n 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.
n intershop.template.MaxIncludeDepth
Specifies the maximum depth for local template includes to impede recursive
includes. The default value is 10.
Template Update Options

Three additional properties are available which 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.
n 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.
NOTE: If the value for CheckSource is false, the settings for CheckSourceInterval and
CheckSourceModified have no effect.

n 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 7 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.
n 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 intervals 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 which 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).
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.
CAUTION: 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.
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.
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 7 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 7 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, see
the Application Programming Guide.
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.
Table 25. Pipeline processing settings

intershop.pipelines. Boolean Checks the modification time of pipelines and
CheckSource 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. Boolean Specifes whether the localized descriptor files
LoadLocalizedPipeline for pipelets and pipelines are loaded (true|
Descriptors false). The default is false.
intershop.pipelines.strict. Boolean Specifies whether the pipeline is checked for
CheckParameterTypes the 'strict' node parameter, i.e., where both
start and end nodes are set 'strict' (true|false).
The default is false.
intershop.pipelines. String Used to preload the pipelines from the
PreloadFromCartridges 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. String Used to preload the pipelines from the
PreloadFromSites 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. String Used to preload the pipelets from the specified
PreloadFromCartridges 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. String Used to switch on the pipeline transaction
transaction.Default synchronization. The default values
SynchronizationScope are CurrentSession for the scope and
CurrentStartNode for the object. This will
intershop.pipelines.
synchronize incoming requests at transaction
transaction.Default
boundaries within one session if the same
SynchronizationObject
initial pipeline start node was called. Sub-
pipeline calls are not considered.
ORM Engine Options

For handling persistent objects (POs), Intershop 7 uses the ORM engine. This engine
features a PO cache which stores generated POs in order to increase application
performance by reducing database calls. ORM engine settings can be defined
globally for the entire cluster, or locally for individual server instances.
• Global settings are stored in the global orm.properties and appserver.properties
files, both located in <IS.INSTANCE.SHARE>/system/config/cluster/.
• Local settings for the ORM engine can be stored in the local
appserver#.properties files, located in <IS.INSTANCE.SHARE>/system/config/
servers/<HOST.ID>/<INSTANCE.ID>.
Database Connection Settings

The ORM engine supports three options for connecting to the database:
• using the JDBC DriverManager
• using JNDI for connecting to an existing data source defined by the application
server
• creating an own data source using the JDBC Driver
By default, Intershop 7 is set up to create its own data source.

CAUTION: Do not use the data sources provided by the underlying application server, as this may
have a negative impact on performance and stability. It is strongly recommended to use the data
source created by Intershop 7.
The following settings in the orm.properties file control Intershop 7's database

connection:
# Alternative 1: JDBC DriverManager

#intershop.jdbc.driver=[your driver class]

#intershop.jdbc.url=[your jdbc url]
# Alternative 2: DataSource Lookup via JNDI

#intershop.jdbc.dataSourceFactory=\
#com.intershop.beehive.orm.capi.jdbc.JNDIDataSourceFactory
#intershop.jdbc.jndiLookupName=beehive:comp/env/jdbc/core/defaultDB
#intershop.jndi.contextFactory=
#intershop.jndi.providerURL=
#
# Alternative 3: DataSource via JDBC Driver
intershop.jdbc.dataSourceFactory=\
com.intershop.beehive.core.capi.jdbc.oracle.OracleUcpDataSourceFactory
intershop.jdbc.dataSourceName=defaultDB
#
# intershop.jdbc.url
#
# 3.1. Single standalone database instance
#
# 3.1.1 SID thin-style based, default.
#
intershop.jdbc.url=jdbc:oracle:thin:@<@IS.AS.DBCONNECTION.HOSTNAME@>:\
<@IS.AS.DBCONNECTION.PORT@>:<@IS.AS.DBCONNECTION.SID@>
#
# 3.1.2 SERVICE_NAME thin-style based are supported only by the JDBC
# thin driver. The syntax is: @//hostname:port/service_name
#
#intershop.jdbc.url=jdbc:oracle:thin:@//<@IS.AS.DBCONNECTION.HOSTNAME@>:\
#<@IS.AS.DBCONNECTION.PORT@>/service_name
#
# 3.2. Real Application Cluster (RAC)
#
# 3.2.1 RAC with Single Client Access Name (SCAN)
#
# Note: The URL jdbc:oracle:thin:@//cluster_alias:port/service_name does
# not work within Oracle 11.2.0.1.0 and throws NullPointerExceptions at
# oracle.ucp.jdbc.oracle.OracleDatabaseInstanceInfoList.markUpInstanceForUpEvent
#
# The only valid URL for RAC systems with SCAN and Oracle 11.2.0.1.0
# intershop.jdbc.url=jdbc:oracle:thin:@
# (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=cluster_alias)(PORT=port))
# (CONNECT_DATA=(SERVICE_NAME=service_name)))
#
# Oracle 11.2.0.2.0 valid URLs
# intershop.jdbc.url=jdbc:oracle:thin:@//cluster_alias:port/service_name
# intershop.jdbc.url=jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
# (HOST=cluster_alias)(PORT=port))(CONNECT_DATA=(SERVICE_NAME=service_name)))
#
# 3.2.2 RAC with all addresses
#
#intershop.jdbc.url=jdbc:oracle:thin:@(DESCRIPTION=\
#(ADDRESS=(PROTOCOL=TCP)(HOST=rac-node1)(PORT=port))\
#(ADDRESS=(PROTOCOL=TCP)(HOST=rac-node2)(PORT=port))\
#(ADDRESS=........................................))\
#(ADDRESS=(PROTOCOL=TCP)(HOST=rac-nodeN)(PORT=port))\
#(LOAD_BALANCE=YES)\
#(CONNECT_DATA=(SERVICE_NAME=service_name)))
#
########################################
intershop.jdbc.driverType=thin
intershop.jdbc.networkProtocol=tcp
intershop.jdbc.portNumber=<@IS.AS.DBCONNECTION.PORT@>
intershop.jdbc.databaseName=<@IS.AS.DBCONNECTION.SID@>

# common options (used for DataSource via JDBC Driver and Oracle Tools support)
intershop.jdbc.serverName=<@IS.AS.DBCONNECTION.TNSALIAS@>
intershop.jdbc.user=<@IS.AS.DBCONNECTION.USER@>
intershop.jdbc.password=<@IS.AS.DBCONNECTION.PASSWD@>
# Oracle JDBC Driver properties, see Oracle documentation

intershop.jdbc.connectionCacheInitialLimit=5
intershop.jdbc.connectionCacheMinLimit=5
intershop.jdbc.connectionCacheMaxLimit=150
intershop.jdbc.connectionCacheInactivityTimeout=30
# Oracle Real Application Cluster (RAC) - JDBC Fast Connection Failover (FCF)
# configuration via:
# * Remote Oracle Notification Service (ONS) subscription configuration and
# * Client-side daemon "ons.jar" file located within the appserver CLASSPATH.
#
# Download "ons.jar" from:
# * 10gR2: see otn.oracle.com
# * 11gR2: ORACLE_HOME/opmn/lib/ons.jar (database server)
#
# Determine Real Application Cluster (RAC) Oracle Notification Services (ONS) ports
# contacting your DBA. The following Oracle grid infrastructure tool determines the
# remote ONS daemon ports and status on the Oracle RAC nodes:
# * 10gR2: onsctl ping
# * 11gR2: onsctl debug
#
# Syntax:
# intershop.jdbc.rac.fastConnectionFailover=false|true
# - enable or disable JDBC FCF, default false.
# intershop.jdbc.rac.remoteONSConfig=nodes=host:port[,host:port,...]
# - nodes ONS configuration attribute,
# a list of host:port pairs separated by comma (,)
# Examples two-node RAC cluster or RAC cluster via SCAN:

# 1. fastConnectionFailover=true, remoteONSConfig=nodes=
# <rac-node1-vip>:6200,<rac-node2-vip>:6200
# 2. fastConnectionFailover=true, remoteONSConfig=nodes=<scan>:6200
#
intershop.jdbc.rac.fastConnectionFailover=false
intershop.jdbc.rac.remoteONSConfig=nodes=<scan>:6200
# Additional Enfinity settings

intershop.jdbc.tablespaces.index=IS_INDX
intershop.jdbc.tablespaces.contextIndex=IS_INDX_CTX
intershop.jdbc.tablespaces.users=IS_USERS
intershop.jdbc.tablespaces.temp=IS_TEMP
Data Source Settings

The following table lists the required settings for connecting to a data source using
the JDBC DriverManager.
Table 26. Data source lookup using JDBC DriverManager
intershop.jdbc.driver Determines the driver class to use when connecting to
an existing data source via JDBC.
intershop.jdbc.url Specifies the database URL to use when connecting to
an existing data source via JDBC.
The following table lists the required settings for connecting to a data source via
JNDI.

Table 27. Data source lookup via JNDI
intershop.jdbc.dataSourceFactory Specifies the JNDI data source factory class to use.
intershop.jdbc.jndiLookupName Specifies the JNDI context to which this data source is to
be bound.
intershop.jndi.contextFactory Determines the context factory class that reads the initial
context.
intershop.jndi.providerURL Specifies the URL to when connecting to the naming
service for the context factory.
The following table lists the required settings for creating a new data source using
the JDBC Driver, Intershop 7's default option.
Table 28. Creating a data source using JDBC Driver
intershop.jdbc.dataSourceFactory Determines the factory class that creates the JDBC data
source instance for the specified database type.
intershop.jdbc.dataSourceName Specifies the name of the particular database
as specified during the Intershop 7 installation
(<DB.NAME>).
intershop.jdbc.url Specifies the database to be contacted. This setting,
which is specific for Oracle data sources only, combines
some of the database connection parameters
mentioned below, such as driver type and database
server, into one single URL-like string for convenience.
NOTE: Settings made here overwrite those in the single
properties.
intershop.jdbc.driverType Specifies the type of the database driver. The Intershop 7
standard is thin.
intershop.jdbc.networkProtocol Specifies the network protocol used to communicate
with the database server. The default is tcp.
intershop.jdbc.portNumber Specifies the port number where the database server
listens for requests (<DB.LISTENER.PORT>).
intershop.jdbc.databaseName Specifies the name of the particular database
as specified during the Intershop 7 installation
(<DB.NAME>).
UCP Settings
The following table lists the common settings for the Universal Connection Pool
(UCP). In the orm.properties file it is neccesary that the following properties and
values are set. It is recommended that you use the settings for this feature as it
offers better performance. For more information about the properties and values,
please see Oracle UCP documentation.
Table 29. UCP Settings
intershop.jdbc.ucp. Pool data source class=
ConnectionFactory oracle.jdbc.pool.OracleDataSource
ClassName
intershop.jdbc.ucp. Name of the Connection Pool= orm
ConnectionPoolName

intershop.jdbc.ucp. A description Oracle UCP connection pool-enabled data source.
Description
intershop.jdbc.ucp. The role name for the data source
RoleName
intershop.jdbc.ucp. Name of the data source=
DataSourceName ${intershop.jdbc.dataSourceName}
intershop.jdbc.ucp. Name of the database= ${intershop.jdbc.databaseName}
DatabaseName
intershop.jdbc.ucp. Name of the database server=
ServerName ${intershop.jdbc.serverName}
intershop.jdbc.ucp. The network protocol=
NetworkProtocol ${intershop.jdbc.networkProtocol}
intershop.jdbc.ucp. The port number used by the database=
PortNumber ${intershop.jdbc.portNumber}
Table 30. Data source settings to obtain pooled connections to the database
intershop.jdbc.ucp.URL The URL used to access the database=
${intershop.jdbc.url}
intershop.jdbc.ucp.User The username used to access the URL=
${intershop.jdbc.user}
intershop.jdbc.ucp. The password used to access the URL=
Password ${intershop.jdbc.password}
Table 31. Database Connection Attribute Settings
intershop.jdbc.ucp. The initial number of cached connections allowed=
InitialPoolSize ${intershop.jdbc.connectionCacheInitialLimit}
intershop.jdbc.ucp. The minimum number of cached connections allowed=
MinPoolSize ${intershop.jdbc.connectionCacheMinLimit}
intershop.jdbc.ucp. The maximum number of cached connections allowed=
MaxPoolSize ${intershop.jdbc.connectionCacheMaxLimit}
intershop.jdbc.ucp. Timeout for stale connections=
InactiveConnection ${intershop.jdbc.connectionCacheInactivityTimeout}
Timeout
intershop.jdbc.ucp. Each connection is checked every time it is acquired. This is
ValidateConnection commented out by default, but may be useful by some systems.
OnBorrow See Note below.
intershop.jdbc.ucp. Default value is 10
MaxStatements
NOTE: The property ValidateConnectionOnBorrow administers the process of getting a connection

from the pool (synchronized internally in the UCP, i.e. parallel requests are serialized). The
connection validation increases latency in regards to database requests. As a result you should
carefully consider connections validation and run a performance test before enabling this feature
on production systems.
You can view the UCP-enabled data sources information (configuration, general
and Fast Connection Failover (FCF) statistics) in Monitor the System State.

Additionally you can perform background monitoring from the SMC, by selecting
Monitoring > Background > Configurations. Here you can see JDBC connection
data, such as available, active and total connections.
Fast Connection Failover Settings

Intershop 7 can make use of Oracle's Fast Connection Failover (FCF) feature
when working with Real Application Cluster (RAC) environments. Generally, Fast
Connection Failover manages pooled connections for high availability and provides
the following features:
• rapid detection and cleanup of invalid cached connections,
• load balancing of available connections,
• run-time work request distribution to all active Oracle RAC instances.
The following settings in orm.properties control Intershop 7's FCF usage:

Table 32. Fast Connection Failover (FCF) Settings
intershop.jdbc.rac. Enables (true) or disables (false) the JDBC FCF feature for
fastConnectionFailover Intershop 7.
intershop.jdbc.rac. Lists the Oracle Notification Services (ONS) hosts and ports, or, if
remoteONSConfig applicable, the Single Client Access Name (SCAN) and port.
intershop.jdbc.ucp. Maps to
FastConnection ${intershop.jdbc.rac.fastConnectionFailover}.
FailoverEnabled
intershop.jdbc.ucp. Maps to ${intershop.jdbc.rac.remoteONSConfig}
ONSConfiguration
The Oracle grid infrastructure tools onsctl and srvctl determine the remote ONS
daemon ports, SCAN host or hosts and the status on the Oracle RAC nodes. The
following commands, which are to be triggered on the database host, produce the
necessary information:
onsctl debug
srvctl config scan
CAUTION: Make sure to contact your DBA to help determine the appropriate RAC, ONS and SCAN
information of your database environment if you intend to setup Intershop 7 for FCF.
DB Connection User/Password Settings

The following settings in orm.properties control the database user and password
settings.
Table 33. DB user and password settings
intershop.jdbc.user Specifies the database user account name as
specified during the Intershop 7 installation
(<IS.AS.DBCONNECTION.USER>).
intershop.jdbc.password Specifies the database password as
specified during the Intershop 7 installation
(<IS.AS.DBCONNECTION.PASSWD>).

intershop.jdbc.password.encrypted Specifies whether the database password is encrypted
(true|false). This property is optional, a missing value
means false.
System administrators may want to encrypt the database password, passed and
stored as plain text upon installation. To this end, Intershop 7 provides an ANT
script that generates an encrypted password. To encrypt, for example, the password
"intershop", use the following command (with the Intershop 7 build environment
properly set, e.g., as user isas#):
ant -Dpassword=intershop pwd-encrypt
This returns the following string:

standard@PBEWithMD5AndTripleDES:xmgbyJN/vlg=|1JTy1iId+jzt7s6l0xMQMw==
which is then to be copied as the value for the intershop.jdbc.password key in

orm.properties.
Miscellaneous DB Connection Settings

The following table lists general settings that are commonly used for the data
source lookup, and other database-related Intershop 7 options.
Table 34. Common Intershop 7 datasource settings
intershop.jdbc.serverName Specifies the database server name as specified during
the Intershop 7 installation, usually the Oracle TNS name
(<IS.AS.DBCONNECTION.TNSALIAS>).
intershop.jdbc. Specifies the initial number of connections in the
connectionCacheInitialLimit JDBC shared connection pool, that is, the database
connections of the Intershop 7 application established
via JDBC (default: 5).
intershop.jdbc. Specifies the minimum number of connections in the
connectionCacheMinLimit JDBC shared connection pool, default: 5.
intershop.jdbc. Specifies the maximum number of connections in the
connectionCacheMaxLimit JDBC shared connection pool, default: 150.
intershop.jdbc. Specifies the maximum period (in minutes) a connection
connectionCacheInactivityTimeout can be unused (default: 30). When the period expires,
the connection is closed and its resources are freed.
intershop.jdbc.tablespaces.index Used by the dbinit process. This property specifies the
tablespace name for indexes. The value IS_INDX is used
by the Intershop 7 database initialization. If you connect
your Intershop 7 to a different database instance, change
this property according to your tablespace name.
intershop.jdbc.tablespaces. Used by the dbinit process. This property specifies
contextIndex the tablespace name for context indexes. The value
IS_INDX_CTX is used by the Intershop 7 database
initialization. If you connect your Intershop 7 to a
different database instance, change this property
according to your tablespace name.
intershop.jdbc.tablespaces.users Specifies the tablespace name for users, by default:
IS_USERS.

intershop.jdbc.tablespaces.temp Specifies the tablespace name for temporary data, by
default: IS_TEMP.
NOTE: Using the syntax intershop.jdbc.connectionCache*, you can specify additional database
connection settings by appending the Oracle property name. Refer to the Oracle documentation
for further information.
The next table lists general database connection settings that are controlled by the
Intershop 7 core cartridge.
Table 35. core database connection properties
intershop.cartridges.core.jdbc. Specifies the number of possible shared read
numberOfSharedReadConnections connections that are kept beyond the request. This
connection pool receives read-only SQL statements
that are used, for example, by the Intershop 7 search
framework. The default value is 5.
intershop.cartridges.core.jdbc. Specifies the maximum number of cached database
maxCachedCursors cursors, distributed over the shared read connections.
The default value is 25.
Basic Cache Settings

The properties in the section # Cache Options in appserver.properties define the
initial default behavior of the cache service:
intershop.cache.RefreshOnDBInit=true
intershop.cache.flushSessionDictionaries=false
n intershop.cache.RefreshOnDBInit
Normally, the dbinit import refreshes the PO cache after every import step to
update any object dependencies. As there are no import dependencies in a
dbinit, you can switch it off by setting this property to false. This accelerates the
dbinit considerably.
n intershop.cache.flushSessionDictionaries
Specifies whether to delete all session-specific key-value pairs when a cache
refresh event is triggered. By default, this option is switched off (false).
PO Cache Synchronization Settings

To synchronize the cache of the applications, Intershop 7 uses event messaging
(see Event Settings). The preset default parameter values work for most
configurations, but there are a few properties you can set manually if required.
The multicast properties (default) listed below are available in the section # Cache
Synchronization Settings in orm.properties.
NOTE: messengerClass, multicastAddress and multicastPort are the only required

parameters.
#intershop.cacheSync.messengerClass=
#intershop.cacheSync.multicastAddress=239.1.0.0
#intershop.cacheSync.multicastPort=1111
#intershop.cacheSync.multicastInterface=
#intershop.cacheSync.multicastTimeToLive=

#intershop.cacheSync.multicastReceiveBufferSize=1048576
#intershop.cacheSync.multicastListenerThreads=5
#intershop.cacheSync.multicastPacketSize=65000
Change the settings as needed and remove the comment character # to enable
them.
n intershop.cacheSync.messengerClass
This required setting specifies the messenger class to be used, the default is
com.intershop.beehive.messaging.internal.multicast.MulticastMessenger.
n intershop.cacheSync.multicastAddress
This parameter defines the IP address of the multicast group. The parameter
is set to 239.1.0.0 by default. This parameter must be set identically on all
machines that are members of the same multicast group, that is, on all machines
hosting application servers in the same Intershop 7 cluster.
NOTE: Make sure that in your cluster, intershop.cacheSync.multicastAddress is
different from intershop.event.multicastAddress.
n intershop.cacheSync.multicastPort
Use this parameter to specify the multicast port number. The default value is
1111. This parameter must be set identically on all machines that are members
of the same multicast group, that is, on all machines hosting application servers
in the same Intershop 7 cluster.
NOTE: Make sure that in your cluster, intershop.cachSync.port is different from
intershop.event.multicastPort.
n intershop.cacheSync.multicastInterface
If more than one network adapter is available, you can specify the adapter to
be used for multicast communication. If this parameter is not set, your system's
default adapter is used.
n intershop.cacheSync.multicastTimeToLive
This parameter specifies the time-to-live of the multicast packet to control the
scope of the multicasts. The default time-to-live value is 1. Increasing the time-
to-live value is necessary if the application servers of a cluster belong to different
subnets that are connected by routers. Note that in this case, the routers must
also be configured to pass the IP multicast traffic between the connected
application server subnets.
n intershop.cacheSync.multicastReceiveBufferSize
This setting defines the receive buffer size for cache synchronization events. The
default value is 1 MB. Consider increasing this value if custom code performs
mass data operations through the ORM layer or the number of application
servers in the cluster exceeds 10.
n intershop.cacheSync.multicastListenerThreads
This parameter defines the number of handler threads for cache synchronization
events. The default value is 5. Consider increasing this value if custom code
performs mass data operations through the ORM layer or the number of
application servers in the cluster exceeds 10.
n intershop.cacheSync.multicastPacketSize
This parameter sets the maximum size of a multicast packet.

NOTE: If you intend to use other messaging systems than the default multicast, you must enable
and adjust the corresponding intershop.cacheSync properties (see Event Settings).
Search Engine Settings

To provide powerful storefront search options, like full-text search or dynamic
navigation, Intershop 7 integrates third-party search engines via dedicated adapter
cartridges. Intershop ships Apache Solr as the standard search option.
NOTE: The settings discussed in this section do not refer to SEO-specific properties. For SEO
settings, refer to Web Search Engine Optimization.
Multi-Threaded Search Index Creation

With an integrated external search engine, Intershop 7 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.
n intershop.search.indexcreation.network.corePoolSize
Defines the number of threads that are kept in the pool, even if they are idle. The
default value is 30.
n intershop.search.indexcreation.network.maximumPoolSize
Defines the maximum number of threads allowed in the pool. The default value
is 35.
n intershop.search.indexcreation.network.keepAliveTime
Defines the time (in seconds) that threads that exceed the core pool size may
remain idle before being terminated. The default value is 1.
n intershop.search.indexcreation.source.queueLength
Defines the length of the queue that feeds the retriever, that is, the queue to
which the source worker writes. The default value is 1000.
n intershop.search.indexcreation.retriever.workerCount
Defines 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.
n intershop.search.indexcreation.retriever.queueLength
Defines the length of the queue that feeds the unpacker, that is, the queue to
which the retriever writes. The default value is 1000.
n intershop.search.indexcreation.unpack.queuelength
Defines the length of the queue that feeds the index writer, that is, the queue to
which the unpacker writes. The default value is 1000.

TIP: 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.
Oracle Text Search Options

In case no external search engine is integrated, Intershop 7 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.
n oracle.context.enclosingChars.remove
If set true (default), multiple enclosing characters are removed to prevent
"DRG-50937: query too complex" errors (with enabled or forced substring search
only.)
n oracle.context.enclosingChars
Contains a list of the removable enclosing characters.
Query File Options

Intershop 7 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:
n intershop.queries.CheckSource
Enables 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.
n intershop.queries.Preload
Specifies whether the query files of all cartridges and sites are preloaded on
server startup; the default value is true.
Cache Engine
The Cache Engine provides a mechanism to manage and perform cache operations
(clear, enable/disable, configure, etc.) for all Intershop 7 caches on all application
servers within the installation. The Cache Engine is implemented within the
cartridge Cache. The Intershop 7 administrator can monitor the cache efficiency and
size, refresh the information, and change certain values for some caches.
Cache management via the Cache Engine is made possible by means of Java
MBeans. MBeans are manageable resources in Java, and in Intershop 7 MBeans are
managed with JMX tools (see Java Visual VM and JConsole). It should be noted that
the cache engine handles a number of operations and thus, there is no UI specific to
the Cache Engine in Intershop 7 SMC or back office.
There are four cache groups that are managed via the cache engine:
• ORMCache (persistent objects)
• ObjectCache (Least Recently Used or LRU)

• PageCache
• SearchIndexReloadable
Cache Engine Messaging Settings

If there are several Intershop 7 clusters in one subnet, a cluster may receive events
from a foreign cluster if both clusters happen to be using the same multicast IP and
port. In this case, you have to specify a unique multicast IP and port for each cluster
in the cache.properties files, located in <IS.INSTANCE.SHARE>/system/config/cluster/.
The corresponding default settings (prefixed intershop.cacheengine.wrapped) are
listed below.
and adjust the corresponding intershop.cacheengine properties (see Event Settings).
intershop.cacheengine.wrapped.messengerClass=
intershop.cacheengine.wrapped.multicastAddress=239.1.2.3
intershop.cacheengine.wrapped.multicastPort=1234
#intershop.cacheengine.wrapped.multicastInterface=
#intershop.cacheengine.wrapped.multicastTimeToLive=
#intershop.cacheengine.wrapped.multicastReceiveBufferSize=1048576
intershop.cacheengine.wrapped.multicastListenerThreads=5
intershop.cacheengine.wrapped.multicastPacketSize=65000
Monitoring Cache Activity

To monitor cache activity, select the MBean tab in the JVisual VM (or JConsole).
Expand the com.intershop.enfinity tree structure. The resources (sets of MBeans) we
are concerned with are CacheClearProcessor, CacheInformation and ClearableCaches.
A description of each resource is listed in the table below:
Table 36. Cache Management
Cache Resource Description

com.intershop.enfinity
CacheClearProcessor This resource empties the objects within the
ClearableCaches resource.
BatchCacheClear Caches included here are cleared as a batch immediately
or at a late time. For example, after a product upload has
occurred.
InstantCache Clears all Java VM caches included here based on
Clear conditions specified in the Intershop 7 installation.
ORMCacheSync Clears local caches included here on the Java VM
CacheClear immediately based on conditions specified in the
Intershop 7 installation.
CacheInformation This resource displays cache attribute values (i.e. actual
size, HitCount, Ratio, usw.). You can reset the monitor
under the operations tab.
ORMCache Displays data for Intershop 7 classes, connections and
transactions monitoring.
PageCache Displays data for all sites within an Intershop 7 instance.
SearchIndex Displays data for content search within a given context
Reloadable (i.e. 'DE Specials' or 'US Specials').

Cache Resource Description

ClearableCaches This resource allows you to configure cache attributes
(size, capacity, usw.), clear and enable/disable a cache.
ORMCaches ORM caches can be cleared here.
ObjectCaches Object caches can be cleared here.
PageCaches Page caches can be cleared here.
SearchIndexes Search index caches can be cleared here.
Since the administrator must from time to time clear one or more caches, it is
important that they are cleared in the following order:
1. ORM
2. ObjectCache
3. SearchIndex
4. PageCache
When clearing the PageCache, it is neccesary that the site has 'page caching'
selected as well as 'keyword processing' and 'text indexing' selected. You can view/
change the attributes for each site by entering the SMC > Site Management >
<your-site-name>-Site - Page Cache.
CPU Affinity Settings

If Intershop 7 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.
NOTE: 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.SHARE>/system/
config/servers/<HOST.ID>/<INSTANCE.ID>. 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 7 continues
running uninterrupted.
NOTE: Binding a server process of the Intershop 7 application to a specific logical CPU moves this
application server 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 7 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 7, you have to bind Intershop 7 to a single logical
CPU on a multi-core/multi-processor machine.
NOTE: Do not hesitate to contact Intershop if you have questions regarding the number of (logical)
CPUs supported by your Intershop 7 license.
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:
n intershop.cacheSync.multicastInterface
Specifies the IP interface to be used for ORM cache synchronization. Use the
following property:
intershop.cacheSync.multicastInterface=192.168.2.1
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.SHARE>/system/config/servers/<HOST.ID>/<INSTANCE.ID>/. This
overloads any cluster-wide setting in the orm.properties.
n intershop.event.multicastInterface
Specifies the IP interface to be used for event multicast. Edit the property in the
corresponding local appserver#.properties file in <IS.INSTANCE.SHARE>/system/
config/servers/<HOST.ID>/<INSTANCE.ID>/.
intershop.event.multicastInterface=192.168.3.1
n intershop.servletEngine.connector.address
Specifies the IP interface to be used for Web Adapter traffic. Edit the property
in the corresponding local appserver#.properties file in <IS.INSTANCE.SHARE>/
system/config/servers/<HOST.ID>/<INSTANCE.ID>/.
intershop.servletEngine.connector.address=192.168.3.1
User Login and Password Rules

In Intershop 7, 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 application server 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.

NOTE: 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 7 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.
NOTE: For sales channel storefronts, only PasswordExpressionValidator is used as password

validator by default.
By default, Intershop 7 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:
n <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.

n <domain>.PasswordValidators
Specifies possible validators that will be used to validate the password,
using provider names delimited by comma. Intershop 7 includes two
providers, PasswordExpressionValidator and PasswordHistoryValidator.
Note that custom providers must implement the interface
com.intershop.beehive.core.capi.user.PasswordValidator.
n <domain>.PasswordExpirationNotificationPeriod
Specifies 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 upon login.

n <domain>.PasswordExpirationPeriod
Specifies 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.
n <domain>.LoginFailureLockoutCount
Specifies the maximum number of login attempts a back-office user can make
using a wrong password. After this number is reached, the user account is
locked for the period defined in <domain>.LoginFailureLockoutDuration.
NOTE: A locked user account can be unlocked manually via the User Manager in the Intershop 7
back office.
n <domain>.LoginFailureLockoutDuration
Specifies the time (in minutes) a user account is locked after the number of
failed login attempts (<domain>.LoginFailureLockoutCount) has been reached.
n <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.
n <domain>.UserLoginDescription[_Locale]
Specifies a (locale-specific) description of the defined login name rules, which is
displayed to the user.
n <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.
n <domain>.UserPasswordDescription[_Locale]
Specifies a (locale-specific) description of the defined password rules, which is
displayed to the user.
n <domain>.PasswordRepeatPreventionCount
Specifies 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.
n <domain>.PasswordRepeatPreventionDescription[_Locale]
Specifies a (locale-specific) warning, which is displayed to the user stating the
number of previous passwords not to be reused.

Object Locking Settings

Intershop 7 provides a correlated locking mechanism for objects that can be locked
in the Intershop 7 back office. This mechanism allows to prevent conflicts between
back office editing, 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 global appserver.properties file control specific aspects
of the locking mechanism:
n intershop.locking.correlatedLockingEnabled
Specifies 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, the Intershop 7 back office does not display the corresponding
warnings and the lock conflict resolution options.
n import.locking.acquisition.timeout
Specifies the acquisition timeout (in seconds) for import processes started via
the Intershop 7 back office. 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 the Intershop 7 back office (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:
n staging.objects.locking.acquisition.timeout
Specifies the acquisition timeout (in seconds) for publish-to-live processes
started via the Intershop 7 back office. The default value is 60. Note that this
property is evaluated only if intershop.locking.correlatedLockingEnabled=
true.
n staging.objects.locking.acquisition.namedResourceThreshold
Specifies 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.
Startup Retry Settings

In case of exceptions upon server 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:
Table 37. Startup retry options

intershop.startup. Boolean Enables the startup retry in case of exceptions. The
retryOnError default value is false.
intershop.startup. Integer Limits the number of retries (1...maxint). If the value is
retryCount 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. Integer Defines the waiting time (in seconds) between
retryInterval subsequent server startup attempts.
Graceful Application Server Shutdown

Intershop 7 provides a graceful application server 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.
Data Encryption/Decryption Options

In order to ensure PCI DSS compliance, Intershop 7 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.
Table 38. Data encryption/decryption properties
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. Specifies the name of the provider class that manages
provider the encryption key.

intershop.encryption.keystore. Specifies the name of the Java keystore file. Its base
filename directory is <IS.INSTANCE.SHARE>/sytem/config/cluster,
and the default value is intershop.keystore.
intershop.encryption.keystore. Specifies the variable part of the current keystore
password password, intended to be modified by Intershop 7
administrators. Can contain up to 90 alphanumeric
characters.
intershop.encryption.keystore. Specifies the variable part of the new keystore password
password.change in case it is modified.
intershop.encryption.keystore. Controls whether Intershop 7 does create (true) or does
create not create (false) a new keystore file on server start if
there is none available.
intershop.encryption.random. Specifies the name of the file that contains the random
filename part of the keystore password. Its base directory is
<IS.INSTANCE.SHARE>/sytem/config/cluster, and the
default value is random.
intershop.encryption.random. Specifies the name of the new file that contains the
filename.change random part of the keystore password in case it is
modified.
intershop.encryption.random. Controls whether Intershop 7 does create (true) or does
create not create (false) a new random part file on server start
if there is none available.
Web Search Engine Optimization

Intershop 7 storefront pages are optimized for internet search engines by
means of specific title and meta tags. Generally, SEO is managed through the
Intershop 7 back office. For detailed information about SEO attribute handling in
the Intershop 7 back office, please consult the Intershop 7 guide Managing Online
Shops.
NOTE: The settings discussed in this section do not refer to the integrated search engine. For the
Intershop 7 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
• for individual applications
<IS.INSTANCE.SHARE>/sites/<site>/<version>/applications/<application>/seo
• for individual sites
<IS.INSTANCE.SHARE>/sites/<site>/<version>/units/<site>/seo
• for the cluster
<IS.INSTANCE.SHARE>/system/config/cluster/seo
The lookup (or fallback) path is

1.) application-specific properties
2.) site-specific properties

3.) cluster-specific properties

NOTE: It is possible to pre-define language-specific meta texts using language-specific meta text
properties MetaTexts_<language>.properties.
By default, Intershop 7 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
Mail Server Settings

Intershop 7 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 7-specific properties:
Table 39. Simple mail server settings

intershop.SMTPServer String Specifies the SMTP (outgoing) mail server,
which is used for the notification mechanism.
intershop.mail.messageID. Boolean Specifies whether or not (true|false)
setByAppserver to include the Message-ID header from
outgoing mails.
intershop.mail. String Specifies the domain used in the Message-ID
messageID.domain 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.
Table 40. Secure mail server settings

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.
Multi-Threaded Export Settings

The export framework of Intershop 7 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.
TIP: On a project-specific base, you can apply the multi-threaded export capabilities to other areas
as well. This involves, however, development effort.
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:

Table 41. Multi-threaded export settings

Export1.MultiThreading. Boolean Enables or disables (true|false) the multi-
Enabled threaded export.
Export1.MultiThreading. Integer Limits the maximum number of threads
MaxThreadCount when multi-threading export is enabled.
The recommended default value is
<number_of_CPUs>*2.
Export1.MultiThreading. Integer Specifies the number of export objects that are
BatchSize provided to a single export thread when multi-
threaded export is enabled (default 15).
Export1.MultiThreading. String Specifies the name of the template to be used
HeaderTemplateName to create the export header.
Export1.MultiThreading. String Specifies the name of the template to be used
FooterTemplateName to create the export footer.
Export1.MultiThreading. Boolean Specifies whether or not (true|false) to
CopyPipelineDictionary 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. String Specifies the name of the iterator that holds
ExportIteratorName the export data in multi-threaded mode.

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

intershop.user. Boolean Enables case sensitivity for login names. If set
AllowMixedCaseLogin false, login names are always converted into
lower case. Do not change this setting in a
productive system.
intershop.server. String In an Intershop 7 deployment with multiple
assignedToServerGroup 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 back-office requests.
(Server group names for storefront use can be
added as desired.)
intershop.servletEngine. Integer If the Saferpay payment method is used, the
connector.maxHttpHeaderSize server that hosts the Intershop 7 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. Integer Defines at which file size (in bytes) the Web
maxBufferedFileSize 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. Boolean With selective page cache deletion, specifies
registerCachedFiles 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. Boolean Specifies whether to monitor the
CheckSource urlrewrite.properties files for modifications and
triggers a refresh if needed.
intershop.urlrewrite. Integer Specifies the time interval in seconds after
CheckSourceInterval which the urlrewrite.properties files are to be
checked for modifications if CheckSource
is true. (The value 0 – always – is not
recommended).
intershop.webservice. String Specifies the site statuses (see General Site
soap.allowedSiteStatuses Preferences) 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.

Chapter 2: Intershop 7 Administration Locales, Tax Data, Currencies
Sensitive Properties Settings

Intershop 7 can exclude sensitive properties from being displayed in the
administrative UI clients, like, for example, the monitoring module of the
SMC (see Monitor the System State). 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.
NOTE: The actual location of the properties listed in intershop.cartridges.monitor.
sensitiveProperties is irrelevant, that is, they may reside in any of Intershop 7'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
Prepare Locales, Tax Data, Currencies and Exchange

Rates
In Intershop 7, locales, tax data, currencies and exchange rates are configured
centrally by the system administrator, using a set of *.properties files. The
system checks these configurations on application server startup. In case new
configurations are detected, or changes to existing ones, the system automatically
triggers the necessary updates, inserts, or deletions in the database.
Configure Server Start Pipeline

The update mechanism for locales, tax data, currencies and exchange rates is based
on a set of pipelines which are executed on server startup. The initial pipeline to
start the update mechanism is configured in the <IS.INSTANCE.SHARE>/system/
config/cluster/appserver.properties, using the following entry:
intershop.pipelines.ExecuteUponServerStart =
DefaultServerStartPipeline-Start
NOTE: In a standard installation, the pipeline is already configured.
Prepare Locales
Locale Configuration Files

To add one or more locales and/or to set a new lead locale, you must create
• the file localization.properties that lists the new locales
• for every new locale, a formats configuration file
<ISOLanguageCode>_<ISOCountryCode>.properties (such as en_US.properties.)

Locales, Tax Data, Currencies Chapter 2: Intershop 7 Administration
The files are stored in <IS.INSTANCE.SHARE>/system/config/cluster/.

Check the example files in <IS.INSTANCE.SHARE>/system/config/cluster/, including
localization.properties.example, de_DE.properties.example, en_GB.properties.example
and en_US.properties.example.
NOTE: For the changes to become effective, the server must be restarted.
Add Locales
The configuration file localization.properties lists the locales to be added to the
system in the following syntax
key = <ISOLanguageCode> <ISOCountryCode> <ISOCurrencyCode>
<usedAsLeadLocale>
for example,
japanese = ja JP JPY false
Set Lead Locale

To set a new lead locale, use the last argument usedAsLeadLocale of the locale key,
as defined in localization.properties, setting it true. Following the example above,
use the following key to set Japanese as the new lead locale:
japanese = ja JP JPY true
Delete Locale
To delete existing locales, use the key deleteLocales in localization.properties. Each
locale to be deleted must be identified by its ISOLanguageCode and ISOCountryCode
joined by an underscore. To delete Japanese and German, for exapmple, use
deleteLocales = ja_JP de_DE
Set Locale-Specific Patterns

The configuration files <ISOLanguageCode>_<ISOCountryCode>.properties list
format patterns for numbers, date, etc. to be used in the corresponding locale.
decimalNegativePattern = - #,##0.00
decimalPositivePattern = #,##0.00
decimalGroupingCharacter = ,
decimalDecimalSeparator = .
shortCurrencyNegativePattern = - #,##0.00
shortCurrencyPositivePattern = #,##0.00
longCurrencyNegativePattern = * - #,##0.00
longCurrencyPositivePattern = * #,##0.00
currencyGroupingCharacter = ,
currencyDecimalSeparator = .
longDatePattern = dd-MMM-yyyy
shortDatePattern = MM/dd/yy
timePattern = hh:mm:ss a
dateTimeAMString = am
dateTimePMString = pm
integerNegativePattern = -#,##0
integerPositivePattern = #,##0
integerGroupingCharacter = ,
integerDecimalCharacter = .

shortQuantityNegativePattern = - #,##0.###
shortQuantityPositivePattern = #,##0.###
longQuantityNegativePattern = - #,##0.### *
longQuantityPositivePattern = #,##0.### *
quantityGroupingCharacter = ,
quantityDecimalCharacter = .
inputDecimalNegativePattern = -#,##0.00
inputDecimalPositivePattern = #,##0.00
inputCurrencyNegativePattern = -#,##0.00
inputCurrencyPositivePattern = #,##0.00
inputDatePattern = dd.MM.yyyy
inputTimePattern = HH:mm
inputDateTimePattern = dd.MM.yyyy HH:mm
inputIntegerNegativePattern = -#,##0
inputIntegerPositivePattern = #,##0
inputQuantityNegativePattern = -#,##0.###
inputQuantityPositivePattern = #,##0.###
inputDatePatternUserHint = TT.MM.JJJJ
inputTimePatternUserHint = SS:MM
priceImpexDateTimePattern = dd.MM.yyyy HH:mm:ss
Adjust the patterns according to the locale to be added and save the file as, for
example, ja_JP.properties in <IS.INSTANCE.SHARE>/system/config/cluster/.
NOTE: The syntax of the patterns is identical to that documented in the JDK API specification for
the classes DecimalFormat and SimpleDateFormat.
Locale Update Process

Upon adding a new locale, the system creates the "last modified" marker file
<IS.INSTANCE.SHARE>/system/config/cluster/localization.lastupdate. This file
records the "last modified" time and a backup of the actual configuration file
for comparison at the next server start. If localization.properties is changed, the
database will be updated again; if, however, the comparison does not indicate any
changes, no action will be taken.
Prepare Tax Data Sets

Tax data sets can be configured for one or more channels or organizations, and
define tax jurisdictions, tax jurisdiction mappings to countries and states, tax
classes, a tax rate matrix and tax data set sharing relationships.
NOTE: Any existing items belonging to the configured channel or organization which do not
appear in the tax data set are deleted from the database.
Tax Data Configuration Files

To update tax data in the database at server start, you must create the file
taxdataset.properties in <IS.INSTANCE.SHARE>/system/config/cluster/.
NOTE: Check the example file taxdataset.properties.example contained in <IS.INSTANCE.SHARE>/
system/config/cluster/.
This file comprises five sections: channel/organization specification, tax jurisdictions

and country/state mappings, tax classes, tax rates, and tax sharing relationships.

The syntax is described below.

n Channel/Organization Specification
Table 43. Tax data channel/organization specification
Key Description
Default.channel Used to specify either the default channel or the
default organization to which the tax data belong
Default.organization
(optional). If not specified, each jurisdiction and tax
class must be specifically assigned to a channel or
organization.
n Tax Jurisdiction and Country/State Mappings

<jid> is an identifier to group the attributes for one tax jurisdiction.
Table 44. Tax jurisdiction mappings
Key Description
Jurisdiction.<jid>.name Specifies the name for the tax jurisdiction.
Jurisdiction.<jid>.channel Specifies either the channel to which the
tax jurisdiction belongs if different from
Jurisdiction.<jid>. organization
Default.channel or the organization to which
the tax jurisdiction belongs if different from
Default.organization (optional).
Jurisdiction.<jid>.default Specifies whether this is the default jurisdiction, false
if not specified (optional).
Jurisdiction.<jid>.mapping. Specifies a jurisdiction-country assignment. Make sure
<n>.country to specify all relevant names, identifiers etc. that may
occur in your system for each country, like Germany
and DE for Germany.
Jurisdiction.<jid>.mapping. Specifies a jurisdiction-state assignment (optional).
<n>.state
n Tax Classes
NOTE: <cid> serves as tax class ID. It is also used as an identifier to group the attributes for
a tax class.
Table 45. Tax class properties
Key Description
Class.<cid>.code Specifies the tax class code.
Class.<cid>.name Specifies the name of the tax class.
Class.<cid>.channel Specifies either the channel to which the tax class
belongs if different from Default.channel or the
Class.<cid>.organization
organization to which the tax class belongs if different
from Default.organization (optional).
Class.<cid>.description Specifies a short description of the tax class.
Class.<cid>.default Specifies whether this is the default tax class, false if
not specified (optional).

n Tax Rates
Table 46. Tax rate properties
Key Description
Rate.<jid>.<cid>.value Specifies the tax rate in the format xx.yyy, e.g., for
7.5%, set 0.075.
Rate.<jid>.<cid>.validfrom Specifies a valid-from date in the dd.mm.yyyy,
e.g., 16.01.2004. Optional when .previous rate
becomes invalid and .value becomes valid.
Rate.<jid>.<cid>.previous Specifies an optional tax rate valid previous to
.validfrom (format xx.yyy).
n Tax Data Sharing

Each relationship needs to define
n the channel or organization from which the data is shared, and
n the channel or organization to which the data is being shared.
To share the same tax data set with more than one channel(s) / organization(s)
requires the definition of multiple relationships. Note that an identifier (<id>) is
used to group sharing relationships.
Table 47. Properties for tax data sharing
Key Description
Sharing.<id>.from.channel Used to specify either the channel or the
organization that provides its tax data set to
Sharing.<id>.from.organization
other channels/organizations.
Sharing.<id>.to.channel Used to specify either the channel or the
organization that uses the tax data set
Sharing.<id>.to.organization
provided by other channels/organizations.
Sharing.<id>.relationDefinitionName Used to specify the relation definition name,
either TAX_CLASS or TAX_JURISDICTION
The following lines illustrate the tax data settings using one of Intershop 7's demo
channels as an example.
# ### 1. Domain specification #######
Default.channel=PrimeTech-PrimeTechSpecials
# ### 2. Tax Jurisdictions ##########
Jurisdiction.GERMANY.name=Germany
Jurisdiction.GERMANY.default=true
Jurisdiction.GERMANY.mapping.1.country=Germany
Jurisdiction.GERMANY.mapping.2.country=DE
Jurisdiction.OTHER.name=Outside Germany
# ### 3. Tax Classes ################
Class.NORMAL.name=FullTax
Class.NORMAL.description=Full Tax charged
Class.NORMAL.default=true
Class.REDUCED.name=ReducedTax
Class.REDUCED.description=Reduced Tax charged
Class.ZERO.name=NoTax
Class.ZERO.description=No Tax charged
# ### 4. Tax Rates ##################
Rate.GERMANY.NORMAL.value=0.19
Rate.GERMANY.REDUCED.value=0.07
Rate.GERMANY.ZERO.value=0.0
Rate.OTHER.NORMAL.value=0.0
# ### 5. Sharing tax data sets ######

Sharing.1.from.channel=PrimeTech-PrimeTechSpecials
Sharing.1.to.channel=PrimeTech-ResellerChannel
Tax Data Update Process

Upon setting new tax data for a domain, the system creates the "last modified"
marker file <IS.INSTANCE.SHARE>/system/config/cluster/taxdataset.lastupdate. This
file records the "last modified" time and a backup of the current configuration
file for comparison at the next server start. If taxdataset.properties is changed, the
Prepare Currencies
The currency configuration file lists those currencies that should be enabled in the
server, and, optionally, names a currency to be set as the lead currency.
NOTE: Currencies not listed in the configuration file are disabled in the database. If the current lead
currency is not listed as an active currency and no other currency is named as the lead currency,
then the lead currency is not disabled.
Currency Configuration File

To update currency information in the database at server start, you must create the
file activecurrencies.properties in <IS.INSTANCE.SHARE>/system/config/cluster/.
NOTE: Check the example file activecurrencies.properties.example contained in
<IS.INSTANCE.SHARE>/system/config/cluster/.
This file lists the enabled currencies in the following syntax:

ActiveCurrency.<n>=<ISOCurrencyCode>
To enable a new lead currency, set

LeadCurrency=<ISOCurrencyCode>
A complete currency configuration file could look like this:

# Specifies which currencies should be set active
LeadCurrency=EUR
ActiveCurrency.1=GBP
ActiveCurrency.2=EUR
Applying this file to a standard Intershop 7 installation, the currency EUR would
replace USD as lead currency and USD would be no longer be listed as an active
currency in the system.
Currency Update Process

Upon setting new currencies, the system creates the "last modified" marker file
<IS.INSTANCE.SHARE>/system/config/cluster/activecurrencies.lastupdate. This file
records the "last modified" time and a backup of the actual configuration file for
comparison at the next server start. If activecurrencies.properties is changed, the

Chapter 2: Intershop 7 Administration Data Replication
Prepare Exchange Rates

The exchange rate configuration file lists those exchange rates that should be
enabled in the server. The items listed in the file are inserted into or updated in the
database as appropriate.
NOTE: Exchange rates not listed in the configuration file are deleted from the database.
Exchange Rate Configuration File

To update exchange rates in the database at server start, you must create the file
exchangerates.properties in <IS.INSTANCE.SHARE>/system/config/cluster/.
NOTE: Check the example file exchangerates.properties.example contained in
<IS.INSTANCE.SHARE>/system/config/cluster/.
This file lists the enabled exchange rates in the following syntax:
ExchangeRate.<n>.From=<ISOCurrencyCode>
ExchangeRate.<n>.To =<ISOCurrencyCode>
ExchangeRate.<n>.Rate=a.b
where a.b is the from-to exchange rate with a dot (.) as decimal separator. For
example, the following file
ExchangeRate.1.From=EUR
ExchangeRate.1.To =GBP
ExchangeRate.1.Rate=0.67
would delete all existing exchange rates apart from EUR to GBP and change the
existing EUR-GBP rate to 0.67 (1 EUR is worth 0.67 GBP).
Exchange Rate Update Process

Upon setting new exchange rates, the system creates the "last modified" marker
file <IS.INSTANCE.SHARE>/system/config/cluster/exchangerates.lastupdate. This file
records the "last modified" time and a backup of the actual configuration file for
comparison at the next server start. If exchangerates.properties is changed, the
Data Replication
Intershop 7 features powerful replication mechanisms to transfer data between
separated systems. Generally, two different approaches are available:
n Data Replication
Data replication is a special mechanism used to transfer large amounts of data
between two Intershop 7 clusters, i.e., from a source to a target system via fast
mass-data operations.
n Product Data Feeds
Generally, product data feeds are used to transfer data to external systems other
than Intershop 7. As a special use case, however, it can be used to selectively
transfer small sets of particular product data between two Intershop 7 clusters.
The sections that follow describe the data replication process. A brief introduction
to product data feeds (in comparison to data replication) is provided in Data

Data Replication Chapter 2: Intershop 7 Administration
Replication Versus Product Data Feeds. For a more detailed discussion of concepts
and processes related to product data feeds, see the guide Managing Online Shops.
Understanding the Data Replication Process
What Is Data Replication?

Data replication refers to the process of first updating data in a source system
and then synchronizing the data with the respective target systems that belong
together forming a target cluster. The database replication mechanism makes it
possible to develop and maintain content in the background without disturbances
to the live system. For systems that have high availability requirements, Intershop 7
is capable of a distributed setup over multiple data centers. Therefore, data
replication can be performed for multiple data center installations.
CAUTION: A data replication process cannot delete a channel in the target system. If you intend
to delete a channel, you must delete it manually in the source and target system.
To get an idea of the 'moving' parts of a data replication process, below are the
important concepts that must be clearly understood:
• Cluster
The Intershop 7 system consisting of the synchronized database account,
synchronized Intershop Shared Files, Intershop Application Servers and
Intershop Web Servers
• Sub Cluster
A sub cluster is the local part of an Intershop 7 in each data center (one database
account, one Intershop Shared Files instance).
• Edit System
The source Intershop 7 sub-cluster
• Live System
The target Intershop 7 sub-cluster
• Data Center
A data center is a physical location of one or more Intershop 7 cluster
• Edit Schema
The database schema of the edit system
• Live Schema
The database schema of the live system
• Edit User
The user working with the edit system
• Live User
The user working with the live system
• DNS Switch
Domain Name Service switch
• Data Replication

The standard replication mechanism of Intershop 7

• Oracle Streams
The replication mechanism of Oracle. (see: Oracle Online Documentation)
Basic Architecture
The data replication mechanism relates two systems: a source system and a target
system. The data replication process makes no assumptions about whether a
system is online or offline.
Figure 4. Data Replication Architecture
The target system includes one or more application servers, the Web server, the
Web Adapter and a target database account. The number of application servers,
Web servers and Web Adapters is irrelevant to the data replication mechanism as
long as the requirements are met in order to process incoming requests properly.
The source system also includes one or more application servers, Web server, Web
Adapters and a source database account. Again, the number of application servers,
Web server and Web Adapters is irrelevant to the data replication mechanism.
Typically, the sizing requirements for a source system are lower, as the source
system does not have to process online requests.
A source system can be connected to multiple target clusters. However, each
data replication process is directed at exactly one replication target cluster. It is
not possible to update multiple target clusters from a source system in one data
replication process.
Within environments having more than one data center, a distributed target system
cluster is possible. Though physically there are multiple target systems, from a
data replication point of view they are considered a single target system cluster (or
rather, a target cluster). Therefore, the source system simultaneously updates all
target systems belonging to the same target cluster. However, it is not possible to

update multiple target systems belonging to "different" target clusters in a single

data replication process.
Local and Remote Data Replication

Two basic replication scenarios can be distinguished.
n Local Data Replication
The local data replication scenario assumes a single database instance both for
the source and the target cluster. Source and target clusters use different users/
schemas, with both users/schemas working on separate table sets.
n Remote Data Replication
In a remote data replication scenario, two different database instances are used,
possibly residing on different hosts.
n Multiple Data Centers
Data replication is performed across several target Intershop 7 clusters.
Whereby, the databases of the target clusters are synchronized by Oracle
Streams.
NOTE: Local data replication can have significant performance advantages over remote data
replication.
Data Replication Chains

Note that a system can serve as source and target cluster at the same time. Hence,
it is possible to set up data replication chains in which content is transferred
consecutively across multiple systems.
Figure 5. Simple Replication Chain

As an example, setting up a data replication chain may be required for test or

acceptance systems, where data or design changes are tested or approved before
they go live.
Data Replication Workflow

Data replication involves two main stages: defining data replication tasks and
executing these tasks as data replication processes. Both stages are described in
more detail below:
Role Concept
Two basic user roles for data replication can be distinguished:
n Data Replication Manager
Data replication managers operate within a particular business unit (channel,
enterprise, sales partner). They do not need any technical knowledge of
data replication. They create replication tasks and assign them to the system
administrator for execution. For example, the data replication manager could be
an editor who maintains product and catalog information of a sales channel of
the source system. The editor then creates the task to replicate the data to the
sales channel of the target cluster.
n System Administrator
System administrators act as data replication managers of the system unit
(central e-selling administration). The system administrators supervise the data
replication technically across the whole system. They receive the replication
tasks from the data replication managers of the individual business units and
combine them to data replication processes for execution. Additionally, they
set up and initialize target clusters, trigger the rollback of publication processes,
monitor and control the process progress.
Each business unit (channel, enterprise/sales partner) contains an access

privilege Data Replication Manager, which is connected with the permission
SLD_MANAGE_DATA_REPLICATION. The Data Replication Tasks module becomes
accessible if the user inherits the access privilege Data Replication Manager for the
particular business unit. The system administrators own the same permission, but in
comparison to the context of a business unit, the functionality of the module Data
Replication Tasks is limited to process published tasks using the additional module
Data Replication Processes.
Data Replication Tasks

Data replication tasks determine the content to be replicated. They are defined by
the responsible data replication managers individually for each channel in the sales
organization or partner back offices. For example, the data replication manager for
the channel "PrimeTechSpecials" can define data replication tasks for this particular
channel, using the sales channel management plug-in in the Intershop 7 back
office.

Figure 6. Defining data replication tasks
For each data replication task, the data replication manager must define
n Start Date
The start date sets the earliest time at which a replication task can be executed.
n Replication Groups
To each replication task, one or more data replication groups are assigned. Data
replication groups identify the content to be replicated. Each replication group
refers to a certain content domain. For example, the data replication group
"Organization" includes the organization profile, the departments, the users and
roles, and all preferences defined for an organization.
Data Replication Processes

Once defined, data replication tasks are submitted to the system administrator for
execution. To execute data replication tasks, the system administrator defines data
replication processes in the central administration front end. For more information,
refer to the "Central Administration User Guide".
Figure 7. Defining Data Replication Processes
For each data replication process, the system administrator defines:

n Target Cluster
A source system can be connected to multiple target clusters. However, each
replication process can address a single target cluster only.

NOTE: A target cluster can consist of multiple target systems, all of which belong to the same
ClusterID
n Replication Tasks
Each replication process executes one or more replication tasks as submitted by
the responsible data replication managers. Only replication tasks whose start
date has been reached can be included with a replication process.
n Activation Rules
Data replication processes can be started manually, or as scheduled jobs at
predefined times.
n Data Replication Type
The data replication type determines which data replication phases are
executed for a replication process. See What Happens During Data Replication?.
What Happens During Data Replication?
Data Replication Phases

A complete data replication process consists of the following main phases, as
described in the following figure:
Figure 8. Replication phases
n Phase 1: Identification
The content to be replicated (database tables, file system directories) is selected.
n Phase 2: Preparation
During this phase, the content involved in the current replication process is
prepared. For example, the database tables will be analyzed to guarantee
optimal execution plans for SQL statements used during the replication process.
Moreover, there are built indexes of the staging directories, which are then
moved into the distribution directory <IS.INSTANCE.SHARE>/dist/idx.
n Phase 3: Synchronization
The replication process merges content to be replicated (new content of source
system), with content that should not be changed (old content of target cluster
belonging to other domains). During the synchronization phase, the old content
of the target cluster that should not be changed is replicated to physical shadow
containers (tables or directories).

n Phase 4: Replication
During the replication phase, the new content is copied to the shadow container
of the target cluster. Database content and file system content is handled
separately.
The prepared index files are compared to the existing indexes in the live system.
Thus, the static content changes are determined, and the corresponding files are
transferred.
n Phase 5: Publication
The final step of the data replication process is to publish the replicated content,
for example by performing a switch between live and shadow tables (full
replication of database content) or between active and inactive directories
(replication of file system content). As a result, any new or changed data is
available for online users, and deleted data does not longer appear in the Web
front.
NOTE: The publication does not take place if any of the preceding steps has ended with an
error.
n Phase 6: Cache Refresh

There are several caches in Intershop 7 to ensure high performance. These
caches are refreshed whenever new content has been published.
The process details for the individual phases differ depending on the content type
to be replicated and the staging processor used to execute the replication process.
Full Replication and Delta Replication

For the replication of database content, Intershop 7 uses different replication
mechanisms depending on the type of database content.
Full Replication
In case of full replication, database content is transferred from the source to the
target cluster regardless of changes. Full replication is used for most types of
database content, except tables that are writable in the target cluster (such as user
data on a system used as live system.) The full replication mechanism relies on
synonym tables, linked to a live and a shadow table.
Delta Replication
In case of delta replication, only content which has actually changed is transferred
from the source to the target cluster. The replicated content is directly inserted into
the live tables. Delta replication is used for database data which is writable in the
target cluster.
Data Replication Types

For each replication process, a data replication type is set by the system
administrator (see Data Replication Processes). The data replication type

determines which replication phases are actually performed for the respective data
replication task. The following replication types are available:
n Data Transfer
This process transfers the data to the target cluster, involving preparation,
synchronization and replication. However, it does not trigger a table or directory
switch (publication).
n Data Publishing
This process publishes data that have already been transferred to the target
cluster. The process triggers all necessary table and directory switches as well as
concomitant database commits to persist the changes (publication and cache
refresh).
NOTE: Data publishing can only be executed on the results of a process of type "Data Transfer"
executed immediately before. Note also that with database content which is writeable in the
target cluster, hence replicated via delta replication, data transfer and data publishing cannot
be separated.
n Data Transfer and Publishing

This process accomplishes a complete replication process.
n Undo
An Undo process rolls back a data replication process of type "Data Publishing"
or "Data Transfer & Publishing" which has been completed successfully. Undo
restores the target cluster state prior to executing the data replication task that
is rolled back. Note that Undo can only roll back the most recent data replication
process.
NOTE: Undo does not support the process type "Data Transfer".
NOTE: Undo is not available for replication processes that include Delta Replication, e.g. users
or promotions.
Initialization
When replication begins, initialization starts as part of either the "Data Transfer"
or "Data Transfer and Publishing" processes for tables. In Intershop 7 the system
creates the "infrastructure" required for the replication process, including tables
designated for replication. Initialization cannot be selected individually from the
backoffice but rather starts automatically. A request to export the source system
database is followed by import into the target system database. Additionally, a
synonym with the original table name, special views, deletion triggers and deletion
tables (depending on whether full or delta replication is defined for the table) is
created.
Data Replication and Channel Structure

The data replication mechanism requires both the source and target cluster to have
the same structure in the database (tables, indexes,...) and the same base content
(system domain, root site, ...). It supports the transfer of new organizations and
channels to the target cluster. However, the content of an organization or channel
can only be transferred if the respective structure (domain hierarchy) has been
replicated before or is involved in same replication process.

For example, assume a partner organization Miller working in the partner channel
Reseller Channel of the sales organization PrimeTech. In case the organization
Miller wants to replicate master repository data, then Miller, Reseller Channel and
PrimeTech also have to exist on the target cluster.
NOTE: It is not possible to replicate content into the repository of a different organization, or an
organization working in a different channel.
In practice, these dependencies impose important restrictions on the order in which

data replication processes have to be executed. For example, when creating a new
channel on the source system with its own channel repository, the new channel has
to be replicated first or together with its channel repository.
Data Replication Versus Product Data Feeds

Data replication is a special mechanism used to transfer large amounts of data from
a source to a target cluster via fast mass-data operations. Product data feeds refer to
a more general mechanism that provides the possibility to externalize the content
of a product repository into different types of targets.
On the one hand, the target of a product data feed can be a file. If targeted at a file,
publishing a product data feed works similar to – and serves similar purposes as –
export processes.
On the other hand, the target of a product data feed can be a separate Intershop 7
system (target cluster). In cases like this, product data feeds are used to selectively
transfer product data (database content and related file system content, including
images, thumbnails and attachments) from a source to a target cluster, similar to
data replication.
In fact, product data feeds – if used to transfer product data to a target cluster – rely
on the same environment as data replication in terms of architecture, setup and
configuration of source and target cluster. However, the underlying mechanisms to
actually transfer data are entirely different.
With product data transfer using product data feeds, data objects are converted
to WebObjects and serialized by Apache Axis. A Web service residing at the target
cluster is then used to deserialize the WebObjects and merge the data into the
target cluster's database.
NOTE: In contrast to data replication, product data feeds are designed to transfer small sets of data,
for example individual products that have been modified on the source system, with the changes
having to be transferred immediately to the target cluster.
When using product data feeds to transfer product data to a target cluster, the
following specific issues are important:
n System Environment
Before product data feeds to a target cluster can be used, the system
administrator has to set up source and target cluster and prepare them for data
transfer. The steps are identical to the steps necessary to prepare source and
target cluster for data replication. Refer to Preparing for Data Replication.
n Modification of Live Tables
Transferring product data from a source to a target cluster using product data
feeds directly affects the target cluster's live tables. In contrast to product data
transfer using data replication, no switching of tables is involved.

n Impact on Page Caching

If data transfer via product data feeds has been successful, all affected pages
in the page cache are invalidated, using the selective page cache deletion
mechanism (see Page Cache Preferences).
n No Undo
Data transfers executed via product data feeds cannot be rolled back.
Preparing for Data Replication or Product Data Feeds

This section describes how to connect a source and a target cluster for data
replication. The description is also applicable to scenarios in which product data
should be transferred from a source to a target cluster using product data feeds.
NOTE: The procedure outlined below assumes that source and target cluster have already been set
up, including database initialization via dbinit or dump import. Make sure that the IDs are identical.
Hence, run only one dbinit process, export the resulting dump and import this dump into the other
schema, or use one prepared dump for both instances.
Step 1: Preparing the Database Connection

The first step is to create a database connection that enables the target cluster to
access database tables of the source system. Two different means are available to
enable the database connection:
n Database Link
The database link points from the target to the source system. This is the
standard way to enable the database connection, available both for local and
remote replication scenarios. Using the name of the database link, the target
cluster can resolve queries to database tables of the source system, as shown
below (assuming the database link is named ISEDITING).
SQL> select tname from tab@ISEDITING;
n Direct Access
For local replication scenarios, an alternative mechanism is available. The
database user of the source system (e.g. intershop_edit) can grant direct access
rights to selected tables to the target cluster. The target cluster can then access
tables of this user directly, as shown below.
SQL>select tname from intershop_edit.tab;
Granting direct access requires a stored procedure to be executed, which makes

sure that all tables affected by the data replication process have been covered. If
configured accordingly, this stored procedure is performed automatically during
a replication process of type "Data Transfer" or "Data Transfer and Publishing".
Granting access manually is performed by executing the stored procedure
individually.
Creating a Database Link

Creating the database link assumes that users/schemas and database for source
and target cluster have already been set up. To create the database link, log on
to the target cluster database schema and issue the following SQL command,
replacing the placeholders according to the list that follows:

SQL> create database link <STAGING.DBLINK.NAME>

> connect to <STAGING.EDIT.AS.DBCONNECTION.USER>
> identified by <STAGING.EDIT.AS.DBCONNECTION.PASSWD>
> using '<STAGING.EDIT.DBCONNECTION.TNSALIAS>';
• <STAGING.DBLINK.NAME> is the name of the database link to be created
• <STAGING.EDIT.AS.DBCONNECTION.USER> is the database user name of the source

system
• <STAGING.EDIT.AS.DBCONNECTION.PASSWD> is the database user password of the
source system
• <STAGING.EDIT.DBCONNECTION.TNSALIAS> is the database connection alias of the
source system, as defined in the tnsnames.ora file, located in the <ora_home>/
network/admin directory of the source system database server. If you do not
have access to the database, contact your database administrator to get this
information.
NOTE: tnsnames.ora also exists on the Intershop 7 appserver for the local Oracle client, this
client is not utilized.
Using the default users and passwords of a standard server installation, this SQL
command could look as follows:
SQL> create database link ISEDITING connect to INTERSHOP_EDIT
identified by INTERSHOP_EDIT using 'ISEDITING.world';
As an alternative, you can create the database link without a TNS alias entry
in <ora_home>/network/admin/tnsnames.ora by executing the following SQL
command:
SQL> create database link ISEDITING connect to INTERSHOP_EDIT
identified by INTERSHOP_EDIT using
'(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
(HOST=<STAGING.EDIT.DB.HOSTNAME>)
(PORT=<STAGING.EDIT.DB.LISTENER.PORT>))
(CONNECT_DATA=(SID=<STAGING.EDIT.DB.SID>)))';
To see if the database link works, you can, for example, execute the following SQL
command:
SQL> select tname from tab@ISEDITING;
This command should not return any errors, and it should list the respective table
names of the source system database.
Granting Direct Table Access

For local replication scenarios, granting direct table access to the target cluster
provides an alternative means to enable the database connection between source
and target cluster.
To grant direct table access rights to the target cluster, a stored procedure
(staging.grant_live_user_privs) needs to be executed on the source system. This
is done automatically when a replication process of type "Data Transfer" or "Data

Transfer and Publishing" is performed. To enable the stored procedure, proceed as

follows:
1. On the source cluster, open the replication-clusters.xml file in
<IS.INSTANCE.SHARE>/system/config/cluster.
2. In the corresponding target system definition, specify the target database
user.
The relevant entry could look as follows:
<target-clusters>
<target-cluster id="Cluster42">
<target-systems>
...
<target-system id="TargetSystem2" active="false">
...
<target-database-user>INTERSHOP_LIVE</target-database-user>
</target-system>
</target-systems>
</target-cluster>
</target-clusters>
NOTE: For more information about the replication-clusters.xml file,, refer to Source System
Configuration.
3. Restart both the target and the source system.

NOTE: Make sure to start the target cluster first.
Granting Direct Table Access Manually

The following list details how to manually grant direct table access.
1. Login to the database as editing user and execute the stored procedure
staging.grant_live_user_privs('NAME OF TARGET_USER SCHEMA'), e.g.:
• exec staging.grant_live_user_privs('INTERSHOP_LIVE0')
2. Repeat for every target user schema, where the target system is configured
to use direct database access.
Step 2: Configuring Source and Target cluster

Once the database connection between source and target cluster has been
established, there are a number of configuration settings that must be specified for
the source and the target.
In Intershop 7 data replication is based on a multiple data center approach. This
essentially means that critical components of an installation (such as the Intershop
Shared Files and database) or cluster can be distributed over multiple data centers
to ensure availability. The staging.properties file contains the type of replication
cluster (live, edit, none) and is contained in both the editing and live systems. The
communication channel configuration file, replication-clusters.xml, is located in
the editing system and transfers the information required by the live system at
replication. The configuration files are shared across all the application servers of
any one cluster, including servers within clusters that are distributed across more
than one data center.

Source System Configuration

Each Editing system contains information about the target clusters it serves. Each
target cluster consists of one or more target systems. The communication channels
that are needed during the replication process are configured in the editing system.
The replication-clusters.xml must contain the following information:
n List of the target cluster(s) and its subsequent systems
n List of the target system(s) for every target cluster
n An "Active" flag indicating the target systems involved in replication
n The URL of each target system's web server
n Intershop 7 servergroup to use in the target system at replication begin
n Intershop 7 servergroup to use in the source system for file content
download
n Connection information for access to the editing system's database data
during replication:
• DBLink connecting to editing database schema
• Name of the target schema (allows the editing system to grant this target
system access to the editing schema) or the DBlink name must be provided
An example of the replication-clusters.xml file:

<target-clusters>
<target-cluster id="Cluster42">
<target-systems>
<target-system id="TargetSystem1" active="true">
<webserver-url>http://ts1.mydomain.com:80</webserver-url>
<source-server-group>BOS</source-server-group>
<target-server-group>BOS</target-server-group>
<source-database-link>ISEDITING.world</source-database-link>
</target-system>
<target-system id="TargetSystem2" active="false">
<webserver-url>http://ts2.mydomain.com:80</webserver-url>
<source-server-group>BOS</source-server-group>
<target-server-group>STG</target-server-group>
<target-database-user>INTERSHOP_LIVE</target-database-user>
</target-system>
</target-systems>
</target-cluster>
</target-clusters>
NOTE: Keep in mind that the target systems that are not used in the replication process must be
flagged active="false" in replication-clusters.xml. The URL of the source system is not required
in the configuration, though it is used to download file content, because it is already known from
appserver.properties.
On the source system:

1. Open the staging.properties file in <IS.INSTANCE.SHARE>/system/config/
cluster.
2. Set staging.system.type to editing.
staging.system.type=editing
This setting triggers the creation of special tables for database replication
during database initialization via dbinit (see step 3 below).

3. Restart the Intershop 7 application.

This enables the settings made.
Target cluster Configuration

On the target cluster:
1. Open the staging.properties file in <IS.INSTANCE.SHARE>/system/config/
cluster.
2. Set staging.system.type to live.
staging.system.type=live
3. You can provide a name for the target cluster as a value for
staging.system.name. This name (which can be an arbitrary string) will be
used to refer to the target cluster in the central administration front end of
the source system.
staging.system.name=Sample Target cluster
4. Restart the Intershop 7 application.

This enables the settings made.
The data replication mechanism allows for additional database table inclusion
at a later time in regular operation. Therefore, each time a replication process
of type "Data Transfer" or "Data Transfer and Publication" is started, the process
automatically checks if new tables must be initialized.
Step 3: Database Initialization

The data replication mechanism is based on a set of special tables (live and shadow
tables, see Processors and Decorators), which need to be created before the actual
data replication can take place. This requires to initialize the database accordingly.
Two basic approaches are available to initialize the database in a new replication
environment:
n Running a dbinit process on the source system, then exporting a database
dump and importing this dump in the target cluster
With this approach, you can already prepare the required database tables
when executing the dbinit process. To this end, set staging.system.type in the
staging.properties file either live or editing (the default value is none).
staging.system.type = editing | live
n Importing an existing database dump in the source and target clusters

With this approach, the database tables required for the data replication are
created during the replication process.
General Data Replication Configuration

The data replication environment is set up during Intershop 7 installation, and
its general configuration (stored in <IS.INSTANCE.SHARE>/system/config/cluster/
staging.properties) should not be altered. However, in case of system changes, these
settings need to be adjusted according to the new conditions.

The staging.properties file has three main sections: for general system configuration,
live system configuration, and staging processor configuration. Each section is
described below.
General System Configuration

The following properties for general system configuration are available:
NOTE: Intershop recommends not to alter the default settings.
n staging.system.type
Defines the system type within a data replication environment. Accepted
values are none, live and editing. With the types live and editing, the database
is capable of storing replicated data, so these types can easily be switched.
With the staging type none, there are no database tables prepared for data
replication, so after changing none to live or editing, the database must be
reinitialized using dbinit.
The default value in a non-staging environment is editing.
n staging.system.name
States the name of the system. Note that the actual definition of the system
name is done in replication-clusters.xml, the staging.properties file keeps it for
information purposes only. The default value is the host name.
Timeout Settings
After the replicated data has been published in the target cluster's database or file
system, the system's caches must be refreshed. In case of timeouts upon cache
refreshing, the replication process continues executing, but errors are logged
accordingly. As the page cache may contain inconsistent data after a replication
timeout, remove the cache in the according Intershop 7 application and restart the
application.
The timeout settings apply only to the target cluster. They define the maximum
time the replication process waits for the related cache to be refreshed before
logging an error.
Processors and Decorators

The data replication framework relies on so-called staging processors and
associated staging processor decorators. The staging processors provide methods
for the replication of different content types, such as domain specific database
content or system-wide database content.
The data replication processors and decorators are contained in the package
com.intershop.beehive.core.capi.staging.process in the core cartridge, and are
declared in the staging.properties file of an editing system.
CAUTION: Invalid processor and decorator settings may corrupt your data.
Data Replication Jobs

Intershop 7 includes a number of scheduled jobs that perform certain recurring
tasks related to data replication.

NOTE: Enable these jobs only if you are using the data replication functionality on your systems.
Jobs on Source System
Replication Process Scheduler

This job tries to start all replication processes with state WAITING and current date
>= replication process schedule time. Note that there can only one replication
process run per target cluster - a second one will not be executed at this time.
The pipeline executed in this job is TriggerReplicationProcess-Schedule of the
sld_system_app cartridge. The job is prepared by the sld_system_app cartridge into
the domain SLDSystem. To configure the job, log on to the SMC and select the site
SLDSystem.
By default, the job is disabled. Enable the job and configure it to run every 60
minutes.
Replication Task State Synchronization

This job determines all replication tasks of the system with state PENDING and
updates state to WAITING, if current date >= replication task start time. This
is necessary because only tasks with state WAITING can be assigned to replication
processes.
The pipeline executed in this job is ReplicationTaskStateSynchronizationJob-Start of
the sld_system_app cartridge. The job is prepared by the sld_system_app cartridge
into the domain SLDSystem. To configure the job, log on to the SMC and select the
site SLDSystem.
By default, the job is disabled. Enable the job and configure it to run every 60
minutes.
Jobs on Target Cluster
SyncLiveWithEditingStagingProcess
If a replication process fails, e.g., because the source system crashes after a
replication process has been started, resources on the target cluster remain
locked. This job regularly checks if there are any replication processes with status
FAILED, and releases the locked resources. The pipeline executed in this job is
SyncLiveWithEditingStagingProcess-Start of the core cartridge. The job is prepared by
the core cartridge into the domain root. Hence, to configure the job, log on to the
SMC and select the site root.
By default, the job is enabled and configured to run every 1440 minutes (once
a day), which is the recommended setting. In case of evident failures, Intershop
recommends to trigger the job manually.
Logging
As all application log files, the log files for data replication are located in the
<IS.INSTANCE.SHARE>/system/log/ directory.

There are two types of replication log files:

n dbinit Log File
The staging-<hostID>-dbinit-<timeFrame>.log file is written during the database
initialization. It records all replication-relevant dbinit events, such as the creation
of replication tables, table environments, or replication directories.
n Application Server Log File
The staging-<hostID>-<serverID>-<timeFrame>.log files are written during
replication operations. Note that each application server writes its own log file.

Chapter 3
System Management
Overview
This chapter provides a reference to the System Management Console (SMC). It
describes how to use the SMC in order to perform basic administration tasks in an
Intershop 7 cluster, such as managing scheduled jobs, managing logging options,
and monitoring the application functionality:
n Navigate the SMC
This section explains how to access, log in to, and navigate the SMC.
n Schedule Management
This section describes how to control scheduled jobs in the Intershop 7 system.
n Logging Options
This section outlines how to change the logging options of the Intershop 7
application.
n File Browser
This section describes the SMC File Browser tool.
n License Auditing
This section describes how to generate a license report as required by your
purchasing contract and license agreement.
n Site Management
This section describes the site management features like server group
assignments or page cache behavior, for instance.
n Monitor the System State
This section outlines the monitoring functionality of the SMC.
n Installation Maintenance
This section describes the installation maintenance features of the SMC.
Navigate the SMC

The System Management Console is a Web front application running in a Web
browser.

Navigate the SMC Chapter 3: System Management
Access and Log In to the SMC

To access the SMC via a standard Web browser:
1. Enter a URL with the following syntax:
http://<SYSTEM.HOST>/INTERSHOP/web/BOS/SMC
where <SYSTEM.HOST> is either the IP or DNS name of the machine hosting the
Intershop 7 Web Gateway.
2. Log in as administrator.
In a default Intershop 7 installation, use the following credentials:
• Login: admin
• Password: !InterShop00!
NOTE: For security reasons, you should change this password. See Change the SMC
Password.
Navigate the SMC

After logging in, the main screen of the System Management Console is displayed.
Figure 9. SMC main screen
This screen is sub-divided into two areas: a navigation bar on the left and the main
page area on the right, which displays lists or dialogs associated with the module
selected in the navigation bar.
The navigation bar comprises the following sections:
n Schedules
Allows for controlling scheduled jobs in the Intershop 7 system. See Schedule
Management.
n Logging
Allows for specifying the level of detail recorded in the application log files. See
Logging Options.
n License Report
Allows for generating a license report, according to your Intershop 7 purchasing
contract and license agreement. See License Auditing.
n Site Management
Allows for controlling global settings for the sites served by the Intershop 7
system. See Site Management.

Chapter 3: System Management Schedule Management
n Monitoring
Allows for monitoring the server functionality. See Monitor the System State.
n Installation Maintenance
Allows for collecting vital information about the Intershop 7 system and
transferring it to Intershop Support. See Installation Maintenance.
In addition, the quick access buttons located above the main page area provide
immediate access to certain functionality:
n Home
Opens the front end start page.
n Change Password
Opens the user detail view for the current user (admin) to change the password.
n Logoff
Logs off the user (admin) from the current session and displays the log on
screen.
Change the SMC Password

NOTE: The SMC user name is always admin and cannot be changed.
To change the SMC password:

1. Click the Change Password button.
The Change Password page is displayed.
Figure 10. Changing the SMC password
2. Enter the old password, the new password and the new password
confirmation in the corresponding fields.
3. Click Apply.
Your password has now been changed.
Schedule Management
Using the Schedules module, the Intershop 7 system administrator can control all
scheduled jobs created in the system, regardless of their original site assignment,
permission, etc. In addition, this module allows for creating, editing or deleting
scheduled jobs in any of the system sites.

Schedule Management Chapter 3: System Management
Enable/Disable the Job Processor

Intershop 7 allows for enabling/disabling the job processor of an application server
in a cluster while the server is running. To do so:
1. In the navigation bar, select Schedules|Target Servers.
The job processor statuses for all servers in the cluster are displayed.
Figure 11. Job processor statuses in the cluster
2. Select the application server where you intend to change the job processor
status.
Click the checkbox next to the server to select it.
3. Click Enable or Disable, as appropriate.
The job processor state is set as required and made persistent in the local
properties file of the corresponding application server (<IS.INSTANCE.SHARE>/
system/config/servers/<HOST.ID>/<INSTANCE.ID>/appserver<#>.properties). The
new job processor status is published within the cluster via the servers' event
messaging information.
List Scheduled Jobs

To view a list of scheduled jobs defined in any of the system sites:
1. In the navigation bar, select Schedules|Scheduling.
A list of all schedules in the root site is displayed.
2. Select the required site from the list box and click Apply.
A list of all schedules in the selected site is displayed.

Figure 12. Schedules overview page
The job schedules overview allows for filtering the schedules list by domain,
operation state, server, instance and host machine. In addition, the schedules
list can be sorted by name, domain, last run, last duration and operation state
through clicking the corresponding attribute in the table head.
Create a New Scheduled Job

To create a new scheduled job:
2. Select the site where you intend to create the schedule and click Apply.
3. Click New.
An empty Schedule Details page is displayed.

Figure 13. Specifying schedule details
4. Enter all required information.

The following table lists the available fields.
Table 48. Schedule Detail Fields
Field Description
Name A unique name for the schedule. Duplicate entries are rejected.
Description A description of the schedule.
Enabled (checkbox) Select this checkbox to enable (activate) the schedule.
Application Select the application where the scheduled pipeline shall run.
Pipeline The name of the scheduled pipeline.
Start Node The start node of the scheduled pipeline.
Host Name Specify the host where the scheduled pipeline shall run. (If left
blank, it may run on any host in the cluster.)
Installation ID Specify the Intershop 7 instance where the scheduled
pipeline shall run, e.g., ES1. The installation ID is stored in the
intershop.properties file of the respective instance as value of the
property IS_INSTALLATION. If no ID is provided, the schedule
can run in any instance in the cluster.
Server Name Specify the application server where the scheduled pipeline
shall run. (If left blank, it runs on the application server where
the automatic job processing is enabled.)

Field Description
Server Group Specify the application server group where the scheduled
pipeline shall run. (If left blank, it runs in the default server
group set for the application.)
Data Center Specify, if applicable, the data center that the scheduled
pipeline shall use.
Run Once (radio button) Select this option to run the schedule once.
Recurring Interval (radio Select this option for the schedule to run at recurring intervals.
button)
Run Time Set the time when the pipeline starts running.
Active Set the period during which the specified recurring interval is
active.
Every (radio button) Select this option for the schedule to run at the specified
recurrence pattern.
On these days (radio Select this option for the schedule to run on the selected
button) day(s).
5. Click Apply to save your changes.

If you have activated the new scheduled job, it will run at the specified time.
Edit a Scheduled Job

To edit an existing scheduled job:
2. Select the site where you intend to edit the schedule and click Apply.
3. Click the name of the schedule you intend to edit.
The selected schedule's details are displayed.
4. Change the schedule's settings as required.
To discard the changes and restore the previous saved state, click Reset.
Run a Scheduled Job Manually

To run an existing scheduled job manually:
2. Select the site where you intend to run the schedule and click Apply.
3. Select the checkbox next to the schedule you intend to run.
4. Click Run.
The scheduled job is run immediately, regardless of any activation and run time
settings.

Delete a Scheduled Job

To delete one or more scheduled jobs:
2. Select the site where you intend to delete the schedule and click Apply.
3. Select the checkbox(es) next to the schedule(s) you intend to delete.
4. Click Delete.
The selected schedules are removed from the system.
Manage Process Chains

Intershop 7 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:
n <chain>
The root element of the process chain XML file. Important attributes
include name (used in the SMC module Monitoring|Locking|Processes) and
keepAliveTime, which specifies the pool wait time in minutes.
n <concurrent>
Child element of <chain> or <sequence>. Includes jobs or pipelines to be
executed in parallel. The attribute name is used in the SMC module Monitoring|
Locking|Processes.
n <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 SMC
module Monitoring|Locking|Processes.
n <job>
Child element of <sequence> or <concurrent>. Specifies a job to be executed
within the chain. The next table lists the attributes for <job>.

Table 49. Attributes of the process chain element <job>
Attribute Description
job Specifies the name of the job as defined in the SMC 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.
n <pipeline>
Child element of <sequence> or <concurrent>. Specifies a pipeline to be
executed within the chain. The next table lists the attributes for <pipeline>.
Table 50. Attributes of the process chain element <pipeline>
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.
n <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.
NOTE: Make sure that <error> is the last element within the corresponding <sequence>.
n <parameter>
Optional child element of <pipeline>. Can specify the parameter that the
pipeline to be executed may require.
n <description>
Optional child element of <sequence>, <concurrent>, <job> or <pipeline>.
Specifies a description to be displayed in the SMC module Monitoring|Locking|
Processes.

Logging Options Chapter 3: System Management
n <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 upon 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.
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 7 core cartridge. This involves the following steps:
n Creating a new scheduled job
For details about scheduled job creation, refer to Create a New Scheduled Job.
Make sure to specify the pipeline ExecuteProcessChain and the start node Start.
n 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.
n Configuring the process chain execution

Define the recurring interval, specific login and password, etc. as necessary. For
details, see Create a New Scheduled Job.
The process chain will be executed according to your settings.
Logging Options
Using the SMC Logging module, you can customize the existing logging appenders
defined for your Intershop 7 instance. The settings specified in this SMC module are
written to <IS.INSTANCE.SHARE>/system/config/cluster/logging.properties.
For information about basic logging framework concepts, refer to Application
Logging.
View Logging Status

Upon opening the Logging module, the SMC displays an overview page that lists
the available application servers in the cluster. It shows some basic information,
including startup time, status and activated settings scope.
Figure 14. Logging module overview
To check the logging status for an application server, click the server name in the
list. This opens the Logging status detail view for the selected server.

Chapter 3: System Management Logging Options
Figure 15. Application server logging status
Available Logging Settings
Settings Scope
As with most application properties, you can define global (cluster-wide) logging
settings, or define them locally for each application server, where local settings
overwrite global settings.
To decide whether to use global or local settings for an application server:
1. In the SMC Navigation Bar, select Logging.
The Logging Settings overview page is displayed.
2. Select the intended application server.
The detail view for the application server is displayed.
3. Open the Logging Settings tab.
Figure 16. Application server logging settings
4. In the Settings Scope section, select the required option.

Choose either
• Use Cluster-Wide Settings, or

• Use Application Server-Specific Settings.

NOTE: Changing the scope from cluster-wide to application server-specific copies the cluster-
wide setting for this application server. Changing the scope from application server-specific to
cluster-wide deletes the application server-specific settings.
5. Click Apply.
If you choose to use cluster-wide settings, the actual logging options are not
editable in this dialog.
NOTE: The further logging options apply to both the cluster-wide and the application server-
specific settings.
Additional Logging Configuration Files

For maintenance reasons or during application development, you may need
additional logback configuration file includes, which are loaded and applied at
runtime.
Uploading Configuration Files

To upload logback configuration includes:
2. Navigate to the intended Advanced Logging Settings tab.
For cluster-wide settings, open Logging | Cluster Wide Settings in the SMC
Navigation Bar, then change to the Advanced Logging Settings tab.
The files are uploaded to <IS_SHARE>/config/cluster/loggingextension.
For application server-specific settings, select the intended application server
and open the Advanced Logging Settings tab.
The files are uploaded to <IS_SHARE>/config/servers/<Host>/<InstallationID>/
<ServerName>/loggingextension.
3. In the Upload File field, specify the file path or click Browse to locate the
file.
4. Click Upload.
The file is uploaded and, upon completion, displayed in the list.
NOTE: Uploaded files are automatically activated, i.e., the corresponding logging settings are
applied without further user interaction.
Deleting Configuration Files

To delete logback configuration includes:
2. Navigate to the intended Advanced Logging Settings tab.
For cluster-wide settings, open Logging | Cluster Wide Settings in the SMC
Navigation Bar, then change to the Advanced Logging Settings tab.

For application server-specific settings, select the intended application server

and open the Advanced Logging Settings tab.
3. Select the configuration file(s) you want to delete.
Mark the corresponding checkbox(es).
4. Click Delete.
A confirmation box appears prompting you to confirm the file deletion and
appender deactivation.
5. Click OK to confirm the deletion.
The configuration file is removed, and the corresponding appenders are
deactivated.
NOTE: Upon file deletion, only the appenders defined with this file are deactivated, possibly
defined other settings still remain active as long as the server is up.
Appender Options: Level Filters and Categories

All appenders defined for Intershop 7 via the logback-*.xml configuration files
can be customized in the SMC through defining log level filters and assigning log
categories. The following table lists the appenders and their corresponding settings
as available by default.
Table 51. Default appender settings
Appender Level Filter Assigned Categories

Audits root,
com.intershop.beehive.core.internal.request
Debug Debug
Error Fixed Error root,
ImpexError Warn root,
Job Info root,
ServerStartupConsole org.apache.catalina.startup.Catalina
TraceConsole
Warn Fixed Warn root,
WarnConsole Warn
An empty level filter (set to none) indicates that this appender currently has not
assigned a customizable level filter. This means, any log events to be recorded by
this appender only pass the filters defined in the preceding filter chain (turbo filters,
category filters).
NOTE: If there is no category assigned, the appender does not record any log output.
Changing the Logging Settings

Changing the logging settings via the SMC means customizing the level filters and
category assignments for the existing appenders.

Selecting the Settings Scope

First choose whether to define cluster-wide or application server-specific logging
settings:
• To define cluster-wide settings, open Logging | Cluster Wide Settings in the SMC
Navigation Bar.
• To define application server-specific settings, proceed as described in Settings
Scope, and apply the Application Server-Specific Settings option.
NOTE: The further logging options apply to both the cluster-wide and the application server-
specific settings.
Setting the Level Filter

To change the level filter for an appender:
1. Open the Logging Settings for the cluster or an application server.
2. In the Appender section, click the appender to change.
The appender's detail page is displayed.
3. In the Level Filter section, select the level filter to use.
Open the drop-down list and choose the required filter.
Figure 17. Selecting a level filter

Clicking Reset reverts to the last saved state.
Managing Categories
NOTE: The category lists delivered by the SMC Logging module only display categories that are
known to the logging system at the given time. A category is known if it is explicitly mentioned
in a configuration file or after the corresponding application code has issued a log request for this
category.

Assigning Categories
To add category assignments for an appender:
3. In the Assigned Categories section, select the required categories.
Before setting the required category level, you must select a root category (with
additivity="false") that limits the appender inheritance (see Application
Logging: Basic Concepts).
The category drop-down list allows for selecting all sub categories of the given
root category that are not already included.
Figure 18. Assigning a category to an appender
4. Click Assign to save the selected category with the appender.

Clicking Back to List returns you to the overview page without assigning the
category to the appender.
Unassigning Categories
To remove a category assignment from an appender:
3. In the Assigned Categories list, select the category assignments to remove.
Use the checkbox to select the intended categories.
4. Click Unassign.
The category assignment is removed from the appender.

File Browser Chapter 3: System Management
Viewing Child Categories

Categories may include sub categories that are included automatically when
creating assignments for appenders. To view sub categories:
3. In the Assigned Categories list, click the name of an assigned category.
The Sub Categories page is displayed.
Figure 19. Automatically included sub categories
4. Click Back to return to the appender's detail page.
File Browser
The File Browser enables Intershop 7 directory browsing and zip-compressed
download from the SMC. This tool enables administrators to quickly browse the
Intershop 7 directories without requiring access to the file system as only the SMC
login is required. With this tool, it is possible to view and download files from any
server within an Intershop 7 cluster.
Figure 20. SMC file browser
By default, all directories are hidden. System folders are made available by
configuring the property file located at <IS_SHARE>/system/config/apps/
intershop.enfinity.SMC/filebrowser.properties. Here you can specify directories
and sub directories for viewing and download by using the IS path alias (such as
${IS_SHARE};${IS_HOME}) or without the alias (such as c:/share/**** or /var/***)
depending on your operating system. To set a directory to 'browsable'(viewable),
edit the property file per the following:
filebrowser.dir.browsable=${IS_SHARE}/system/log;${IS_HOME}/webadapter/
log;/var/log
NOTE: All sub directories within a 'browsable' directory are automatically viewable.
The above example sets three log directories as viewable by the file browser. These
are separated by a semi-colon (;).

Chapter 3: System Management License Auditing
Conversely you can specify a set of files or sub directories as hidden with a regular
expression even if the directory is viewable. To hide a file within the above defined
directories, edit the property file per the following:
filebrowser.files.hidden.regexp=.*zip
The above example hides all files that end with 'zip' from being able to be viewed in
the file browser.
License Auditing
Intershop is authorized to request license reports from Intershop 7 customers. Use
the License Report module to generate a license report and to send it to Intershop,
according to your purchasing contract and license agreement.
CAUTION: With multi-core technology, each CPU core is considered a CPU for licensing purposes.
To generate a license report:

1. In the SMC navigation bar, select License Report.
The License Report module is displayed.
Figure 21. Generating a license report
2. Specify a start and end date, and click Generate to start the report
generation.
The license report contains the contents of your license.xml file, lists all installed
cartridges and provides general cluster information.
3. Specify the e-mail addresses of the report's recipient and sender.
Your purchasing contract or license agreement should specify an e-mail
address where generated license reports are to be sent, for example
[email protected].

Site Management Chapter 3: System Management
Figure 22. Submitting the license report
4. Click Send as e-mail to send the license report to Intershop.

You can also download the report as encrypted XML file by clicking Download
Report.
Site Management
Using the SMC Site Management module, the system administrator can control
global settings for the sites served by the Intershop 7 system.
Access and Navigate the Site Management Module

To enter the site management module, select Site Management from the SMC
navigation bar. This opens the Sites Overview page, which lists all sites served by
the system and displays basic information like ID and online status.
Figure 23. SMC sites overview
To edit the setting for a site, click the site name in the list. This will open the site's
detail page. The site's detail page contains three tabs, General, Page Cache and
Applications, which allow for setting the corresponding preferences.

Chapter 3: System Management Site Management
General Site Preferences

On the General tab, the following preferences are controlled: server group
assignment, HTTPS traffic, URL rewriting and online status.
Figure 24. General site preferences
n Server Group
Allows for assigning the site to a dedicated server group (see Server Group
Definition). If not set, the default group WFS is used.
n HTTPS
Allows for securing the online access to the site using the secure protocol HTTPS
for pages defined as "secure URLs" (like, for example, checkout pages or profile
pages).
NOTE: For development environments, all HTTPS links can be deactivated. This setting is stored
in the user session as well as in the page cache. When toggling HTTPS, it may be necessary to
flush or deactivate caches and remove the user sessions.
n URLRewriteSiteName
Specifies the name of the site if URL rewriting is enabled.
NOTE: Not specifying this value may cause URL rewriting rules to malfunction.
n URL Rewriting
Allows for applying the URL rewriting mechanism in order to enable the site to
publish search engine friendly URLs.
n Status
Allows for setting the online status of the site.
Table 52. Site statuses
Status Description
Live The site is accessible.
Maintenance The site is only available to back office operators. Storefront requests
addressed to the site are blocked.
Disabled The site is only available for system administrators in the SMC or Central
Administration Front End. Back office and storefront requests to the site
are blocked.
To adjust one of the mentioned preferences, change the corresponding setting as

necessary, then click Apply to save the changes. Click Reset to discard your changes
and to revert to the last saved state.

Site Management Chapter 3: System Management
Page Cache Preferences

On the Page Cache tab, system administrators control the page cache behavior of
the site. This includes, in addition to the global page cache activation, the following
settings:
• the time that cached pages are kept,
• keyword-based cache invalidation and deletion,
• cache index-based cache invalidation and deletion,
• complete cache invalidation and deletion, and
• cache prefetching.
Figure 25. Page cache settings
In detail, the following options are available:

n Page caching
Allows for globally activating the page caching.
n Maximum age of static content
Allows for setting the maximum time after which static content (such as images)
is invalidated automatically.
n Explicit keyword processing
Enables the keyword-based page cache invalidation and deletion. Storefront
pages marked with specific keywords can selectively be invalidated, and later
removed from the cache.
NOTE: This option should only be enabled if the templates for your channel have been
assigned specific keywords.
n Full text indexing

Allows to index all cached pages. It is then possible to invalidate all pages that
contain given keywords.

Chapter 3: System Management Site Management
To adjust one of the mentioned preferences, change the corresponding setting as

necessary, then click Apply to save the changes. Click Reset to discard your changes
and to revert to the last saved state.
In addition, the Page Cache tab provides the interface for the following operations:
n Invalidate page cache
Allows for invalidating only selected pages in the page cache. To this end,
enter the respective keywords in the text box (either keywords defined in the
template or keywords found in the page cache index), and click Invalidate.
n Invalidate complete cache
Allows for invalidating the entire page cache, without respect to any keywords.
n Prefetch cache
Explicitly triggers the Web crawler in order to refill the the Web Adapter's page
cache after page cache deletions (for details, refer to Page Cache Pre-Fetching).
Application Settings
The Applications tab lists all applications that are attached to the current site.
Clicking an application entry opens the application detail page that displays
relevant information about the selected application.
Figure 26. A site's application list
The General tab of the application detail view shows important information like
type, name, URL ID, and status (default, enabled).
Figure 27. General application data
The Cartridge Structure tab lists all cartridges used by the current application.

Monitor the System State Chapter 3: System Management
Figure 28. Application cartridges
The REST API tab lists all ressources of the current application that are accessible
using REST calls.
Figure 29. Application REST ressources
Monitor the System State

The SMC monitoring module is the main system monitoring tool. Using this
module, system administrators can monitor the properties, process information,
current threads and requests of all server components in the Intershop 7
system. This information can be used for advanced debugging, profiling and
troubleshooting purposes in an Intershop 7 installation.
Access and Navigate the Monitoring Module

To enter the monitoring module, select Monitoring from the SMC navigation bar.
This opens the Cluster Overview page, which lists all servers in the cluster and
displays basic performance data.

Chapter 3: System Management Monitor the System State
Figure 30. Monitoring Cluster Overview page
Monitoring Sub-Modules
The Monitoring section in the navigation bar comprises the following sub-modules,
each providing the corresponding detailed information:
• Application Server
• Java VM
• OR Mapping
• JDBC
• Cartridges
• Performance
• Background
• Database Status
• Locking
• Services
• Additional Monitoring Options
Sub-Module Overview Page

Through clicking one of the sub-modules, you are taken to an overview page that
lists the available monitoring options.
Figure 31. Application Server overview page
Sub-Module Detail Page

To view the detailed information of a topic listed in the sub-module overview page,
click the corresponding link. This opens the detail view.

Figure 32. Application Server process details
Monitoring Options
The following tables outline the available monitoring options, sub-section by sub-
section.
n Application Server
Table 53. General application server monitoring options
Monitoring Item Description

Process Information Displays general information about the application server
(process ID, startup date, cluster ID, server groups), and about its
Web front service (port, handler thread number, etc.)
Resource Usage Displays information about the current server process (CPU
usage, total process size, in-memory size, used system threads).
Properties Displays the properties that are currently known by the
application. This list contains aggregated properties from a
number of *.properties files, for example the global and local
appserver.properties, orm.properties, all cartridge *.properties
files, and staging.properties. Note that sensitive properties may
be hidden (see Sensitive Properties Settings).
Sessions and Requests Displays information about the session management options
and session and request statistics for the server.
Configuration Values Enables the retrieval of configuration data from an application
server. Configuration values can be retrieved from the scope,
domain, application and key (displaying all of the values for
each instance of a particular key).
n Java VM

Table 54. Java Virtual Machine monitoring options

Resource Usage Displays information about the Java Virtual Machine (total heap
size, used heap size, used/total heap ratio.)
Threads Displays all threads that currently exist in the Java Virtual
Machine.
System Properties Displays all the system properties of the application server's
JVM.
n OR Mapping
Table 55. OR Mapping monitoring options

ORM Cache Displays general information about the ORM cache such
as number of cached instances, cache synchronization
information, or persistent objects in the cache.
Persistent Object Displays information about the selected persistent object on
Information the monitored server (number of instances in cache, default
reference type.)
n JDBC
Table 56. JDBC layer monitoring options

Drivers Displays information about the registered JDBC drivers.
Data Sources Displays general data source information and Oracle
connection cache information.
n Cartridges
Table 57. Cartridges Monitoring options

Loaded Cartridges Lists all cartridges loaded on the server and shows basic
cartridge information (name, display name, version, build,
cartridge directory, JAR files.)
Loaded Pipelets Lists all pipelets loaded on the server.
Duplicated Pipelets Generates a list of duplicate pipelets on the server.
n Performance
Table 58. Performance Monitoring options

Configuration Configures and activates/deactivates the Performance Monitor
types (request, pipeline, class, managed service, object path,
pagelet, pipelet, query, SQL and template) and displays the
current monitoring state (active/inactive). You can also set
values to be written to a log.
Compare Performance Select a sensor and base report data to make a performance
Monitoring Results comparison to another report (across all sites). A sensor is a
Request, Pipeline, Class, Managed Service, Object Path, Pagelet,
Pipelet, Query, SQL or Template.


Performance by Domain Select a specific site and display request performance. Values
and Site are returned for hits, total time, effective time, average time
minimum time and maximum time.
Performance by Type Select a specific type of performance measurement and display
the values across all sites.
n Background
Table 59. Background Monitoring options

Configuration Displays the current background monitoring state and allows
for switching it on or off and adjusting the timeout between
two measurement cycles.
Memory Charts Shows the memory usage of the running server (process
memory, JVM memory, ORM cache memory) in graphs.
Session Charts Displays graphical information about the sessions of the
running server (total sessions, active sessions, active requests.)
Performance Charts Displays detailed information about the performance of the
running server (average response time, CPU usage, load factor,
thread count.)
CAUTION: The Configuration dialog allows for specifying a new monitor pipeline. Unless you
have implemented a custom monitor pipeline or added a custom start node to the existing
one, Intershop strongly recommends to keep the default settings.
n Database Status
NOTE: Before you can monitor the database status, you have to execute the script
DBMonitorGrants.sql, located in <IS.INSTANCE.DIR>/bin.
Table 60. Database Status Monitoring

Database Status Displays detailed information about database configuration
and performance. Select one of the reports from the list box to
display the corresponding information.
n Locking
Table 61. Locking Monitoring options

Named Resources Displays information about named resources. Named resources
are virtual entities. Every named resource is identified by
a unique name. Named resources can have a hierarchical
structure.
Instance Resources Displays information about instance resources. Instance
resources are created dynamically. Every instance resource
represents an instance of a PersistentObject.
Processes Displays information about Intershop 7 processes, such as data
replication processes, import processes and scheduled jobs.
Locking Conflicts Displays information about resource acquisition problems.
Resource acquisitions problems occur if a process tries to
acquire a resource that is already locked by another process.

n Services
This section summarizes the service providers that are integrated into your
system. The overview page lists the services and their statuses in the site and
application server contexts, grouped by service type.
Clicking a service name opens a detail view, which is divided into two tabs.
The Monitoring tab shows more, fine-grained operation details, whereas the
Maintenance tab provides options to enable/disable, ping or test the current
service.
n Additional Monitoring Options
Enable CIC/runtime sensors artifacts tracking for pipelines, pagelets and
templates. Follow the instructions below to perform this action.
1. Select Monitoring > Performance > Configuration from within the SMC.
2. Select the monitoring types you want to activate and click "Apply".
3. Mark the box "Trace artifact structure for activated sensors" and click
"Apply".
Trace artifact structure for activated sensors and click "Apply".
All further requests will trace the corresponding hierarchy to a log file (/share/
system/logs/monitor-$hostName-$installationID-artifact-structures.log). Entries
will be of format:
Timestamp|requestID|root ArtifactPath
with
ArtifactPath = ArtifactID
JMX and MBean Support
What is JMX?
JMX refers to the Java Management Extension, a framework for application and
network management in the Java programming language. Using JMX technology,
a given resource is instrumented by one or more Java objects known as Managed
Beans, or MBeans. These MBeans are registered in an MBean server. Through the
MBean server, resources exposed via MBeans can be accessed by management
applications (JMX clients) in order to
• Read and change application parameters during runtime
• Provide statistical data (performance, resource usage, logs, errors, etc.)
• Receive notifications in case of errors
• Monitor critical system components.
Intershop 7 provides a set of pre-defined MBeans that make it possible to obtain

and process system monitoring information from JMX clients such as the MX4j HTTP
Adaptor for Tomcat application servers. In addition, Intershop 7 includes a simple
mechanism to register additional MBeans provided by custom cartridges.

NOTE: The current release of Intershop 7 provides support for standard MBeans, which define
their management operations and attributes by a static Java interface. Other MBean types are not
supported.
MBean Registration
A standard MBean consists of a Java interface (with the suffix MBean) and an
implementation class. Each cartridge registers the MBeans which it provides.
Registered MBeans are then loaded during application server startup and
integrated with the MBean server of the underlying application server.
To register MBeans, you have to provide an mbeans.properties file within the
classpath directory javasource/resources/<cartridge-name>/naming of your
cartridge. The mbeans.properties file defines the respective "MBean-Classname" to
"JMX-ObjectName" mappings. The general schema for MBean entries is
mbean_class_name=mbean_object_name
The MBean class name needs to be fully qualified. The JMX object name is
used to register the MBean at the MBean server. It has to be compliant with the
notation of a java.management.ObjectName (e.g. domain: key1 = value1 , key2
= value2). The sample below shows the respective configuration entry for the
LoggerAdministrationMBean, provided by the core cartridge.
com.intershop.beehive.core.capi.mbean.LoggingAdmin=com.intershop.enfinity:
name=com.intershop.beehive.core.capi.mbean.LoggerAdministrationMBean,
type=AdministrationMBean
It is possible to replace MBeans of other cartridges by mapping their name to

a different implementation class. The order in which the cartridges are loaded
decides which MBean will be finally registered. The cartridge loaded last wins.
Java Visual VM and JConsole

The Java tools J Visual VM and JConsole are used primarily by Intershop 7
administrators to monitor the system environment (resources consumption,
processes, threads, etc.) for a running installation, as well as displaying attributes
and operations related to Intershop 7 MBeans. While both are included with
Intershop 7 JVisual VM is more powerful and does not tax your resources when run
from within your installation.
NOTE: To enable Java monitoring in an Intershop 7 environment, you need to edit the tomcat.bat
file. Open this file with an editor, scroll down and uncomment the 'JMX Support' properties. Note
the port number as you will need it when specifying the JMX connection for both JConsole and
JVisual VM. This will enable JMX support for all Java applications located on a single Tomcat server
within your Intershop 7 installation.
Open JVisual VM in the Intershop 7 folder located in engine\jdk\bin. Double-click

jvisualvm.exe. Select the 'Add JMX Connection' button from the top, and enter
the <hostname> and <port> of your Tomcat server. You can only view a single
application server, however all VM's on the server are viewable and can be opened
in separate tabs. Right-click the application to open the Overview.
Here you have the tabs Overview, Monitor, Threads, Sampler and MBeans. A
description of each tab is listed below.
• Overview

Here you can see the virtual machine where your application is running and
the Java home folder where the application is located. Here you can also view
system properties.
• Monitor
Here you can see memory and performance, CPU usage, classes loaded and
threads.
• Threads
This tab opens with a view of 'All Threads' on a timeline, and allows you to create
a thread dump to save and analyze later. The drop-down menu allows you to
see 'All', 'Live', 'Finished' and 'Selected' application threads.
• Sampler
Sampler provides you with a profile of your application performance. You
can generate graphs for specific threads, as well as see the objects that are
consuming system resources.
• MBeans
This tab allows you to view all MBeans registered with the platform MBean
server. As Administrator, you will be primarily concerned with monitoring and
performing operations for the following:
• Under com.intershop.enfinity, you can view the attributes of and monitor
application MBeans, view the attributes of cartridge MBeans and via
ClearableCaches view and perform operations on the ORM, Object and
PageCache MBeans.
• Under oracle.ucp.admin and oracle.ucp.admin.UniversalConnectionPoolMBean
you can view attributes and perform operations on the Intershop 7 Oracle
database pool connections.
When you select an MBean and view the attributes, where the value is bold, you can
double-click the value and it is shown as a graph or chart. For example, some cache
MBeans allow you to view the number of cache hits for a particular resource.
Open JConsole in the Intershop 7 folder located in engine\jdk\bin. Double-click
jconsole.exe. JConsole automatically monitors the VM on the Tomcat server in
which the application is opened. You can connect to a different host at any time by
selecting 'Connection | New Connection' and entering the neccesary information.
The table below lists the tabs and the monitoring options:
Table 62. JConsole Tabs
Tab Monitoring Focus

Overview Here you can see Heap Memory Usage, Threads, Classes loaded and CPU
Usage graphs for the Tomcat server where your application is running. You
can select a Time Range (12 hours, 1 day, 7 days, etc.) from the drop-down
(or by right-clicking any of the objects) in the application window.
Memory The memory tab allows you to see charts (change the displayed information
in the drop-down at the top) displaying memory use versus time and
specific memory pools. You can also view specifics in the 'Details' window.
Threads Here you can see the current, highest number, live daemon threads as well
as the total number of application threads. Select the thread you want to
view from the 'Threads' window in the bottom-right of the application

Tab Monitoring Focus

window. Garbage Collection is available in the upper right of the application
window (see Note).
Classes View the number of 'Loaded Classes' in chart form for the selected 'Time
Range'.
VM Summary This tab displays the Uptime (total amount of time since the JVM was
started), process CPU (total amount of CPU time), and the time spent in JIT
compilation.
MBeans Shows all registered MBeans. When you select an MBean in the tree, its
attributes, operations, notifications and other information is displayed on
the right. Display a chart of an attribute's value versus time by double-
clicking on the attribute value.
NOTE: Garbage collection (GC) the process of releasing memory used by objects no longer being
referenced and can have dramatic effects on performance. See Oracle JConsole documentation
for more details.
Intershop 7 Sample MBeans

Intershop 7 already exposes a variety of resources through a set of pre-defined
MBeans, making it possible to monitor important parts the system using JMX
management applications. With the current release, MBeans are included with the
cartridges core and monitor. Mbeans provided by these cartridges are contained in
the package com.intershop.beehive.<cartridge_name>.capi.mbean. See the JavaDocs
installed by Intershop 7 for these cartridges (in <IS.INSTANCE.DIR>/share/system/
cartridges/<cartridge_name>/release/docs/api) for details on the attributes and
operations exposed by the MBeans. A summary is provided in the following table.
Table 63. Intershop 7 sample MBeans
Cartridge MBean Interface Description

core DatabaseDriverInformation Drivers (oracle.jdbc.driver.OracleDriver,
MBean com.ibm.db2j.jdbc.EmbeddedDriver) Pool
size, connection count
core LoggingAdminMBean Enabled log scopes. Operations to remove or
add log scopes.
core OracleDataSourceInformation General data source informationOracle
MBean connection cache information
core ORMCacheInformationMBean General information about the OR Mapping's
persistent object cache
core ORMCacheInformationObject Information on individual persistent objects
MBean (e.g., number of instances in cache, default
reference type, etc.)
core JobsMBean Used to handle jobs.
core PipelinesMBean Used to reload pipelines via JMX.
monitor ProcessInformationMBean Process information (general process
information, Web front service information,
important environment variables), resource
usage (CPU usage, total process size, in-
memory size; used system threads) JVM
resource usage (total heap size, used heap
size), threads (thread group, name, thread

Chapter 3: System Management Installation Maintenance
Cartridge MBean Interface Description

name, priority, daemon, alive), system
properties
monitor SessionRequestInformation Session persistence enabled, number of
MBean active sessions, average number of sessions
per day, total number of requests, etc.
NOTE: For detailed information on the resources that are instrumented by the MBeans, you
need to inspect the MBeans using a JMX management application such as MX4j HTTP Adaptor or
MBeansInspector.
Installation Maintenance
Using the SMC Installation Maintenance module, the system administrator can
collect vital information about the Intershop 7 system and transfer it to Intershop
Support.
Access and Navigate the Installation Maintenance Module

To enter the Installation Maintenance module, select Installation Maintenance from
the SMC navigation bar. This opens the overview page, which lists the available
tasks and allows for accessing the corresponding managers.
Figure 33. Installation Maintenance overview
The following managers are available:

n Cluster Information
Allows for compiling basic system information upon server start or at runtime
("snapshots").
n Dump Generation
Allows for creating thread dumps and heap dumps.
n Information Files
Allows for managing the generated information files and sending them to
Intershop Support.
Generating Cluster Information Reports

Using the Cluster Information manager, system administrators can compile basic
system information reports for selected servers. The report generation can be
configured to be executed upon server start, or can be manually triggered at any
time when the application is running ("snapshots"). The following tables list the
corresponding information that is available for each report type.

Installation Maintenance Chapter 3: System Management
Table 64. Startup information
Information Type Description

Application Server Information Application server name, IP, port and existing server
groups
Application Software Information Intershop 7 version number and product ID
Operating System Operating system name and version
Java Java environment version
Loaded Cartridges Name, path and version of the loaded cartridges
Database Basic database information like server name, port and
user.
JDBC Driver Loaded JDBC driver version
License Key License key information
Table 65. Snapshot information
Information Type Description

Application Server Process Basic values like RAM usage, CPU usage, disc space
ORM Cache Detailed information about loaded persistent objects
JVM Resources JVM heap usage information
Threads Detailed information about active threads
Properties All used properties with current values
Loaded Pipelets Loaded pipelets with package structure (Be aware that
this operation might need considerable resources and
time to process.)
Locking Conflicts Processes that tried to lock the same resource in parallel
To generate a cluster information report:

1. In the SMC Navigation Bar, open Installation Maintenance|Cluster
Information.
The Cluster Information detail page is displayed.
2. Open either the Startup tab or the Snapshot tab.
Reports configured on the Startup tab will be generated upon server start,
whereas reports configured on the Snapshot tab are intended to be generated
manually.
3. In the Application Server section, select the intended application server(s).
Mark the corresponding checkbox(es), then click Apply.
4. In the Information section, select the required information type(s).
Mark the corresponding checkbox(es), then click Apply. For details about the
available information types, see the tables above.
5. For snapshot reports, click Create Snapshot.
The snapshot report is generated immediately. Configured startup reports are
generated upon the next server start.
NOTE: Some cluster information options (ORM Cache, Loaded Pipelets, Locking Conflicts) may be
time and ressource consuming and may impact the system performance. They should be enabled
only if the information is crucial to the system maintenance.

The generated report information files are available in the Information Files
manager. For further details, see Managing Information Files.
Generating Java Dumps

Using the Dump Generation manager, system administrators can create memory
dumps for selected servers, namely thread dumps and heap dumps. The next table
lists the information that is available for each dump type.
Table 66. Dump information
Information Type Dump Type Description

Locked Monitors Thread dump Includes information about locked monitors
Locked Synchronizers Thread dump Includes information about locked
synchronizers
Live Objects Heap dump Includes information about live objects, i.e.,
objects that are accessible by other objects
To generate a memory dump:

1. In the SMC Navigation Bar, open Installation Maintenance|Dump
Generation.
The Dump Generation detail page is displayed.
2. Open either the Threaddump tab or the Heapdump tab.
3. In the Application Server section, select the intended application server(s).
Mark the corresponding checkbox(es), then click Apply.
4. In the Information section, select the required information type(s).
Mark the corresponding checkbox(es), then click Apply. For details about the
available information types, see the table above.
5. Click Create Threaddump or, respectively, Create Heapdump.
The corresponding memory dump is generated immediately.
NOTE: Depending on the JVM size, generating a heap dump will hold the system for some time
and requires an according amount of free disc space. Intershop recommends to create heap dumps
sequentially if several application servers are involved.
The dump files are created in a VisualVM-compatible format, which allows for
a convenient visual representation of the dump data. The generated files are
available in the Information Files manager. For further details, see Managing
Information Files.
Managing Information Files

Using the Information Files manager, system administrators can view and
download the generated report and dump files, as well as e-mail them to Intershop
Support.
NOTE: Sending information files via e-mail requires a properly configured server for outgoing mail
(intershop.SMTPServer in appserver.properties).

Installation Maintenance Chapter 3: System Management
Figure 34. Information Files manager
Viewing and Downloading Files

To view or download generated report or dump files:
1. In the SMC Navigation Bar, open Installation Maintenance|Information
Files.
This opens the Information Files detail page, displaying a list of generated files.
2. In the row of the intended file, click View or, respectively, Download.
The file is displayed in the SMC window, or, respectively, the browser's
download dialog is opened, prompting you to save the file.
E-Mailing Files
To e-mail generated report or dump files:
1. In the SMC Navigation Bar, open Installation Maintenance|Information
Files.
This opens the Information Files detail page, displaying a list of generated files.
2. Select the file(s) to be e-mailed.
Mark the corresponding checkbox(es).
NOTE: Larger files cannot be sent by e-mail and therefore cannot be selected. The
corresponding limit is controlled by the property intershop.mail.attachment.maxsize
in cluster_information.properties.
3. Click Send.
This opens the e-mail dialog as illustrated in the figure below.

Figure 35. E-mailing an information file
4. Specify the intended e-mail recipient(s).

Select either a preconfigured recipient, i.e., the team EMEA or the team US
of Intershop Support, or specify a particular recipient. Furthermore, you can
specify additional recipients using the CC and BCC fields.
5. In the Message section, specify an e-mail subject and edit the message text
as necessary.
If you refer to an existing support case, use the corresponding case ID as
subject.
NOTE: You can remove an attached file from the e-mail through clicking Remove next to the
intended file.
6. Click Send E-Mail.

The e-mail including the attached information file(s) is sent to the specified
recipient(s).

Chapter 4
Reference
Appendix A: Command Line Tools and Scripts

This section lists the commonly used command line tools and scripts that are
provided with Intershop 7.
Table 67. Intershop 7 command line tools and scripts
Tool/Script Location Description

dbinit.sh | bat <IS.INSTANCE. Executes the database initialization process.
DIR>/bin/ The switch -is.share allows for using an
optional ISF.
dbmigrate.sh | bat <IS.INSTANCE. Executes the database migration process. The
DIR>/bin/ switch -is.share allows for using an optional ISF.
dbtool.sh | bat <IS.INSTANCE. Intended to start Oracle database tools like
DIR>/bin/ SQL Plus without having to enter the database
password in the command line. It retrieves the
password from <IS.INSTANCE.SHARE>/system/
config/cluster/orm.properties and passes it
to the stdin of the respective Oracle database
tool. The name of the password property can
be specified as a parameter, but defaults to
intershop.jdbc.password. The switch -is.share
allows for using an optional ISF.
eserver#-ase /etc/init.d/ Instance-specific scripts to start individual
components (Intershop Application Server,
eserver#-httpd
Web server, Web Adapter agent) of an
eserver#-waa Intershop 7 instance (Linux only).
eserver# /usr/bin/ Instance-specific script to start or stop all
components of an Intershop 7 instance (Linux
only).
encode_password.sh | bat <IS.INSTANCE. Encodes passwords for Tomcat users. Must
DIR>/bin/ be run when a new user for the Tomcat
Cluster Management Console is to be added
in <IS.INSTANCE.SHARE>/system/tcm/config/
users.xml.
environment.sh | bat <IS.INSTANCE. Sets the Intershop 7 environment, i.e.,
DIR>/bin/ the needed Intershop 7, Oracle, Java and
Ant system variables as well as PATH and
LD_LIBRARY_PATH. This script is automatically
executed with other Intershop 7 command
calls.

Chapter 4: Reference Command Line Tools and Scripts

INTERSHOP_perm.sh <IS.INSTANCE. Sets file permissions and ownerships of files
DIR>/bin/ and directories in the Intershop 7 instance
for the isas# and iswa# users (Unix only). This
script is automatically executed upon installing
Intershop 7 and should be run manually only
in case of replacing components in an existing
Intershop 7 instance, for example, to update
the permissions for a new license file or a new
JDK.
isclc.sh | cmd <IS.INSTANCE. Starts an Intershop 7 import process or any
DIR>/tools/clc/ configured job from the command line, see
Command Line Client.
isservice.exe <IS.INSTANCE. Starts the Win32 service "Intershop 7
DIR>/bin/ Application Server (#)", i.e., starts the
Intershop 7 Node Manager in background
mode (Windows only).
nodemanager.sh | bat <IS.INSTANCE. Starts the Intershop 7 Node Manager. The
DIR>/bin/ Node Manager then starts the application
server processes as defined in its configuration
(in <IS.INSTANCE.DIR>/engine/nodemanager/
config/nodemanager.properties). This script
is used internally by the Intershop 7 start/stop
script. NOTE: You should use nodemanager.sh
only for development or debugging purposes.
To start the Intershop 7 instance for normal
operation, use /etc/init.d/eserver or, on
Windows, the Win32 service "Intershop 7
Application Server (#)".
nodemanager_start.sh | <IS.INSTANCE. Starts the Intershop 7 Node Manager in
start_intershop.bat DIR>/bin/ background mode. The Node Manager
then starts the application server
processes as defined in its configuration (in
<IS.INSTANCE.DIR>/engine/nodemanager/
script.
nodemanager_stop.sh | <IS.INSTANCE. Stops a background Intershop 7 Node
stop_intershop.bat DIR>/bin/ Manager and thus, the application server
processes as defined in its configuration (in
<IS.INSTANCE.DIR>/engine/nodemanager/
script.
notUsableIndexes.sh | bat <IS.INSTANCE. Lists and, optionally, deletes all unused
DIR>/bin/ (redundant) indexes in the Intershop 7
database.
tomcat.sh | bat <IS.INSTANCE. Starts an instance of the Tomcat application
DIR>/bin/ server. This script is used internally by the
Intershop 7 Node Manager.
waa.sh | cmd <IS.INSTANCE. Starts the Intershop 7 Web Adapter agent. The
DIR>/ Web Adapter agent is primarily responsible
webadapter/bin/ for the selective page cache deletion and
the deletion of outdated page caches. This
script is used internally by the Intershop 7

Command Line Tools and Scripts Chapter 4: Reference

start/stop script /etc/init.d/eserver. NOTE: You
should use waa.sh only for development or
debugging purposes. To start the WAA for
normal operation, use /etc/init.d/eserver or,
on Windows, the Win32 service "Intershop
Intershop 7 Webadapter Agent (#)".
waa_env.sh | cmd <IS.INSTANCE. Sets the environment for the Web Adapter
DIR>/ agent. This script is used internally by the WAA
webadapter/bin/ start/stop scripts.
WA-AgentService.exe <IS.INSTANCE. Starts the Win32 service "Intershop 7
DIR>/ Webadapter Agent (#)", i.e., starts the
webadapter/bin/ Intershop 7 Web Adapter agent in background
mode (Windows only).
watchdog_waa_start.sh <IS.INSTANCE. Starts the Intershop 7 Web Adapter agent in
DIR>/ background mode (Unix only). This script is
webadapter/bin/ used internally by the Intershop 7 start/stop
script.
watchdog_waa_stop.sh <IS.INSTANCE. Stops a background Intershop 7 Web Adapter
DIR>/ agent (Unix only). This script is used internally
webadapter/bin/ by the Intershop 7 start/stop script.
ant clean-localize <IS.INSTANCE. Cleans localized and generated cartridge
DIR>/tools/misc/ templates.
ant clean-localize- <IS.INSTANCE. Cleans localized generated cartridge
generated DIR>/tools/misc/ templates.
ant clean-pagecompile <IS.INSTANCE. Cleans the pagecompile directory of all
DIR>/tools/misc/ cartridges and sites.
ant dbextract <IS.INSTANCE. Extracts table, index and constraint structures
DIR>/tools/misc/ from the Intershop 7 database schema.
ant dbextract_sources <IS.INSTANCE. Extracts PL/SQL sources of the current schema.
DIR>/tools/misc/
ant disable-foreign-keys <IS.INSTANCE. Disables all foreign keys in the database.
DIR>/tools/misc/
ant enable-foreign-keys <IS.INSTANCE. Enables all foreign keys in the database.
DIR>/tools/misc/
ant export <IS.INSTANCE. Exports the content of the Intershop 7
DIR>/tools/misc/ database to a dump file.
ant exportandfixts <IS.INSTANCE. Exports the database content and fixes the
DIR>/tools/misc/ tablespace name within an Oracle dump
export file.
ant fixts <IS.INSTANCE. Fixes the tablespace names within an Oracle
DIR>/tools/misc/ dump export file.
ant import <IS.INSTANCE. Imports a database dump file into the
DIR>/tools/misc/ Intershop 7 database.
ant localize <IS.INSTANCE. Localizes templates.
DIR>/tools/misc/
ant precompile <IS.INSTANCE. Precompiles all templates which have not
DIR>/tools/misc/ been precompiled before or whose ISML files
have been modified. The switches -Dis.share
and -Dis.target allow for using an optional ISF
or IS_TARGET, respectively.

Chapter 4: Reference Summary of Placeholders

ant recreate-ctx-indexes <IS.INSTANCE. Recreates all context indexes in the database.
DIR>/tools/misc/
ant ssh_keygen <IS.INSTANCE. Generates the key pair needed for SSH transfer
DIR>/tools/misc/ of the report cartridge.
ant test <IS.INSTANCE. Starts the eTest runner.
DIR>/tools/misc/
ant uuid <IS.INSTANCE. Generates a UUID that can be used as a
DIR>/tools/misc/ primary key for a persistent object.
NOTE: For all Ant task targets defined in <IS.INSTANCE.DIR>/tools/misc/build.xml, the switch -
Dis.share allows for using an optional ISF.
Appendix B: Summary of Placeholders

This chapter deals with the placeholders used by the Intershop setup program for
installing Intershop 7, and provides a brief explanation (# refers to the number of an
Intershop 7 instance):
NOTE: Some placeholders exist only on one platform (see the <IS.INSTANCE.DIR>/log/
placeholders.log file, for more information).
The following tables list the placeholders used by the Intershop 7 setup program.
Note that # is used as placeholder to denote the number of the Intershop 7
instance.
Table 68. Operating system-relevant placeholders
Placeholder Meaning Default Value

<IS_OS_PLATFORM> States the operating system
type and version
<SYSTEM.AS.USER> Application server user name isas#
<SYSTEM.AS.USER.ID> ID of the application server 3200 + 2 * (#-1)
user
<SYSTEM.AS.USER.HOMEDIR> Home directory of the
application server user
<SYSTEM.WA.USER> Web Adapter user name iswa#
<SYSTEM.WA.USER.ID> ID of the Web Adapter user 3201 + 2 * (#-1)
<SYSTEM.WA.USER.HOMEDIR> Home directory of the Web
Adapter user
<SYSTEM.IS.GROUP> Group name of an Intershop 7 isgrp#
system group
<SYSTEM.IS.GROUP.ID> Group ID of the Intershop 7 3200 + 2 * (#-1)
system group
<ORACLE.CLIENT.DIR> Oracle Home, installation
directory of the Oracle Client
Table 69. Intershop instance-relevant placeholders

<IS.INSTANCE.DIR> Physical directory of an
Intershop 7 instance

Tomcat and Node Manager Settings Chapter 4: Reference

<IS.INSTANCE.LINK> UNIX link to the instance
<IS.INSTANCE.ID> Number of the Intershop 7
instance
<IS.INSTANCE.SHARE> Intershop Shared Files path.
When using a remote ISF: path
to the mount target (e.g., /
mnt/host2_share)
<IS.INSTANCE.SHARE.HOSTID> ID of the host with the ISF <host_name>_ES#
Table 70. Application server-relevant placeholders

<IS.AS.HOST.NAME> Fully-qualified host name of <host_name>
the application server
<IS.AS.HTTP.PORT> TCP port of the Intershop 7 10054 + ((#-1)*50)
application server
Table 71. Web server-relevant placeholders

<IS.WS.HOST.NAME> DNS host name of the Web <host_name>
server
<IS.WS.HOST.HTTPSPORT> TCP/IP port of the Web 443 - 1 + #
server used for HTTPS
communication
<IS.WS.HOST.PORT> TCP/IP Web server port 80 - 1 + #
<IS.WA.SHMKEY> Shared memory key
for Apache Web Server
(hexadecimal value)
Table 72. Database-relevant placeholders

<DB.DOMAIN> Oracle database domain world
<DB.HOSTNAME> Fully-qualified host name of
the database server
<DB.LISTENER.PORT> Listener TCP/IP port of the 1521
database server
<DB.NAME> Name of the database isdb1
instance
<DB.SID> Oracle database server ID ISORCL1
Appendix C: Tomcat and Node Manager Settings

This section addresses specific administration issues with respect to the Apache
Jakarta Tomcat application server.

Chapter 4: Reference Tomcat and Node Manager Settings
Big Picture
The Apache Jakarta Tomcat application server makes the operating environment
for all Intershop 7 applications. The application server comes out of the box with
Intershop 7 and is installed with every Intershop Application Server.
The Node Manager is a standalone Java program that is used to control all server
processes in an Intershop 7 instance. The Node Manager starts, stops and (in case of
abnormal process termination) restarts application server processes. In addition, it
provides the communication interface for the Tomcat Cluster Management Console
(TCC) that is used for remote control purposes (see Cluster Management).
The Node Manager and the Tomcat Cluster Management Console interact starting
and managing the Tomcat application server processes, and when checking
the cluster state. The figure below illustrates the interaction using a distributed
installation as an example.
Figure 36. Tomcat cluster management overview
n Startup (1)
The Node Manager starts the Tomcat server processes (and thus, the application
on top of them) as configured. It monitors the servers permanently to restart
them when necessary. See Node Manager Configuration.
n Application and Process Management (2), (3)
To shut down a remote server or to control application on a remote server, the
TCC communicates to the remote TCC, which then fulfills the request in the local
server instance (2).
To get a list of all remote server instances and their state or to terminate a
remote server, the TCC communicates to the responsible Node Manager, which
then executes the requested operations (3).
n Cluster State (4)
TCCs and Node Managers send out heartbeat information (including name,
host, port) via event messaging (multicast by default - see Event Settings). In

addition, each TCC evaluates incoming heartbeats. This way, it gets the required
information about the available server instances in the entire cluster, and on
how to contact a remote TCC or Node Manager for application and progress
management.
Shared Cluster Management Settings

For the communication and remote management to work, the TCCs and the Node
Managers must share the event messaging settings and the user database.
• Settings necessary for cluster-wide management are stored in the common
configuration file tcm.properties and the user database users.xml, located in
<IS.INSTANCE.SHARE>/system/tcm/config.
• Additional, instance-specific configuration information is read from the
configuration file tcm.properties located in <IS.INSTANCE.SHARE>/system/tcm/
config/local/<IS.AS.HOSTNAME>/<IS.INSTANCE.ID>. For more information, see
Local Cluster Management Settings.
The following table lists the required settings in tcm.properties that the TCC and the
Node Manager use for cluster-wide management.
Table 73. Cluster management settings
intershop.tcm.event. Specifies the messenger class to be used, the default
messengerClass is com.intershop.beehive.messaging.internal.multicast.
MulticastMessenger.
intershop.tcm.event. Defines the group address used for multicast messaging.
multicastAddress
intershop.tcm.event.multicastPort Defines the event distribution port for multicast
messaging.
intershop.tcm.event. Defines the number of handler threads to process
multicastListenerThreads incoming events. The default value is 5.
intershop.tcm.registration. Defines the interval (in seconds) after which the TCC
registrationTime or Node Manager sends out a heartbeat packet to re-
register with all other TCCs. The default value is 10.
intershop.tcm.registration. Defines the interval (in seconds) after which the TCC
expirationTime unregisters a Node Manager or another TCC if no
heartbeat packets were received. The default value is 50.
intershop.tcm.jmx.protocol Defines the protocol used to transport JMX control
commands to other TCC and node manager instances.
Currently only http is supported.
intershop.tcm.password.digest Defines the algorithm used for TCC user password
encryption (see Add New TCC User). The default value is
MD5.
and adjust the corresponding intershop.tcm.event properties (see Event Settings).
For information on how to change cluster management user settings, refer to Add
New TCC User, and Change the TCC Password. The Event Messaging API description
(Multicast, JMS and JGroups) can be found in the section Event Settings.

Local Cluster Management Settings

In larger installations, it is typically necessary to separate the event messaging
traffic (multicast is the default) between TCC and Node Managers from other traffic.
This can be done by binding multicast messaging to a dedicated network adapter.
If there are multiple network adapters installed on a machine, you can specify the
IP of the network interface to use for multicast messaging as value of property
intershop.tcm.event.multicastInterface. Note that this configuration,
which is machine-specific, is defined in a local configuration file tcm.properties,
located in <IS.INSTANCE.SHARE>/system/tcm/config/local/<IS.AS.HOSTNAME>/
<IS.INSTANCE.ID>. See Event Settings, for discussion of a similar mechanism for
handling multicast communication at application server level.
Node Manager Settings

In addition to the shared and local cluster-wide configuration properties, each Node
Manager reads its local configuration file, which defines the server processes to be
started and the process control options.
Node Manager Configuration

The local Node Manager configuration is defined in the nodemanager.properties file
(in <IS.INSTANCE.DIR>/engine/nodemanager/config/).
NOTE: The location of the nodemanger.properties file can be set as JVM property via the
commandline expression -Dnodemanger.config.dir=<path>.
As one Node Manager controls all server processes in an Intershop 7 instance, these
settings apply to all servers. The following table lists the Node Manager properties
in the nodemanager.properties file.
Table 74. Node Manager properties
network.protocol Defines the protocol to use for communication (default
http).
network.interface Specifies the IP of the network interface to use; by
default, the primary IP is set.
network.port Sets the port for receiving requests from the TCC
(default: 10050). If not set, the Node Manager starts
without communication functionality.
config.update.timeout Defines the interval (in seconds) between two
configuration look-ups to enable configuration changes
at runtime. If not specified or set 0, the Node Manager
reads its configuration once at startup.
The table below lists the properties that can be set for the processes controlled by
the Node Manager.
Table 75. Process properties
process.allowedExitCodes Specifies untreated exit codes of the Node Manager
subprocesses. If a subprocess exits with one of these exit
codes, the Node Manager will not restart it.

process.list Specifies the names of the subprocesses that are
controlled by the current Node Manager instance
(comma separated list), e.g., appserver0,appserver1.
process.<process_name>. Specifies the command line string to start the
command subprocess. This string can include command line
arguments to be passed to the subprocess.
process.<process_name>. autostart A boolean value indicating whether the Node Manager
should start the specified subprocess at startup. The
default value is true. If set false, only the TCC can start
this subprocess.
To pass additional properties to the application server process, either edit the
startup script (this would apply to all server processes) or enter the required
arguments in the command shell when starting a single instance. Additional
properties include specific memory allocation, additional classpaths, etc.
Node Manager Startup Command

As the command line call to start the Node Manager is very complex, a command
line script is used for convenience reasons (nodemanager.sh on Unix platforms,
nodemanager.bat on Windows, located in <IS.INSTANCE.DIR>/bin/).
The startup script performs the following tasks:
• prepares the Node Manager system environment via the environment shell script
• assembles the class path for the watchdog Java process
• starts the Node Manager process
NOTE: Intershop recommends not to change the Node Manager startup scripts.
Once running, the Node Manager starts the Intershop 7 server processes, as defined
in the nodemanager.properties file (see Node Manager Configuration).
NOTE: You should use nodemanager.sh only for development or debugging purposes.
For information on how to start an Intershop 7 instance for normal operation, refer
to the Intershop 7 Installation Guide.
Application Server Configuration

The configuration for each Tomcat instance that runs a specific Intershop 7
instance, is saved in the directory <IS.INSTANCE.DIR>/engine/tomcat/servers/
appserver<ID>/conf.
The default configuration, which is used, for example, when cloning a Tomcat
instance, is stored in <IS.INSTANCE.DIR>/engine/tomcat/servers/_default_/conf.
Application Server Shutdown

The Tomcat application server receives shutdown requests via a dedicated
shutdown port. The default port number for instance ES1 is 10051. However, the
shutdown port can be freely defined.

The string which is used internally to request a shutdown is configured in the

server.xml file. By default, the string is set to SHUTDOWN, as shown below:
<Server port="10051" shutdown="SHUTDOWN">
CAUTION: For security reasons, it is strongly recommended to change the default shutdown
request string in the server.xml file. Otherwise, any local network user can shut down the application
server instance by simply sending the string SHUTDOWN to the respective shutdown port.
Application Server Network Settings

The Apache Jakarta Tomcat provides abundant options for configuring its network
connection. These properties are set in the Tomcat configuration file server.xml
as attributes to the Connector element. The Connector component represents
Tomcat's connection interface for serving HTTP(S) requests.
For detailed information on how to configure the Apache Jakarta Tomcat, refer
to the Tomcat documentation in <IS.INSTANCE.DIR>/engine/tomcat/tomcat_inst/
webapps/tomcat-docs/.
For the purpose of serving Intershop 7, the following options are relevant and may
require customizing:
n Application Server Network Connection
n Keystore Settings for HTTPS
Application Server Network Connection

The TCP port number on which the Tomcat Connector will create a server socket
and await incoming connections is defined by the attribute port. With Intershop 7,
the default application server ports are 10052 for HTTP and 10053 for HTTPS.
The port numbers have to be modified when cloning an application server (for
information on this issue, see the Intershop 7 Installation Guide).
NOTE: In the context of Intershop 7, the TCP port number discussed above are used for
communication with the Tomcat Cluster Management Console. Note that the Web Adapter
routes all requests to its internal JSP and servlet engine, using the port specified by the key
intershop.servletEngine.connector.port. See Servlet Engine Settings.
HTTPS Keystore Settings

The location of the security key for the HTTPS Connector is specified in the attribute
keystoreFile. This attribute gives the absolute path and file name of the keystore
file, the default is
keystoreFile="<IS.INSTANCE.SHARE>/system/tcm/config/keystore"
To edit the key file, you need a password. This password is defined by the attribute
keystorePass, with intershop as default value.
Intershop 7 provides a demo, yet fully functional security key. To prevent warnings
about certificate/IP mismatches, Intershop recommends to create an own key file
for each server.
To edit the existing keystore file, e.g., to create new certificates, use the keytool
program, located in <IS.INSTANCE.DIR>/engine/jdk/bin. For information on
managing keystores using keytool, refer to the JDK documentation.

NOTE: The keystore settings play a role for communication with the Tomcat Cluster Management
Console. They are not relevant to securing your Intershop 7 back office or storefront applications.
For information on these topics, see SSL Support.
Tomcat Logging Options

The Tomcat log files tcc_access_log are stored separately for every server instance in
the Tomcat log directory <IS.INSTANCE.DIR>/engine/tomcat/servers/appserver<ID>/
logs. For information on the log, consult the official documentation of the Apache
Jakarta Tomcat. In the context of Intershop 7, the following log files are relevant:
n EnfinitySuite_log
Tomcat logs all events, warnings and errors that occur when loading the
Intershop 7 application into EnfinitySuite_log. Once loaded and running,
Intershop 7 writes its own log files, see Application Logging.
n tcc_log
Tomcat logs all events, warnings and errors that occur when executing the
Tomcat Cluster Management Console (see Cluster Management) into tcc_log.
Cluster Management
The Tomcat Cluster Management Console (TCC) is a standalone Web frontend
application used to administer the Intershop 7 server cluster. It provides a graphical
user interface for controlling all application server instances, as well as the
applications on top of them, running in the cluster.
Access the Cluster Management Console

As the Tomcat Cluster Management Console is independent of Intershop 7, it
cannot be accessed by an Intershop 7 user as the Intershop 7 applications.
To access the cluster management application:
1. In a Web browser, open the following URL:
http://<SYSTEM.HOST>:<IS.TC.HTTP.PORT>/tcc
where <SYSTEM.HOST> is either the IP or DNS name of the machine hosting

Intershop 7, and <IS.TC.HTTP.PORT> is the Tomcat communication port (either
HTTP or HTTPS) as specified in the file server.xml, located in the directory
<IS.INSTANCE.DIR>/engine/tomcat/servers/appserver<ID>/conf/. The installation
default ports are 10052 (HTTP) and 10053 (HTTPS).
The cluster management login page is displayed.
2. Log in using the following credentials:
• Login: admin
• Password: !InterShop00!
NOTE: When you log in to the cluster management module for the first time, you should
change your password. See Change the TCC Password.

General Overview
After logging in, the cluster overview page is displayed. It contains links to the
Servers and Applications modules that allow for managing the Intershop 7 cluster.
Figure 37. TCC Cluster overview
Change the TCC Password

At the first login, you should change your password for the TCC.
NOTE: The user name is always admin and cannot be changed.
To change the password:

1. Click Change Password on the upper right navigation bar.
The Change Password page appears.
Figure 38. Changing the password for the TCC
2. Enter your old password in the Old Password field.

3. Enter a new password in the New Password field.
To rule out typos, re-enter the new password in the Confirm Password field.
4. Click OK.
Your password has now been changed.
Add New TCC User

Creating a new user for the TCC involves two basic steps:
• Adding the user to the user list (<IS.INSTANCE.SHARE>/system/tcm/config/
users.xml)
• Creating a password using the encode_password script (in <IS.INSTANCE.DIR>/
bin)
To create a new TCC user:

1. Open users.xml for editing.
2. Copy the entire <user ... /> line.
3. Specify a new user name.

Enter the new user name as value for the attribute username.

4. Create and encode a password for the new user.

In a command line, enter
encode_password <MD5|SHA> <cleartext_password>
5. Add the new password to users.xml.

Copy the string returned by encode_password as value for the password
attribute.
Log Off From the TCC

To close the TCC, click Logoff on the upper right navigation bar. The current session
is terminated, and the Logon dialog will be displayed.
Control Server Processes

Controlling server processes involves starting, stopping, restarting or terminating
the entire server processes. This functionality is provided in the Servers module.
Access the Servers Module

Access the Servers module either by clicking Servers in the Cluster overview
(General Overview), or by selecting Servers from the navigation bar.
Figure 39. TCC Cluster Servers module
This page displays a "snapshot" of all available servers in the current Intershop 7
cluster and provides the information described in the table below.
Table 76. Cluster Overview Columns
Column Information
Server Displays the name of the application server instances.
Host Displays the fully qualified DNS name of each server's host machine.
Port Indicates the port on which each server is running.
Start Date Indicates the start date and time for each server.
Status Shows the status of each server, e.g., Starting, Running, or Stopped.
Server Control Options

To apply server control functions to an individual server, select its corresponding
checkbox and click one of the buttons below the server list. The available buttons
and their functions are described in the table below.
Table 77. Server control buttons
Button Function
Refresh Refreshes the screen contents displaying, e.g., a new server state.
Restart Stops the execution of the selected server, then starts it.

Button Function
Start Sends an HTTP request to the Node Manager to trigger the startup
command for the selected server.
Stop Sends an HTTP request to the selected server to stop it via a controlled
shutdown. The server shuts down any subprocesses and stops
executing.
Terminate Sends an HTTP request to the Node Manager to trigger a "kill"
command to be sent to the selected server. This command can be
used to terminate a frozen server process. It is usually not needed in
normal operation.
Create or Delete Server Processes

On multiprocessor machines, you can easily clone an application server process.
Thus, you can increase the performance of your Intershop 7 system without having
to install an entire Intershop Application Server.
NOTE: Make sure that the server hardware resources allow for cloning an application server.
The Tomcat Cluster Management Console (TCC) provides a convenient graphical

user interface for creating or deleting application server processes.
CAUTION: With multiple application servers, you must enable the cache synchronization to make
sure that the applications deliver consitent data. For details about these settings, refer to PO Cache
Synchronization Settings.
Creating a New Server

To create an additional application server process:
1. Open the TCC Servers module.
Either select Servers in the navigation bar, or click the Servers link in the
overview page.
2. Click New.
The New Server Instance page is displayed.
Figure 40. Creating a new application server process
3. Enter all values as needed and mark the Autostart checkbox if required.
The following table lists the recommended port scheme.

Table 78. Recommended server process ports
Intershop 7 AS Instance Port Description

Instance
ES1 10050 Node Manager port
appserver0 10051 Tomcat shutdown port
10052 Tomcat HTTP port
10053 Tomcat HTTPS port
10054 Intershop 7 port
ES2 10100 Node Manager port
4. Click Create.
The new server instance, i.e., the appserver<#> directory in <IS.INSTANCE.DIR>/
engine/tomcat/servers, is created; and the Node Manager properties are
updated accordingly.
5. Enable the cache synchronization.
In <IS.INSTANCE.SHARE>/system/config/cluster/orm.properties, remove the
comment character # from
#intershop.cacheSync.multicastAddress=239.1.0.0
#intershop.cacheSync.port=1111
and specify valid channel and port numbers. For details about these settings,
refer to PO Cache Synchronization Settings.
6. Propagate the new server instance to the Web adapter's configuration
service.
In <IS.INSTANCE.DIR>/webadapter/webadapter.properties, add the access URL
of the new application server's configuration servlet to the # configuration
service section, for example:
cs.url.0=http://<SYSTEM.HOST>:10054/servlet/ConfigurationServlet
cs.url.1=http://<SYSTEM.HOST>:10064/servlet/ConfigurationServlet
For details about these settings, refer to Configuration Servlets.

Deleting a Server
To delete an application server process:
overview page.
2. Select the application server you intend to delete.
Mark the checkbox next to the server process to select it.
NOTE: Make sure that the server process is stopped before trying to delete it.
3. Click Delete and confirm the removal when prompted.

The selected server instance, i.e., the appserver<#> directory in
<IS.INSTANCE.DIR>/engine/tomcat/servers, is removed; and the Node Manager
properties are updated accordingly.
Control Applications
Controlling applications involves starting, stopping, or reloading them. This
functionality can be applied either to only those applications that run on top of
an individual server instance or globally to all applications in the cluster. The table
below lists the available options.
Table 79. Application control buttons
Button Function
Refresh Refreshes the screen contents displaying, e.g., a new application.
Start Sends an HTTP request to the server(s) to start the selected application.
Stop Sends an HTTP request to the server(s) to stop the selected application.
Reload Sends an HTTP request to the server(s) to stop and restart the selected
application.
Use these commands to restart a single application without restarting the entire
server process. This may be necessary during application development or when
changing the configuration.
Server-Specific Application Control

To manage applications in a specific server instance:
overview page.
2. In the Servers list view, click the name of the server whose applications you
intend to manage.
The applications running in the selected server are displayed in a list view.

Figure 41. Control applications in a single server instance
3. Select an application and click the required control button.

Mark the corresponding checkbox and apply one of the controls listed in
Control Applications (Start, Stop or Reload).
NOTE: As your current session is the TCC application, it cannot be selected.
Cluster-Wide Application Control

To globally manage applications in the cluster:
1. Open the TCC Applications module.
Either select Applications in the navigation bar, or click the Applications link in
the overview page. A list of all applications running in the cluster is displayed.
Figure 42. Control applications in the entire cluster
2. Select an application and click the required control button.

Mark the corresponding checkbox and apply one of the controls listed in
Control Applications (Start, Stop or Reload).
NOTE: As your current session is the TCC application, it cannot be selected.
Managing Tomcat Server Instances Across Intershop 7 Clusters

In complex deployments involving multiple Intershop 7 clusters, it may be desirable
to manage Tomcat server processes from different Intershop 7 clusters in a single
TCC. For example, consider a data replication scenario with source system and a
target system. Being part of different Intershop 7 clusters, source and target system
access separate Intershop Shared Files instances.
In a standard setup, the TCC configuration files are also separate, as they reside
in the respective Intershop Shared Files area of cluster 1 and cluster 2. Using the
Intershop 7 environment variable IS_TCM_SHARE, defined in the intershop.properties
file below <IS.INSTANCE.HOME>, both clusters can be forced to use the same set of
configuration files. As a consequence, the Tomcat server instances can be managed
from the same TCC.

Chapter 4: Reference Command Line Client
Figure 43. Sample scenario with two Intershop 7 clusters accessing joint TCC configuration files
For different clusters to use the same TCC configuration files, the IS_TCM_SHARE
variable in the intershop.properties file of each instance has to point to the same
location.
Figure 44. Managing server instances from different Intershop 7 clusters in the same TCC
NOTE: You can use any Tomcat server instance to connect to the TCC, using the instance's Tomcat
HTTP port (e.g., port 10052). In larger deployments, consider using a dedicated Tomcat server
instance which serves administrative purposes only and does not run the Intershop 7 application.
Intershop 7 Command Line Client

Intershop 7 provides a command-line client (CLC) that can trigger pre-configured
jobs and run import processes. The command-line client, isclc.sh|cmd as installed in
<IS.INSTANCE. DIR>/tools/clc/, is self-contained, that is, it does not require any other
parts of the Intershop 7 instance. The CLC can be copied to and run from any other
machine with a JRE installed. (Note that the CLC is also prepared to be wrapped in
ANT tasks. If you intend to do so, ANT is also required on the client's machine.)
Executing isclc.sh|cmd without additional parameters returns the two command
options that are enabled by default:
Expected command as first parameter. Known commands are:
runjob
import
NOTE: On a project-specific base, the Intershop 7 CLC can be enhanced to support additional
tasks. For detailed information, refer to the corresponding concept document on the Intershop
Knowledge Base.
Running Jobs
To use the Intershop 7 CLC for running pre-configured jobs, the basic call is
isclc.sh|cmd runjob

Command Line Client Chapter 4: Reference
Executing this without additional parameters returns the parameter overview for
the runjob task. The following table lists the available parameters.
Table 80. CLC parameters for running jobs
Parameter Mandatory Description

-domain, -d yes The domain to which the job belongs.
-help, -? no Display usage. Default: false.
-host, -h yes The target system. Format: IP_or_Name[:Port].
-interval, -i no If waiting until finished, poll every <n> seconds. Default: 1.
-job, -j yes The job that should be started.
-login, -l no The user name of the user under whose permissions the job
is to be executed. Default: admin.
-password, -p yes The password of the user under whose permissions the job is
to be executed.
-servergroup, -g no The server group at the target system. Default: BOS.
-wait, -w no Wait until finished. Default: true.
Using these parameters, a complete call may look like this (all in one line):
isclc.sh runjob -d root -h 10.0.25.3
-j AnalyzeDatabaseSchema -l admin -p \!InterShop00\!
You may also call the parameters via a prepared plain text file:
isclc.sh runjob @AnalyzeDB.parameters
with AnalyzeDB.parameters listing the parameters:

-d
root
-h
10.0.25.3
-j
AnalyzeDatabaseSchema
-l
admin
-p
\!InterShop00\!
Running Imports
To use the Intershop 7 CLC for running import processes, the basic call is
isclc.sh|cmd import
Executing this without additional parameters returns the parameter overview for
the import task. The following table lists the available parameters.
Table 81. CLC parameters for triggering imports

-channel, -c yes The channel handling the import.
-filename, -f yes The name of the file (on the Intershop 7 server) to import.
-help, -? no Display usage. Default: false.
-host, -h yes The target system. Format: IP_or_Name[:Port].

Chapter 4: Reference Enabling Optional Components

-interval, -i no If waiting until finished, poll every <n> seconds. Default: 1.
-locale, -lc no The locale to be used for the import. Default: en_US.
-login, -l no The user name of the user under whose permissions the job
is to be executed. Default: admin.
-organization, -o yes The organization's site name.
-password, -p yes The password of the user under whose permissions the job is
to be executed.
-servergroup, -g no The server group at the target system. Default: BOS.
-type, -t yes The type of object to be imported, e.g., product.
-unit, -u yes The unit the file should be imported to.
-wait, -w no Wait until finished. Default: true.
Using these parameters, a complete call may look like this (all in one line):
isclc.sh import -h 10.0.25.3 -l admin -p \!InterShop00\!
-o PrimeTech-Site -c PrimeTechSpecials
-u PrimeTech-PrimeTechSpecials -t product
-f test_product1-update.xml -lc de_DE
You may also call the parameters via a prepared plain text file:
isclc.sh import @testimport.parameters
with testimport.parameters listing the parameters:

-h
10.0.25.3
-l
admin
-p
\!InterShop00\!
-o
PrimeTech-Site
-c
PrimeTechSpecials
-u
PrimeTech-PrimeTechSpecials
-t
product
-f
test_product1-update.xml
-lc
de_DE
Appendix E: Enabling Optional Components

This section outlines additional administrative tasks with respect to optional
Intershop 7 features and components. These include:
n Intershop Studio
This sections outlines how to obtain Intershop Studio, Intershop 7's integrated
development environment.
n Web Analytics Services
This section outlines how to set up the WebTrends business reporting for your
Intershop 7 system.

Enabling Optional Components Chapter 4: Reference
n eCircle E-Mail Marketing

This section describes how to activate eCircle messaging as an online marketing
method in Intershop 7.
n SoQuero Data Feed FTP Upload
This section describes how to enable the automatic data feed upload to
SoQuero Online Marketing as implemented in Intershop 7.
n Recommendation Engine Integration
This section outlines how to enable product recommendation features for sales
channel storefronts.
n Back Office Localization
This section describes how to localize the standard Web front template set into
German.
Intershop Studio
Intershop Studio is the integrated development environment for Intershop 7.
Intershop Studio assists developers in creating or modifying, building, and testing
cartridges for Intershop 7 applications.
Intershop supports Intershop Studio on 64bit Linux and 64bit Windows. It is,
however, not part of the standard Intershop 7 installation scenario, but packaged
on the installation medium in setup/studio.
To deploy Intershop Studio, just extract the Intershop Studio directory from the
Intershop Studio_<version>-<platform>.zip file to your hard drive. For information
about configuring Intershop Studio and developing for Intershop 7, refer to the
Intershop 7 Application Programming Guide.
NOTE: All customers with valid support contracts can obtain Intershop Studio releases and updates
via Intershop Support.
Web Analytics Services

Intershop 7 supports business reporting via an interface to Web analytics services.
Based on specifically prepared storefront pages, these services trace and analyze
the user interaction and generate corresponding reports.
Intershop provides an adapter cartridge for WebTrends Analytics. Support for other
web analytics services can be obtained on request. For more information, contact
Intershop.
Integrating a Web analytics service requires the following main tasks:
n Contracting the Web analytics solution
Make sure that your organization has closed an according contract with the
corresponding Web analytics solution provider.
n Setting up the adapter cartridge
This includes deploying and registering the adapter cartridge (as any other
additional cartridge), as well as installing or otherwise integrating the chosen
Web analytics service as required.

n Configuring Business Reports

Make sure that your organization has configured and enabled reports that
match the intended business scenarios.
For more information, refer to the documentation included with the adapter
cartridge.
eCircle E-Mail Marketing

Intershop 7 is prepared to support e-mail marketing campaigns through the
integration of eCircle-messenger (eC-m), a system for distributing newsletters or
other marketing messages to configurable groups of recipients. The necessary
adapter cartridge (ac_ecircle) is installed and initialized by default, but not
functional.
Enabling e-mail marketing requires the following tasks:
n Closing an eCircle Contract
Contact eCircle AG (www.ecircle-ag.com) to negotiate and close your e-mail
marketing provider contract.
n Getting SSL Certificates
With closing the eCircle contract, you will obtain SSL certificates to secure
the Web service traffic between the Intershop 7 installation and the eCircle-
messenger. Place the certificate into <IS.INSTANCE.SHARE>/system/cartridges/
ac_ecircle/release/cert and import it into the JDK, using, e.g., the JDK's keytool
utility.
n Enabling Web ServiceTraffic
Configure your system's firewall to allow HTTPS traffic between the IAS host and
the eCircle-messenger host. Alternatively, you can route the Web service traffic
through a proxy and allow the proxy to connect to eCircle.
n Configuring the E-Mail Marketing Preferences
This includes:
• Setting the e-mail marketing preferences for the channel in the Intershop 7
back office applying the account data provided by eCircle; for details refer to
the Intershop 7 user guide Managing Online Shops.
• Setting the preferences for abandoned basket messages; for details refer to
the Intershop 7 user guide Managing Online Shops.
• Enabling and scheduling the job Cleanup Outdated Baskets (SLDSystem
domain) in the SMC; for details about scheduled job management, refer to
Schedule Management.
SoQuero Data Feed FTP Upload

Product data feeds provide the possibility to externalize the content of the product
repository to different types of targets. The SoQuero Data Feed is a markup format
that is used by SoQuero's feed engine. Using the service involved, your current
product data is fed to multiple price and product search engines.

Enabling the automatic FTP upload of your feed data requires the following tasks:
n Closing an Online Marketing Contract
Make sure that your organization has contracted the SoQuero Data Feed service
with SoQuero Online Marketing.
n Configuring the FTP Connection
Specify the connection data (server name, path, user name, password) provided
with the data feed contract in the data feed configuration file syndication-
targets.properties, located in <IS.INSTANCE.SHARE>/system/config/cluster. In
addition, make sure to set
intershop.syndication.target.SoqueroDataFeed.ftp=true
in syndication-targets.properties in both <IS.INSTANCE.SHARE>/system/

config/cluster and each site's specific configuration directory, e.g.,
<IS.INSTANCE.SHARE>/sites/<site>/units/<unit>/syndication/config/.
n Creating the Data Feed
This includes:
• Configuring the SoQuero Data Feed,
• Assigning the intended products to the feed,
• Running the feed generation.
For a detailed description of the necessary tasks, refer to the Intershop 7 user guide
Managing Online Shops.
Recommendation Engine Integration

Intershop 7 can integrate product recommendation engines, a means to leverage
cross- and up-selling potential in online shops. To this end, Intershop 7 delivers
specific data feeds to the (external) recommendation engine, which, in turn,
supplies the recommendation information to the sales channel storefront.
Intershop provides adapter cartridges for a number of common recommendation
services, including Avail SaaS and Prudsys. Support for other recommendation
services can be obtained on request. For more information, contact Intershop.
Enabling product recommendations comprises the following main tasks:
n Closing an Recommendation Service Provider Contract
Your organization must negotiate and contract a dedicated product
recommendation service with the corresponding recommendation service
vendor.
n Setting up the adapter cartridge
This includes deploying and registering the adapter cartridge (as any other
additional cartridge), as well as installing or otherwise integrating the chosen
recommendation service as required.
n Configuring the Recommendation Service
Make sure to configure the recommendation service details as provided by the
vendor (e.g., the service URL) and as implemented in the storefront (default
page templates etc.).

n Preparing the Storefront Pages

Make sure to prepare the storefront pages intended to display the
recommendation data. That is, the corresponding pages must provide for
adding a corresponding product recommendation component, which displays
the actual recommendation data.
n Generating Product Recommendations Data Feeds
In order to provide your recommendation service provider with the required
product and order data, Intershop 7 must deliver dedicated data feeds to the
corresponding recommendation engine.
For more information, refer to the documentation included with the adapter
cartridge.
Back Office Localization

Intershop 7 includes the necessary resource files for a German localization (de_DE) of
the Intershop 7 back office. This includes, basically
• a set of German ISML template files,
• cartridge-specific German localization properties files,
• as well as a specific ant localize task, tLoc configurations and cartridge-
specific tLoc CSV dictionaries, in case you intend to customize the default
German Intershop 7 back office translations or to deploy translations for other
locales (see below).
For a German localization, no additional steps are required. The locale de_DE is
automatically initialized by default. That is, just setting the "Preferred Language" to
German switches the Intershop 7 back office display language accordingly.
Generating Standard Template Set for Other Locales

In order to deploy Intershop 7 back office template sets other than en_US or de_DE,
you must adjust the ant localize task as described below.
NOTE: If you intend to customize the Intershop 7 back office localization, make sure that tLoc is
installed.
On Windows, tLoc is installed as part of the development tools, which are

automatically included when performing a single machine installation.
On Linux, tLoc is shipped as an optional RPM package. To install it, change to the
installation package directory and run
rpm -ihv optional/*tloc*.rpm
To localize templates for fr_FR, for example, proceed as follows:

1. Log on as or switch to the application server user isas#.
On Windows, make sure to prepare the build environment using
environment.bat (located in <IS.INSTANCE.DIR>/bin).
2. Change to the <IS.INSTANCE.DIR>/tools/build/shared/tloc/etc directory.
$ cd <IS.INSTANCE.DIR>/tools/build/shared/tloc/etc

This directory contains the tLoc prepares_config.xml and extracts_config.xml

configuration files, as well as the merges_config.xml configuration file in a locale
subdirectory (by default, only de_DE).
3. Create a subdirectory for your target locale, and copy the existing
merges_config.xml file into the new locale subdirectory.
Following the example, type
• On Linux:
$ mkdir fr_FR
$ cp de_DE/merges_config.xml fr_FR/
• On Windows:
md fr_FR
copy de_DE\merges_config.xml fr_FR\
4. Edit the tLoc configuration files as necessary.

In the extracts_config.xml and merges_config.xml files, add a corresponding
<writer | reader>column.# for your additional translation, and edit the
character replacement rules according to your target locale's requirements.
NOTE: For details about tLoc configuration, refer to the Template Localization Guide.
5. Add the translations for your target locale to the dictionary files.
The CSV dictionaries, which by default contain only the translations for de_DE,
are located in the release/tloc/dict subdirectory of each cartridge to be localized.
Insert the translations for your additional locale into a new column, or replace
the German translations in column 5 if you are sure that that you do not need
them.
NOTE: Make sure that the translation columns in the dictionary match the corresponding
settings in the tLoc configuration files.
6. Execute the localize ant task.

From <IS.INSTANCE.DIR>/tools/misc, run
$ ant localize
The ant script

• determines the locale subdirectories in <IS.INSTANCE.DIR>/tools/build/
shared/tloc/etc,
• generates localized templates for all given locales using the translations
found in the specified dictionary column,
• and copies them to the corresponding <cartridge>/release/templates
directories.

Translating Localization Properties Files for Other Locales

To complete the Intershop 7 back office localization for other locales, you must
translate the localization properties files for your target language. To this end, the
following steps are necessary:
n Retrieving original localization properties files
To do so, scan all cartridges for *_en.properties files in the localizations
subdirectories and copy these files to a working directory.
NOTE: Keep the given directory structure, as some files have the same names and would
overwrite each other if you copied them all to a single directory.
n Translating localization properties files

Translate the text values in the original *_en.properties files to your target
language, and rename the translated files according to your target locale (for
"global" French, for example, *_fr.properties, for France, *_fr_FR.properties files,
for Swiss French *_fr_CH.properties files, etc.).
NOTE: Use either UTF-8 encoding or UCN entities for special characters in your translated
localization properties files.
n Deploying translated localization properties files

The translated localization properties files must be located in the same locations
as the original *_en.properties files. On Linux, make sure to adjust the file rights
for the new files for the application server user isas#.
NOTE: To have Intershop 7 check and reload new or modified localization properties at
runtime, enable the property intershop.localization.CheckContent (located in the
global appserver.properties file) and set it true.
After having generated the Intershop 7 back office template set and translated the
localization properties files, you must enable your target locale in Intershop 7. For
information about setting additional locales, refer to Prepare Locales. When done,
setting the session locale to your target locale switches the Intershop 7 back office
display language accordingly.
NOTE: Be aware that any modifications to the text values made through the Localization module
of the Intershop 7 back office are stored to the database but are not written to the properties files.

Is7.4 Admin Admin

Uploaded by

Copyright:

Available Formats

Is7.4 Admin Admin

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Is7.4 Admin Admin

Uploaded by

Copyright:

Available Formats

Administration and

Publication date 2014-01-06

About This Guide .................................................................................... 11

Main Software Components ..................................................................... 12

Administration Overview ......................................................................... 18

Chapter 2: Intershop 7 Administration ................................................ 21

Intershop 7 Configuration Framework ...................................................... 21

Web Server Settings ................................................................................ 25

Web Adapter Settings ............................................................................. 28

Administration and Configuration Guide iii

Intershop 7 Application Settings .............................................................. 48

iv Administration and Configuration Guide

Prepare Locales, Tax Data, Currencies and Exchange Rates ......................... 92

Administration and Configuration Guide v

Data Replication ..................................................................................... 98

Chapter 3: System Management ....................................................... 116

Overview .............................................................................................. 116

Navigate the SMC .................................................................................. 116

vi Administration and Configuration Guide

Logging Options ................................................................................... 125

File Browser .......................................................................................... 131

License Auditing ................................................................................... 132

Site Management .................................................................................. 133

Monitor the System State ...................................................................... 137

Installation Maintenance ....................................................................... 146

Administration and Configuration Guide vii

Chapter 4: Reference ......................................................................... 151

Appendix A: Command Line Tools and Scripts ......................................... 151

Appendix B: Summary of Placeholders ................................................... 154

Appendix C: Tomcat and Node Manager Settings .................................... 155

Intershop 7 Command Line Client ........................................................... 168

Appendix E: Enabling Optional Components ........................................... 170

viii Administration and Configuration Guide

Administration and Configuration Guide ix

x Administration and Configuration Guide

About This Guide

Administration and Configuration Guide 11

Highlights commands to be typed at command prompts as well as example

Main Software Components

12 Administration and Configuration Guide

Web Server and Web Adapter

The Web Adapter

Administration and Configuration Guide 13

The Web Adapter is configured using two different configuration files:

14 Administration and Configuration Guide

Internal Servlet Engine

Administration and Configuration Guide 15

The business logic features are:

Business Component and Application Cartridges

Data Storage and Database

16 Administration and Configuration Guide

Relational Database System

Intershop Shared Files (ISF)

The file system storage is split into two main areas:

Shared Directory Structure Description

Administration and Configuration Guide 17

Shared Directory Structure Description

18 Administration and Configuration Guide

• String: Text without blank spaces