Concept - Contact Center 1.0


The Contact Center is an application that provides a base set of Customer Relationship Management (CRM) functionality. It is used by specially trained personnel in order to manage the relationship with customers. It includes:

  • Customer Management
    • Manage customers master data
    • Manage account information (activation, reactivation, password)
  • Offer, Order Management
    • Provide customers specific discounts
    • Placement and editing of orders for customer by representative (including quick-order)
    • Support quoting process
  • Contact/Request Management
    • Logging and tracking of contacts (reason, duration, solution)
    • Support of multichannel contacts (call, chat)

The Contact Center is a standalone application. It is connected to Intershop 7 via a special REST API. The API can also be used by external systems or by custom clients allowing them to connect to IS7.

Software Version Information

The content of the present document is valid for the following combinations of software versions:

IntershopIntershop Contact Center




Giving an overview of used terminologies and expressions in reference to the Intershop Contact Center application.

Contact Center (CC)

The Intershop Contact Center is an Intershop Commerce Suite 7 application that is designed to help merchants establishing and managing personal contact with their customers. It integrates multiple communication channels that offer one-to-one contact, and provides customers with a quick and easy way of obtaining information and getting help via phone, chat, e-mail, etc.

Contact Center Agent (CCA)In the Intershop Contact Center, the contact center agent is an actor who is responsible for managing customer requests. The contact center agent handles requests via multiple communication channels, and acts and reacts according to a customer's needs with respect to, for example, orders, shipping or payment matters.
communication channelThe communication channel refers to the type of communication between the Intershop Contact Center and a customer, like phone, chat, e-mail, contact form, etc.
contact sessionThe contact session refers to the phase of interaction and communication between the contact center agent and the customer. A contact session may involve multiple requests.
requestThe request refers to a single issue cycle within a contact session. A request has a reason, may involve an action, and has a solution.
actionThe action refers to an operation triggered by the contact center agent in response to a customer's request (like, for example, creating a promotion code or adding/removing a product to/from the shopping cart).
solutionThe solution is the documented result of whether and how a customer's request is completed/fulfilled.


  • Cookbook - JUnit Tests
    A reference on how to write a JUnit 4 test and how mocking works. At the end of the page "Mocking with Guice" is explained.



An Intershop 7 installation can be divided in editing systems and live cluster. Both are accessable via the Web Adapter. Changes in the edit system are replicated to live system where the real web shops are running. The web shop technology provides a REST API that provides calls for almost all purchase relevant topics like catalog browsing, cart and checkout functionality, promotion topics and even account management issues.The new Contact Center extension module is developed as an independent application. It can be deployed on a separate web server. The application communicates with Intershop 7 via REST. A Contact Center REST API is deployed to the Intershop 7 server and extends the WebShop REST API by some specific calls like customer search, checkout on behalf of a customer, or generating vouchers. Other external data systems like ERP or recommendation engine can be easily integrated via REST, too. And vice versa the Contact Center REST API can easily be used by external systems.

Assembly, Component Set and Cartridge Structure

The whole extension module for the Contact Center is combined in an own assembly. It contains the Contact Center UI as well as the Contact Center REST API which are stored in own cartridges. The cartridges are only code containers. They cannot be overwritten by customized cartridges containing parts of the standard cartridge. The following figure outlines the cartridge structure.


Fundamental initialization of the Contact Center application (root domain, application type, database structures if needed)

init_contactcenterInitialization and migration of business user data

Backing cartridge for co-browsing the storefront

app_contactcenterContact Center web client
app_sf_contactcenter_restREST-API of the Contact Center
Contain the tests for the respective cartridge

Suggested by the architects to keep the functionality to administer the Contact Center

ucm_demo_contactcenterContains demo content for the Contact Center

Initialization (DBInit)

Application Type and Root Domain

Application type and root domain are defined in the cartridge as_contactcenter.

Application type: intershop.CC

Root domain: root.sites = ContactCenter

Permissions and Roles

Permissions and roles are defined in init_contactcenter.

The following permissions for the Contact Center are defined:



The permission to operate the Intershop Contact Center as a Contact Center Agent

The following roles are defined for now:

RoleAssigned Permissions



Application Architecture

The Contact Center application is based on the Omni Channel Service Framework which consists of several Ember Artifacts. So the framework is like a technology container which can easily be extended and adapted for the customer’s needs. The UI is application specific. It contains several views for the user’s interactions. A web page can consist of several views and a view can use other views.

The data which are displayed and editable are stored in models. A model is a class that defines the properties and behavior of the data that you present to the user. Anything that the user expects to see if they leave your app and come back later (or if they refresh the page) should be represented by a model. Different views are used by different models that allow the display and change of their data.

