Team Server User Guide - Bosch Software Innovations

Transcription

Visual Rules Suite - Team Platform
Team Server User Guide
Version 6.0
Bosch Software Innovations GmbH
Americas:
Bosch Software Innovations Corp.
161 N. Clark Street
Suite 3500
Chicago, Illinois 60601/USA
Tel. +1 312 368-2500
info@bosch-si.com
www.bosch-si.com
Asia:
Bosch Software Innovations
c/o Robert Bosch (SEA) Pte Ltd
11 Bishan Street 21
Singapore 573943
Tel. +65 6571 2220
info-sg@bosch-si.com
www.bosch-si.com
Europe:
Bosch Software Innovations GmbH
Ziegelei 7
88090 Immenstaad/GERMANY
Tel. +49 7545 202-300
info-de@bosch-si.com
www.bosch-si.de
© Bosch Software Innovations GmbH, 2004 - 2013. All rights reserved. Dissemination or reproduction of this publication or any part of it for any purpose or in any form whatever is not permitted without the prior express written consent of Bosch Software Innovations GmbH. Information contained
in this publication may be subject to revision without advance notice. MLDS, Visual Rules and Work Frame Relations are registered trademarks of
Bosch Software Innovations GmbH. BOSCH and the symbol are registered trademarks of Robert Bosch GmbH, Germany. Some of the product and
company names used in this white paper are trademarks and/or registered trademarks. They are used explicitly for reference purposes and are,
independent of marking, property of their respective owners.
2
Team Server User Guide 6.0
© Bosch Software Innovations GmbH
Table of Contents
1.Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1
Range of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.1
Multitenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2
Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3
Scope of Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.1
Team Server-Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.1.1 Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4
1.3.2
Team Server-Web Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.3
Team Server Maintenance Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.4
License Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3.5
User Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Rights Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.4.1
Team Server Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.4.1.1 Default Rights Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.4.2
Team Server User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.4.2.1 Administrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.4.2.2 Build Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.4.2.3 Release Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.4.2.4 Repository Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.4.2.5 Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.4.2.6 Web Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.4.2.7 Web Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.4.3
1.5
Team Server Access Rights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Data Separation Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.5.1
Separation of Tenant Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.5.2
Separation of Application Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.5.3
Necessity and Benefits of the Data Separation . . . . . . . . . . . . . . . . . 38
2.Setting up the Team Server . . . . . . . . . . . . . . . . . . . . . . . 39
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.1
Preparing the Database Environment . . . . . . . . . . . . . . . . . . . . . . 41
3
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.1.1
Automatic Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.1.1.1 Example: Oracle Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.1.2
Manual Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.1.2.1 Example: Oracle Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2
Preparing the Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.2.1
Preparing a WebSphere Application Server. . . . . . . . . . . . . . . . . . . . . 44
2.2.2
Preparing a JBoss Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.3
Adjusting the Team Server war Files . . . . . . . . . . . . . . . . . . . . . . . 46
2.4
Deploying the Team Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4.1
2.5
Specific Procedure of Deployment for WebSphere . . . . . . . . . . . . . . . 49
Installing the Team Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.5.1
Installing the Team Server with the Installation Wizard . . . . . . . . . . . 53
2.5.2
Installing the Team Server with the Maintenance Tool. . . . . . . . . . . . 57
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.5.2.1 Creating and initializing the global Database Schema. . . . . 57
2.5.2.2 Creating and initializing the Database Schema for an individual Tenant59
2.6
Migrating Data from Product Version 5.4 . . . . . . . . . . . . . . . . . . . 61
2.7
Manually setting up Tenants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.8
Configuring the Team Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.8.1
Configuring the Team Server-Backend . . . . . . . . . . . . . . . . . . . . . . . . 68
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.8.1.1 Configuring the Build Environment for the Backend . . . . . . 69
2.8.1.2 Specifying the Database Connection for the Backend. . . . . 70
2.8.1.3 Specifying the Times of Garbage Collection . . . . . . . . . . . . . 70
2.8.1.4 Specifying the Cache Size for Permission Checks . . . . . . . . 71
2.8.1.5 Specifying the Location of the Build Directory . . . . . . . . . . . 71
2.8.1.6 Specifying the Location of the Backup Directory . . . . . . . . . 71
2.8.1.7 Specifying the Location of the Working Directory . . . . . . . . . 72
2.8.1.8 Specifying the Location of the License File. . . . . . . . . . . . . . 72
2.8.1.9 Specifying the maximum Number of Build Slots . . . . . . . . . 73
2.8.2
4
Adding a Script to the global Build Environment. . . . . . . . . . . . . . . . . 74
Table of Contents
3.Concepts and Background . . . . . . . . . . . . . . . . . . . . . . . . 77
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.1
Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.2
Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.3
HEAD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.4
Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.5
Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.5.1
Continuous Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.5.2
Release Build Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.5.3
Process Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.5.3.1 Stage "Prepare" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.5.3.2 Stage "Clean". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.5.3.3 Stage "Validate". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.5.3.4 Stage "Generate". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.5.3.5 Stage "Compile". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.5.3.6 Stage "Test" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.5.3.7 Stage "Distribute" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.5.3.8 Stage "Clean up" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.6
Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.6.1
Build Artifact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.6.1.1 Rule Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.6.1.2 Maven Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.7
3.6.2
Continuous Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.6.3
Release Build. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.1
Repository Management View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.1.1
Tab "Details". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5
Table of Contents
4.1.1.1 Tab "Details" for a Repository. . . . . . . . . . . . . . . . . . . . . . . . . 92
4.1.1.2 Tab "Details" for a Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.1.1.3 Tab "Details" for a Resource. . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2
4.1.2
Tab "Revisions" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.1.3
Tab "AuditLog" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.1.4
Tab "Permissions" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.1.5
Tab "Content" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.1.6
Tab "Project". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Build Management View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.2.1
Overview Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
4.2.1.1 Section "Continuous build processes". . . . . . . . . . . . . . . . . 101
4.2.1.2 Section "Release build processes" . . . . . . . . . . . . . . . . . . . 102
4.2.1.3 Section "Build process executions" . . . . . . . . . . . . . . . . . . . 103
4.2.2
Global Configuration Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
4.2.2.1 Tab "JDK’s" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.2.2.2 Tab "Maven installations" . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.2.2.3 Tab "Maven repositories" . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.2.2.4 Tab "Execution servers" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.2.2.5 Tab "Mail server configuration" . . . . . . . . . . . . . . . . . . . . . . 109
4.2.3
Build Process Environment Page . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
4.2.3.1 Section "Java" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.2.3.2 Section "Maven" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.2.3.3 Section "Publish in" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.2.3.4 Section "Execute as" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.2.3.5 Section "Send E-mail notification after each build to" . . . . 115
4.2.3.6 Section "General Settings" . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.2.4
Build Process Permissions Page . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
4.2.4.1 Section "Users with Read permission". . . . . . . . . . . . . . . . . 118
4.2.4.2 Section "Teams with Read permission". . . . . . . . . . . . . . . . 119
4.2.5
Build Process Monitoring Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
4.2.5.1 Section "Builds" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.2.5.2 Section "Duration". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.2.5.3 Section "Test coverage" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.2.5.4 Section "Current status/Console output" . . . . . . . . . . . . . . 125
4.2.6
6
Build Details Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Table of Contents
4.2.6.1 Section "Build artifacts" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.2.6.2 Section "Overview" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.2.6.3 Tab "Test Coverage" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.2.6.4 Tab "Console output" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.2.6.5 Tab "Changes since last build". . . . . . . . . . . . . . . . . . . . . . . 131
4.2.6.6 Tab "Build report" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.2.6.7 Tab "Test report" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.3
Maintenance View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.3.1
Overview Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
4.3.1.1 Section "Application". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.3.1.2 Section "Identity Management" . . . . . . . . . . . . . . . . . . . . . . 136
4.3.1.3 Section "Log detail level" . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.3.2
License Management Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
4.3.3
System Information Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
4.3.4
Logging Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
5.Managing Repositories. . . . . . . . . . . . . . . . . . . . . . . . . .141
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.1
Exporting Repositories into an Archive. . . . . . . . . . . . . . . . . . . . . 143
5.2
Importing Repositories from an Archive. . . . . . . . . . . . . . . . . . . . 145
5.3
Uploading an Archive to your Team Server . . . . . . . . . . . . . . . . . 147
5.4
Downloading an Archive from your Team Server. . . . . . . . . . . . . 148
5.5
Searching for Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.6
Locking/unlocking Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
5.6.1
Locking a Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
5.6.2
Unlocking a Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
5.7
Creating a new Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.8
Creating a Branch in a Repository . . . . . . . . . . . . . . . . . . . . . . . . 154
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
5.9
5.8.1
Creating a new Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
5.8.2
Creating a Copy of a Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Creating a new Rule Project in the Branch HEAD . . . . . . . . . . . . 157
7
Table of Contents
5.10
Editing Rule Project Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.11
Managing Rule Project Dependencies . . . . . . . . . . . . . . . . . . . . . 160
5.12
Creating a new Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5.13
Renaming a Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
5.14
Adding existing Projects to a Branch . . . . . . . . . . . . . . . . . . . . . . 164
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
5.14.1 Adding Projects to a selected Branch . . . . . . . . . . . . . . . . . . . . . . . .165
5.14.2 Adding a selected Project to a Branch . . . . . . . . . . . . . . . . . . . . . . . .166
5.15
Deleting a Repository, Branch or Resource . . . . . . . . . . . . . . . . . 167
5.16
Managing Access Rights for a Repository . . . . . . . . . . . . . . . . . . 168
6.Managing Build Processes . . . . . . . . . . . . . . . . . . . . . . .169
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.1
Managing the global Build Environment . . . . . . . . . . . . . . . . . . . 171
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
6.1.1
Managing the available Java/Maven Installations . . . . . . . . . . . . . .172
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6.1.1.1 Adding an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6.1.1.2 Changing the Name of an Installation . . . . . . . . . . . . . . . . . 173
6.1.1.3 Changing the Home Directory of an Installation . . . . . . . . . 173
6.1.2
Managing the available Maven Repositories . . . . . . . . . . . . . . . . . .174
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
6.1.2.1 Adding a Maven Repository . . . . . . . . . . . . . . . . . . . . . . . . . 174
6.1.2.2 Changing the Name of a Maven Repository . . . . . . . . . . . . 175
6.1.2.3 Changing the URL of a Maven Repository. . . . . . . . . . . . . . 175
6.1.3
Managing the available Execution Servers . . . . . . . . . . . . . . . . . . . .176
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.1.3.1 Adding an Execution Server . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.1.3.2 Changing the Name of an Execution Server . . . . . . . . . . . . 177
6.1.3.3 Changing the URL of an Execution Server. . . . . . . . . . . . . . 177
6.1.4
6.2
Activating the Mail Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
Creating a Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
6.2.1
8
Creating a Continuous Build Process. . . . . . . . . . . . . . . . . . . . . . . . .180
Table of Contents
6.2.2
6.3
Creating a Release Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Configuring a Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184
6.3.1
Configuring the Environment for a Build Process . . . . . . . . . . . . . . .185
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.3.1.1 Specifying the Java Environment . . . . . . . . . . . . . . . . . . . . . 186
6.3.1.2 Specifying the Maven Environment . . . . . . . . . . . . . . . . . . . 186
6.3.1.3 Specifying, where Libraries are to be published. . . . . . . . . 187
6.3.1.4 Specifying the executing User . . . . . . . . . . . . . . . . . . . . . . . 187
6.3.1.5 Specifying Users to be notified. . . . . . . . . . . . . . . . . . . . . . . 188
6.3.1.6 Specifying general Settings . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.3.2
Managing Access Rights for a Build Process. . . . . . . . . . . . . . . . . . .191
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.3.2.1 Managing Access Rights for Users. . . . . . . . . . . . . . . . . . . . 192
6.3.2.2 Managing Permissions for Teams . . . . . . . . . . . . . . . . . . . . 194
6.3.3
6.4
Specifying Projects to be built . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196
Manually triggering a Build Process . . . . . . . . . . . . . . . . . . . . . . . 198
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198
6.5
6.4.1
Manually Triggering a Continuous Build . . . . . . . . . . . . . . . . . . . . . .199
6.4.2
Manually Triggering a Release Build . . . . . . . . . . . . . . . . . . . . . . . . .200
Downloading Build Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.Maintaining the Team Server. . . . . . . . . . . . . . . . . . . . .203
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7.1
Managing Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
7.2
Showing System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7.3
Showing the Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7.4
Creating/restoring a Backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
gesamter Abschnitt wurde in der eutschen Version überarbeitet, anschließend hier anpassen
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208
7.4.1
Creating/restoring a complete Backup . . . . . . . . . . . . . . . . . . . . . . .209
7.4.2
Creating/restoring a tenant-specific Backup. . . . . . . . . . . . . . . . . . .210
9
Table of Contents
10
1. Introduction
Introduction -
This chapter introduces the following subjects for the Visual Rules Team Server:
• Range of Application (1.1)
• Software Architecture (1.2)
• Scope of Delivery (1.3)
• Rights Concept (1.4)
• Data Separation Concept (1.5)
12
Introduction - Range of Application
1.1 Range of Application
The Visual Rules Team Server is designed to work on Rule Projects as a team. It
is the central connector between the members of a team allowing to administrate changes in a central Repository.
With respect to the administration of Rule Projects the Visual Rules Team Server
provides an auditing and a versioning of the individual Resources, which are
accessible via the Visual Rules Modeler. Here the Rights Concept of the Visual
Rules Team Server allows an elaborated user administration based on the component Identity Management. In addition, users can be granted context-sensitive permissions with respect to specific Resources down to the level of
individual files. Here the Visual Rules Team Server supports Multitenancy.
13
Introduction - Range of Application
Moreover, the Visual Rules Team Server allows to automatically build Rule Projects (i.e. to generate, compile, test, package and deploy the resulting java code
to a production system). Finally, the resulting Build Artifacts may be provided on
a Maven Repository or on the Visual Rules Execution Server. Here, these Build
Artifacts are accessible via the Visual Rules Team Server at any time.
With the help of the Visual Rules WebModeler also Rule Projects, which are
already in use, can be easily edited. Thus the Visual Rules Team Server closes
the gap between the modeling of rules with the Visual Rules WebModeler and
the execution of rules with the Visual Rules Execution Server.

For more information on the Visual Rules Modeler, the Visual Rules WebModeler, the Visual Rules Execution Server and the Identity Management
see the respective user guides.
1.1.1 Multitenancy
Multitenancy is a principle, which allows to share a single Team Server instance
together with a single database instance between multiple tenants. The Team
Server ensures that the data of each tenant is accessible only by the owning tenant and its users. In contrast to the multi-instance approach Multitenancy is
more efficient with respect to the usage of some resources like hardware or virtualization infrastructure and licenses.
14
Introduction - Software Architecture
1.2 Software Architecture
Software architecture of the Visual Rules Team Server
The Visual Rules Team Server consists of the following software components:
• Team Server-Backend (1.3.1)
• Team Server-Web Console (1.3.2)
Here each component is self-contained and delivered as an individual web
archive (war).
Due to the separation of the two components of the Visual Rules Team Server,
the Team Server-Backend may be connected to an internal company network
(intranet) while only the Team Server-Web Console is provided in the demilita-
15
Introduction - Software Architecture
rized zone (DMZ):
Connection of the Team Server components to a company intranet
16
Introduction - Scope of Delivery
1.3 Scope of Delivery
Introduction
The distribution file teamPlatform-6.x.x.zip of the Visual Rules Team Server
includes the following parts:
• Team Server-Backend (1.3.1)
• Team Server-Web Console (1.3.2)
• Team Server Maintenance Tool (1.3.3)
• License Information (1.3.4)
• User Guides (1.3.5)
17
1.3.1 Team Server-Backend
The Team Server-Backend is a self-contained standard Java EE web application.
It contains the build server component to build Rule Projects as well as the Rule
Repository to administrate Rule Projects.

In the distribution file teamPlatform-6.x.x.zip, the files needed for the
Team Server-Backend are included in the archive teamserver.war. This file
name is editable, though.
The Team Server-Backend is based on the user administration component Identity Management (1.3.1.1).
The Team Server-Backend can be accessed via the standardized HTTP protocol.

The accessibility via the standardized HTTP protocol yields the following
advantages:
- The integration of the Team Server-Backend into the company network
is simplified.
- The effort for configuring firewalls is minimized.
1.3.1.1 Identity Management
The Identity Management (IM) is a user administration component that provides
interfaces, which other systems can use to administrate their usage policy: user
authentication and authorization. The main scope of IM in a customer application is to manage the permissions (as parts of the customer application).

You can access the Identity Management via the tab User Administration,
if so. For more information on the Identity Management see the related
documentation.
18
1.3.2 Team Server-Web Console
The Team Server-Web Console is a self-contained standard Java EE web application.

