close
1 Install and Update Guide for EWA Local
2 Table of Contents
3 Introduction
3.1 "EWA Central" vs. "EWA local"
3.2 Target audience
3.3 Definitions
3.4 Terms
4 Requirements
4.1 Delivery Media
4.2 Software
4.2.1 Application server / Database server machine
4.2.2 Client machines
4.3 Hardware
4.4 Network
5 Installation
5.1 EWA “local”
5.1.1 Run the installer
5.1.2 Check the services
5.1.3 Register the access authorization(s)
5.1.4 Add a first Group and first User
5.2 Install database content from DVDs
5.3 Manual modifications
5.4 Quick check of the installation
5.4.1 Check on the server
5.4.2 Check on the client
6 EWA Configuration
6.1 EWA Application Server Settings
6.1.1 core_cfg.xml
6.1.2 license.xml
6.1.3 um_cfg.xml (and um_batch_cfg.xml)
6.1.4 secure_linkout_cfg.xml
6.1.5 additional_downloads_cfg.xml
6.2 Feedback
6.2.1 Introduction
6.2.1.1 Feedback Channel: Fax
6.2.1.1.1 Preconditions
6.2.1.1.2 Configuration
6.2.1.2 Feedback Channel: Email
6.2.1.2.1 Preconditions
6.2.1.2.2 Configuration
6.2.1.3 Feedback Channel: Email-or-Fax
6.2.1.3.1 Preconditions
6.2.1.3.2 Configuration
6.2.1.4 Feedback Channel: XSF-email
6.2.1.4.1 Preconditions
6.2.1.4.2 Configuration
6.2.1.5 Feedback Channel: XSF-fax
6.2.1.5.1 Preconditions
6.2.1.5.2 Configuration
6.2.1.6 Feedback Channel: xml-post
6.2.1.6.1 Preconditions
6.2.1.6.2 Configuration
6.2.1.7 Advanced features of the feedbackRecipients.xml
6.3 Configuration of WIS net
6.3.1 wis_cfg.xml
6.4 Configuration of EPC net
6.4.1 epc_cfg.xml
6.4.2 EPC Shopping lists
7 Advanced Configuration
7.1 Switching EWA to default HTTP Port 80
7.2 Logging
7.2.1 EWA system log
7.2.1.1 File names and location of logfiles
7.2.1.2 Log level
7.2.1.3 Rolling File Adapter
7.2.2 Application Server logging
7.2.3 Client Side Logging
7.3 Security
7.3.1 Secure Socket Layer (SSL, HTTPS) Support – Optional
7.3.2 Protection against unsolicited access
7.4 User Management Configuration
7.4.1 HP User Management
7.4.2 LDAP
7.4.2.1 General Setup of LDAP
7.4.2.2 Using LDAP Authentication (Simple mode)
7.4.2.3 Using LDAP Fetch Mode
7.4.2.4 Using LDAP Search Mode
7.4.2.5 Using LDAP Search and Authentication Mode (most valuable for accessing an MS ActiveDirectory)
7.4.3 Corporate Directory
7.4.4 StarTekInfo
7.5 User Reports Configuration
7.5.1 User Reports for the Central Accounting
7.5.2 Configuration
7.5.2.1 Main configuration parameters
7.5.2.2 Configuration settings for the central accounting reports
7.5.3 Market User Reports
7.5.3.1 Configuration settings for the market reports
7.5.3.2 Changing the E-Mail Body of the Market Reports
7.5.3.3 Regular Expression Syntax for Workshop and Group Filters
7.6 Shoppinglist/Joborder webservice exchange
8 Single Sign On with EWA
8.1 Single Sign On
8.1.1 Windows NTLM Authentication
8.1.1.1 Setting up SSO on Tomcat and Internet Information Server (IIS)
8.1.1.1.0.1 Setup Internet Information Server
8.1.1.1.0.2 Configure and restart the EWA server
8.1.1.1.0.3 Install files from the EWA media
8.1.1.1.0.4 Configure and restart the IIS
8.1.1.2 Check the Environment
8.1.1.3 Client Setup for SSO
8.1.1.3.0.1 Ensure the correct Java Runtime
8.1.1.3.0.2 EWANAPI Update
8.1.2 SiteMinder Authentication
8.1.2.1 Configuration of SiteMinder
8.1.2.2 Working with SiteMinder SSO integration activated
9 Clustering of an EWA Server
9.1 Clustering
9.2 Clustering EWA using Tomcat application server
9.2.1 NAT Request distributors / Load Balancers
9.2.2 Using mod2jk and Apache httpd for Load Balacing
9.2.3 Distributed Java Servlet Containers
9.2.3.1 Servlet Sessions
9.2.3.2 Session Affinity (or Sticky Sessions)
9.2.3.3 Replicated Sessions
9.2.3.3.1 Session Replication in Tomcat 7
9.3 Steps to Cluster EWA with Tomcat as Application Server
9.3.1 Installing Apache Web Server
9.3.2 Install and Configure mod_jk Connector
9.3.2.1 Changes in all EWA Servers
9.3.2.2 Configuring Session Replication
10 De-Installation
10.1 "Hardcore" de-installation
11 Update / Migration
11.1 Regular updates
12 Additional software installation
12.1 Spooler
12.1.1 General
12.1.2 Configuration
12.1.2.1 Spool file location
12.1.2.2 Access rights for spool out files
12.1.3 Interactively running the spoolers
12.1.3.1 ASRA Spooler (AWAT data spooler)
12.1.3.2 Damagecode Spooler (SSL data spooler)
12.1.4 Scheduled process of spooling / Spooling multiple "packages"
12.1.5 Additional Information
13 Client software installation
13.1 Java Runtime Environment
13.2 EWANAPI (External API to call EWA  clients for DMS calls and/or Xentry integration) (ewanapi.exe / wisapi.exe)
13.2.1 Automatic Installation via the integrated EWANAPI Installer
13.2.1.1 Server side preparation (System administrators tasks):
13.2.1.1.1 Rules for reading the specific server settings to be applied on clients
13.2.1.1.2 Automatic property replacement within ewanapi.ini
13.2.1.1.3 Influence target installation directory on the client PC
13.2.1.1.4 Prefer SSO authentication before provided credentials
13.2.1.1.5 Address Proxy settings / problems
13.2.1.1.6 Preparation for Autoline 8.30 / 8.35 integration
13.2.1.1.7 Preparation for Autoline 8.2 Emulation layer
13.2.1.1.8 Preparation for fallback server option
13.2.1.1.9 Preparation for Siteminder integration option
13.2.1.1.10 Other settings
13.2.2 Automatic Deployment of EWANAPI
13.2.3 Manual Installation
13.2.4 Configuration
13.2.5 Proxy Server Configuration for EWANAPI
13.2.6 Example of an ewanapi.ini file
14 References
14.0.1 Admin Tool Guide
14.0.2 User Administration document
14.0.3 EWANAPI description document
14.0.4 WIS Release Notes
14.0.5 EPC Release Notes

1 Install and Update Guide for EWA Local

Valid from EWA version 1.21.228.0

Created for Daimler AG

2 Table of Contents

1 Install and Update Guide for EWA Local

2 Table of Contents

3 Introduction

3.1 "EWA Central" vs. "EWA local"

3.2 Target audience

3.3 Definitions

3.4 Terms

4 Requirements

4.1 Delivery Media

4.2 Software

4.2.1 Application server / Database server machine

4.2.2 Client machines

4.3 Hardware

4.4 Network

5 Installation

5.1 EWA “local”

5.1.1 Run the installer

5.1.2 Check the services

5.1.3 Register the access authorization(s)

5.1.4 Add a first Group and first User

5.2 Install database content from DVDs

5.3 Manual modifications

5.4 Quick check of the installation

5.4.1 Check on the server

5.4.2 Check on the client

6 EWA Configuration

6.1 EWA Application Server Settings

6.1.1 core_cfg.xml

6.1.2 license.xml

6.1.3 um_cfg.xml (and um_batch_cfg.xml)

6.1.4 secure_linkout_cfg.xml

6.1.5 additional_downloads_cfg.xml

6.2 Feedback

6.2.1 Introduction

6.2.1.1 Feedback Channel: Fax

6.2.1.1.1 Preconditions

6.2.1.1.2 Configuration

6.2.1.2 Feedback Channel: Email

6.2.1.2.1 Preconditions

6.2.1.2.2 Configuration

6.2.1.3 Feedback Channel: Email-or-Fax

6.2.1.3.1 Preconditions

6.2.1.3.2 Configuration

6.2.1.4 Feedback Channel: XSF-email

6.2.1.4.1 Preconditions

6.2.1.4.2 Configuration

6.2.1.5 Feedback Channel: XSF-fax

6.2.1.5.1 Preconditions

6.2.1.5.2 Configuration

6.2.1.6 Feedback Channel: xml-post

6.2.1.6.1 Preconditions

6.2.1.6.2 Configuration

6.2.1.7 Advanced features of the feedbackRecipients.xml

6.3 Configuration of WIS net

6.3.1 wis_cfg.xml

6.4 Configuration of EPC net

6.4.1 epc_cfg.xml

6.4.2 EPC Shopping lists

7 Advanced Configuration

7.1 Switching EWA to default HTTP Port 80

7.2 Logging

7.2.1 EWA system log

7.2.1.1 File names and location of logfiles

7.2.1.2 Log level

7.2.1.3 Rolling File Adapter

7.2.2 Application Server logging

7.2.3 Client Side Logging

7.3 Security

7.3.1 Secure Socket Layer (SSL, HTTPS) Support – Optional

7.3.2 Protection against unsolicited access

7.4 User Management Configuration

7.4.1 HP User Management

7.4.2 LDAP

7.4.2.1 General Setup of LDAP

7.4.2.2 Using LDAP Authentication (Simple mode)

7.4.2.3 Using LDAP Fetch Mode

7.4.2.4 Using LDAP Search Mode

7.4.2.5 Using LDAP Search and Authentication Mode (most valuable for accessing an MS ActiveDirectory)

7.4.3 Corporate Directory

7.4.4 StarTekInfo

7.5 User Reports Configuration

7.5.1 User Reports for the Central Accounting

7.5.2 Configuration

7.5.2.1 Main configuration parameters

7.5.2.2 Configuration settings for the central accounting reports

7.5.3 Market User Reports

7.5.3.1 Configuration settings for the market reports

7.5.3.2 Changing the E-Mail Body of the Market Reports

7.5.3.3 Regular Expression Syntax for Workshop and Group Filters

7.6 Shoppinglist/Joborder webservice exchange

8 Single Sign On with EWA

8.1 Single Sign On

8.1.1 Windows NTLM Authentication

8.1.1.1 Setting up SSO on Tomcat and Internet Information Server (IIS)

8.1.1.1.0.1 Setup Internet Information Server

8.1.1.1.0.2 Configure and restart the EWA server

8.1.1.1.0.3 Install files from the EWA media

8.1.1.1.0.4 Configure and restart the IIS

8.1.1.2 Check the Environment

8.1.1.3 Client Setup for SSO

8.1.1.3.0.1 Ensure the correct Java Runtime

8.1.1.3.0.2 EWANAPI Update

8.1.2 SiteMinder Authentication

8.1.2.1 Configuration of SiteMinder

8.1.2.2 Working with SiteMinder SSO integration activated

9 Clustering of an EWA Server

9.1 Clustering

9.2 Clustering EWA using Tomcat application server

9.2.1 NAT Request distributors / Load Balancers

9.2.2 Using mod2jk and Apache httpd for Load Balacing

9.2.3 Distributed Java Servlet Containers

9.2.3.1 Servlet Sessions

9.2.3.2 Session Affinity (or Sticky Sessions)

9.2.3.3 Replicated Sessions

9.2.3.3.1 Session Replication in Tomcat 7

9.3 Steps to Cluster EWA with Tomcat as Application Server

9.3.1 Installing Apache Web Server

9.3.2 Install and Configure mod_jk Connector

9.3.2.1 Changes in all EWA Servers

9.3.2.2 Configuring Session Replication

10 De-Installation

10.1 "Hardcore" de-installation

11 Update / Migration

11.1 Regular updates

12 Additional software installation

12.1 Spooler

12.1.1 General

12.1.2 Configuration

12.1.2.1 Spool file location

12.1.2.2 Access rights for spool out files

12.1.3 Interactively running the spoolers

12.1.3.1 ASRA Spooler (AWAT data spooler)

12.1.3.2 Damagecode Spooler (SSL data spooler)

12.1.4 Scheduled process of spooling / Spooling multiple "packages"

12.1.5 Additional Information

13 Client software installation

13.1 Java Runtime Environment

13.2 EWANAPI (External API to call EWA  clients for DMS calls and/or Xentry integration) (ewanapi.exe / wisapi.exe)

13.2.1 Automatic Installation via the integrated EWANAPI Installer

13.2.1.1 Server side preparation (System administrators tasks):

13.2.1.1.1 Rules for reading the specific server settings to be applied on clients

13.2.1.1.2 Automatic property replacement within ewanapi.ini

13.2.1.1.3 Influence target installation directory on the client PC

13.2.1.1.4 Prefer SSO authentication before provided credentials

13.2.1.1.5 Address Proxy settings / problems

13.2.1.1.6 Preparation for Autoline 8.30 / 8.35 integration

13.2.1.1.7 Preparation for Autoline 8.2 Emulation layer

13.2.1.1.8 Preparation for fallback server option

13.2.1.1.9 Preparation for Siteminder integration option

13.2.1.1.10 Other settings

13.2.2 Automatic Deployment of EWANAPI

13.2.3 Manual Installation

13.2.4 Configuration

13.2.5 Proxy Server Configuration for EWANAPI

13.2.6 Example of an ewanapi.ini file

14 References

14.0.1 Admin Tool Guide

14.0.2 User Administration document

14.0.3 EWANAPI description document

14.0.4 WIS Release Notes

14.0.5 EPC Release Notes


3 Introduction

The intention of this operation manual is to provide system administrators sufficient background knowledge to install EWA, configure it and handle usual problems and errors that may occur during EWA setup, configuration and in daily operation. In order to do this an overview over the system architecture of EWA and its core framework is given. The next sections describe general setup and configuration tasks. Additionally, details of some specific topics (like e.g. log information) are provided. A "Frequently Asked Questions" (FAQ) section completes this document.

However, it is not (and cannot be) the aim of this document to provide guidelines to resolve problems originating from third party components like problems setting up an application server or a database system on several Windows OS environments, configuring firewalls to allow user access, integrating EWA in other environments (Web- or Application Servers other than the ones supported), running several versions of programs (e.g. several versions of the Java Runtime Environment) at the same time etc.

3.1 "EWA Central" vs. "EWA local"

EWA is a server based, distributed application. There are two main differences in the application deployment which will be called "central" and "local" – you will notice these terms often within this document.

Central: this installation type means a centrally hosted server environment which is typically used not only for a single workshop but i.e. for a whole market as Internet based application. Installation and Updates will be performed by experienced system administrators. The server and database software is somehow more advanced (and typically needs separate licensing) then the software from the "local" environment.

Local: this type of installation typically refers to an installation within a local workshop. It has other needs for installation, maintenance and performance. Installation and Updates will be supported by automatic processes. And the software requirements are not as "challenging" as the ones for the "central" environment.

3.2 Target audience

This document has been written for system administrators with at least basic knowledge of

3.3 Definitions

Following definitions shall help to describe the installation from a more generic view. These definitions or properties do not have to be available as operating system variables. They shall just provide some kind of abstraction throughout this documentation.

The following text will refer to these definitions as [property].

Example:
A "[EWA_HOME]\config" path will have to be expanded by you for your local settings to i.e. "C:\EWA_net\config".

Property

Description

DVD-DRIVE

The drive letter in which you have mounted the delivery DVD

EWA_HOME

Installation location of the EWA installation.
Example:

C:\EWA

EWA_SERVER_PORT

Port of the EWA services to listen to.
Example:

9000

3.4 Terms

This section lists some terms that are being used within this document.

Term

Description

DBMSDatabase Management System
DBShortcut for Database / Database System
CoreThis is the "heart" of EWA on the server side. Basically it is the AccessGateway, the EWA system framework and some other components.
Or: everything apart of EPC and WIS that runs on the server.
User Management DB
Core database
The runtime database running in Read/Write mode.
This database stores user and runtime information.

See the system software chapter for supported products.

WIS databaseRuntime, readonly database containing service information for WIS.
This database is based on the DBMS Transbase.
EPC databaseRuntime, readonly database containing service information for WIS.
This database is based on the DBMS Transbase.

4 Requirements

4.1 Delivery Media

For the installation to take place, you need at least following items:

4.2 Software

As mentioned in the previous chapter the EWA server and client components are completely based on Java.

The components on the client side are started by means of "Java Web Start". Starting with Java 2 (jre-packages 1.4 and above) "Java Web Start" is part of the "Java Runtime Environment" installation.

Apart from a Web-Browser (like Internet Explorer) and a working JRE (which in turn includes Java WebStart) there are no other software requirements on the client side. The JRE on client side needs to be at least version 1.6, it is recommended to use version 1.7, though. Installation of the EWA client components is done automatically via "Java Web Start".

On the server side a Web-Server, a Servlet Container (or J2EE Application Server), an installed user database, the EWA core framework and the applications including the according application databases need to be installed.

For EWA "central" Tomcat serves as Web- and Application server. MS SQL, DB2 or TransBase is used as the database for user information. Web-Archives (.war) files contain the program logic for the Access Gateway, User management, WIS and EPC. Program modules within these Web-Archives are being executed by the servlet container each time a request is sent by a user.

For EWA "local" Tomcat serves as Web- and Application server. TransBase is used as the database for user information. Web-Archives (.war) files contain the program logic for the Access Gateway, User management, WIS and EPC. Program modules within these Web-Archives are being executed by the servlet container each time a request is sent by a user.

Additionally, two TransBase databases are being used, one for WIS and another one for EPC.

Other services and programs used for instance by EPC FP and WIS classic (like the access authorization Service, Program Manager etc.) are not required for EWA.

Since some of the mentioned server components do only run on a Windows environment, it is necessary to use MS Windows as the server side operating system.

Note:
Following software components are expected to be installed correctly on the server and client machines BEFORE starting with the installation of EWA.

4.2.1 Application server / Database server machine

Type of SoftwareServer 1000

< 1000 registered user

Server 2000

< 2000 registered user

Server 4000
2 clustered servers
with separate DB server
< 4.000
registered user
Server 8000
4 clustered servers
with separate DB server
< 8.000
registered user
Stand-alone PCComment
Operating SystemWindows Server 2003 SP2,
Windows Server 2008 32/64bit -
Deutsch/Englisch
Windows Server 2003 SP2,
Windows Server 2008 32/64bit -
Deutsch/Englisch
Windows Server 2003 SP2,
Windows Server 2008 32/64bit -
Deutsch/Englisch
Windows Server 2003 SP2,
Windows Server 2008 32/64bit -
Deutsch/Englisch
Windows 7, Windows 8
Deutsch/Englisch
Windows XP and Windows Vista are not part of the integration tests anymore.
Web BrowserInternet Explorer 8/10Internet Explorer 8/10Internet Explorer 8/10Internet Explorer 8/10Internet Explorer 8/10Other browsers (Firefox, Chrome or other versions of IE) are not part of integration tests and not officially supported.
However, EWA might work with other browsers then the mentioned ones.
Java 2 RuntimeJRE 1.7JRE 1.7JRE 1.7JRE 1.7JRE 1.7http://www.java.com/download, or install the Java Runtime Environment provided from the installation DVD:
[EWA-HOME]\client-apps\jre\jre.exe

Note:
Some operating systems have Internet Information Server running on the default Web port 80 by default. Thus EWA will be installed by default on the HTTP port 9000. You can change this later to port 80 if you like to. In that case do not forget to shutdown IIS permanently.

4.2.2 Client machines

The client machines will not be covered by the installation process. But in order to allow execution of the client software, following software must be installed on the client systems:

Type of Software

Minimum requirementsOptimal requirements

Comment

Operating System

Windows XP, Windows 7, Windows 8Windows XP, Windows 7, Windows 8Windows XP is not part of the integration tests anymore.

Web Browser

Internet Explorer 8/10Internet Explorer 8/10

Part of the operating systems listed here.

Other browsers (Firefox, Chrome or other versions of IE) are not part of integration tests and not officially supported.
However, EWA might work with other browsers then the mentioned ones.

Java 2 Runtime

JRE 1.7JRE 1.7http://www.java.com/download, or install the Java Runtime Environment provided from the installation DVD:
[EWA-HOME]\client-apps\jre\jre.exe

4.3 Hardware

The hardware requirements for the EWA servers have to take two things into account.

This section is intended to give a general reference that has to be adjusted individually for the environment the individual setup is intended to run in. For detailed and more recent requirements please check the Rollout Plan provided by Daimler AG.

 

Server 1000

< 1000 registered user

Server 2000

< 2000 registered user

Server 4000
2 clustered servers
with separate DB server
< 4.000
registered user
Server 8000
4 clustered servers
with separate DB server
< 8.000
registered user
Stand-alone PC

CPU

Dual Core CPU 2GHz

Quad Core 2 GHzQuad Core 2 GHzQuad Core 2 GHzCeleron D 1,8 GHz

Memory

2GB

4GB4GB4GB1GB

Free disk space

100GB100GB100GB100GB50GB

Network

Ethernet 100 MBit
(TCP/IP)

Ethernet 100 MBit
(TCP/IP)
Ethernet 100 MBit
(TCP/IP)
Ethernet 100 MBit
(TCP/IP)
Ethernet 100 MBit
(TCP/IP)
HDD ControllerSCSI / IDE / S-ATASCSI / IDE / S-ATASCSI / IDE / S-ATASCSI / IDE / S-ATAIDE / S-ATA

Operating System

As specified above

    
DVD DriveDVD 16/48DVD 16/48DVD 16/48DVD 16/48DVD 16/48

Table: EWA Server Hardware

 Minimum requirementsOptimum requirements
CPUP III 750 MhzCeleron D 1,8 GHz
Memory512MB1GB
NetworkEthernet 100 MBit
(TCP/IP)
Ethernet 100 MBit
(TCP/IP)
Display resolution1024x7691280x1024
Accessories17" TFT Monitor, 19" CRT Monitor,
Tastatur, Maus
17" TFT Monitor, 19" CRT Monitor,
Tastatur, Maus
DVD Drive--

Table: EWA Client Hardware

Four default configuration types have been defined:

  1. Central/Big:
    Central installation for large number of users connected via Internet, Intranet, Extranet, VPN; custom application server and write database
  2. Central/Small:
    Central installation for limited number of users connected via Internet, Intranet, Extranet, VPN; modified standard EWA server installation (extended database)
  3. Local/Big:
    Workshop-central server for local LAN clients and workshop subsidiaries; standard EWA server installation, modifications for failure safety possible; no Internet connection
  4. Local/Medium-Small:
    Standard EWA installation on single PC or Workshop server (PC); no Internet connection

Note:
EDC installation is not supported. EWA is not PAI compliant and installation in an therefore EDC environment needs special agreements.

Operation scenarioCentralLocal
Configuration TypeBig
Medium/SmallBigMedium/Small
Recommended for
  • non-EDC/ADC installations
  • large number of users
  • and/or high service levels needed
  • limited number of users via Internet
  • and/or limited service levels needed
  • if no centralized scenario is possible/available
  • regular workshop with LAN-connected subsidiaries
  • regular workshop location (no subsidiaries)
TechnologyIndividual setup of application servers and database servers(Modified) EWA standard installation(Modified) EWA standard installation; for failure safety a fast restore mechanism or a second EWA server is recommendedEWA standard installation on a standard PC server
OSApplication Servers and Database Servers:
   Windows 2003 Server, SP2
for Write Database Servers - alternatively UNIX
Windows 2003 Server, SP2
Application Server
  • Apache Tomcat 7.0.42
    or
  • IBM WebSphere 6.1.0.23
     
EWA standard installation
(Apache Tomcat 7.0.42)
EWA standard installation
(Apache Tomcat 7.0.42)
EWA standard installation (Apache Tomcat 7.0.42)
Write Database
  • IBM DB2 9.5 (UDB)
    or
  • MS SQL-Server 2008 R2, MS SQL-Server 2005 Service Pack 2
  • EWA standard installation (Transbase)
    or
  • IBM DB2 9.5 (UDB)
    or
  • MS SQL-Server 2008 R2, MS SQL-Server 2005 Service Pack 2
  • EWA standard installation (Transbase)
    or
  • MS SQL-Server 2008 R2, MS SQL-Server 2005 Service Pack 2
  • EWA standard installation (Transbase)
Required BandwidthIndependent of operational model, depending on number of users, usage of the application and if Citrix is used or not.
Bandwidth minimum for "central" application: 256 kbit downstream ; recommended: 2 Mbit. See document "Bandwidth Usage".
Service Location / Operation / Administration
  • EDC (for Daimler internal users and plants only)
  • ADC
    • TSS Automotive Retail Extranet (Retailfactory)
    • EWA server APAC
    • EWA server Brasil
  • MPC level (market specific in-country server, e.g. at MPC Japan operated by ITM APAC Operations Support Team in Singapore)
  • Provider
  • ...
  • Provider
  • MPC
  • Workshop
  • Workshop
Internet connectivity (server-side) possibleYesNo
VPN possibleADC OK, otherwise depends on providerdepends on provider
Samples
  • Retailfactory
  • smart-IT center (cahrs)
  • Pappas Group Austria
  • MB Canada (hosted by PQA)
  • Bertel O. Steen A/S Norway
  • WIS integrated in the STAR TekInfo-Portal MBUSA
  • Kunzmann, Aschaffenburg
  • Hess, Trier
  • Weilbacher, Eberswalde-Finow
    .. with their subsidiaries in different locations
  • Pfister, Gerolzhofen, Germany
  • Zawiwi Trading Company, Oman
  • Star Auto S.A, Abidjan, Ivory Coast

The following hardware configurations have been defined:

PropertyValue

CPU

>= Dual Core CPU 2GHz

Memory

>= 1 GB

Free disk space

>= 50 GB

Network

100 MBit/s

Operating System

As specified above

DVD-Drive

Due to large database updates, a fast DVD drive is recommended on this machine (DVD 16/48)

Table: EWA Server Hardware

Since EWA does not differ to other Web applications in this respect the same guidelines apply.  As a general rule it can be said that the amount of system memory is more important than the power of the CPU.

4.4 Network

Network route

TCP/IP Port(s)

Description

Client -> Application Server

9000
can be adjusted

Access to the EWA services if no front-HTTP server is involved.

HTTP-Server -> Application Server

needed if HTTP Frontend Server is in use

can be configured

A plugin for the correspondend application server has to be attached to the HTTP front server and talks to the web application server over the port configured for that communication.

This scenario will take place in a firewalled environment.

Application Server -> Transbase

2054/2055
WIS database

2034/2035
EPC database

Plus additional ports dynamically created per DB connection on random port numbers

Access to the information databases of WIS and EPC.

Note:
It is NOT recommended to place any kind of firewall or network restriction between application and Transbase Content database server as the range of used ports vary dynamically and can not be determined. Additionally the used database is a Read-Only database which is not of interest of attacks.

Application Server -> Transbase

2044/2045
can be configured

Access to the authorization database for EWA AccessGateway.

EWANAPI.exe (WISAPI.exe) -> Application Server

9000
can be adjusted

EWANAPI.exe (can be regarded as a normal client to the system) has to be able to access the AccessGateway in a direct manner. Proxy servers are currently not supported.

5 Installation

This chapter covers the installation steps for the application server, the database and the EWA core framework (including Access Gateway and User management).

5.1 EWA “local”

5.1.1 Run the installer

If a previous local version was already successfully installed and the user has not started the installer in unattended (the installer makes some assumptions for the user, i.e. ewa installation directory or installation language) or forced mode, the installer will stop when called in such an environment and ask you to make use of the Update program "AdminTool" (you will learn about this later on).

Note:
If you execute the installer on a Terminal Server environment be sure to execute it the setup program from the main console only and not from a TerminalServices client window. InstallShield-based installers appear to have major problems in such a scenario.

Installation requires administrative rights on Windows.

Installation

Login to Windows as Administrator or user who is part of the Administrators group.

Take your DVD of the EWA DVD release set and execute the setup file from

[DVD-DRIVE]:\ewa\setup.exe

In our example installation our path was set to “C:\EWA_net”. If you use a different path for your installation, the given command and configuration examples need to be adopted to your folder structure. By default the installer suggests the installation into the Windows standard program files folder - which is perfect for "local" EWA installations.

The installation should finish without any error messages.

5.1.2 Check the services

After the installation you will find some new links within the Favorites of your Internet Explorer

With the EWA Admin Tool you should now check the services.

The tab "Server" must display two green traffic lights, the traffic lights in the tabs "EPC" and "WIS" will remain dark until you installed the database content.

5.1.3 Register the access authorization(s)

For licensing open the EWA website (use the favorite in Internet Explorer to do so. If you performed an standard installation, you might also click here).
You will be asked for a username and password. On an initial installation these values will be

Admin Username = admin
Admin Password  = admin

Note:
You will immediately be asked to change your password now. Ensure you remember what you enter here.

Under the Button “Administration/Server/Edit the access authorization you will find the input fields for the StartKey.

Notes:
You can add StartKeys in a formatted way (with "-" as separator and with leading or trailing blanks) as well as in the plain way.

5.1.4 Add a first Group and first User