There is a program layer which holds the functional structure of the application, the controllers. In Ember.js, controllers allow to decorate models with display logic. In general, the models will have properties that are saved to the server, while controllers will have properties that your app does not need to save to the server. A controller can use several models and a model can be used by several controllers. The methods of the controller prepare the REST calls with manipulated data or changes the model values with data received from the REST calls responses.

The wiring between model, view and controller is defined by so called routes which can be accessed via the URL.

Controllers communicate with the REST API of IS 7 via adapters. These adapters contain the REST calls themselves and execute the call with the parameter values prepared by the controller. The responses are returned to the controllers.

OCST Deployment

The contact center UI server uses a new concept to deliver functionality of the presentation layer. The UI server has no direct database link as the IS 7. The client directly communicates with the REST interface of IS 7.

The contact center UI server has less infrastructure requirements than an IS 7. Depending on who is using the functionality different deployment scenarios are possible.


  • Application server is not directly accessible from the internet.
  • Indirect access to application server to be support easier maintenance.

Deployment Scenarios

The usage of mod_jk and Web Adapter in one Web server needs to separate these requests by an URL pattern (defined in the httpd.conf). This could decrease the flexibility of URL rewriting.

Development Scenario

The development environment does not need multiple server instances. So everything is deployable at one machine.

The Contact Center UI server is accessible via mod_jk or via the outer tomcat URI. The configuration of the contact center UI server needs the location of the WA-storefront.

Staging Inside Scenario

The Staging Inside Scenario fits for an inhouse usage of the Contact Center. The IT department is responsible to serve IS 7 and Contact Center.

The Contact Center UI server is configured with the name and port of the Load Balancer.

Outside Scenario

This scenario has an independent deployment of IS 7 and Contact Center UI Server. This scenario is important for external call center agencies or departments with different IT.

The gray box is an external system without administrative access. But this environment needs the Contact Center cartridges for Contact Center communication.

Client Technology

The client application has to provide a appealing user interface for an Contact Center Agent. The clients communicate with the application server by using REST calls.

In the following the architecture and the different user interaction scenarios are described.


The deployment scenarios of the new Contact Center client are still in progress and thus may be object to changes.

Web Application Technology

The Contact Center client is not a Intershop-specific cartridge, but a standalone web application that can be deployed to a simple J2EE app server (e.g., Tomcat). The project f_contactcenter/app_contactcenter is configured as a Eclipse Web Tools (WTP) project that can be run and debugged directly from the Intershop Studio. It is built as a standalone Gradle project.

The client can be configured via the file /WEB-INF/resources/config/configuration.xml. It contains the necessary settings for the REST APIs the client can use, as well as the payment whitelist settings:

	<bean id="webshop"
        <property name="restURIBase" value="${WebshopRestURIBase}" />
        <property name="restURI" value="${WebshopRestURI}" />
        <property name="version" value="7.5.0" />
    <bean id="contactcenter"
        <property name="restURIBase" value="${ContactcenterRestURIBase}" />
        <property name="restURI" value="${ContactcenterRestURI}" />
        <property name="version" value="1.0.0" />
        <property name="paymentMethods">

The placeholders (e.g., ${WebshopRestURIBase}) are filled by the gradle process. And on the other hand we have the payment methods which are directly filled. Changing the latter parameter requires a server restart.


The JavaScript framework Ember.js provides its own way to model applications. Therefore, structuring elements like routes, models, controllers, adapters, components and views are introduced (see illustration below).

RoutesDefine a URL path to access a certain view. Setup the model and the controller.Specify route customers and set up a controller (e.g., CustomersController) and initialize/load a model (e.g., CustomersModel).
ModelContains the data and is initialized when a route is accessed. Contain computed properties.CustomersModel will be filled with an array of customers. Computed properties are "calculatedAge" (property birthday)
ControllerHave a model and provide actions to perform transitions to other routes or manipulate/save/reload the model.Performing a delete action on the selected customer (e.g., CustomersController).
ViewRender a template which is backed by a controller. Each template may contain render, view, partial or custom component helpers for structuring.A customers template (e.g., CustomersView) is rendering the CustomersController contents (e.g., CustomersModel).
AdapterAbstraction layer for accessing the REST API via PUT, POST, GET and DELETE (CRUD - create, read, update, delete)The standard REST behavior can be overridden by customizing the global REST adapter or individual model adapters.

From a controller view perspective the following initial structure was established. In the final version 1.0.0 Controllers and templates in the view layer may have changed their namings.