In the distribution file teamPlatform-6.x.x.zip, the files needed for the
Team Server-Web Console are included in the archive teamserver-webconsole.war. This file name is editable, though.
It contains the user interface (UI) of the Visual Rules Team Server as well as that
of the Visual Rules WebModeler.
1.3.3 Team Server Maintenance Tool
The Team Server Maintenance Tool is a command line based tool used for the
following tasks:
• Installing the Team Server with the Maintenance Tool (2.5.2)
• Migrating Data from Product Version 5.4 (2.6)

Within the distribution file teamPlatform-6.x.x.zip, the files needed for the
Team Server Maintenance Tool are included in the archive teamservermaintenance.jar.
The Team Server Maintenance Tool can be used with the following parameters:
Parameter
-applicationName <arg>
Description
Name, under which a migrated Team Server
application is registered in the Identity Management, when Migrating Data from Product Version 5.4
-h
Puts out an overview of the parameters
(- -help)
Parameters of the Team Server Maintenance Tool
19
Parameter
-adminPassword <arg>
Description
Password of the administrator of the Identity
Management
-adminUser <arg>
Name of the administrator of the Identity Management
-b <arg>
Database brand
(- -brand <arg>)
Example values are:
• oracle (Oracle Database)
• mysql (Oracle MySQL)
• mssql (Microsoft SQL Server)
• h2 (H2 Database)
Note: The brand can also be given via the
parameter -tsBrand <arg>.
20
Parameter
Description
-c <arg>
Executes a specific command. The following
(-command <arg>)
commands are available:
• dumpProperties
Puts out properties (can be used with
parameters -o <arg> (- -out <arg>), -f <arg> (-file <arg>), -b <arg> (- -brand <arg>), -d
<arg> (- -driver <arg>), -j <arg> (- -url <arg>),
-p <arg> (- -password <arg>) and -u <arg> (- user <arg>))
For example see Generating a Properties File
• init
Creates database tables (can be used with
parameters -f <arg> (- -file <arg>), -b <arg> (-brand <arg>), -d <arg> (- -driver <arg>), -j
<arg> (- -url <arg>), -p <arg> (- -password
<arg>) and -u <arg> (- -user <arg>))
For example see Creating Database Tables
• dumpDDL
Generates a DDL script (must be used with b <arg> (- -brand <arg>), can be used with
parameter -o <arg> (- -out <arg>))
For example see Generating a DDL Script
• migrate
Migrates from product version 5.4.x (must
be used with parameters -f <arg> (- -file
<arg>), -vrbackup <arg>, -tenantName
<arg>, -adminUser <arg>, -applicationName
<arg>, -logPasswords (optionally))
Note: For Migrating Data from Product Version
5.4 see 2.6.
21
Parameter
Description
-d <arg>
Fully qualified class name of the JDBC driver
(- -driver <arg>)
used to execute database operations
Example values are:
• oracle.jdbc.OracleDriver
(for Oracle Database)
• com.mysql.jdbc.Driver
(for Oracle MySQL)
• net.sourceforge.jtds.jdbc.Driver
(for Microsoft SQL Server)
• org.h2.Driver
(for H2 Database)
Note: The class name can also be given via
the parameter -tsDriver <arg>.
The JDBC driver must match the database brand and the respective JAR file
must be given on the class path of the
Team Server Maintenance Tool. (You
can add the driver to the class path of
the Team Server Maintenance Tool by
copying the JAR file into the folder
teamserver-maintenance/lib).
-domainName <arg>
Name of the domain
-f <arg>
Path to the properties file to read input data
(- -file <arg>)
from
-force
Deactivates the interactive migration mode
(- -force)
Note: Parameter is helpful for migrations,
which are not attended by a user. Parameter can only be used in combination
with value migrate for parameter -c
<arg> (-command <arg>).
-globalSchema <arg>
Name of the database scheme, where tables
containing global settings are located
22
Parameter
-j <arg>
Description
Connection URL to the used database
(- -url <arg>)
Example values are:
• jdbc:oracle:thin:@<server>[:<port>]:<databa
se_name>
(for Oracle Database)
• jdbc:mysql://<host_name>[<:port>]/
<database_name>
(for Oracle MySQL)
• jdbc:jtds:sqlserver://
<host_name>[:<port>]/<database_name>
(for Microsoft SQL Server)
• jdbc:h2:tcp://<host_name>[:<port>]/<databasename>
(for H2 Database)
Note: The URL can also be given via the
parameter -tsUrl.
-logPasswords
If this parameter is given, the newly created
passwords will be written (in plain text) to the
migration result file, when Migrating Data from
Product Version 5.4
Note: This parameter is to be omitted, if passwords are not to be logged, i.e. if default
password logging behavior is desired.
23
Parameter
Description
-o <arg>
Path to a file, into which the output of the pro-
(- -out <arg>)
gram is written
Note: Parameter is especially helpful in combination with values dumpProperties or
dumpDDL for parameter -c <arg> (-command <arg>) to directly write the configuration or the DDL script into a file
instead of putting them out to the console.
-owner <arg>
User name of the user to whom all initial permissions should be assigned
-p <arg>
Password of the database user, who is used to
(- -password <arg>)
maintain the database scheme
Note: If used in combination with value
migrate for parameter -c <arg> (-command <arg>), the value must be the
password of the administrator (i.e. the
user with the name "Admin") of the earlier product version.
The password can also be given via the
parameter -tsPassword <arg>.
-tablePrefix <arg>
Prefix of the custom database tables
-tenantName <arg>
Name of the tenant for whom the initialization
should be done
-tenantSchema <arg>
Name of the database schema
-tsBrand <arg>
Database brand used for the Team ServerBackend
Note: The brand can also be given via the
properties file (if parameter -f <arg> (- file <arg>) is given). Can be used
instead of parameter -b <arg> (- -brand
<arg>) (for more information see there).
24
Parameter
-tsDriver <arg>
Description
Fully qualified class name of the JDBC driver
used to execute database operations for the
Team Server-Backend
Note: The class name can also be given via
the properties file (if parameter -f <arg>
(- -file <arg>) is given). Can be used
instead of parameter -d <arg> (- -driver
<arg>) (for more information see there).
-tsPassword <arg>
Password of the database user, who is used to
maintain the database schema for the Team
Server-Backend
Note: The password can also be given via the
instead of parameter -p <arg> (- -password <arg>).
-tsUrl
Connection URL to the database used for the
Team Server-Backend
Note: The URL can also be given via the properties file (if parameter -f <arg> (- -file
<arg>) is given). Can be used instead of
parameter -j <arg> (- -url <arg>) (for
more information see there).
-tsUser
Name of the database user, who is used to
maintain the database schema for the Team
Server-Backend
Note: The name can also be given via the
instead of parameter -u <arg> (- -user
<arg>).
25
Parameter
Description
-u <arg>
Name of the database user, who is used to
(- -user <arg>)
maintain the database schema
Note: The name can also be given via the
parameter -tsUser.
-vrbackup <arg>
Path to the backup file .vrback, from which data
are migrated, when Migrating Data from Product Version 5.4
26
1.3.4 License Information
The license information for the Visual Rules Team Server is given by the following documents:
• 3rd Party Usage.pdf
• about.html
• about_de.html
• license.html
• license_de.html

Within the distribution file teamPlatform-6.x.x.zip, the license information
documents are included in the folder legalnotice.
1.3.5 User Guides
The user guides for the Visual Rules Team Server are the following:
• Team Server User Guide (i.e. the user guide at hand)
• WebModeler User Guide (i.e. the user guide for the Visual Rules WebModeler)

Within the distribution file teamPlatform-6.x.x.zip, the user guides are
included in the folder doc.
27
Introduction - Rights Concept
1.4 Rights Concept
Introduction
Rights concept of the Team Server
The rights concept of the Visual Rules Team Server is based on three different
concepts, i.e. the following:
• Team Server Permissions (1.4.1)
• Team Server User Roles (1.4.2)
• Team Server Access Rights (1.4.3)
The actual rights of a user/team result from the combination of these.

A team may include further teams.
Generally, all permissions, which are assigned to a team, are automatically assigned to each individual user/team in that team.
28
1.4.1 Team Server Permissions
Team Server Permissions are permissions, which are defined in the Identity
Management with respect to the Visual Rules Team Server. Here each permision represents specific kinds of actions.

Per default, each tenant is assigned the Default Rights Package.
The following Team Server Permissions are distinguished:
Permission
permitted action(s)
Add/delete licenses
Managing Licenses
Administer build process permissions
Administrating build process permissions
Managing permissions with
Administrate repository permissions
respect to all repositories and the
included resources
Exporting Repositories into an
Archive repositories
Archive
Changing the detail level of the dis-
Configure logging
played logs
Changing the configuration file
Configure Team Server
teamserver.properties
Configure the global build environment
Create branch
Create repository
Delete branch
ment
Creating a Branch in a Repository
Create continuous build process
Create release build process
Managing the global Build Environ-
Creating a Continuous Build Process
Creating a Release Build Process
Creating a new Repository
Deleting a Branch
Team Server Permissions
29
Permission
Delete continuous build process
Delete release build process
Delete repository
Delete repository archive
Download repository archive
permitted action(s)
Deleting a Continuous Build Process
Deleting a Release Build Process
Deleting a Repository
Deleting an archive
Downloading an Archive from your
Team Server
Read/write permissions with
Manage access control list
respect to all build processes and
repositories
Manage locks
Upload repository archive
Restore archived repository
Locking/unlocking Resources
Uploading an Archive to your Team
Server
Importing Repositories from an
Archive
Rename branch
Renaming a Branch
Show/download system log
Showing the Log File
Show system properties
Trigger/Cancel continuous build
Trigger/Cancel release build
Open Web Modeler in read/write mode
Open Web Modeler in read-only mode
Showing System Information
Manually Triggering a Continuous
Build and canceling it
Manually Triggering a Release
Build and canceling it
Opening the Visual Rules WebModeler in read/write mode
Opening the Visual Rules WebModeler in read-only mode
Team Server Permissions
30
1.4.1.1 Default Rights Package
The default rights package is assigned to each tenant per default.
It includes the following Team Server Permissions:
• Administrate repository permissions
• Create repository
• Delete repository
• Manage locks
• Upload repository archive
• Download repository archive
• Archive repositories
• Restore archived repository
• Delete repository archive
• Create branch
• Rename branch
• Delete branch
• Manage access control list
• Administer build process permissions
• Create continuous build process
• Delete continuous build process
• Trigger/Cancel continuous build
• Create release build process
• Delete release build process
• Trigger/Cancel release build
• Open Web Modeler in read/write mode
• Open Web Modeler in read-only mode
31
1.4.2 Team Server User Roles
Introduction
Team Server User Roles are user roles, which are defined in the Identity Management with respect to the Visual Rules Team Server. Here each user role represents a virtual user, who is authorized to fulfill specific tasks (i.e. is granted
the corresponding Team Server Permissions per definition).
Per default, the following Team Server User Roles are provided:
• Administrator (1.4.2.1)
• Build Manager (1.4.2.2)
• Release Manager (1.4.2.3)
• Repository Manager (1.4.2.4)
• Modeler (1.4.2.5)
• Web Modeler (1.4.2.6)
• Web Viewer (1.4.2.7)
Further Team Server User Roles can be defined in the Identity Management.

Per default, each of the Team Server User Roles includes the following
permissions, which are generally defined (i.e. with respect to all Team
Server applications) in the Identity Management:
- Query user
- Query group
These permissions are the minimum requirement to work with the Visual
Rules products via the Team Server.
32
1.4.2.1 Administrator
The user role Administrator represents an administrator. Per default, he is
granted all Team Server Permissions.
1.4.2.2 Build Manager
The user role Build Manager represents a build manager. Per default, he is
granted all relevant Team Server Permissions for Managing Build Processes, i.e.
the following:
• Create continuous build process
• Delete continuous build process
• Trigger/Cancel continuous build
1.4.2.3 Release Manager
The user role Release Manager represents a release manager. Per default, he is
granted all relevant Team Server Permissions for managing Release Builds, i.e.
the following:
• Delete release build process
• Trigger/Cancel release build
33
1.4.2.4 Repository Manager
The user role Repository Manager represents a user with all relevant permissions for Managing Repositories, i.e. the following:
• Administrate repository permissions
• Create repository
• Delete repository
• Manage locks
• Upload repository archive
• Download repository archive
• Archive repositories
• Restore archived repository
• Delete repository archive
• Create branch
• Rename branch
• Delete branch
1.4.2.5 Modeler
The user role Modeler represents a user with all relevant permissions for working with the Visual Rules Modeler.
1.4.2.6 Web Modeler
The user role Web Modeler represents a user with all relevant permissions for
working with the Visual Rules WebModeler. Per default, he is granted the permission Open Web Modeler in read/write mode.
34
1.4.2.7 Web Viewer
The user role Web Viewer represents a user of the Visual Rules WebModeler in
read-only mode. Per default, he is granted the permission Open Web Modeler in
read-only mode.
1.4.3 Team Server Access Rights
Team Server access rights are read/write permissions, which are context-sensitive with respect to contents in the Team Server. I.e. they can be granted a user/
team with respect to a specific Repository (or included elements) on the one
hand, and to a specific Build Process on the other hand.

For managing Team Server permissions see the following chapters:
- Managing Access Rights for a Repository (5.16)
- Managing Access Rights for a Build Process (6.3.2)
35
Introduction - Data Separation Concept
1.5 Data Separation Concept
The data separation concept of the Visual Rules Team Server includes the following aspects:
• Separation of Tenant Data (1.5.1)
• Separation of Application Data (1.5.2)

For Necessity and Benefits of the Data Separation see 1.5.3.
1.5.1 Separation of Tenant Data
As the Team Server supports Multitenancy, it must be ensured that the tenants‘
data (e.g. Rule Models, Build Processes, etc.) are stored separately. Therefore
each tenant needs an own "private" space for his data. This is achieved by using
an individual database schema for each tenant. Furthermore, one additional
schema is required for storing global (i.e. non-tenant-specific) information like
the mapping between tenants and the schemas assigned to them.
1.5.2 Separation of Application Data
Unlike the common approach to use one schema per application, the Visual
Rules Team Server uses one schema for each individual tenant. This is due to
36
the fact that the separation of tenant data is the first priority. Applications separate their data by using a kind of namespaces. The namespace per application
enables the sharing of one tenant schema by different applications. This
ensures that applications don't influence the data of other applications even of
the same type (e.g. two different instances of the Team Server). The so-called
namespaces are just prefixes, which are prepended on the database object
names of an application. The following example illustrates that by using the
table VRTS_VERSION.
Application
name
Team Server
Namespace
(prefix)
DB object
name
Prefix +‘_‘+ DB
object name
TS1
VRTS_VERSION
TS1_VRTS_VERSION
TS2
VRTS_VERSION
TS2_VRTS_VERSION
Instance 1
Team Server
Instance 2
This pattern will be applied on all application instance specific database objects
over all affected schemas (global management schema and tenant schemas).
The following image displays how the namespace spans a kind of virtual application specific schemas over multiple real database schemas:
37
1.5.3 Necessity and Benefits of the Data Separation
Common multitenancy requires that the application separates the data of tenants and ensures that one tenant isn't able to access the data of other tenants.
This can be done in several ways, e.g. by an additional column on each table
which holds the tenant ID. The approach of the Visual Rules Team Server has
the following benefits:
• Tenant data can be stored physically separated using different tablespaces
• Resources can be used efficiently, because multiple applications of the
same type can be installed in a single tenant schema
• A schema migration is possible (e.g. during an application update) for a specific application of a specific tenant
• The data composition of a single tenant doesn't necessarily affect other tenants
38
2. Setting up the Team
Server
Setting up the Team Server -
Introduction
Prerequisites: The relevant database as well as the Identity Management is
running.
Setting up the Visual Rules Team Server includes the following tasks:
• Preparing the Database Environment (2.1)
• Preparing the Web Server (2.2)
• Adjusting the Team Server war Files (2.3)
• Deploying the Team Server (2.4)
• Installing the Team Server (2.5)
• Migrating Data from Product Version 5.4 (2.6)
• Manually setting up Tenants (2.7)
• Installing a Team Server License (see Managing Licenses (7.1))

Adjusting the Team Server war Files is necessary only in specific cases
(see there for more information).
Manually setting up Tenants is necessary only, if with regards to the
underlying database the Manual Mode is used.
After setting up the Team Server, you also have the possibility of Configuring the Team Server (2.8), if necessary.
40
Setting up the Team Server - Preparing the Database Environment
2.1 Preparing the Database Environment
Introduction
The Visual Rules Team Server supports basically two operational modes regarding the database, i.e. an Automatic Mode (2.1.1) and a Manual Mode (2.1.2).
Which operational mode is suitable, mainly depends on your requirements for
security.

In the Automatic Mode the database user needs privileges to modify the
structure of the database.
The Automatic Mode is not suited for productive environments but still is
valuable for evaluational purposes since it drastically simplifies the operating of the system.
When using the Automatic Mode, it is recommended to provide a separate database instance for the installation of the Team Server.
When using the Manual Mode, the database schemes for tenants have to
be setup manually. For Manually setting up Tenants see 2.7.
For examples with respect to an Oracle database see 2.1.1.1 and 2.1.2.1.
2.1.1 Automatic Mode

