server installation manual, version 2014 r2 for ibm...

MANUAL SERVER INSTALLATION MANUAL VERSION 2014 R2 FOR IBM WEBSPHERE

Table of Contents

I

Table of Contents

1 GENERAL INFORMATION ................................................................................. 1

1.1 Document history ...................................................................................................... 1

1.2 Introduction ............................................................................................................... 1

1.2.1 Objective ......................................................................................................... 1 1.2.2 Target audience ............................................................................................... 2 1.2.3 Prerequisites ................................................................................................... 2 1.2.4 Contact ............................................................................................................ 2 1.2.5 Structure .......................................................................................................... 2 1.2.6 Conventions .................................................................................................... 3 1.2.7 Your feedback is highly welcome ..................................................................... 4

1.3 Application description .............................................................................................. 4

1.4 System overview and deployment scenarios ............................................................ 4

2 SYSTEM REQUIREMENTS ................................................................................ 6

2.1 Hardware and Software requirements ....................................................................... 6

3 PREPARATIONS .............................................................................................. 7

3.1 License ..................................................................................................................... 7

3.2 Database .................................................................................................................. 7

3.2.1 JDBC driver ..................................................................................................... 7 3.2.2 Microsoft SQL Server 2005 and 2008 .............................................................. 8 3.2.3 Oracle 9i, 10g and 11g .................................................................................... 8

3.3 File system ............................................................................................................... 9

3.4 Application server ..................................................................................................... 9

3.5 Solr installation ....................................................................................................... 10

4 INSTALLATION STEP-BY-STEP ........................................................................ 11

4.1 Checklist ................................................................................................................. 11

4.2 Installation environment .......................................................................................... 11

4.2.1 Setup installation environment ....................................................................... 12 4.2.2 Configure TTS Server with application-config.properties ............................... 12

4.3 Data source ............................................................................................................ 16

4.3.1 Creating a data source with the IBM WebSphere 7.0 Console ....................... 16

4.4 Application server settings ...................................................................................... 33

4.4.1 JVM-settings .................................................................................................. 33 4.4.2 URL-encoding................................................................................................ 33

4.5 Deployment ............................................................................................................ 33

4.5.1 Deployment ................................................................................................... 34 4.5.2 Classloader hierarchy .................................................................................... 40 4.5.3 Assigning the reference to the application-config.properties file ..................... 45 4.5.4 Setting the prefix and suffix of Session Id ...................................................... 47

4.6 Deployment of the Solr core ................................................................................... 48

4.7 Post installation steps ............................................................................................. 48

Table of Contents

II

4.7.1 Initialization of the database schema ............................................................. 48 4.7.2 First login as administrator ............................................................................. 50 4.7.3 Next steps ..................................................................................................... 53

4.8 Securing Solr .......................................................................................................... 54

4.8.1 Securing Solr via Basic Authentication .......................................................... 54 4.8.2 Configure users and groups........................................................................... 55 4.8.3 Activate application security ........................................................................... 59 4.8.4 Test security .................................................................................................. 64

4.9 Troubleshooting ...................................................................................................... 65

4.9.1 The server does not start up .......................................................................... 66 4.9.2 Database is unavailable ................................................................................. 66 4.9.3 Login fails ...................................................................................................... 67

4.10 Websphere-specific LDAP settings ......................................................................... 67

4.11 Solr installation example (single Solr instance) ....................................................... 67

4.11.1 Configure Solr home ...................................................................................... 68 4.11.2 Deploy Solr .................................................................................................... 72 4.11.3 Testing Solr ................................................................................................... 77

5 MIGRATING FROM PREVIOUS VERSIONS ......................................................... 79

5.1 General remarks ..................................................................................................... 79

5.2 Updating from version 7.1 to 2012 .......................................................................... 79

5.3 Updating from version 2012 to 2012 R2 .................................................................. 79

5.4 Updating from version 2012 R2 to 2013 .................................................................. 80


5.6 Updating from version 2013 R2 to 2014 .................................................................. 83

5.6.1 Solr Search Engine ........................................................................................ 83 5.6.2 New mandatory application properties ........................................................... 83 5.6.3 New optional application properties ............................................................... 84


5.7.1 Scheduler Service on Websphere .................................................................. 87

6 APPENDIX .................................................................................................... 89

6.1 Properties service ................................................................................................... 89

6.2 Data service ............................................................................................................ 94

6.2.1 JNDI data source ........................................................................................... 94

6.3 Store service ........................................................................................................... 96

6.4 User service for authentication and authorization ................................................... 97

6.4.1 Login modules ............................................................................................... 97 6.4.2 LDAP authentication ...................................................................................... 98 6.4.3 Single-Sign-On (SSO) ................................................................................. 103

6.5 Logging service .................................................................................................... 109

6.6 Version control and Workflow service ................................................................... 111

6.6.1 Version control ............................................................................................. 111 6.6.2 Workflow service ......................................................................................... 112

6.7 Cache service ....................................................................................................... 113

Table of Contents

III

6.8 Repository service ................................................................................................ 115

6.9 Notification service ................................................................................................ 115

6.10 Language service ................................................................................................. 117

6.11 Template service .................................................................................................. 118

6.12 Scheduler service ................................................................................................. 119

6.13 Configuration service ............................................................................................ 120

6.14 Feature service ..................................................................................................... 121

6.15 Miscellaneous parameters .................................................................................... 121

6.16 Search service ...................................................................................................... 122

6.16.1 Solr Search Service ..................................................................................... 122 6.16.2 Searching parameter ................................................................................... 123 6.16.3 Highlighting parameter ................................................................................. 124

Server Installation Manual, Version 2014 R2 for IBM Websphere

1

1 General Information

1.1 Document history

Date Author Version Changes

02.07.2009 Maurice Gottschalk 0.1 Created

17.08.2009 Maurice Gottschalk 0.2 Ready for quality assurance

22.10.2009 Ulfert Köppen 0.3 Text QA

22.02.2010 Maurice Gottschalk 0.4 Optimizing the guide

28.05.2010 André Wolf 0.5 Technical QA

03.06.2010 Ulfert Köppen 1.0 Final proofreading

13.05.2011 Maurice Gottschalk 1.1 Updated guide to version 7.0


31.5.2011 Ulfert Köppen 2.0 Proofreading and QA done

09.09.2011 Maurice Gottschalk 2.1 Updated guide to version 7.1

13.02.2012 Maurice Gottschalk 2.2 Restructured and updated the guide for TTKF 2012


04.04.2012 Ulfert Köppen 3.0 Proofreading & QA done

06.09.2012 Maurice Gottschalk 3.1 Updated guide to version 2012 R2


10.09.2012 Ulfert Köppen 3.3 QA done

22.02.2013 Maurice Gottschalk 4.0

02.04.2013 Ulfert Köppen 4.1 QA done

02.11.2013 Ulfert Köppen 5.0 Updated to version 2013 R2

06.06.2014 Maurice Gottschalk 5.1 Updated guide to version 2014

1.2 Introduction

1.2.1 Objective

This document describes the requirements of the TTS Server components, named Work-

bench and Web Publisher, and their installation process.

The goal of this document is to provide an understanding of the server configuration and to

guarantee its successful installation.


2

1.2.2 Target audience