The JavaScript framework Require.js allows to have controllers, routes, views etc in separate JavaScript files, which can be loaded on demand and defining dependencies (e.g., jQuery-placeholder.js needs jQuery.js). Therefore the JavaScript code can be structured and included whereever needed.

  • RequireJS is a JavaScript file and module loader.
  • It is optimized for in-browser use, but it can be used in other JavaScript environments.


  • Bootstrap is a free collection of tools for creating user interfaces for websites and web application.
  • Bootstrap contains HTML and CSS-based templates (snippets) for text, forms, buttons, navigation and other components.
  • Bootstrap also contains optional JavaScript extensions.
  • Bootstrap is used for the responsive layout of the Contact Center.


jQuery is the most used JavaScript framework in history. It is also on the dependencies-list of the Ember.js framework.

  • jQuery is a fast, small and feature-rich JavaScript library.
  • It allows HTML document traversal and manipulation, event handling, animation and provides an easy-to-use Ajax function for (a)synchronous server requests.
  • Works across a multitude of browsers.


  • Less is a CSS pre-processor, meaning that it extends the CSS language, adding features that allow variables, mixins, functions and many other techniques that allow you to make CSS that is more maintainable, themable and extendable.

  • Less runs inside Node, in the browser and inside Rhino. There are also many 3rd party tools that allow to compile files and watch for changes.


Handlebars is a HTML-template engine for JavaScript. It allows deeper structuring of code by defining semantic templates for display, which is usually the HTML code of a website. Using individual helper functions, partials (includes) and ember specific helpers (e.g., render, partial, or view) it allows creating a well defined structure for templates. As part of the Ember distribution it is tidly integrated and well documented.


The client application configuration can be found inside the home.jsp file. The attributes are used to make the Ember application configurable for development, production or other environments.