When using the automatic mode, it is recommended to provide a separate database instance for the installation of the Team Server.
In the automatic mode the Team Server performs most of the administrative
work (e.g. the creation of tenant schemata and their population with database
objects like tables). To be able to do this, the database user, who is used by the
41
Team Server for connecting to the database, must be authorized to do the following:
• Creating new schemata in the database
• Populating these with tables and other database objects
• Performing regular database operations on these objects
2.1.1.1 Example: Oracle Database
To operate the Team Server in the automatic mode, a database administrator
has to execute the following statements to prepare the database for the installation of the Team Server:
-- Create a database user which the Team Server uses to connect to the
-- database. This user must have sufficient privileges for regular
-- operation of the Team Server and additionally to create database
-- schemata for new tenants automatically (the specification of the
-- tablespaces in the example is optional).
create user <username>
identified by <password>
default tablespace <tablespaceName>
temporary tablespace TEMP;
-- grant login privilege so the Team Server is able to connect to the
-- database
grant create session to <username>;
-- grant create user privilege so that the Team Server is capable to create
-- a database schema for the tenant (the schema is created when a user logs
-- into the Team Platform for a tenant for the first time if no schema
-- exists for the tenant, i.e. a schema named according to the tenants
-- technical name prefixed with 'VRS_')
grant create user to <username>;
-- grant create database object privileges in all schemata in the database
-- so that the Team Server is able to automatically create its database
-- objects in the tenant schemata
grant create any table to <username>;
grant create any view to <username>;
grant create any index to <username>;
grant create any sequence to <username>;
grant create any trigger to <username>;
42
-- grant CRUD privileges in all schemata so that the Team Server is able to
-- perform regular database operations accross all tenant schemata
grant select any table to <username>;
grant insert any table to <username>;
grant update any table to <username>;
grant delete any table to <username>;
2.1.2 Manual Mode

When using the manual mode, the database schemes for tenants have to
be setup manually. For Manually setting up Tenants see 2.7.
The manual operation mode mandates that a database administrator handles
the creation and the configuration of the user, who is used by the Team Server
for connecting to the database, as well as the tenant schemas.
2.1.2.1 Example: Oracle Database
To operate the Team Server in the manual mode, a database administrator has
to execute the following statements to prepare the database for the installation
of the Team Server:
-- Create a database user which the Team Server uses to connect to the
-- database. This user only must have sufficient privileges for regular
-- operation of the Team Server. In this operational mode the database
-- administrator is responsible for the creation of database schemata
-- and their initialization with the Team Server database tables using
-- a command line based maintenance tool which is provided as part of
-- the Team Server distribution.
create user <username>
default tablespace <tableSpaceName>
temporary tablespace <tempTableSpaceName>
quota unlimited on <tableSpaceName>;
-- grant login privilege so the Team Server is able to connect to the
-- database
grant create session to <username>;
-- grant create database object privileges to the user in his schema so
-- that the Team Server can create a basic set of database objects which
43
Setting up the Team Server - Preparing the Web Server
-- are required for the management of the tenant schemata (these
-- privileges may be revoked from the user when the Team Server
-- installation successfully completed)
grant create table to <username>;
grant create view to <username>;
grant create index to <username>;
grant create sequence to <username>;
grant create trigger to <username>;
2.2 Preparing the Web Server

If you use a WebSphere application server or a JBoss web server, see one
of the following chapters:
- Preparing a WebSphere Application Server (2.2.1)
- Preparing a JBoss Web Server (2.2.2)
► To prepare the web server, add the database to the web server so that it is
provided as a data resource via the JNDI name jdbc/teamserverDS.
2.2.1 Preparing a WebSphere Application Server
To prepare a WebSphere application server, do the following:
► Configure the credentials for the database access as JAAS J2C authentication data alias.
► Configure the specific JDBC provider that is required for the database.
44
Setting up the Team Server - Preparing the Web Server
► Configure the database as a JDBC data source. Here use the following settings:
• jdbc/teamserverDS as JNDI name for that data source
• In the security settings, specify the authentication alias for containermanaged authentication alias and component-managed authentication
alias.
• In the security settings, set the mapping-configuration alias to DefaultPrincipalMapping.

WebSphere can't resolve the default JNDI name for the Team ServerBackend.
► Save the configuration changes and restart the WebSphere application
server to make the authentication alias effective.
2.2.2 Preparing a JBoss Web Server
To prepare a JBoss web server, do the following:
► Register a new module for your JDBC driver.
► Add a data source and driver in your JBoss configuration file using
java:jboss/jdbc/teamserverDS as JNDI name for that data source.

Generally, for JBoss the JNDI name must start with java:jboss/.
45
Setting up the Team Server - Adjusting the Team Server war Files
2.3 Adjusting the Team Server war Files
In the following cases you need to adjust your war files:
• You do not want to use the default home directory (i.e. ${user.home}/visualrules-teamserver) of the Team Server.
• You do not want to use the default location (i.e. ${user.home}/visualrulesteamserver/config/) for the configuration file of the Team Server-Web Console.
• You use WebSphere or JBoss (with a version earlier than 7.1.2) as an application server.

WebSphere and JBoss (with a version earlier than 7.1.2) are unable to
resolve system variables like ${user.home} in your web.xml files.
To adjust your war files, do the following, if necessary:
► If you do not want to use the default home directory, do the following:
• Extract the archive teamserver.war.
• In the folder WEB-INF, open the file web.xml.
• In the file web.xml, set the parameter VR_TEAMSERVER_HOME to the
absolute path of the working directory.
• Repack (zip) the archive teamserver.war.
► If you do not want to use the default location for the configuration file of the
Team Server-Web Console, do the following:
• Extract the archive teamserver-webconsole.war.
• In the file web.xml, set the parameter webconsoleConfigLocation to the
prospective location of the web console properties file.
• Repack (zip) the archive teamserver-webconsole.war.
46
Setting up the Team Server - Adjusting the Team Server war Files
► If you use WebSphere or JBoss (with a version earlier than 7.1.2) as an application server, do the following:
• Extract the archive teamserver.war.
• Replace all occurrences of variables in the file by absolute path names.
• Repack (zip) the archive teamserver.war.
• Extract the archive teamserver-webconsole.war.
• Replace all occurrences of variables in the file by absolute path names.
• Repack (zip) the archive teamserver-webconsole.war.
47
Setting up the Team Server - Deploying the Team Server
2.4 Deploying the Team Server

If you use a WebSphere application server, see the Specific Procedure of
Deployment for WebSphere (2.4.1).
The general procedure to deploy the Team Server is the following:
► Deploy the following war files:
• teamserver.war
• teamserver-webconsole.war
► Start the Team Server-Backend.
► Start the Team Server-Web Console.

You can verify that the Team Server-Backend/Team Server-Web Console
are running, by opening them in a web browser. Here the URL‘s need to
be given in the following formats:
- Team Server-Backend:
<protocol>:<host>:<port>/<teamServerBackendContext>
e.g. http://localhost:8080/teamserver
- Team Server-Web Console:
<protocol>:<host>:<port>/<teamServerWebconsoleContext>
e.g. http://localhost:8080/teamserver-webconsole
When the Team Server-Backend is running a login screen appears. If the
Team Server-Web Console is running, the Installation Wizard appears.
48
2.4.1 Specific Procedure of Deployment for WebSphere
If you use a WebSphere application server, the procedure to deploy the Team
Server is the following:
► Add the war file teamserver.war as a new enterprise application. As a deviation from the fast path installation with default settings, you here need to do
the following:
• Select the Team Server Webapp mapping to the WebSphere application
server.
• Map the context root to /teamserver.
• Finish and save the configuration changes.

WebSphere‘s default class loader setting is not appropriate for the Team
Server Webapp.
► To adjust the module class loader of the Team Server-Backend, do the following:
• Navigate to Applications > Application Types > WebSphere enterprise
applications and click on teamserver_war.
• In the section Modules, click on Manage Modules.
• Click on the module Team Server Webapp.
• In the drop box Class loader order, select Classes loaded with local class
loader first (parent last).
• Apply and save the configuration changes.

WebSphere can't resolve the default JNDI name for the Team ServerBackend.
49
► To adjust the JNDI name for the Team Server-Backend in the Team Server
properties file, do the following:
• Start the Team Server war application.
→ The default Team Server properties file is created.
• Stop the Team Server war application.
• In the Team Server properties file, adjust the following property:
de.innovations.ts.database.jdbc.url=jdbc/teamserverDS

The Team Server properties file teamserver.properties is located in the
folder config in the working directory.
• Save the Team Server properties file.
► Add the teamserver-webconsole.war as new enterprise application. As a
deviation from the fast path installation with default settings, you here need
to do the following:
• Select the Team Server Webconsole mapping to the WebSphere application server.
• Map the context root to /teamserver-webconsole.
• Finish and save the configuration changes.
► To adjust the Team Server web console module class loader, do the following:
• Navigate to Applications > Application Types > WebSphere enterprise
applications and click on teamserver-webconsole_war.
• In the section Modules, click on Manage Modules
• Click on the module Team Server Webconsole.
• In the drop box Class loader order, select Classes loaded with local class
loader first (parent last).
• Apply and save the configuration changes.
50
► To start the Team Server, do the following:
• Start the Team Server war application.
• Start the Team Server web console war application.
51
Setting up the Team Server - Installing the Team Server
2.5 Installing the Team Server
Introduction
Once the relevant database and the Identity Management are running, you can
install the Team Server.
Installing the Team Server includes the following steps:
• Creating and initializing the global database schema
• Creating and initializing the database schema for an individual tenant
• Registering the Team Server in the Identity Management
In these steps you are supported either by the Installation Wizard or by the Team
Server Maintenance Tool.
Accordingly, you have the following possibilities:
• Installing the Team Server with the Installation Wizard (2.5.1)
• Installing the Team Server with the Maintenance Tool (2.5.2)

When Installing the Team Server with the Installation Wizard, the basic
steps of installation are done automatically.
When Installing the Team Server with the Maintenance Tool, only the registering of the Team Server in the Identity Management is done automatically.
Whether you use the Installation Wizard or the Team Server Maintenance
Tool to install the Team Server, depends on your specific needs. In both
cases, the result is the same.
52
2.5.1 Installing the Team Server with the Installation Wizard
You can install the Visual Rules Team Server with the help of the Installation
Wizard.

When installing the Team Server with the help of the Installation Wizard,
the basic steps of installation are done automatically.
running.

Once the Team Server has been deployed, the Installation Wizard is
accessible via the web browser with an address in the format <protocol>:<host>:<port>/<teamServerWebconcoleContext>, e.g. http://localhost:8080/teamserver-webconsole.
For Deploying the Team Server see 2.4.
To install the Team Server via the Installation Wizard, do the following:
► Open the Installation Wizard:
► Adjust the URL of the Team Server-Backend, replacing localhost by the
server name.
53
► Click on Forward>>.
→ The page Identity Management Connection opens:
► Adjust the URL‘s of the backend and web console of the Identity Management, replacing localhost by the server name.
► Enter the user name, password and tenant of an administrator, who is
authorized to install applications in the Identity Management, in the respective fields.

The Team Server application will be registered in the Identity Management with the respective user.
→ The page Database connection opens:
54
► If necessary, change the entries in the following fields:
• Brand: Brand of the data base
• Global schema: Name of the data base schema containing the data base
tables for the schema management component, which is shared by all
Visual Rules Suite applications
• Custom table prefix: Prefix of the Team Server-specific data base tables
→ The page Application Settings opens:
► If necessary, change the default entries in the following fields:
• Domain name: Name of the domain, under which your Team Server will
be installed in the Identity Management
• Application name: Application name, with which your Team Server will be
installed in the Identity Management
• Administrator: Administrator, who is authorized to install applications in
the Identity Management
55
→ The page Summary opens:
► Click on Start installation.
→ The installation is executed. When finished the following message appears:
► Click on OK.
→ The Team Server-Web Console opens.
56
2.5.2 Installing the Team Server with the Maintenance Tool
Introduction
You can install the Team Server with the Team Server Maintenance Tool.
This includes the following steps:
• Creating and initializing the global Database Schema (2.5.2.1)
• Creating and initializing the Database Schema for an individual Tenant
(2.5.2.2)
running.

When installing with the Team Server Maintenance Tool, the Team Server
is automatically registered in the Identity Management.
2.5.2.1 Creating and initializing the global Database Schema
To create and initialize the global database schema, do the following:
► Extract the distribution file teamPlatform-6.x.x.zip.
► In the command line go to the folder teamserver-maintenance.
► Enter one of the following commands:
• Windows:
teamServerMaintenance.bat -c dumpProperties -o teamserver.properties
• Linux/Solaris:
teamServerMaintenance.sh -c dumpProperties -o teamserver.properties
► Press Enter.
→ In the folder teamserver-maintenance a properties file with the name teamserver.properties is created.
57
► Open the properties file in an editor.
► Set the parameters, which specify the database connections (i.e. all parameters, the name of which includes database).

Information on the relevant parameters, their meanings and possible values is given in the properties file teamserver.properties.
► Save the properties file.
► Download the JDBC driver corresponding to the database and copy it to the
folder lib in the folder teamserver-maintenance.
► In the command line, enter one of the following commands (adapted according to the settings in your Identity Management, if necessary):
• Windows:
teamServerMaintenance.bat -c init -f teamserver.properties
-domainName IAP -applicationName teamserver -owner Admin
-adminUser Ain -adminPassword Admin -tenantName DEFAULT
-o teamserver.properties
• Linux/Solaris:
teamServerMaintenance.sh -c init -f teamserver.properties
-domainName IAP -applicationName teamserver -owner Admin
-adminUser Admin -adminPassword Admin -tenantName DEFAULT
-o teamserver.properties
► Press Enter.
→ The database tables are created.
► Relocate the properties file.
58
2.5.2.2 Creating and initializing the Database Schema for an individual Tenant
To create and intitialize the database schema for an individual tenant, do the following:
► Extract the distribution file teamPlatform-6.x.x.zip.
► In the command line go to the folder teamserver-maintenance.
► Enter one of the following commands:
• Windows:
teamServerMaintenance.bat -c dumpProperties -o teamserver.properties
• Linux/Solaris:
teamServerMaintenance.sh -c dumpProperties -o teamserver.properties
► Press Enter.
→ In the folder teamserver-maintenance a properties file with the name teamserver.properties is created.
► Open the properties file in an editor.
► Set the parameters, which specify the database connections (i.e. all parameters, the name of which includes database).

Information on the relevant parameters, their meanings and possible values is given in the properties file teamserver.properties.
► Save the properties file.
► Download the JDBC driver corresponding to the database and copy it to the
folder lib in the folder teamserver-maintenance.
► In the command line, enter one of the following commands (adapted according to the settings in your Identity Management, if necessary):
• Windows:
teamServerMaintenance.bat -c setup -f teamserver.properties -admin© Bosch Software Innovations GmbH
59
User Admin -adminPassword Admin -tenantName DEFAULT -tenantSchema VRS_DEFAULT -tsHome path/to/ts/home
• Linux/Solaris:
teamServerMaintenance.sh -c setup -f teamserver.properties -adminUser
Admin -adminPassword Admin -tenantName DEFAULT -tenantSchema
VRS_DEFAULT -tsHome path/to/ts/home
► Press Enter.
→ The database tables are created.
► Relocate the properties file.
60
Setting up the Team Server - Migrating Data from Product Version 5.4
2.6 Migrating Data from Product Version
5.4
You can migrate the data from product version 5.4.x to the current version of the
Visual Rules Team Server with the Team Server Maintenance Tool. Due to the
newly introduced principle of Multitenancy, the complete data of the earlier version will here be made available for one specific tenant, whom you can choose.

Before migrating, it is recommended to create a tenant-specific backup of
the current version of the Team Server with respect to the relevant tenant
(see 7.4.2).
Prerequisites: The current version of the Team Server has been installed, but it
is not running. The database server for the current version is running. The user who is used to connect to the database for the
current version, is allowed to read and insert database statements. A backup archive file (file extension .vrback) of the earlier
version as well as the configuration file teamserver.properties of
the current version are located on the computer, on which the
Team Server Maintenance Tool is running. The Identity Management is running.

For Installing the Team Server see 2.5.
For creating a backup of the earlier product version see the related user
guide.
61
During the migration the following automatically happens:
• Users, teams, repositories, Build Processes etc. are transferred from the earlier version to the current version. Here, if an element with the same name
already exists in the current version, it is updated. I.e. generally, given contents/settings in the new version are kept, while further contents/settings
are added, if so. In particular, this means for instance:
– Permissions are granted to a user in the new version, if they had been
granted to the same user (identified by login name) in the earlier version.
– Users are added to a team in the new version, if they were included in the
same team (identified by name) in the earlier version.
– Projects are added to a Repository in the new version, if they were
included in the same Repository (identified by name) in the earlier version.