Please refer to the UserManagement manual to setup users and groups to be able to work with the system. To complete the basic installation you don't need to do this right now.

5.2 Install database content from DVDs

Retrieval Database content installation (for WIS and EPC) as well as whole EWA system updates will be performed by the EWA Admin Tool. This is a windows executable that gives you an administrative interface to some system tasks like services control, software update, database clean up, ...

You will find this tool after installation in the “Favorites” in the folder “EWA” of your Internet Explorer.

For detailed information please refer to the corresponding EWA Admin Tool documentation. ‎It describes in detail how to install new database content for both EPC and WIS.

5.3 Manual modifications

From this step forward manual steps have to be performed if you want to migrate the just installed “local” version to a fully functional “central” version.

This is documented inside special documentation you can find on the delivery media within the folder:

[DVD-DRIVE]:\ewa\central\doc (all files)

If you want to migrate to a "central" version, first copy all the files from that folder into

[EWA_HOME]:\docs

which overrides the more simple "local" documentation. Then open the freshly installed documentation from there and continue reading the documentation at the current point. You will see that there is guidance on how to migrate EWA to a central version.

5.4 Quick check of the installation

5.4.1 Check on the server

In order to verify whether all components have been correctly installed and configured it is now time to reboot your system. After having rebooted, start the Internet Explorer.

In order to check the  functionality of the administration go to the following URL:

http://localhost:9000/EWA-net

or use the “EWA net” Favorite in “EWA net” folder of the Internet Explorer. You should see the EWA start page. Log in as administrator - this is currently the only user being setup in the system.

The default Admin user name and password are set by the installers to:

5.4.2 Check on the client

If you want to check whether your clients are well prepared to perfectly run EWA, please assure the following manually steps have been completed as there are no automatic installation steps for the client:

Congratulations!

You have successfully setup a standard EWA server. To configure the system to your needs (i.e. make use of a different authentication system), please refer to the chapters about EWA configuration and advanced configuration to make the best out of your installation.

6 EWA Configuration

Many of the settings below can easily be configured via the administrative Web interface of EWA. But there is even more that can be performed by modifying the underlying XML files.

Important Note:
As mentioned earlier you should have reasonable experience and a good understanding of XML before you start editing the files mentioned below. You may easily make your EWA server fail to start even with small syntactical errors in the files.

6.1 EWA Application Server Settings

Note:
Some basic settings described here (like email Server, access authorization reminder, feedback,...) can also be modified by a user with System Administrator user role from within EWA's server administration masks.

6.1.1 core_cfg.xml

The behavior of the AccessGateway and each HP Service as well as some general settings can be configured in the [EWA_HOME]\config\core_cfg.xml file.

Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xml>
        <SECTION name="Services">
                <SECTION name="MailService">
                        <!-- Parameter emailEnabled: Set this to "true" or "false" if the Email Service is active and -->
                        <!--                         sending Emails.                                                  -->
                        <PARAMETER name="emailEnabled">true</PARAMETER>
(...)
</xml>

Parameter

Example Value

Description

ApplicationIntegration
applicationIntegrationEnabledfalseEnable or disable a list of URLs which appear in the Start menu of EWA. If set to "false" the whole section will just be ignored.
ApplicationIntegration - ApplicationDetails_x (where x is a number from 1 to n, so this section can be repeated several times for multiple applications to be integrated into your start screen of EWA)
URLofApplicationhttp://www.hp.comURL which will be opened in a new window if this button will be clicked.

If the existing session of EWA needs to be included in the URL, you can specify the token {SESSION} to be replaced with the session ID, e.g. http://myserver/otherApp.do;jsessionid={SESSION}?param=value

NameofApplicationBrowse HPName which will appear below the button
URLofApplicationIcon/EWA-net/someicon.gifURL to an image which will displayed as button
NewWindowForApplicationtrueShall this application be started in a separate window instead of overriding the current window content?
true / false
UserRoleForApplicationWorkshopAdmin, ServerAdminWhat user role will see this application in the start menu? If you do not specify one, all users will see this. You can even comma separate multiple roles.

Allowed values are:
ServerAdmin
WorkshopAdmin
WorkshopUser

ClientSettings
BrowserInternetExplorerIf the client determines it runs in a Desktop environment then this browser will be used.
You may specify "InternetExplorer" or just nothing to enforce InternetExplorer.
You may also specify something like %ProgramFiles%\Firefox\firefox.exe.
Possible values are:
  • InternetExplorer
  • InternetExplorer64
  • DefaultBrowser
  • Path to browser executable
BrowserForTerminalServerInternetExplorerThe same configuration item as for regular browser except that this entry is valid for terminal server instances.
Possible values are the same as for ClientSettings.Browser.
ClientSettings - LaunchViaServer
enabledfalseIf set to true and a client application (EPC/WIS) opens a URL in a browser then the request will be sent via the server and a cookie will be set with the user's id as its value.
cookieNameEWAnetUsernameThe name of the cookie to set
cookieDomainfalseThe domain for which the cookie is valid. An explicitly specified domain must always start with a dot. Leave empty for automatic configuration for the domain that made the request. See RFC 2109.
cookiePath/The cookie Path is the subset of URLs to which this cookie applies. See RFC 2109.
ClientSettings - RequestService
maxMemoryCacheSizeKB1024The maximum memory-cache size in KB used for client side 1st level caching of requests.
maxDiskCacheSizeKB10240The maximum disk-cache size in KB used for client side 2nd level caching of requests.
workerPoolSize5The number of simultaneous requests that the client can execute.
ClientSettings - MessageArea
minutesForStateChange10Not used anymore
ClientSettings - DownloadArea
accessfalseIf false, the download area cannot be accessed from client applications.
The menu-item to open the download area will not be visible and the URL is not accessible.
ClientSettings - LicenseArea
LicenseHandlerStandardHandlerDepending on the LicenseHandler that is configured, either the default EWA-License Handler is used or the CommonLic handler is used. If CommonLic handler is used, the licenses need to be configured the same way as on Star Diagnosis or XENTRY systems in a special file.
Possible values:
  • StandardHandler
  • CommonLicHandler
Services - AccountingService
deleteEntriesOlderThanDays180If this value is set to > 0 than entries in the accounting table which are older than the given number of days will be removed automatically. If no value has been set, a default of 180 days will be assumed.
Services - FinCacheService
NumberOfFincacheResults30Used to set the maximal Number of displayed FIN-Numbers in EPC and WIS
Services - MailService
emailEnabledtrueCan email services be used within EWA? Should be switched on and configured correctly
smtpServersome.mail.serverName or IP of the email server to be used
smtpPort25Email port on which the SMTP service listens. Standard is 25
smtpUsersomeUserOptional:
If your SMTP server needs authentication, provide this info. Leave it blank if not required.
smtpPasswordsecretOptional:
If your SMTP server needs authentication, provide the password here.
defaultFromAddressmail@ewanet.comDefault email address that will be used if not overridden by a service using the email service.
Services - ManagementService
managementEnabledtrueEnable or disable the JMX management console with this switch. For further options please take a look to the Monitoring and Management section.
Services - Portalnterface
portalServiceEnabledfalsePortal Service is switched off by default. Using this configuration enabled, users, groups and workshops can be administered remotely using WebServices. Please take a look to the user management documentation for more details!
userExpirationTimersfalseExtension for portal service configuration, enables global option to define expiration times for EWA user accounts for blocking access after a certain time.
treatUsersWithUndefinedValidityAsAlwaysValidfalseIf expirationTimer is activated (see Services.Portalnterface.userExpirationTimers) and users exist without an expiration time set, those users should be treated as always valid. Otherwise (false) users without an expiration time set are always invalid.
activationDurationsfalseList of provided license durations for the portal selection.
Must be a comma separated list of integer values which represent the milliseconds as duration.
externalHostNameewanet.external.daimler.comExternal host name to use when trying to generate the JNLP for starting up clients.
NOTE: The hostname must be the name which is the external DNS name to contact the server. The hostname must also be valid for the server itself!
Services - GenericStorageService
startStorageCleanupDeamontrueFlag to decide if the GenericStorageService-Deamon should be running at all
startTime24:00Time when the GenericStorageService-Deamon should run
disableWorkshopVisibilityfalseShall the workshop community level be switched off for internal storage of data? If switched off even data that should be visible for all users of a workshop will then only be visible to the one who is the "owner" of the information
batchQuerySize100Integer to configure the maximum number of keys which are used in a single queries to the GenericStorageService. Queries which have more keys will be broken up into batches of the defined size. The default configuration is 100.
cacheablePrefixesCSVEPC:MANUFACTURERNOTE:,EPC:MARKETNOTE:Comma separated list of Prefixes of GSS key prefixes that should be cached.
If the CacheablePrefixesCSV value is empty or if CacheablePrefixes is not defined then caching will be deactivated.
cacheRefreshIntervalMinutes60The number of minutes between each GSS cache refresh. During a refresh the cache will be emptied and all keys matching the "CacheablePrefixes" list will be read from the database and put in the cache.
Services - DataExchangeService (See also dataExchangeSubscribers_cfg.xml)
starttrueActivate the notification service? true or false.
sleepTimeOnIdleMillis250How many milliseconds will be slept if there were no outstanding notifications.
sleepTimeOnErrorMillis5000How many milliseconds will be slept if there was an error when sending a notification.
maxQueueSize1000The maximum number of outstanding notifications queued for a single subscriber. If a new entry is added and the max queue size is exceeded then the oldest entries are discarded to reduce the size.
minimumAgeDays7The minimum age in days that an entry must be before it will be automatically deleted by the cleanup service.
Services - AuthSyncService (only for usage of MPC Self Service)
starttrueActivate the service? true or false.
queueFactoryAuthSyncQueueConnectionFactoryName of the JNDI Element for the DealerDirectory Message Queue Connection Factory. This will be prefixed with java:comp/env/jms/
queueNameAuthSyncQueueName of the JNDI Element for the DealerDirectory Message Queue. This will be prefixed with java:comp/env/jms/
errorQueueNameAuthSyncErrorQueueName of the JNDI Element for the Error Message Queue where messages from the AuthSyncQueue get moved to if there has been an error. This will be prefixed with java:comp/env/jms/
heartbeatSeconds10Time in seconds between heartbeat log entries. Log entries are for monitoring purposes. At each heartbeat the Message Queue connection will be retried if it had failed previously.
ldapURLldap://server.example.com:389The URL to connect to the LDAP directory server.
ldapUserDNuid=admin,ou=systemThe distinguished name of the user to connect to the LDAP directory server.
ldapPasswordsecretThe password of the user to connect to the LDAP directory server.
ldapWorkshopSearchBaseDNou=organizations,o=exampleThe base distinguished name to search for a workshop in LDAP directory.
ldapWorkshopSearchFilterouThe filter to search for workshops in the LDAP directory. With the filter 'ou' every workshop is taken that matches the ldapWorkshopSearchBaseDN.
storeRetailFactoryThe implementation of the AuthSyncService-Store to use. Currently there are 3 stores available:
  • Trace - a simple trace store to write AuthSync-Data into a logfile
  • CoreDB - a store implementation to write AuthSync-Data into the EWA core database. Note: This store is not implemented completely and should not be used.
  • RetailFactory - a store that uses the CDP Web Service to sync the data with the different Retailfactory databases and directories.
storeNotAvailableWaitSeconds30How long to wait before retrying when the store (e.g. CDP Web Service) is not available.
storeErrorWaitSeconds30How long to initially before retrying wait when there was an store (e.g. CDP Web Service) error (that is not a not available error).
maxCountStoreError5The maximum number of consecutive store errors which can occur, before a message is moved to the error queue.
maxCountErrorQueue30The maximum number of consecutive message that can be moved to the error queue before the AuthSyncService stops.
webServiceWSDLLocationhttps://example.com/example?wsdlThe location of the WSDL-file of the CDP Web Service used by the Retailfactory store.
webServiceUsernameexampleThe username to connect to the CDP Web Service used by the Retailfactory store
webServicePasswordsecretThe password to connect to the CDP Web Service used by the Retailfactory store
acceptAllSSLCertificatesfalseTrue to accept CDP Web Services that use a Self Signed SSL Certificate. This prevents the need to manually add the certificate to the EWA JRE's truststore.

AccessGateway - ApplicationSettings

sslEnabled

false

If SSL will be used within the WebApplication of EWA.

Note:
This is not the only key to be used for the administration of SSL. Please see the section Setting up SSL for more info.

sslForClientsEnabledfalseThis setting determines, if SSL should be used for communication between client applications and EWA server. If set to true the client applications will communicate via https with the EWA server.
Make sure that also SSL for EWA in general is set to true and check the other settings for setting up SSL.
useExternalSSLModulefalseThis setting requires using an external SSL module, e.g. NetScaler, to ensure SSL termination. If set to true the client applications will communicate via https with the EWA server.
Still, the EWA server internally uses HTTP. Ensure that the parameters sslEnabled and sslForClientsEnabled are not set to true. Make sure that the SSL termination is configured correctly.

httpPort

9000

Port for http

httpsPort

8443

Port for https (SSL).

AccessGateway - Proxy (only for StarTekInfo portal integration)

proxyEnabled

false

Enables EWA server to connect to outside (e.g. to external User Management) via proxy.

host

proxy.daimler.com

Host name (e.g. for proxy setting)

port

8088

Port (e.g. for proxy setting)

noProxy

localhost|15.*

No proxy will be used for those addresses. Use Java syntax (e.g. "|" for separating two values)

AccessGateway - LicenseExpirationReminder (access authorization expiration reminder)

emailEnabled

true

Set this to "true" or "false" if the access authorization reminder service is active and sending Reminder Emails at times where the access authorization is near to expire.  All users in the system being administrators will be sent an email as soon as one of the access authorizations is about the expire

userWarningsEnabled

true

Set this to "true" or "false" if users should be warned by a popup-dialog inside the applications.

fromAddress

startkey@ewanet.com

Email sender address to use as from address in the sent emails. For most email-gateways this needs to be available.

ccAddresses

 

Email destination addresses to deliver a copy of the messages to.The email-addresses should be entered comma separated. This field is not required if no recipents are needed for CC.

daysBeforeEmailReminder

14

Timout in number of days from which on warning messages are being sent out by the reminder service to the list of specified server administrators.

emailRepeatHours

48

Number of hours after which the server repeats in sending Email reminders about the upcoming expiration of the access authorizations.

daysBeforeUserNotification

3

Number of days before reminders are showing up on  user interfaces to remind the administrator to aquire new access authorizations.

SiteMinder
siteMinderEnabledtrueSet to true if the EWA server is protected by SiteMinder
authURLPattern\Ahttps://login\.eg\.com/Security/login\.fcc.*The Java Regular Expression which matches positive for the SiteMinder URL to which a request is redirected when authentication is required.
formLoginThe name attribute of the SiteMinder authentication HTML <form> element. If the value is not set then the first form will be assumed.
Note: This implementation requires form-based Siteminder authentication.
formUserUSERThe name attribute of the HTML element where the Username must be entered.
Note: This implementation requires form-based Siteminder authentication.
formPasswordPASSWORDThe name attribute of the HTML element where the Password must be entered.
Note: This implementation requires form-based Siteminder authentication.
formSubmitSUBMITCURRRENTLY NOT USED. The name attribute of the HTML element used to submit the form.
Note: This implementation requires form-based Siteminder authentication.
formCredCookieFORMCREDThe name of the Form Credentials Cookie set by SiteMinder in response to submitting user credentials to the Authentication screen.
Note: This implementation requires form-based Siteminder authentication.
sessionCookieSMSESSIONThe name of the SiteMinder Session Cookie set by SiteMinder in response to submitting a request with a Form Credentials Cookie containing valid user credentials.
Note: This implementation requires form-based Siteminder authentication.
Feedback (please refer to the Feedback configuration description)
EnabledtrueWhether feedback feature is enabled or not.
Modusxml-postValid values can be:
 fax
email
email-or-fax
Customer Support & Feedback (CSF) related options (use of this option may depends on the timeline of the CSF project):
 csf-email
 csf-fax
 xml-post (default)
EpcModemdWorking mode of EPC - md, sa, paints and fluids (pf)
RecipientsConfigFilefeedbackRecipients.xmlSpecifies the addresses (fax or email) in a distinct level of detail. A simple default configuration has been provided which you can easily adjust to your needs.

The default looks like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<feedback-recipients xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="feedbackRecipients.xsd">
    <default preferred="fax">
        <email>john.doe@daimler.com</email>
        <fax>+49-711-17-0</fax>
    </default>
</feedback-recipients>
 

TransferConfigFilefeedbackTransfer.xmlThis specifies the file which is responsible for selecting the appropriate feedback channel (Fax, EMail or XML transfer).

This file does not have to be touched and will be updated by the installer automatically.

FeedbackAppURL/Feedback/submitAppContext.doWhich URLs do the applications have to call to submit their feedback context.

Do not touch. This field will be overridden by software updates.

Internal - FeedbackEmailEmpty by defaultYou may want to use this setting if you want to force one single email address to be set as receiver for all your emails in case email is being used as Feedback channel and will even override any automatically determined address from the mapping file feedbackRecipients.xml

Recommendation is to leave this field empty unless you make use of the global Feedback email router (ask your MPC whether your country has been setup there).

Internal - FeedbackFromEmailjohn.doe@daimler.comSet the sender address for feedback which will appear as sender for feedback generated emails in case that Feedback uses EMail as channel.
CustomerServiceRequest - URLhttps://aftersales.i.daimler.com/XentryFrameWeb/Welcome.doThe URL to open a customer support ticket.
Should not be used anymore, as the default feedback system should be XSF now.
CSF -> SelectablefalseFlag if the admin user can select the CSF related options as mode in feedback modus on the admin's server configuration web page within EWA.

Do not touch. This field will be overridden by software updates.

CSF -> URLhttp://aftersales-net.daimler.com/supportURL where to post feedback information to in case of a XSF integration.

Do not touch. This field will be overridden by software updates.

XSF -> XMLMapFile (Optional) Debug option: Write a XML file of each data request which is processed in feedback, if provided
XSF -> XMLFile (Optional) Debug option: Write a XML file to disk each time a XML is posted to feedback server - this writes a file which exactly the content which is sent to feedback back-end using HTTP Post.
Backup
root_folderewa_backupBackup directory for the built in user management database. Has to be provided relative to [EWA_HOME]
Cluster
EnabledfalseIndicate here whether you run a clustered environment. In this case i.e. the simple configuration screen will be switched off and you have to assure to configure all servers consistently based on XML file configuration manually.
This approach has been chosen to avoid confusing side effects as in a cluster you cannot determine on which server you currently modify settings.
Spooler
ASRASpooloutdownloads/spooler/asraThis is the default value where the ASRA spooler files will be expected. Do not touch this setting unless you know what you do. It is the correct default for the interactive spooling.

This path is relative to your EWA home directory.

You may change this setting to an absolute path somewhere else (i.e. on a network share) if you want to run spooler jobs via "Scheduled Tasks". In this case ensure that all servers in a cluster have the same path information and that your EWA server runs as a service with a user account having access to network locations (the "system" account does not have these privileges)

Please find more information about the spoolers here

DamageCodeSpooloutdownloads/spooler/damagecodeThis is the default value where the DamageCode spooler files will be expected. Do not touch this setting unless you know what you do. It is the correct default for the interactive spooling.

This path is relative to your EWA home directory.

You may change this setting to an absolute path somewhere else (i.e. on a network share) if you want to run spooler jobs via "Scheduled Tasks". In this case ensure that all servers in a cluster have the same path information and that your EWA server runs as a service with a user account having access to network locations (the "system" account does not have these privileges)

Please find more information about the spoolers here

UserReporting
EnableExtendedUserTypefalseFlag if the user reporting extension is active. This will display further options in the Web GUI for managing users to types.
SendUserReportfalseFlag if the user reporting sends out emails. When running in a clustered environment on ONE node should send out the user reports.
ReportDirectoryreportsPath for saving the report files on the disk.
A relative path will be relative to the EWA server installation.
The reports names are of the form: \\_userreport.html
UserReporting - accounting
In this section the EWA accounting report is configured. This report is generated to send accounting information about this installation of EWA to the licensing department of Daimler AG.
This section needs to have the requestingID set to accounting. In order have this report sent the value for "active" should be set to true.
Note: Please be aware that this report has to be sent to the licensing department of Daimler in order to create invoices to the customers. However, this report should not be generated for local and test installations.
ExportTime00:00The time of the day when the report is to be executed.
ExportDatedailyThis value needs to be set to daily, as the report has to be sent every day.
ExportDay1This value needs to be set to 1, as the report has to be sent every day.
TargetAddressTostartkey.ordering@daimler.comThe target email address where to send the report to. This email address has to be startkey.ordering@daimler.com in order to create correct accounting data.
TargetAddressCctest@test.deAdditional email address where the report should be sent to in CC-field of the email.
Note: Multiple CC-Addresses can be configured by adding multiple lines of the parameter TargetAddressCc.
ManufacturerNotes
root_folderSBSmanufacturerNotesDirectory for the exporting EPC manufacturer notes. Has to be provided relative to [EWA_HOME]
ClientPerformanceLogging
LoggingIntervalMinutes5If client performance logging is used, this variable determines after how many minutes the client should send his logged data. The default is 5 minutes.
More information about client performance logging can be found in the user management documentation.
AdditionalClientOptions
privateJREVersionOracle Java SE 7 Update 25The version of Java Runtime that is included in EWA. This is just the version text to be displayed on the EWA download page.

Table: core_cfg.xml

6.1.2 license.xml

Location: [EWA_HOME]\config\license_cfg.xml

This configuration file contains the server access authorizations for EPC and WIS of the EWA application server.

Example:

<?xml version="1.0" encoding="UTF-8"?>
<xml>
<SECTION name="Licenses">
     <PARAMETER name="wis">J9GF4AXXXXXXX...</PARAMETER>
     <PARAMETER name="epc">ZYVND3XXXXX...</PARAMETER>
</SECTION>
</xml>

 

Parameter

Example Value

Description

wis

J9GF4AXXXXXX...

Server access authorization for WIS. The access authorizations can define a timeout. Also it specifies the maximum user access rights. The access authorization has to be requested from the EWA software provider (e.g. Daimler).

epc

ZYVND3XXXXXXX...

Server access authorization for EPC. The access authorization can define a timeout. Also it specifies the maximum user access rights. The access authorization has to be requested from the EWA software provider (e.g. Daimler).

Table: Section "Licenses"

Note:
If your server runs several redundant LAN adapters you might get server access authorizations for each of these LAN adapters and add those access authorizations comma or semicolon separated here to support high availability.

6.1.3 um_cfg.xml (and um_batch_cfg.xml)

These files are located at [EWA_HOME]\config\um_cfg.xml

These configuration files contains all configuration concerning user management. The file um_cfg.xml is used for online authentication whereas um_batch_cfg.xml contains the configuration for batch calls as they are used for instance by "EWANAPI.exe". Within the config files it is defined which authentication mode to use and what the connection parameters to the authentication / authorization datastores look like.

Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xml>
    <SECTION name="General">
        <!-- Type of user management; valid Entries are: StarTekInfo, HPUserManagement -->
        <PARAMETER name="userManagementService">HPUserManagement</PARAMETER>
(...)
</xml>

 

Parameter

Example Value

Description

userManagementService

HPUserManagement

User management, that will be used. Currently possible values are:
StarTekInfo, HPUserManagement

Note:
All following parameters do only make sense, if HPUserManagementis used here. Otherwise they are disregarded.

authenticationMode

Own

Authentication mode for HPUserManagment. User Logon (login and passwords) can either be authenticated by interfacing the DC-Corporate Directory or – if not applicable – against the own system database.

Currently possible values are:
Own, CorporateDirectory, LDAP

useOwnAuthOnConnectError

false

Use Own Authentication as fallback if external call to LDAP or Corporate Directory fails with an Exception (e.g. connection error)

Currently possible values are:

true, false

useOwnAuthOnAuthError

false

Use Own Authentication as fallback if external call to LDAP or Corporate Directory results in a non-authenticated result, e.g. username or password not correct.

Currently possible values are:

true, false 

reAuthenticationEnabled

true

Configuration for en-/disabling automatic Re-Authentication.

Valid entries are: true, false

passwordChangeActive

true

Configuration for en-/disabling Own DB Password Change, which means that the user might change his/her password on his/her own.

Valid entries are: true, false

userEditActivetrueConfiguration for en-/disabling Own DB User's Details Edit. If set to false the user can not change its users details. In this case only the server administrator is able to change user details.

valid entries are: true, false

loginPagehttps://retailfactory.mercedes-benz.com/031_LoginEWAnet_de.aspxLogin page where is user is redirected to if session expired or user clicks on log off button on user management screen.

Please provide a fully qualified URL here.

If not configured the default EWA login page will be used.

cascadedAdministrationfalseSwitched off by default, which means there is only one workshop which has all the access authorization the server StartKey provides.

If switched on ("true") the mode changes and you can setup several workshops, where each workshop is limited individually in the number of allowed users per application

showReqmntsOnLoginfalseThere is an automated check whether the system on which the EWA clients shall run is configured sufficiently to run EWA. It basically checks for the correct Java and Java WebStart. It might not be able to run this scripted Active/X thus to avoid annoyances switch this check off here for the login screen.

Nevertheless this switch is integrated anyway in the downloads area

hostNameLabelOverrideMy EWA Server InstallationLabel which is shown in the user management pages instead of server host name and IP address.

This can be used in a clustered environment when the server administrator does not want to expose the internal server host names.

If this field is left empty, the default server host name will be used.

marketNotesEditorialSupportfalseFlag if Market Notes editors can be specified in user management administration.

If this is set to true, users can have the permission to edit Market Notes and Market Note sets can be exported.

valid entries are: true, false

userBasedDownloadPermissisonsfalseFlag if additional download permissions can be enabled per user for spooler files.

If this is set to true, each user has a additional option to be administered which allows enabling of spool files downloads.

valid options are: true, false

Own
inviteUserPerEMailEnabledtrueDo you want to allow the service that on interactive creation of users an email will be generated inviting the user to EWA?
forgotPasswordButtonAvailabletrueDetermines if the button "Forgot Password" should be displayed on EWA login page.
enforcePasswordChangetrueIf the password has expired or has been created by a System Administrator, the User will be forced to change it before he is able to continue his work. This typically happens during the first login.
passwordChangeReminder14Amount of time before password expiration when EWA shall start to request a password change. Until final expiration this request can be skipped.
passwordChangeInterval60Number of days a password remains valid and does not have to be changed.
paginationPagesize15Number of entries that will be displayed on one page when performing searches
paginationSmallPagesize10Number of entries that will be displayed on small pages when performing searches. This is only used in batch user edit page.
searchIsCaseSensitivefalseShall the search on the UserManagement database be performed with case sensitity on?
tokenActiveMinutesAfterStart30Minutes after web session expiration to be able to reauthenticate the user. This parameter is used for reauthentication during client application start (validity time for start JNLP file).
tokenActiveMinutesAfterReinitialization480Minutes after web session expiration to be able to reauthenticate the user. This parameter is used for reauthentication when client is started and running already.
tokenMinMinutesBeforeUpdate10Defines the interval in which the token validity is updated. In order to not update the token expiration time with every request, this interval defines a timeframe in which the token is not updated.

Table: Section "General"

Contents of section "CorporateDirectory":

Parameter

Example Value

Description

ldapHost

hptis106.bbn.hp.com

The hostname, where the Corporate Directory resides within Daimler

ldapPort

389

The port, on which the Corporate Directory Service listens

bindDN

CN=test,cn=Users,DC=DC-EWO,DC=bbn,DC=hp,DC=com

The full qualified LDAP bind user, which is used to connect to the Corporate Directory

bindPasswd

very_secret

The password of the LDAP bind user, which is used to connect to the Corporate Directory

Table: Section "CorporateDirectory"

Contents of section "LDAP"

Parameter

Example Value

Description

ldapHost

192.168.0.55

The hostname, where the Directory resides.

ldapPort

389

The port, on which the Directory Service listens

ldapFallbackHost

192.168.0.56

The hostname, where the Fallback Directory resides. This directory host is used if the ldapHost is not available.

ldapFallbackPort

389

The port, on which the Fallback Directory Service listens. This directory host is used if the ldapHost is not available.

bindDN

CN=ewa, CN=Users, DC=RES, DC=CAHRS, DC=CORP

DN (Distinguished Name) used to establish the LDAP-Connection. If this field is empty, the connection will be made anonymously.

Note:
If authMode="authenticate", Tokens {userid}, {password} and {domain} will be replaced by the submitted login information.

Before replacing the tokens by the values entered in the login mask, the characters "*()" from the entered values will be escaped!

Example: authentication with LDAP:
bindDN="CN={userid}, CN=Users, DC={domain}, DC=CAHRS, DC=CORP"

Example: fixed binding with "fetch" or "search":
bindDN="CN=EWAnet, CN=Users, DC=RES, DC=CAHRS, DC=CORP"

bindPasswd

ewaewa

Password to use when binding with bindDN

Note:
If authMode="authenticate", Tokens {userid}, {password} and {domain} will be replaced by the submitted login information. Before replacement, the characters "*()" will be NOT escaped!

Example: authentication with LDAP:
bindPasswd="{password}"

Example: fixed binding with "fetch" or "search":
bindPasswd="secret!?"

useSSL

false

SSL with LDAP is currently not supported.
For later use if connection will be made secure.

authMode

search