System administrators, developers and all interested parties

1.2.3 Prerequisites

It is expected that system administrators, developers and who else may be interested have

profound knowledge of

› Windows and/or Unix-based operating systems

› Administration and handling of database management systems (Microsoft SQL Server / Oracle)

› Administration and handling of application servers (Oracle Weblogic, IBM Websphere, Apache Tomcat)

› deployment of web applications (WAR,EAR, external web application)

› SQL

› HTML

› XML

Please read this installation guide completely and carefully!

1.2.4 Contact

› TTS Support

Phone: +49 (0) 2 21 / 17 09 30 -110

Fax: +49 (0) 2 21 / 17 09 30 - 170

[email protected]

› Application consultant

Application consultants, very skilled and experienced in TTS Server, guide you through the installation process and provide professional solutions matching your requirements. If no application consultant has been assigned yet, please contact your key account manager.

1.2.5 Structure

The first chapter sheds light on the functionalities and technologies used in TTS Server com-

ponents. The pictures is completed by presenting the System overview and deployments

scenarios.

The next section points to the System requirements concerning hardware and software.

They should be checked thoroughly and carefully.

The Preparations chapter contains information on the prerequisites to get the TTS Server

running.

The Installation chapter guides you step-by-step through the deployment of the TTS Server

components, including all necessary actions like creating database connections or defining

server configuration. Post installation steps deals with initial administration tasks. This

mailto:[email protected]


3

chapter closes with a Troubleshooting section, which provides solutions for common prob-

lems.

Due to the fact that the TTS Server is a highly complex application, many configuration op-

tions are provided. All sorts of settings are explained in detail in the Appendix. Each proper-

ty or parameter of the application's services is listed with its name, a description, and the

possible values.

1.2.6 Conventions

1.2.6.1 Symbols

To highlight important information on the one hand, and "nice to know" details on the other,

the following icons are used:

Attention

Hint or note

Tip

Path

1.2.6.2 Abbreviations

TTPS - TT Performance Suite

TTKF - TT Knowledge Force

TTG - TT Guide

DB - Database

EAR - Enterprise Application Archive

JNDI - Java Naming and Directory Interface

LDAP - Lightweight Directory Access Protocol

SOLR - Solr Search Engine

SSO - Single-Sign-On

WAR - Web Archive

1.2.6.3 Variables

Variables are marked with leading $:

$TTPS_HOME - installation directory of TTS Server

$SOLR_HOME - directory of the search index created by Solr and the Solr configuration

$TOMCAT_HOME - installation directory of Apache Tomcat

$WEBSPHERE_HOME - installation directory of IBM WebSphere

$WEBLOGIC_HOME - installation directory of Oracle Weblogic


4

1.2.7 Your feedback is highly welcome

TTS welcomes your feedback concerning the quality and usefulness of this manual. Your

comments and suggestions will be considered as valuable input for future revisions of this

manual.

› You found an error? Please let us know where.

› A topic is not described clearly enough? Please let us know which one.

› You request more information? On which topic?

› The examples do not work for you? Please let us know so we can provide additional examples.

Please feel free to send us your feedback: [email protected]. We appreciate your help!

1.3 Application description

The TTS Server consists of two components: the Workbench and the Web Publisher. Rep-

resenting a production and delivery platform, the Workbench provides author functionalities,

whereas the Web Publisher makes the contents accessible to the end users.

The server components have been developed in a platform-independent way, using technol-

ogies like Java, Eclipse, HTML, JavaScript, CSS, XML, and XSLT (to create platform-

independent document types like RTF or PDF). There are only few components that are plat-

form-dependent, like the 'recorder' software or the 'QuickAccess for Desktop Applications'

online-help-system - due to the technology used in them.

The TTS Server is based on the following technologies:

› Java SE 6

› Java EE 1.5

› Servlets 2.5 / JSP 2.1

› JavaScript

As a result of the server component's architecture, it takes but little effort to integrate the TTS

Server in existing environments, depending on the infrastructure.

Furthermore, there is no need to install ActiveX controls.

1.4 System overview and deployment scenarios

This chapter offers a short outline of the TTS Server system environment in two different de-

ployment scenarios.

The first scenario (figure 1.1), which is the minimum way in practice, involves one application

server hosting both Workbench and Web Publisher, along with the Solr web application. The

backend provides a database, file system (as repository), and an optional LDAP directory for

authentication and authorization purposes. End users access the application via HTTP(S).

For performance and security reasons, we strongly recommend a deployment scenario using

a reverse proxy.

mailto:[email protected]


5

Figure 1.1

The second scenario (figure 1.2) differs from the first one by being more scalable and dy-

namic, thanks to using three application servers plus a load balancer that distributes all re-

quests among the reverse proxies. One application server hosts the Workbench and one

(Preview-) Web Publisher. The other server(s) run(s) the main Web Publisher. The third one

provides with Solr web application the search engine.

Figure 1.2

Both scenarios, minimum and recommended, are field-tested concepts. The usage depends

on the customer's requirements. Nevertheless, we recommend the deployment including a

reverse proxy in any case. Moreover, if there is a huge number of end users expected, an

installation in a clustered environment is advised, since this scenario offers more flexibility,

better scalability, and higher performance.


6

2 System requirements

2.1 Hardware and Software requirements

For the current hardware and software requirements of TTS server, please refer to the

System requirements located in the TTS Community:

http://tts.invisionzone.com/index.php?/files/category/17-system-requirements/

http://tts.invisionzone.com/index.php?/files/category/10-manuals/


7

3 Preparations

3.1 License

Before you start the installation process, a valid license for the TTS Server is required.

Please request the license file via your professional service consultant or TTS Support

([email protected]). Please provide the MAC addresses as well as the IP addresses of the

servers on which the components are going to be installed.

Both components, TTS Server Workbench and Web Publisher, need their own

license file. If you plan to install the applications on separate machines, the MAC

and IP address of each server has to be provided.

3.2 Database

To store data persistently, the TTS Server components require a relational database. There-

fore, a new database must be created in your database management system (DBMS).

A database user is needed to access the database. The user must be granted some permis-

sions for the database, which will be explained later, as well as permissions for Microsoft

SQL Server and for Oracle.

With regard to the server configuration, the following pieces of information are required:

› Host name or IP address of the database server

› TCP port of the database service

› Name of the database

› Names and passwords of the database users

UTF-8 should be used as character set to store data in the database. If the data-

base is used primarily for languages with a Unicode range higher than U+0800

(see www.unicode.org/charts for more information), a UTF-16 character set should

be used.

3.2.1 JDBC driver

Currently, the following JDBC drivers, as provided by the database vendors, are supported:

› Microsoft SQL Server JDBC Driver: sqljdbc.jar (version 3.0)

› Oracle JDBC Driver: ojdbc14.jar (version 10.1.0.5 or 10.2.0.4)

Especially for Oracle, we recommend using a driver that matches the database version, but

at least the supported versions described above.

If the server is deployed to Oracle WebLogic or IBM WebSphere, the embedded JDBC driv-

ers provided by these application servers should be used. These drivers usually feature ex-

cellent integration into the configuration and monitoring components of the application server.

mailto:[email protected]://www.unicode.org/charts


8

The JDBC drivers for Microsoft SQL Server and Oracle are not distributed with