As for a Build Process the deployment to multiple execution servers is no
longer supported by the current version, the following applies: When different projects, which were to be built in a Build Process of the earlier version, had there been configured to be deployed to different execution
servers, then the following applies to the new version: The first execution
server encountered during the migration will be taken for all projects to
be built in the relevant Build Process.
• Each user of the new version is assigned a newly generated password in the
Identity Management.
• A migration result file named MigrationResult.txt is written and placed in the
directory teamserver-maintenance.

The newly generated passwords can be written (in plain text) to the migration result file using the parameter -logPasswords. The old passwords are
not stored.
62
To migrate data from product version 5.4.x, do the following:
► Extract the distribution file teamserver-distro-6.x.x.zip.
► Add the database driver file of the relevant database to the folder lib in the
directory teamserver-maintenance.
► Copy the file teamserver.properties to the directory teamserver-maintenance.
► In the file teamserver.properties of the new product version, set the values
of the following parameters:
• de.innovations.ts.database.driver: database driver name
• de.innovations.ts.database.jdbc.url: database url
• de.innovations.ts.database.jdbc.username: username
• de.innovations.ts.database.jdbc.password: database password

No other properties in the file teamserver.properties must be changed.
► Copy the backup archive file (file extension .vrback) of the earlier version to
the directory teamserver-maintenance.
► In the command line, change to the directory teamserver-maintenance.
► In the command line, enter the following command:
teamServerMaintenance.bat -c migrate -f teamserver.properties -vrbackup
<Filename>.vrback -tenantName <Tenant> -adminUser <Name>
-adminPassword <Password> -logPasswords
where:
• <Filename> represents the name of the backup archive file
• <Tenant> represents the name of the tenant, for whom you want the
migrated data to be available
• <Name> represents the name of the administrator of the Identity Management
63
• <Password> represents the password of the administrator of the Identity
Management
• -logPasswords is optional (if you want passwords to be written to the
migration result file)
► Press Enter.
→ You are asked to confirm your action.
► Confirm your action.
→ The migration starts. Once it is finished, the following message is put out to
the console: Migration successfully completed. The migration result file
gives the overall status of the migration and the new passwords, if so.
► Delete the directory VR_TEAMSERV ER_HOME/data/<tenantschema>/
rulerepository on the file system of the current version, where
<tenantschema> represents the name of the schema for the tenant, for
whom you want the migrated data to be available.
► If you want to use scripts (i.e. Windows batch scripts or Shell scripts), which
have been used in the global environment of the earlier version, then copy
these scripts from the team server home directory of the earlier version to
that of the current version.

Your administrator is responsible for informing users about the migration
and providing them with their new login credentials. If the passwords are
not put out to the migration result file, they must be manually changed in
the Identity Management web-console.
The migration will be effective with the next start of the Team Server.
64
Setting up the Team Server - Manually setting up Tenants
2.7 Manually setting up Tenants

Manually setting up tenants is necessary only if with regards to the underlying database the Manual Mode is used. In the Automatic Mode this is
done automatically.
To manually set up tenants, do the following:
► Create a new tenant schema consisting of the 'VRS_' schema prefix followed
by the technical tenant name.

The new tenant schema will be registered, when a Team Server user logs
in for the tenant for the first time. For this registration to work the Team
Server database user must be able to select existing schemas to verify
that a database schema actually exists for the tenant.
Example:
(for Oracle database)
-- create user for the new tenant
create user VRS_<tenantName>
default tablespace <tableSpaceName>
temporary tablespace <tempTableSpaceName>
quota unlimited on <tableSpaceName>;
► Generate DDL scripts for the tenant schema, using the Team Server Maintenance Tool.
Example:
(for Oracle database under Windows)
teamServerMaintenance.bat -c dumpDDL -b oracle -globalSchema
<username> -tablePrefix <tablePrefix> -tenantName <tenantName> -tenantSchema VRS_<tenantName>
► Execute the tenant-specific part of the generated DDL on your database
using a database user with sufficient privileges to create the database
objects defined in the script. Here you have to skip the DDL statements for
the global DB objects.
65
Setting up the Team Server - Manually setting up Tenants
► Grant the CRUD privileges on the created Team Server database objects to
the database user, who is used by the Team Server for connecting to the
database.
Example:
(for Oracle database)
-- Take the result of this select statement and execute
-- it also, to grant the necessary privileges
select grant_statements||owner||'.'||db_obj.object_name||
' to <username>;' as grant_statements
from (
select 'grant select on 'as grant_statements, v.owner,
v.VIEW_NAME as object_name
from sys.all_views v
union all
select 'grant select,insert,update,delete on ',
t.owner, t.table_name
from sys.all_tables t
) db_obj
where db_obj.owner = 'VRS_'||'<tenantName>' and
db_obj.object_name like '<tablePrefix>%'
66
Setting up the Team Server - Configuring the Team Server
2.8 Configuring the Team Server
Introduction
If necessary, you can configure the Visual Rules Team Server according to your
needs.

If you do not configure the Team Server, a default configuration is used.
Here you have the following possibilities:
• Configuring the Team Server-Backend (2.8.1)
• Adding a Script to the global Build Environment (2.8.2)
67
2.8.1 Configuring the Team Server-Backend
Introduction
Configuring the Team Server-Backend includes the following tasks:
• Configuring the Build Environment for the Backend (2.8.1.1)
• Specifying the Database Connection for the Backend (2.8.1.2)
• Specifying the Times of Garbage Collection (2.8.1.3)
• Specifying the Cache Size for Permission Checks (2.8.1.4)
• Specifying the Location of the Build Directory (2.8.1.5)
• Specifying the Location of the Backup Directory (2.8.1.6)
• Specifying the Location of the Working Directory (2.8.1.7)
• Specifying the Location of the License File (2.8.1.8)
• Specifying the maximum Number of Build Slots (2.8.1.9)

Most of the configuration is done in the properties file teamserver.properties. This file is located in the folder config in the working directory.
68
2.8.1.1 Configuring the Build Environment for the Backend

Configuring the build environment for the backend is only necessary, if
your license allows for Managing Build Processes, i.e. if in the license file
license.txt the Team Server Build is listed as a feature.
As a prerequisite for Managing Build Processes, you need to configure the build
environment for the Team Server-Backend such that at least one Maven installation and one Maven repository is provided.