authMode: Authentication mode to use to verify user permissions:

  • fetch
    Fetch LDAP record from directory and compare defined attribute with submitted user password
  • search
    Search for user in directory and compare defined attribute with first matched LDAP entry's attribute
  • authenticate
    Try to bind LDAP with submitted user name and password.
  • search+authenticate
    Best used with a MS ActiveDirectory

fetchDN

CN={userid}, OU={domain}, DC=RES, DC=CAHRS, DC=CORP

Name of the DN to fetch to compare attribute. Only applicable if authMode="fetch".

Note:
Tokens {userid}, {password} and {domain} will be replaced by the submitted login information.

Before replacement, the characters "*()" will be escaped (see "bindDN" above)!

searchFilter

sAMAccountName={userid}

Filter attribute name which will be searched on the LDAP search if a LDAP user entry needs to be found in the directory. e.g. "sn", "mail", etc...

Only applicable if authMode="search" or "search+authenticate". See RFC 2254 for a detailed description of LDAP filters

Note:
Tokens {userid}, {password} and {domain} will be replaced by the submitted login information.

Before replacement, the characters "*()" will be escaped (see "bindDN" above)!

Example:
searchFilter="mail= {userid}@smart.com"
or
searchFilter="mail =*_{userid}@{domain}.smart.com"

Example2:
searchFilter="(&(mail=*{userid}*)(co=*{domain}*))"

searchScope

CN=smart-center, DC={domain}, DC=cahrs, DC=corp

Context which will be searched for an LDAP user entry. Only applicable if authMode="search".

Note:
Tokens {userid}, {password} and {domain} will be replaced by the submitted login information.

Before replacement, the characters "*()" will be escaped (see "bindDN" above)!

Example:
searchScope="CN=Users,DC={domain},DC=cahrs, DC=corp"

attribute

ipPhone

Attribute to read from LDAP entry for comparism with the submitted login information.

Only applicable if authMode="fetch" or "search".

Example:
attribute="ipPhone"

encryptAttributeBeforeCompare

false

Set to "true" if the LDAP-attribute needs to be encrypted before comparison with submitted login information (requires that the entered Password, is already encrypted and LDAP information is not encrypted).

Only applicable if authMode="fetch" or "search".

Note:
The used encryption algorithm is identical to the one in the HP-Usermanagement "Own" mode.

encryptPasswordBeforeCompare

false

Set to "true" if the submitted login password needs to be encrypted before comparison with the LDAP attribute (requires that the LDAP information is stored encrypted or is encrypted before comparison by setting encryptAttributeBeforeCompare to true).

Only applicable if authMode="fetch" or "search".

Note:
The used encryption algorithm is identical to the one in the HP-Usermanagement "Own" mode.

Table: Section "LDAP"

For more information about the LDAP configuration, please see the chapter about User Management configuration.

Contents of section "UserManagementURL"

Parameter

Example Value

Description

LDAPUserManagementURL

http://URL.to.your.user.management/site

The URL to the ldap user management site (if Authentication mode is "LDAP").

CDUserManagementURL

http://URL.to.your.user.management/site

The URL to the ldap user management site (if Authentication mode is "CorporateDirectory").

Table: Section "UserManagementURL"

Contents of section "External"

Parameter

Example Value

Description

defaultCountryCode

200

County code to use for all user if external user management does not provide sufficient details.

Table: Section "External"

6.1.4 secure_linkout_cfg.xml

The behavior of the Secure Linkout and SD Media feature of EWA (token generation to access sensitive data) is configured in the [EWA_HOME]\config\secure_linkout_cfg.xml file.
URLs configured to use the Secure Linkout or SD Media mechanism will be appended by some additional parameters when opened by the client applications WIS or EPC.

Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xml>
        <!-- All settings for the secure linkout -->
        <SECTION name="SecureLinkoutConfig">
                <!-- Trigger to enable secure linkout mechanism -->
                <PARAMETER name="EnableSecureLinkout">true</PARAMETER>
                <!-- Section that is used to list URLs to the Retail Factory's Secure Linkout Server providing additional multimedia documentation material for WIS/ASRA -->
                <SECTION name="SecureLinkout">
                        <!-- The URLs to the productivly used documentation material -->
                        <SECTION name="URLs">
                        <PARAMETER name="totalAmount">6</PARAMETER>
                        <PARAMETER name="1">http://retailfactory.mercedes-benz.com/XBC/index.html</PARAMETER>
(...)
</xml>

Contents of section "SecureLinkoutConfig"

Parameter

Example Value

Description

EnableSecureLinkouttrueEnable or disable the secure linkout mechanism. If disabled the URLs will be just opened without appending any parameter.
SecureLinkout
GlobalTimeURLhttp://retailfactory.mercedes-benz.com/axis2/services/ValidationTimeService?wsdlThe URL to the global time web service for secure linkout.
TestModefalseEnable or disable test mode for Secure Linkout URLs. If testmode is enabled an a TestURL is defined for a URL then this URL will be replaced by the TestURL before opening the browser.
SecureLinkout - URLs
totalAmount6The number of URLs that are defined in the list of Secure Linkout URLs. If the number is lower than the actual amount of URLs in the list, only the first x URLs will be used.
Note: The value for totalAmount needs to be set correctly!
URL ID (e.g. 1)http://retailfactory.mercedes-benz.com/XBC/index.htmlEach URL that is supposed to use the Secure Linkout mechanism needs to specified in this list and has to use a separate ID.
SecureLinkout - TestURLs
URL ID (e.g. 1)http://retailfactory.mercedes-benz.com/test/XBC/index.htmlA test URL ID has to match a URL ID. If TestMode is enabled and a URL is opened that URL will be replaced by the Test URL.
SDMedia
UserWindow3600The time frame, how long the SD media token should be valid.
TestModefalseEnable or disable test mode for SD Media URLs. If testmode is enabled an a TestURL is defined for a URL then this URL will be replaced by the TestURL before opening the browser.
SDMedia - URLs
totalAmount6The number of URLs that are defined in the list of SD Media URLs. If the number is lower than the actual amount of URLs in the list, only the first x URLs will be used.
Note: The value for totalAmount needs to be set correctly!
URL ID (e.g. 1)http://WSM-mercedes-benz.edgesuite.net/index_de.htmlEach URL that is supposed to use the SD Media mechanism needs to specified in this list and has to use a separate ID.
SDMedia - TestURLs
URL ID (e.g. 1)http://WSM-mercedes-benz.edgesuite.net/test/index_de.htmlA test URL ID has to match a URL ID. If TestMode is enabled and a URL is opened that URL will be replaced by the Test URL.

Table: "secure_linkout_cfg.xml" - Section "SecureLinkoutConfig"

6.1.5 additional_downloads_cfg.xml

This is an optional file which will neither be installed by the installer nor be updated or modified by any software installation process. Thus if you want to integrate your own download sections within EWA's download section please follow this short description and have a closer look into an example file which will show you how to customize your environment in respect to download options.

The configuration file will be read each time the download page will be shown so you may customize it without the need of restarting the EWA server.

The file must be created and stored within the [EWA_HOME]\config folder with the given name additional_downloads_cfg.xml.

The basic structure of the file is as this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xml>
        <!-- Section to enter further downloads to the download area -->
        <SECTION name="AdditionalDownloads">
        ....
        </SECTION>
</xml>

What we have created up to now is an extension of the downloads section with exactly 0 new entries. So we need to add the subsections which will show up inside the download area. We add an enumeration of sections called "AdditionalDownload_x" where x is a number from 1 to the number of sections you want to add.

Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xml>
        <!-- Section to enter further downloads to the download area -->
        <!-- UserRoleForApplication can take more than one value, the roles should be comma separated -->
        <!-- The valid values for UserRoleForApplication are: ServerAdmin, WorkshopAdmin, WorkshopUser -->
        <!-- The default value for UserRoleForApplication is WorkshopUser, WorkshopAdmin, ServerAdmin -->
        <SECTION name="AdditionalDownloads">
                <!-- Start your enumeration with value "_1" and enumerate your keys from there -->

                <SECTION name="AdditionalDownload_1">
                        <!-- Description can be provided multiple times if you want to specify descriptions in different languages -->
                        <!-- But then ensure there is at least one default text without "locale=" specification -->
                        <PARAMETER name="Description" locale="en">This text will show up in anglish &lt;br&gt;if browser requests english</PARAMETER>
                        <PARAMETER name="Description" locale="de">Dieser Text erscheint in Deutsch wenn der Anwender Deutsch als Sprache eingestellt hat</PARAMETER>
                        <PARAMETER name="Description">This is the default text which will show for all other browser languages. We better use English here :)</PARAMETER>
                        <!-- Location to download, absolute path or, by use of URL-Rewriting, a relative EWA Server reference -->
                        <PARAMETER name="URLofDownload">http://www.hp.com</PARAMETER>
                        <PARAMETER name="LinkText" locale="en" >Have a closer look on the HP Page i.e. for Driver Updates</PARAMETER>
                        <PARAMETER name="LinkText" locale="de" >HP Download Seite</PARAMETER>
                        <PARAMETER name="LinkText">HP Download Page</PARAMETER>
                        <!-- User Role that has access to this download. If not specified, all users may have access to it -->
                        <PARAMETER name="UserRoleForApplication">WorkshopUser, WorkshopAdmin, ServerAdmin</PARAMETER>
                </SECTION>

                <SECTION name="AdditionalDownload_2">
                        <PARAMETER name="Description">The link for the EWANAPI Installer provided here again</PARAMETER>
                        <!-- Location to download, absolute path or, by use of URL-Rewriting, a relative EWA Server reference -->
                        <PARAMETER name="URLofDownload">/EWA-net/ewanapi_installer.jnlp</PARAMETER>
                        <!-- Shall we include/do we need to include session information in the URL? Default: false -->
                        <PARAMETER name="URLdoRewriting">true</PARAMETER>
                        <PARAMETER name="LinkText">EWANAPI Installer (again)</PARAMETER>
                </SECTION>

                <SECTION name="AdditionalDownload_3">
                        <PARAMETER name="Description">Download and run a setup located at [EWA_HOME]\downloads\test\Setup.exe</PARAMETER>
                        <!-- Location to download, absolute path or, by use of URL-Rewriting, a relative EWA Server reference -->
                        <PARAMETER name="URLofDownload">/EWA-net/download/downloads/test/Setup.exe</PARAMETER>
                        <!-- Shall we include/do we need to include session information in the URL? We MUST use session information to allow access to download below the "downloads" directory-->
                        <PARAMETER name="URLdoRewriting">true</PARAMETER>
                        <PARAMETER name="LinkText">Some sample Setup</PARAMETER>
                </SECTION>

        </SECTION>
</xml>

Following parameter tags can be used:

The example from above will result in a download area extension like this:

6.2 Feedback

6.2.1 Introduction

EWA is offering you a direct linkout to the Customer Support & Feedback (XSF) application of Daimler in order to deliver your feedback (corrections of documentation, improvements, handling problems etc.) to the proper parts of the After Sales organization. The problem areas generally occurring in the workshop are clearly defined by so called event categories.

Since several releases the default feedback variant used to submit feedback in EWA is XSF (mode: xml-post). Other options (Email, Fax) are still available, but need to be configured explicitely.

6.2.1.1 Feedback Channel: Fax

6.2.1.1.1 Preconditions

This type of Feedback channel provides the lowest level of integration and process benefit, but is the one that is expected to work almost everywhere - this is why it has been chosen as default configuration. Please choose this channel in case

In this case the only feasible option to be used is fax. This mode will automatically assemble all the relevant context information from the client applications (EPC, WIS/ASRA), create a printout with feedback information from the client and allow this printout to be faxed. The printed fax will contain the correct fax number to send this fax to.

6.2.1.1.2 Configuration

Steps to be performed on the server side for this configuration are:

  1. Go to the [EWA_HOME]\config directory

  2. core_cfg.xml: Set the feedback "Modus" parameter to fax.

  3. Make a copy of the file feedbackRecipients.xml as faxRecipients.xml.  This should be done to avoid that a software update will override the file.

  4. Edit the file and change the default value of the parameter <fax> to the value of your choice where you want/must send your feedback information to.
    Example: <fax>+49 (711) 17-12345</fax>

  5. core_cfg.xml:
    Set the feedback file reference parameter "RecipientsConfigFile" to the new filename you have chosen to create above like this:
    <PARAMETER name="RecipientsConfigFile">faxRecipients.xml</PARAMETER>

  6. Restart your EWA server and give feedback a try.

6.2.1.2 Feedback Channel: Email

6.2.1.2.1 Preconditions

This type of Feedback channel provides a better integration and process benefit, but can only be used if some preconditions can be met. Please choose this channel in case

If these requirements can be met you may choose  email as your Feedback Channel. This mode will automatically assemble all the relevant context information from the client applications (EPC, WIS/ASRA) and create a feedback email in a specific format. Users will not have.

6.2.1.2.2 Configuration