<script type="text/javascript">
        /* declare the application webroot path*/
        var ContactCenterConfiguration = {
        	webRootURI: 'resources',
        	baseURI: '${contactcenter.restURIBase}',
        	restURI: '${contactcenter.restURI}',
        	paymentMethodsWhiteList: ${contactcenter.paymentMethods},
        	webshopURIBase: '${webshop.restURIBase}',
        	 * For 7.4.5 "payments"-compatibility the version can be set to '7.4.5'
        	 * Standard is the '7.5.2' version number.
        	version: '7.5.2',  
        	     * Refresh interval for Contact Center Session, when only WebShop calls are made
        	     * n (n > 0) - when WebShop calls are made, at least n milliseconds later a CC refresh call is made 
        	     * n ( n <= 0)  - no refresh (for servers with high session timeout)
        	sessionRefreshTime: 30000,  // milliseconds
    	     * Enabling the clockService which is required for reoccuring events (e.g., automatic session refresh)
        	 * Can be disabled by setting to false (e.g., testing)  
        	clockService: true,
        	 * Internationalization configuration for
        	 * Check I18nInitializer for additional details 
        	i18n: { 
	        	 * Available language property files located under /resources/localizations
	        	 * First language is default language when browser language does not match any other
	        	 * language. 
	        	 * Using ' ' is the default language containing the english translation and points to
	        	languages: [' ', 'de'],
	        	 * List of all translation properties files available
                 * located under /contactCenter/localizations
	        	propertyFiles: [
	               'application', 'basket', 'cobrowse', 'customersearch', 'customersearchresult', 'hnavbar', 'index', 'login', 'index', 
                   'orderdetails', 'orders', 'ordersummary', 'promotionhistory', 'promotions', 'quickorder', 'storefinder'
	             * Relative path where all properties files are located
	            path: './resources/localizations/'


The application comes along with localized templates, controllers, views, etc. Therefore we need language dependent text snippets in JavaScript and Handlebars (template engine) - which are refered to as localized strings.

These localized strings are stored in standard Java properties files. Nevertheless, these files are readout by a JavaScript framework which allows us to access translations in JavaScript (e.g., controllers, routes,..) as well as in templates. The two ways are presented below.

Template Localization
<!-- Text translation -->
TEMPLATE: <h4>{{i18n "login.dialog.header.title"}}</h4>
--> HTML: <h4>Contact Center</h4>
<!-- HTML attributes ("unbound" indicates that a constant is displayed) -->
TEMPLATE: <a {{action "doLogout"}} title="{{unbound i18n ""}}">...</a>
--> HTML: <a title="Logout">...</a>
<!-- Component attributes translation -->
TEMPLATE: {{input type="text" placeholderTranslation="login.dialog.loginname.placeholder"}}
--> HTML: <input type="text" placeholder="Login name">

In JavaScript you can access the jQuery localization plugin directly.

Localization within Javascript
JAVASCRIPT: console.log($.i18n.prop('login.dialog.errors.missing_login'));
-> CONSOLE: "You missed entering your login name."

Within controllers the initialization of attributes should be made within the initialization method. Doing so the localizations get enough time to load, before they are looked up.

Localization within an Ember Controller
FooController = Ember.Controller.extend({
    init: function() {
        // setting the the localization to the properties "footerButtons" and "title"
           footerButtons: [
                Button.create({title: $.i18n.prop('application.button.close'), clicked: 'close', dismiss: 'modal'})
           title: $.i18n.prop('quickorder.modal.paymentmethod.title')
// BAD (not working)
FooController = Ember.Controller.extend({
   // FAIL! initializing localizations here fails, since localization are not loaded in that early stage of instantiation.
   footerButtons: [
       Button.create({title: $.i18n.prop('application.button.close'), clicked: 'close', dismiss: 'modal'})
   title: $.i18n.prop('quickorder.modal.paymentmethod.title')

The localization files are simple Java properties files that will be resolved locale-dependent, with the most specific locale tried first (e.g., -> ->

Localization file contents
login.dialog.footer.copyright=Intershop 7 ContactCenter - {0} &#169; Intershop Communications, 2014
login.dialog.loginname.placeholder=Login name



The Contact Center web application runs within HTTPS which means it is secured through SSL encryption. The new Contact Center REST API supports HTTP as well as HTTPS, but the the communication between the web application and the REST API will be exclusively HTTPS. All REST calls in the Contact Center REST API are restricted resources that use a token-based Basic HTTP authentication.

The Contact Center REST API includes a two-step security check. Firstly, a LoginProvider checks if the user (Contact Center Agent) exists and is able to log in to a organization the Contact Center works for.

In the second step a PermissionProvider checks wether the user has the permission (role) to access the REST calls. The needed permissions are defined in the file as_contactcenter\staticfiles\cartridge\components\ for the domain TargetOrganization which refers to the organization given by theappropriate header field UserOrganization.

Both security checks require a header field UserOrganization which contains the name of the organization where the user is validated against.

The interactive REST client is a single page JavaScript application. Therefore, the user authentication relevant data will be stored within JavaScript. Thus neither cookies must be used nor sensitive data has to be appended to any REST URL requests.


The client application uses HTTPS only. Sensitive data is NOT stored in cookies and is NOT appended to the URL.

The Contact Center is an standalone application which supports some IS 7 functionality for the use as an Contact Center Agent. The CCA has the special permission SLD_OPERATE_CONTACTCENTER. This role is able to log in in the Contact Center where some more use cases than in the B2C WebShop are available. The CCA is able to select a customer of an special channel and use the B2C WebShop on behalf of the selected customer. This is possible about the connected REST APIs, one for the customer's B2C Web Shop, the other for some customized Contact Center REST calls, e.g., the creation of promotion codes for special promotions created for the Contact Center in the BO.


The user who wants to log in must exist in the given organization (e.g., PrimeTech) and must be assigned to the role Contact Center Contact Center Agent.

In order to log in to the Contact Center UI, the REST call REST API OCST - Get User Details should be used.

To authenticate the user for the first time:

  • Add header fields
    • Authorization ; with Value: String "Basic " +Base64-encoded credentials separated by ':' (login + ":" + password)
    • UserOrganization with value login (plaintext)


  • Add header fields
    • UserLogin with value login (plaintext)
    • UserPassword with value login (plaintext)
    • UserOrganization with value login (plaintext)

The response of this call will contain an authentication-token which should be used to authenticate the user in all further calls.

For repeated access:

  • Add Header fields
    • authentication-token ; value: generated token from the first response header
    • UserOrganization with value login (plaintext) - used for permission check

Each token is only valid for a given time period, which is defined by the maximum inactivity time for the accessed site.

Concept - REST Framework

Third Party Libraries

The Contact Center makes excessive use of open source JavaScript and CSS libraries. These are documented on the 3rd party components and libraries confluence page referencing the f_contactcenter component set and the cartridge app_contactcenter.

The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.
The Intershop Knowledge Portal uses only technically necessary cookies. We do not track visitors or have visitors tracked by 3rd parties. Please find further information on privacy in the Intershop Privacy Policy and Legal Notice.
Knowledge Base
Product Releases
Log on to continue
This Knowledge Base document is reserved for registered customers.
Log on with your Intershop Entra ID to continue.
Write an email to if you experience login issues,
or if you want to register as customer.