The environment must be configured for the user who is specified when
starting the servlet container of the relevant application server.
To configure the build environment for the backend, do the following:
► Install Maven (see http://maven.apache.org/).
► Install a Maven repository, e.g. Archiva or Artifactory.
► Deploy the Visual Rules Maven plug-ins to the relevant Maven repository.

The Visual Rules Maven plug-ins are part of the Visual Rules Builder. For
details see the respective documentation.
69
2.8.1.2 Specifying the Database Connection for the Backend
You can specify the database connections for the Team Server-Backend in the
properties file teamserver.properties.
To specify the database connection for the backend, do the following:
► Set the parameter de.innovations.ts.database.brand to the relevant database brand. This can be one of the following:
• h2 (for H2 database)
• oracle (for Oracle 10g/11g)
• mysql (for Oracle MySQL)
• mssql (for Microsoft MSSQL)
► Use JNDI and provide a JNDI resource that is bound to
java:comp/env/jdbc/teamserverDS.
► Set the parameter de.innovations.ts.database.testOnBorrow to true, if you
want a connection to be validated before being borrowed from the database
connection pool (This can be helpful when working with databases that
specify a time-out for JDBC connections). Otherwise set it to false.
2.8.1.3 Specifying the Times of Garbage Collection
You can specify the times of garbage collection for the data store in the properties file teamserver.properties.
To specify the times of garbage collection, do the following:
► Set the parameter de.innovations.ts.repository.datastore.schedule.time to
the point in time (format: hhmm) when you want the garbage collection to be
initially executed.
► Set the parameter de.innovations.ts.repository.datastore.schedule.interval
to the interval (in minutes) with which you want the garbage collection to be
repeated.
70
2.8.1.4 Specifying the Cache Size for Permission Checks
You can specify the cache size for permission checks in the properties file teamserver.properties.
To specify the cache size for permission checks, do the following:
► Set the parameter de.innovations.ts.permission.cache.size to the relevant
size.
2.8.1.5 Specifying the Location of the Build Directory
You can specify the location of the build directory in the properties file teamserver.properties.

The user, who is specified when starting the servlet container of the relevant application server, must have Read and Write permission on the
build directory.
To specify the location of the build directory, do the following:
► Set the parameter de.innovations.ts.build.dir to the absolute path of the
build directory.
2.8.1.6 Specifying the Location of the Backup Directory
You can specify the location of the backup directory in the properties file teamserver.properties.

backup directory.
To specify the location of the backup directory, do the following:
► Set the parameter de.innovations.ts.backup.dir to the absolute path of the
backup directory.
71
2.8.1.7 Specifying the Location of the Working Directory
You can specify the location of the working directory in the folder WEB-INF.

working directory.
To specify the location of the working directory, do the following:
► Open the file web.xml.
► In file web.xml, set the environment variable VR_TEAMSERVER_HOME to the
absolute path of the working directory.
2.8.1.8 Specifying the Location of the License File
You can specify the location of the license file in the folder WEB-INF.

If the license file is located either in the working directory (with the name
license.txt) or in the folder .visualrules6 of the user directory (with any
name), specifying its location is not necessary. These places are automatically searched for the license file.
To specify the location of the license file, do the following:
► Open the file web.xml.
► In the file web.xml, set the context parameter VR_TEAMSERVER_LICENSE to
the absolute path of the license file.
72
2.8.1.9 Specifying the maximum Number of Build Slots
You can specify the maximum number of build slots, i.e. the maximum number
of Build Processes that can be executed parallel, in the folder WEB-INF.

Per default the maximum number of build slots is 2. A higher value may
cause a deterioration of the performance of your system.
To specify the specify the maximum number of build slots, do the following:
► Set the de.innovations.ts.build.slotCount to the appropriate value.
73
2.8.2 Adding a Script to the global Build Environment
You can add scripts (i.e. Windows batch scripts or Shell scripts) to the global
build environment of the Visual Rules Team Server. If so, such a script can be
selected to be executed after a Build (see 6.3.1.6 Specifying general Settings).

The following environment variables are available and may be used within
a build script:
- TP_BUILD_STATUS (in {SUCCESS, TEST_WARNINGS, PROBLEMATIC,
CANCELED, FAILURE, ERROR})
- TP_BUILD_NAME (e.g. 2011-12-16_14-53-59)
- TP_BUILD_JOB_NAME (e.g. exampleJob)
Furthermore, you need to consider the following when writing a script:
- The kind of script must match the operating system, on which the
Visual Rules Team Server is hosted.
- The user, who has been used to start the application server, on which
the Visual Rules Team Server is running, must have permission to execute the script.
- The working directory of the script is the directory of the Build, after
which the script is executed.
- For maximum flexibility in scripts, build related metadata (e.g. build
projects) can be extracted from the XML-based file build.info (automatically generated in the directory of the Build). A schema definition for
the content of the file build.info can be accessed via <teamserverbackend-URL>/schema/1.0/buildInfo.xsd (this schema is valid for
build.info files generated by product versions 5.4.x)
Prerequisites: The Team Server has been installed.

74
For Installing the Team Server with the Installation Wizard see 2.5.1.
To add a script to the global build environment, do the following:
► Place the script file in the folder scripts in the directory build.

Per default, the directory build is located in the working directory. Another
location may be specified though (see 2.8.1.5 Specifying the Location of
the Build Directory).
75
76
3. Concepts and Background
Concepts and Background -
Introduction
This chapter introduces the concepts, which the Visual Rules Team Server is
based on. These are the following concepts:
• Repository (3.1)
• Branch (3.2)
• HEAD (3.3)
• Resource (3.4)
• Build Process (3.5)
• Build (3.6)
• Test Coverage (3.7)
78
Concepts and Background - Repository
3.1 Repository
For the Visual Rules Team Server, a Repository is a central archive in a relational
database, which allows to store and version any kind of Resources.

Projects in a Repository can be grouped in a Branch (3.2).
Each Repository necessarily contains one Branch, called HEAD.
3.2 Branch
A Branch is a structural element inside a Repository, i.e. a container that can
include projects. Branches allow to parallelly develop a project in different directions under version control.

The main branch is called HEAD.
3.3 HEAD
The Branch HEAD represents the mainline of development.
79
Concepts and Background - Resource
3.4 Resource
For the Visual Rules Team Server there are the following kinds of Resources (as
used in the Visual Rules Modeler or the Visual Rules WebModeler):
• Projects
• Folders, e.g. the following kinds:
– Rule Models
– Rule Packages
– Rules
• Files, e.g. the following kinds:
– Rule Project Files
– Test Suites
– Tests
Here folders and files are necessarily included in projects.

The Visual Rules Team Server automatically maintains a revision history
for each Resource. The revision history runs along a revision number,
which is assigned to the respective Resource and which is automatically
increased, whenever changes to the Resource are published to the Visual
Rules Team Server.
80
Concepts and Background - Build Process
3.5 Build Process
Introduction
A Build Process is a defined process of converting the Rule Models included in
Rule Projects into executable Java code.

An execution of a Build Process is a Build (3.6).
Depending on whether or not a Build Process allows for a Release Build, the following kinds are here distinguished:
• Continuous Build Process (3.5.1)
• Release Build Process (3.5.2)

A Build Process consists of several consecutive Process Stages (3.5.3).
3.5.1 Continuous Build Process
A Continuous Build Process is a Build Process, which is exclusively triggered
automatically, e.g. on a regular time basis.

A Continuous Build Process does not allow for the execution of a Release
Build.
3.5.2 Release Build Process
A Release Build Process is a Build Process, which can be triggered manually and
thus allows for the execution of a Release Build. Here a version number can be
edited.
81
3.5.3 Process Stages
Introduction
Each Build Process usually includes the following stages:
• Stage "Prepare" (3.5.3.1)
• Stage "Clean" (3.5.3.2)
• Stage "Validate" (3.5.3.3)
• Stage "Generate" (3.5.3.4)
• Stage "Compile" (3.5.3.5)
• Stage "Test" (3.5.3.6)
• Stage "Distribute" (3.5.3.7)
• Stage "Clean up" (3.5.3.8)
Here in a Build the Stage "Prepare" as well as the Stage "Clean up" are executed
only once, while all other Process Stages are executed repeatedly for each Rule
Project:
Process Stages of a Build Process

For a specific Build Process the Stage "Test" may be excluded (see 6.3.1.6
Specifying general Settings).
82
3.5.3.1 Stage "Prepare"
In the Stage "Prepare" of a Build Process the Rule Projects to be built are
checked out from the Repository.

When Manually Triggering a Release Build, the following is done additionally:
- In order to secure that none of the Resources in the relevant Rule Projects is currently locked, these projects are tried to be locked. If this is
not possible, i.e. if a Resource actually is locked, then the Build Process cannot be executed and a corresponding message appears.
- For each of the relevant Rule Projects the version number of the current Release Build is written into the respective Rule Project File.
- In the Repository the relevant Rule Projects are labeled as released.
3.5.3.2 Stage "Clean"
In the Stage "Clean" of a Build Process the Resources from former Build Processes are deleted.
3.5.3.3 Stage "Validate"
In the Stage "Validate" of a Build Process the relevant Rule Models are being validated.
3.5.3.4 Stage "Generate"
In the Stage "Generate" of a Build Process Java source code is generated for the
relevant Rule Models.
3.5.3.5 Stage "Compile"
In the Stage "Compile" of a Build Process the generated Java source code is
being compiled.
83
3.5.3.6 Stage "Test"
In the Stage "Test" of a Build Process the compiled Java source code is tested,
i.e. the Rule Tests, which are defined in the relevant Rule Projects, are executed.

For an individual Build Process the Stage "Test" may be excluded (see
6.3.1.6 Specifying general Settings).
3.5.3.7 Stage "Distribute"
In the Stage "Distribute" of a Build Process the results from the preceding process stages are packaged and distributed as a Build Artifact.
3.5.3.8 Stage "Clean up"
In the Stage "Clean up" of a Build Process unnecessary files are deleted from
the build directory and e-mails are sent (according to the global settings in the
Tab "Mail server configuration" of the Global Configuration Page and the userspecific settings in the Section "Users with Read permission" of the Build Process Permissions Page).
84
Concepts and Background - Build
3.6 Build
Introduction
A Build is a one-time execution of a Build Process, i.e. an act of converting Rule
Models into executable Java code along the lines of the respective process configuration.

Any result of a Build is considered a Build Artifact (3.6.1).
Depending on whether or not the resulting Build Artifact is supposed to be
released, the following kinds of a Build are distinguished:
• Continuous Build (3.6.2)
• Release Build (3.6.3)
3.6.1 Build Artifact
A Build Artifact is a file produced by a Build.

A specific kind of Build Artifact is the so-called Rule Library (3.6.1.1).
3.6.1.1 Rule Library
A Rule Library is a specific kind of Build Artifact. I.e. a JAR file containing the java
code for the Rule Models contained in a Rule Project, as it is produced by a
Build.

Only if a Rule Library is deployed to a Maven Repository (3.6.1.2), it can
be reused in the Visual Rules Modeler.
3.6.1.2 Maven Repository
A Maven Repository is used to deploy a Rule Library.
85
Concepts and Background - Test Coverage
3.6.2 Continuous Build
A Continuous Build is a Build, the resulting Build Artifacts of which serve as a
basis for testing and further development.

The Build Artifacts resulting from a Continuous Build are not supposed to
be released.
3.6.3 Release Build
A Release Build is a Build, the resulting Build Artifacts of which are supposed to
be released. It is necessarily identified by a version number.
3.7 Test Coverage
The Test Coverage is a measure of quality of a Rule Test.
It is given by the number of Flow Rule Elements/Decision Table Cells that have
been actually executed in the tested Rules divided by the total number of Flow
Rule Elements/Decision Table Cells in the tested Rules.
86
4. User Interface
User Interface -
Introduction
The user interface of the Visual Rules Team Server provides different views,
each of which is used for a specific range of application.
There are the following views:
• Repository Management View (4.1)
• Build Management View (4.2)
• Maintenance View (4.3)

The views open when clicking on the corresponding tabs.
The tab User Administration opens the Identity Management (IM). For
more information see the related documentation.
88
User Interface - Repository Management View
4.1 Repository Management View

The Repository Management View opens when clicking on the tab Repository Management.
Repository Management View
The Repository Management View is used for Managing Repositories. It shows a
directory of the repositories and included elements, which are accessible in the
Visual Rules Team Server.
When a repository/element is selected, it provides a corresponding selection of
the following tabs:
• Tab "Details" (4.1.1)
• Tab "Revisions" (4.1.2)
• Tab "AuditLog" (4.1.3)
• Tab "Permissions" (4.1.4)
• Tab "Content" (4.1.5)
• Tab "Project" (4.1.6)
89
Additionally, the Repository Management View offers a corresponding selection
of the following buttons:
Button
Function
Creating a new element of the kind available in the
respective context, i.e.:
• Creating a new Repository
New
• Creating a new Branch
• Creating a new Rule Project in the Branch HEAD
• Creating a new Rule
• Exporting Repositories into an Archive
Organize
90
• Importing Repositories from an Archive
Refresh
Refreshing the Repository Management View
Search
Searching for Resources
Copy
Creating a Copy of a Branch
Add projects
Adding Projects to a selected Branch
Add to branch
Adding a selected Project to a Branch
Delete
Deleting a Repository, Branch or Resource
Open
Opening a Rule in the Visual Rules WebModeler
Open
Opening a file in a new window
4.1.1 Tab "Details"

The Tab "Details" is provided on the Repository Management View, when
an element (of any kind) is selected in the directory.
The Tab "Details" provides detailed information on the respective element (i.e.
Repository, Branch, Resource) as well as buttons to execute specific tasks.
Depending on the kind of element, the Tab "Details" appears in one of the following forms:
• Tab "Details" for a Repository (4.1.1.1)
• Tab "Details" for a Branch (4.1.1.2)
• Tab "Details" for a Resource (4.1.1.3)
91
4.1.1.1 Tab "Details" for a Repository
Tab "Details" for a repository
For a Repository the Tab "Details" holds the name.
4.1.1.2 Tab "Details" for a Branch
Tab "Details" for a branch
For a Branch, the Tab "Details" holds the following information:
Repository:
Repository including the Branch
Branch:
Name of the Branch
Created at:
Point of time when the Branch was created
Created by:
Creator of the Branch
Additionally, it offers the button

Rename for Renaming a Branch.
As the Branch HEAD generally cannot be renamed, the button
Rename is deactivated, if so.
92
4.1.1.3 Tab "Details" for a Resource
Tab "Details" for a resource
For a Resource, the Tab "Details" holds the following information:
Repository:
Repository including the Resource
Branch:
Branch including the Resource
Revision:
Revision number of the Resource
Created at:
Point of time when the Resource was created
Created by:
Creator of the Resource
Last contributor:
Editor of the latest changes to the Resource
Last modified:
Point of time of the latest changes to the Resource
Locked by:
User who locked the Resource, if so
Last comment:
Comment on the latest changes to the Resource, if so
Additionally, it can offer the following buttons (depending on the kind of the
respective Resource):
Button
Function
Lock
Locking a Resource
Unlock
Unlocking a Resource
93
4.1.2 Tab "Revisions"

The Tab "Revisions" is provided on the Repository Management View,
when a Resource is selected in the directory.
Tab "Revisions"
The Tab "Revisions" holds the revisions for the respective Resource.
For each revision it shows the revision number, date and contributor. For a
selected revision it additionally shows a comment and tags, if so.
94
4.1.3 Tab "AuditLog"

The Tab "AuditLog" is provided on the Repository Management View, when
a Resource is selected in the directory.
Tab "AuditLog"
The Tab "AuditLog" holds changes concerning the respective Resource and all
Resources included therein.
For each change it shows the date and contributor. For a selected change it
additionally shows the following:
• A comment (if there is any)
• Resources that have been added, modified or deleted
95
4.1.4 Tab "Permissions"

The Tab "Permissions" is provided on the Repository Management View,
when a Resource is selected in the directory.
Tab "Permissions"
The Tab "Permissions" holds the Team Server Access Rights currently granted to
a selected user/team with respect to the selected Resource.
Here the following applies:
• If the check box Inherit is activated, then the Team Server Access Rights are
those, which the relevant user/team is granted with respect to the containing element, e.g. the Repository including the Branch, the Branch including
the Resource, etc..
• In the field Summary a description of the resulting permissions is provided.
96
4.1.5 Tab "Content"

The Tab "Content" is provided on the Repository Management View, when
a Resource is selected in the directory, for which a preview is available,
e.g. a text file, an XML file etc..
Tab "Content"
The Tab "Content" holds a preview of the respective file.
97
4.1.6 Tab "Project"

The Tab "Project" is provided on the Repository Management View, when
a Rule Project File (ruleproject.vr) is selected in the directory.
Tab "Project"
The Tab "Project" holds the Identifiers of the respective Rule Project as well as
the required Rule Project Dependencies. For a selected Rule Project Dependency it additionally shows the Identifiers of this.
Additionally, the Tab "Project" offers the following buttons:
Button
Add dependency
Function
Adding a required Rule Project Dependency
Deleting a required Rule Project Dependency
98
Save
Saving changes
Reset
Resetting changes
User Interface - Build Management View
4.2 Build Management View

The Build Management View opens when clicking on the tab Build Management.
The Build Management View is used for Managing Build Processes.
It provides the following pages:
• Overview Page (4.2.1)
• Global Configuration Page (4.2.2)
• Build Process Environment Page (4.2.3)
• Build Process Permissions Page (4.2.4)
• Build Process Monitoring Page (4.2.5)
• Build Details Page (4.2.6)

While the Overview Page is the starting page of the Build Management
View, other pages open, when clicking on the respective buttons.
Additionally, the Build Management View generally offers the following buttons:
Button
Function
New
Creating a Build Process
Global configuration
Opening the Global Configuration Page
General buttons of the Build Management View
99
4.2.1 Overview Page

The Overview Page is the starting page of the Build Management View. If
necessary, it can be opened by clicking on Overview in the breadcrumb
navigation.
Overview Page
The Overview Page shows an overview of the Build Processes.
Here the Build Processes are subsumed in the following sections:
• Section "Continuous build processes" (4.2.1.1)
• Section "Release build processes" (4.2.1.2)
• Section "Build process executions" (4.2.1.3)

If a Build Process is currently being executed, this is indicated by the icon
in front of its name.
Additionally, the Overview Page offers the General buttons of the Build Management View.
100
4.2.1.1 Section "Continuous build processes"

The Section "Continuous build processes" is a part of the Overview Page.
Section "Continuous build processes"
The Section "Continuous build processes" holds the Build Processes for Continuous Builds.
For each Build Process it provides the following information:
Name:
Name of the Build Process
Last success:
Point of time of the latest successful Build
Last failed:
Point of time of the latest failed Build
Additionally, it offers the following buttons:
Button
Function
Manually Triggering a Continuous Build
Canceling a Build
Deleting the relevant Build Process
101
4.2.1.2 Section "Release build processes"

The Section "Release build processes" is a part of the Overview Page.
Section "Release build processes"
The Section "Release build processes" shows a list of all Build Processes for
Release Builds.
For each Release Build Process it provides the following information:
Name:
Name of the Build Process
Last success:
Point of time of the latest successful Build
Last failed:
Point of time of the latest failed Build
Button
Function
Canceling a Build
Deleting the relevant Build Process
102
4.2.1.3 Section "Build process executions"

The Section "Build process executions" is a part of the Overview Page.
Section "Build process executions"
The Section "Build process executions" holds the Build Processes, which have
been triggered but are not yet finished. These are subsumed in the following
sections:
• Running: i.e. processes, which are currently executed
• Pending: i.e. processes, which will be executed next

The maximum number of parallel executions of Build Processes is configurable (see 2.8.1.9). Per default, it is two.
103
4.2.2 Global Configuration Page

The Global Configuration Page is provided on the Build Management
View. It opens when clicking on the button
Global configuration.
Global Configuration Page
The Global Configuration Page holds the global build environment (i.e. the configuration options, which are generally available for all Build Processes).
Here the following tabs are provided:
• Tab "JDK’s" (4.2.2.1)
• Tab "Maven installations" (4.2.2.2)
• Tab "Maven repositories" (4.2.2.3)
• Tab "Execution servers" (4.2.2.4)
• Tab "Mail server configuration" (4.2.2.5)
Additionally, the Global Configuration Page offers the General buttons of the
Build Management View.
104
4.2.2.1 Tab "JDK’s"

The Tab "JDK’s" is provided on the Global Configuration Page.
Tab "JDK’s"
The Tab "JDK’s" holds the available Java installations.
For each Java installation it provides the following information:
Name:
Name of the Java installation
Home directory:
Absolute path to the Java installation directory
Button
Add
Function
Adding a Java installation
Deleting a Java installation
105
4.2.2.2 Tab "Maven installations"

The Tab "Maven installations" is provided on the Global Configuration
Page.
Tab "Maven installations"
The Tab "Maven installations" holds the available Maven installations.
For each Maven installation it provides the following information:
Name:
Name of the Maven installation
Home directory:
Absolute path to the Maven installation
Button
Add
Function
Adding a Maven installation
Deleting a Maven installation
106
4.2.2.3 Tab "Maven repositories"

The Tab "Maven repositories" is provided on the Global Configuration
Page.
Tab "Maven Repositories"
The Tab "Maven repositories" holds the available Maven repositories.
For each repository it provides the following information:
Name:
Name of the repository
Url:
URL of the repository
User name:
Name of the user
Password:
Password of the user
Button
Add
Function
Adding a Maven repository
Deleting a Maven repository
107
4.2.2.4 Tab "Execution servers"

The Tab "Execution servers" is provided on the Global Configuration Page.
Tab "Execution servers"
The Tab "Execution servers" holds the available execution servers.
For each execution server it provides the following information:
:
Name:
Name of the execution server
Url:
URL of the execution server
Button
Add
Function
Adding an execution server
Deleting an execution server
108
4.2.2.5 Tab "Mail server configuration"

The Tab "Mail server configuration" is provided on the Global Configuration Page.
Tab "Mail server configuration"
The Tab "Mail server configuration" holds the configuration of the Visual Rules
Team Server with respect to the related mail server (provided, that the mail
server is activated).

If activated, the mail server notifies selected users by an e-mail whenever
the relevant Build Process has been executed. For Specifying Users to be
notified see 6.3.1.5.
Per default the mail server is deactivated. For Activating the Mail Server
see 6.1.4.
It includes the following fields and check boxes:
SMTP Server:
Host of the SMTP server
Systemadministrator E-mail:
Entry to be written in the field Sender of an email
Use SMTP Authentication:
If activated, the authentication is automatically
used for the SMTP server
Name:
User name for the SMTP authentication
Note: This field appears only if check box Use
SMTP Authentication is activated
Password:
Password for the SMTP authentication
Note: This field appears only if check box Use
SMTP Authentication is activated
109
Use SSL:
If activated, the SSL protocol is used
SMTP port:
Port of the SMTP server
Note: If no port is given, a default port, i.e.
25, is used.
Charset:
Character set to be used in an e-mail
Note: If no character set is given, a default
character set, i.e. UTF-8, is used.
110
4.2.3 Build Process Environment Page

The Build Process Environment Page is provided in the Build Management View. It opens for a Build Process, when clicking on
Environment
in the related Build Process Monitoring Page.
Build Process Environment Page
The Build Process Environment Page holds the name of the respective Build Process as well as the configurations of its specific environment. It includes the following sections:
• Section "Java" (4.2.3.1)
• Section "Maven" (4.2.3.2)
• Section "Publish in" (4.2.3.3)
• Section "Execute as" (4.2.3.4)
• Section "Send E-mail notification after each build to" (4.2.3.5)
• Section "General Settings" (4.2.3.6)

The Section "Send E-mail notification after each build to" is not included
when Creating a Build Process.
111
In addition to the General buttons of the Build Management View, the Build Process Environment Page offers the following buttons:
Button
Function
Projects
Specifying Projects to be built
Environment
Configuring the Environment for a Build Process
Permissions
Managing Access Rights for a Build Process
4.2.3.1 Section "Java"

The Section "Java" is a part of the Build Process Environment Page.
Section "Java"
The Section "Java" holds the Java settings for the respective Build Process.
It includes the following fields:
JDK:
JDK (Java Development Kit) used to create the JVM (Java
Virtual Machine), which executes the Build Process.
Note: This JDK is also used by the Build Process to compile your Java source files.
VM arguments:
VM (Virtual Machine) arguments, which overwrite the
default VM arguments of the respective JVM, if so
Note: In this field an entry is not necessarily required.
112
4.2.3.2 Section "Maven"

The Section "Maven" is a part of the Build Process Environment Page.
Section "Maven"
The Section "Maven" holds the Maven settings for the respective Build Process.
Installation:
Maven installation used to launch Maven
Arguments:
Additional Maven arguments
Note: In this field an entry is not necessarily
required.
113
4.2.3.3 Section "Publish in"

The Section "Publish in" is a part of the Build Process Environment Page.
Section "Publish in"
The Section "Publish in" holds the Maven repository and/or the execution server,
where the libraries resulting from the respective Build Process are to be published, if so.
4.2.3.4 Section "Execute as"

The Section "Execute as" is a part of the Build Process Environment Page.
Section "Execute as"
The Section "Execute as" holds the user, who is assumed to have started a Build,
whenever it was in fact started automatically.

The user, who started a Build is given in the field of the Section "Overview"
of the Build Details Page.
114
Username:
User name of the respective user
Password:
Password of the respective user
4.2.3.5 Section "Send E-mail notification after each build to"

The Section "Send E-mail notification after each build to" is a part of the
Build Process Environment Page for an existing Build Process. It is not
included there when Creating a Build Process.
Section "Send E-mail"
The Section "Send E-mail notification after each build to" holds e-mail recipients
for the respective Build Process. Whenever the process has been executed,
these recipients are automatically sent an e-mail, which provides detailed information on the respective Build.

The information contained in the e-mail is the same as the information
given in the Section "Overview" and the Section "Build artifacts" of the
Build Details Page.
It provides the following buttons:
Button
Add recipient
Function
Adding a user as a recipient
Removing a user as a recipient
115
4.2.3.6 Section "General Settings"

The Section "General Settings" is a part of the Build Process Environment
Page.
Section "General Settings"
The Section "General Settings" holds the general settings for the respective
Build Process. It includes the following fields:
Maximum number of
Maximum number of kept Builds in the build direc-
kept builds:
tory
Trigger build automati- If activated, a Build is automatically triggered based
cally:
on the frequency specified in the attached list boxes.
Note: If the check box Only after modification is
activated, then the Build is triggered only, if
changes to the relevant Rule Project have
lately been published to the Visual Rules
Team Server.
Script to be executed
Script to be executed after a Build is finished
afterwards:
Note: There is not necessarily a script given here.
For selecting a script see (see 6.3.1.6 Specifying general Settings)
Skip test executions
If activated, the Stage "Test" is not included in the
process, i.e. executions of Rule Tests are skipped.

116
The field Additional build arguments is reserved for future use.
4.2.4 Build Process Permissions Page

The Build Process Permissions Page is provided in the Build Management
View. It opens for a Build Process, when clicking on
Permissions in the
related Build Process Monitoring Page.
Build Process Permissions Page
The Build Process Permissions Page holds the Team Server Access Rights for
the respective Build Process.
It includes the following sections:
• Section "Users with Read permission" (4.2.4.1)
• Section "Teams with Read permission" (4.2.4.2)
In addition to the General buttons of the Build Management View, the Build Process Monitoring Page offers the following buttons:
Button
Function
Projects
Environment
Permissions
117
4.2.4.1 Section "Users with Read permission"

The Section "Users with Read permission" is provided on the Build Process Permissions Page.
Section "Users with Read permission"
The Section "Users with Read permission" shows a list of all users, who are
granted the Read permission for the relevant Build Process. Here individual
users may also be granted Write permission.
It offers the following buttons:
Button
Add
Function
Adding a user to the list
Removing a user from the list
118
4.2.4.2 Section "Teams with Read permission"

The Section "Teams with Read permission" is provided on the Build Process Permissions Page.
Section "Teams with Read permission"
The Section "Teams with Read permission" shows a list of all teams, who are
granted the Read permission for the relevant Build Process. Here individual
teams may also be granted Write permission.
It offers the following buttons:
Button
Add
Function
Adding a team to the list
Removing a team from the list
119
4.2.5 Build Process Monitoring Page

The Build Process Monitoring Page is provided in the Build Management
View. It opens for a Build Process, when clicking on that Build Process on
the Overview Page.
Build Process Monitoring Page
The Build Process Monitoring Page holds detailed information on the respective
Build Process.
It includes the following sections:
• Section "Builds" (4.2.5.1)
• Section "Duration" (4.2.5.2)
• Section "Test coverage" (4.2.5.3)
• Section "Current status/Console output" (4.2.5.4)
120
In addition to the General buttons of the Build Management View, the Build Process Monitoring Page offers the following buttons:
Button
Function
Projects
Environment
Permissions
Build
Perform release
Manually Triggering a Release Build
Cancel
Canceling the current Build
121
4.2.5.1 Section "Builds"

The Section "Builds" is a part of the Build Process Monitoring Page.
Section "Builds"
The Section "Builds" shows a list of the Builds, i.e. executions of the respective
Build Process.

The number of Builds, which are shown, is limited (by the entry in the field
Maximum number of kept builds in the Section "General Settings"). I.e.
once this maximum number is reached, for each new Build the currently
oldest one is deleted automatically. Here, individual Builds may be
marked to be kept. If so, the next subsequent Build will be deleted
instead, if necessary.
122
For each individual Build, it holds the following information:
Status of the build:
Status of the Build
Here the following icons have the following meaning:
•
: Build has been finished without problems
•
: Build has been finished, but there are warnings
•
: Build has been canceled
•
: Build has failed due to errors
Note: Detailed information on errors and warnings is
provided on the Tab "Build report" and the Tab
"Test report" of the Build Details Page.
Name:
Label and number of the Build
Here the label may be marked as follows:
•
: The Release Build Process has been triggered
manually (see 6.4.2 Manually Triggering a Release
Build)
•
: The Build is marked to be kept
Note: The number of a Build is automatically
assigned in ascending order.
Finish at:
Point of time when the Build finished
Button
Function
Triggering a Build
Canceling a Build
123
Button
Function
Deleting a Build
Marking a Build to be kept
Note: This marking cannot be undone. The respective Build can
always be manually deleted, though.
4.2.5.2 Section "Duration"

The Section "Duration" is a part of the Build Process Monitoring Page.
Section "Duration"
The Section "Duration" shows a diagram of the durations of the individual Builds
currently shown in the Section "Builds".
4.2.5.3 Section "Test coverage"

The Section "Test coverage" is a part of the Build Process Monitoring
Page.
Section "Test coverage"
124
The Section "Test coverage" shows a diagram of the Test Coverage for all individual Builds (in each case calculated on the basis of the Test Coverage for the individual projects that have been built).

It is possible that for a specific Build no Test Coverage is given, e.g. when
the Build has failed.
4.2.5.4 Section "Current status/Console output"

The Section "Current status/Console output" is a part of the Build Process
Monitoring Page.
Section "Current status/Console output"
The Section "Current status/Console output" holds the current status of the latest Build (i.e. the latest execution of the respective Build Process) as well as the
respective console output.
125
4.2.6 Build Details Page

The Build Details Page is provided in the Build Management View. It
opens for a Build, when clicking on that Build in the Section "Builds" of the
Build Process Monitoring Page.
Build Details Page
The Build Details Page holds detailed information on the respective Build.
It includes the following sections/tabs:
• Section "Build artifacts" (4.2.6.1)
• Section "Overview" (4.2.6.2)
• Tab "Test Coverage" (4.2.6.3)
• Tab "Console output" (4.2.6.4)
• Tab "Changes since last build" (4.2.6.5)
• Tab "Build report" (4.2.6.6)
• Tab "Test report" (4.2.6.7)
126
4.2.6.1 Section "Build artifacts"

The Section "Build artifacts" is a part of the Build Details Page.
Section "Build artifacts"
The Section "Build artifacts" shows an overview of the Build Artifacts of a Build.
Here you have the possibility of Downloading Build Artifacts.
127
4.2.6.2 Section "Overview"

The Section "Overview" is a part of the Build Details Page.
Section "Overview"
The Section "Overview" holds the following information on a Build:
Build:
Number/label of the Build
Status:
Status of the Build. Here the following entries have the following meaning:
•
successful:
Build has been finished without problems
•
successful (see test report):
Build has been finished, but there are test warnings
(Detailed information is provided on the Tab "Test report")
•
successful (see build report):
Build has been finished, but there are build warnings
Detailed information is provided on the Tab "Build report")
•
canceled:
Build was canceled
•
failed:
Build has failed due to errors
Started at:
128
Point of time when the Build was started
Finished at:
Point of time when the Build was finished
Duration:
Duration of the Build
Started by:
User who started the Build
Additionally, the Section "Overview" offers the button
for downloading the
workspace archive of the Build.
4.2.6.3 Tab "Test Coverage"