TTS Server. You can download an adequate driver from the Microsoft or Oracle

websites.

3.2.2 Microsoft SQL Server 2005 and 2008

The database user must have the permission to connect to the newly created database. This

is usually done during user creation by setting the standard database. If not, access to the

database has to be granted separately via the user properties.

The database user should be granted dbo rights, since he needs to create, alter and

delete tables, procedures, functions, indices and so on.

Be aware that the port of the database might be set dynamically for a named instance.

It may therefore deviate from the default value 1433.

3.2.3 Oracle 9i, 10g and 11g

In Oracle, a tablespace must be created at first. The related data file should have a size of at

least 50 MB. To automatically assign more disk space, the "AUTOEXTEND" option must be

activated. Otherwise, the database cannot store additional data once the space limit is

reached.

The database user must be granted the following permissions:

› SYSTEM PERMISSION: ROLE: CONNECT

› SYSTEM PERMISSION: CREATE SESSION

› SYSTEM PERMISSION: CREATE TABLE

› SYSTEM PERMISSION: CREATE SEQUENCE

› SYSTEM PERMISSION: CREATE PROCEDURE

Furthermore, you need to grant the database user unlimited quota to the created tablespace.

On request, TTS Support can provide you with SQL scripts that can be used to gener-

ate the required tablespace and user and to set the specific rights for the user.


9

3.3 File system

The following directories are required for the TTS server components. One for the repository

to save the document and guide contents. The other one is used as a data store for runtime

files. The user of the application server needs complete access to those directories, to read,

write, execute, and delete files.

Sample file system structure

$TTPS_HOME/repository/repository_1

$TTPS_HOME/repository/repository_2

$TTPS_HOME/repository/repository_n

$TTPS_HOME/repository/guide

$TTPS_HOME/store

Please refer to the hardware requirements section for information on the hard disk

space that is required for both the repository and the data store.

Please make sure the created directories are accessible to all installed instances

of the TTS server. This also holds true if the instances are running on different

machines.

3.4 Application server

The application server must be a Java application server supporting JavaServlet 2.5, Ja-

vaServer Pages 2.1, and Java EE 5. All the servers with their supported versions mentioned

in the system requirements, namely Apache Tomcat, IBM WebSphere, and Oracle Web-

Logic, meet these requirements.

In this guide, we assume that the application server on which the TTS Server will be running

has already been installed. For manuals and installation guides of the application server,

please visit the websites mentioned in the software requirements section.

For performance reasons, it is recommended to install the TTS Server Workbench and

two TTS Server Web Publishers (one for preview purposes) on separate server in-

stances. Please refer to the System overview and deployment scenarios chapter for

the recommended deployment scenario.

Only the Web Publisher can be operated in a clustered environment. The Work-

bench is not designed to work on more than one cluster node. Therefore, it must

only be deployed to a single cluster node.

In a scenario with one Workbench and several Web Publishers, an internal distributed

cache keeps data consistent and up-to-date between the different server components.


10

3.5 Solr installation

The TTS Server infrastructure uses Apache SolrTM for indexing and searching.

Apache SolrTM is a web application available from the Apache Software Foundation. Please

install Solr according to their installation instructions.

Please use a Solr version that matches your Java JRE version. The Solr versions 4.8.0

and higher require Java 7.

The TTS Server Components require the Solr version 4.7.1 or higher.

You can install Solr

› either in the same servlet container as the TTS Server Components,

› or in a separate servlet container, possibly on a different machine.

Please use a dedicated Solr instance for the TTS Server infrastructure.

During installation, be sure to define an appropriate location for the index. If not speci-

fied, Solr will place the index in a default location, which might be situated inside your

application server webapps space. This is not recommended. Instead, select a location

of your choice and define it as the solr home directory.

You will need the following properties for the TTS Server Components installation:

› The Solr home location, e.g. C:\solr

› Solr's URL and Port, e.g. http://127.0.0.1:8983/solr

http://127.0.0.1:8983/solr


11

4 Installation step-by-step

4.1 Checklist

Before you start deploying TTS Server, please make sure that the following requirements are

met:

› The installation files are available.

› The licenses for the components are available.

› Database and Database user(s) have been created.

› All required paths on file system are available.

› Details of distributed caching (Multicast-IP-address and port and so on).

› The application server is installed properly.

› The Solr search engine is installed, and a solr home directory is configured.

Currently, many customers use Apache Tomcat to run the TTS server. This application serv-

er is open source, free to use, and sufficient for most customers' demands.

If the TTS server is used enterprise-wide, possibly worldwide, for a large number of authors

and end users, an alternative application server - which is more suited for an enterprise set-

ting - should be considered. Therefore, IBM WebSphere or Oracle Weblogic are supported

as well. These are commercial, offer high performance, stability, scalability (via clustering),

better maintenance, and convenient monitoring.

Before you start TTS Server for the first time, you are strongly advised to read

the Post installation steps chapter.

4.2 Installation environment

You need to configure the TTS Server components before you can deploy and start the ap-

plication successfully. The basic configuration comprises server properties, database con-

nection, andfile system paths. Once these settings have been provided, the server can be

run in default mode.

Additional settings may be necessary for services and features like user authentication and

authorization, caching, or workflow and versioning. They are explained in detail in the ap-

pendix.

The actual configuration is carried out via a file named application-config.properties. Please

note that the application has fall-back-mechanism to load configuration parameters by scan-

ning several external locations before using the system's default value:

1. Properties file with default name application-config.properties

2. Context parameters

3. JVM arguments


12

4.2.1 Setup installation environment

As best practice, we recommend setting up a simple installation environment to keep things

clear. Therefore, just create the following folder structure:

$TTPS_HOME/apps

$TTPS_HOME/logs

$TTPS_HOME/repository

$TTPS_HOME/repository/guide

$TTPS_HOME/store

$TTPS_HOME/temp

The apps folder is there to store the single .WAR files of the Workbench and the Web Pub-

lisher. Depending on the application server and its deployment behavior, the structure within

apps may differ.

The logs directory may contain generated log files, if you configure it that way. Especially if

the application server does not unpack the .WAR files during deployment, we will need to

configure the application to write logs in that folder.

The application's file repository will be setup within repository; runtime files are located in

store.

For temporary installation purposes, files may be stored in temp.

Of course you may place these folders wherever you like, but please consider at least keep-

ing the document content within repository, separate from runtime files in store.

At last, we place the server license file and the application-config.properties directly in

$TTPS_HOME.

4.2.2 Configure TTS Server with application-config.properties

4.2.2.1 What is application-config.properties?

The application-config.properties file is actually a simple text file with a .properties extension,

serving - among other things - especially as a configuration mechanism for Java applications.

Within this file, you can define application parameters using key-value-pairs separated by a

'='.

Defining parameters is subject to simple rules:

› The file must have a .properties extension

› Parameter and value are separated with an '=' on a single line

› Parameter and value are valid

› Parameters for TTS Server Workbench match the following syntax: ttkf.server.. or

ttkf.integrator..


13

› Parameters for TTS Server Web Publisher match the following syntax: ttkf.server.. or

ttkf.accelerator..

› File paths must be separated with a slash “/” instead of backslash “\”

The following example shows a snippet of an application-config.properties file:

# workbench database configuration