Steps to be performed on the server side for this configuration are:

  1. Go to the [EWA_HOME]\config directory

  2. core_cfg.xml: Set the feedback "Modus" parameter to email.

  3. Ensure that the EWA email service (Parameter "MailService" is up and running and setup correctly. You may test it via the "Messaging" option of EWA.

  4. Email recipients - option 1:
    If your country is setup in the global Daimler Email router for Feedback (please get in contact with your MPC about that) you may simply use the functionality of that email router by setting the property "FeedbackEmail" in the core_cfg.xml to the value: test.gspsupport@daimler.com

  5. Email recipients - option 2:
    If you want to setup your own Email routing to different locations you may want to make use of the advanced features of EWA's Feedback. In this case please make a copy of the file feedbackRecipients.xml as emailRecipients.xml and adjust the file core_cfg.xml:
    Set the feedback file reference parameter "RecipientsConfigFile" to the new filename you have chosen like this:
    <PARAMETER name="RecipientsConfigFile">emailRecipients.xml</PARAMETER>.
    Edit the file according to the description of the feedbackRecipients.xml file.

  6. Restart your EWA server and give feedback a try.

6.2.1.3 Feedback Channel: Email-or-Fax

6.2.1.3.1 Preconditions

This type of Feedback channel is an automatic switch between Fax and Email depending on the setup of your feedbackRecipients.xml file which works like a decision matrix. Basically the same preconditions as for email and fax (see above) apply here.

Basically you will only want to do this if you have the full responsibility of different fax channels and you are not able to use the global email router or one single fax number for feedback.

If these requirements can be met you may choose  email-or-fax as your Feedback Channel mode.

6.2.1.3.2 Configuration

Steps to be performed on the server side for this configuration are:

  1. Go to the [EWA_HOME]\config directory

  2. core_cfg.xml: Set the feedback "Modus" parameter to email-or-fax.

  3. Ensure that the EWA email service (Parameter "MailService" is up and running and setup correctly. You may test it via the "Messaging" option of EWA.

  4. As you want to setup your own Email and Fax routing to different locations you will want to make use of the advanced features of EWA's Feedback. In this case please make a copy of the file feedbackRecipients.xml as recipients.xml and adjust the file core_cfg.xml:
    Set the feedback file reference parameter "RecipientsConfigFile" to the new filename you have chosen like this:
    <PARAMETER name="RecipientsConfigFile">recipients.xml</PARAMETER>.
    Edit the file according to the description of the feedbackRecipients.xml file.

  5. Restart your EWA server and give feedback a try.

6.2.1.4 Feedback Channel: XSF-email

6.2.1.4.1 Preconditions

You may use this option only once the XSF project has reached phase 2 (planned for 01-July-2006) and you received an official Go! to use XSF features - please reconfirm with you local MPC.

This type of Feedback channel is an automatic switch between XSF functionality and Email as a fallback depending on the setup of a fixed central decision matrix feedbackTransfer.xml file provided by Daimler (for the selection whether XSF can be used for a specific event type or the email functionality shall be chosen) and the file feedbackRecipients.xml  which in case of the email fallback selects the appropriate email address.

Summary of requirements:

If all these requirements can be met you may choose  XSF-email as your Feedback Channel mode.

6.2.1.4.2 Configuration

Steps to be performed on the server side for this configuration are:

  1. Go to the [EWA_HOME]\config directory

  2. core_cfg.xml: Set the feedback "Modus" parameter to XSF-email.

  3. Ensure that the EWA email service (Parameter "MailService" is up and running and setup correctly. You may test it via the "Messaging" option of EWA.

  4. As you will want to setup your own Email routing to different locations you will want to make use of the advanced features of EWA's Feedback. In this case please make a copy of the file feedbackRecipients.xml as emailRecipients.xml and adjust the file core_cfg.xml:
    Set the feedback file reference parameter "RecipientsConfigFile" to the new filename you have chosen like this::
    <PARAMETER name="RecipientsConfigFile">emailRecipients.xml</PARAMETER>
    Edit the file according to the description of the feedbackRecipients.xml file.

  5. Restart your EWA server and give feedback a try.

6.2.1.5 Feedback Channel: XSF-fax

6.2.1.5.1 Preconditions

Like the option XSF-email you may use this option only once the XSF project has reached phase 2 (planned for 01-July-2006) and you received an official Go! to use XSF features - please reconfirm with you local MPC.

This type of Feedback channel is an automatic switch between XSF functionality and Fax as a fallback depending on the setup of a fixed central decision matrix feedbackTransfer.xml file provided by Daimler (used for the selection whether XSF can be used for a specific event type or the fax  functionality shall be chosen) and the file feedbackRecipients.xml  which in case of the fax fallback selects the appropriate fax number.

Summary of requirements:

If all these requirements can be met you may choose  XSF-fax as your Feedback Channel mode.

6.2.1.5.2 Configuration

Steps to be performed on the server side for this configuration are:

  1. Go to the [EWA_HOME]\config directory

  2. core_cfg.xml: Set the feedback "Modus" parameter to XSF-fax.

  3. As you will want to setup your own Fax  routing to different locations you will want to make use of the advanced features of EWA's Feedback. In this case please make a copy of the file feedbackRecipients.xml as faxRecipients.xml and adjust the file core_cfg.xml:
    Set the feedback file reference parameter "RecipientsConfigFile" to the new filename you have chosen like this:
    <PARAMETER name="RecipientsConfigFile">faxRecipients.xml</PARAMETER>.
    Edit the file according to the description of the feedbackRecipients.xml file.

  4. Restart your EWA server and give feedback a try.

6.2.1.6 Feedback Channel: xml-post

6.2.1.6.1 Preconditions

This option may only be used once the XSF project has reached phase 3 (planned for 01-April-2007) and you received an official Go! to use XSF features - please reconfirm with you local MPC.

This type of Feedback channel allows full integration of EWA's Feedback module with the XSF project.

Summary of requirements:

If all these requirements can be met you may choose  xml-post as your Feedback Channel mode.

6.2.1.6.2 Configuration

Steps to be performed on the server side for this configuration are:

  1. Go to the [EWA_HOME]\config directory

  2. core_cfg.xml: Set the feedback "Modus" parameter to xml-post.

  3. Restart your EWA server and give feedback a try.

 

6.2.1.7 Advanced features of the feedbackRecipients.xml

As described above the standard software setup of EWA provides a simple, but useful feedbackRecipients.xml file which contains a global fax number and a global email address for you to be used unless you need more advanced features. This file will be updated by the software installation processes and thus might override any changes you have made within it.

Therefore it is highly recommended (as described above) that once you start editing it you make a copy of it in the config folder of EWA and update the reference to the file within the core_xfg.xml file's parameter "RecipientsConfigFile". This ensures that your changes will not be destroyed by a software update.

The file initially looks like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<feedback-recipients xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="feedbackRecipients.xsd">
    <default preferred="fax">
        <email>test.gspsupport@daimler.com</email>
        <fax>+49-711-17-0</fax>
    </default>
</feedback-recipients>

You may want to simply change the default values for the recipients of fax or email by editing the fax or email elements.

But there is more that you can do with this file. The file may serve as an advanced decision matrix on the following attributes:

  1. Country:
    This is the top level decision in the decision tree. It represents the country of the workshop of the current user. Country numbers are a Daimler/GSP definition and 3 digits in length (i.e. 200 for Germany). A list of all valid country numbers can be looked up in the file country_codes.xml.
    This feature allows country specific email addresses and/or fax numbers.

  2. Workshop:
    The second level in the decision tree is the number of the Workshop the current user belongs to.

  3. Feedback Event Category:
    This is the bottom level in the decision tree for the selected category of feedback that shall be provided. Following values are valid:
    A1: Datacard
    C1: Parts Query (EPC)
    C2: Passenger Car Accessories
    D1: TIPS
    D2: Work Documentation (WIS)
    D3: Operation Item (ASRA)
    D4: Damage Codes
    E1: System Problems

     

To explain in more detail what the flexibility of this file is all about let's do a simple example:

 <?xml version="1.0" encoding="ISO-8859-1"?>
<feedback-recipients xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="feedbackRecipients.xsd">
    <country code="839" preferred= "email">
        <!-- we come here only if country of current user's workshop is Japan -->
        <category code="C1" preferred= "fax">
            <!-- we come here only if the user selected "Parts Query" in Feedback as event category --> 
            <email>feedback1@dcx.jp</email>
            <fax>+81 (1) 1234</fax>
        </category> 
        <!-- We are in Japan, but no further criteria was matching -->
        <default preferred= "email">
            <email>feedback2@dcx.jp</email>
            <fax>+81 (1) 12345</fax>
        </default>
    </country> 
    <!-- we come here if nothing of the above matches -->
    <default preferred= "fax">
        <email>feedback@daimler.com</email>
        <fax>+49 (711) 12345</fax>
    </default>
</feedback-recipients>

Let's go through this example and explain the different options:

Toplevel we define a country element with code "839" which means that this is country "Japan". When Feedback steps down the decision tree it compares the users country code with the one it finds here. Assuming now the user is in Japan. Then feedback remembers that in case of the email-or-fax mode email is the preferred choice via the preferred attribute. The next level of decision was to check for workshop. But this optional level is omitted so feedback steps further down and checks the event category that the user has chosen. Assuming now he has pressed the Feedback button inside the EPC client or has pressed the "Parts Query - EPC" button on the feedback mask, Feedback will match this against the given code "C1" here - and this code really represents the "Parts Query" event category. Feedback now remembers at this point that in case of email-or-fax the preferred Feedback channel will be email. Feedback has resolved the information it needs and will work in the following way:

Let's continue with this example. Assuming the user is in Japan, but would have chosen a different category - not the "Parts Query". Then feedback would have stepped into the "default" element within this workshop element and would have resolved the information from there.

Assuming the user is one located in Germany then already on the top level of the decision tree Feedback would have stepped into the global "default" section (the one at the bottom of the file) as no other matching workshop could be found. It would have resolved the information from there.

More advanced features:

An even more complex configuration that could be used for example multi-country servers of EWA may look like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<feedback-recipients xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="feedbackRecipients.xsd">

    <country code="200 557">
    <!-- we come here only if country of current user's workshop is Germany or Austria -->

        <workshop id="000000 A030X2">
            <category code="A1 C1" preferred= "fax">
                <email>feedback1@dcx.de</email>
                <fax>+49 (711) 17-12345</fax>
            </category>
            <category code="C2" preferred= "email">
                <email>feedback2@dcx.de</email>
                <fax>+49 (711) 17-123456</fax>
            </category>
            <!-- used for Austria or Germany and workshop either "00000" or "A030X2" but other feedback event category -->
            <default preferred= "fax">
                <email>feedback3@dcx.de</email>
                <fax>+49 (711) 17-12347</fax>
            </default>
        </workshop>

        <!-- used for all other workshops within Germany and Austria -->
        <category code="A1 C1" preferred= "fax">
            <email>feedback4@dcx.de</email>
            <fax>+49 (711) 17-12348</fax>
        </category>

        <default preferred= "fax">
            <email>feedback5@dcx.de</email>
            <fax>+49 (711) 17-12349</fax>
        </default>
    </country> 

    <country code="839" preferred= "email">
        <!-- we come here only if country of current user's workshop is Japan -->
        <category code="C1" preferred= "fax">
        <!-- we come here only if the user selected "Parts Query" in Feedback as event category --> 
            <email>feedback1@dcx.jp</email>
            <fax>+81 (1) 1234</fax>
        </category> 
        <!-- We are in Japan, but no further criteria was matching -->
        <default preferred= "email">
            <email>feedback2@dcx.jp</email>
            <fax>+81 (1) 12345</fax>
        </default>
    </country> 

    <!-- we come here if nothing of the above matches, so this is the "catch all" block -->
    <default preferred= "fax">
        <email>feedback@daimler.com</email>
        <fax>+49 (711) 12345</fax>
    </default>
</feedback-recipients>

6.3 Configuration of WIS net

6.3.1 wis_cfg.xml

The configuration file of the WIS-net server is located in [EWA_HOME]\config\wis_cfg.xml file.

Example:

<?xml version="1.0"?>
<!-- <!DOCTYPE export SYSTEM "wisconfig.dtd"> //-->
<WISCONFIGURATION>
    <SECTION name="imagecache">
        <!-- Size is given in Megabyte -->
        <PARAMETER name="maximumsize">128</PARAMETER>
    </SECTION>
    <SECTION name="pool">
        <SECTION name="co">
            <SECTION name="db">
                <PARAMETER name="driver">oracle.jdbc.driver.OracleDriver</PARAMETER>
                <PARAMETER name="url">jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=53.74.251.22)(PORT=1521)))(CONNECT_DATA=(SID=COL)(SERVER=DEDICATED)))</PARAMETER>
                <PARAMETER name="user">wisnet</PARAMETER>
                <PARAMETER name="password">wisnet</PARAMETER>
            </SECTION>
            <PARAMETER name="size">5</PARAMETER>
            <PARAMETER name="pingstatement">select count(*) from dual</PARAMETER>       
        </SECTION>
        <SECTION name="db">
            <PARAMETER name="driver">transbase.jdbc.Driver</PARAMETER>
            <PARAMETER name="url">jdbc:transbase://localhost:2054/wisnet</PARAMETER>
            <PARAMETER name="user">tbadmin</PARAMETER>
            <PARAMETER name="password"></PARAMETER>
            <PARAMETER name="size">5</PARAMETER>
            <PARAMETER name="pingstatement">select count(*) from Config</PARAMETER>
            <PARAMETER name="abondonedtimeout">0</PARAMETER>                        
        </SECTION>
    </SECTION>

    <SECTION name="client">
        <!-- Java heap size of client in MB, default is 64 MB -->
        <PARAMETER name="heapsize">128</PARAMETER>
        <PARAMETER name="many_docs_limit">250</PARAMETER>
        <PARAMETER name="additionalAnnahmeblattPrint">true</PARAMETER>
        <PARAMETER name="wsmButtonVisible">true</PARAMETER>
        <PARAMETER name="checkINetURL">daimler.com</PARAMETER>
        <PARAMETER name="epcdatacardjnlpurl">/EPC-net/jnlp/datacard_viewer/datacardviewer_{1}.jnlp</PARAMETER>
        <SECTION name="ui">
            <PARAMETER name="fontname">ARIAL Unicode MS>
            <PARAMETER name="fallbackfontname">Arial</PARAMETER>
            <PARAMETER name="3">private</PARAMETER>
                <SECTION name="standard">
                    <PARAMETER name="fontsize">12</PARAMETER>
                </SECTION>
                <SECTION name="c4">
                    <PARAMETER name="fontsize">15</PARAMETER>
                </SECTION>
            </SECTION>
    </SECTION>

    <SECTION name="server">
        <PARAMETER name="codebase">WIS-net/html</PARAMETER>
        <PARAMETER name="clientresources">WIS-net/html/resources/wis-net_Res.jar</PARAMETER>
        <PARAMETER name="clientresources_version_key">wis-net_Res</PARAMETER>
        <PARAMETER name="helpbase">http://localhost:9000/WIS-net/online-help/html</PARAMETER>
        <PARAMETER name="gateway">http://localhost:9000/EWA-net/ewa-net</PARAMETER>
        <PARAMETER name="language_preset">en</PARAMETER>
        <!-- debugLevel is on of ALERT, ERROR, WARNING, INFO or DEBUG -->
        <PARAMETER name="debugLevel">INFO</PARAMETER>
        <PARAMETER name="useMultiline">false</PARAMETER>
        <PARAMETER name="webetmbase">http://localhost:9000/WIS-net</PARAMETER>
        <PARAMETER name="gotisbase">http://gotis.aftersales.mercedes-benz.com/go.asp?where=</PARAMETER>
        <PARAMETER name="wsmbase">http://wsm-mercedes-benz.edgesuite.net/index_para.html</PARAMETER>
        <PARAMETER name="enableWMCSearch">true</PARAMETER>
        <PARAMETER name="enableWMCFiltering">true</PARAMETER>
        <PARAMETER name="collectPerformanceData">true</PARAMETER>
        <PARAMETER name="datacardUrl">http://localhost:9000/EPC-net/datacardapi</PARAMETER>
        <PARAMETER name="datacard_V2_Url">http://localhost:9000/EPC-net/datacardapi_V2</PARAMETER>
        <PARAMETER name="convertLegacyBookmarks">true</PARAMETER>
        <PARAMETER name="fulltextSearchImplementation">LUCENE</PARAMETER>
        <SECTION name="lucene">
            <PARAMETER name="indexDirectoryBasepath">C:/WIS/lucene-indices</PARAMETER>
            <PARAMETER name="containsSearchIsDefault">true</PARAMETER>
            <PARAMETER name="enableTitleSearch">true</PARAMETER>
            <PARAMETER name="morpholigicalSearchInDocument">true</PARAMETER>
            <PARAMETER name="resultSizeLimit">50000</PARAMETER>
            <PARAMETER name="searchInParallel">true</PARAMETER>
            <PARAMETER name="docTitleSearchImplementation">LUCENE</PARAMETER>                       
        </SECTION>
    </SECTION>
    <SECTION name="casedirect">
        <PARAMETER name="rootdir">C:\temp</PARAMETER>
        <PARAMETER name="webserver">http://53.74.251.21:8080</PARAMETER>
        <PARAMETER name="proxyserver"></PARAMETER>
        <PARAMETER name="proxyport">80</PARAMETER>

        <SECTION name="cookie">
            <SECTION name="1">
                <PARAMETER name="path">/caseonline</PARAMETER>
                <PARAMETER name="name">caseonline_rechte</PARAMETER>
                <PARAMETER name="value">14634</PARAMETER>
                <PARAMETER name="domain">.daimlerchrysler.com</PARAMETER>
            </SECTION>
            <SECTION name="2">
                <PARAMETER name="path">/caseonline</PARAMETER>
                <PARAMETER name="name">caseonline_passwort</PARAMETER>
                <PARAMETER name="value">stws</PARAMETER>
                <PARAMETER name="domain">.daimlerchrysler.com</PARAMETER>
            </SECTION>
            <SECTION name="3">
                <PARAMETER name="path">/caseonline</PARAMETER>
                <PARAMETER name="name">caseonline_login</PARAMETER>
                <PARAMETER name="value">stws</PARAMETER>
                <PARAMETER name="domain">.daimlerchrysler.com</PARAMETER>
            </SECTION>
            <SECTION name="4">
                <PARAMETER name="path">/caseonline</PARAMETER>
                <PARAMETER name="name">caseonline_login</PARAMETER>
                <PARAMETER name="value">stws</PARAMETER>
                <PARAMETER name="domain">u10grz02.grz.mbcase.daimlerchrysler.com:8091</PARAMETER>
            </SECTION>
            <SECTION name="5">
                <PARAMETER name="path">/caseonline</PARAMETER>
                <PARAMETER name="name">caseonline_sprache</PARAMETER>
                <PARAMETER name="value">000</PARAMETER>
                <PARAMETER name="domain">u10grz02.grz.mbcase.daimlerchrysler.com:8091</PARAMETER>
            </SECTION>
        </SECTION>


    </SECTION>

    <SECTION name="caseonline">
        <!-- needed for G.07 configuration -->
        <SECTION name="mappings">
            <SECTION name="fzgart_table">
                <PARAMETER name="1">P</PARAMETER>
                <PARAMETER name="2">P</PARAMETER>
                <PARAMETER name="3">T</PARAMETER>
                <PARAMETER name="4">T</PARAMETER>
                <PARAMETER name="6">N</PARAMETER>
                <PARAMETER name="8">O</PARAMETER>
                <PARAMETER name="9">U</PARAMETER>
            </SECTION>
        </SECTION>
        <SECTION name="importer">
            <PARAMETERR name="fileprefix">co-</PARAMETER>
            <PARAMETER name="filetype">.zip</PARAMETER>
        </SECTION>
    </SECTION>

    <SECTION name="setup">
        <SECTION name="caseonline">
            <PARAMETER name="allowed">true</PARAMETER>
            <!-- true = merge WIS and CO docs, false = only show CO doc even if both exist -->
            <PARAMETER name="merge_wis">true</PARAMETER>
            <SECTION name="sync">
                <PARAMETER name="mainswitch">1</PARAMETER>
            </SECTION>
        </SECTION>
        <SECTION name="casedirect">
            <PARAMETER name="allowed">true</PARAMETER>
        </SECTION>
        <SECTION name="asra">
            <PARAMETER name="defaultJoborderFileName">C:\temp\MBCASE\joborder\joborder.txt</PARAMETER>
        </SECTION>
        <SECTION name="paperformat">
            <PARAMETER name="paperformat_names">A3|A4|Letter|Legal</PARAMETER>
            <PARAMETER name="paperformat_rb">F_SETUP_P_GENERAL_PRINT_SL_A3|F_SETUP_P_GENERAL_PRINT_SL_A4|F_SETUP_P_GENERAL_PRINT_SL_LETTER|F_SETUP_P_GENERAL_PRINT_SL_LEGAL</PARAMETER>
            <PARAMETER name="A3">29.7cm*42cm</PARAMETER>
            <PARAMETER name="A4">21cm*29.7cm</PARAMETER>
            <PARAMETER name="Letter">8.5in*11in</PARAMETER>
            <PARAMETER name="Legal">8.5in*14in</PARAMETER>
        </SECTION>
        <SECTION name="fonts">
            <SECTION name="MODERN">
                <PARAMETER name="PLAIN.W32">Arial</PARAMETER>
                <PARAMETER name="BOLD.W32">Arial Bold</PARAMETER>
                <PARAMETER name="ITALIC.W32">Arial Italic</PARAMETER>
                <PARAMETER name="BOLD-ITALIC.W32">Arial Bold Italic</PARAMETER>

                <PARAMETER name="PLAIN.20.W32">MS Gothic</PARAMETER>
                <PARAMETER name="BOLD.20.W32">MS Gothic</PARAMETER>
                <PARAMETER name="ITALIC.20.W32">MS Gothic</PARAMETER>
                <PARAMETER name="BOLD-ITALIC.20.W32">MS Gothic</PARAMETER>

                <PARAMETER name="PLAIN.28.W32">MS Song</PARAMETER>
                <PARAMETER name="BOLD.28.W32">MS Song</PARAMETER>
                <PARAMETER name="ITALIC.28.W32">MS Song</PARAMETER>
                <PARAMETER name="BOLD-ITALIC.28.W32">MS Song</PARAMETER>

                <PARAMETER name="PLAIN.39.W32">SimSun</PARAMETER>
                <PARAMETER name="BOLD.39.W32">SimSun</PARAMETER>
                <PARAMETER name="ITALIC.39.W32">SimSun</PARAMETER>
                <PARAMETER name="BOLD-ITALIC.39.W32">SimSun</PARAMETER>

                <PARAMETER name="PLAIN.86.W32">Gulim</PARAMETER>
                <PARAMETER name="BOLD.86.W32">Gulim</PARAMETER>
                <PARAMETER name="ITALIC.86.W32">Gulim</PARAMETER>
                <PARAMETER name="BOLD-ITALIC.86.W32">Gulim</PARAMETER>

                <PARAMETER name="PLAIN.87.W32">Arial Unicode MS</PARAMETER>
                <PARAMETER name="BOLD.87.W32">Arial Unicode MS</PARAMETER>
                <PARAMETER name="ITALIC.87.W32">Arial Unicode MS</PARAMETER>
                <PARAMETER name="BOLD-ITALIC.87.W32">Arial Unicode MS</PARAMETER>

                <PARAMETER name="PLAIN.88.W32">Arial Unicode MS</PARAMETER>
                <PARAMETER name="BOLD.88.W32">Arial Unicode MS</PARAMETER>
                <PARAMETER name="ITALIC.88.W32">Arial Unicode MS</PARAMETER>
                <PARAMETER name="BOLD-ITALIC.88.W32">Arial Unicode MS</PARAMETER>
            </SECTION>
            <SECTION name="CLASSIC">
               <PARAMETER name="PLAIN.W32">Arial</PARAMETER>
               <PARAMETER name="BOLD.W32">Arial Bold</PARAMETER>
               <PARAMETER name="ITALIC.W32">Arial Italic</PARAMETER>
               <PARAMETER name="BOLD-ITALIC.W32">Arial Bold Italic</PARAMETER>

               <PARAMETER name="PLAIN.20.W32">MS Gothic</PARAMETER>
               <PARAMETER name="BOLD.20.W32">MS Gothic</PARAMETER>
               <PARAMETER name="ITALIC.20.W32">MS Gothic</PARAMETER>
               <PARAMETER name="BOLD-ITALIC.20.W32">MS Gothic</PARAMETER>

               <PARAMETER name="PLAIN.28.W32">MS Song</PARAMETER>
               <PARAMETER name="BOLD.28.W32">MS Song</PARAMETER>
               <PARAMETER name="ITALIC.28.W32">MS Song</PARAMETER>
               <PARAMETER name="BOLD-ITALIC.28.W32">MS Song</PARAMETER>

               <PARAMETER name="PLAIN.39.W32">SimSun</PARAMETER>
               <PARAMETER name="BOLD.39.W32">SimSun</PARAMETER>
               <PARAMETER name="ITALIC.39.W32">SimSun</PARAMETER>
               <PARAMETER name="BOLD-ITALIC.39.W32">SimSun</PARAMETER>

               <PARAMETER name="PLAIN.86.W32">Gulim</PARAMETER>
               <PARAMETER name="BOLD.86.W32">Gulim</PARAMETER>
               <PARAMETER name="ITALIC.86.W32">Gulim</PARAMETER>
               <PARAMETER name="BOLD-ITALIC.86.W32">Gulim</PARAMETER>

               <PARAMETER name="PLAIN.87.W32">Arial Unicode MS</PARAMETER>
               <PARAMETER name="BOLD.87.W32">Arial Unicode MS</PARAMETER>
               <PARAMETER name="ITALIC.87.W32">Arial Unicode MS</PARAMETER>
               <PARAMETER name="BOLD-ITALIC.87.W32">Arial Unicode MS</PARAMETER>

               <PARAMETER name="PLAIN.88.W32">Arial Unicode MS</PARAMETER>
               <PARAMETER name="BOLD.88.W32">Arial Unicode MS</PARAMETER>
               <PARAMETER name="ITALIC.88.W32">Arial Unicode MS</PARAMETER>
               <PARAMETER name="BOLD-ITALIC.88.W32">Arial Unicode MS</PARAMETER>
            </SECTION>
            <PARAMETER name="HELVETICA.PLAIN.W32">Arial</PARAMETER>
            <PARAMETER name="HELVETICA.BOLD.W32">Arial Bold</PARAMETER>
            <PARAMETER name="HELVETICA.ITALIC.W32">Arial Italic</PARAMETER>
            <PARAMETER name="HELVETICA.BOLD-ITALIC.W32">Arial Bold Italic</PARAMETER>
            <PARAMETER name="TIMES.PLAIN.W32">Times New Roman</PARAMETER>
            <PARAMETER name="TIMES.BOLD.W32">Times New Roman Fett</PARAMETER>
            <PARAMETER name="TIMES.ITALIC.W32">Times New Roman Kursiv</PARAMETER>
            <PARAMETER name="TIMES.BOLD-ITALIC.W32">Times New Roman Fett Kursiv</PARAMETER>
            <PARAMETER name="TIMES_ROMAN.PLAIN.W32">Times New Roman</PARAMETER>
            <PARAMETER name="TIMES_ROMAN.BOLD.W32">Times New Roman Fett</PARAMETER>
            <PARAMETER name="TIMES_ROMAN.ITALIC.W32">Times New Roman Kursiv</PARAMETER>
            <PARAMETER name="TIMES_ROMAN.BOLD-ITALIC.W32">Times New Roman Fett Kursiv</PARAMETER>
            <PARAMETER name="SWISS.PLAIN.W32">Arial</PARAMETER>
            <PARAMETER name="SWISS.BOLD.W32">Arial Bold</PARAMETER>
            <PARAMETER name="SWISS.ITALIC.W32">Arial Italic</PARAMETER>
            <PARAMETER name="SWISS.BOLD-ITALIC.W32">Arial Bold Italic</PARAMETER>
            <PARAMETER name="TYPEWRITE.PLAIN.W32">Courier New</PARAMETER>
            <PARAMETER name="DEFAULT.PLAIN.W32">Courier New</PARAMETER>
            <PARAMETER name="COURIER.PLAIN.W32">Courier New</PARAMETER>
            <PARAMETER name="COURIER.BOLD.W32">Courier New Fett</PARAMETER>
            <PARAMETER name="ARIAL.PLAIN.W32">Arial Narrow</PARAMETER>
            <PARAMETER name="ARIAL.BOLD.W32">Arial Fett</PARAMETER>
            <PARAMETER name="SYMBOLS.PLAIN.W32">Symbols</PARAMETER>
            <PARAMETER name="SYMBOLS.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="GREEK.PLAIN.W32">Greek</PARAMETER>
            <PARAMETER name="GREEK.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="GREEK.BOLD.W32">Greek Bold</PARAMETER>
            <PARAMETER name="GREEK.BOLD.W32.offset">61440</PARAMETER>
            <PARAMETER name="GREEK.ITALIC.W32">Greek Italic</PARAMETER>
            <PARAMETER name="GREEK.ITALIC.W32.offset">61440</PARAMETER>
            <PARAMETER name="GREEK.BOLD-ITALIC.W32">Greek Bold Italic</PARAMETER>
            <PARAMETER name="GREEK.BOLD-ITALIC.W32.offset">61440</PARAMETER>
            <PARAMETER name="MATH~A.PLAIN.W32">Math A</PARAMETER>
            <PARAMETER name="MATH~A.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="MATH~B.PLAIN.W32">Math B</PARAMETER>
            <PARAMETER name="MATH~B.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="MATH~EXT;.PLAIN.W32">Math Ext.</PARAMETER>
            <PARAMETER name="MATH~EXT;.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="LOGOC0.PLAIN.W32">MB Service</PARAMETER>
            <PARAMETER name="LOGOC0.PLAIN.W32.offset">0</PARAMETER>
            <PARAMETER name="LOGO1C0.PLAIN.W32">MB Laenderkennzeichen</PARAMETER>
            <PARAMETER name="LOGO1C0.PLAIN.W32.offset">0</PARAMETER>
            <PARAMETER name="LOGO1C41.PLAIN.W32">MB Diktogramme</PARAMETER>
            <PARAMETER name="LOGO1C41.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="LOGO1C356.PLAIN.W32">MB Fahrzeuge</PARAMETER>
            <PARAMETER name="LOGO1C356.PLAIN.W32.offset">0</PARAMETER>
            <PARAMETER name="LOGO1C357.PLAIN.W32">MB Pruefzeichen</PARAMETER>
            <PARAMETER name="LOGO1C357.PLAIN.W32.offset">0</PARAMETER>
            <PARAMETER name="LOGO1C360.PLAIN.W32">MB Kurzzeichen</PARAMETER>
            <PARAMETER name="LOGO1C360.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="LOGO2C0.PLAIN.W32">AMS New Digital</PARAMETER>
            <PARAMETER name="LOGO3C0.PLAIN.W32">MB Bedienzeichen</PARAMETER>
            <PARAMETER name="LOGO3C0.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="LOGO3C41.PLAIN.W32">MB Bedienzeichen S-Klasse</PARAMETER>
            <PARAMETER name="LOGO3C41.PLAIN.W32.offset">0</PARAMETER>
            <PARAMETER name="LOGO3C356.PLAIN.W32">MB Handkurzzeichen</PARAMETER>
            <PARAMETER name="LOGO3C356.PLAIN.W32.offset">0</PARAMETER>
            <PARAMETER name="LOGO3C357.PLAIN.W32">MB Digitalanzeige S-Klasse</PARAMETER>
            <PARAMETER name="LOGO3C357.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="LOGO3C360.PLAIN.W32">MB Schweisszeichen</PARAMETER>
            <PARAMETER name="LOGO3C360.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="LOGO3C361.PLAIN.W32">MB Bed. Zeichen W210</PARAMETER>
            <PARAMETER name="LOGO3C361.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="FONT3C0.PLAIN.W32">MB Fahrzeuge II</PARAMETER>
            <PARAMETER name="FONT3C0.PLAIN.W32.offset">61440</PARAMETER>
            <PARAMETER name="FONT3C41.PLAIN.W32">MBFahrzeuge III</PARAMETER>
            <PARAMETER name="FONT3C41.PLAIN.W32.offset">0</PARAMETER>
        </SECTION>
        <SECTION name="image">
            <SECTION name="TIFF">
                <PARAMETER name="matcher">com.daimler.wis.common.image.TIFFMatcher</PARAMETER>
                <PARAMETER name="decoder">com.daimler.wis.common.image.TIFFDecoder</PARAMETER>
            </SECTION>
            <SECTION name="GIF">
                <PARAMETER name="matcher">com.daimler.wis.common.image.GIFMatcher</PARAMETER>
                <PARAMETER name="decoder">com.daimler.wis.common.image.GIFDecoder</PARAMETER>
            </SECTION>
            <SECTION name="JPEG">
                <PARAMETER name="matcher">com.daimler.wis.common.image.JPEGMatcher</PARAMETER>
                <PARAMETER name="decoder">com.daimler.wis.common.image.JPEGDecoder</PARAMETER>
            </SECTION>
            <SECTION name="DTW">
                <PARAMETER name="matcher">com.daimler.wis.common.image.dtwdecoder.DTWMatcher</PARAMETER>
                <PARAMETER name="decoder">com.daimler.wis.common.image.dtwdecoder.DTWDecoder</PARAMETER>
            </SECTION>
        </SECTION>
        <SECTION name="markers">
            <PARAMETER name="anzieh.t">SIDS_ANZIEHMOMENTE</PARAMETER>
            <PARAMETER name="as.t">SIDS_AS_TABELLE</PARAMETER>
            <PARAMETER name="basdat">SIDS_BASISDATEN</PARAMETER>
            <PARAMETER name="bilder.t">SIDS_FIGURE</PARAMETER>
            <PARAMETER name="diag.t">SIDS_DIAGNOSE</PARAMETER>
            <PARAMETER name="fig">SIDS_FIGURE</PARAMETER>
            <PARAMETER name="aender.t">SIDS_AENDERUNGSHINWEISE</PARAMETER>
            <PARAMETER name="fuell.t">SIDS_FUELLMENGEN</PARAMETER>
            <PARAMETER name="hndwkz.t">SIDS_HDLSUEBL_WERKZEUGE</PARAMETER>
        </SECTION>
        <SECTION name="aggtypabk2bmart">
            <PARAMETER name="A">A</PARAMETER>
            <PARAMETER name="AG">G</PARAMETER>
            <PARAMETER name="MG">G</PARAMETER>
            <PARAMETER name="H1">HA</PARAMETER>
            <PARAMETER name="H2">HA</PARAMETER>
            <PARAMETER name="LG">L</PARAMETER>
            <PARAMETER name="P">P</PARAMETER>
            <PARAMETER name="V1">VA</PARAMETER>
            <PARAMETER name="V2">VA</PARAMETER>
            <PARAMETER name="VG">VG</PARAMETER>
            <PARAMETER name="T">T</PARAMETER>
            <PARAMETER name="M">M</PARAMETER>
            <PARAMETER name="L">L</PARAMETER>
            <PARAMETER name="G">G</PARAMETER>
            <PARAMETER name="HA">HA</PARAMETER>
            <PARAMETER name="VA">VA</PARAMETER>
        </SECTION>
    </SECTION>

    <SECTION name="services">
        <!--  Licence string for application "Damage Code Standalone"
             (Position 63 to 72 will be used for country code which should
             be 0, meaning international)
         -->
        <PARAMETER name="damageCodeLicence">01111110001000000111100000000011111111111111111111111111111111100000000000011110</PARAMETER>
    </SECTION>
</WISCONFIGURATION>

 

The next table explains important configuration settings.

ParameterExample ValueDescription
imagecache
maximumsize128The cache size for images in MB.
pool.co
size5Pool size for CASE-Online database access.
pool.co.db
driveroracle.jdbc.driver.OracleDriverJDBC-Driver to connect to CASE-Online database.
urljdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)
(HOST=53.74.251.22)(PORT=1521)))
(CONNECT_DATA=(SID=COL)(SERVER=DEDICATED)))
URL for CASE-Online database.

 

userwisnetUser for CASE-Online database access.
passwordwisnetPassword for CASE-Online database access.
pool.db
drivertransbase.jdbc.DriverJDBC-Driver to connect to WIS-net database.
urljdbc:transbase://localhost:2054/wisnetURL for WIS-net database.
usertbadminUser for WIS-net database access.
password Password for WIS-net database access.
size5Pool size for WIS-net database access.Attention:
A pool size of 5 is only suitable for a standalone installation. For a server installation a size of 200 may be adequate (it depends on the number of parallel user using this server).
pingstatementselect count(*) from ConfigSQL Statement which is used to check the availability of the database. This value must usually not be changed
abandonedtimeout0timout in seconds for removing abandoned connections (Default: 0, i.e. no Timeout)
client
heapsize128Java heap size of client in MB, default is 64 MB.
many_docs_limit250Threshold of document search result list size to display message "x documents found. Show ?". Default is 250, taken from wis-net_Res.properties-key F_WS_MSG_MANY_DOCS.
additionalAnnahmeblattPrinttrueWhen a service sheet is printed via EWANAPI also a reception report is printed if this parameter is true.
wsmButtonVisibletrueEnables the WSM Button in WIS/ASSRA. Default is true.
checkINetURLdaimler.comURL which is used to check the accessibility of the internet. Should be a common site, e.g. daimler.com or google.com. If not configured or empty, no accessibility check is done in the client when the WSM button is pressed.
epcdatacardviewtrueIndicates whether or not the new datacard is to be used in a WIS/ASRA Client. Default is true. When false is configured, the old datacard frame is used in WIS/ASRA
epcdatacardjnlpurl{0}/EPC-net/jnlp/datacard_viewer/datacardviewer_{1}.jnlpURL/URI of EPC datacardviewer extension. Placeholder {1} will be replaced with EPC version, optional placeholder {0} will be replaced with root URL of EWA net server. Usually the default value works correct and there is no need to configure this parameter.
client.ui
fontnameArial Unicode MSPreferred Font. Default is Arial Unicode MS
fallbackFontnameArialSecond choice of Font if fontname is not installed on client. Default is the Java font
client.ui.standard
fontsize15Standard font size for C4 machines. Default is 11
client.ui.c4
fontsize12Standard font size. Default is 11
server
codebaseWIS-net/htmlPath on the server where to find the WIS-net application . The Prefix "http://<server>:<port>/" is added automatically.
clientresourceWIS-net/html/resources/wis-net_Res.jarPath where the WIS/ASRA ressource file is placed. Default is WIS-net/html/resources/wis-net_Res.jar
clientresource_version_keywis-net_ResKey in %EWA_HOME%/version.txt for Java Web Start versioning of wis-net_Res.jar. Default is wis-net_Res
helpbasehttp://localhost:9000/WIS-net/online-help/html URL pointing to help resources.
gatewayhttp://localhost:9000/EWA-net/ewa-net URL pointing to the access gateway.
language_presetenLanguage pre settings used. This is the default UI language for clients connecting to this server. Each user can override this setting by choosing a preferred language in his personal client setup. Language presets either have the form en, de to specify only a country, or en_us, de_de to specify country and language.
debugLevelINFO Debug level for WIS-net server. One of ALERT, ERROR, WARNING, INFO or DEBUG
useMultilinefalseUse multiline mode for log output (true or false allowed).
webetmbasehttp://localhost:9000/WIS-netURL where WebETM Cadviewer is found.
gotisbasehttp://gotis.aftersales.mercedes-benz.com/go.asp?where=substitution string for the string gotis: in a document
wsmbasehttp://wsm-mercedes-benz.edgesuite.net/index_para.htmlsubstitution string for the string wsm: in a document
enableWMCSearchtrueEnable WMC sensitive document search. Default true. Should not be disabled
enableWMCFilteringtrueEnable Reduced WMC Lists in Client. Default true. Should not be disabled
collectPerformanceDatatrueActivate/deactivate collection of performance data.
convertLegacyBookmarkstrueindicates that bookmarks are to be migratet from old WIS/ASRA user profiles. Default is true. This parameter must not be set to false except in case of system misbehaviour
datacardUrlhttp://localhost:9000/EPC-net/datacardapiURL pointing to EPC datacard api. (valid if epcdatacardview=false)
datacard_V2_Urlhttp://localhost:9000/EPC-net/datacardapiURL pointing to the EPC datacard api of the new Datacard (valid if epcdatacardview=true)
fulltextSearchImplementationLUCENESelects the the full text search implementation. Valid values are LEGACY (DB-Based implementation) or LUCENE (linguistic search based on Lucene). Default is LUCENE. Note that in WIS 3.7 it is intended to not provide the neccessary LEGACY data in the WIS-DB. Therefore this value sholdn't be changed from lucene to legacy.
server.lucene
indexDirectoryBasepathC:/WIS/lucene-indicesBase path of language-dependent Lucene indexes.
containsSearchIsDefaulttrueEnables/disables the infix search as default search mode. Valid values are false and true. Default is true.
enableTitleSearchtrueEnables searching of document titles in the Lucene index. I.e. the full text search also takes document titles into account. Valid values are true or false. This options requires that document titles have been indexed. Default is true.
morpholigicalSearchInDocumenttrueEnables morphological searching inside a document. (e.g. searching "engines" will also find "engine"). Since the search over serveral documents is always morphological in lucene it is recommented to use this method also for the search inside a document. Note that the morphological search is done in the server. Therefore every morphological search means an additional server request. Default for the morphological search is true.
resultSizeLimit50000Limit of document hits of searches in Lucene indexes. Valid values are positive integers. Default is 50000. A search is done in two steps. The first step searches ALL documents containing a given word and the second step reduces the result set to its validity. Since this config-value is valid for the first step, the result set could be cut even if the user gets less than 1000 Documents. But cutting the result set will lead to unpredictable result sets. Therefore it is not reccommented to reduce this value.
searchInParalleltrueEnable parallel search. If enabled, all languages of the WIS Document language cascades will be searched in parallel. If disabled, the all documents of the first language will be searched and afterwards all documents of the second language etc.
docTitleSearchImplementationLUCENEA WIS search for document titles may be configured to LUCENE or LEGACY (=Database Method). Note that the Database Method is very limited and do not support the extended search method features. Therefore this method is not recommended.
casedirect
rootdirC:\tempRoot directory to use for CASE-Online direct access.
webserverhttp://53.74.251.21:8080URL where CASE-Online is reachable.
proxyserver Proxy server name (if needed).
proxyport80Proxy server port (if needed).
casedirect.cookie The cookie section is configured for the currently used CASE-Online webserver. If the webserver should require other cookie settings some day, please contact the CASE-Online providers to get the correct values.
caseonline.importer
fileprefixco-File prefix for CASE-Online import files. Default is "co-".
filetype.zipFile type (ending) for CASE-Online import files. Default is ".zip".
setup.caseonline
allowedtrueThis flag triggers two things:
Enable/disable the checkbox "Perform every search across latest documents" in client setup window. If the flag is set to false, users cannot perform searches on the CASE-Online database.
merge_wistrueIt set to true, search results of WIS and CASE-Online are merged.
setup.casedirect
allowedtrueThis flag enables or disables the server to access the CASE-Online database directly.
setup.asra  
defaultJoborderFileNameC:\temp\MBCASE\joborder\joborder.txtSet default joborder path and file name for ASRA job orders. It is possible to use any variables (%VARNAME%) which will be substituted at client side when defined.
setup.paperformat
paperformat_namesA3|A4|Letter|LegalNames for used paper formats.
paperformat_rbF_SETUP_P_WS_PRINT_SL_A3 |
F_SETUP_P_WS_PRINT_SL_A4 | F_SETUP_P_WS_PRINT_SL_LETTER | F_SETUP_P_WS_PRINT_SL_LEGAL
Resource bundle names for paper formates.
A329.7cm*42cmPaper size for format A3.
A420.9cm*29.1cmPaper size for format A4.
Letter8.5in*11inPaper size for format Letter.
Legal8.5in*14inPaper size for format Legal.
services
damageCodeLicence011111100010000001111000000000111111111
11111111111111111111111100000000000011110
License to use for damage code application.
 profiledummytrueUse profile dummy.
 profilefileC:\temp\wis_profile_File name prefix where profile will be saved.
 fincachedummytrueUse FIN cache dummy.
 fincachefileC:\temp\wis_fincache_File name prefix where FIN chache will be saved.

Table: wis_cfg.xml

6.4 Configuration of EPC net

6.4.1 epc_cfg.xml

The configuration file of the EPC-net server is located in [EWA_HOME]\config\epc_cfg.xml file.

Example:

<config>
<param name="gateway">EWA-net/ewa-net</param>
<param name="applicationMode">HPSERVICE</param>
<param name="clientMainClass">com.snapon.sbs.epc.client.view.impl.MBEPCApplication</param>
<param name="dbDriver">transbase.jdbc.Driver</param>
<param name="dbUser">tbuser</param>
<param name="SPECIAL_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/SPECIALFILES</param>
<param name="COMM_URL">pooling:30:null:10000:null:5:null:null:null:null:null:null:jdbc:transbase://localhost:2034/COMM</param>
<param name="ALLTEXT_URL">pooling:70:null:10000:null:2:true:null:null:null:null:null:jdbc:transbase://localhost:2034/ALLTEXT</param>
<param name="DCEX_DCEX_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/DCEX_DCEX</param>
<param name="MBJA_DCJA_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBJA_DCJA</param>
<param name="MBIE_DCIE_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBIE_DCIE</param>
<param name="MBLA_DCLA_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBLA_DCLA</param>
<param name="MBOE_DCBUS_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBOE_DCBUS</param>
<param name="MBOE_DCCAR_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBOE_DCCAR</param>
<param name="MBOE_DCGWGN_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBOE_DCGWGN</param>
<param name="MBOE_DCTRAC_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBOE_DCTRAC</param>
<param name="MBOE_DCTRAN_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBOE_DCTRAN</param>
<param name="MBOE_DCTRK_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBOE_DCTRK</param>
<param name="MBOE_DCUMOG_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBOE_DCUMOG</param>
<param name="MBNA_DCNA_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBNA_DCNA</param>
<param name="MBSA_DCSA_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBSA_DCSA</param>
<param name="MBSM_DCSM_URL">pooling:30:null:10000:null:2:null:null:null:null:null:null:jdbc:transbase://localhost:2034/MBSM_DCSM</param>
<param name="DAG_DCIAG_ARC_URL">pooling:30:null:10000:null:2:true:null:null:null:null:null:jdbc:transbase://localhost:2034/DAG_DCIAG_ARC</param>
<param name="DAG_DCIAG_URL">pooling:30:null:10000:null:2:true:null:null:null:null:null:jdbc:transbase://localhost:2034/DAG_DCIAG</param>
<param name="DAG_DCPC_URL">pooling:30:null:10000:null:2:true:null:null:null:null:null:jdbc:transbase://localhost:2034/DAG_DCPC</param>
<param name="DAG_DCCV_URL">pooling:30:null:10000:null:2:true:null:null:null:null:null:jdbc:transbase://localhost:2034/DAG_DCCV</param>
<param name="BM_IMAGES_H_URL">pooling:40:null:10000:20:20:true:null:null:null:null:null:jdbc:transbase://localhost:2034/BM_IMAGES</param>
<param name="SA_IMAGES_H_URL">pooling:40:null:10000:20:20:true:null:null:null:null:null:jdbc:transbase://localhost:2034/SA_IMAGES</param>
<param name="BM_IMAGES_ARC_H_URL">pooling:40:null:10000:20:20:true:null:null:null:null:null:jdbc:transbase://localhost:2034/BM_IMAGES_ARC</param>
<param name="SA_IMAGES_ARC_H_URL">pooling:40:null:10000:20:20:true:null:null:null:null:null:jdbc:transbase://localhost:2034/SA_IMAGES_ARC</param>\
<param name="BM_IMAGES_WS_H_URL">pooling:40:null:10000:20:20:true:null:null:null:null:null:jdbc:transbase://localhost:2034/PNG_IMAGES</param>
<param name="SA_IMAGES_WS_H_URL">pooling:40:null:10000:20:20:true:null:null:null:null:null:jdbc:transbase://localhost:2034/PNG_IMAGES</param>
<param name="BM_IMAGES_WS_ARC_H_URL">pooling:40:null:10000:20:20:true:null:null:null:null:null:jdbc:transbase://localhost:2034/PNG_IMAGES_ARC</param>
<param name="SA_IMAGES_WS_ARC_H_URL">pooling:40:null:10000:20:20:true:null:null:null:null:null:jdbc:transbase://localhost:2034/PNG_IMAGES_ARC</param>
<param name="BM_IMAGES_WS_URL">BM_IMAGES_WS_H_URL,BM_IMAGES_WS_ARC_H_URL</param>
<param name="SA_IMAGES_WS_URL">SA_IMAGES_WS_H_URL,SA_IMAGES_WS_ARC_H_URL</param>
<param name="BM_IMAGES_URL">BM_IMAGES_H_URL,BM_IMAGES_ARC_H_URL</param>
<param name="SA_IMAGES_URL">SA_IMAGES_H_URL,SA_IMAGES_ARC_H_URL</param><param name="MBNOART_IMAGES_URL">COMMONI_H_URL</param>
<param name="helpPath">/EPC-net/online-help/html</param>
<param name="wnewPath">/EPC-net/whatsnew/html</param>
<param name="tipofthedaycfgPath">/webapps/EPC-net/whatsnew/html</param>
<param name="logoPath">/images/logo/background_main.jpg</param>
<param name="showLogoImage">true</param>
<param name="dmsPartNoDelims">' ','-'</param>
<param name="imageop1">ScaleSmooth</param>
<param name="defaultDatabaseLocale">en</param>
<param name="defaultLocale">G</param>
<param name="defaultLocaleGUI">G</param>
<param name="hasSA">true</param>
<param name="availableClasses">1,2,3,4,5,6,7,F,M,T,A,S</param>
<param name="availableClasses_NA">1,2</param>
<param name="availableClasses_JA">1,2,3</param>
<param name="availableClasses_LA">3,4,5,6</param>
<param name="availableClasses_SA">1,2,3,4,5,6,7</param>
<param name="availableClasses_SMART">F</param>
<param name="shoplistVersion">1.1</param>
<param name="XFR_Delete_Exit">true</param>
<param name="LookAndFeel">Automatic</param>
<param name="enhancedFilteringClasses">1,2,3</param>
<param name="SupplementaryTextIn_SL_XFR_File">true</param>
<param name="sendAllModelsForDK">false</param>
<param name="AutoAppendMotorCode">true</param>
<param name="AutoAppendMotorCodeClass">1</param>
<param name="MinPartSearchNameLength">3</param>
<param name="transmitDatacard">true</param>
<param name="compressDatacardResponse">false</param>
<!-- valid values for remanufacturedAggTypes M,GA,GM,LG,VA,HA,VG,P,FH -<param name="remanufacturedAggTypes">M,GA,GM</param>
<param name="remanufacturedAggClasses">1,2,3,F</param>
<param name="CollapseReplacementChain">true</param>
<param name="VPDIdentClasses">1,2,3,4,5,6,7,F</param>
<param name="XFRServiceAndFile">false</param>
<param name="IncludeAggregateBMforCodeDesc">true</param>
<param name="CodeDescriptionEldasClasses">1,2</param>
<param name="defaultThumbnails">true</param>
<param name="clearClientDiskCacheWithDbUpdate">false</param>
<!-- valid values for clientImageThreads between 1 and 3-->
<param name="clientImageThreads">2</param>
<!-- valid values for minClientHeapSize minimum 128 and higher values in 64 steps-->
<param name="minClientHeapSize">128</param>
<!-- valid values for diasableAggIdxFallbackClasses 1,2,3,4,5,6,7,F -->
<param name="disableAggIdxFallbackClasses">3,4</param>
<param name="wildcardSearchHitLimit">5000</param>
<param name="CKDFilterEnabledClasses">1</param>
<param name="AutoCatSelect">true</param>
<param name="accessoryCodePattern">TZ*</param>
</config>

 

The next table explains the important configuration settings.

ParameterExample ValueDescription
config
gatewayEWA-net/ewa-netPath to Access Gateway
applicationModeHPSERVICEMode is in EWA net always HPSERVICES
clientMainClasscom.proquest.epc.view.impl.MBEPCApplicationJava class path to application
dbDrivertransbase.jdbc.DriverDriver for EPC DB data
dbUsertbuserUser name for EPC DB access
*_URLpooling:
arg1 -- 30:
arg2 -- null:
arg3 -- 10000:
arg4 -- null:
arg5 -- 2:
arg6 -- null:
arg7 -- null:
arg8 -- null:
arg9 -- null:
arg10-- null:
arg11-- null:
arg12-- jdbc:transbase://localhost:2034/*
Connection pool settings:
arg1 -- MaxNumber Connections to this DB
arg2 -- whenExhaustedAction (byte)
arg3 -- maxWait (long) - default: -1 (forever)
arg4 -- maxIdle (int) - 5 connections
arg5 -- minIdle (int) - default: 0 connections
arg6 -- testOnBorrow (boolean) - default: false - do not test
arg7 -- testOnReturn (boolean) - default: false  - do not test
arg8 -- timeBetweenEvictionRunsMillis (long) - default: -1 (forever)
arg9 -- numTestPerEvictionRun (int) - 5 (should not matter in this case)
arg10-- minEvictableIdleTimeMillis (long - default: 1000 * 60 * 30 (= 1800000 msec = 1800 sec = 30 min)
arg11-- testWhileIdle (boolean) - default: false - do not test
arg12-- Driver and path to DB - localhost could be redirect to a different DB server.  2034 is the port number for EPC Transbase DB
*_IMAGES_URL*_H_URLInternal references - Don't touch
dbUsertbuserUser name for EPC DB access
helpPath/EPC-net/online-help/htmlRoot path to help files
wnewPath/EPC-net/whatsnew/htmlRoot path to Whats New files
tipofthedaycfgPath/webapps/EPC-net/whatsnew/htmlDefines the path to the tip of the day config file
logoPath/images/logo/background_main.jpgPath to background image in the epc.jar file
showLogoImagetrueBackground image disable = false
dmsPartNoDelims' ','-'This is the default setting for Terminal Emulation in the Options Setup dialog.
imageop1ScaleSmoothImage view parameter  Don't touch
defaultDatabaseLocaleenDefault fallback data language
defaultLocaleGDefault data language
G = German
E = English
S = Spanish
P = Portuguese
F = French
I = Italian
defaultLocaleGUIGThis is the GUI language in one character.  The application will convert this character over to a java locale for the application to use as the default GUI language.
hasSAtrueEnables/Disables the SA/Component radio button in the Compman search window.
availableClasses*1,2,3,4,5,6,7,F,M,T,A,SSet the classes available in each market
shoplistVersion1.1This is the version of the internal shopping list structure.
XFR_Delete_ExittrueTranfer file behaviour when exit EPC
true = delete (default)
false = keep it
LookAndFeelAutomaticEPC Look and Feel
possible settings:
- Automatic (Windows for JRE 1.4.2 and WindowsClassic for JRE 1.5.x)
- Windows
- CrossPlatform
- WindowsClassic (shows up on JRE 1.4.2 as CrossPlatform)
enhancedFilteringClasses1Enhanced Filter Rules valid for the set classes. Additional Classes could be set  with comma seperated.
Attention:
This filtering could in some cases hide valid parts
SupplementaryTextin_SL_XFR_FiletrueDefault setting for new users of the Supplementary Text in XFR file setting. Could always be changed on the client side. This setting could be overwritten with the epc_xfr_cfg.xml file settings SuplementaryTextInXFR
sendAllModellsForDKfalseIf autonavigate into a Modell is the Modell pulldown menu only showing the current modell. This was done for performance reasons. If the value is "true" than the pulldown shows all Modells.
AutoAppendMotorCodetrueAppend automatically the motor code to the code list for filtering
AutoAppendMotorCodeClass1Set the vehicle class for which the setting AutoAppendMotorCode should be valid
MinPartSearchNameLength3Number of characters which must for a partname search at least be entered.
transmitDatacardtrueIf (false) than the server will re-retrieve the datacard, which means less network bandwith but little bit more server load
compressDatacardResponsefalse(true) will enable the compression of Datacards before it get send to client. Less bandwith - more load on server and client
remanufacturedAggTypesM,GA,GMdisables filtering for those remanufactured aggregate types
remanufacturedAggClasses1,2,3,Frestrict the "remanufacturedAggTypes" to classes
CollapseReplacementChaintrueenables the Replacement Chain feature
VPDIdentClasses1,2,3,4,5,6,7,Frestrict the "VPDIdent" to classes
XFRServiceAndFilefalseFalse: If ewanapi call has process ID will the xfr file not be written. Only DataExchangeService will be updated
IncludeAggregateBMforCodeDesctrueSA Code descriptions are based on chassis and aggregate models. This parameter defines if only the chassis BM should be checked (false) or also the Aggregate BM's from the datacard (true)
CodeDescriptionEldasClasses1,2SA Code description are displayed for CodeB and Dialog catalogs. This parameter extends the display of SA code description also to ELDAS catalogs based on vehicle classes
defaultThumbnailsfalseDefines if feature Thumbnails should be enabled (true) for new users
clearClientDiskCacheWithDbUpdatefalseDefines if the Client Diskcache should be cleared (true) when the server get a new data release
clientImageThreads2Defines how many parallel image requests should be send from each client to server. Attention: More requests need more HeapSizeMemory!
minClientHeapSize128Defines the minimum MaxHeapSize for a client - User can configure more, but not less
disableAggIdxFallbackClasses3,4Defines the vehicle classes which should not add a aggregate to the Aggregate Index when on datacard is no valid model for this aggregate
wildcardSearchHitLimit5000Defines the max hits found with wildcard search before it stop and shows a message box. This limit avoids that a too long hitlist could cause an OutOfHeapSizeException
CKDFilterEnabledClasses1Defines the vehicle classes which should do CKD filtering (only DIALOG)
AutoCatSelecttrueDefines if the Automatic Catalog select feature should be enabled or disabled
accessoryCodePatternTZ*Defines the pattern of CODE which should be identified as Accessory Code. Wildcard * is allowed

Table: epc_cfg.xml EPC net

6.4.2 EPC Shopping lists

Please find more information regarding EPC shopping list handling and configuration here.

7 Advanced Configuration

7.1 Switching EWA to default HTTP Port 80

The standard installation will make EWA run on the specific port 9000. This is to avoid conflicts with existing installations of an HTTP server listening on port 80 (i.e. Windows 2000 Server installations with IIS running for administrative tasks). If you make use of an upfront web server as described in the section about setting up EWA for clustering you will already find EWA running on the port 80.

So apart from the steps described in the following sections to make the EWA Application Server listen on port 80, you might also want to see the clustering documentation and setup a WebServer in front of the application server.

However, to allow you to switch your application server installation to use the HTTP default port 80, following instructions might be helpful for you:

  1. Edit the J2EE Server configuration
    For the "local" environment this is:
    [EWA_HOME]\server\conf\server.xml
    Find the section and edit the line:
    <!--
        Define a non-SSL HTTP/1.1 Connector on port 9000
    -->
    <Connector port="80"
               protocol="HTTP/1.1"
               secure="false"
               maxHttpHeaderSize="8192"
               acceptCount="300"
               maxThreads="200"
               minSpareThreads="25"
               maxSpareThreads="75"
               enableLookups="false"
               redirectPort="8443"
               connectionTimeout="60000"
               disableUploadTimeout="false" />
    

    Replace the current value for "port" (i.e. "9000") with the new value "80".

  2. Edit the central config file of EWA:

    [EWA_HOME]\config\core_cfg.xml

    Edit the value

    [...]
    <PARAMETER name="httpPort">80</PARAMETER>
    [...]

    Replace the value with "80".

  3. Edit the EPC configuration file. Adjust the property for the datacard access URL:

    [EWA_HOME]\config\epc_cfg.xml

    Find the section and edit the line:

    [...]
    <param name="datacardapi">http://localhost:80/EPC-net/datacardapi</param>
    [...]

    Replace the value with "80"

  4. Restart the EWA server
  5. If you make use of EWANAPI please assure that all clients refer to the corrected address now. As EWANAPI has to connect to the server, it needs the correct URL, including a correct port number for the URL.
    Find and edit the file:

    EWANAPI.INI

    and edit the entry

    [...]
    [HTTP-Config]
    [...]
    Port=80
    

    Replace the value with "80".

7.2 Logging

7.2.1 EWA system log

EWA makes use of the Log4J logging API, a de-facto standard in the Java world. Its configuration will be performed within the file

[EWA_HOME]\config\log4_config.xml

You will find different so called "appenders" within this file to be configured. Each of them has properties that you can use to fine tune the logging mechanisms:

There are 2 basically different files that log different things:

  1. A developer log file that contains typically the most information.
    This information will be generated by two appenders: one writing HTML formatted output (name of the appender is "HTML"), the other one writing plain ASCII (name of this appender is "STANDARD_FILE")
  2. A DC compliant monitor file reporting monitoring information.
    This information will be generated by an appender named "DCMONFILE". It creates a file in the format specified by Daimler

7.2.1.1 File names and location of logfiles

You can modify the filenames into which the appenders write. The filenames are being defined by the parameter "File" for each appender. You are free in choosing a filename you like. As long as you specifiy simply a filename without directory information, this file will be created in the folder [EWA_HOME]\logs.

As soon as you provide an absolute path, this will be chosen.

Example:

<param name="File" value="C:\test__log.txt" />

will write the output directly into the root directory of drive C:

Note:
Please be aware that changing the directory in which EWA will log might have unwanted side effects. One of them is that neither Dr.EWA nor the administration pages will be able to find those log files then. EWA's tools expect that logfiles will be written into [EWA_HOME]\logs.

7.2.1.2 Log level

The log level for the log appenders can be set individually for the both appenders writing the debugging log information. For each of these appenders you will find the entry

<param name="Threshold" value="WARN" />

There are different log levels available. The higher you set the level (from DEBUG up to FATAL) the less narrative the log file will be, but you will then only see the more critical reports :

Level SettingDescription / Meaning
DEBUGall messages, including developer statements not aimed for productive use

Note:
Be careful not use simply use this level. It will almost keep your server from running as so much information will be logged!

INFOno debug info, but everything that is informative
WARNmore then just informative messages: but warnings and errors. Can be used for productive environments
ERRORonly errors and exceptions
FATALworst case if the application is in a state where it typically cannot recover from

7.2.1.3 Rolling File Adapter

To avoid big log files, we use the Log4JImprovedRollingFileAppender as appender. This appender will create numbered files with a specific file size. It has additional parameters to define the file size and the maximum number of files:

ParameterDescription
MaxBackupIndexThe MaxBackupIndex option determines how many backup files are kept before the oldest is erased. This option takes a positive integer value. If set to zero, then there will be no backup files and the log file will be truncated when it reaches MaxFileSize.
MaxFileSizeThe maximum size that the output file is allowed to reach before being rolled over to backup files.

7.2.2 Application Server logging

EWA will be run inside and under the control of the application server. During runtime of the application server all of its components perform some kind of communication between each other and fulfill different tasks. Those are not under the control of EWA and will be monitored within separate, application server specific files.

If something goes wrong – i.e. an exception occurs (some unexpected behavior) – It will be logged into an application server (often also referred to as "container") own log file. The details of the logging information depends upon the configured log level (or debug level).

Note:
These logfiles will mainly contain information in the startup phase of the components. Typically during runtime you will find the most relevant information within the logfiles that EWA writes on its own (see above).

The application server uses its own logging mechanism, which is used for server internal messages. This file can be access from the following path:

[EWA_HOME]\logs\stdout.log

7.2.3 Client Side Logging

Besides logging on server side, logging can also be influenced on client side. This can mainly be used for troubleshooting of client application problems.

Logging is per default enabled on information level but can be configured during runtime to a different level or format. Logging configuration is set by a file on the clients machine. The format of the file is described below and will be searched in the following order:

  1. %USERPROFILE%\logging.properties
  2. C:\logging.properties

  3. (default configuration)

The client application is watching for a configuration change for every 10 seconds and refreshes the logging configuration if the file has been altered.

An example logging configuration on client side could look like this:

# Handler to which the log output is directed to
handlers=java.util.logging.ConsoleHandler

# Default global logging level.
# This specifies which kinds of events are logged across
# all loggers. For any given facility this global level
# can be overriden by a facility specific level
# Note that the ConsoleHandler also has a separate level
# setting to limit messages printed to the console.
.level=INFO

# For example, set the com.hp logger to only log SEVERE messages:
com.hp.level=SEVERE

Logging levels can be specified for different application component structures and set to different levels. Levels can be...

For further configuration options, please take a look to the Java Logging Overview,

7.3 Security

7.3.1 Secure Socket Layer (SSL, HTTPS) Support – Optional

Support for SSL is optional. Installing SSL requires general SSL knowledge. Before installing SSL please make sure the server is running correctly. Only after you tested the system completely and assured it is running fine, start installing SSL. After completing the SSL installation, you can use the system like before. You can even use your old bookmark. EWA will automatically switch to SSL during logon. You can recognize this by finding the yellow lock icon in the Internet Explorer status bar.

For protection against unsolicited access please find more information here.

During the SSL installation, please stop the EWA server and restart it only after completing the SSL setup. If you do not do this you might get confused as files might be locked or the server will not react in the way you expected it.

Get a certificate for the computer

Before using SSL you have to get an official SSL certificate for the server you want to run the EWA application server on. This certificate will be issued to the host name and IP address. It can either be a "self signed" certificate (for first simple tests this might be sufficient) or an official certificate signed by a known certificate authority like Verisign or Thawte.

Note:
A self signed certificate should only be used for testing. EWANAPI doesn’t support self signed certificates. Also the Internet Explorer will show a warning, that the certificate issuer is not trusted.

General approach for getting a certificate (find more details about that later on):

  1. Use an empty key store like the one provided on the EWA media (or create a new empty key store for your certificate)
    Key stores are a Java mechanism for storing the private/public key pairs that finally make up your certificate. You can think of those files like a treasure box which is locked by a password that only you and of course your application server know.
  2. Generate a public/private key pair in that key store. This key pair will again be protected by a password.
    Ensure you use the same password for both your key pair and your key store itself!
    If you miss this, you will not be able to run the Application Server in SSL mode as it then cannot access your certficate.
  3. Request a certificate from a certificate authority (CA) for that key.
  4. Import the certificate you have received from the CA. Import the chain certificate (the authentication certificate of the CA).

For getting an official and trusted certificate please refer to the certificate authorities and your internal processes for doing so.

Prepare the key store

Find the prepared and empty key store on the delivery media (you may also create your own if you have good experience). We will later refer to the key store in the server's file system at:

File: [EWA_HOME]\certificates\ewanet.jks

So, copy the key store file from the delivery media at

[DVD-DRIVE]:\ewa\central\config\ewanet.jks

to

[EWA_HOME]\certificates\ewanet.jks

(create the directory "certificates" if needed).
Please ensure to remove any write protection on the file after you copied it from the delivery media.
.

The file is a Java key store file and we will make use of it in the next steps.

To be able to work with the system you could simply make use of Oracle's "keytool" which is part of a public Java Development Kit. But we recommend to make use of the "KeyStore Explorer" (http://keystore-explorer.sourceforge.net). This document assumes you have this software installed.

Assuming you have installed the "KeyStore Explorer", you will now be able to open the key store at

EWA_HOME\certificates\ewanet.jks

Double-click the file and a GUI will open, asking you for the key store's password.

  1. You will be asked for a password. Enter "changeit" as this is the default when you use the key store from the delivery media
  2. We recommend you change the password now and save the key store again (use the menu "Tools / Set Password" to do this and then click on "File / Save").
  3. Create a public/private key pair (use the menu "Tools / Generate Key Pair"). This will make up your certificate later).

    Use RSA, 2048 Bits and the default settings for the rest.
    When asked for information please set at least a meaningful duration (i.e. 365 days for one year).

    Make use of the default algorithm (SHA-256 with RSA).
    Leave the generated Serial Number and the preselected Version 3.
    If you know what to do, you can add some additional information by clicking Add Extensions.

    Click Edit Name and add the correct data (Common Name (CN), Email,...). Make sure to enter the Common Name attribute with exactly the DNS name that your client later will refer to when trying to connect your EWA server.

    Note:
    It is important that for the "Common Name" you specify exactly the server name that your clients of EWA will make use of in the future. Typically it is recommended to use the fully qualified DNS name of the EWA server.

  4. You will then be asked for an alias. This will not be used by the server, it is just an intuitive name for your reference, as you could i.e. add several different certificates within the given key store. You may just accept the suggestion of the KeyStore Explorer application.

  5. Enter a password for the keypair now.
    Note:
    It is important that you now use exactly the same password as for the key store itself. If you do this wrong, your EWA server will definitely not run with SSL switched on as it will not be able to access your certificate. So make use of the password that you have set for the key store itself again.

  6. Now you must save your keystore again.
    Congratulations! You successfully created a "self-signed" certificate.
    It is not yet trusted, but to test your system you could for now skip the next few steps of this documentation and try to configure your server.

    Note:
    DO NOT DELETE THE KEYSTORE NOW. It will be used by the server and you will also need it to re-import the real certificate from a trusted authority like VeriSign. If you delete the keystore and then get your official certificate back, it will be worthless. You will not be able to recreate a keystore and keypair matching this certficate.

  7. To get a real certificate, please first create a Certificate Signing Request (CSR) now

    Save this to the disk and get in contact with i.e. VeriSign or Thawte where you will have to upload this information.
    They will return 2 certificates after a few days - and after you paid it, of course :)
    - a so called "chain certificate"
    - your personal "trusted" and official certificate that now will be accepted by all browsers and the EWANAPI executable once imported into your key store.
    Both have to be imported via "Import CA Reply" in the context menu of your certificate in the key store (see screenshot above) - starting always with the chain certificate!
    Please follow the instructions of the certificate authority where you received the certificate files from. Should you have any problems importing the certificates, please contact the certificate authority, which basically tells you that you might have to import and export the files through the InternetExplorer certificate store.
  8. Do not forget to save your key store now. Then close the KeyStore Explorer application.
  9. Congratulations! Your key store is complete, but to use it you now have to activate SSL in the server - something you will have to do after each update of the software.

Activate SSL within the application server

File: [EWA_HOME]\server\conf\server.xml

Activate the TomCat SSL connector. To do this simply un-comment the Connector for SSL. Change the attribute "keyStore" to the file path of ewanet.jks, e.g. c:/EWA_net/certificates/ewanet.jks.

If you are using a different password then the standard "changeit", please add/modify the appropriate attribute like in the example below. Remember to replace the token "[EWA_HOME]" by the real path of your installation. Also do not forget to un-comment the section!

Example:

<!--
        Define a non-SSL HTTP/1.1 Connector on port 9000
-->
<Connector port="9000"
        protocol="HTTP/1.1"
        secure="false"
        maxHttpHeaderSize="8192"
        acceptCount="300"
        maxThreads="200"
        enableLookups="false"
        redirectPort="8443"
        connectionTimeout="60000"
        disableUploadTimeout="false" />


<!--
    Define a SSL HTTP/1.1 Connector on port 8443
<Connector port="8443"
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxHttpHeaderSize="8192"
           acceptCount="300"
           maxThreads="200"
           enableLookups="false"
           scheme="https"
           secure="true"
           clientAuth="false"
           SSLEnabled="true"
           connectionTimeout="60000"
           disableUploadTimeout="false"
           keystoreFile="[EWA_HOME]/certificates/ewanet.jks" 
           keystorePass="changeit"
           sslProtocol="TLS" />
-->

Note:
Ensure that your replace the placeholder string "[EWA_HOME]" by your real installation directory, i.e. "C:/EWA_net" wherever it appeared in the samples above.

Now you successfully activated the SSL mode of the application server, but EWA is not yet aware of this setting.

Activate SSL inside of the EWA application

After configuring your application server to make use of SSL you finally have to tell the EWA application itself about your intention to use SSL and on which ports your application server listens. This is needed as there is no common API in the different application servers to ask them for this information.

Note:
In opposite to early versions of EWA is not necessary anymore to perform this step after each software update.

Edit the configuration file:

File: [EWA_HOME]\config\core_cfg.xml

Activate SSL inside of EWA. Go to the AccessGateway -> ApplicationSettings section at the very bottom of that file. There set the property "sslEnabled" from false to true.

<SECTION name="AccessGateway">
        <SECTION name="ApplicationSettings">
        <!-- SSL within EWA - do not forget to configure your server accordingly -->
        <PARAMETER name="sslEnabled">true</PARAMETER>
        <!-- SSL for client - server communication - should be configured only together with sslEnabled -->
        <PARAMETER name="sslForClientsEnabled">false</PARAMETER>
        <!-- If using an external SSL module, the external client-URLs will be generated with https instead of http.
                        Ensure that the parameters sslEnabled and sslForClientsEnabled are not set to true. -->
        <PARAMETER name="useExternalSSLModule">false</PARAMETER>
        <PARAMETER name="httpPort">9000</PARAMETER>
        <PARAMETER name="httpsPort">8443</PARAMETER>

        </SECTION>

7.3.2 Protection against unsolicited access

The system should be protected against unsolicited access. In general all URLs that should not be accessed from outside should be blocked. For the application itself the so called AccessGateway will be a single point of entry. No direct access to business logic is allowed and possible. This prevents potential security issues. There are also URLs that should be only accessible for system administrator (e.g. run time statistics).

The security constraint feature of the web application settings (web.xml) will be used to reach this goal.  Only few resources should be accessible from outside. Unfortunately it isn’t possible to define a positive list (which URLs are allowed) but only a negative list.

The protection level are:

URL

Description

Defined in

Protection level

/ewa-net

AccessGateway

core_cfg.xml, wis_cfg.xml

public

/ewa-net.jnlp

AccessGateway WebStart

web.xml

public