The Tab "Test Coverage" is provided on the Build Details Page.
Tab "Test Coverage"
The Tab "Test Coverage" shows the Test Coverage for the individual projects,
which have been built in a Build.
129
4.2.6.4 Tab "Console output"

The Tab "Console output" is provided on the Build Details Page.
Tab "Console output"
The Tab "Console output" shows the console output of a Build Process.
130
4.2.6.5 Tab "Changes since last build"

The Tab "Changes since last build" is provided on the Build Details Page.
Tab "Changes since last build"
The Tab "Changes since last build" shows the latest changes, i.e. the Resources
that have been modified, added or deleted since the last Build. Here with
respect to each Resource the following information is given:
The Resource has been modified
The Resource has been added
The Resource has been deleted
Resource:
Name of the Resource
Revision:
Revision number of the Resource
Repository:
Repository including the Resource
Branch:
Branch including the Resource
131
4.2.6.6 Tab "Build report"

The Tab "Build report" is provided on the Build Details Page.
Tab "Build report"
The Tab "Build report" shows an overview of the Process Stages of a Build. Here
for each process stage the following information is given:
The process stage has been finished without problems
The process stage has been finished, but there are warnings
The process stage was canceled automatically
Name:
Name of the process stage
Start time:
Point of time when the process stage has started
Duration:
Duration of the process stage
Elements can be expanded to show more detailed information by clicking on
132
.
4.2.6.7 Tab "Test report"

The Tab "Test report" is provided on the Build Details Page.
Tab "Test report"
The Tab "Test report" shows an overview of the Rule Tests of a Build.

Rule Tests are executed in the Stage "Test" of a Build.
Here the following information is given with respect to a Rule Test:
The actual and the expected test results coincide without fail
There are warnings (e.g. because for a specific data element
no expected value has been specified)
One of the following applies:
• Executing the test was not possible
• The actual and the expected test results do not coincide
without fail
Name:
Name of the Rule Test
Tested Rule:
Tested Rule
Duration:
Duration of the Rule Test
133
User Interface - Maintenance View
4.3 Maintenance View

The Maintenance View opens when clicking on the tab Maintenance.
The Maintenance View is used for Maintaining the Team Server.
It provides the following pages:
• Overview Page (4.3.1)
• License Management Page (4.3.2)
• System Information Page (4.3.3)
• Logging Page (4.3.4)
Additionally, the Maintenance View offers the following buttons:
Button
134
Function
License Management
Managing Licenses
System Information
Showing System Information
Logging
Showing the Log File
4.3.1 Overview Page

The Overview Page is the starting page of the Maintenance View. If necessary, it can be opened by clicking on Overview in the breadcrumb navigation.
Overview Page
The Overview Page includes the following sections:
• Section "Application" (4.3.1.1)
• Section "Identity Management" (4.3.1.2)
• Section "Log detail level" (4.3.1.3)
135
4.3.1.1 Section "Application"

The Section "Application" is a part of the Overview Page.
Section "Application"
The Section "Application" shows the following information on your Team Server
application:
ID:
Id of the Team Server application (as registered in the Identity
Management)
Name:
Name of the Team Server application (as registered in the Identity
Management)
Version:
Version of the Team Server application
4.3.1.2 Section "Identity Management"

The Section "Identity Management" is a part of the Overview Page.
Section "Identity Management"
The Section "Identity Management" shows the following information with respect
to the Identity Management:
136
Backend:
URL of the backend
Web Console:
URL of the web console
4.3.1.3 Section "Log detail level"

The Section "Log detail level" is a part of the Overview Page.
Section "Log detail level"
The Section "Log detail level" shows the current log detail level of the Logging
Page. Additionally it offers the button
Logging for Showing the Log File.
137
4.3.2 License Management Page

The License Management Page is provided in the Maintenance View. It
opens when clicking on
License Manegement.
License Management Page
The License Management Page shows information on the license files for the
Visual Rules Team Server.
Here, for each license file, the following information is given:
File:
License name on the file system
License:
Licensee
Type:
Type of license (i.e. Full, Eval, or Demo)
Maintenance ends in:
End of maintenance
Valid:
End of license validation
Modeler users:
Maximum number of modeler users
Webmodeler users:
Maximum number of webmodeler users
Webmodeler viewers:
Maximum number of webmodeler viewers
Additionally, it offers the following buttons for Managing Licenses:
Button
Add License
Function
Adding a license
Deleting a license
138
4.3.3 System Information Page

The System Information Page is provided in the Maintenance View. It
opens when clicking on
System Information.
System Information Page
The System Information Page shows information on the system on which your
Team Server is running.
139
4.3.4 Logging Page

The Logging Page is provided in the Maintenance View. It opens when
clicking on
Logging.
Logging Page
The Logging Page shows the log file of the Team Server. Additionally it offers the
button

for downloading the log file.
The detail level of the logs to be displayed can be set in a range from 1
(Record very little) through 5 (Record all) (see 7.3).
Each log (i.e. each individual line) provides the following information (one after
another):
• Date of log, e.g. 2011-12-16 14:09:44,210
• Name of thread, e.g. [http-thread-pool-17080(4)]
• Log-level, e.g. [INFO], [ERROR], [WARN], etc.
• Full qualified name of the Java-class, which produced the log (with the relevant line number attached), e.g. (d.v.t.s.PrincipalLookupUtil:48)
• Content of log, e.g. Executing RemoteInvocation: method name 'getProperty'; parameter types [java.lang.String]

It is recommended to generally attach the log file teamserver.log when
sending a support request.
140
5. Managing Repositories
Managing Repositories -
Introduction
You can manage repositories in the Repository Management View of the Visual
Rules Team Server.

The Repository Management View opens when clicking on the tab Repository Management.
• Exporting Repositories into an Archive (5.1)
• Importing Repositories from an Archive (5.2)
• Uploading an Archive to your Team Server (5.3)
• Downloading an Archive from your Team Server (5.4)
• Searching for Resources (5.5)
• Locking/unlocking Resources (5.6)
• Creating a new Repository (5.7)
• Creating a Branch in a Repository (5.8)
• Creating a new Rule Project in the Branch HEAD (5.9)
• Editing Rule Project Identifiers (5.10)
• Managing Rule Project Dependencies (5.11)
• Creating a new Rule (5.12)
• Renaming a Branch (5.13)
• Adding existing Projects to a Branch (5.14)
• Deleting a Repository, Branch or Resource (5.15)
• Managing Access Rights for a Repository (5.16)
142
Managing Repositories - Exporting Repositories into an Archive
5.1 Exporting Repositories into an Archive
You can export a Repository (or several repositories) into an archive. Here, the
archive (i.e. a zip file) is created automatically.
Prerequisites: The Repository Management View is shown.
To export repositories, do the following:
► Click on
Organize and select
Export.
→ The following page opens:
► Select the relevant repositories.

You can select all repositories at once by activating the check box in the
headline.
143
Managing Repositories - Exporting Repositories into an Archive
► Click on Next>>.
→ Insert a name for the resulting archive.

The name of the archive must be unique. The file extension is added automatically.
► Click on Finish.
→ The repositories are being exported. When finished, the following message
appears:
► Click on OK.
144
Managing Repositories - Importing Repositories from an Archive
5.2 Importing Repositories from an Archive
You can import a Repository (or several repositories) from an archive.
To import repositories from an archive, do the following:
► Click on
Organize and select
Import.
It shows a list of the archives, which are currently available for your Team
Server.
► Click on

in the relevant line.
If the relevant archive is not available, you can upload it from your file system. For Uploading an Archive to your Team Server see 5.3.
→ The following dialog appears:
145
Managing Repositories - Importing Repositories from an Archive
► Select the relevant repositories.

You can select all repositories at once by activating the check box in the
headline.
The names of repositories must be unique. If a repository with the same
name already exists, it will be overwritten when importing the new one.
► If you want to import a repository with another name, do the following:
• In the column Import as, double-click on the entry of the repository.
• Edit the name.
► Click on Finish.
→ The repositories are being imported. When finished, the following message
appears:
► Click on OK.
146
Managing Repositories - Uploading an Archive to your Team Server
5.3 Uploading an Archive to your Team
Server
You can upload archives from your file system to your Team Server.
To upload an archive to your Team Server, do the following:
► Click on Upload archive.
► Click on Browse and select the relevant archive from your file system.
► Click on Upload.
→ The archive is uploaded. When finished, the following message appears:
► Click on OK.
147
Managing Repositories - Downloading an Archive from your Team Server
5.4 Downloading an Archive from your Team
Server
You can download archives from your Team Server to your file system.
To download an archive from your Team Server, do the following:
► Click on
Organize and select
Import.
It shows a list of the archives, which are currently available for your Team
Server.
► Click on
→ A dialog appears that allows you to download the archive.
148
Managing Repositories - Searching for Resources
5.5 Searching for Resources
You can search for Resources in the repositories of your Team Server.
To search for a Resource, do the following:
► Click on
Search.
► If you want to restrict the scope of your search to specific repositories,
Branches or Resources, activate the related check boxes in the section
Repositories.

Clicking on Clear clears all restrictions in the section Repositories.
149
Managing Repositories - Searching for Resources
► To specify search options, do the following in the section Search options, if
necessary:
• In the subsection User, specify a user. Here you can restrict the search to
what the user has done with respect to the relevant Resource.
• In the subsection Period of last change, specify a space of time, when the
relevant Resource has been changed for the last time.
• In the subsection Text, specify a piece of text that is included in the relevant Resource. Here you can restrict the search with respect to where the
piece of text is included.
• In the subsection Resource, specify the relevant kind(s) of Resource.
Here you can restrict the search to a particular kind of file by entering the
corresponding file extension in the field File extension.

Clicking on
Clear Search clears all restrictions in the section Search
options.
► Click on
Start search.
→ The search is started. When finished, the found Resources are displayed in
the section Result.

150
Clicking on
Unlock all unlocks all Resources in the section Result.
Clicking on
refreshes the section Result.
Managing Repositories - Locking/unlocking Resources
5.6 Locking/unlocking Resources
Introduction
You can lock/unlock a Resource, such that it cannot/can be edited by other
users.
• Locking a Resource (5.6.1)
• Unlocking a Resource (5.6.2)
151
Managing Repositories - Locking/unlocking Resources
5.6.1 Locking a Resource
To lock a Resource, do the following:
► In the directory of the Repository Management View, select the Resource.
► On the Tab "Details", click on
Lock.
► Click on Yes.
→ The Resource is locked, i.e. it cannot be edited by other users.
5.6.2 Unlocking a Resource
To unlock a Resource, do the following:
► In the directory of the Repository Management View, select the Resource.
► In the Tab "Details", click on
Unlock.
► Click on Yes.
→ The Resource is unlocked, i.e. it can be edited by other users.
152
Managing Repositories - Creating a new Repository
5.7 Creating a new Repository
You can create a new Repository on your Team Server. Here the new Repository
automatically contains a Branch HEAD.
To create a new Repository, do the following:
► Click on
New and select
Repository.
► In the field Name, enter a name for the new Repository.
► Click on OK.
→ The Repository is being created. When finished, the following message
appears:
► Click on OK.

You can delete a selected Repository by clicking on
Delete.
153
Managing Repositories - Creating a Branch in a Repository
5.8 Creating a Branch in a Repository
Introduction
You can create Branches in a Repository on your Team Server.

The Branch HEAD is automatically created and therefore you cannot create it.
• Creating a new Branch (5.8.1)
• Creating a Copy of a Branch (5.8.2)