ttkf.server.data.hibernate.dialect = de.tts.bd.business.data.UnicodeOracle10gDialect

ttkf.server.data.hibernate.default_schema = TTS

# publisher database configuration

ttkf.accelerator.data.portal.hibernate.dialect = de.tts.bd.business.data.UnicodeOracle10gDialect

ttkf.accelerator.data.portal.hibernate.default_schema = TTS

# store directory

ttkf.server.store.store.base.directory = /ttkf/datastore

4.2.2.2 How to make application-config.properties accessible?

On Websphere, you can easily provide the application-config.properties file to the TTS Serv-

er by creating an environment variable within the administration console.

Just navigate to the server which hosts the applications, move to Java and Process Man-

agement, then to Process Definition. Next go to Java Virtual Machine and click Custom

Properties.

There you add a variable named ttkf.server.properties with value representing the full path

of the file's location, in our case $TTPS_HOME/application-config.properties.

See the Assigning the reference to the application-config.properties file section in the

Deployment chapter for a step-by-step guide.

4.2.2.3 Example of a minimum configuration

The following example illustrates the installation of TTS Server components using Oracle

database.

Database Connection

At first we configure the database connection. Since we want to use a data source, we just

need to set hibernate dialect and default schema. Internally the JNDI name we will bind the

data source which is called java:comp/env/jdbc/TTKFDS.

ttkf.server.data.hibernate.dialect = de.tts.bd.business.data.UnicodeOracle10gDialect

ttkf.server.data.hibernate.default_schema = TTS

We define the connection properties for Web Publisher as well.

ttkf.accelerator.data.portal.hibernate.dialect =

de.tts.bd.business.data.UnicodeOracle10gDialect

ttkf.accelerator.data.hibernate.portal.default_schema = TTS


14

See the Database service chapter in the appendix for details.

Application Properties

We begin by defining the context names of Workbench and Web Publisher. Since the context

names can be chosen freely, it is necessary for intercommunication of the applications to

know the context name of each other.

ttkf.server.properties.acceleratorContextPath = /publisher

ttkf.server.properties.integratorContextPath = /workbench

Next we set the location of the license file, the directory for the application server's logs, and

the super user IPs.

ttkf.server.properties.licenseFile=file:C:/TTPS/server.ttlk

ttkf.server.properties.applicationServerLogDirectory=C:/ibm/websphere/logs

ttkf.server.properties.superuserIPs=127.0.0.1,192.168.85.48

For Websphere, we also have to specify the xmlReaderClass and XercesXMLSerializerFac-

tory parameters to avoid XML parsing issues.

ttkf.server.properties.xmlReaderClass=org.apache.xerces.parsers.SAXParser

ttkf.server.properties.XercesXMLSerializerFactory=org.exolab.castor.xml.XercesXMLSerializ

erFactory

The last and very important parameters are the following Websphere-specific ones:

ttkf.server.properties.httpRequestWrapperClass=de.tts.bd.web.Websphere61RequestWrapp

er

ttkf.server.properties.was61SessionIdPrefix= to be defined later after deployment

ttkf.server.properties.was61SessionIdSuffix= to be defined later after deployment

Because only the Workbench can re/indexing entities with Solr, the Workbench have to know

the Publisher URL.

ttkf.server.properties.internal_acceleratorURL=http://192.168.86.44:9980/publisher

See the Properties service chapter in the appendix for details.


15

Solr

The Workbench needs to know the Solr-URL for re/indexing the entities.

ttkf.server.search.server.url=http://127.0.0.1:8983/solr/core

See the Search Service chapter in the appendix for more details.

See the Solr installation chapter in the Preparations for more details.

Data Store

Now we need to configure the base directory of the runtime files. So we define the location of

our new created folder $TTPS/store.

ttkf.server.store.store.base.directory = C:/TTPS/store

See the Store service chapter in the appendix for more information.

Guide

To store Guides, a Guide-Repository is needed. So we just define the location of our created

folder $TTPS_HOME/repository/guide.

ttkf.server.guidebase.rootdir=C:/TTPS/repository/guide

See the Miscellaneous parameters chapter in the appendix for more details.

Distributed Cache

To get the distributed cache working properly, we need to configure several parameters. Be

sure to have information about the mode of the distributed cache (unicast/multicast) and the

corresponding IP-addresses and ports ready.

We will configure multicast, which is the default mode.

ttkf.server.cache.peers.multicastGroupPort=45637

ttkf.server.cache.peers.multicastGroupAddress=228.8.18.9

See the Cache service chapter in the appendix for details.

Logging

Finally, we direct the log output to the log directory we created. This is only necessary if the

application server does not unpack the .WAR files. If the application server unpacks the

.WAR file during deployment, the logs are written to $APPLICATION_HOME/WEB-INF/logs.

In this example, we assume that the application server does not unpack .WAR files.

ttkf.integrator.logging.log4j.appender.system.File=C:/TTPS/logs/workbench/system.xml

ttkf.accelerator.logging.log4j.appender.system.File=C:/TTPS/logs/publisher/system.xml

See the Logging service chapter in the appendix for details.


16

4.2.2.4 How to escape special characters within the .properties file

The encoding of a .properties file is per definition ISO-8859-1, also known as Latin-1. All non-

Latin-1 characters must be entered using Unicode escape characters, e. g. \uHHHH, where

HHHH is a hexadecimal index of the character in the Unicode character set. A non-Latin-1

text file can be converted to a correct .properties file by using the native2ascii tool that ships

with the JDK.

4.3 Data source

4.3.1 Creating a data source with the IBM WebSphere 7.0 Console

In WebSphere 7.0, you can create a data source in a very convenient way by using wizards

in the WebSphere console. For a complete data source, four steps have to be performed.