/jnlp/*.jnlp

Client Tools + Resources for WebStart

core_cfg.xml

public

/jars/*

Client Tools JAR files

core_cfg.xml

public

/jsp/*

Web interface

struts_config.xml

public

/Login/*

Web interface

struts_config.xml

public ¹

/Admin/*

Web interface

struts_config.xml

public ¹

/images/*

Images

 

public

/forward.htm

Welcome file

web.xml

public

EWA-net URLs

¹Internal info: these URLs have already been protected by Apache Struts.

URL

Description

Defined in

Protection level

/EPCServlet

EPC Business logic

core_cfg.xml

protected

/jnlpServlet

EPC WebStart

core_cfg.xml

protected

/datacardapi

Datacard API

epc_cfg.xml

public

/servlets/epc.jar

EPC jar

epc_cfg.xml

public

/servlets/*

Mixed

 

public

/servlets/Html/*

Online help

epc_cfg.xml

public

/database/*

Database

 

protected

EPC-net URLs

URL

Description

Defined in

Protection level

/wis

WISnet Business logic

core_cfg.xml

protected

/webstart.jnlp

WISnet WebStart

core_cfg.xml

protected

/statistic

WISnet statistics

web.xml

admin

/html/*

WISnet jars

wis_cfg.xml

public

/online-help/html/*

Online help

wis_cfg.xml

public

/html/*

Resourcebundles

wis_cfg.xml

public

/* (???)

WebETM Base

wis_cfg.xml

t.b.d.

/errorPages/404.jsp

Error pages

web.xml

public

/resources/*

CAD viewer

 

protected

/index.html

Welcome page

web.xml

public

WIS-net URLs

Configure web.xml

Change the settings of all installed web applications. The settings file is

EWA-net:          [EWAHOME]\webapps\EWA-net\WEB-INF\web.xml
EPC-net:           [EWAHOME]\webapps\EWA-net\WEB-INF\web.xml
WIS-net:            [EWAHOME]\webapps\EWA-net\WEB-INF\web.xml

Add to the web.xml:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Blocked URLs</web-resource-name>
        <description>Block all traffic to unwanted URLs.</description>
        <url-pattern>/jsp/*</url-pattern>
        <url-pattern>/someotherurl</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>This group doesn't contain user. So no user is allowed to
            access such URLs</description>
        <role-name>ewanet_protected</role-name>
    </auth-constraint>
</security-constraint>

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Admin URLs</web-resource-name>
        <description> URLs accessible for administrators only</description>
        <url-pattern>/statistic</url-pattern>
        <url-pattern>/someotherurl</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Only admin user </description>
        <role-name>ewanet_admin</role-name>
    </auth-constraint>
</security-constraint>

<login-config>
    <auth-method>BASIC</auth-method>
</login-config>

<security-role>
    <role-name>ewanet_protected</role-name>
    <role-name>ewanet_admin</role-name>
</security-role>

7.4 User Management Configuration

File: [EWA_ HOME]\config\core_cfg.xml
File: [EWA_ HOME]\config\um_cfg.xml
File: [EWA_ HOME]\config\um_batch_cfg.xml

The User Management configuration can be changed by editing the files core_cfg.xml and um_cfg.xml. Additionally the file um_batch_cfg.xml is used for installations which support EWANAPI. It is required to configure the login method for EWANAPI authentication calls.

EWANAPI uses the values of "um_batch_cfg.xml" where as the standard login masks use "um_cfg.xml" as configuration. So the best way to configure EWANAPI access to setup a correct and tested "um_cfg.xml" and then after successful tests make a copy of it and rename it "um_batch_cfg.xml".

7.4.1 HP User Management

HP User Management is the default User Management. It is being switched on automatically at the time when EWA local is installed.

Edit: [EWA_ HOME]\config\um_cfg.xml

Set <PARAMETER name="userManagementService">HPUserManagement</PARAMETER>
Set <PARAMETER name="authenticationMode">Own</PARAMETER>

EWA supports different authentication modes for the HP User Management:

 

7.4.2 LDAP

LDAP authentication offers the possibility to authenticate users using a generic LDAP server. Also Microsoft Active Directory can be used as authentication interface using LDAP. LDAP authentication is only possible if HP User Management is switched on.

The LDAP authentication interface offers four possibilities for authentication of users:

  1. LDAP Authentication (Most simple mode)
    The entered user name, domain and password are used for authentication by trying to bind against a LDAP server. If the bind is successful, it is assumed that the password was correct.
  2. LDAP Attribute comparism (Fetch Mode)
    The LDAP server is bound using a fixed account. An LDAP record is fetched using the userid and domain name of the entered credentials. One attribute from the record is then compared to the entered password of the user.
  3. LDAP Search and Result Attribute comparism (Search Mode)
    The LDAP server is bound using a fixed account. A LDAP record is searched in the directory using a specific scope with a filter which is generated using the credentials of the user. One attribute from the LDAP search result is compared with the password of the user.
  4. LDAP Entry Search and User Authentication
    The LDAP directory is searched for a user name like in search mode, the resulting matched user is authenticated using the provided password.

7.4.2.1 General Setup of LDAP

To enable LDAP authentication the following configuration needs to be adopted:

Edit: files [EWA_ HOME]\config\um_cfg.xml / [EWA_ HOME]\config\um_batch_cfg.xml

Set <PARAMETER name="userManagementService">HPUserManagement</PARAMETER>
Set <PARAMETER name="authenticationMode">LDAP</PARAMETER>

Modify the section "LDAP" to match your LDAP environment.

No matter which type of authentication you want to make use of, there is one common thing for all of them:

Specify your LDAP Server and Port:
<PARAMETER name="ldapHost">your.ldap.server</PARAMETER>
<PARAMETER name="ldapPort">389</PARAMETER>

Port 389 is an LDAP port of a typical "standard" environment.

You can also specify a fallback LDAP Server and Port. In case the first LDAP server is not available this fallback server will be used.
If no fallback server exists, leave the following parameters empty. Otherwise configure them as follows:
<PARAMETER name="ldapFallbackHost">your.ldap.fallback.server</PARAMETER>
<PARAMETER name="ldapFallbackPort">389</PARAMETER>

See the sections below for the specific settings of each individual authentication method.

7.4.2.2 Using LDAP Authentication (Simple mode)

Using this simple mode basically performs a "bind" against the given LDAP server. If a "bind" is succesful, the user will be authenticated successfully, if not the user will not be authenticated. Typically this will not work in large and complex setups where users are distributed in LDAP over several nodes which cannot be expressed by one single DN pattern.

To authenticate the user against LDAP by issuing a direct bind with the user credentials, the following settings in sections LDAP need to be adopted:

  1. Specify the bind DN to use for authentication:
    <PARAMETER name="bindDN">[your bind DN]</PARAMETER>
    DN with which the LDAP-Connection is established. Placeholders in the DN - to make the DN more flexible - are:
    {userid}
    {password}
    {domain}
     Note: This value only exists if you setup userids in the form "<domain>\<userid>"
    They will be replaced from the provided login information of the user. Before replacement, the characters "*()" of the entered user credentials will be escaped.
    Example for a bindDN parameter, which expects users in the subtree (com - company - {domain} - Users):
    CN={userid},CN=Users,DC={domain},DC=company,DC=com
  2. Specify the binding password for the connection:
    Placeholders
    {userid}
    {password}
    {domain}
    will be replaced by the submitted login information. The characters "*()" of the user credentials will be NOT escaped! To authenticate against LDAP, use the following setting:
    <PARAMETER name="bindPasswd">{password}</PARAMETER>
  3. Specify the mode for authentication:
    <PARAMETER name="authMode">authenticate</PARAMETER>

All other options in the section LDAP are not relevant in this case.

7.4.2.3 Using LDAP Fetch Mode

If you do not want to make use of LDAP user passwords for your EWA users, you may want to sign a specific attribute within the User object in LDAP as pseudo password. In this case we follow the approach:

  1. Bind to the LDAP server with one explicit "bind user" or even anonymous.
  2. Go down the hierarchy following a provided, flexible DN
  3. Resolve the attribute of the user object that was found and compare the password against this attribute

To process authentication using a LDAP fetch the following settings need to be performed within the configuration:

  1. Specify the bind DN to use for authentication:
    <PARAMETER name="bindDN">[your bind DN]</PARAMETER>
    DN with which the LDAP-Connection is established with an explicit "bind user". These values will be fixed as they are needed for binding and do not make use of the provided login information during the.authentication process. You might even be able to bind anonymously. In this case you can leave the "bind" fields empty.
    Example:
    CN=Administrator,CN=Users,DC=myDomain,DC=company,DC=com
  2. Specify the binding password for the connection:
    <PARAMETER name="bindPasswd">noBodyShouldKnowTh1s</PARAMETER>
  3. Specify the mode for authentication:
    <PARAMETER name="authMode">fetch</PARAMETER>
  4. Specify the DN to fetch. This means that the LDAP tree will be followed down the given path stated by the DN and at the located User object a distinct attribute will be compared against the password or another fixed value.
    The DN is typically composed using the entered user credentials. The placeholders
    {userid}
    {password}
    {domain}

     will be replaced by the submitted login information. Before replacement, the characters "*()" in the entered credentials will be escaped.
    Example:
    <PARAMETER name="fetchDN">
    CN={userid},CN=Users,DC={domain},DC=company,DC=com
    </PARAMETER>
  5. Specify the attribute of the LDAP User object which should be used for comparison against the password:
    Example:
    <PARAMETER name="attribute">telephoneNumber</PARAMETER>
  6. Specify whether the attribute value should be encrypted before comparism. The encryption method is SHA-1.
    This will be set to "false" in most cases.
    <PARAMETER name="encryptAttributeBeforeCompare">false</PARAMETER>
  7. Specify whether the entered password of the user should be encrypted before comparism. The encryption method is SHA-1.
    This will correspond to "false" in most cases.
    <PARAMETER name="encryptPasswordBeforeCompare">false</PARAMETER>

All other options of section LDAP are not relevant in this case.

7.4.2.4 Using LDAP Search Mode

The "search" mode is even more advanced. In complex environments, the User objects will typically be distributed over several different subtrees within LDAP. Fetch is not sufficient in this case, so we allow a recursive "search" below a given subtree. To perform this search we need a root part of the tree - the DN from which to start (here referred to as "searchScope"). Furthermore we need a search clause to tell us how we find a User object that might by a potential candidate. And finally we need an attribute to compare the password against.

To process authentication using a LDAP search the following settings need to be done in the configuration:

  1. Specify the bind DN to use for authentication:
    <PARAMETER name="bindDN">[your bind DN]</PARAMETER>
    DN with which the LDAP-Connection is established. These values will be fixed as they are needed for binding, but could also be anonymous.
    Example:
    CN=Administrator,CN=Users,DC=myDomain,DC=company,DC=com
  2. Specify the binding password for the connection:
    <PARAMETER name="bindPasswd">noBodyShouldKnowTh1s</PARAMETER>
  3. Specify the mode for authentication:
    <PARAMETER name="authMode">search</PARAMETER>
  4. Specify the search filter to use when trying to find a LDAP record.
    Regular LDAP search filter expressions can be entered. See RFC 2254 for a detailed description of LDAP filters.
    The known placeholders
    {userid}
    {password}
    {domain}
    can be used in the expression and will be replaced automatically by the submitted login information. Before replacement, the characters "*()" in the entered credentials will be escaped.
    Note: Only the first matching record will be used for authentication!
    Examples:
    <PARAMETER name="searchFilter">
    mail=*_{userid}@{domain}.company.com
    (&(sAMAccountName={userid})(ObjectClass=user))
    employeeNumber={userid}
    </PARAMETER>
     
  5. Specify the search scope.
    Context which will be searched for an LDAP user entry.
    Again, the tokens
    {userid}
    {password}
    {domain}
    can be used and will be replaced by the submitted login information. Before replacement, the characters "*()" in the entered credentials will be escaped.
    Example:
    <PARAMETER name="searchScope">
    CN=Users,DC={domain},DC=company,DC=com
    </PARAMETER>
  6. Specify the attribute which should be compared against the password:
    Example:
    <PARAMETER name="attribute">telephoneNumber</PARAMETER>
  7. Specify whether the attribute value should be encrypted before comparism. The encryption method is SHA-1.
    This will correspond to "false" in most cases.
    <PARAMETER name="encryptAttributeBeforeCompare">false</PARAMETER>
  8. Specify whether the entered password of the user should be encrypted before comparism. The encryption method is SHA-1.
    This will correspond to "false" in most cases.
    <PARAMETER name="encryptPasswordBeforeCompare">false</PARAMETER>

All other options of the section LDAP are not relevant in this case.

7.4.2.5 Using LDAP Search and Authentication Mode (most valuable for accessing an MS ActiveDirectory)

Typically in an ActiveDirectory world you will still not be satisfied with the approaches discussed up to now. "Bind" will not work as in large environments you will not be able to specifiy a bind DN which is flexible enough, and "search" and "fetch" rely on attributes to be compared instead of using the ActiveDirectory password - which is not exposed as a separate attribute that we could use for comparison.

Any help out of this dilemma? Yes. We allow another mode which is "Search and Authenticate". The basic idea is that after finding a user candidate in the LDAP tree we bind it, because we now can get the real bind DN of this user. The name of this attribute holding the DN is "distinguishedName" in MS ActiveDirectory, in other LDAP directories it might be different, i.e. "dn".

To process authentication using a LDAP search and authenticate the following settings need to be done in the configuration:

  1. Specify the bind DN to use for authentication for searching the user account:
    <PARAMETER name="bindDN">[your bind DN]</PARAMETER>
    DN with which the LDAP-Connection is established. These values will be fixed as they are needed for binding.
    Example:
    CN=Administrator,CN=Users,DC=myDomain,DC=company,DC=com
  2. Specify the binding password for the connection:
    <PARAMETER name="bindPasswd">noBodyShouldKnowTh1s</PARAMETER>
  3. Specify the mode for authentication:
    <PARAMETER name="authMode">search+authenticate</PARAMETER>
  4. Specify the search filter to use when trying to find a LDAP user.
    Regular LDAP search filter expressions can be entered. See RFC 2254 for a detailed description of LDAP filters.
    Tokens
    {userid}
    {password}
    {domain}

    will be replaced by the submitted login information. Before replacement, the characters "*()" in the entered credentials will be escaped.
    Note: Only the first matching record will be used for authentication!
    Examples:
    <PARAMETER name="searchFilter">
    mail=*_{userid}@{domain}.company.com
    (&(sAMAccountName={userid})(ObjectClass=user))
    employeeNumber={userid}
    </PARAMETER>
     
  5. Specify the search scope.
    Context which will be searched for an LDAP user entry.
    Again, tokens
    {userid}
    {password}
    {domain}
     will be replaced by the submitted login information. Before replacement, the characters "*()" in the entered credentials will be escaped.
    Example:
    <PARAMETER name="searchScope">
    CN=Users,DC={domain},DC=company,DC=com
    </PARAMETER>
  6. Specify the attribute which should be user to define the DN of the user.:
    Examples:
    <PARAMETER name="attribute">dn</PARAMETER>
    <PARAMETER name="attribute">distinguishedName</PARAMETER>
    (recommended for MS Active Directory)

All further options of section LDAP are not relevant in this case.

7.4.3 Corporate Directory

This is basically used by Daimler internally in Stuttgart.

Edit: [EWA_HOME]\config\um_cfg.xml

Set <PARAMETER name="userManagementService">HPUserManagement</PARAMETER>
Set <PARAMETER name="authenticationMode">CorporateDirectory</PARAMETER>

Modify the section "CorporateDirectory" to match the DC CorporateDirectory LDAP settings and furthermore assure that the internal IT allows your EWA Server to access the Corporate Directory.

7.4.4 StarTekInfo

This is only used by MB USA for integration of EWA into the external StarTek portal. In this mode most parts of the EWA internal UserManagement become switched off.

Copy
[DVD-DRIVE]:\ewa\central\config\startekapi.properties
to
[EWA_HOME]\config
Edit the URL to the StarTekInfo server inside this file, if the server has changed.

Edit: [EWA_HOME]\config\um_cfg.xml
Set <PARAMETER name="userManagementService">StarTekInfo</PARAMETER>.

To run the WIS / EPC applications the user needs to log on using the StarTekInfo Portal. The rendered portal web page needs to use the following or an equivalent HTML form to start the application:

<form name="docWisForm" method="post" action="http://server.domain:9000/EWA-net/ewa-net.jnlp">
    <input type="hidden" name="userid" value="STAR0101" />
    <input type="hidden" name="sessionid" value="ABCDEFGHIJKLMNOPQRSTUVWXYZ" size="50" />
    <input type="hidden" name="function" value="start" />
    <input type="hidden" name="method" value="start" />
    <input type="hidden" name="appid" value="50" />
</form>

Check the Proxy Settings in the core configuration file [EWA_HOME]\config\core_cfg.xml. The EWA server needs to perform HTTP network access to the configured StarTek server and thus you may have to specify a proxy to allow this.

7.5 User Reports Configuration

EWA can be configured to send reports containing information about its users and their details, permissions for applications and data, and the groups and workshops they are members of. There are two types of user reports that can be requested:

  1. User Reports for the central accounting in XML form (archived and encrypted)
  2. User Reports for markets in HTML and CSV format (archived and optionally password protected)

7.5.1 User Reports for the Central Accounting

These reports are sent to the central accounting and are to be generated once a day. This daily generation rate cannot be changed. In the first step a backup-process is performed which stores the whole database as XML. This data is then transformed with an XSLT-Style sheet into the report. This report is then archived, encrypted using AES and sent to a free configurable email-address.

The process fulfills the following requirements:

7.5.2 Configuration

The configuration for these two types of reports is similar. The main difference is that the ID of the reports for the central accounting should be "accounting" while the IDs for the market reports can be arbitrary. The market reports also have several additional configuration options.

Reports for the central accounting are configured and activated in the configuration file:

File: [EWA_HOME]\config\core_cfg.xml

Note:
Any changes in the configuration will only be active after the server has been restarted.

The relevant block is:

<SECTION name="UserReporting">

The UserReporting block of the core_cfg consists of three parameters, that are valid for both the accounting as well as for the market reports, and the "accounting" section.

7.5.2.1 Main configuration parameters

  1. Flag if the user reporting extension is active. Setting to true will display further options in the Web GUI for managing users to types:
    <PARAMETER name="EnableExtendedUserType">true</PARAMETER>
  2. Flag if the accounting and markets user reporting are active and send out emails. When running in a clustered environment only ONE node should send out the user reports. Setting this parameter to false deactivates the generation of the reports and the sending of emails for both the central accounting and the markets:
    <PARAMETER name="SendUserReport">true</PARAMETER>
  3. Path for saving the report files on the disk. The path defined here will be appended to the EWA installation directory:
    <PARAMETER name="ReportDirectory">reports</PARAMETER>
    Any reports generated will be saved in this directory using the following conventions:
    For central accounting:
    <EWA>\<ReportDirectory>\userreport.xml                                     for market reports
    <EWA>\<ReportDirectory>\userreport.xml.zip                             for market reports
    <EWA>\<ReportDirectory>\userreport.xml.zip.bin                     for market reports (this encrypted file is attached to the mail)
    For the markets:
    <EWA>\<ReportDirectory>\<requestingID>_userreport.xml    for market reports
    <EWA>\<ReportDirectory>\<requestingID>_userreport.html      for market reports
    <EWA>\<ReportDirectory>\<requestingID>_userreport.csv        for market reports
    <EWA>\<ReportDirectory>\<requestingID>_userreport.zip        for market reports (this possibly encrypted archive is attached to the mail)

Requesters are defined in SECTIONs with requestingIDs and activity flags.

7.5.2.2 Configuration settings for the central accounting reports

<!-- The setting for the accounting xml report: -->
<!-- The ID "accounting" is reserved for this type of report -->
<!-- it should not be used as an ID for other types of report requesters -->
<!-- The following are valid options for the "active" parameter: -->
<!-- false: No reports are generated and sent by email (default) -->
<!-- true: License Reporting is active (as xml for the central accounting) -->
<SECTION requestingID="accounting" active="true">
   <PARAMETER name="ExportTime">00:00</PARAMETER>
   <!-- valid entry is only 'daily' -->
   <PARAMETER name="ExportDate">daily</PARAMETER>
   <!-- valid entry is only 1 -->
   <PARAMETER name="ExportDay">1</PARAMETER>
   <PARAMETER name="TargetAddressTo">startkey.ordering@daimler.com</PARAMETER>
   <PARAMETER name="TargetAddressCc">someaddress1@example.com</PARAMETER>
   <PARAMETER name="TargetAddressCc">someaddress2@example.com</PARAMETER>
</SECTION>
  1. The active parameter in the SECTION tag defines if this report is active and whether it will be executed. Setting this value to false will prevent the report from being generated and sent.
  2. The ExportTime parameter defines the time when the report will be executed and sent. Valid notation is "hh:mm". Failing to provide a valid strings results in resetting the export time to 00:00.
  3. The ExportDate parameter defines the interval at which the report will be generated and sent. The only valid entry for the central accounting reports is "daily".
  4. The ExportDay parameter defines the day within the specified interval (ExportDate) when the report will be executed and sent. The only valid entry for the central accounting reports is "1".
  5. The TargetAddressTo parameter defines a single email address to send the archived an encrypted report to. Do not change this value for the accounting reports.
  6. The TargetAddressCc parameter defines a single email address to send the archived an encrypted report to as carbon copy. Arbitrary number of parameters is allowed. Leave empty if no emails should be sent as CC.

Note:
Please be aware that the requestingID for this report should be accounting in order for it to be sent in the correct format.

Note:
Changing the value of the active flag to false will prevent the user report from being generated and sent to central accounting.

Note:
Be aware that the accounting report is used to generate invoices. Therefore it is very important not to send non-productive data. Please make sure that the report is deactivated if you set up a test server.

7.5.3 Market User Reports

There have been various requests by MPC/GV and other contracting parties for an overview of the ordered users and their access-rights. To avoid costly manual creation the reports are generated automatically by EWA.

The process fulfills the following requirements:

7.5.3.1 Configuration settings for the market reports

<!-- this is an example of a market report requester -->
<!-- the requestingID attribute is the name of this requester -->
<!-- all requestingIDs within this file need to have different values -->
<!-- the 'active' attribute determines whether to activate this requester or not --><!-- 
<SECTION requestingID="TestMarketOne" active="true">
-->;

    <!-- this parameter defines the time of the day when the report is to be executed -->
    <!-- 
    <PARAMETER name="ExportTime">22:44</PARAMETER>
    -->

    <!-- This parameter defines the interval at which reports are generated -->
    <!-- valid entries are daily, weekly, monthly, bi-monthly, quarterly, semi-yearly, yearly -->
    <!--
    <PARAMETER name="ExportDate">monthly</PARAMETER>
    -->
    
    <!-- This parameter defines the day corresponding to the interval at which reports are generated -->
    <!-- valid entries are (for interval: <range of valid values>): -->
    <!-- daily: 1; weekly: >=1, <=7; monthly: >=1, <=28-31; quaterly >=1, <=89-91; semi-yearly: >=1, <=180-184; yearly: >=1, <=365/366 -->
    <!-- The range of valid values depends on the current year, halfyear, quarter and month. -->
    <!--
    <PARAMETER name="ExportDay">1</PARAMETER>
    -->

    <!-- Here a single address can be defined to receive the email with the reports -->
    <!-- 
    <PARAMETER name="TargetAddressTo">someaddress@example.com</PARAMETER>
    -->

    <!-- Password for the zip archive that is created and sent by email. Optional -->
    <!-- 
    <PARAMETER name="Password"/>
    -->

    <!-- The following line defines a single CC address where a report email is to be sent -->
    <!-- Please note that you can duplicate this line several times to enter several CC addresses -->
    <!--
    <PARAMETER name="TargetAddressCc">some@example.com</PARAMETER>
    <PARAMETER name="TargetAddressCc">other@example.com</PARAMETER>
    -->

    <!-- the names of the necessary workshops for the report can be defined using regular expressions (see the advanced configuration documentation for detailed syntax explanations and examples) -->
    <!-- example: if all workshops beginning with "MBworkshop" are needed for the report use: "\AMBworkshop" or "^MBworkshop" as regular expression -->
    <!-- example: if all workshops ending with "test" are needed for the report use: "test\Z" or "test$" as regular expression -->
    <!-- comment this line if all workshops are needed for the report -->
    <!-- Group filters for workshops: -->
    <!-- Using the "groups" parameter a regular expression for the groups that should be included into the report can be defined -->
    <!-- Leaving it empty or not defining this parameter at all results in including all groups into the report. -->
    <!-- You can define several regular expressions using the OR notation - '|' -->
    <!-- Expressions are case sensitive! -->
    <!-- The next example includes all workshops that start with "MyShop"
    and all groups that either start with "abc" or end with "def"
    <PARAMETER name="Workshop" groups="(^abc)|(def$)">^MyShop</PARAMETER> -->
    <!-- The next example includes all workshops that start with "547" and end with "21" (with arbitrary characters in between)
    As no "groups" parameter is defined all groups will be imported.
    <PARAMETER name="Workshop">^547.*21$</PARAMETER>
    -->
    
<!-- End Tag for this report requester -->
<!--
</SECTION>
--> 
</SECTION>
  1. The requestingID parameter in the SECTION tag defines the name of this report and will be used for the generation of the e-mail body and the names of the report files. All requesters need to have different names.
  2. The active parameter in the SECTION tag defines if this report is active and whether it will be executed.
  3. The ExportTime parameter defines the time when the report will be executed and sent. Valid notation is "hh:mm". Failing to validate the format results in resetting the time to 00:00
  4. The ExportDate parameter defines the interval at which the report will be generated and sent. Valid entries are "daily", "weekly", "monthly", "bi-monthly", "quarterly", "semi-yearly" and "yearly".
  5. The ExportDay parameter defines the day within the specified interval (ExportDate) when the report will be executed and sent. E.g. If ExportDate is monthly and ExportDay is 3, the report will be sent exactly on the 3rd day of each month.
  6. The TargetAddressTo parameter defines a single email address to send the archived an encrypted report to.
  7. The TargetAddressCc parameter defines a single email address to send the archived an encrypted report to as carbon copy. Arbitrary number of parameters is allowed. Leave empty if no emails should be sent as CC.
  8. The Password parameter contains a password for the archive that is generated for the report files. Leave empty if no password is required.
  9. The Workshop parameter contains a regular expression defining the names of the workshops that should be included in the report upon successful match.
  10. The groups parameter within the Workshop element defines a regular expression for all the groups the should be included in the report upon successful match.

Note:
Both positive and negative regular expressions can be defined using certain special characters.

A short example for positive regular expression:
    ^abc.*def$            :    include all that start with "abc" and end with "def" (with arbitrary characters in between)

A short example for 'negative' regular expression:
    ^abc(?!.*def$)    :    include all that start with "abc" and DO NOT end with "def" (with arbitrary characters in between)

For detailed explanations on the syntax of regular expressions and examples see below.

Note:
Any changes in the configuration will only be active after the server has been restarted.

7.5.3.2 Changing the E-Mail Body of the Market Reports

The body of the e-mail that the market reports are sent with is generated by the XSL transformation file licReportEmail_mr.xsl. This file is located in the webapps\EWA-net\WEB-INF folder of your EWA-net installation. The default body has the following format:

Dear recipient,

please find attached the <export interval> report of all workshops with names like: 
<workshop and groups regular expressions list>

Best Regards,

Your system administration team.

7.5.3.3 Regular Expression Syntax for Workshop and Group Filters

Using different types of filters is possible for the market reports functionality of EWA. Filters allow to include only specific workshops and groups into the market reports and exclude others. Filters are defined using the standard regular expressions syntax.

Special characters:

|          alternative ("or", e.g.: this|that) 
.               one arbitrary character 
*               repeat the last character (the same character may present zero or many times) 
.*              arbitrary string (zero or more arbitrary characters)
+               repeat the last character(at least one time) 
?               the last character should appear one time or not at all 
{n} {n,m}       the last character must appear n or n to m times (e.g.: W{3} corresponds to WWW)
\A              start of the string
^               start of the string
\Z              end of string 
$               end of string
\w              alphanumeric character including "_" 
\W              not alphanumeric character including " " 
\b              word boundary ("boundary", e.g.: \bin\b for the word 'in') 
\B              non-boundary 
\d              digit 
\D              no digit 
\s              whitespace 
\S              non-whitespace 
[...]           class of characters, e.g. [A-H] letters A to H 
[^...]          exclusion of a class of characters, e.g. [^A-H]: any characters besides any from the class [A-H]
?!              Negate the next (e.g. ^abc(?!.*def$|ghi$) - anything that starts with "abc" and does NOT end with "def" or "ghi"

Regular Expressions examples (Case Sensitive!!!)

1. All strings that have "200" anywhere in them: "200"
        Example: Will accept e.g. "200xxx", "xxx200", "xxx200yyy"
        Note: If the pattern does not define that the search should 
        start at the beginning or at the end, the whole string is
        searched for occurrences.

2. All strings that begin with a "200": "\A200" or "^200"
        Example: Will accept e.g. "200xxxx"
        Will NOT accept : "y200xxx" (200 is not the beginning of the string)
        Note: "\A" or "^" denotes the beginning of a string

3. All strings that end with a "200": "200\Z" or "200$"
        Example: Will accept e.g. "xxxx200"
        Will NOT accept : "xxxx200y" (200 is not the end of the string)
        Note: "\Z" or "$" denotes the end of a string

4. All strings that start with exactly three arbitrary characters, 
        followed by a "200", followed by arbitrary characters: "\A...200"
        Example: Will accept e.g. "123200" or "123200xxx".
        Will NOT accept : "12200" or "12200xx" (only two characters before "200") 
        Note: "." denotes an arbitrary single character
        Note: ".*" denotes an arbitrary number of arbitrary characters

5. Any string that has at least one character: "."

6. Strings starting with "200" followed by an arbitrary number of characters, 
        followed by "91", followed again by an arbitrary number of characters: "\A200.*91
        Example: Will accept e.g. "200xxxx91" or "200xx91xxxx" or "20091xxx"
        Will NOT accept "x200yy91" as 200 is not at the beginning
        
7. String starting with "200", then two characters, then "91",
        then arbitrary characters then "21" then end of string: "\A200..91.*21\Z"
        Example: Will accept e.g. "200xx91yyyy21" or "200xx9121"
        Will NOT accept : "200x91yyyy21" (only one character between 200 and 91) 
        "200xx91yyyy21z" (21 is not at the end)
        "z200xx91yyyy21" (200 is not at the beginning)

Negative examples:
8. String that are NOT exactly "abcdef": "^(?!abcdef$)"

9. String that start with "abc" then have arbitrary characters 
        and do NOT end with "def" or "ghi": "^abc(?!.*def$|ghi$)"
        Example: Will accept e.g. "abcXXX"
        Will NOT accept e.g. "abcXXXdef" of "abcXXXghi"    

7.6 Shoppinglist/Joborder webservice exchange

EWA provides the Job Order (JO)/ Shopping List (SL) data via a central provided web service.

A web service notification mechanism is provided to inform all atached systems if a new JO/SL was stored in EWA’s core database. In response to a notification a system like Webparts or ASM then queries EWA’s web service to retrieve the data.

Process identification data is needed for each JO/SL dataset because every single user will have multiple JO/SL data sets stored in EWA’s central core database. Therefore EWANAPI needs a new optional parameter to submit the actual process context to WIS/EPC.

EWA needs to keep the existing file exchange mechanisms because EWA is used with a wide variety of DMS systems which aren’t controlled by Daimler. When EPC or WIS is started with a process ID it should automatically default to using the Data Exchange Service to store JO/SL data.

When EPC starts WIS it should pass its current process ID to WIS and vice versa.

 

 

Step Number

Description

1

ASM/WebParts starts EWANAPI via Web Start and submits the actual process ID.

2

The process ID gets submitted to WIS or EPC.

3

JO/SL data is saved to the EWA backend.

4

All subscribers get a new data available notification for a particular process ID.

5

One of the subscribers (ASM or WebParts) should recognize the process ID as one which it generated and then get the new dataset via a web service offered by EWA.

Additional information about the web service can be taken from the Data Exchange Service User Documentation

8 Single Sign On with EWA

8.1 Single Sign On

When it comes to web applications and portal solutions, one of the main annoyances that users have to deal with is having to enter their credential information again and again for many of those applications. Single Sign On (often referred to as SSO) is a mechanism to provide more comfort to the user while still keeping the security aspects in mind.

Single Sign On can be enabled transparently for EWA, but as it has some requirements from the infrastructure side it cannot and will not be enabled and installed by default. If you decide to switch your EWA environment to Single Sign On, please keep in mind that you still have to store all the relevant user information inside EWA's User database. This is caused by the fact that EWA still has to perform the authorization internally - although the authentication might have already been performed by Single Sign On.

Single Sign On feature will be automatically switched on in case your environment has been prepared according to the steps below. If a user cannot be authenticated via Single Sign On then EWA automatically falls back to interactive login.

8.1.1 Windows NTLM Authentication

You will typically make use of Windows NTLM authentication if

Note:
Please ensure that you have set up all users with their respective MS Windows domain accounts inside of EWA, i.e. not just "johndoe", but "EMEA\johndoe" in case the user "johndoe" is part of the "EMEA" domain. Forgetting this results in the fact that users cannot automatically be authenticated.
The passwords of the users inside the EWA system do not have to be "real" passwords. Dummy passwords ensuring that the EWA passwords policy are being matched will be sufficient.

8.1.1.1 Setting up SSO on Tomcat and Internet Information Server (IIS)

A quick overview over the necessary steps that are required to allow NTLM authentication with Tomcat and IIS:

After setting up Tomcat and IIS you must also perform the steps in the following sections:

The steps will be described in detail below. Don't worry, they are quite quickly and easily performed.

8.1.1.1.0.1 Setup Internet Information Server

You may setup IIS on the same machine as your EWA installation is running on, or you may install it on a separate machine. For smaller installations that will run in NTLM mode only it might be sufficient to setup the IIS on the same machine as the EWA server is running on.

Note:
For large EWA installations and/or installations that you want to run in mixed mode (users being part of a Windows domain and "other" users who would have to login to EWA interactively) you will definitely have to setup separate instances of Web Servers - one with NTLM security switched on, one with anonymous security to allow interactive login to EWA.

Note:
If you run a local version of EWA (with a local access authorization) you will definitely have to setup the WebServer on the same machine as the EWA Server is running on. If you do not follow this guideline, the EPC and WIS application will not start claiming that it cannot exchange a token with the server.

Installation, if not already done, can be performed via the Windows Control Panel in the "Add/Remove Software" control. Choose "Add/Remove Windows Components".

Note:
This description assumes that IIS can be used for the EWA integration only. For hosting of several different applications with this single IIS instance  you may encounter restrictions or problems.

After installing IIS you have a new directory structure below C:\InetPub

8.1.1.1.0.2 Configure and restart the EWA server

In order to allow a Web Server plugin to contact the EWA application server we must enable the module allowing this. Open the file

[EWA_HOME]\server\conf\server.xml

Search for the word "AJP/1.3" which will guide you to the connector for the Web Server plugin. This is by default commented out, so remove the XML comments before and after the "Connector" section.

If the content in your standard XML file looked like this:

  <!--
      Define an AJP 1.3 Connector on port 8009
<Connector port="8009" 
        backlog="200"
        maxThreads="200"
        enableLookups="false"
        redirectPort="8443"
        secure="false"
        protocol="AJP/1.3"
        tomcatAuthentication="false" />
 -->

 

Simply change it to this (see the marked characters):

  <!--
      Define an AJP 1.3 Connector on port 8009
  -->
<Connector port="8009" 
        backlog="200"
        maxThreads="200"
        enableLookups="false"
        redirectPort="8443"
        secure="false"
        protocol="AJP/1.3"
        tomcatAuthentication="false" />

Now we have to tell EWA that clients will contact the EWA environment via the standard HTTP port 80 instead of the standard EWA port 9000. In order to achieve this, please open the file

[EWA_HOME]\config\core_cfg.xml

in a text editor and change the following setting accordingly to port 80. Ensure you have SSL disabled

<SECTION name="AccessGateway">
        <SECTION name="ApplicationSettings">
        <!-- SSL within EWA - do not forget to configure your server accordingly -->
             <PARAMETER name="sslEnabled">false</PARAMETER>
            <!-- SSL for client - server communication - should be configured only together with sslEnabled -->
                <PARAMETER name="sslForClientsEnabled">false</PARAMETER>
             <PARAMETER name="httpPort">80</PARAMETER>

Note:
SSL on the EWA server will not be used. If you want to secure access to EWA you may install a server certificate on the Web Server machine. Secured connection between the Web Server and the EWA server is not needed.

Restart the EWA server now. You will still be able to access the login page via port 9000 on the EWA server itself, but you will not be able to start any EWA client application anymore. This is okay.

8.1.1.1.0.3 Install files from the EWA media
8.1.1.1.0.4 Configure and restart the IIS

After you have all files installed you can start configuring the IIS. Open the Windows Management Console and open the hive of the "Internet Information Services".

Add the redirection handler which will forward all EWA related request to the EWA server. Select the "Default Web Site" hive and display its properties. Select the tab "ISAPI Filters" and add a new filter with name "jakarta" and pointing it to the isapi_redirect.dll into this directory:
file in the installation directory of your SSO files, i.e. C:\InetPub\wwwroot\ewa_sso\isapi_redirect.dll

 

Press "OK" and select the tab called "Directory Security". Click on "Edit" in the field named "Anonymous access and authentication control". Uncheck any current checkmark and set the checkmark "Integrated windows authentication". Ensure that only this checkmark is set.

Press "OK" to close this dialog and press "OK" again on the properties main dialog. You might be asked whether you want to apply the setting to some other components as well. Simply press "OK" here again and continue.

Now install an additional so called "Virtual Directory". Right-click the "Default Web Site" hive and select "New -> Virtual Directory". This will open a wizard. Please follow the following instructions exactly:

You will be asked for an alias. Please enter "jakarta".

The next screen will ask you for the directory which this virtual directory shall represent. Please enter "C:\InetPub\wwwroot\ewa_sso" or the directory you had chosen above.

The last screen will ask you for the permissions. Ensure you enable the checkmark "Execute (such as ISAPI applications or CGI)".

Finalize the wizard, right click the just created virtual directory "jakarta" and compare your settings with the following screen:

 

If you run Windows Server 2003 or newer for your Web Server (only in this case) you will have to perform the following additional step which is not needed on Windows 2000 Server based systems:

Click on the "Web Service Extensions" hive and click on "Add a new Web Service extension". If you forget this step the integration will not work as by default unknown ISAPI filters will be forbidden to run. Fill out the appearing dialog as follows:

Okay, that's all for the configuration of the Web Server.

Go to the "Services" hive inside the Management console and restart the "IIS Admin Service" now.

Please review again all your settings.

8.1.1.2 Check the Environment

You can now check whether your Web Server is correctly forwarding the requests to the EWA server.

Open Internet Explorer on the Web Server machine and enter the URL:

http://localhost/EWA-net

The minimum you should see now is the login mask of EWA. If you cannot see this, please review the steps above and perform each of the steps again. Typical pitfalls are misspelled directory names, a wrong hostname, etc.

If this check is correctly working, try to connect the Web Server from any other computer of the domain and see if that works as well. Complete your tests by also starting WIS and EPC to ensure that your environment is completely working.

If you are currently logged on to a Windows domain and this account has already been setup within EWA's User Management then you should automatically be logged in - the interactive login page in this case will automatically be skipped and you will automatically see the "Programs" menu within EWA.

SSO will automatically be used if you connect to the EWA server via the URL

http://localhost/EWA-net

If you want your users to be forced to login interactively tell them to connect via the URL

http://localhost/EWA-net/Login/showLogonForm.do

 

Note:
If you perform tests on your Web Server on Windows 2003 directly, please check your Site settings within Internet Explorer to ensure that NTLM credentials will really be sent to the web server. The appropriate settings can be found in "Tools -> Internet Options ->  Security". Please click on "Sites..." and ensure that "http://localhost" is part of that list. See below:

Example:
Let's assume you have been logged on to Windows as "EMEA\johndoe" where "johndoe" is the account name (user login) and "EMEA" the name of the Windows domain the user belongs to. You may setup a user (no matter which user role) now in EWA with the fully qualified user login "EMEA\johndoe" (pattern <domain>\<userid>) instead of only his login name. This is the most important thing to be aware of. You will have to provide a password for him as EWA , but this will not be used for SSO, of course, but it might be used as a fallback should the domain login not be possible.

Now that your Web Server integration successfully works, please do not forget to switch the logging level for the bridge down to "error". Open the file isapi_redirect.properties  and change the line loglevel=debug to loglevel=error. Restart the IIS Admin service.

8.1.1.3 Client Setup for SSO

8.1.1.3.0.1 Ensure the correct Java Runtime

Please refer to the EWA requirements and make sure that the proper Java Runtime has been installed on all the client machines that want to make use of the SSO feature.

8.1.1.3.0.2 EWANAPI Update

This step will only have to be performed if your installation makes use of the EWANAPI interface (i.e. for DMS interconnectivity,...). In order to ensure that EWANAPI can make use of the SSO feature, it needs the information to which Web Server it has to connect and on which port.

Therefore the users have to login to EWA, run the EWANAPI Installer which will perform the updates.

After the update, you might simply issue a command like this in a command prompt:

EWANAPI.exe

See it? On Windows clients being part of the domain the user credentials will not have to be provided to EWANAPI anymore. The current user credentials of the logged on user will automatically be used. For users not being part of the domain it's still the old game - they will have to provide their credentials on the command line.
The call above should start the WIS client with the user account of the user who is currently logged on against a domain on that client machine.

Congratulations! Working with EWA has become even more comfortable for you and your users.

8.1.2 SiteMinder Authentication

The aim of this section is to describe how to integrate EWA into a SiteMinder authentication environment. SiteMinder is a web based Single Sign On (SSO) solution from Computer Associates. Web application can be seamlessly integrated into SiteMinder SSO – this is achieved by configuring the application's front end HTTP Server so that requests to the application can be intercepted and in case that the user is not yet authenticated, SiteMinder will redirect the user's browser to the SiteMinder web based login form where the user can supply his username and password. After successfully authenticating SiteMinder issues an access token in the form of a browser cookie and the user's browser is redirected back the original page which it attempted to open. Each and every request to the application server is intercepted by SiteMinder, if the request contains a valid access token (cookie) then the request is passed on the Web Application Server (e.g. tomcat via JK/AJP).

Special adaptation of EWA was required as WIS and EPC applications are Java-Swing applications and not web based. These applications communicate with the backend server via HTTP to read or persist data. The "Client Communication Layer" is the component which has been extended to handle the SiteMinder authentication challenges, where possible transparent to the user. In a minor number of cases a Java-Swing dialog will be displayed to gather the user's credentials required for SiteMinder authentication

8.1.2.1 Configuration of SiteMinder

The installation and base configuration of SiteMinder WebAgent component on the front end HTTP server is beyond the scope of this document please refer to the Computer Associates documentation. After installing the SiteMinder WebAgent on the front end HTTP server it is necessary to specify which URL's will be secured and which will remain unprotected. Unprotected areas are required for the following reasons:

URLSecurity Setting
  
/WIS-net/Unprotected
/EPC-net/Unprotected
  
/EWA-net/Protected including all sub directories except the following
/EWA-net/download/Unprotected
/EWA-net/jnlp/Unprotected
/EWA-net/xmlparameterUnprotected
/EWA-net/userUnprotected

Note:
It is necessary to configure the SiteMinder WebAgent not to Preserve Post Data. To do this add/set PreservePostData="NO" to the SiteMinder WebAgent configuration file.
Additionally SetRemoteUser="YES" must be set so that the login-name of the user authenticated by SiteMinder is passed through to the tomcat server. The configuration file can be found on the frontend HTTP server and is called LocalConfig.conf, however in some environments the SiteMinder Poilicy Director Server may have been configured to override the local configuration, in this case you must ask the Policy Director administrator to change the two parameter's values.

SiteMinder installations protecting corporate sites are usually visually customized, thus a few parameters must be configured so that EWA can function correctly. The following table lists the parameters which must be configured in the core_cfg.xml file which is in the [EWA_HOME]\config\ folder. The parameters are in the SiteMinder subsection of the AccessGateway section.

ConfigurationDefaultTypeDescription
siteMinderEnabledfalseBoolean as String (true | false)Set to true if the EWA server is protected by SiteMinder.
authURLPatternn/aRegular Expression StringThe Java Regular Expression which matches positive for the SiteMinder URL to which a request is redirected when authentication is required.
form-- Not set --StringThe name attribute of the SiteMinder authentication HTML <form> element. If the value is not set then the first form will be assumed.
formUserUSERStringThe name attribute of the HTML <input> element where the Username must be entered.
formPasswordPASSWORDStringThe name attribute of the HTML <input> element where the Password must be entered.
formSubmit-- Not set --StringThe name attribute of the HTML <input> element used to submit the form.
formCredCookieFROMCREDStringThe name of the Form Credentials Cookie set by SiteMinder in response to submitting user credentials to the Authentication screen.
formSessionSMSESSIONStringThe name of the SiteMinder Session Cookie set by SiteMinder in response to submitting a request with a Form Credentials Cookie containing valid user credentials.

8.1.2.2 Working with SiteMinder SSO integration activated

To finalize the installation restart the Web Application Server [Tomcat | WebSphere] and login to EWA. You will also need to ensure the usernames in EWA are the same as those user for logging onto SiteMinder (usually the Email address of the user). When starting EWA in the browser the URL of the front end server, which has been configured for SiteMinder, will be used. The user will be initially redirected to the Corporate SiteMinder login page where he or she must login. After logging the SSO mechanism of EWA will come into action and the EWA application will be shown without the user needing to login again. EPC or WIS can now be started.

In one use case it will be necessary to reenter his/her credentials. This happens if the SiteMinder session times out which happens if the SiteMinder integration has be configured to force users to re-authenticate after a defined period of time. This configuration is a setting of the SiteMinder plug-in which was installed on the front end Server). If the user is working with a web application then he/she will be redirected to the web based corporate logion screen. If however this happens which working with a non web based application (EPC or WIS) then the application will display a dialog requesting the user's credentials.

9 Clustering of an EWA Server

9.1 Clustering

This chapter is based on an evaluation performed for EWA. Goal was to find existent possibilities to deliver EWA in a clustered environment. The main motivation behind the effort is to provide in the future a high available, distributed, fault-tolerant and load-balanced environment.

A clustered EWA should improve:

And reduce:

Nonetheless this description does not inquire into:



Clustering EWA local version depends on Apache and Jakarta Tomcat clustering features.

Basically this document assumes that an appropriate DNS and NAT solution for EWA will be provided by Daimler or other responsible network administrators. On the other hand, this description provides the necessary steps and options to set up an EWA application with multiple web-servers and JSP Servlet engines. How TCP/HTTP requests reach each of these clustered web-servers is not defined or described.

9.2 Clustering EWA using Tomcat application server

EWA local architecture uses Jakarta Tomcat as web server and servlet container. Since EWA's content is mostly dynamic, HP suggests to keep mainly Tomcat as web server for serving content. Additional front-end web servers can be used to distribute request amongst several cluster nodes in the EWA server farm. Besides the request distribution (using a sticky session) the usage of a front-end HTTP server will not generate further performance benefits. The main part for clustering lies in clustering the application servers. HTTP front-end servers could be clustered to improve availability. The EWA installation in this case should be complete and each application server node should contain the application server and the Transbase content databases. The User Management database should be located at a central location and have a high performance clustered server. The clustered architecture of EWA should look like this:


Example Clustering setup in a EWA Farm

9.2.1 NAT Request distributors / Load Balancers

NAT request distributors or Load Balancers can be used for load balancing, fault tolerance, or both. Usually the algorithm chosen to distribute requests depends on the NAT product installed. Most NAT request distributors also offer fault tolerance by detecting various kinds of web server faults, and then will stop distributing requests to any server that is down.

There are many NAT request distributor implementations available, both commercial and as open source software that runs on commodity computer hardware. However further investigation is not part of the scope of this description.

Besides regular NAT request distributor products also built-in Windows Server 2003 functionality for load balancing (NLB) can be used for Distributing requests. Note that Windows Server 2003 NLB is a layer 3 distributor so is not able to detect session types or application server service failures!

9.2.2 Using mod2jk and Apache httpd for Load Balacing

When using Apache httpd as web server and Tomcat as servlet container, the communication connector offered by Tomcat (mod_jk) offers best load balancing and failover across several Tomcat instances. Each Apache with mod_jk in a cluster can perform:

9.2.3 Distributed Java Servlet Containers

A distributed servlet container will generally deploy and run one instance of the application per servlet container, with each servlet container and web application in a separated JVM, and requests will be processed in parallel. Additionally, each Tomcat instance runs its own instance of the web application, and treats the application instance as if it is the only instance running.

9.2.3.1 Servlet Sessions

Defined by Java Servlet Specification 2.4 and chosen by Tomcat developers, all requests belonging to the same session from a single client must be processed by the same servlet container instance. This makes Session object replication an optional feature of distributed servlet containers. According to the specification, it is not mandatory for distributed servlet containers to implement session replication.

9.2.3.2 Session Affinity (or Sticky Sessions)

For web applications that are marked as distributable, all requests belonging to one HTTP session are served by one Tomcat instance. This is called session affinity. Session replication is not necessary for the application to function if session affinity is used. However, if the Tomcat instance or the server machine it runs on fails, the servlet session data is lost and the user may need to login again.

As the WIS and EPC applications support transparent session recovery, a failover may not be critical in most cases, so using sticky sessions will prevent the requirement for session replication.

If you are not able to run the installation with sticky sessions, you need to implement a session replication, so that the current session state is replicated to all cluster nodes.

9.2.3.3 Replicated Sessions

With replicated sessions, if one Tomcat instance crashes, the session state data is not lost because at least one other Tomcat instance has been sent a copy of that data. Some servlet session replication implementations replicate all sessions to all servlet container instances in the cluster, whereas other implementations replicate one servlet container instance's sessions to only one or two "buddy" servlet container instances in the cluster.

If the request distribution mechanism between the servers use sticky sessions, session replication is not required (as the application automatically re-connect to server). However session replication can prevent some detailed use cases where problems may arise.

It is also required to mention that the implementation of session replication will generate a bit of network and CPU overhead compared to standalone installations.

9.2.3.3.1 Session Replication in Tomcat 7

Tomcat 7 has at least a couple of session replication implementations. This section investigates the open-source implementation which is integrated into Tomcat 7. This session replication works based on UDP multicast. Therefore it is necessary that the network adapter used supports multicasting. A unicast TCP implementation is provided for Tomcat 7 also.

Note:
The Windows systems required to run EWA should already have the appropriate ServicePack installed to solve some issues related to multicasting like Q319627 (Multicast Fragmentation).
See here for more information: http://support.microsoft.com/default.aspx?scid=kb;en-us;319627

9.3 Steps to Cluster EWA with Tomcat as Application Server

This section assumes you have successfully installed EWA.

9.3.1 Installing Apache Web Server

Extract the Apache HTTPd installation EXE from EWA delivery DVD, which is contained in \ewa\central\tools\apache_httpd.zip. (Alternatively you can download the release from http://httpd.apache.org/download.cgi and compile it on your own). Apache installation steps for Windows are simple. Make sure the following Windows services are stopped and configured for "Manual" start if you are using Windows 2000:

Install as many Apache Web servers as the cluster foresees. Usually each HTTP server is installed in a separated server.

Note:
This description describes the integration with Apache 2.2.8 - any other version may also be suitable - but has not been tested.

9.3.2 Install and Configure mod_jk Connector

This section describes how to install and use Tomcat 7 as a backend servlet container to the Apache HTTPd web server via a custom protocol connector module. The steps must be followed for each Apache and Tomcat instance running and the clustered architecture is assumed to be similar to the architecture figure shown earlier:

  1. Before installing mod_jk2 connector, please make sure the Apache HTTPd server is running correctly.

  2. Stop "EWA net Server" and Apache HTTPd windows services.

  3. Extract the connector from EWA installation media. The mod_jk is contained in \ewa\central\tools\apache_httpd.zip. Alternatively you can download the module sources from http://tomcat.apache.org/download-connectors.cgi the release 1.2.30 of mod_jk2 connector. Make sure the mod_jk2 version fits to the Apache HTTPd-version you are using.
    E.g. mod_jk-1.2.30-httpd-2.2.3.so has been built for Apache 2.2.x, whereas mod_jk-1.2.30-httpd-2.0.53.so has been built for Apache 2.0.x.

  4. Unzip mod_jk.so file into [APACHE_HOME]\modules a file called mod_jk.so.

  5. Edit the file [APACHE_HOME]\conf\httpd.conf and add the configuration entries as contained in \ewa\central\tools\apache_httpd.zip --> httpd.conf_entries_example. For further reference please visit http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html. Please do not forget to adjust the described path's in the file!

    # Sample extension file which needs to be added to Apache HTTPD configuration file httpd.conf
    # For further referece, please take a look to:
    # http://tomcat.apache.org/connectors-doc/config/apache.html
    
    # TODO: Please align path's to you installation
    # TODO: After integration is completed and is working, set the logging switch to error
    #Load the jk_mod
    LoadModule jk_module modules/mod_jk.so
    # The name of a worker file for the Tomcat servlet containers
    JkWorkersFile "C:/Program Files/Apache Software Foundation/Apache2.2/conf/workers.properties"
    
    # Full or server relative path to the Tomcat Connector module log file 
    JkLogFile "C:/Program Files/Apache Software Foundation/Apache2.2/logs/mod_jk.log"
    
    # The Tomcat Connector module log level, can be debug, info, warn error or trace
    # Note: Set to error if the integration is working!
    JkLogLevel debug
    
    # A mount point from a context to a Tomcat worker
    JkMount /EWA-net ewanet
    JkMount /EWA-net/* ewanet
    JkMount /WIS-net/* ewanet
    JkMount /EPC-net/* ewanet
     
  6. If your EWA Servers' AccessGateways are configured to listen to any other port than port 80, the load-balancer needs to listen to this port, too. EWA's default port is 9000. You can check the port of your EWA Servers's AccessGateways in the file [SERVER_HOME]\config\core_cfg.xml. Search for the PARAMETER "httpPort" and take this number.

    <SECTION name="AccessGateway">
            <!-- Section to define where the Access Gateway finds the Applications -->
            <SECTION name="ApplicationSettings">
                    <!-- SSL within EWA - do not forget to configure your server accordingly -->
                    <PARAMETER name="sslEnabled">false</PARAMETER>
                    <!-- SSL for client - server communication - should be configured only together with sslEnabled -->
                    <PARAMETER name="sslForClientsEnabled">false</PARAMETER>
                    <PARAMETER name="httpPort">9000</PARAMETER>
                   

    To make the load-balancer listen to this port you need to add a Listen-entry to the file [APACHE_HOME]\conf\httpd.conf. By default only port 80 is mentioned here.

    #
    # Listen: Allows you to bind Apache to specific IP addresses and/or
    # ports, instead of the default. See also the <VirtualHost>
    # directive.
    #
    # Change this to Listen on specific IP addresses as shown below to 
    # prevent Apache from glomming onto all bound IP addresses.
    #
    #Listen 12.34.56.78:80
    Listen 80
    Listen 9000
             
    
  7. Extract the file workers.properties from the archive \ewa\central\tools\apache_httpd.zip and modify it with a text editor (i.e. Windows Notepad) depending on your environment. Note that the name of each defined worker needs to match the defined jvmRoute in Tomcats server.xml!

    # Configuration filr for mod_jk to connect to Tomcat
    # For further reference, please take a look to:
    # http://tomcat.apache.org/connectors-doc/config/workers.html
    
    # Define the central EWA worker
    worker.list=ewanet
    
    # Define the EWA worker as a cluster to balance requests to three hosts
    worker.ewanet.type=lb
    worker.ewanet.balanced_workers=ewanode1,ewanode2,ewanode3
    worker.ewanet.sticky_session=1
    worker.ewanet.sticky_session_force=0
    
    # Define EWA working application host 1
    worker.ewanode1.type=ajp13
    worker.ewanode1.host=192.168.0.10
    worker.ewanode1.port=8009
    worker.ewanode1.lbfactor=1
    
    # Define EWA working application host 2
    worker.ewanode2.type=ajp13
    worker.ewanode2.host=192.168.0.11
    worker.ewanode2.port=8009
    worker.ewanode2.lbfactor=1
    
    # Define EWA working application host 3
    worker.ewanode3.type=ajp13
    worker.ewanode3.host=192.168.0.12
    worker.ewanode3.port=8009
    worker.ewanode3.lbfactor=1

9.3.2.1 Changes in all EWA Servers

These changes should be applied to all EWA servers in your cluster.

  1. Open the file <EWA-net>\server\conf\server.xml and un-comment (enable) the following lines in the connectors section of the file:

    <!--
        Define an AJP 1.3 Connector on port 8009
    -->
    <Connector port="8009" 
               backlog="200"
               maxThreads="200"
               enableLookups="false"
               redirectPort="8443"
               secure="false"
               protocol="AJP/1.3" />

     

  2. If you don't want anymore the users to access EWA directly through Tomcat, you can comment the connector declaration which uses port 9000 in the file server.xml mentioned before.

  3. In the same file modify the Engine definition of Tomcat by modifying the jvmRoute attribute. Each EWA server in the cluster must have a unique jvmRoute name (e.g. ewanode1, ewanode2, etc). Note that for sticky session the workers in mod_jk's workers.properties need to be named accodingly matching the jvmRoute's!

    <!--
        Define the top level container in our container hierarchy
    -->
    <Engine name="EWA net Server Engine"
            defaultHost="localhost"
            jvmRoute="ewanode1">

9.3.2.2 Configuring Session Replication

Session replication for Tomcat 7 is implemented in the core version of the application server. No special extensions of software modules are required.

  1. Stop all EWA servers in your cluster.

  2. Tomcat session replication makes use of multicast. Make sure all EWA servers and used network interfaces support multicasting. Please check out your operating system manuals.

  3. Open the file <EWA-net>\server\conf\server.xml and un-comment the following lines inside the EWA Host section of the file:

    <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
                     channelSendOptions="8">
    
      <Manager className="org.apache.catalina.ha.session.DeltaManager"
                       expireSessionsOnShutdown="false"
                       notifyListenersOnReplication="true"/>
    
      <Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <Membership className="org.apache.catalina.tribes.membership.McastService"
                                    address="228.0.0.4"
                                    port="45564"
                                    frequency="500"
                                    dropTime="3000"/>
            <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                              address="auto"
                              port="4000"
                              autoBind="100"
                              selectorTimeout="5000"
                              maxThreads="6"/>
    
            <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
              <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
            </Sender>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
      </Channel>
    
      <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
                     filter=""/>
    
      <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
                            tempDir="/tmp/war-temp/"
                            deployDir="/tmp/war-deploy/"
                            watchDir="/tmp/war-listen/"
                            watchEnabled="false"/>
    
      <ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
      <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
    </Cluster>


  4. Restart Tomcat and Apache.

[Cluster1] A non-stop service is theoretically possible but in practice depends on the clustering choices made regarding overall application architecture, hardware platforms. Training the system's administrators is also an effective way to reduce downtime.

[Cluster2] C-JDBC might be useful for the EWA architecture. Testing C-JDBC together with EWA is however not part of the scope in this phase. See http://c-jdbc.objectweb.org.

   

10 De-Installation

For the de-installation of EWA just follow the standard way for Windows applications. Go into the Control panel into “Add or Remove Programs”, select the entry “EWA” and click on “Change/Remove”.

The EWA software will be completely deinstalled from the system.

10.1 "Hardcore" de-installation

You might at some point face the problem that one step of the advanced de-installation fails and subsequently the whole de-installation fails. This is a frustrating thing with Windows installation software as the smallest change to your environment might make a de-installer fail. To help you out of this misery, we provide a script that de-installs the software in a batched way.

The following step will wipe your EWA installation and the services. It is very important to restart after the script has finished, to completely remove all the EWA  services.

Note:
Use this script own your own risk - this is not the official way to de-install the software. But it has proven to often run much better then the official way.

You can find the script on the delivery media:

[DVD-DRIVE]:\ewa\tools\CleanEWAInstallation.vbs

11 Update / Migration

Note:
Update and migration steps are only supported from the exact previous delivery version to the current one. If you have an older version, you might want to de-install it and install EWA from scratch using the most current delivery media.

Note:
EWA does not support a full recover option. You may want to make a full backup of your system before updating the software. A good harddrive partitioning tool or tape backup will help to get the server back working if something should go wrong during an update.

There are two aspects of updating the EWA system:

  1. Monthly updates (typically database content for WIS and EPC as well as updates of resources)
  2. Major updates of the system software

Typically you will not see a difference in the way how to perform those updates.

11.1 Regular updates

Typically once a month you will receive a new set of DVDs (or receive your media sets online via the ManageSoft online channel). Updating is a simple thing.

Note:
If you make use of a distributed server environment (having database server and application server on different physical machines), you will not perform integrated updates via AdminTool. Therefore in these environments you as administrator are responsible for keeping the system consistent.
On the application server, call setup.exe /u for a pure software update, then apply the manual changes as described.
On the database server(s), call setup.exe /u as well for updating the software, then make use of the advanced features of the AdminTool. Please refer to the AdminToolGuide.
Even though using this enhanced setup procedure it is possible to install a new database content without upgrading the software. Nevertheless it is highly recommended to ALWAYS update the software when updating the database content. The software setup will only upgrade components when they have changed but additionally will ensure that help files, what's new pages and translations are up to date.
In Summary: Please update the software also when updating the databases in your EWA installation.

Go to the favorites of your Internet Explorer and click on the buttons “Update WIS” to perform an update of WIS and then click onto the favorite “Update EPC” to perform an update of EPC. The system will be automatically updated and check any dependencies between WIS and EPC. There might be situations where you have to provide both DVD sets to allow an upgrade. If you cannot provide the valid media sets, you might not be able to upgrade. This is to ensure consistency of the system software.

For more information please refer to the corresponding EWA Admin Tool documentation.

Note:
If you performed an upgrade from a 1.2 version of EWA to the current version, a migration of the database internals will have to be performed based on some heuristics.
If you have set up only one workshop with several groups and users, the single workshop will be migrated and visible. If you have defined multiple workshops, a new Server Workshop will be created containing the administrator user. In this case other workshops and users are not visible anymore (but still existing!). In this case the "Cascaded Workshop Administration" needs to be enabled. This will allow you to use multiple workshops in your installation. Information on how to do this can be found here.
Anyway it is recommended you check the relationships of your user objects to groups and workshops after migration and manually correct it where the migration algorithm did not perform the steps you would have expected.

12 Additional software installation

12.1 Spooler

12.1.1 General

EWA provides basically the same spooler programs as provided as part of the former WIS. Those spoolers have slightly been modified to fit better into the EWA architecture.

Note:
This description is not a replacement for the spooler manuals. It just describes installation and basic ideas behind the spoolers in the special context of EWA.
For a reference of the spooler manuals including a description of the file formats please refer to the documentation's table of contents.

Note:
In order to run the spoolers successfully you need at least 2 GB free harddisk space on the disk where the WIS database service is running (!) as complex SQL queries on the database may need temporary space on the disk. Especially the creation of DamageCode rules files need a lot of temporary harddisk space.

In order to be able to create spool files the spooler programs (ASRA spooler and Damagecode spooler) will have to be installed manually from the delivery media of EWA onto the same machine where the EWA installation resides. The installation will be described in more detail in the following sections.

The basic mechanism to spool out data (either via ASRA spooler or Damagecode spooler) and to make it accessible for download in the download area is:

12.1.2 Configuration

12.1.2.1 Spool file location

The location for the spool out files can be changed by editing the core configuration file core_cfg.xml within the section "Spooler". By default a relative path is set for both ASRA and Damagecode spooler which is interpreted as relative to the EWA_HOME directory. Server administrators which intend to run the spoolers in batch mode and in a clustered environment may want to change this location to a distinct location which is accessible by all EWA cluster nodes.

Default (relative path)

<SECTION name="Spooler">
    <PARAMETER name="ASRASpoolout">downloads/spooler/asra</PARAMETER> 
    <PARAMETER name="DamageCodeSpoolout">downloads/spooler/damagecode</PARAMETER> 
</SECTION>

Example (absolute path)

<SECTION name="Spooler">
    <PARAMETER name="ASRASpoolout">N:/ewanet_spooler_results/asra</PARAMETER> 
    <PARAMETER name="DamageCodeSpoolout">N:/ewanet_spooler_results/asra/damagecode</PARAMETER> 
</SECTION>

Note:
It is important for you to know that if you switch your file locations to a network path (accessed via UNC path or via mapped drive letters) you will have to change the account under which your EWA server is running to a user account being allowed to access network resources. The "system" account in Windows is not allowed to do so.

12.1.2.2 Access rights for spool out files

By default EWA gains users with user role "System Administrator" or "Workshop Administrator" access to the download area for spooled files. You can change this behavior to a per-user-setting by changing the value "userBasedDownloadPermissisons" to "true" in the section "General" of the  UserManagement configuration file um_cfg.xml. Once done you must explicitly assign the user right "Allow download of spooler files" to any user who should gain access to this download area. Even the system administrator does not have this right by default!

12.1.3 Interactively running the spoolers

12.1.3.1 ASRA Spooler (AWAT data spooler)

This spooler allows the extraction of ASRA related data from the WIS database in the same way as it was possible with "classic" WIS. After startup of the application you will see the following screen:

The marked text field shows the automatically pre-selected output folder for your files. It is recommended to not change this folder in order to ensure that your spool out files will be written into a location where EWA can find them to allow downloads via the EWA download page.

Note:
Please ensure that you do not accidently override existing files. Please move those files into a backup location before spooling out the files.

After spooling out the data you may login into EWA from any client and display the download section (assuming you have the rights to access those pages).

You may download the files for the ASRA Spooler from the section named "ASRA Spooler Output". You may even browse the log file from here. The download page will list all the file that have been spooled out along with the configuration information that was used to create those files. Clicking on one of the hyperlinks in the browser will make the browser start the download of the appropriate file.

12.1.3.2 Damagecode Spooler (SSL data spooler)

This spooler allows the extraction of damage code related data from the WIS database in the same way as it was possible with "classic" WIS. After startup of the application you will see the following screen:

The marked text field shows the automatically pre-selected output folder for your files. It is recommended to not change the output folder in order to ensure that your spool out files will be written into a location where EWA can find them to allow downloads via the EWA download page.

Note:
Please ensure that you do not accidently override existing files. Please move those files into a backup location before spooling out the files.

After spooling out the data you may login into EWA from any client and display the download section (assuming you have the rights to access those pages).

You may download the files for the Damage Code Spooler from the section named "Damage Code Spooler Output". You may even browse the log files from here.

12.1.4 Scheduled process of spooling / Spooling multiple "packages"

If you want to make use of more advanced features like

you will want to make use of the option to run the spooler executables in "batch mode" which means that they do not show any user interface but get their configuration information from a separate ini-file which basically tells them what they have to do. Once you are sure that your created configuration files are valid and operating the way you expect them you can easily make this process part of the Windows Scheduler.

12.1.5 Additional Information

For additional information about using the ASRA and Damagecode Spoolers as well as detailed information about the spoolout files and structure please have a look at the different spooler documents in the documentation's table of contents.

13 Client software installation

13.1 Java Runtime Environment

Before users can start working with the EWA clients (EWANAPI installer, EPC , WIS ), you should ensure that the client systems are well prepared. If you have an officially supported  Java Runtime already installed on all the client machines, you are well prepared. Going to the Download Area of the User Management in your browser you will notice that the Web Application automatically tries to determine whether your clients are capable of executing EWA .

If you need to install a Java Runtime Environment, you can make use of the one provided in the downloads section. Simply click on "Download and Install" which will download the appropriate Java Installer.

Note:
After successful installation of a new Java Runtime Environment you may have to log off and on again to update the System check display as it cashes the settings per session to avoid nasty dialogs.

 

13.2 EWANAPI (External API to call EWA  clients for DMS calls and/or Xentry integration) (ewanapi.exe / wisapi.exe)

EWA provides an external application called EWANAPI.exe which allows external programs to communicate with the AccessGateway, the WIS  client  and/or the EPC  client.

This application was implemented with downwards compatibility in mind. Its command line arguments are compatible with the “classic” WISAPI.exe from the former WIS environment. It has been extended to support authentication at the AccessGateway and Shoppinglist calls to EPC .

Note:
To indicate the downwards compatibility there is still a “clone” of the EWANAPI.exe called WISAPI.exe around that can be used in the same way as EWANAPI.exe

Note:
EWANAPI has matured from a simple DMS integration layer to an API which is heavily used by the Xentry applications like Xentry TIPS or Xentry Diagnostics. Therefore it is recommended to have EWANAPI installed in always the most current version on the client PCs. A so called "automatic deployment" supports to keep the clients up to date. Read more about this feature here.

13.2.1 Automatic Installation via the integrated EWANAPI Installer

EWA provides a Java based installer which performs the necessary steps on each of the clients computers that otherwise would have to be executed manually.

The EWANAPI installer can easily be accessed from the Download section of EWA . Simply click on the Download and Installation button. You can also do this anytime you want to update your EWANAPI environment.

Note:
This step can only be performed once a correct version of Java has been installed on the client. If no Java has yet been installed, just install it via the appropriate Download and Installation button just above the "EWANAPI/WISAPI" installer link.

13.2.1.1 Server side preparation (System administrators tasks):

The installer will always fetch the most recent EWANAPI installation files from the server installation directory [EWA-HOME]\clientapps\EWANAPI. The following files will be transferred to the clients by the installer:

The executables, the JAR and the DLL will be copied to the client during installation also (Note: ewanapi.exe will also be installed as wis.exe during installation on the client for WIS Classic backwards compatibility).

13.2.1.1.1 Rules for reading the specific server settings to be applied on clients

The installer and the autodeployment engine will check the directory for an appropriate ewanapi.ini file to read their settings from in the following order:

  1. Check for an ewanapi.ini.<workshop_number>.
    The idea behind it is to allow a per workshop default setting which allows especially hosters of large central environments a high level of flexibility.
    Imagine a workshop still using Autoline 8.2. Let's assume this workshop has the workshop number "XG307". In this case you could copy the ewanapi.ini file with the name ewanapi.ini.XG307. Starting the installer from the download page will fetch the current users workshop information and try to read the workshop specific ewanapi.ini file and run the installation with settings provided there.
  2. If such a file cannot be found the installer tries to read the file ewanapi.ini.installer.
  3. If all those files could not be found the installer will fall back to the standard ewanapi.ini file and read its information for the installation from there.

Note:
The installer will take care about all these files and will migrate your existing settings during a software update on the server side.

The steps that now will be performed by the installer are

Note:
The user running the installer must have sufficient user rights to install files into the chosen directory. Depending on the policies of your local Operating System he may not even be allowed to install files or create directories within "C:\Program Files\EWANAPI". In this case a different directory must be chosen or the user may have to ask the local system administration.

Now for the tasks that you as system administrator will want to perform to influence the installation on the client side in the best way. The central point is the ewanapi.ini file. It contains a high level of flexibility to influence the client installation.

13.2.1.1.2 Automatic property replacement within ewanapi.ini

The following table documents that placeholders you can make use of if you like some properties to be filled automatically according to the runtime settings.

PlaceholderReplaced during installation with
%EWA_HOST%

used for Server= property and for FallbackServer= property
Name of the EWA server the client will connect to.
This must be the same name as the one you use when connecting to EWA via the browser.
If you run your EWA with a front end web server this will be the name of the Web server, it does not have to be the one of the EWA application server which might not be reachable directly in this scenario.
%EWA_PORT%

used for Port= property and for FallbackPort= property
Number of the EWA TCP/IP port on which to connect to the EWA server.
This must be the same port as the one you use when connecting to EWA via the browser.
If you run your EWA with a front end web server this will be the port of the Web server, it does not have to be the one of the EWA application server which might not be reachable directly in this scenario.
%EWA_SECURE%  

used for Secure-HTTP= property and for FallbackSecure-HTTP= property
Indicates with "true" or "false" whether HTTPS shall be used
%EWA_WEBSTART%

used for WebStart= property
Will be replaced by the absolute path of the active Java WebStart installation on the client machine.

This allows high flexibility for the System Administrator. To allow the installer to derive the correct runtime settings from the server and automatically apply it to the EWANAPI installation on each of the clients, the pre-installed configuration file ewanapi.ini may directly be used.
But these values might also be overridden by static values.

Example:
If you specify:
Server=my.ewanet.com
the installer will leave this untouched.

But specifying
Server=%EWA_HOST%
indicates the installer it should replace this pattern by the server name that was used when accessing EWA  via the browser.

Hint:
The administrator might even decide to let EWANAPI determine the WebStart Installation automatically during runtime. In this case the complete line
WebStart=....
can be omitted or simply commented (default now in the delivered ini-file).

13.2.1.1.3 Influence target installation directory on the client PC

By default the preconfigured ewanapi.ini file will make the client installer install the EWANAPI files into %ProgramFiles%\EWANAPI. This behavior is controlled by the property:

[Installer]
InstallDir=%ProgramFiles%\EWANAPI
 

If you know of policies that inhibit the normal users in your environment to install in this directory because of insufficient rights do not let them run into trouble. Of course they can select a new path in the client anyway, but be so kind and change the default location already to a path where they will be allowed to install in. A fallback that should always work is:

[Installer]
InstallDir=%USERPROFILE%
 

13.2.1.1.4 Prefer SSO authentication before provided credentials

[General]
SSOPreferred=true


For environments that make use of NTLM Authentication within EWA it might be very helpful to enforce EWANAPI to try NTLM authentication first before making use of any credentials provided to EWANAPI. Thus the authentication consists of a maximum of 2 steps:

1) Try to authenticate via NTLM. If this does not succeed, perform step 2

2) Try to authenticate via credentials provided.

Note:
This setting might be useful especially within EWA  environments where the EWA  user database is not yet synchronized with the Dealer Directory of Daimler.
A good example is a call from TIPS to EWA  where TIPS expects a user to be setup in the local EWA  system. But if the userid does not exist (is not synchronized) within the local EWA  server, the call will fail.
If the local EWANAPI.ini contains the flag "SSOPreferred=true" and the EWA  server is configured for NTLM authentication then the applet tries to first authenticate via NTLM. TIPS in this case can make the call with  userid which is currently known to the underlying Windows system and the local EWA  server.

13.2.1.1.5 Address Proxy settings / problems

Proxy settings will be handled automatically by WebStart in the same way like for all the EWA clients. If the EWA clients like WIS or EPC or even the EWANAPI Installer itself work fine in a given environment, EWANAPI will do so as well using exactly the same mechanisms in WebStart.

Note:
The proxy properties have gone from the EWANAPI.ini file. Adding them will not harm, but the information will not be used anymore by EWANAPI.

13.2.1.1.6 Preparation for Autoline 8.30 / 8.35 integration

Version of Autoline 8.3 and above provide an out of the box support of EPC respectively WIS/ASRA via EWANAPI. The tradeoff is that it currently expects some files to be located in the user profile directory. If those files are not present Autoline 8.3 will not enable the EPC or WIS/ASRA buttons. The best way to install EWANAPI on user's PCs is by use of the following settings - which have to be set on the EWA server inside the file [EWA-HOME]\clientapps\ewanapi\ewanapi.ini:

[Installer]
InstallDir=%USERPROFILE%
Autoline_82_Enabled=false
Autoline_82_Allowed=false
Autoline_82_WISServer=
Autoline_82_EPCServer=
 

Note:
Modify the EWANAPI file on the server before you start installing EWANAPI on the clients! If you published EWANAPI to a client already before applying those changes on the server side, go ahead and deinstall EWANAPI on that client(s) and then install again after applying the changes on the server.

13.2.1.1.7 Preparation for Autoline 8.2 Emulation layer

For an Autoline 8.2 related installation the section for the Autoline 8.2 emulation layer must look like this - otherwise the user will not see the option for installation of the Autoline 8.2 emulation:

[Installer]
InstallDir=%ProgramFiles%\EWANAPI
Autoline_82_Enabled=true
Autoline_82_Allowed=true
Autoline_82_WISServer=
Autoline_82_EPCServer=
 

Note:
In order to make user specific changes, like using customer files or registry settings, the one installing EWANAPI for an Autoline 8.2 integration must have administrative rights.

Note:
Once EWANAPI with enabled Autoline 8.2 support is installed, then any classic applications like WIS Classic and EPC FP will not work in an integrated way anymore. Leave the server side of these applications installed, but do not make use of the clients anymore. A mixed environment is not supported and may lead to confusing situations..

Explanation:

13.2.1.1.8 Preparation for fallback server option

EWANAPI supports a flexible fallback setting within the EWANAPI.ini and EWANAPI Cookie files. The following properties indicate which alternative EWA server to contact under distinct error codes on the default server.

Attribute NameSettingBehavior
FallbackServerNoneUnder distinct error situations try to contact an alternative server with the name/IP given here.
Fallback settings will only be used by EWANAPI if a fallback server has been configured.
FallbackPortNoneThe port of the fallback server to be contacted.
FallbackSecure-HTTPNoneIndicate with true or false whether the connection while authenticating shall be HTTPS or not.
FallbackErrorCodesNoneIf no values given, HTTP code 500 from the default server will force EWANAPI to contact an alternative server. You may specifiy another list of HTTP error codes here like:
500,501,502,503,504,404
13.2.1.1.9 Preparation for Siteminder integration option

Server administrators of environments running their EWA application server behind a Siteminder secured infrastructure should review their settings whether they make use of the standard Siteminder Cookie name which is "SMSESSION". If not, they should set it to the corresponding value of their environment to help external accessors to set the cookie with the correct name.

Attribute NameSettingBehavior
SiteminderCookieNameNoneName of the Siteminder Cookie used inside the given infrastructure. If none was given, the default of "SMSESSION" will be used.
13.2.1.1.10 Other settings
Attribute NameSettingBehavior
Timeout60Maximum seconds to wait until application has to respond on the channel.
Extended_ParametersNoneHidden standard parameters in the ini file. Are added to the argument list
StandaloneNoneFor STAR DIAGNOSIS and STANDALONE environments set this to "true", otherwise false

13.2.2 Automatic Deployment of EWANAPI

EWA  supports a feature called "AutoDeployment". This feature has been introduced with early Xentry releases as Xentry highly relies on EWANAPI as an integration layer.

The idea of automatic deployment is, that an EWA user will not have to take care about a renewal of an EWANAPI release on his client. In former times of EWA , deployment was implemented via a kind of a pull-mechanism, i.e. the user had to check for a new release on the server by himself. By use of automatic deployment, this can be switched now to a push-mechanism, i.e. the user will automatically be notified in case of a new release on the server.

The check of a new release is triggered during the start of the EWA clients (WIS  or EPC ): after startup, the application will query the current version of EWANAPI on the server. Based on the check of the "Version" field a more recent file on the server can be detected. In such a case the user will be notified. He than can decide to directly install the new EWANAPI or to delay the installation.

Automatic deployment can be controlled by the following attributes as part of the [Installer] section within the  ewanapi.ini file(s) on the server - and as mentioned above it can be controlled server or workshop specific by using specific EWANAPI.ini files on the server to control the behaviour:

 

Attribute NameSettingBehavior
AutodeploymentNoneAutodeployment will be de-activated, i.e. no notification is given to the user and no automatic installation will be performed.
In order to update an EWANAPI on the client the user must still go into the download area and start the EWANAPI installer on his own.

Note:
In Citrix or Terminal Server environments, where the "client" side is also controlled by the server administrator, this feature is turned off. The server administrator is responsible to publish new EWA versions each time a software update has been performed and should also install EWANAPI on the respective client machines.

The version can visually be compared by checking the Version field in the EWANAPI.ini file on the client against the one on the server inside [EWA_HOME]\clientapps\ewanapi.

Especially on environments where EWANAPI is starting up the clients it is highly recommended to switch automatic deployment off as in this case files that need upgrade might be locked. This can lead to confusion on the user's side.

CheckUpdateAutodeployment will be activated. A notification is given to the user, but only if EWANAPI is already installed on the client and this is older than the one on the server.
If no EWANAPI could be found on the client system, no notification is given at all.
CheckInstallAndUpdateAutodeployment will be activated. As an addition to the setting "CheckUpdate" a notification will also be given if the client does not yet have an EWANAPI installation. If a missing EWANAPI has been detected the user will be asked to install it now.
 ForceUpdateAutodeployment will be activated in a more enforced mode. Much like "CheckUpdate" a starting EWA client will check the presence of am EWANAPI installation on the client. If present and the installed version on the client is older than the one on the EWA server, the server will enforce the update. Some information dialogs still appear, but the user will not be able to interrupt the installation until it has completed.
 ForceInstallAndUpdateAutodeployment will be activated in a more enforced mode. Much like "CheckInstallAndUpdate" a starting EWA client will check the presence of am EWANAPI installation on the client. If present and the installed version on the client is older than the one on the EWA server or no EWANAPI installation is present at all, the server will enforce the update. Some information dialogs still appear, but the user will not be able to interrupt the installation until it has completed.
TraceServerChangestrueIt will be checked, if the current EWA  server (as indicated by the URL in the browser) matches the EWA  server configuration in the currently installed EWANAPI.ini file on the client PC. If the servers do not match, the user will get a warning-message to avoid that server settings will be overridden accidently. This warning will also appear in case of enforced updates - which allows the user to abort the enforced update in this case.
Server matching is done by checking server names. If the name check will fail, the IP-addresses will be compared as a fallback.
falseNo checking will be done.
LeaveCookietrueIf set to true, the EWA clients (EPC and WIS ) will leave some information (named the EWANAPI "Cookie") within the user's home directory. This information can be helpful when i.e Xentry clients want to connect to a local EWA server and cannot find an EWANAPI installation on the client.

As mentioned above for the reading rules of EWANAPI.ini this setting can be controlled on a server level, but also on a workshop level - as for all the settings inside EWANAPI.ini

The information to be stored within the Cookie will be retrieved in the same way as the how the EWANAPI installer writes the EWANAPI.ini file into a client installation during full installation of EWANAPI, i.e. "Server", "Port" and "Secure-HTTP" will be derived from the EWA settings (if the Placeholders are being used within the corrsponding EWANAPI.ini file on the server) or by using the fixed values written into the corresponding EWANAPI.ini file on the server.

 falseNo information will be written at all during startup of the clients. An existing EWANAPI "Cookie" of the current user will be removed once an EWA  client starts up.
TimeoutStillLockedinteger number of secondsThe number of seconds after which a timeout will occur if the files which need to be overwritten during the install process are still locked.
Background info: Mostly in cases of DMS integration with EWA  it might happen that EWANAPI.exe will be used to start up an EWA client. If this happens and the starting EWA  clients detects that EWANAPI.exe must be updated, it cannot do this as EWANAPI.exe is currently running. Therefore the update can be delayed up to this number of seconds where a background process tries to replace EWANAPI. After this time without success of replacing EWANAPI.exe the updater will fail with an error message.

In addition to these attributes, the following principles will additionally control automatic deployment:

The following diagram shows the complete control of the automatic deployment:
 

Autodeployment Control

13.2.3 Manual Installation

On the delivery media you will find the WISAPI/EWANAPI program along with the required components in the folder:

[DVD-DRIVE]:\ewa\Apps\ewanapi\application

You can also find it after installation within the server installation directory

[EWA_HOME]:\clientapps\ewanapi

If you want to use these components, installation is fairly simple:

If you enter “ewanapi.exe” or “wisapi.exe” in a Console window now, you should see a usage information listing all parameter sets that are known to ewanapi.exe.

13.2.4 Configuration

Configuration has to be performed in the ewanapi.ini file. Adjust the values inside this file according to your needs.

13.2.5 Proxy Server Configuration for EWANAPI

Proxy settings will be handled automatically by WebStart in the same way like for all the EWA  clients. If the EWA  clients like WIS  or EPC  or even the EWANAPI Installer itself work fine in a given environment, EWANAPI will do so as well using exactly the same mechanisms of Java WebStart.

Note:
The proxy properties that were part of the early configuration files of EWANAPI have gone from the EWANAPI.ini file. Adding them will not harm, but the information will not be used anymore by EWANAPI.

13.2.6 Example of an ewanapi.ini file

Following dump shows a sample ewanapi.ini file. Highlighted properties may be changed already on the server side's ini-file to preset valid values for the clients or may be set on the client side later on:

[HTTP-Config]
##################################
# ATTENTION!!!
##################################
# Some parameters are being set to
# %EWA_xxx%
# These will be replaced by the automatic installer for EWANAPI
# If you want to make those values explicit or do not distribute EWANAPI via the installer,
# please adjust the values on your own before distributing EWANAPI.
# EWANAPI will not work if it is being installed with those values during runtime.
##################################
#
#
# Name of the Server where the AccessGateway is installed
Server=%EWA_HOST%
# Server=localhost  
#   if you want to state a server explicitly for all clients in advance
#
# Port on which the application is listening
# Typically this is 9000 for a normal HTTP connection, 8443 for a HTTPS connection
Port=%EWA_PORT%
# Port=9000         
#   if you want to specify a port explicitly for all clients in advance
#
# Will you use HTTPS for a secure connection?
Secure-HTTP=%EWA_SECURE%
# Secure-HTTP=false
#

[Files]
# Where to store data files
# For future use maybe, not yet supported
WIS-Net_DATA=%HOMEDRIVE%%HOMEPATH%\data_wis.txt
WIS-Net_ERROR=%HOMEDRIVE%%HOMEPATH%\error_wis.txt
EPC-Net_DATA=%HOMEDRIVE%%HOMEPATH%\data_epc.txt
EPC-Net_ERROR=%HOMEDRIVE%%HOMEPATH%\error_epc.txt

[General]
Version=1.5.2.0
# Maximum seconds to wait until application has to respond on the channel
Timeout=60
# For STAR DIAGNOSIS and STANDALONE environments set this to "true"
Standalone=false
# Let the system find the file on its own
#WebStart=%EWA_WEBSTART%
# WebStart=%ProgramFiles%\Java\j2re1.4.2_05\javaws\javaws.exe
Extended_Parameters=
#WIS-Net_StarterApplication=%ProgramFiles%\Citrix\ICA Client\wfcrun32.exe "%ProgramFiles%\EWACTXCL\CTX-WIS.ica"
#EPC-Net_StarterApplication=%ProgramFiles%\Citrix\ICA Client\wfcrun32.exe "%ProgramFiles%\EWACTXCL\CTX-EPC.ica"
SSOPreferred=false

[Standalone]
WIS-Net_EXE=%WISNETEXE%
# Not yet supported as there is not yet a standalone EPC 
EPC-Net_EXE=%EPCNETEXE%

[Installer]
# For Autoline 8.3x support choose
# InstallDir=%USERPROFILE%
InstallDir=%ProgramFiles%\EWANAPI
Autoline_82_Enabled=false
Autoline_82_Allowed=false
Autoline_82_WISServer=
Autoline_82_EPCServer=
# How do we want to control the automatic publication of EWA  clients?
# Valid values are:
# None: No check will ever be performed by this client
# CheckUpdate: Checks for new versions will only be performed if there is already an EWANAPI locally installed on that client
# CheckInstallAndUpdate: Suggest updates and even new installations if there is not yet an EWANAPI locally installed on that client
# ForceUpdate: Enforce new versions will only be performed if there is already an EWANAPI locally installed on that client
# ForceInstallAndUpdate: Enforce updates and even new installations if there is not yet an EWANAPI locally installed on that client
Autodeployment=CheckInstallAndUpdate
# Do we want to trace whether we accidently moved to another EWA  server?
# true: it will be monitored whether the current connection contacts the same server as the one registered inside EWANAPI
# false: there is no monitoring active at all
TraceServerChanges=true
# Do we want to leave an EWANAPI cookie on the client ?
# true: the client will leave the information about: EWA  Server, HTTP-Port and HTTP(S) inside a small ".ewanapi_cookie" file in the user's home directory
# false: no cookie will be left. Existing cookie will be removed for the current user.
LeaveCookie=true
# The number of seconds after which a timeout will occur if the files which need to be overwritten during the install process are still locked.
TimeoutStillLocked=120



14 References

This section lists further documentation. No parts of the following documents were repeated here to ensure consistency within the information provided.

14.0.1 Admin Tool Guide

Filename: [DVD-DRIVE]:\ewa\doc\AdminToolGuide.htm
Authors: Manuel Gutjahr, Martin Tolksdorf (HP)

14.0.2 User Administration document

Filename: [DVD-DRIVE]:\ewa\doc\HP-UM_UserGuide.htm
Authors: Manuel Gutjahr, Martin Tolksdorf (HP)

14.0.3 EWANAPI description document

Filename: [DVD-DRIVE]:\ewa\doc\EWANAPI_Description.htm
Authors: Manuel Gutjahr, Martin Tolksdorf (HP)

14.0.4 WIS Release Notes

Part of the global ReleaseNotes: [DVD-DRIVE]:\ewa\doc\ReleaseNotes.htm
Authors: Martin Woschko(devoteam)

14.0.5 EPC Release Notes

Part of the global ReleaseNotes: [DVD-DRIVE]:\ewa\doc\ReleaseNotes.htm
Authors: Rainer Englisch (SBS)