When creating a Branch, both the time of creation and the creator are
stored.
The names of Branches within a Repository must be unique.
You have the possibility of Renaming a Branch at any time.
You can delete a selected Branch (except the Branch HEAD) by clicking on
Delete.
154
5.8.1 Creating a new Branch
You can create a new Branch in a Repository.
To create a new Branch, do the following:
► In the directory of the Repository Management View, select the relevant
Repository.
► Click on
New and select
Branch.
► In the field Name, enter a name for the new Branch.

The name of a Branch must be unique within a Repository.
► Click on OK.
→ The new Branch is being created. When finished, the following message
appears:
► Click on OK.
155
5.8.2 Creating a Copy of a Branch
You can create a copy of a Branch within a Repository.
To create a copy of a Branch, do the following:
► In the directory of the Repository Management View, select the relevant
Branch.
► Click on
Copy.
► If necessary, change the default name.

► Click on OK.
→ A copy of the Branch is being created. When finished, the following message
appears:
► Click on OK.
156
Managing Repositories - Creating a new Rule Project in the Branch HEAD
5.9 Creating a new Rule Project in the
Branch HEAD
You can create a new Rule Project on the Branch HEAD.

Creating a Rule Project in another Branch but HEAD is not considered a
reasonable approach and therefore not possible.
To create a new Rule Project in the Branch HEAD, do the following:
► Select the relevant Branch HEAD in the directory.
► Click on
New and select
Create Rule Project.
► In the field Name, enter a name for the new Rule Project.
157
Managing Repositories - Creating a new Rule Project in the Branch HEAD
► In the field below, enter a comment, if necessary.

The comment will be displayed on the Tab "Details", the Tab "Revisions"
and the Tab "AuditLog" for the Rule Project, if so.
► Click on OK.
→ A Rule Project is created. When finished, the following message appears:
► Click on OK.
158
Managing Repositories - Editing Rule Project Identifiers
5.10 Editing Rule Project Identifiers
You can edit the Rule Project Identifiers (i.e. Group ID, Artifact ID and Version) of
a Rule Project.
To edit the Rule Project Identifiers of a Rule Project, do the following:
► In the directory, select the related Rule Project File (ruleproject.vr).
► Select the Tab "Project".
► In the section Identifiers, edit the entries in the fields Artifact ID, Group ID
and Version.
► Click on Save.
→ Your changes are being saved. When finished, the following message
appears:
► Click on OK.
159
Managing Repositories - Managing Rule Project Dependencies
5.11 Managing Rule Project Dependencies
You can manage (i.e. add, delete or edit) the Rule Project Dependencies of a
Rule Project.
To manage the Rule Project Dependencies of a Rule Project, do the following:
► In the directory, select the related Rule Project File (ruleproject.vr).
► Select the Tab "Project".
► To add a Rule Project Dependency, do the following:
• Click on Add dependency.
→ An empty row is added to the list.
• Enter the Rule Project Identifiers of the Rule Project Dependency.
► To delete a Rule Project Dependency, click on
in the respective line.
► To edit a Rule Project Dependency, do the following:
• Double-click into the corresponding line.
→ The fields are now editable.
• Edit the relevant entries.
► Click on Save.
→ Your changes are being saved. When finished, the following message
appears:
► Click on OK.
160
Managing Repositories - Creating a new Rule
5.12 Creating a new Rule
You can create Rules (i.e. Flow Rules or Decision Tables) inside a Rule Model or
a Rule Package.
To create a new Rule, do the following:
► In the directory, select the relevant Rule Model/Rule Package.
► Click on
New and select
Flow Rule or
Decision Table, respectively.
► In the field Name, enter a name for the new Rule.
► In the field Comment, enter a comment, if necessary.
161
Managing Repositories - Creating a new Rule
► If you do not want the new Rule to be automatically opened in the Visual
Rules WebModeler, deactivate the corresponding check box.
→ The new Rule is being saved. When finished, the following message
appears:
► Click on OK.
→ If so, the Visual Rules WebModeler opens, showing the Rule.
162
Managing Repositories - Renaming a Branch
5.13 Renaming a Branch
You can rename Branches within a Repository.

The Branch HEAD generally cannot be renamed.
To rename a Branch, do the following:
► In the directory, select the Branch.
► Select the Tab "Details".
► Click on
Rename.
► Change the name.

► Click on OK.
→ The Branch is renamed.
163
Managing Repositories - Adding existing Projects to a Branch
5.14 Adding existing Projects to a Branch
Introduction
You can add existing projects to a Branch within the same Repository.

Existing projects cannot be added to the Branch HEAD.
Here you can either focus on the Branch or on the project.
Accordingly, you have the following possibilities:
• Adding Projects to a selected Branch (5.14.1)
• Adding a selected Project to a Branch (5.14.2)

The name of a project must be unique within a Branch. Therefore a
project cannot be added to a Branch, which already contains a project
with the same name.
You can delete a project from a Branch by clicking on
Delete in the Tab
"Details" for a Resource.
164
5.14.1 Adding Projects to a selected Branch
You can add one or more projects to a selected Branch within a Repository.
To add projects to a selected Branch, do the following:
► In the directory of the Repository Management View, select the Branch.
► Click on
Add project(s).
It shows all projects in the Repository containing the Branch.

It is possible that, due to naming restrictions, a project cannot be added.
If so, it is crossed out.
► Select the relevant projects.
► Click on OK.
→ The projects are being added to the Branch. When finished, the following
message appears:
► Click on OK.
165
5.14.2Adding a selected Project to a Branch
You can add a selected project to a Branch within the same Repository.
To add a selected project to a Branch, do the following:
► In the directory of the Repository Management View, select the project.
► Click on
Add to branch.
It shows all Branches in the Repository.
► Select the relevant Branch.
► Click on OK.
→ The project is being added to the Branch. When finished, the following message appears:
→ Click on OK.
166
Managing Repositories - Deleting a Repository, Branch or Resource
5.15 Deleting a Repository, Branch or
Resource
You can delete a Repository, a Branch or a Resource of any kind. Here all contents are deleted as well.

As for Resources a revision history is maintained, these can be restored
even when they have been deleted. This can be done in the Visual Rules
Modeler.
To delete a Repository, Branch or Resource, do the following:
► In the directory, select the Repository, Branch or Resource.
► Click on
Delete.
► Click on OK.
→ The Repository, Branch or Resource is being deleted. When finished, the following message appears:
► Click on OK.
167
Managing Repositories - Managing Access Rights for a Repository
5.16 Managing Access Rights for a Repository
You can manage Team Server Access Rights with respect to an individual Repository (or included elements, i.e. Branches or Resources of any kind).
To manage access rights for a Repository, do the following:
► In the directory, select the relevant Repository, Branch or Resource.
► Select the Tab "Permissions".
► With respect to each relevant user, do the following in the section User:
• In the field Name, select the user.
• In the field Permissions, select the access rights.
→ In the field Summary, the resulting access rights are given.
► With respect to each relevant team, do the following in the section Team:
• In the field Name, select the team.
• In the field Permissions, select the access rights.
→ In the field Summary, the resulting access rights are given.
168
6. Managing Build
Processes
Managing Build Processes -
Introduction
You can manage Build Processes in the Build Management View of the Visual
Rules Team Server.

The Build Management View opens when clicking on the tab Build Management.
• Managing the global Build Environment (6.1)
• Creating a Build Process (6.2)
• Configuring a Build Process (6.3)
• Manually triggering a Build Process (6.4)
• Downloading Build Artifacts (6.5)
170
Managing Build Processes - Managing the global Build Environment
6.1 Managing the global Build Environment
Introduction
You can manage the global build environment (i.e. the configuration options,
which are generally available for all Build Processes).
Prerequisites: The Global Configuration Page is shown.

The Global Configuration Page opens, when clicking on
Global Config-
uration in the Build Management View.
• Managing the available Java/Maven Installations (6.1.1)
• Managing the available Maven Repositories (6.1.2)
• Managing the available Execution Servers (6.1.3)
• Activating the Mail Server (6.1.4)
171
6.1.1 Managing the available Java/Maven Installations
Introduction
You can manage the available Java/Maven installations on the Tab "JDK’s"/Tab
"Maven installations" of the Global Configuration Page.
• Adding an Installation (6.1.1.1)
• Changing the Name of an Installation (6.1.1.2)
• Changing the Home Directory of an Installation (6.1.1.3)
6.1.1.1 Adding an Installation
To add a Java/Maven installation, do the following:
► In the Tab "JDK’s"/Tab "Maven installations", click on
Add/
Add.
► Enter a name for the installation in the column Name.
► Enter the absolute path to the installation directory in the column Home
Directory.
► Click on Update.
→ The installation is added to the list.

You can delete an installation from the list by clicking on
in the rele-
vant line.
172
6.1.1.2 Changing the Name of an Installation
To change the name of a Java/Maven installation, do the following:
► In the Tab "JDK’s"/Tab "Maven installations", double-click on the relevant
field of the column Name.
→ The entry is editable.
► Edit the entry.
→ The name is changed.
6.1.1.3 Changing the Home Directory of an Installation
To change the home directory of a Java/Maven installation, do the following:
► In the Tab "JDK’s"/Tab "Maven installations", double-click on the relevant
field in the column Home directory.
→ The entry is editable.
► Edit the entry.
→ The home directory is changed.
173
6.1.2 Managing the available Maven Repositories
Introduction
You can manage the available Maven repositories on the Tab "Maven repositories" of the Global Configuration Page.
• Adding a Maven Repository (6.1.2.1)
• Changing the Name of a Maven Repository (6.1.2.2)
• Changing the URL of a Maven Repository (6.1.2.3)

You can delete a Repository from the list by clicking on
in the relevant
line.
6.1.2.1 Adding a Maven Repository
To add a Maven Repository, do the following:
► In the Tab "Maven repositories", click on
Add.
► Enter a name for the Repository in the column Name.
► Enter the URL of the Repository in the column URL.
→ The Repository is added on the list.
174
6.1.2.2 Changing the Name of a Maven Repository
To change the name of a Maven Repository, do the following:
► In the Tab "Maven repositories", double-click on the relevant field of the column Name.
→ The field turns into an editable field.
► Change the entry in the field.
6.1.2.3 Changing the URL of a Maven Repository
To change the URL of a Maven Repository, do the following:
► In the Tab "Maven repositories", double-click on the relevant field in the column URL.
→ The URL is changed.
175
6.1.3 Managing the available Execution Servers
Introduction
You can manage the available execution servers on the Tab "Execution servers"
of the Global Configuration Page.
• Adding an Execution Server (6.1.3.1)
• Changing the Name of an Execution Server (6.1.3.2)
• Changing the URL of an Execution Server (6.1.3.3)

You can delete an execution server from the list by clicking on
in the
relevant line.
6.1.3.1 Adding an Execution Server
To add an execution server, do the following:
► In the Tab "Execution servers", click on
Add.
► Enter a name for the execution server in the column Name.
► Enter the URL of the execution server in the column URL.
→ The execution server is added on the list.
176
6.1.3.2 Changing the Name of an Execution Server
To change the name of an execution server, do the following:
► In the Tab "Execution servers", double-click on the relevant field of the column Name.
6.1.3.3 Changing the URL of an Execution Server
To change the URL of an execution server, do the following:
► In the Tab "Execution servers", double-click on the relevant field in the column URL.
→ The URL is changed.
177
6.1.4 Activating the Mail Server
You can activate the mail server on the Tab "Mail server configuration" of the
Global Configuration Page.

Per default the mail server is deactivated. If activated, then for individual
Build Processes selected users can automatically be notified by an e-mail
whenever the relevant Build Process has been executed (see 6.3.1 Configuring the Environment for a Build Process).
To activate the mail server, do the following:
► Activate the check box Activate mail server.
→ The fields for the configuration are activated.
► In the field SMTP Server, specify the host of the SMTP server.
► In the field Systemadministrator E-mail Address, specify the entry to be written in the field Sender of an e-mail.
► If you want to enter an authentication to be automatically used for the SMTP
server, do the following:
• Activate the check box Use SMTP Authentication.
→ The fields Name and Password appear.
• In the field Name, enter a user name for the authentication.
• In the field Password, enter a password for the authentication.
► If you want the SSL protocol to be used, activate the check box Use SSL.
► In the field SMTP port, specify the port of the SMTP server, if necessary. Otherwise the default port is used, i.e. 25.
► In the field Charset, specify the character set to be used in an e-mail, if necessary. Otherwise the default character set is used, i.e. UTF-8.
► Click on Save.
178
Managing Build Processes - Creating a Build Process
6.2 Creating a Build Process
Introduction
You can create new Build Processes.
Prerequisites: The Build Management View is shown.
• Creating a Continuous Build Process (6.2.1)
• Creating a Release Build Process (6.2.2)
179
6.2.1 Creating a Continuous Build Process
You can create a new Continuous Build Process.
To create a Continuous Build Process, do the following:
► In the Build Management View, click on
New and select
Continuous
process.
→ The Build Process Environment Page opens.
► Configure the environment for the process.

For Configuring the Environment for a Build Process see 6.3.1.
→ The following page is displayed:
► In the drop-down field Repository, select the Repository including the projects to be built in the process.
► In the drop-down field Branch, select the Branch including the projects to be
built in the process.
→ The section Projects displays a list of all projects in the relevant Branch.
► Select the projects to be built in the process.

You can select all projects at once by activating the check box in the headline.
180
► Click on OK.
→ The Build Process is being created. When finished, the following message
appears:
► Click on OK.
181
6.2.2 Creating a Release Build Process
You can create a new Release Build Process.

It is recommended to create a new Branch for the new process (see 5.8
Creating a Branch in a Repository). This way, it will be possible select projects from separate Branches of the relevant Repository to be built in the
process.
To create a Release Build Process, do the following:
► In the Build Management View, click on
New and select
Release pro-
cess.
→ The Build Process Environment Page opens.
► Configure the environment for the process.

For Configuring the Environment for a Build Process see 6.3.1.
→ The following list is displayed:
► In the drop-down field Repository, select the Repository including the projects to be built in the process.
► If you do not want to create a new Branch, do the following:
• Select the option Existing.
• In the drop-down field Branch, select the Branch including the projects to
be built in the process.
182
► If you want to create a new Branch for the process, do the following:
• Select the option New.
• In the attached field, enter a name for the new Branch.
→ The section Projects displays a list of all projects in all Branches of the relevant Repository.

► Click on OK.
→ The Build Process is being created. When finished, the following message
appears:
► Click on OK.
183
Managing Build Processes - Configuring a Build Process
6.3 Configuring a Build Process
Introduction
You can configure Build Processes.
Here you can do the following:
• Configuring the Environment for a Build Process (6.3.1)
• Managing Access Rights for a Build Process (6.3.2)
• Specifying Projects to be built (6.3.3)
184
6.3.1 Configuring the Environment for a Build Process
Introduction
You can configure the environment for an individual Build Process.

For Managing the global Build Environment see 6.1.
To configure the environment for a Build Process, do the following:
► In the Overview Page, click on the Build Process.
→ The Build Process Monitoring Page is shown.
► Click on
Environment.
→ The Build Process Environment Page is shown.
• Specifying the Java Environment (6.3.1.1)
• Specifying the Maven Environment (6.3.1.2)
• Specifying, where Libraries are to be published (6.3.1.3)
• Specifying the executing User (6.3.1.4)
• Specifying Users to be notified (6.3.1.5)
• Specifying general Settings (6.3.1.6)
185
6.3.1.1 Specifying the Java Environment
You can specify the Java environment for a Build Process.
Prerequisites: The Build Process Environment Page is shown.
To specify the Java environment, do the following in the Section "Java":
► In the field JDK, select a JDK (Java Development Kit) to be used to create the
JVM (Java Virtual Machine), which executes the Build Process.
► In the field VM Arguments, enter VM (Virtual Machine) arguments, which
overwrite the default VM arguments of the respective JVM, if necessary.

In the field VM Arguments an entry is not necessarily required. If no entry
is given the default VM arguments of the JVM are used.
6.3.1.2 Specifying the Maven Environment
You can specify the Maven environment for a Build Process.
To specify the Maven environment, do the following in the Section "Maven":
► In the field Installation, select the Maven installation used to launch Maven.
► In the field Arguments, enter additional Maven arguments, if necessary.

186
In the field Arguments an entry is not necessarily required.
6.3.1.3 Specifying, where Libraries are to be published
You can specify, where the libraries resulting from a Build Process are to published, if necessary.
To specify where libraries are to be published, do the following:
► Activate the check box Publish library in.
→ The Section "Publish in" is shown.
► If you want the libraries to be published to a Maven Repository, select a
Maven Repository from the drop-down field Maven repository.
► If you want the libraries to be published to an execution server, select an
execution server from the drop-down field Execution Server.
6.3.1.4 Specifying the executing User
You can specify the executing user (i.e. the user, who is assumed to have started
a Build, whenever it was in fact started automatically) for an individual Build Process.
To specify the executing user, do the following in the Section "Execute as":
► In the field Username, enter the respective user name.
► In the field Password, enter the respective password.
187
6.3.1.5 Specifying Users to be notified
You can specify, which users are sent an e-mail notification whenever the relevant Build Process has been executed.