1. Create a JDBC provider (if the application server doesn't provide one yet)

2. Deposit authentication data

3. Create the data source

4. Configure the connection pool

In the following step-by-step example, a data source pointing to an Oracle 11g database will

be generated.

4.3.1.1 Creating a JDBC provider

» Click the Expand hyperlink.


» Click the JDBC providers hyperlink.

http://en.wikipedia.org/wiki/ISO/IEC_8859-1http://en.wikipedia.org/wiki/Unicode


17

» Click the New button.

» Choose Oracle as Database type.

» Choose Oracle JDBC Driver as provider type.

» Select Connection pool data source as Implementation type.


18

» Click the Next button.



19

» Click the Finish button.

» Click the Save hyperlink.


20

4.3.1.2 Creating the data source

In this step, the JDBC datasource will be created.

» Click the Data sources hyperlink.



21

» Enter GTTKFDS into the Data source name field.

» Enter jdbc/TTKFDS into the JNDI name field.

» Click the Select an existing JDBC provider radiobutton.

» Click the Select... combobox.

» Click the Oracle JDBC Driver menu item.


22


» Enter the jdbc connection url (example: jdbc:oracle:thin:@dbhost.domain.local:1521:XE) into the URL field.

» Press the +V key.

» Click theOracle11g data store helper list item.

» Click Use this data source in container managed persistence (CMP).



23




24


4.3.1.3 Creating database login credentials for a JDBC-Datasource

In this step, the authentication data will be created, containing user name and password of

the database user. If - for security reasons - you want to use two different database users,

you need to create authentication data for each user.

» Click the GTTKFDS hyperlink.


25

» Click the JAAS - J2C authentication data hyperlink.



26

» Enter TTN into the Information required Alias field.

» Press the key.

» Enter TTNUSER into the User ID field.

» Press the key.

» Enter ttn into the Password field.

» Click the OK button.



27

» Click the Data sources hyperlink.

4.3.1.4 Configuring the Connection Pool

In this step, the database connection pool will be increased to improve the database access

performance.



28

» Click the Connection pool properties hyperlink.

» Enter 30 into the Maximum connections field to increase the number of maximum parallel connections to the database.

» Click the Information required Minimum connections input field.

» Enter 5 in the Minimum connections input field.


29




30

4.3.1.5 Assigning credentials to data source


» Choose the created credentials for component-managed authentication alias.


31




32

4.3.1.6 Testing the database connection

To make sure that everything was entered correctly, you can test the connection:

» Click the Select checkbox.

» Click the Test connection button.

If everything was configured correctly, the connection test should finish successfully.


33

In case the connection test fails, you may want to verify that...

› the database (to which the data source is pointing to) is running the connection

› is not blocked by any software (e.g. a firewall)

› the JDBC driver is configured correctly

› the proper JDBC driver is placed in the defined directory

› the user name and password of the database user(s) are correct

4.4 Application server settings

4.4.1 JVM-settings

The JVM of each server instance must meet at least the following memory settings:

› Maximum PermGen space: 192 MB (-XX:MaxPermSize=192m)

› Maximum Java heap size: 1024 MB (-Xmx1024m)

› Initial Java heap size: 256 MB (-Xms256m)

› Maximum thread stack size: (-Xss512k)

4.4.2 URL-encoding

Websphere is handling the encoding of the URL and the content by using the servlet request

encoding, either set in the servlet or in the java server page. Actually that is the preferred

way specified in the J2EE 2.5.

In case encoding problems occur, it might help to set the client.encoding.override system

property, forcing the application server to use the UTF-8 character set.

System property of the JVM:

-Dclient.encoding.override=UTF-8

For more information, please see:

http://pic.dhe.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=%2Fcom.ibm.webspher

e.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Ftrun_svr_utf.html

4.5 Deployment

For IBM WebSphere, the deployment of TTS Server Workbench is described exemplarily

step by step. All steps must be carried out for Web Publisher instances as well. The data

source that has been created in the Data source chapter will be used here.

The example shows the deployment via a .WAR file. Usually, TTS provides pre-configured

.WAR or .EAR files for both components, TTS Server Workbench and Web Publisher. If this

http://pic.dhe.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Ftrun_svr_utf.htmlhttp://pic.dhe.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Ftrun_svr_utf.html


34

doesn't hold true in your case, TTS support or the application consultant will gladly help you

create the archive.

Please do not forget to define Websphere-specific properties – such as httpRe-

questWrapperClass, xmlReaderClass, XMLSerializerFactory, and so on – in the

server properties and in the scheduler service (org.quartz.threadPool.class,

org.quartz.threadPool.workManager).

4.5.1 Deployment

» Next to "Applications": Click the Expand [+] button.

» Click the New Application hyperlink.

» Click the New Enterprise Application hyperlink.

» Choose the location of the WAR/EAR file, either local or remote.



35


» Click the Precompile JavaServer Pages files checkbox.



36


» Click the Browse... button to map a work manager to the corresponding resource.

» Select either a newly created work manager (for example called wm/TT_Scheduler), or the default manager. Make sure you select the right scope (the server) for the work

manager.

» Click the Apply button.


37

» Click the Browse... button.

» Click the radiobutton to select the data source GTTKFDS.



38


» Specify the virtual host on which you would like to install TTS Server Workbench, then click Next.


39

» Enter workbench as context root.


» Complete the installation of TTS Server Workbench by clicking the Finish button.


40

» To activate the changes made to WebSphere: Click the Save hyperlink.

4.5.2 Classloader hierarchy

Before starting the application, the classloader hierarchy of the application has to be

changed. The default setting of webSphere may cause problems if the application server and

the application use different versions of the same base modules (e.g. the XML parser). To

avoid any classloading issues, the application classloader should always be consulted first.

» Navigate to the list of applications by opening the navigation group Applications and clicking on Enterprise Applications.

» Click the Applications hyperlink.

» Click the Application Types hyperlink.

» Click the WebSphere enterprise applications hyperlink.

» Click the workbench hyperlink.


41

» Click the Class loading and update detection hyperlink.

» Click the Classes loaded with local class loader first (parent last) radiobutton.


42


» Click the Manage Modules hyperlink.


43

» Click the Workbench hyperlink.

» Click the Class loader order dropdown button.

» Select the Classes loaded with local class loader first (parent last) list item.


44



Do not forget to adjust the class loader hierarchy in the application and the web

module of each TTS Server instance.


45

4.5.3 Assigning the reference to the application-config.properties file

The major part of the application’s configuration is set up using a properties file provided by

your TTS application consultant.

The following step is necessary to make the properties file available to the web application.

» Click the Servers hyperlink.

» Click the WebSphere application servers hyperlink.

» Click the server1 hyperlink.

» Click the Java and Process Management hyperlink.

» Click the Process definition hyperlink.


46

» Click the Java Virtual Machine hyperlink.

» Click the Custom properties hyperlink.



47

» Enter ttkf.server.properties into the Name field.

» Enter the fully-qualified path to the application-config.properties file on the file system into the Value field.



4.5.4 Setting the prefix and suffix of Session Id

For proper communication between TTS Server Client and TTS Server Workbench, you

need to configure the prefix and suffix the server appends to the session id. If they are not

configured correctly, communication will probably fail.


48

Proceed with the following steps:

1. If TTS Server Workbench is not running, start the application now.

2. Call the install site (http://[server]:[port]/[contextWorkbench]/site/install/install.do) and

click the Websphere tab. There, you should see three specific Websphere parameters. If

you get an error message instead, be sure to call the URL either from localhost or from

an IP listed in superUserIPs (see the post installation steps chapter).

3. Now, just copy and paste these entries into the application-config.properties file:

ttkf.server.properties.requestWrapperClass=de.tts.bd.web.Websphere61RequestWrappe

r

ttkf.server.properties.was61SessionIdPrefix= 0000

ttkf.server.properties.was61SessionIdSuffix= :-1

4. Restart the server.

4.6 Deployment of the Solr core

We assume that you have installed the Solr Web application, and that you are running

a dedicated Solr instance for the TTS Server infrastructure.

In this step, you will install the prepared Solr core which is included in the TTS Server Com-

ponents distribution.

1. Stop the servlet container.

2. Make sure that you have defined a dedicated solr home directory, and remove all files

from that directory.

3. Unpack the file solr.zip to the solr home directory. After this step, the solr home directory

should contain the file solr.xml and the directory core.

4. Start the servlet container.

Visit http://please.insert.your.solr.url.and:port/solr/#/core to confirm that your Solr is running,

and that the required Solr core is present.

4.7 Post installation steps

4.7.1 Initialization of the database schema

If the steps described in the previous chapters have been carried out, the application should

now be properly configured and deployed, thus being ready to start. There are two different

procedures to start it: with Apache Tomcat, the server itself has to be started, whereas with

IBM WebSphere or Oracle Weblogic, TTS Server can be started through the administration

console.

To initialize the database schema, a browser has to be started on the application serv-

er machine. If this is not possible and you thus have to use the browser on another

computer, the IP address of that machine must be declared as superuser IP (property

superuserIPs of Properties service).

http://please.insert.your.solr.url.and:port/solr/#/core


49

The webpage for initializing the database is located at the following URL:

http://[server]:[port]/[contextWorkbench]/site/install/install.do

Start by entering the URL given above in the browser. A straightforward administration page

appears, offering to test the database connection, (re-)create or update the database sche-

ma, or to import/export the entire database content.

4.7.1.1 Test database connection

To ensure that the database connection is working properly and that the database user has

been granted all necessary permissions, the Workbench setup provides a database connec-

tion test:

Shortly after clicking the Test the connection link, the result of the test will be displayed,

representing successful tests in green, failed operations in red print.


50

4.7.1.2 Initialize database

If you click the Initialize database link, the Workbench creates the database schema as well

as initial data. After a few moments, the login screen will then appear. A full restart of TTS

Server will be necessary to ensure that all services are running properly.

When (re-)creating the database schema or importing database content, the previous

data will be deleted completely. Please use this function very carefully!

Web Publisher does not require to initialize the database schema. It is therefore rec-

ommended to install and start up the Workbench standalone before installing (and

starting) the Web Publisher.

After initializing the database schema, the application should be restarted. Now

the Web Publisher may be started as well. For an easier analysis of possible

problems, the log file of the application server should be saved before restarting

the server or applications.

4.7.2 First login as administrator

During database schema creation, a few initial data have already been created, like the ad-

ministrator user:

› User name: admin

› Password: admin

The first login is done by calling http://[server]:[port]/[contextWorkbench]/ in the browser and

entering the administrator's user name and password.


51

After logging in as administrator, the start page of the TTS Server Workbench will look like

the following screen by default (depending on the license):


52

TTS Server Web Publisher with login required:


53

TTS Server Web Publisher without login required:

For security reasons, change the administrator password upon first login.

4.7.3 Next steps

The next steps for the administrator will usually encompass:

› Defining repositories and document types

› Assigning repositories to document types

› Adding users and maintenance roles

› Assigning authorizations to external users

› Defining a process model

› Managing custom properties

› ...

Please see the Administrator manual for more details on the steps outlined above.


54

4.8 Securing Solr

We strongly advise you to secure the Solr web application so that only the TTS Server

Components will be able to access it.

4.8.1 Securing Solr via Basic Authentication

A common approach to securing Solr is Basic Authentication. This method restricts access to

web applications based on users and roles. Users are usually required to authenticate them-

selves by a password.

In IBM Websphere, please follow these configuration steps:

4.8.1.1 Configure users and groups

In Websphere, navigate to Users and Groups.

Select Manage Users and define the new user "solradmin".

Select Manage Groups and define the new group "SolrAccess".

4.8.1.2 Adapt [solr]/WEB-INF/web.xml

Add the following xml fragment to the end of the file, directly before the closing tag :

SolrAccess

Solr

/*

DELETE

GET

POST

PUT

HEAD

TRACE

OPTIONS

SolrAccess

BASIC

Solr


55

4.8.1.3 Define application security for Solr

Navigate to Security - Global Security and enable application security (the checkbox should

be checked).

Navigate to Enterprise Applications - solr.war - Security role to user/group mapping. This

option only appears if Solr was deployed with security constraints within the deployment de-

scriptor. Find the role "SolrAccess" and assign "Special subject". Select the value "All Au-

thenticated in Applications Realm".

4.8.1.4 Adapt application-config.properties

Add the user name and password to the application properties:

ttkf.server.search.server.user=solradmin

ttkf.server.search.server.password=[the password for solradmin]

4.8.2 Configure users and groups


» Click the Manage Users hyperlink.


56

» Click the Create... button.

» Enter solradmin into the User ID field.

» Enter Solradmin into the First name field.

» Enter Solradmin into the Last name field.

» Enter Password.


57

» Create the user.

» Click the Manage Groups hyperlink.


58

» Click the Create... button.

» Enter SolrAcess into the Group name field.

» Click the Create button.


59

4.8.3 Activate application security

» Click the Security hyperlink.

» Click the Global security hyperlink.


60

» Click the Enable application security checkbox.



61


» Click the Applications hyperlink.

» Click the Application Types hyperlink.

» Click the WebSphere enterprise applications hyperlink.


62

» Click the solr_war hyperlink.

» Click the Security role to user/group mapping hyperlink.


63

» Click the Select checkbox.

» Click the Map Special Subjects image.

» Click the All Authenticated in Application's Realm input field.



64


4.8.4 Test security

» Click the Search or enter address input field.

http://servername:port/solrcontext e.g. http://localhost:9080/solr

» Enter solradmin into the User Name field.

» Enter solr into the Password field.


http://servername:port/solrcontexthttp://localhost:9080/solr


65

» Click the Core Selector hyperlink.

» Click the core input field.

After successful deployment you should see this site, the Solr search index.

4.9 Troubleshooting

The configuration and deployment of a complex application such as TTS Server sometimes

results in errors. In this chapter, the most common issues and their solutions will be dis-

cussed.

Before you contact TTS Support, you are encouraged to have a look at this chapter, as an

answer to the problem you are facing may be given here. In case the problem cannot be


66

solved, TTS Support will be glad to help you.

Please note, however, that support activities are not covered by the maintenance fee if the

problem results from a mistake the customer made during installation.

In order for TTS Support to be able to help you in the best possible way, please

attach log files and configuration files of the TTS Server to your support request.

If the TTS Server Workbench is up and running, the log and configuration files can be

downloaded from the Administration section (>Settings >Support >Server manage-

ment). Otherwise, the log files of the application server should be attached instead.

4.9.1 The server does not start up

› Is the application server running correctly?

› Is the context path, if configured, pointing to the right directory (Apache Tomcat)?

› Is the license of TTS Server available and valid?

› Is the application-config.properties file available and configured properly?

› Is the data store defined in application-config.properties available?

4.9.2 Database is unavailable

› Is the database up and running?

› Can the database be accessed from the machine on which the application server is running?

› Has the port been set correctly?

› Is the specified data source available?

› Is the appropriate JDBC driver properly defined/stored on the application server?

› Is the data store defined in application-config.properties available?


67

4.9.3 Login fails

› Has the correct user name and password been entered?

› Is the user already logged in?

› Has the maximum permissible number of logged-in users been reached?

› Has the license expired?

› Is this TTS Server addressing the right database (if pointing to a database initialized from another TTS Server Workbench, user logins might fail)?

4.10 Websphere-specific LDAP settings

For Websphere, it is necessary to define the trustStoreType when configuring LDAPS. Oth-

erwise, the trust store cannot be read correctly and an exception is thrown.

The parameter is called javax.net.ssl.trustStoreType and must be set to jks.

Example: -Djavax.net.ssl.trustStoreType=jks

4.11 Solr installation example (single Solr instance)

For general installation instructions, please refer to the Solr documentation.

With Websphere as application server, and assuming that you will use Solr only for the TTS

Server infrastructure, we recommend the following installation steps:

› Download and unpack the Solr distribution to a temporary location, e.g. C:\temp\solr-dist.

› Provide the jar files from C:\temp\solr-dist\example\lib\ext either by copying directly into solr.war orinto directoryIBM\Websphere\AppServer\lib.

› Create an empty directory for the Solr core and index data, e.g. C:\ttkf\solr. This direc-tory will be referred to as the solr home.


68

› Unpack solr.zip to the solr home directory. The solr home should now contain the file solr.xml and the subdirectory core.

› In Websphere, define the generic JVM (Java Virtual Machine) argument

-Dsolr.solr.home=C:\ttkf\solr

› Deploy solr.war from C:\temp\solr-dist\dist as a new web application.

4.11.1 Configure Solr home

» Click the Server Types hyperlink.

» Click the WebSphere application servers hyperlink.


69

» Click the server1 hyperlink.

» Click the Java and Process Management hyperlink.


70

» Click the Process definition hyperlink.

» Click the Java Virtual Machine hyperlink.


71

» Click the Generic JVM arguments input field.

» Add JVM parameter -Dsolr.solr.home=C:\ttkf\solr



72


After applying solr home a restart of the application server might be necessary.

4.11.2 Deploy Solr

» Click the Install button.


73

» Click Browse and choose the solr.war file.




74


» Click the solr.war checkbox.



75

» Click the solr.war checkbox.


» Enter solr into the solr.war field.



76




77

» Click the Start button.

4.11.3 Testing Solr

After deployment call the following URL to test if Solr is running properly. The default port in

Websphere for the applications is 9080. The URL depends of course on your system envi-

ronment.

http://servername:port/solrcontext e.g. http://localhost:9080/solr

» Click the Core Selector hyperlink.

» Click the core input field.

http://servername:port/solrcontexthttp://localhost:9080/solr


78

After successful deployment you should see this site, an empty Solr search index.


79

5 Migrating from previous versions

5.1 General remarks

This chapter provides a short summary of the most important changes that were introduced

in the major releases, focusing on installation and update routines as well as migration sce-

narios.

5.2 Updating from version 7.1 to 2012

Configuration

› The content-based revision number, which could be combined with a storage pattern, has been removed. Please use the document type assigned versioning instead, which

provides a lot more possibilities.

› The "showStatifyCertificateButton" parameter was added. For more details, see the Properties service chapter.

› The default maintenance interval of the repository service was decreased to 5 seconds.

› Detailed logging of LDAP connections has been introduced. See the Logging service chapter for more information.

5.3 Updating from version 2012 to 2012 R2

Configuration of Publisher

› The template xml contains an additional filter configuration. The "roleAccessPredicateFilter" is now part of all filter chains by default.

This filter suppresses all entities that are not assigned to any role the current user is a

member of.

In earlier releases, the roleAccessPredicateFilter was applied implicitly to all filter

chains. Therefore, to maintain the default behavior, it is necessary to add the filter to all

existing filter chains. Take care to add it to existing customizings if it is needed. (it will

be needed in most cases.)

Example:

...

› The template.xml contains an additional attribute in the filter chain configuration. All defined filter chains (including the nameless default filter chain) have to define an

additional mandatory "chain-elements-factory" attribute. The only valid value for that at-

tribute, at the current state, is "de.tts.bd.eud.filter.chain.DefaultChainElementFactory".


80

Example:

...

Configuration of Publisher

› Until this version, the path of the feature.xml file could only be a path inside the applica-tion classpath. From now on, the path can also be an absolute path anywhere on the

system. The path has just to begin with the prefix "file:"

5.4 Updating from version 2012 R2 to 2013

Web Publisher with new design (hasFrameset)

› If using the new design for the Publisher, there must be configured a new parameter within the file templates.xml, named hasFrameset.

› < property name="hasFrameset" > true

› Publisher designs prior 2013 need to set this value to true (default value), new designs must set this value to false, since the new portal design has no frames anymore.

Web Publisher offers image formats for user profiles

› With TTKF 2013, a new design for the Web Publisher has been introduced, allowing users to upload profile images. Those images may be used for comments, newsfeeds,

or other resources.

To ensure a performant way of accessing content, you are advised to define image

formats, so a properly scaled image exists for each use case, reducing network traffic

and CPU usage.

› Currently, we provide formats for

› profile images

› images for newsfeeds.

› Configuration is done in the properties service following a specific syntax:

› constant value: ttkf.server.properties.image.format

› domain: either userprofile or newsfeedentry

› format name: any name

› value: width and height of the format in pixels; if both values are specified, the image will be scaled to match the longer side; if only one value is given, the other one must

be marked with "~"

Examples:

ttkf.server.properties.image.format.userprofile.passport = width:50;height:150

ttkf.server.properties.image.format.newsfeedentry.resource = width:500;height:~

› Configure the productive image formats – comma-separated – via following parameter:

› ttkf.server.properties.image.formats = userprofile.passport,newsfeedentry.resource


81

› To limit the file size for profile images, use the following parameter:

› constant value: ttkf.server.properties.image.upload

› domain: userprofile

› maxsize

› value: any decimal number followed by unit kb or mb

Samples:

ttkf.server.properties.image.upload.userprofile.maxsize = 128kb

ttkf.server.properties.image.upload.userprofile.maxsize = 1.4mb

Web Publisher with more flexible Windows-based SSO configuration

› Now it is possible to configure the authorities populator for the Windows-based SSO in a more flexible way. Instead of requesting user information and authorities from an

LDAP server (default behavior), you may now get those bits of information from the lo-

cal database.

Example for configuring local database authorities populator:

ttn.bd.login.sso.windows.authorization.WindowsSSODatabaseAuthoritiesPopulator

For more information, see User service for authentication and authorization in the ap-

pendix.

Workbench & Web Publisher: Combine multiple attributes in LDAP groupMembership

› The definition of the groupMembership attribute now allows the combination of different attributes from LDAP.

Example:

ttkf.server.user.ldap.default.dialect.user.attr.groupMembership = #c#l

With the value c standing for country and l for location, the LDAP-interface now creates

entries like "c=DE,l=Heidelberg".

Workbench supports definition of more mime-types for zip archives

› When uploading a zip file as document content, the archive is extracted and its content examined.

Files that match a set of pre-configured mime types will be considered to be different

publishing formats of the document and will be linked in the publisher automatically.

The files considered as published document formats are configured in a pair of mime

type / priority values.

A duplicate definition of a priority value will overwrite the previously defined mime type

value.

When extending the list of supported mime types with custom mime types, make sure

to respect priority values that are already used. This means that you should use incre-

mental values starting with the value 10.


82

› Preconfigured default values

The following values are preconfigured and therefore do not require explicit definition:

› text/html=0

› text/xml=1

› text/rtf=2

› application/msword=3

› application/vnd.ms-word=4

› application/mspowerpoint=5

› application/vnd.ms-powerpoint=6

› application/msexcel=7

› application/vnd.ms-excel=8

› application/pdf=9

› Definition of custom mime-type support

› The list of supported mime types can be extended using the application-config.properties file. The mime types have to be added in the format {pre-

fix}.{mimetype}={priority} where the prefix is

ttkf.integrator.collectionContentHandler.customSupportedTypes.

The following example shows how to add support for javascript (*.js), richtext (*.rtx)

and plain text (*.txt) files:

ttkf.integrator.collectionContentHandler.customSupportedTypes.text/javascript=10

ttkf.integrator.collectionContentHandler.customSupportedTypes.text/richtext=11

ttkf.integrator.collectionContentHandler.customSupportedTypes.text/plain=12

Adding the following lines will additionally add support for MS Help files (*.chm)

ttkf.integrator.collectionContentHandler.customSupportedTypes.application/mshelp=

13

ttkf.integrator.collectionContentHandler.customSupportedTypes.application/vnd.ms-

htmlhelp=14


Workbench supports additional workflow functions

› In 2013 R2, two new workflow functions were introduced to offer more flexibility within the workflow process: NotifyAssigneeOnlyFunction and NotifyOwnerOnlyFunction.

› NotifyOwnerOnlyFunction: Sends an e-mail to the document's owner when the workflow status changes

› NotifyAssigneeOnlyFunction: Sends an e-mail to the document's assignee when the workflow status changes


83

5.6 Updating from version 2013 R2 to 2014

5.6.1 Solr Search Engine

With the 2014 update, the Solr search server replaced the lucene search engine.

For a general Solr Installation Guide, see Solr Installation in the Preparations chapter.

On how the Solr server is linked with the tt server components, see the Solr installation ex-

ample in the Installation step-by-step chapter.

5.6.2 New mandatory application properties

5.6.2.1 Search service (Solr)

ttkf.server.search.server.url

This mandatory parameter defines how the Workbench and Publisher can reach the Solr

server.

ttkf.server.search.server.url={full context path to the solr instance}

Example:

ttkf.server.search.server.url=http://127.0.0.1:8983/solr/core

5.6.2.2 internal_acceleratorURL

Is now mandatory, because only the Workbench can re/indexing entities with Solr, the Work-

bench have to know the Accelerator URL.

ttkf.server.properties.internal_acceleratorURL={valid accelerator URL}

Example:

ttkf.server.properties.internal_acceleratorURL=http://192.168.86.44:9980/publisher

5.6.2.3 Guide

ttkf.server.guidebase.rootdir

To store Guides, a Guide-Repository is needed. Therefor a path is needed, where the

Guides can be stored:

ttkf.server.guidebase.rootdir={path with read/write access}


84

Example:

ttkf.server.guidebase.rootdir=C:/TTKF/repository/guide

5.6.3 New optional application properties

5.6.3.1 Search service (General parameter)

ttkf.server.search.max.result.size

This optional parameter defines the maximum number of unfiltered search results which

should be returned by a query.

By default, each search request will be limited to 10.000 results.

Default: 10.000

ttkf.server.search.max.result.size={Positive integer}

Example:

ttkf.server.search.max.result.size=5000

ttkf.server.search.disjunction.tie

This optional parameter specifies the tie breaker for the DisMax parser in the SolR search

engine.

When searching multiple fields, this factor defines the impact that additional matches will

have on the score of a result item. For example, when a query matches the title and the de-

scription of a document, with the best match found in the title, the score of the additional

match in the description will be multiplied by the tie factor and added to the score of the best

match in the title of the document.

With a tie factor of 0.0, additional matches will be ignored.

With a tie factor of 1.0, the overall score of a result item will be the sum of all field matches.

Usually, the tie factor should be much less than 1.0.

Default: 0.5

ttkf.server.search.disjunction.tie={Between 0 and 1}

Example:

ttkf.server.search.disjunction.tie=0.0

See http://docs.lucidworks.com/display/solr/The+DisMax+Query+Parser for more de-

tails.

http://docs.lucidworks.com/display/solr/The+DisMax+Query+Parser


85

5.6.3.2 Search service (Highlighting parameter)

The following configuration parameters for the highlighting of query results are optional.

Each highlighting parameter has a direct equivalent in the SolR syntax.

See: http://docs.lucidworks.com/display/solr/Highlighting for more details.

ttkf.server.search.highlighting.snippets

Maximum number of highlighted snippets per field.

Default:1

ttkf.server.search.highlighting.snippets={Positive integer}

Example:

ttkf.server.search.highlighting.snippets=2

ttkf.server.search.highlighting.fragsize

Size in characters for highlighted fragments.

Default: 256

ttkf.server.search.highlighting.fragsize={Positive integer}

Example:

ttkf.server.search.highlighting.fragsize=256

ttkf.server.search.highlighting.simple.pre

HTML markup to insert at the start of a match in the fragment.

Default:

ttkf.server.search.highlighting.simple.pre={HTML markup}

Example:

ttkf.server.search.highlighting.simple.pre=


86

ttkf.server.search.highlighting.simple.post

HTML markup to insert at the end of a match in a fragment.

Default:

ttkf.server.search.highlighting.simple.post={HTML markup}

Example:

ttkf.server.search.highlighting.simple.post=

5.6.3.3 Guide

ttkf.server.guidebase.paging.size

When the user scrolls in a category and reach the end of the list of currently visible Guides,

the next {ttkf.server.guidebase.paging.size} Guides will loaded.

Default: 20

ttkf.server.guidebase.paging.size={x>=20}

Example:

ttkf.server.guidebase.paging.size=100

5.6.3.4 LDAP

To consider nested groups for LDAP authentication define the following new optional param-

eters:

ttkf.server.user.ldap.default.recurseIntoGroups

Should parent groups be considered?

Default: false

ttkf.server.user.ldap.default.recurseIntoGroups={true|false}

Example:

ttkf.server.user.ldap.default.recurseIntoGroups=true

ttkf.server.user.ldap.default.group.base.dn

Base DN for group search.

Default: Value of parameter ttkf.server.user.ldap.default.base.dn

ttkf.server.user.ldap.default.group.base.dn={root domain for groups}


87

Example:

ttkf.server.user.ldap.default.group.base.dn = DC=teamtraining,DC=local

ttkf.server.user.ldap.default.dialect.group.filter

Filter query for group search. Template parameters can be used.

Default: (&(objectClass=group)(dn=${ttc:group}))

Example:

ttkf.server.user.ldap.default.dialect.group.filter=(&(objectClass=group)(dn=${ttc:group}))

ttkf.server.user.ldap.default.dialect.group.attr.groupMembership

Name of the group membership attribute.

Default: memberOf

Example:

ttkf.server.user.ldap.default.dialect.group.attr.groupMembership=memberOf


5.7.1 Scheduler Service on Websphere

For 2014 R2 the parameters for the scheduler service on Websphere have changed.

Instead of org.quartz.threadPool.class and org.quartz.threadPool.workManager the parame-

ters org.quartz.threadExecutor.class and org.quartz.threadExecutor.workManagerName

must be set.

Old parameters which must be removed, otherwise errors might be occurr during runtime.

› org.quartz.threadPool.class

› org.quartz.threadPool.workManager

New parameters which must be set, when running on Websphere.

› org.quartz.threadExecutor.class

› org.quartz.threadExecutor.workManagerName


88

5.7.1.1 ttkf.server.scheduler.org.quartz.threadExecutor.class

Defines the thread executor used for Websphere.

Possible value:

ttkf.server.scheduler.org.quartz.threadEx

server installation manual, version 2014 r2 for ibm...

Documents