For E-mails to be actually sent the mail server must be activated (see
6.1.4 Activating the Mail Server).
To add users to be notified, do the following in the Section "Send E-mail notification after each build to":
► Click on Add recipient.
► Select the relevant users.
188
► Click on OK.
→ The users are added as e-mail recipients.

You can remove a user as an e-mail recipient by clicking on
.
189
6.3.1.6 Specifying general Settings
You can specify general settings for an individual Build Process.
To specify general settings, do the following in the Section "General Settings":
► In the field Maximum number of kept builds, specify how many Builds at
most you want to be kept in the build directory.

Amongst others, this number limits the number of Builds in the Build Process Monitoring Page.
► If you want a Build to be triggered automatically, do the following:
• Activate the check box Trigger build automatically.
• Specify a frequency in the attached fields.
• If you want a Build to be triggered only, if changes to the relevant Rule
Project have lately been published to the Visual Rules Team Server, then
also activate the check box Only after modification.

The field Additional build arguments is reserved for future use.
► If you want a script to be executed after a Build, select the relevant script in
the selection field Script to be executed afterwards.

The field Script to be executed afterwards provides those scripts which
have been added to the global build environment. For Adding a Script to
the global Build Environment see 2.8.2.
► If you want Rule Tests to be skipped in a Build (i.e. exclude the Stage "Test"
from the process), activate the check box Skip test executions.
190
6.3.2 Managing Access Rights for a Build Process
Introduction
You can manage Team Server Access Rights with respect to an individual Build
Process.
To manage access rights for a Build Process, do the following:
► In the Overview Page, click on the Build Process.
→ The Build Process Monitoring Page is shown.
► Click on
Permissions.
→ The Build Process Permissions Page is shown.
• Managing Access Rights for Users (6.3.2.1)
• Managing Permissions for Teams (6.3.2.2)
191
6.3.2.1 Managing Access Rights for Users
You can manage Team Server Access Rights with respect to a Build Process for
individual users.
Prerequisites: The Build Process Permissions Page is shown for the Build Process.
To manage access rights for users, do the following in the Section "Users with
Read permission":
► To assign Read permission to one or more users, do the following:
• Click on Add.
It shows all users registered in the Identity Management, who are cur-
192
rently not assigned any access rights with respect to the relevant Build
Process.
• Select the relevant users.
• Click on OK.
→ The users are added.
► To withdraw Read permission from a user, do the following
• Click on
• Click on OK.
→ The user is removed.
► To assign/withdraw Write permission to/from a user, activate/deactivate the
relevant check box in the column Write.
193
6.3.2.2 Managing Permissions for Teams
You can manage Team Server Access Rights with respect to a Build Process for
teams.
Prerequisites: The Build Process Permissions Page is shown for the Build Process.
To manage access rights for users, do the following in the section Section
"Teams with Read permission":
► To assign Read permission to one or more teams, do the following:
• Click on Add.
It shows all teams registered in the Identity Management, who are cur-
194
rently not assigned any access rights with respect to the relevant Build
Process.
• Select the relevant teams.
• Click on OK.
→ The teams are added.
► To withdraw Read permission from a team, do the following
• Click on
• Click on OK.
→ The team is removed from the Section "Users with Read permission".
► To assign/withdraw Write permission to/from a team, activate/deactivate
the relevant check box in the column Write.
195
6.3.3 Specifying Projects to be built
To specify the projects to be built in a Build Process, do the following:
► On the related Build Process Monitoring Page. click on
Projects.
→ The following page is displayed:
► In the drop-down field Repository, select the Repository including the relevant projects.
► In the drop-down field Branch, select the Branch including the relevant projects.
→ The section Projects displays a list a list of all projects in the relevant
Branch.

196
► If you want an executable library to be created from a project, do the following in the relevant line:
• Activate the check box create with entry model.
• In the attached field, select a Rule Model, for which the web services
should be accessible via the Visual Rules Execution Server, if necessary.

An entry in this field is not required, if there is only one Rule Model in the
relevant project (which is the most common case).
• If you want the project to be deployed to the Visual Rules Execution
Server, activate the corresponding check box.
► Click on OK.
→ The following message appears:
► Click on OK.
197
Managing Build Processes - Manually triggering a Build Process
6.4 Manually triggering a Build Process
Introduction
You can manually trigger a Build, i.e. execute a Build Process.
• Manually Triggering a Continuous Build (6.4.1)
• Manually Triggering a Release Build (6.4.2)

The number of parallel executions of Build Processes is restricted. Hence
a triggered process is not necessarily executed immediately. If necessary,
it is held in the Section "Build process executions". For Specifying the
maximum Number of Build Slots see 2.8.1.9.
Once it is triggered, you can cancel the Build Process by clicking on
in
the Section "Builds".
Once the execution of the Build Process is started, its current status is
shown in the Section "Current status/Console output".
198
6.4.1 Manually Triggering a Continuous Build
You can manually trigger a Continuous Build on the related Build Process Monitoring Page or on the Overview Page.
To manually trigger a Continuous Build, do the following:
► Depending on which page is shown, click on one of the following buttons:
• On the Build Process Monitoring Page:
Build
• In the relevant line of the Overview Page:
► Click on OK.
199
6.4.2 Manually Triggering a Release Build
You can manually trigger a Release Build on the related Build Process Monitoring Page.
To manually trigger a Release Build, do the following:
► Click on
Perform release.
→ The following page appears:
It shows the projects to be built as well as the related version numbers in
each case, i.e. both for the upcoming release of the relevant project (column
Release version) and after the upcoming release (column Subsequent version).
► If you want to change a project version, do the following:
• Double-click in the relevant line.
• Edit the version numbers.
• Click on Update.
► Click on Trigger.
► Click on Ok.
200
Managing Build Processes - Downloading Build Artifacts
6.5 Downloading Build Artifacts
You can download the Build Artifacts of a Build Process in the Section "Build artifacts" of the Build Details Page.

The Build Details Page opens for a Build, when clicking on that Build in
the Build Process Monitoring Page.
To download a Build Artifact, do the following:
► Click on the Build Artifact.
→ A dialog appears that allows you to download the Build Artifact.
201
Managing Build Processes - Downloading Build Artifacts
202
7. Maintaining the
Team Server
Maintaining the Team Server -
Introduction
Maintaining the Team Server includes the following tasks:
• Managing Licenses (7.1)
• Showing System Information (7.2)
• Showing the Log File (7.3)
• Creating/restoring a Backup (7.4)
204
Maintaining the Team Server - Managing Licenses
7.1 Managing Licenses
You can manage (i.e. add or delete) licenses for your Visual Rules Team Server.
Prerequisites: The Maintenance View is shown.
To manage licenses for your Team Server, do the following:
► Click on
License Management.
→ The License Management Page opens.
► To add a license, do the following:
• On the License Management Page, click on Add License.
• Click on Browse and select a license file from your file system.
• Click on Add.
• Click on OK.
205
Maintaining the Team Server - Managing Licenses
► To delete a license, do the following:
• Click on
in front of the license.
• Click on Yes.
206
Maintaining the Team Server - Showing System Information
7.2 Showing System Information
You can show system information about the system on which your Team Server
is running.
To show system information, do the following:
► Click on
System Information.
→ The System Information Page opens.
7.3 Showing the Log File
You can show the log file for your Team Server.
To show the log file, do the following:
► Click on
Logging.
→ The Logging Page opens showing the log file. Here you can do the following:
• Change the detail level of the displayed logs with the slider on the left.
• Download the log file by clicking on

Download log file.
For setting the detail level you need the user permission Configure logging.
As a high detail level affects the performance of your system, detail level
1 is recommended for regular use.
207
Maintaining the Team Server - Creating/restoring a Backup
7.4 Creating/restoring a Backup
gesamter Abschnitt wurde in der eutschen Version überarbeitet, anschließend
hier anpassen
Introduction
You can create/restore a backup of the current database of your Team Server.
The Team Server data are held both in the file system and in the database. The
file system stores indices, configurations and work spaces of the individual
Build Processes, while the database stores all business-relevant data (e.g.
repositories, business rules and rule projects).
Both the data in the database and those in the file system are held tenant-specifically and need to be stored for each tenant individually. The data in the file
system are not necessarily needed for a data backup and can be restored
through a new configuration of the Team Server.
Accordingly, you have the following possibilities to create/restore a backup:
• Creating/restoring a complete Backup (7.4.1)
• Creating/restoring a tenant-specific Backup (7.4.2)

To avoid inconsistencies, it is recommended not to create/restore a
backup for the data in the file system, while the Team Server is running.
208
7.4.1 Creating/restoring a complete Backup
You can create/restore a complete backup.
To create a complete backup, do the following:
► If you want to include the data in the file system, stop the Team Server.

Stopping the Team Server is not necessary, if you only want to save the
data in the database.
► Save all data in the database, which are stored in the global database
schema.
► Save all data in the database, which are stored in the database schemas of
the individual tenants.

See the documentation for your database vendor on how to use the vendor-specific database backup tool.
► If necessary, save all data in the file system in ${VR_TEAMSERVER_HOME}.
► Restart the Team Server.
→ All relevant data are saved.
To restore the data, do the following:
► Stop the Team Server.
► Restore the data in the file system.
► Restore all saved database schemas, starting with the global schema, using
the native database tools.
→ The data are restored.
209
7.4.2 Creating/restoring a tenant-specific Backup
You can create/restore a backup for an individual tenant.
To create a tenant-specific backup, do the following:
► If you want to include the data in the file system, stop the Team Server.

Stopping the Team Server is not necessary, if you only want to save the
data in the database.
► Save all data in the database, which are stored in the tenant-specific database schema, using the native database tools.

The mapping between the tenant name and the database schema can be
found in the database tables TENANT_SCHEMA and TENANT_BINDING.
► If desired, save all data in the file system in ${VR_TEAMSERVER_HOME}/
data/${TENANT_SCHEMA}.
→ All relevant data are saved.
To restore the data, do the following:
► Stop the Team Server.
► Restore all saved database schemas of the relevant tenant, using the native
database tools.
► If necessary, restore the data in the file system in
${VR_TEAMSERVER_HOME}/data/${TENANT_SCHEMA}.
→ The data are restored.
210
Index
Index
Index
Continuous Build . . . . . . . . . . . . . . . . . . 86
A
Architecture (Software Architecture) . . 15
Artifact (Build Artifact) . . . . . . . . . . . . . . 85
M
Maintenance . . . . . . . . . . . . . . . . . . . . 203
Maintenance Tool . . . . . . . . . . . . . . . . . 19
Maintenance View . . . . . . . . . . . . . . . . 134
Maven Repository . . . . . . . . . . . . . . . . . 85
B
Backend . . . . . . . . . . . . . . . . . . . . . . . . . 18
Configuring the Backend . . . . . . . . . 68
Configuring the Environment for the
Backend . . . . . . . . . . . . . . . . . . . . 69
Branch . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Adding Projects to a Branch . . . . . . 165
Creating a Copy of a Branch . . . . . 156
Creating a new Branch . . . . . . . . . . 155
Deleting a Branch . . . . . . . . . . . . . . 167
Managing Access Rights for a Branch
168
Renaming a Branch . . . . . . . . . . . . 163
Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Build Artifact . . . . . . . . . . . . . . . . . . . 85
Continuous Build . . . . . . . . . . . . . . . 86
Release Build . . . . . . . . . . . . . . . . . . 86
Build Artifact . . . . . . . . . . . . . . . . . . . . . 85
Rule Library . . . . . . . . . . . . . . . . . . . . 85
Build Management View . . . . . . . . . . . . 99
Build Details Page . . . . . . . . . . . . . 126
Build Process Environment Page . 111
Build Process Monitoring Page . . . 120
Build Process Permissions Page . . 117
Global Configuration Page . . . . . . . 104
Build Process . . . . . . . . . . . . . . . . . . . . . 81
Configuring a Build Process . . . . . . 184
Configuring the Environment . . . . . 185
Creating a Build Process . . . . . . . . 179
Managing Build Processes . . . . . . . 169
Process Stages . . . . . . . . . . . . . . . . . 82
Specifying projects to be built . . . . 196
C
Configuration . . . . . . . . . . . . . . . . . . . . . 67
Configuring the Backend . . . . . . . . . 68
Configuring the Environment for the
Backend . . . . . . . . . . . . . . . . . . . . 69
Configuring the global Build Environment . . . . . . . . . . . . . . . . . . . . . . 171
212
P
Process Stages . . . . . . . . . . . . . . . . . . . 82
"Clean up" . . . . . . . . . . . . . . . . . . . . . 84
"Clean" . . . . . . . . . . . . . . . . . . . . . . . . 83
"Compile" . . . . . . . . . . . . . . . . . . . . . . 83
"Distribute" . . . . . . . . . . . . . . . . . . . . 84
"Generate" . . . . . . . . . . . . . . . . . . . . . 83
"Prepare" . . . . . . . . . . . . . . . . . . . . . . 83
"Test" . . . . . . . . . . . . . . . . . . . . . . . . . 84
"Validate" . . . . . . . . . . . . . . . . . . . . . . 83
Project
Adding a Project to a Branch . . . . . 166
R
Range of Application . . . . . . . . . . . . . . . 13
Release Build . . . . . . . . . . . . . . . . . . . . 86
Repository . . . . . . . . . . . . . . . . . . . . . . . 79
Branch . . . . . . . . . . . . . . . . . . . . . . . . 79
Creating a Branch in a Repository 154
Creating a Repository . . . . . . . . . . . 153
Deleting a Repository . . . . . . . . . . . 167
Managing Access Rights for a Repository . . . . . . . . . . . . . . . . . . . . . . . . . 168
Managing Repositories . . . . . . . . . 141
Repository Management . . . . . . . . . . 141
Repository Management View . . . . . . . 89
Resource . . . . . . . . . . . . . . . . . . . . . . . . 80
Deleting a Resource . . . . . . . . . . . . 167
Locking a Resource . . . . . . . . . . . . 152
Managing Access Rights for a Resource
. . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Unlocking a Resource . . . . . . . . . . 152
Rights Concept . . . . . . . . . . . . . . . . . . . 28
Rule
Creating a Rule . . . . . . . . . . . . . . . . 161
Rule Library . . . . . . . . . . . . . . . . . . . . . . 85
Rule Project
Creating a Rule Project . . . . . . . . . 157
Index
S
Scope of Delivery . . . . . . . . . . . . . . . . . .
Software Architecture . . . . . . . . . . . . . .
Stage "Clean up" . . . . . . . . . . . . . . . . . .
Stage "Clean" . . . . . . . . . . . . . . . . . . . . .
Stage "Compile" . . . . . . . . . . . . . . . . . . .
Stage "Distribute" . . . . . . . . . . . . . . . . .
Stage "Generate" . . . . . . . . . . . . . . . . . .
Stage "Prepare" . . . . . . . . . . . . . . . . . . .
Stage "Test" . . . . . . . . . . . . . . . . . . . . . .
Stage "Validate" . . . . . . . . . . . . . . . . . . .
17
15
84
83
83
84
83
83
84
83
T
Team Server
Backend . . . . . . . . . . . . . . . . . . . . . . 18
Configuration . . . . . . . . . . . . . . . . . . 67
Maintenance . . . . . . . . . . . . . . . . . . 203
Maintenance Tool . . . . . . . . . . . . . . . 19
Range of Application . . . . . . . . . . . . 13
Rights Concept . . . . . . . . . . . . . . . . . 28
Scope of Delivery . . . . . . . . . . . . . . . 17
Software Architecture . . . . . . . . . . . . 15
User Guides . . . . . . . . . . . . . . . . . . . . 27
Web Console . . . . . . . . . . . . . . . . . . . 19
Test Coverage . . . . . . . . . . . . . . . . . . . . 86
U
User Guides . . . . . . . . . . . . . . . . . . . . . . 27
User Interface . . . . . . . . . . . . . . . . . . . . 87
Build Management View . . . . . . . . . 99
Maintenance View . . . . . . . . . . . . . 134
Repository Management View . . . . . 89
V
Views
Build Management . . . . . . . . . . . . . . 99
Maintenance . . . . . . . . . . . . . . . . . . 134
Repository Management . . . . . . . . . 89
W
Web Console . . . . . . . . . . . . . . . . . . . . . 19
213

Team Server User Guide - Bosch Software Innovations

Transcription

Similar documents

Nonwood Declaration - Amptown Cases GmbH

EUROPLAST – NYCAST GmbH Emergency

Picturing family matters

On this date in history: Aug. 13 MEET THE TEAM

AIM2Flourish - Weatherhead School of Management

AC SAR - RWTH Aachen University

April 20, 1995 - The Repository

CJ960 - Bosch

Whether construction material, protective material