interstage application and service management v10 -...

Interstage Application and Service Management V10.0

Administration Guide

B1WD-2521-01ENZ0(00) October 2008

Interstage ASM Administration Guide 2

Trademarks Interstage and Enabler are trademarks of Fujitsu Limited in Japan and/or other countries.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

UNIX is a registered trademark of the Open Group in the United States and in other countries.

Linux is a registered trademark of Linus Torvalds.

Other company names and product names are trademarks or registered trademarks of their respective owners.

Copyright © FUJITSU LIMITED 2008

All rights reserved, including those of translation into other languages. No part of this manual may be reproduced in any form whatsoever without the written permission of Fujitsu Limited.

[High Risk Activity]

The Customer acknowledges and agrees that the Product is designed, developed and manufactured as contemplated for general use, including without limitation, general office use, personal use, household use, and ordinary industrial use, but is not designed, developed and manufactured as contemplated for use accompanying fatal risks or dangers that, unless extremely high safety is secured, could lead directly to death, personal injury, severe physical damage or other loss (hereinafter "High Safety Required Use"), including without limitation, nuclear reaction control in nuclear facility, aircraft flight control, air traffic control, mass transport control, medical life support system, missile launch control in weapon system. The Customer shall not use the Product without securing the sufficient safety required for the High Safety Required Use. In addition, Fujitsu (or other affiliate's name) shall not be liable against the Customer and/or any third party for any claims or damages arising in connection with the High Safety Required Use of the Product.


Contents

1 Introduction....................................................................... 12

1.1 Administration in Interstage ASM .......................................................13

1.2 Users in Interstage ASM.......................................................................13

1.3 Architecture and Interfaces .................................................................14

1.4 Usage and Installation Scenarios........................................................16

1.5 General Operation Prerequisites.........................................................17

2 Enabler Server Administration ........................................ 18

2.1 Installing an Enabler Server.................................................................18

2.2 Starting and Stopping an Enabler Server...........................................19

2.3 Configuring User Authentication ........................................................20

2.4 Administering Users and User Groups ..............................................21

2.5 Backing up and Restoring Enabler Data ............................................22

3 Repository Administration............................................... 23

3.1 Distribution of Data to Repositories ...................................................23

3.2 Resource Requirements.......................................................................24

3.3 Creating Repositories...........................................................................24

3.4 Datastore Parameters...........................................................................26

3.5 Repository Settings ..............................................................................27 3.5.1 General Settings .....................................................................................27 3.5.2 Mail Settings............................................................................................29 3.5.3 Search Settings.......................................................................................29

3.6 Starting and Stopping Repositories....................................................30

3.7 Backing up and Restoring Repositories ............................................30 3.7.1 Backup and Restore of Multiple Repositories.........................................31 3.7.2 Client Access and Synchronization After Repository Restore................31


3.8 Checking and Reorganizing Datastores.............................................32

3.9 Handling Log Files................................................................................32

3.10 Maintaining the Data Model of Repositories ......................................33

3.11 Deleting Repositories ...........................................................................34

4 SCA Server Administration.............................................. 35


4.2 Installing and Running an SCA Server ...............................................36

4.3 Setting Scan Source Directories .........................................................37

4.4 Backing up and Restoring SCA Data..................................................37

4.5 Scheduling Source Code Scans..........................................................38

4.6 Scheduling QAM Measurements.........................................................39

5 Search Server Administration.......................................... 40


5.2 Installing and Running a Search Server.............................................41

5.3 Creating and Maintaining Search Indices ..........................................42 5.3.1 Creating and Updating Search Indices ...................................................42 5.3.2 Optimizing Search Indices ......................................................................44 5.3.3 Deleting Search Index Entries and Indices.............................................44 5.3.4 esindex....................................................................................................44

5.4 Backing up and Restoring Search Indices.........................................45

6 Web/Application Server Administration ......................... 46

6.1 Overview of the Interstage ASM Web Applications...........................46

6.2 Context Names and URLs ....................................................................47

6.3 Installing and Deploying Web Applications .......................................48 6.3.1 Deploying with Interstage Application Server .........................................50 6.3.2 Deploying with Apache Tomcat ..............................................................50

6.4 Configuring SSL Access ......................................................................51 6.4.1 Configuring SSL Access in Interstage Application Server......................51 6.4.2 Configuring SSL Access in Apache Tomcat ...........................................52


6.4.3 Configuring Interstage ASM Clients for SSL Access..............................52

6.5 Setting the Language for the Web Applications................................54

6.6 Configuring Web Applications ............................................................54 6.6.1 Overview of Configuration Settings.........................................................54 6.6.2 Configuring the SCM Web Interface .......................................................56

7 CentraSite Administration................................................ 57

7.1 Installing and Deploying the Web Applications.................................57

7.2 Basic CentraSite Settings ....................................................................58

7.3 Executing CentraSite Administration Functions ...............................60

7.4 Creating a CentraSite Registry and Repository.................................61

7.5 Administering the Registry and Repository.......................................62

7.6 Administering the CentraSite Password Store ..................................62

7.7 Enabling Change Notifications............................................................63

7.8 Configuring the UDDI Interface ...........................................................64

7.9 Setting up Registry Federations..........................................................66

8 WebDAV Interface Configuration .................................... 69

8.1 Installing and Deploying the WebDAV Interface................................69

8.2 General Configuration of the WebDAV Interface...............................69

8.3 Defining WebDAV Shares ....................................................................70 8.3.1 Defining a WebDAV Share for CentraSite ..............................................70 8.3.2 Defining WebDAV Shares for SCM Configurations ................................72

8.4 Working with WebDAV Shares ............................................................74

8.5 Deleting WebDAV Shares.....................................................................74

9 Interstage BPM Integration .............................................. 75

9.1 Installing the LCM/BPM Integration Software ....................................75

9.2 Integrating LCM Definitions and Libraries in BPM............................76

9.3 Deploying the LCM/BPM Integration Web Application .....................77


9.4 Maintaining Host Names, User IDs and Passwords..........................78

10 Bugzilla Integration........................................................... 79

10.1 Mapping of Bugzilla Actions and Data to LCM ..................................79

10.2 Preparations ..........................................................................................81

10.3 Configuring Applications and Services for Bugzilla .........................81 10.3.1 Specifying Connection Data....................................................................81 10.3.2 Mapping Products, Components, Versions, and Milestones ..................82 10.3.3 Specifying Email Addresses for Users....................................................82

10.4 Synchronizing Change Requests with Bugzilla.................................83

10.5 Customizing the Bugzilla Integration..................................................83

11 Client Administration........................................................ 84

11.1 Client Interface ......................................................................................84 11.1.1 Installing the Client Interface...................................................................84 11.1.2 Configuring the Client Interface ..............................................................85

11.2 Command Line Interface ......................................................................87 11.2.1 Installing the Command Line Interface ...................................................87 11.2.2 Configuring the Command Line Interface ...............................................88

12 General Administration Tasks ......................................... 90

12.1 Changing the Password of asmuser...................................................90

12.2 Changing Ports of Server Components .............................................91

13 Commands of the Command Line Interface ................... 92

13.1 Using the Command Line Interface.....................................................92

13.2 esca scan – Scan Source Code...........................................................94

13.3 esca disassemblejar – Disassemble Java Archives..........................95

13.4 eqam collect – Create QAM Measurement .........................................96

13.5 esindex – Create/Maintain Search Index ............................................98

13.6 elcmbug – Synchronize LCM with Bugzilla........................................100


14 Troubleshooting................................................................ 102

14.1 Repository List Incomplete..................................................................102

14.2 Insufficient Memory Errors ..................................................................102

Appendix: Interstage ASM Eclipse Plug-ins.................................... 104

Glossary ............................................................................................. 107


About this Manual This manual describes the administration of the Fujitsu Interstage Application and Service Management suite – hereafter referred to as Interstage ASM.

The manual is structured as follows:

Title Description

Chapter 1 Introduction Provides an introduction to the administration of Interstage ASM and gives an overview of the Interstage ASM users, architecture, interfaces, usage and installation scenarios.

Chapter 2 Enabler Server Administration

Describes administrative tasks related to the Enabler servers where Interstage ASM repositories are located.

Chapter 3 Repository Administration

Describes concepts and administrative tasks related to Interstage ASM repositories.

Chapter 4 SCA Server Administration

Describes the administration of SCA servers, where scanning of source code takes place and SCA cubes are maintained.

Chapter 5 Search Server Administration

Describes the administration of Interstage ASM search servers, where search indices for repositories are created and maintained.

Chapter 6 Web/Application Server Administration

Describes the installation and deployment of the Interstage ASM Web applications as well as administrative tasks related to Web/application servers.

Chapter 7 CentraSite Administration

Describes the configuration and administration of the CentraSite Web applications, registries and repositories.

Chapter 8 WebDAV Interface Configuration

Describes the deployment of the WebDAV interface and the definition and usage of WebDAV shares in CentraSite and SCM.

Chapter 9 Interstage BPM Integration

Describes the installation and setup of the LCM definitions, libraries and Web applications required for the integration of Interstage BPM processes.

Chapter 10

Bugzilla Integration

Describes concepts and administrative tasks related to the integration of Bugzilla into Interstage ASM.


Chapter 11

Client Administration

Describes the installation and configuration of the Interstage ASM client interface and command line interface.

Chapter 12

General Administration Tasks

Describes administrative tasks that relate to Interstage ASM as a whole.

Chapter 13

Commands of the Command Line Interface

Describes commands of the Interstage ASM command line interface which are important for executing the tasks described in this manual.

Chapter 14

Troubleshooting Provides information on problems you may encounter in Interstage ASM operation, and describes appropriate solutions.

Appendix Interstage ASM Eclipse Plug-ins

Provides an overview of the Eclipse plug-ins that make up the Interstage ASM client interface and its documentation.

Readers of this Manual This manual is directed to system administrators who are responsible for preparing and maintaining Interstage ASM for the end users.

Basic knowledge of the following is required:

• Interstage ASM concepts.

• Administration of the operating systems in use.

• Java.

• Web server and application server administration.

Notational Conventions This manual uses the following notational conventions:

Add The names of graphical user interface elements like menu options are shown in bold case.

init System names, for example, command names, and text that is entered from the keyboard are shown in Courier font.

<variable> Variables for which values must be entered are enclosed in angle brackets.

[option] Optional items, for example, optional command parameters, are enclosed in square brackets.

one | two Alternative entries are separated by a vertical bar.


Abbreviations This manual uses the following abbreviations for Interstage products and components:

Interstage ASM Interstage Application and Service Management suite

Interstage BPM Interstage Business Process Manager

Interstage ADM Interstage Application Development Cycle Manager product of Interstage ASM

Interstage SQA Interstage Software Quality Analyzer product of Interstage ASM

CHM Change Management component of Interstage ASM

COC Control Center component of Interstage ASM

DMS Document Management component of Interstage ASM

LCM Lifecycle management components (CHM, RLM, RQM) of Interstage ASM

QAM Quality Assessment component of Interstage ASM

RLM Release Management component of Interstage ASM

RQM Requirements Management component of Interstage ASM

SCA Source Code Analysis component of Interstage ASM

SCM Software Configuration Management component of Interstage ASM

The term "Windows" is used to denote the different Microsoft Windows operating systems supported by Interstage ASM.

Related Documentation Apart from this manual, the following documentation on Interstage ASM is available:

• Interstage ASM Overview: A PDF manual introducing Interstage ASM and describing its main features and basic concepts.

• Interstage ADM Installation Instructions: A PDF manual describing the installation and uninstallation of Interstage ADM.

• Interstage SQA Installation Instructions: A PDF manual describing the installation and uninstallation of Interstage SQA.

• CentraSite Installation Instructions: A PDF manual describing the installation and uninstallation of CentraSite.

• Interstage ADM Lifecycle Management User Guide: An online manual describing how to work with the lifecycle management (LCM) components of Interstage ASM from the client interface.


• Interstage ADM Software Configuration Management User Guide: An online manual describing how to work with the Software Configuration Management (SCM) component of Interstage ASM from the client interface.

• Interstage ADM Document Management User Guide: An online manual describing how to work with the Document Management (DMS) component of Interstage ASM from the client interface.

• Interstage SQA Source Code Analysis User Guide: An online manual describing how to work with the Source Code Analysis (SCA) component of Interstage ASM from the client interface.

• Interstage SQA Quality Assessment User Guide: An online manual describing how to work with the Quality Assessment (QAM) component of Interstage ASM from the client interface.

• CentraSite User Guide: An online manual describing how to work with the SOA Asset Management (CentraSite) component of Interstage ASM from the client interface.

• Interstage ASM Control Center User Guide: An online manual describing how to work with the Control Center (COC) component of Interstage ASM from the client interface.

• Interstage ASM Customization Guide: A PDF manual describing how to extend, localize and customize Interstage ASM.

• Interstage ADM Software Configuration Management Migration Guide: A PDF manual describing how to migrate projects from other source code management systems to the SCM component of Interstage ASM.

• Interstage ADM Command Line Interface: A PDF manual describing the Interstage ADM command line interface.

Additionally, the following documents of Fujitsu Enabler are of relevance:

• Enabler Administration: A PDF manual describing the administration of Enabler servers and repositories.

• Enabler WebDAV Interface: A PDF manual describing how to set up the working environment for accessing files managed in a repository using WebDAV clients.


1 Introduction Interstage Application and Service Management (Interstage ASM) is a suite of products, components and tools that support you in managing the services, software products and applications of your company. Interstage ASM covers the entire lifecycle of services and applications, ranging from requirements and change management through software development, maintenance, and quality assessment to release and asset management.

With its features, Interstage ASM helps you control your development processes, improve the quality of your software, reduce development and maintenance costs, comply with regulatory acts and govern your company's services and applications. Repository-based technology and a wide range of interfaces make Interstage ASM very scalable, reliable, flexible and customizable.

Interstage ASM consists of the following products and components. The white boxes show the products, the dark grey boxes the components they consist of:

CentraSiteCentraSite

Interstage SQAInterstage SQA

Software and DocumentationManagement

QualityAssessment

(QAM)

QualityAssessment

(QAM)

Source CodeAnalysis

(SCA)

Source CodeAnalysis

(SCA)

SOA AssetManagement(CentraSite)

SOA AssetManagement(CentraSite)

Common Components (Enabler Repository, Control Center (COC))Common Components (Enabler Repository, Control Center (COC))

DocumentManagement

(DMS)

DocumentManagement

(DMS)

SoftwareConfigurationManagement

(SCM)

SoftwareConfigurationManagement

(SCM)

Lifecycle Management Analysis and Assessment

Interstage ADM

RequirementsManagement

(RQM)


(RQM)

ReleaseManagement

(RLM)

ReleaseManagement

(RLM)

ChangeManagement

(CHM)

ChangeManagement

(CHM)


(RQM)


(RQM)

ReleaseManagement

(RLM)

ReleaseManagement

(RLM)

ChangeManagement

(CHM)

ChangeManagement

(CHM)


1.1 Administration in Interstage ASM As a system administrator, you are responsible for installing Interstage ASM and for preparing and maintaining the working environment for the end users. You make modifications to the system environment and manage the operation of all system components involved.

Administration in Interstage ASM includes the following tasks:

• Creating and maintaining repositories, and configuring and administering the Enabler servers on which the repositories are located.

• Administering SCA servers where scanning of source code takes place and SCA cubes are maintained.

• Creating and maintaining search indices for repositories, and administering the search servers where the indices are located.

• Deploying and configuring the Interstage ASM Web applications.

• Installing, configuring and administering Interstage ASM clients.

• Integrating Bugzilla and Interstage BPM with Interstage ASM.

The following tools and interfaces are available to perform these tasks:

• For carrying out Interstage ASM specific administration tasks, you can use the Interstage ASM client interface or command line interface.

• Specific CentraSite administration functions can be carried out in a Web browser.

• For user and repository administration, you can use the Enabler tools or command line interface.

• For specific tasks like starting and stopping services, standard tools of the underlying operating system are used.

1.2 Users in Interstage ASM Basically, any users who have access to the Interstage ASM servers and clients can work with the Interstage ASM components. These are typically users who have real user accounts in your environment. The users are authenticated when they access a repository and its data. The sophisticated access concept of Interstage ASM allows you to define exactly which data each authenticated user can access and which actions the user can carry out. For details on user authentication and recommendations related to user administration, refer to Section 2.3 and 2.4.

In addition to the real users working with Interstage ASM, you will be dealing with the Interstage ASM system user, asmuser. Interstage ASM uses asmuser for inter-repository and inter-system communication. asmuser does not have a real user account in any operating system, but it has a password (specified at server installation time) and can be authenticated with each repository.


asmuser is an administrator of all repositories and thus has full access rights to them. Its user ID and password are also registered with some of the server and Web components of Interstage ASM.

1.3 Architecture and Interfaces The following illustration provides an overview of the Interstage ASM architecture and interfaces:

ClientInterfaceClient

Interface

Functionality and Java API

RQMRQM

SCAServerSCA

Server

CHMCHM RLMRLM SCMSCM DMSDMS SCASCA QAMQAM COCCOCCentraSite

CentraSite

SearchServer

SearchServer

CommandLine

Interface

CommandLine

InterfaceWeb

InterfaceWeb

InterfaceWebDAVInterfaceWebDAVInterface

UDDIInterface

UDDIInterface

The functionality of Interstage ASM is implemented in Java and exposed at the Java API.

The Interstage ASM components store their data in Enabler repositories, which are located on one or more Enabler servers.

For scanning source code and obtaining the required analysis data, SCA uses a high-performance code analyzer based on OLAP (Online Analytical Processing) technology. This is referred to as the SCA server.

SCM and DMS provide full text search which is based on search indices. These indices are created and maintained on one or more search servers.


The users of Interstage ASM can work with the following interfaces:

• Client interface The client interface is a graphical user interface that offers the complete Interstage ASM functionality. The client interface is based on Eclipse technology and implemented as Eclipse plug-ins. As such, it can be installed and operated in the following ways: Stand-alone variant: The stand-alone variant is based on the Eclipse RCP (rich client platform) technology. It includes the Eclipse plug-ins of the Interstage ASM components you have installed as well as all features of the Eclipse Workbench required to operate them. This means there is no need to separately install Eclipse. The stand-alone variant of the client interface is the main interface for all Interstage ASM users and components. Existing Eclipse environment: You can install and use the plug-ins of the Interstage ASM components within an existing Eclipse environment. This is particularly suitable for SCM: If you use Eclipse for software development, the SCM functionality can be integrated seamlessly with it. In a similar way, you can add the analysis features of SCA or CentraSite to your development environment.

• Command line interface The command line interface consists of batch files for Windows and shell scripts for UNIX/Linux. It offers the complete SCM functionality as well as basic functionality of other components. You can use the command line interface for batch processing (e.g. create builds in SCM or perform regular source code scans in SCA) as well as for integrating Interstage ASM functionality into third-party tools and solutions without the need for programming.

• Web interface SCM and DMS offer a Web interface in addition to the client interface. The Web interface is servlet-based and allows for performing specific SCM and DMS activities from a Web browser.

• WebDAV interface The WebDAV interface is made available by the Enabler WebDAV services and used in SCM and CentraSite. The Enabler WebDAV services provide folder/file views of the data stored in a repository. Via WebDAV shares, the folders and files can be accessed from any WebDAV-compatible client (e.g. Microsoft Internet Explorer or Microsoft Office) in any Internet location. In SCM, you can define a WebDAV share for each protected configuration and access the folders and files in read-only mode. CentraSite uses WebDAV shares to provide its repository functionality.

• UDDI interface In addition to its JAXR-compliant Java API, CentraSite offers a UDDI (Universal Description, Discovery and Integration) interface, which allows you to integrate it in your SOA environment and use it like any standard UDDI registry. The UDDI interface can be deployed as a Web application on any Web/application server of your choice.


1.4 Usage and Installation Scenarios Interstage ASM is implemented as a three-tier application involving clients, Web/application servers and the Interstage ASM server components. SCM and DMS support a pure client/server scenario in addition.

The following illustration provides an overview of the installation and usage scenarios:

Clientinterface

Command line interface

Interstage ASM functionality and API

Interstage ASM client

Clientinterface

Command line interface


Interstage ASM client

Enabler server

Repository

LAN TCP/IP

SCA server

Web client


Web/application server

Interstage ASM Web applications(remote interface)

HTTP / HTTPS

HTTP / HTTPS Firewall

Search server

TCP/IP

WebDAVinterface

WebDAVclient

TCP/IPUDDI

interface

TCP/IP TCP/IP

TCP/IP


Users can work with the Interstage ASM components and interfaces in the following way:

• Client and command line interfaces: Users work from Interstage ASM clients, where the client and/or command line interface including all the Interstage ASM client functionality are installed. The clients access the repositories and Interstage ASM servers by HTTP or HTTPS via a Web/application server where the Interstage ASM Web applications are installed. The Web applications include the Interstage ASM API and functionality. They forward requests and data to the repositories and server components and return the responses to the clients. The Web applications are also referred to as the remote interface of Interstage ASM. SCM and DMS users can also work directly with repositories from their clients by TCP/IP without using the remote interface. The same is true for access to SCA servers when carrying out analyses. CentraSite users access repositories from the client interface both directly by TCP/IP and via the WebDAV interface, which runs on a Web/application server. On the same or a different Web/application server, the CentraSite UDDI interface may be deployed.

• Web interface of SCM and DMS: Users can work from any Web browser. They connect to the repositories via HTTP or HTTPS and a Web/application server where the Interstage ASM Web applications are installed.

• WebDAV interface: Users can access CentraSite repositories and protected configurations of SCM from any WebDAV client via the WebDAV interface.

1.5 General Operation Prerequisites The following general prerequisites must be fulfilled for operating Interstage ASM:

• The machines where the following Interstage ASM components are installed must be in the same LAN, and direct connection between them must be possible via TCP/IP without any firewall between them: Enabler servers, SCA servers, search servers, Web/application servers where the Interstage ASM Web applications are installed. Interstage ASM clients from which you work with CentraSite must also be in this same LAN.

• For the Interstage ASM client interface, at least version 5.0 of the Sun J2SE Runtime Environment (JRE) or Sun J2SE Development Kit (JDK) must be available. For the other components and interfaces of Interstage ASM, at least version 1.4.2 is required. The Interstage ASM client and server installers for Windows install an appropriate JRE to the jre subdirectory of the Interstage ASM installation directory. This is used by default by the stand-alone variant of the Interstage ASM client interface and by the server components. It is also used by the command line interface if no different JRE/JDK is found by the setting of the JAVA_HOME environment variable. If you are using a JRE/JDK other than Sun’s, it must be fully compatible with the Sun JRE/JDK and provide the same functionality (e.g. JAAS, JSSE). This is not the case, for example, for the IBM JRE or the JRE that comes with Red Hat Enterprise Linux. In such a case, it may help to add the rt.jar of the Sun JRE/JDK to your own JRE/JDK and include it in the CLASSPATH.


2 Enabler Server Administration Interstage ASM stores and manages data in one or more repositories. A repository contains the actual data as well as the underlying data model, which determines how the information is organized. Each repository is based on an Enabler datastore. The repository is the logical unit for storing information, the datastore is the physical unit.

Interstage ASM users can work with multiple repositories and their underlying datastores. The repositories may be located on one or more Windows, UNIX, or Linux systems where the Enabler server software is installed.

When it comes to administering Enabler servers, repositories and user access to them, Interstage ASM mostly relies on the native Enabler features and functions.

The following sections outline concepts and tasks related to Enabler server administration that are relevant for Interstage ASM:

• Installing an Enabler server

• Starting and stopping an Enabler server

• Configuring user authentication

• Administering users and user groups

• Backing up and restoring Enabler data

Details about these concepts and tasks are described in the Enabler Administration manual. It is important that you read and understand at least those sections of the Enabler Administration manual that are mentioned in the descriptions below.

2.1 Installing an Enabler Server Relevant sections of the Enabler Administration manual: 2.1, 2.2, 2.3, 3.2, and 3.4.

For installing an Enabler server on Windows or UNIX/Linux, you use one of the Interstage ASM server installers, which prepare and set up the software as required by Interstage ASM (for details, refer to the Installation Instructions of the Interstage ASM products you are using):

• The service broker port for addressing the Enabler server is set to 9500 or as specified in the setup.

• User authentication is configured for authentication against a user_ident file, and an appropriate user_ident file is created in the directory for datastores. See Section 2.3 for details on user authentication.

• The Interstage ASM system user, asmuser, is added to the Enabler server’s list of valid users. It is also added to the user_ident file with a default password or the password specified in the setup.


An existing Enabler server installation can be used for Interstage ASM if it is configured in an analogous way, particularly as to user authentication and the Interstage ASM system user.

2.2 Starting and Stopping an Enabler Server Relevant sections of the Enabler Administration manual: 2.3 and 2.6.

Before repositories on a server can be accessed, the Enabler service broker (program name: omsservd) must be running.

The Enabler service broker is started automatically when the underlying Windows or UNIX/Linux system is started. It is stopped automatically when the Windows or UNIX/Linux system is stopped.

To start the Enabler service broker manually:

• On Windows: Start the Windows service, Interstage ASM Enabler, using standard Windows interfaces and procedures, for example, the Computer Management console.

• On UNIX/Linux: Execute the enablerstart <port> command in the <ena_inst_dir>/server/bin directory; <ena_inst_dir> is the Enabler installation directory, <port> is the port number assigned to the Enabler service broker.

To stop the Enabler service broker manually:

• On Windows: First stop all repositories. Then stop the Windows service, Interstage ASM Enabler, using standard Windows interfaces and procedures, for example, the Computer Management console.

• On UNIX/Linux: Execute the enablerstop <port> command in the <ena_inst_dir>/server/bin directory; <ena_inst_dir> is the Enabler installation directory, <port> is the port number assigned to the Enabler service broker.


2.3 Configuring User Authentication Relevant sections of the Enabler Administration manual: 3.1 and 3.4.

All users trying to access repositories on an Enabler server must be authenticated. The user must provide at least his/her name and password. This information is checked against an authentication system that is determined by the Enabler server and repository to be accessed.

The following authentication methods and systems are available for Interstage ASM:

• Authentication against a user_ident file

• Authentication against an Active Directory

• Authentication against an LDAP server

After installation, Enabler servers for Interstage ASM are initially configured for authentication against a user_ident file only. The Interstage ASM server installers create an appropriate user_ident file in the directory for datastores. The Interstage ASM system user, asmuser, is automatically added to this user_ident file with a default password or the password specified in the setup.

For proper Interstage ASM operation, it is vital that asmuser can always be authenticated against a user_ident file and that its ID is not changed in any way in this file or elsewhere.

You can use the user_ident file authentication mechanism also for the other users of Interstage ASM. In this case, you have to enter their IDs and passwords in the user_ident file. See Section 3.4.4.3 of the Enabler Administration manual for details on how this is done.

Note that in recent releases, Enabler provides a command, omsuserident, that supports you in maintaining user_ident files. This command is not yet described in the Enabler Administration manual. Contact your support organization if you want to use this command.

In most environments, authentication against a user_ident file for standard Interstage ASM users will not be suitable, because it duplicates the effort of maintaining user IDs and passwords. Therefore, you can configure the user authentication to an existing Active Directory or LDAP server in your environment.

To do this, adapt the JAAS configuration file, jaas.conf, of the Enabler server accordingly: Add the required login module with its configuration to the default JAAS context BELOW the entry for the ELoginModuleUserIdent.


For example, for user authentication against an Active Directory, the default JAAS context would then look as follows: default { com.fujitsu.enabler.jena.ELoginModuleUserIdent sufficient; com.fujitsu.enabler.jena.ELoginModuleADS sufficient HostName="myhost" Port="389" ;

};

Do not remove the entry for ELoginModuleUserIdent from the default JAAS context. It is required for authentication of the Interstage ASM system user, asmuser.

For details on the JAAS configuration file, jaas.conf, and login modules, see Section 3.4.1 and 3.4.4 of the Enabler Administration manual.

2.4 Administering Users and User Groups Relevant sections of the Enabler Administration manual: 3.1, 3.2 and 3.3.

Users and user groups who are to work with Interstage ASM and be granted access rights in Interstage ASM repositories must be users and user groups known to and accepted by Enabler.

Basically, any users and user groups can be granted access to Enabler and Interstage ASM, independent on whether corresponding accounts exist in your environment. However, to facilitate maintenance of users, user groups and group memberships, we recommend you follow these rules:

• Define and maintain all users and user groups, who are to work with Interstage ASM, at the operating system level of your environment, for example, in an Active Directory, on an LDAP server or in the user and groups files of your UNIX/Linux systems. Make sure that each user and user group is unique and used throughout your entire environment. If you are using an Active Directory or LDAP server for user authentication, this should be the system where you maintain your users and groups.

• Make sure that each Enabler server in your environment collects the appropriate users and user groups in its lists of valid users and groups. If you use your own procedures for maintaining these lists, make sure that the entry for the Interstage ASM system user, asmuser, is never removed from the list of valid users. For details on the valid users and groups of an Enabler server, see Section 3.2 of the Enabler Administration manual.

• Make sure that the following settings are activated for your Interstage ASM repositories: 'ID check' and 'update group members'. This ensures that only users and user groups contained in the Enabler server's valid users and groups lists can work with the repositories and be assigned access rights, and that group memberships are to some extent maintained automatically by Enabler. For details, see Section 3.2 and 3.3 of the Enabler Administration manual.


When following the above rules, new users, user groups and changed group assignments in your company can easily be made known to Interstage ASM and reflected in the repositories as follows:

1. Add or change the users and user groups at the operating system level of your environment using standard tools.

2. Update the valid users and groups lists on all Enabler servers, for example, by executing the omsuserinit command.

3. Synchronize the group memberships in the Enabler repositories by executing the corresponding function from the Enabler tools (Synchronize Members in the Enabler User and Group Manager) or the command line interface (omsgroupmemupd), or by stopping and restarting the repositories.

There is no need to explicitly add new users and user groups to the repositories since this is done automatically as required. Obsolete users and groups can be deleted from the repositories using the corresponding Enabler functions.

2.5 Backing up and Restoring Enabler Data In order to avoid loss of data in the event of system or disk crashes, you should back up your repositories on a regular basis. For backing up repositories and restoring them, if required, you use the Enabler functions for backing up and restoring datastores. For details, refer to Section 3.7.

In addition to repositories, you should make a regular backup of the following Enabler directories and files using a backup tool of your choice:

• server\control, server\etc and server\param subdirectories of the Enabler server software installation directory. These subdirectories contain all the configuration and log files of the Enabler server, for example, datastore and broker event logs, omscreate and jaas.conf files.

• user_ident file(s) for user authentication.

In case your Enabler installation is destroyed, you can re-install the Enabler server software and restore the required configuration files from the backup.


3 Repository Administration The following sections describe concepts and tasks related to the administration of repositories and their underlying Enabler datastores:

• Distribution of data to repositories

• Resource requirements

• Creating repositories

• Datastore parameters

• Repository settings

• Starting and stopping repositories

• Backing up and restoring repositories

• Checking and reorganizing datastores

• Handling log files

• Maintaining the data model of repositories

• Deleting repositories

Details about Enabler datastores and their administration are described in the Enabler Administration manual. It is important that you read and understand at least those sections of the Enabler Administration manual that are mentioned in the descriptions below.

3.1 Distribution of Data to Repositories You can use one repository for managing all your Interstage ASM data. However, you will usually distribute the information to several repositories, particularly when many users and large amounts of data are involved. A typical Interstage ASM installation could use repositories as follows: • One or more repositories for hosting software development projects and document

libraries managed with SCM and DMS, depending on the number of projects and libraries, the amount of data and the number of users. For example, you may want to use separate repositories for each of your SCM projects. This has the following advantages: While some repositories are not available because of maintenance work, users can still work in the other repositories. Additionally, more users can work in parallel on the projects as when using one repository only, because the number of connections to one repository is limited to 500.

• One repository for SOA asset management with CentraSite.

• One repository for LCM, SCA, QAM and COC. Since the amount of data created and maintained with these components is not very high, one repository is usually sufficient. However, you may just as well use different repositories, for example, for different departments or components.


3.2 Resource Requirements The number of repositories a server can hold is limited mainly by the server's available memory and disk space. The following rules can help you determine how to dimension your Enabler servers and/or distribute repositories across multiple servers:

• Memory Minimum 40 MB per datastore. Details on how to calculate the memory requirements for datastores are provided in Appendix A.4 of the Enabler Administration manual.

• Disk Space Minimum 2 GB per datastore. Particularly in repositories used for SCM and DMS, the required disk space may be much more, depending on the number and size of files and the number of versions. For example, a medium-sized SCM project consisting of about 1.500 files with 40 versions each and an average size of 75 KB will require about 4 GB. A larger project containing about 10.000 files with 50 versions and 100 KB each will require about 50 GB. With this document, a Microsoft Excel spreadsheet, DiskSpaceCalculation.xls, is provided, which you can use to calculate the disk space requirements of SCM and DMS repositories.

• CPU and Disk Performance As a general rule, you should use the fastest CPUs and disks. The more repositories are running at the same time on a server, the more CPU is needed.

• Connections Interstage ASM limits the number of simultaneous connections to one repository to 500. This must be taken into account in particular when working with direct client/repository connections in SCM, DMS or CentraSite without using the remote interface.

3.3 Creating Repositories Creating a repository consists of creating an Enabler datastore and initializing it with the appropriate data model.

Repositories can be created in the following ways:

• Implicitly create a datastore and initialize it with the required data model. In CentraSite, a datastore and its data model are created implicitly with the first start of the csconfig Web application. See Section 7.4 for details. In the other Interstage ASM components, you can create a datastore implicitly by specifying the name of a repository that does not yet exist when logging on at the client interface.


If the prerequisites are fulfilled, a datastore with the specified name is created automatically on the given server, started in read/write mode and initialized with the data model of the Interstage ASM component in question. The parameters described in Section 3.4 are used for the datastore. For details on creating Enabler datastores and the prerequisites, see Section 6.3 of the Enabler Administration manual.

• Initialize an existing datastore with the appropriate data model: In all Interstage ASM components except for CentraSite, you can specify the name of an existing datastore when logging on at the client interface. If this datastore does not yet contain the required data model of the Interstage ASM component you log on to, the model is inserted automatically.

• Explicitly create and initialize a datastore with the required data model: From the Interstage ASM command line interface, you can explicitly initialize a datastore with an SCM or DMS data model (escm init). If the datastore does not exist, the command creates it with the parameters described in Section 3.4 and starts it. For details, refer to the Interstage ADM Command Line Interface manual.

The following minimum prerequisites must be fulfilled for successfully initializing an existing datastore with an Interstage ASM data model:

• The datastore must be running in read/write mode.

• The name check setting of the datastore must be switched off.

• You must be a datastore administrator or a data modeler.

• The Interstage ASM system user, asmuser, must be one of the datastore administrators.

The Interstage ASM users can immediately start to work with the repositories which you create and initialize with the required data model. In CentraSite, an appropriate WebDAV share must be configured in order to use the full repository functionality; see Section 7.4 for details.


3.4 Datastore Parameters When an Interstage ASM component creates a datastore for a repository automatically, it uses the Enabler default values for the datastore parameters except for the following. For details on datastore parameters, see Chapter 4 and 5 of the Enabler Administration manual.

Datastore Parameter Value

Automatic start On

ID check On

Update group members at datastore start On

Name check Off

Recovery log file size 100,000

Restore logging Off

Automatic recovery On

Number of worker threads 3

Datastore port numbers in Enabler server installations of Interstage ASM are in the range of 21000-22000.

The above values and the Enabler defaults for the remaining parameters are suitable for most environments. In some cases, however, it may be desirable or required to change datastore parameters. For example, you can:

• Increase the number of worker threads depending on the number of CPUs your Enabler server has.

• Switch on restore logging, depending on your backup strategy.

• Increase the transaction timeout and the maximum number of locks that can be set in the repository at a time. This may be necessary for SCM, DMS and CentraSite repositories if you want to import or check in huge resource or object structures. As a basic rule, the maximum number of locks should be at least 5-6 times the number of resources or objects you want to check in or import in one operation. The following table shows some examples for SCM and DMS:

Number of files to import

Number of folders to import

Number of locks required

10,000 2,500 50,000 (=default)

20,000 3,000 100,000

30,000 4,000 200,000


The following datastores parameter settings are vital for Interstage ASM operation:

• The name check setting of the datastore must be switched off.

• The Interstage ASM system user, asmuser, must be a datastore administrator. Other datastore administrators can be changed as required.

You can update datastore parameters at any time using the Enabler tools (Properties for datastores) or command line interface (omsupd). For details, see Section 6.7 of the Enabler Administration manual. Additional hints and recommendations for parameter settings are given in Chapter 4 and 5 of the Enabler Administration manual.

3.5 Repository Settings LCM, SCM and DMS repositories have several administrative settings that allow you to configure them to suit your requirements.

You can change these settings using the Interstage ASM client interface (Properties of repository in SCM and DMS, or Properties of Applications and Services node in LCM) or command line interface (several escm commands). As a prerequisite, you must have datastore administrator rights to the datastore on which the repository is based.

In addition, you can customize the default values for several settings which are used when repositories are created. For details, refer to the Interstage ASM Customization Guide.

The following sections describe the administrative settings you can make:

• General settings

• Mail settings

• Search settings

3.5.1 General Settings For each SCM and DMS repository, you can make the following general settings:

Users allowed to create new projects or document libraries

You can specify that only datastore administrators and/or members of specific access groups are allowed to create new projects or document libraries in the repository. As access groups, you can specify up to eight user groups, separated by semicolons (;), which are known to the Enabler server hosting the repository (see Section 2.4).

By default, every user known to the Enabler server is allowed to create new projects or document libraries.

Users allowed to access the repository

You can restrict access to the repository to the members of up to eight access groups. As access groups, you can specify up to eight user groups, separated by semicolons (;), which are known to the Enabler server hosting the repository (see Section 2.4).

By default, every user known to the Enabler server is allowed to access the repository.


Delta storage of file versions

This setting specifies whether only the differences between file versions are stored in the repository, or the entire contents of each version. When using deltas, the contents of specific versions are constructed from all the relevant deltas at runtime when the versions are accessed. For performance and technical reasons, SCM and DMS store the complete contents for specific file versions (e.g. newest versions, versions contained in snapshots or library editions) even if delta storage is enabled.

Delta storage of file versions may allow you to reduce the disk space required for your repositories. This depends on the types of file you are using. For example, for plain ASCII text files, the disk space requirements may decrease to a great extent, while for Microsoft Office documents even more disk space may be necessary as when storing full versions.

Delta storage of file versions has some drawbacks due to which it is not recommended:

• The creation of deltas and – even more important – the reconstruction of each version when it is accessed impacts the performance of the overall system.

• If any of the deltas is missing or damaged, the contents of all versions are lost and cannot be reconstructed.

Instead of delta storage, you can use other features and functions of SCM and DMS to reduce disk space requirements. For example, you can delete intermediate versions in SCM. Moreover, SCM and DMS save disk space by not creating new files if there are no changes when a new version is created.

When you switch on delta storage of file versions, it becomes effective for new versions; existing versions remain unchanged. When switching the setting off, all existing delta versions are converted to full versions. By default, the setting is off.

Recording of any read access to file content in the project/library log

SCM and DMS by default record all write operations carried out in their repositories in log files (see Section 3.9 for details). With this setting, you can enable also the recording of any read access to the data, i.e. to the files managed in SCM and DMS.

Be aware that the recording of read operations has a major impact on performance and heavily increases the disk space requirements for the log files. You should therefore enable this setting only if absolutely necessary, for example, in highly controlled environments or for auditing purposes.


3.5.2 Mail Settings LCM, SCM and DMS support user notification by email for specific actions. As a prerequisite, the following settings are required:

Mail enabled

The sending of emails must be enabled explicitly. By default, it is disabled.

SMTP Server

The name or IP address of the mail server to be used.

Sender ID and Sender Password

The user ID under which emails are to be sent. By default, this is LCM.Mailer in LCM, or SCM.Mailer in SCM and DMS. For mail systems, which require password authentication of the sender, the password can be specified.

Your environment may require different mail settings for different developers who access the same repository. In this case, you can define individual mail settings on the individual Interstage ASM clients. These settings override the ones made centrally in the repository for the corresponding client. For details, refer to the Interstage ASM Customization Guide.

3.5.3 Search Settings SCM and DMS provide sophisticated search features, including full-text search across multiple projects and libraries in a repository. For each repository where searching is to be allowed, the settings below must be made. As a prerequisite, a full-text search index must have been created for the repository on a system where the Interstage ASM search service is installed. For details, refer to Chapter 5.

Search enabled

Searching must be enabled explicitly for a repository. By default, it is disabled.

Server URL

The URL of the Interstage ASM search server in the following format:

http[s]://<server>[:<port>]

<server> is the Web/application server where the iscm<version> Web application has been deployed and where the search index for this repository is located. <port> is the port to address the Web/application server (default: 80 for HTTP, 443 for HTTPS).

If users specify a proxy server when connecting to the SCM or DMS repository, this proxy is used automatically for access to the search server.

Index path

The absolute path and name of the directory on the search server where the search index for this repository is located.


3.6 Starting and Stopping Repositories Users can access the data in a repository only when the underlying datastore is started. Starting a datastore means activating the required processes on the Enabler server. Datastores of Interstage ASM repositories are usually started automatically when the Enabler server is started, because they have the 'Automatic start' setting switched on.

In case you have stopped a repository, LCM, SCA, QAM and COC offer the possibility to start it when a user tries to log on to it at the client interface. For this to be successful, the user must have datastore administrator rights.

You can also re-start a repository manually using one of the following options. As a prerequisite, you must have datastore administrator rights:

• SCM or DMS: Use the corresponding menu option at the client interface (SCM: Start Repository in repository context menu, DMS: Repository > Start in document library context menu), or the escm start command of the command line interface.

• Any repository: Use the Enabler tools or command line interface. See Section 6.4 of the Enabler Administration manual for details.

Before specific administration functions can be executed on a repository and before the Enabler server is shut down, the datastore must be stopped. You can use one of the following options to stop a datastore. As a prerequisite, you must have datastore administrator rights:

• SCM or DMS: Use the escm stop command of the Interstage ASM command line interface.

• Any repository: Use the Enabler tools or command line interface. See Section 6.4 of the Enabler Administration manual for details.

3.7 Backing up and Restoring Repositories In order to avoid loss of data in the event of system or disk crashes, you should back up your repositories on a regular basis. For backing up repositories and restoring them, if required, you use the Enabler functions for backing up and restoring datastores.

Enabler offers several mechanisms and strategies for datastore backup and restore, which are described in detail in Section 6.11 of the Enabler Administration manual.

Usage of the following methods is recommended: Dump and Load.

Be aware of the following:

• With the Dump function, you can back up datastores which are running in read/write mode and thus avoid down-times. However, Interstage ASM makes use of attribute files, particularly in SCM and DMS. To create a dump with a consistent state of all datastore kernel files and attribute files, you should stop the datastore or switch it to read-only mode.


• With the Load function, you cannot restore a datastore on an Enabler server that differs from the one where you created the dump. For copying or moving a datastore to another Enabler server, use the Copy function (see Section 6.12 of the Enabler Administration manual). Archives which you create with the Copy function can also serve as backups.

3.7.1 Backup and Restore of Multiple Repositories The data created with the Interstage ASM components may be distributed across multiple repositories (see Section 3.1). The data may be interlinked with each other, for example:

• Releases and change requests in LCM may be associated with configurations and resources in SCM, or with libraries, folders and files in DMS.

• Links and categories in COC often relate to items of other Interstage ASM components.

The links between data in different repositories must be taken into account in backup and restore operations. Observe the following rules:

• Optimum consistency can be achieved by backing up all repositories at the same time without any user interaction. For example, switch all datastores to read-only mode, dump then and afterwards re-start them in read/write mode. The same applies to restore operations.

• If it is not possible to back up all repositories at the same time, observe the following sequence: First back up SCM, DMS, SCA, QAM and CentraSite repositories one by one, then back up the LCM and COC repositories.

• If you need to restore a repository, it may be required to restore related repositories as well, depending on the importance of the data links. For example, if you restore an LCM repository with change requests related to SCM projects, you will usually also restore the corresponding SCM repositories; otherwise, there could be dangling references to SCM resources in the LCM repository. On the other hand, if you need to restore a COC repository, you will usually not restore all repositories related to it; the time and effort it takes to correct links in COC is usually much less than restoring the most recent state of the data referenced by the links.

3.7.2 Client Access and Synchronization After Repository Restore After you have restored a repository, Interstage ASM users can immediately work on its contents.

In SCM and DMS, all users need to re-synchronize their local workspaces with the restored data in the repository before they commit or check in any folders or files. The safest way to do this is the following:

1. In SCM, disconnect the affected local projects from the repository. In DMS, move the affected folders from the local workspace to another location to save their contents for later update or merge operations, if required.

2. Check out all the affected projects, folders or files from the repository again.


Another possibility in SCM is to 'update and override' all affected projects in the local workspace without disconnecting before. In this case, however, it must be ensured that all users do this before anyone commits anything to the repository.

3.8 Checking and Reorganizing Datastores You should check and reorganize the Enabler datastores of your repositories on a regular basis, particularly when you delete many items from them (for example, delete entire projects or intermediate versions in SCM or empty the Lost & Found folder in SCM or DMS). Reorganizations can help you reduce the disk space required as well as avoid inefficient use of space within the datastores.

We recommend you regularly carry out the following reorganizations:

• Logical reorganization of the data model and all instances.

• Reorganization of the internal storage structure by releasing empty pages.

• Removal of unreferenced attribute files.

For details, refer to Section 6.10 of the Enabler Administration manual.

3.9 Handling Log Files All Interstage ASM components record the actions carried out in repositories in a log. This log as well as different reports based on it allow you to retrieve detailed information on your data, to control the changes carried out in your repositories and even to check for unauthorized access.

While CentraSite uses dedicated registry objects for logging, the log of the remaining Interstage ASM components is written to different files. The following log files are maintained by the Interstage ASM components:

• Global log file for each of the components, SCA, QAM and COC, which records all actions of the component in a repository.

• Repository log file for each of the components, LCM, SCM and DMS, which records actions of the component that relate to the repository as a whole, for example, the creation or deletion of LCM applications and services, SCM projects or DMS libraries.

• Application or service log file for each application and service in LCM, which records information on all actions carried out for the application or service.

• Project log file for each SCM project, which records information on all actions taken in any configuration of the project. Each day, a new project log file is created to keep the file size low and allow for fast information retrieval in the file.

• Release log file for each release of an SCM project, which records information on release-specific actions.

• Library log file for each DMS library, which records information on all actions carried out in the library. Each day, a new library log file is created to keep the file size low and allow for fast information retrieval in the file.


In SCM and DMS, the total size of all log files may become rather large. For this reason, a reorganization function is available at the client interface, which allows you to delete old entries up to a specified date from all the log files and thus reduce the amount of disk space allocated to the files:

• SCM: Reorganize Log Files option in repository context menu.

• DMS: Repository > Reorganize Log Files option in library context menu.

For reorganizing the log files of a repository, you must have datastore administrator rights.

3.10 Maintaining the Data Model of Repositories As new releases of Interstage ASM become available, changes or enhancements to the data model of the repositories may be required. Users who have installed a new release of the Interstage ASM software can no longer access repositories whose data model is of an older release.

Access from old clients to repositories having a newer data model is usually possible. This means that the data model must be of the same or a newer release than the software of the Interstage ASM clients. For details on the compatibility of Interstage ASM clients, servers and data models, refer to the Release Notes of the Interstage ASM release you are using.

SCM, DMS and CentraSite offer a function for explicitly checking the data model version of a repository and updating it, if required. This function can be executed by datastore administrators only:

• SCM: Check & Update Data Model option in repository context menu.

• DMS: Repository > Check & Update Data Model option in library context menu.

• CentraSite: automigration setting in the CentraSite.properties configuration file of the csconfig Web application. See Section 7.2 for details.

LCM, SCA, QAM and COC allow users with appropriate rights to update the data model, if required, when they log on to the client interface.


3.11 Deleting Repositories When repositories and their contents are no longer needed, you can delete them.

The deletion of a repository cannot be undone. The repository contents will be lost.

You can use one of the following options to delete a repository. As a prerequisite, you must have datastore administrator rights:

• Use the corresponding menu option at the client interface of SCM (Delete Repository in repository context menu) or DMS (Repository > Delete in library context menu).

• Use the escm drop command of the Interstage ASM command line interface.

• Stop and delete the underlying datastore using the Enabler tools or command line interface. See Section 6.9 of the Enabler Administration manual for details.


4 SCA Server Administration SCA users carry out source code analysis on so-called cubes. An SCA cube is an OLAP cube resulting from a source code scan. It includes entities that represent source code elements (e.g. programs, variables, statements) as well as their interrelationships.

SCA cubes are created and maintained on an SCA server. An SCA server can host any number of cubes for different sets of source code. Users of SCA can access cubes stored on the same SCA server or on different servers.

The following sections describe concepts and tasks related to the installation and administration of SCA servers:


• Installing and running an SCA server

• Setting scan source directories

• Backing up and restoring SCA data

• Scheduling source code scans

• Scheduling QAM measurements

4.1 Resource Requirements You can install the SCA server software on any number of Windows systems in your environment.

The decision on how many SCA servers you need mainly depends on resource considerations. The following rules can help you determine how to dimension your servers and/or distribute the load across multiple servers:

• Disk Space The source code to be scanned must be available on the SCA server in one or more scan source directories (see Section 4.3 for details). The scan source directories can be located directly on the SCA server or on a network drive connected or mounted to it. If you copy the source code to the local system, the corresponding amount of disk space is needed. Access to local files by the scanner and during analysis is usually faster than working via network connections. SCA cubes resulting from scans are physically stored on the SCA server in files which are located in the application data directory that was specified during installation of SCA. The initial disk space requirements for a cube are about the same as the memory requirements, i.e. about 1 GB for 14 million lines of code. Each time you repeat scanning for a specific SCA cube within one month, the existing cube file is saved to a file with the same name and a number indicating the day of the month. The new scan results are written to the original cube file. For example, on the 22nd of a month, a mycube file is saved to mycube_22, and the new scan results are written to the mycube file.


The save file is overwritten by a scan on the same day of the next month. This means that up to 31 copies of a cube file may exist, requiring an appropriate amount of disk space.

• Memory 1 GB of memory is required for SCA cubes generated for about 14 million lines of code. Additionally, about 100 KB are required for each active user.

• Performance As a general rule, you should use the fastest CPUs and disks. The more SCA cubes are maintained on one server, the more CPU is needed. Scanning as such is very fast: Within one hour, about 10 million lines of code can be scanned. Scanning 20 million lines of code takes about 90 minutes. The speed with which data is retrieved from the cubes and returned to the users depends mainly on the speed of the network connection between the client and the server, the amount of data to be retrieved and the number of simultaneous users.

• Connections The number of users who can work with SCA cubes on one server simultaneously is limited by the number of licenses you have obtained.

4.2 Installing and Running an SCA Server The SCA server functionality is provided by the following services:

• Analysis service: This service is responsible for building and maintaining the SCA cubes and handling access to the cubes from the Interstage ASM clients. The analysis service runs as a Windows service (display name: Interstage ASM Analysis, program name: isanalysisd).

• Scan service: This service is required for configuring the scanners, retrieving source code files and initiating scans from the Interstage ASM clients. The scan service is provided by the isca<version> Web application.

Both services must be installed and set up on the same Windows system. This involves the following steps:

1. Install the SCA server software and Web applications using the Interstage SQA server installer. This automatically sets up and starts the analysis service. For details, refer to the Interstage SQA Installation Instructions.

2. Deploy and start at least the isca<version> Web application. For details, see Chapter 6.

The analysis service is started automatically when the underlying Windows system is started. It is stopped automatically when the Windows system is stopped.


To start or stop the analysis service manually: Start or stop the Windows service, Interstage ASM Analysis, using standard Windows interfaces and procedures, for example, the Computer Management console.

To start or stop the scan service, start or stop the isca<version> Web application using the standard interfaces and procedures of your Web/application server.

4.3 Setting Scan Source Directories All source code to be scanned must be available on the SCA server in one or more scan source directories. The scan source directories can be located directly on the SCA server or on a network drive connected or mounted to it. The source code to be scanned can be located directly in one of the scan source directories, or in one or more subdirectories thereof. You specify the exact location when you define the scan configuration in the Interstage ASM client interface.

After installation of the SCA server software, one scan source directory is set: analysis\scansrc subdirectory of the application data directory specified in the installation (e.g. C:\InterstageASM).

The scan source directory is stored in the analysisservice.scansrcdir property in the following file:

WEB-INF\scan.properties in the deployment directory of the isca<version> Web application.

You can change the scan source directory or add additional directories by editing the value of the analysisservice.scansrcdir property in this file. Separate multiple scan source directories by a semicolon (;). Use slashes (/) or double backslashes (\\) as separators in the directory paths. For example:

analysisservice.scansrcdir=C:\\ASM\\analysis\\scansrc;D:\\ScanData

For changes in the scan source directories to become effective, restart the isca<version> Web application.

4.4 Backing up and Restoring SCA Data SCA deals with the following data:

• Source code: The source code to be scanned and analyzed must be available in one or more scan source directories (see Section 4.3 for details). For example, source code managed with SCM can be checked out or exported to a scan source directory on the SCA server, or mainframe code can be transferred to such a directory using tools like FTP.


• Scan configurations: Scan configurations specify the options for scanning a specific set of source code files and producing a corresponding SCA cube. Users can set up and change scan configurations from the Interstage ASM client interface. The configurations are stored in the SCA repository. When scanning for a specific SCA cube is started, SCA reads the corresponding configuration from this repository. On the SCA server, scan configurations are stored in intermediate .dat files in the SCA server installation directory. Each scan overwrites the relevant .dat file with the information read from the SCA repository.

• SCA cubes: An SCA cube is the result of a source code scan. It includes entities that represent source code elements (e.g. programs, variables, statements) as well as their interrelationships. SCA cubes are physically stored on the SCA server in files which are located in the analysis\cubes subdirectory of the application data directory that was specified in the installation of SCA (e.g. C:\InterstageASM). For each cube file, up to 31 save files may exist in the same directory (see Section 4.1).

• Analysis data and results: The data and results of analyses are stored in one or more SCA repositories. The results can additionally be checked in to a DMS library.

In order to avoid loss of data in the event of system or disk crashes, you should back up the SCA repositories on a regular basis. For details on how to do this, see Section 3.7.

Backup of additional data in SCA is usually not required for the following reasons:

• The source code is not subject to SCA administration. It is backed up with the original source code management system or file system.

• The scan configurations are obtained from the central repository as required.

• SCA cubes can easily and quickly be rebuilt by scanning the source code again. This is often faster and more efficient than to restore the cubes from a backup.

If you want to back up these data nevertheless, you can do this by backing up the following directories using any tool of your choice:

• analysis subdirectory of the application data directory that was specified in the installation of SCA (e.g. C:\InterstageASM).

• All scan source directories you have defined.

4.5 Scheduling Source Code Scans Scanning can be started at any time from the Interstage ASM client or command line interface.

At the client interface, use the Scan menu option in the context menu for SCA cubes.

At the command line interface, use the esca.bat batch file (Windows) or esca.sh shell script (UNIX/Linux) with the scan command. The syntax and parameters are described in Section 13.2.


The following prerequisites must be fulfilled for executing esca scan:

• The Interstage ASM command line interface must be prepared and configured on the machine where the command is to be executed. For details, see Section 11.2. You will usually execute the command directly on the SCA server, but you can also run it from another system in the same LAN.

• The SCA services on the SCA server must be running.

• The SCA repository must be running and accessible from the system where you execute esca scan as well as from the SCA server so that the scan configuration can be obtained.

You can execute esca scan manually at any time, or you can invoke it via scheduling functions of the underlying operating system like any other command, for example:

• On Windows: the AT command.

• On UNIX/Linux: the cron mechanism.

This allows you, for example, to scan huge software systems every night so that users can start or continue analyzing the most up-to-date sources in the morning.

4.6 Scheduling QAM Measurements In QAM, quality assessments are based on indicator values. These values are obtained by measurements which retrieve the required data from SCA cubes and store them in the QAM repository.

In the same way as you can automate the scanning of source code, you can automate the creation of QAM measurements using the command line interface and scheduling functions of the underlying operating system. This allows you, for example, to create up-to-date measurements each time after you have scanned source code to the appropriate SCA cubes.

To take measurements at the command line interface, use the eqam.bat batch file (Windows) or eqam.sh shell script (UNIX/Linux) with the collect command. The syntax and parameters are described in Section 13.4.

The following prerequisites must be fulfilled for executing eqam collect:

• The Interstage ASM command line interface must be prepared and configured on the machine where the command is to be executed. For details, see Section 11.2. You will usually execute the command directly on the SCA server where the relevant SCA cubes are located, but you can also run it from another system in the same LAN.

• The SCA services on the SCA server must be running.

• The SCA cubes containing the data for the measurement must exist on the SCA server.

• The QAM repository must be running and accessible from the SCA server and the system where you execute eqam collect.


5 Search Server Administration The Interstage ASM client and Web interfaces provide sophisticated search features, including full-text search across multiple SCM projects and DMS libraries in a repository. Users can search for SCM and DMS folders and files by name, contents (full-text search), and properties (e.g. date of last modification, committing user). A search can be executed in one or more specific folders, SCM configurations, releases or projects, or DMS libraries or library editions.

For carrying out searches in SCM and DMS, the following is required:

• The Interstage ASM search service must be installed and running on one or several machines (search servers). For details, see Section 5.2 below.

• A search index must be generated on the search server for each SCM and DMS repository that is to be searched. For details, see Section 5.3 below.

• Searching must be enabled and configured for each repository that is to be searched. For details, see Section 3.5.3.

The following sections describe concepts and tasks related to the installation and administration of search servers in Interstage ASM:


• Installing and running a search server

• Creating and maintaining search indices

• Backing up and restoring search indices

5.1 Resource Requirements You can install the Interstage ASM search server on any number of Windows and/or UNIX/Linux systems in your environment.

The decision on how many search servers you need mainly depends on resource considerations. The following rules can help you determine how to dimension your servers and/or distribute the load across multiple servers.

Searching across multiple repositories is not possible. All SCM projects and DMS libraries which are to be searched in one operation must be located in the same repository.

• Disk Space

For each SCM or DMS repository to be searched, a search index must be generated. The index may be located locally on the search server or on a network drive connected or mounted to it. Access to a local index is usually faster than working via network connections.


The disk space required for the index of one repository can be calculated as follows: <projects_libraries> * <files> * <versions> * <filesize> * 0.05

<projects_libraries> is the number of SCM projects and/or DMS libraries in the repository. <files> is the average number of files per project/library. <versions> is the average number of versions per file. <filesize> is the average file size. 0.05 is the factor to calculate the index size.

• Memory About 200 MB are required for indexing, about 70 MB for searching.

• Performance As a general rule, you should use the fastest CPUs and disks. Index creation and update is very fast. Depending on the file types in use, an index for 1000 files in a repository can be created or updated in less than 10 minutes. The speed also depends on the performance of the search server and the Enabler server where the repository is located as well as on the connection between the two systems. This means that indexing performance is best when the search server is on the same machine as the Enabler server. On the other hand, this may have a negative impact on the performance of search operations and access to the repository. The search speed is in the range of milliseconds to seconds, depending on the complexity of the search conditions. Performance decreases the more indices there are on the same server.

5.2 Installing and Running a Search Server Searches from Interstage ASM clients are carried out via the Interstage ASM search service which must be running on the search server. The search service is provided by the iscm<version> Web application.

Installing a search server on a system means installing and deploying at least the iscm<version> Web application. For details, see Chapter 6.

To start or stop the search service, start or stop the iscm<version> Web application using the standard interfaces and procedures of your Web/application server.


5.3 Creating and Maintaining Search Indices Searches in SCM and DMS are not carried out directly in the repositories, but on search indices. For each SCM and DMS repository to be searched, a separate index must be created and kept up-to-date. Search indices are located in one or more directories on the search server, either locally or on network drives connected or mounted to it.

For index creation and maintenance, you use the esindex.bat batch file (Windows) or esindex.sh shell script (UNIX/Linux), which is part of the Interstage ASM command line interface.

The following sections provide information on:

• Creating and updating search indices

• Optimizing search indices

• Deleting search index entries and complete search indices

• The esindex command for maintaining search indices

5.3.1 Creating and Updating Search Indices Interstage ASM provides options to create a search index for:

• An entire SCM or DMS repository.

• An individual SCM project.

• An individual DMS library.

• Individual folders and files (documents) in SCM projects and DMS libraries which have already been indexed.

An existing index should be updated at regular intervals, for example, each night or several times during the day, to provide the users with up-to-date data. An index update takes into account all items which are included in the index and have changed since the creation or last update of the index.


Ignore Lists In so-called "ignore lists", you can specify folders and files of SCM projects or DMS libraries which are to be ignored by the search indexer. This is useful, for example, for generated code stored in SCM projects which is unreadable for users. When you specify a folder in an ignore list, the folder itself as well as all of its contents are ignored by the search indexer.

If a search index already contains entries for folders or files you add to an ignore list, these are removed by the next index update. If you want to include such entries again in the search index, adapt the ignore list accordingly and then re-create the index for the folders or files. Be aware that an index update will not cover the folders or files as long as you do not re-create the index.

You define an ignore list in an XML file named ignore.xml. The file must be stored in the directory on the search server where the indices for the corresponding repositories are located. Each search index directory can have its own ignore list.

An ignore list has the following format: <ignore> <item server=”<server>” repository=”<repository>” project=”<project or library>” path=”<folder or file>”/> </ignore>

An ignore list can have any number of <item> elements. <server> is the name or IP address of the Enabler server hosting the relevant repository, <repository> is the name of the repository, <project or library> is the relevant SCM project or DMS library, <folder or file> is the path and name of the folder or file to be ignored by the search indexer.

Example: <ignore> <item server=”myserver” repository=”myscm” project=”Project A” path=”/component a/src”/> <item server=”myserver” repository=”mydms” project=”Library A” path=”/internal documents”/> </ignore>


5.3.2 Optimizing Search Indices When an index for a repository has undergone numerous updates, searches may become slower. The main reason is that the number of files used by the index increases as updates are performed.

An index optimization increases the search performance and reduces the physical size of the search index by merging the existing index files and deleting obsolete entries from them.

Carry out an index optimization whenever the search performance gets low, after you have deleted entries from the index, or after you have performed a specific number of index updates.

An index optimization involves many disk I/O operations. Therefore, we recommend you run it at times of low system usage, for example, at night. You should not optimize an index while updating it or creating a new one at the same time. Although this does not cause any damage, the index creation or update requires much more time.

5.3.3 Deleting Search Index Entries and Indices Index data which are no longer needed can be deleted. For example, if you intend to delete a project from an SCM repository, you can delete the related data from the index. Be aware of the following when deleting data from a search index:

• The search index entries for an SCM project or a DMS library must be deleted before you delete the project or library itself.

• Deleted entries are physically removed from a search index only by an index optimization.

If you want to delete the entire index for a repository, you can simply delete the corresponding index files and/or directory on the search server.

5.3.4 esindex For index creation, update, optimization and deletion, you use the esindex.bat batch file (Windows) or esindex.sh shell script (UNIX/Linux), which is part of the Interstage ASM command line interface. The syntax and parameters of esindex are described in Section 13.5.

The following prerequisites must be fulfilled for executing esindex:

• The Interstage ASM command line interface must be prepared and configured on the search server where the index is to be generated. For details, see Section 11.2. You must execute esindex directly on the search server.

• The SCM or DMS repository, for which the index is to be created, must be running and be accessible from the search server.


You can execute esindex manually at any time on the search server, or you can invoke it via scheduling functions of the underlying operating system like any other command, for example:

• On Windows: the AT command.

• On UNIX/Linux: the cron mechanism.

This allows you, for example, to update the search indices for your repositories at night and/or at regular intervals during the day so that the users have access to the up-to-date information.

5.4 Backing up and Restoring Search Indices There is usually no need to back up search indices. Rebuilding the indices after disk or system crashes is often faster and more efficient than to restore them from a backup.

If you want to back up the indices nevertheless, you can do this by backing up the corresponding directories of the search server using any tool of your choice.


6 Web/Application Server Administration Interstage ASM provides part of its functionality and features as Web applications. Some of these Web applications are mandatory for Interstage ASM operation, others are optional.

The Interstage ASM Web applications can be installed and deployed on any standard Web/application server. Connections can be by HTTP and HTTPS.

The following sections describe concepts and administrative tasks related to the Web applications:

• Overview of the Interstage ASM Web applications

• Context names and URLs

• Installing and deploying the Web applications

• Configuring SSL access

• Setting the language for the Web applications

• Configuring the Web applications

6.1 Overview of the Interstage ASM Web Applications The following table provides an overview of the Interstage ASM Web applications. <version> is an identifier for the current version of Interstage ASM, for example, 100 for version 10.0.

Web Application Description

iasmcore<version> Mandatory for LCM, SCA, QAM, COC and CentraSite; used for user and role management in these components as well as for all repository connections from the client and command line interfaces in LCM, SCA, QAM and COC.

csconfig Mandatory for CentraSite; used for defining and retrieving basic settings of the CentraSite environment and for carrying out administrative tasks.

EnWebDAV Mandatory for CentraSite, optional for SCM; provides the WebDAV interface of Interstage ASM.

isca<version> Mandatory for SCA servers, optional otherwise; provides the SCA analysis service and the remote interface for SCA and QAM.

iscm<version> Mandatory for search servers, optional otherwise; provides the search service, Web interface and remote interface for SCM.



idms<version> Optional; provides the Web interface and remote interface for DMS. For using the remote interface, the iscm<version> Web application is also required and must be deployed in addition to the idms<version> Web application.

ilcm<version> Optional; connects LCM to Interstage BPM.

csnotification Optional; provides the notification functionality of CentraSite.

csuddi Optional; provides the UDDI interface of CentraSite.

csfederation Optional; provides the federation functionality of CentraSite.

The Web applications are available as Web archives (.war files) and as directories with the names listed in the table.

6.2 Context Names and URLs Independent of the Web/application server you are using to deploy the Web applications, be aware of the following:

The name of the context by which a Web application is deployed should be identical to the name of the .war file or directory containing the Web application. For example, the context name should be iscm100 if you are deploying the iscm100.war file.

The main reason is that Interstage ASM automatically appends the appropriate context or additional information to the URL which a user specifies at the client interface or the command line interface to address the Web application.

The user of the client or command line interface just enters the following URL: http[s]://<server>[:<port>]

<server> is the Web/application server, <port> the port used to access it.

Interstage ASM automatically appends the appropriate information to this URL. For example, it would append iscm<version> for SCM. <version> in this case is the Interstage ASM version of the client or command line interface, which must always be equal to or less than that of the Web application.


You can override this behavior if required for specific situations by using a URL in one of the following formats at the client or command line interface:

• In LCM, SCM, DMS, SCA, QAM and COC: http[s]://<server>[:<port>]#<context>

<context> is the name of the context to be addressed. Interstage ASM internally maps this URL to: http[s]://<server>[:<port>]/<context>

• In CentraSite: http[s]://<server>[:<port>]/<context>/<configuration_file>

<context> is the name of the context to be addressed (default: csconfig), <configuration_file> is the name of a CentraSite configuration file (default: CentraSite.properties). See Section 7.2 for details on the CentraSite configuration file.

For the Web interface of SCM and DMS, the context name by which the corresponding Web application is deployed is irrelevant. The user always types the full URL including the context in the Web browser: http[s]://<server>[:<port>]/<context>

6.3 Installing and Deploying Web Applications The Interstage ASM Web applications can be installed and deployed on any standard Web/application server where the following prerequisites are fulfilled:

• The Web/application server must be running on the same system or at least in the same LAN as the Enabler servers hosting the Interstage ASM repositories, the SCA servers and the search servers. If different systems are used, direct connections between them must be possible via TCP/IP without any firewall. At least the isca<version> Web application must be deployed on each SCA server, the iscm<version> Web application on each search server.

• The Web/application server itself must be installed and operational. Its servlet container must be conformant to Servlet API 2.3 or higher. For details, refer to the vendor’s documentation.

• At least version 1.4.2 of the Sun J2SE Runtime Environment (JRE) or Sun J2SE Development Kit (JDK) must be installed and used by the application server.

Observe the following rules as to the distribution of the Web applications to different Web/application servers:

• The CentraSite Web applications can be deployed only once in an Interstage ASM environment. They can be distributed to different Web/application servers with the following exception: The csfederation Web application must be deployed on the same Web/application server as the csconfig Web application.

• The remaining Web applications can be installed once or several times on different Web/application servers, for example, to achieve optimum load balancing.


To install and deploy the Interstage ASM Web applications, take the following basic steps:

1. With the Interstage ASM server installers, install the Web applications you intend to use on your Web/application server. The server installers copy the Web applications as .war files and directories to the webapps or ibpm\webapps subdirectory of the Interstage ASM server software installation directory. In specific Web applications, the installers make initial configuration settings. For example, they set the password of the Interstage ASM system user, asmuser, to the configuration files of Web applications where this is required. For details, refer to the Installation Instructions of the Interstage ASM products you are using.

2. Deploy the Web applications using the standard procedures of your Web/application server. You can deploy the Web applications directly from their installation directory. Make sure that the Web applications are extracted or copied to separate deployment directories of your Web/application server. The deployment directories should differ from the directories created by the Interstage ASM server installers, because the latter may be overwritten by a new or update installation. The context name used for each Web application should be identical to the name of the corresponding .war file or directory. See Section 6.2 above for details on context names and URLs. Deploy the Web applications one by one, observing the following rule: For CentraSite, the csconfig Web application should be available and started before you start the EnWebDAV or other CentraSite Web applications for the first time. The sections below outline the deployment with Fujitsu Interstage Application Server and Apache Tomcat. For details, and for information on how to deploy the Web applications with other Web/application servers, refer to the documentation of the Web/application server.

Depending on the Web application, you have to make specific configuration settings after the deployment. For details, see Section 6.6.

After the deployment, a Web application is accessible by the following general URL:

http://<server>[:<port>]/<context>

For access from the Interstage ASM client or command line interface, use the following URL:

http://<server>[:<port>]

<server> is the name of the application server, <port> the port to connect to it (default: 80), <context> the name of the Web application.


6.3.1 Deploying with Interstage Application Server To deploy an Interstage ASM Web application with Fujitsu Interstage Application Server:

1. Log on to the Interstage Management Console.

2. Create a new WorkUnit (Web application) using System > WorkUnit > Create a new WorkUnit. Specify a name for the WorkUnit and assign the IJServer type to it. The name should be identical to that of the Interstage ASM Web application you are deploying.

3. In the Settings tab for the new WorkUnit:

• In the Working Unit Settings section, set the value for Maximum application processing time to 0.

• In the Servlet Container Settings section, set the value for Timeout to 4000.

4. In the Deploy tab for the WorkUnit, specify the .war file of the Interstage ASM Web application you want to deploy. Click Deploy to finish.

6.3.2 Deploying with Apache Tomcat To deploy an Interstage ASM Web application with Apache Tomcat, you can use one of the following procedures:

• In the Tomcat Web Application Manager, specify the .war file of the Web application in the WAR file to deploy section, and click Deploy to deploy and start it.

• Copy the .war file of the Web application to the standard webapps directory of the Apache Tomcat installation directory. It is made available automatically by the Apache Tomcat hot deploy feature.

Handling JavaMail As of Apache Tomcat 5.5.9, the JavaMail library, mail.jar, required by the LCM, SCM, and DMS components is no longer distributed with Apache Tomcat. For your convenience, it is provided in the webapps subdirectory of the Interstage ASM server software installation directory together with the .war files and directories of the Interstage ASM Web applications.

In order to use the library, it must be available in one of the following locations:

• The WEB-INF\lib subdirectory of the deployment directory of the following Interstage ASM Web applications: iasmcore<version>, iscm<version> and idms<version>.

• The <catalina_home>\common\lib directory of Apache Tomcat.

If the library exists in both locations, errors will occur!


6.4 Configuring SSL Access The Interstage ASM Web applications can be accessed by standard TCP/HTTP connections as well as by SSL/HTTPS connections. For SSL/HTTPS access, both the Web/application server and the relevant clients must be configured accordingly.

The following sections outline how to configure Fujitsu Interstage Application Server, Apache Tomcat and the Interstage ASM clients for SSL access. For details on how to proceed on each individual Web/application server, refer to the vendor's documentation.

After completing the SSL configurations, each Interstage ASM Web application is accessible by the following general URL:

https://<server>[:<port>]/<context>

For access from the Interstage ASM client or command line interface, use the following URL:

https://<server>[:<port>]

<server> is the name of the application server, <port> the port to connect to it (default: 443), <context> the name of the Web application.

6.4.1 Configuring SSL Access in Interstage Application Server To configure SSL access in Fujitsu Interstage Application Server:

1. Obtain and install the site certificate you want to use. You can obtain a site certificate from a Certification Authority (CA) like VeriSign. Alternatively, you can use the Fujitsu Interstage scsmakeenv command to create a certificate for testing purposes. Proceed as described in the application server documentation to install the certificate.

2. In the Interstage Management Console, create a new SSL configuration using System > Security > SSL > Create a new SSL Configuration. Specify a name of your choice for the configuration and select the certificate to be used for it.

3. In the Interstage Management Console, configure the Interstage Web server to use SSL: Choose System > Services > Web Server. In the Web Server Settings tab under Detailed Settings, select Enable SSL Encryption and choose the SSL configuration created in step 2. Save your settings by clicking Update.

4. Restart the Web server using System > Services > Web Server > Stop and System > Services > Web Server > Start for the changes to take effect.

Note that by default, Interstage uses the same port for SSL and non-SSL access. This means that if you configure the application server for SSL communication, HTTP without SSL access is no longer possible.


6.4.2 Configuring SSL Access in Apache Tomcat To configure SSL access in Apache Tomcat:

1. Obtain and install the site certificate you want to use. You can obtain a site certificate from a Certification Authority (CA) like VeriSign. Alternatively, you can use the keytool command of your JRE/JDK to create a self-signed certificate. In order to install the certificate, use the keytool command of the JRE/JDK used by Apache Tomcat. Call the command as follows: keytool -import -alias tomcat -trustcacerts -file <cert_file> -keystore <keystore>

<cert_file> is the certificate file, <keystore> is the keystore of the JRE/JDK, for example, <JAVA_HOME>\jre\lib\security\cacerts. Using tomcat for the alias name is crucial.

2. Configure Apache Tomcat to use SSL by uncommenting the corresponding Connector section in the configuration file, <catalina_home>\conf\server.xml: <Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" />

3. Restart Apache Tomcat.

6.4.3 Configuring Interstage ASM Clients for SSL Access If the Interstage ASM client or command line interface is to use HTTPS for communications with the Interstage ASM Web applications, an appropriate certificate must exist in the truststore of the JRE/JDK used by the client. To add such a certificate to the truststore, if required, proceed as follows:

1. Obtain the certificate to be installed. For example, you can:

• Use a certificate obtained from a Certification Authority (CA) like VeriSign.

• Export the certificate from your Apache Tomcat application server with the keytool command of the JRE/JDK in use. Call the command as follows: keytool -export -alias tomcat -file tomcat.cert [-keystore <keystore>]

<keystore> is the keystore of the application server's JRE/JDK, for example, <JAVA_HOME>\jre\lib\security\cacerts.


• Export the certificate from your Fujitsu Interstage Application Server with the scsexppfx command. Call the command as follows: scsexppfx -n <nickname> -f <cert_file>

The file exported from the Fujitsu Interstage environment is in PKCS#12 format. In order to import it into a client's Java environment, it must be converted to the PEM format. Use, for example, the following OpenSSL command to do this (for details, see www.openssl.org): openssl pkcs12 -in <pkcs12_file> -out <pem_file>

Additionally, edit the generated PEM file by removing all information before -----BEGIN CERTIFICATE-----

and after -----END CERTIFICATE-----

2. Add the certificate to the truststore on each client using the keytool command of the JRE/JDK in use. Call the command as follows: keytool -import -alias tomcat -file <cert_file> -trustcerts –noprompt -keystore <truststore>

<cert_file> is the file containing the certificate, <truststore> is the path and name of the truststore of the client's JRE/JDK, for example, <JAVA_HOME>\jre\lib\security\cacerts.

3. Check and, if required, change the default protocol handler for HTTPS on each client in the java.security file of the JRE/JDK in use. The first security provider entry must read as follows: security.provider.1=com.sun.net.ssl.internal.ssl.Provider

4. Set Java system properties on each client, if required, for example, because you are using a keystore and/or truststore other than the default ones. The following Java system properties are relevant for SSL: javax.net.ssl.keyStore – the location of the keystore javax.net.ssl.keyStoreType – the type of the keystore (e.g. jks, pkcs) javax.net.ssl.trustStore – the location of the truststore javax.net.ssl.trustStoreType – the type of the truststore The properties can be specified as follows:

• For the Interstage ASM client interface: Set the Java system properties in the –vmargs parameter, which is evaluated when you start the stand-alone variant of the client interface or Eclipse. Specify each property with the –D option, such as: –vmargs –Djavax.net.ssl.trustStore=D:\Java\cacert You can set the –vmargs parameter in an .ini file that has the same name and is located in the same directory as the executable used to start the stand-alone variant of the client interface or Eclipse. Alternatively, you can specify the parameter with the call to the executable itself. See Section 11.1.2 for details.

• For the Interstage ASM command line interface: Add the corresponding option to the ASM_VMARGS environment variable. See Section 11.2.1 for details.

www.openssl.org�


6.5 Setting the Language for the Web Applications By default, the Interstage ASM Web applications use the language set in the operating system of the Web/application server. In specific cases, this language setting overrides the corresponding setting on the clients which use the Web applications. For example, when working with SCM or DMS via the remote interface, messages are returned in the Web application's language even if the client’s language setting is different.

To overcome such inconveniences, you can change the language of the Interstage ASM Web applications. This is done by setting the user.language Java system property in the servlet container accordingly. For example:

• In Fujitsu Interstage Application Server, add the -Duser.language=<id> in WorkUnit Settings > Java VM Options for the Interstage ASM WorkUnits.

• In Apache Tomcat, set -Duser.language=<id> in the JAVA_OPTS parameter in the catalina.bat (Windows) or catalina.sh (UNIX/Linux) file: JAVA_OPTS="-Duser.language=<id>"

<id> is the language identifier. It can be set to en for English or ja for Japanese.

6.6 Configuring Web Applications Most of the Interstage ASM Web applications can be used immediately after deployment without any further adaptation. Some Web applications, however, require specific configuration settings.

The following sections provide an overview of the configuration settings and describe how to adjust settings for the SCM Web interface.

6.6.1 Overview of Configuration Settings The following table provides an overview of whether and when specific configuration settings are required for each Web application, and where you can find details on these settings.

Web Application Configuration Settings Details in

iasmcore<version> Password of the Interstage ASM system user, asmuser. Adaptation required only if you change the password of asmuser.

12.1

csconfig Basic settings for CentraSite. Adaptation required if values other than the pre-set ones are to be used.

7.2


Web Application Configuration Settings Details in

EnWebDAV WebDAV share definitions. Adaptation required for SCM. For CentraSite, adaptation is required if values other than the pre-set ones are to be used.

8

isca<version> Scan source directories and port of the analysis service. Adaptation required if values other than the pre-set ones are to be used.

4.3, 12.2

iscm<version> Upload file size and multi-byte character encoding for the SCM Web interface. Adaptation required if values other than the pre-set ones are to be used.

6.6.2

idms<version> none

ilcm<version> Password of asmuser, host name of the Interstage BPM server, ID and password of an Interstage BPM user with administrator privileges. Adaptation required only if you change the passwords or the Interstage BPM server or user.

9.4

csnotification Settings for CentraSite notifications. Adaptation required before first usage.

7.7

csuddi Settings for the UDDI interface of CentraSite. Adaptation required if values other than the pre-set ones are to be used.

7.8

csfederation Settings for CentraSite registry federations. Adaptation required if values other than the pre-set ones are to be used.

7.9

6.6.2 Configuring the SCM Web Interface In the iscm<version> Web application, you can configure the following settings for the SCM Web interface:

• Maximum size of files that can be uploaded to the repository

• Encoding of multi-byte characters in files for proper display at the Web interface

The following sections describe these settings in detail. For changes in the settings to become effective, restart the iscm<version> Web application.

Upload File Size You can set a maximum size for files users can upload to a repository via the SCM Web interface. To do this, change the maxFileSize setting of the controller entry in the following file: WEB-INF/struts-config.xml in the deployment directory of the iscm<version> Web application:

...  <controller contentType="text/html; ... maxFileSize="-1" /> ...

You can specify the following values for maxFileSize:

-1 The file size is unlimited

<n>K The maximum file size is <n> kilobytes, <n> is an integer.

<n>M The maximum file size is <n> megabytes.

<n>G The maximum file size is <n> gigabytes.

Multi-byte Character Encoding The SCM Web interface allows you to display the contents of files in a Web browser. Multi-byte characters in these files are shown correctly only if they are encoded appropriately.

The default encoding for multi-byte characters is Shift_JIS. You can change this setting in the charEncoding parameter in the following file: WEB-INF/web.xml in the deployment directory of the iscm<version> Web application:

... <context-param> <param-name>charEncoding</param-name> <param-value>Shift_JIS</param-value>

...

To change the character encoding, replace Shift_JIS by the required encoding.


7 CentraSite Administration A CentraSite installation comprises the following components and systems:

• Several Web applications which provide administration, notification and federation functionality and the UDDI interface.

• A single datastore which includes the CentraSite registry and repository.

• Any number of clients where users work with the CentraSite registry and repository using the client interface.

The following sections describe concepts and administrative tasks related to the CentraSite Web applications:

• Installation and deployment of the CentraSite Web applications

• Basic CentraSite settings

• Execution of CentraSite administration functions

• Creation of a CentraSite registry and repository

• Administration of a CentraSite registry and repository

• Administration of the CentraSite password store

• Enabling of change notifications

• Configuration of the UDDI interface

• Setup of registry federations

7.1 Installing and Deploying the Web Applications The following Web applications are of relevance for a CentraSite installation:


iasmcore<version> Mandatory; used for user and role management.

csconfig Mandatory; used for defining and retrieving basic settings of the CentraSite environment and for carrying out administrative tasks.

EnWebDAV Mandatory; provides the WebDAV interface which is used for the repository functionality of CentraSite.

csnotification Optional; provides the notification functionality of CentraSite.

csuddi Optional; provides the UDDI interface of CentraSite.



csfederation Optional; provides the federation functionality of CentraSite.

You can install and deploy the CentraSite Web applications in the same way as any of the Interstage ASM Web applications. This is described in detail in Chapter 6.

You must at least install and deploy the iasmcore<version>, csconfig and EnWebDAV Web applications. The remaining Web applications are required only if you want to use the corresponding functionality. The Web applications can be deployed on a single Web/application server or distributed to different servers with the following exception: The csfederation Web application must be deployed on the same Web/application server as the csconfig Web application.

If you want to use different CentraSite registries and repositories, you must install and deploy the Web applications a corresponding number of times using different Web/application servers.

7.2 Basic CentraSite Settings Basic settings for CentraSite are stored in the CentraSite.properties configuration file in the WEB-INF subdirectory of the deployment directory of the csconfig Web application. The settings are required and read by all CentraSite Web applications and clients.

The CentraSite.properties file initially contains the following basic settings. The initial values for these settings are predefined or written to the file by the CentraSite server installer.

webdav.server=<server> webdav.port=<port> webdav.path=/EnWebDAV/CentraSite enabler.server=<server> enabler.datastore=CentraSite enabler.port=<port> enabler.user=asmuser enabler.autocreation=yes enabler.automigration=yes asmcore.url=<url> # federation.url=<url> securestore=

The settings have the following meaning:

webdav.server

The name or IP address of the Web/application server where the WebDAV interface (EnWebDAV Web application) is deployed. The server is specified and set in the installation.


webdav.port

The port to address the Web/application server where the WebDAV interface is deployed. The port is specified and set in the installation.

webdav.path

The path of the WebDAV share defined for CentraSite. See Section 8.4 for details.

enabler.server

The name or IP address of the Enabler server where the datastore for the CentraSite registry and repository is or is to be located. The server is specified and set in the installation.

enabler.datastore

The name of the datastore used for the CentraSite registry and repository. The default is CentraSite.

enabler.port

The port to address the Enabler server. The port is specified and set in the installation.

enabler.user

The user ID with which the datastore for the CentraSite registry and repository is to be created and accessed from the csconfig Web application. The default and recommended user ID is the Interstage ASM system user, asmuser.

If you specify a user ID with a domain, enter a double backslash between the domain name and the user name: DOMAIN\\User.

enabler.autocreation

Specifies whether the datastore for the CentraSite registry and repository is to be created and initialized automatically if it does not exist when the csconfig Web application is started. Valid values for this setting are yes and no, the default is yes. See Section 7.4 below for details on creating the CentraSite registry and repository.

enabler.automigration

Specifies whether the data model and data in the datastore are to be updated automatically when the csconfig Web application is started and it is of a newer CentraSite version. Valid values for this setting are yes and no, the default is yes.

asmcore.url

The URL of the iasmcore<version> Web application in the following format: http[s]://<server>[:<port>]

<server> is the name or IP address of the Web/application server where the iasmcore<version> Web application is deployed, <port> the port to address it. Both values are specified and set in the installation.


federation.url

The URL of the federation Web service in the following format: http[s]://<server>[:<port>]/csfederation/services/Federation

<server> is the name or IP address of the Web/application server where the csfederation Web application is deployed, <port> the port to address it. Both values are specified and set in the installation.

If you want to use registry federations, remove the comment sign (#) preceding the entry and adapt the value as required. For details on configuring registry federations, see Section 7.9 below.

securestore

The absolute path and name of the CentraSite password store. This file is used by the csconfig and csfederation Web applications to store users with their encrypted passwords and the federation user (see Section 7.9). The file is created automatically at the first start of the csconfig Web application, and the Interstage ASM system user, asmuser, and its password are stored in it.

The default password store is the secureStore.properties file in the temporary directory which is set for the Java virtual machine used by the Web/application server (java.io.tmpdir Java system property). The default is used when the securestore keyword is not defined at all or commented in the CentraSite.properties file, or when it is defined with an empty value. We recommend you specify a path and file which can be accessed by administrators only. Use slashes (/) or double backslashes (\\) as separators in the path.

For details on how to administer the CentraSite password store, see Section 7.6.

You can change the settings in the CentraSite.properties file at any time. Be aware that changes may require modifications in other Web applications, too. For example, changing the datastore requires modifications in the WebDAV interface.

For changes in the CentraSite.properties file to become effective, restart the csconfig Web application.

7.3 Executing CentraSite Administration Functions Apart from providing basic settings, the csconfig Web application is used to execute administration functions in CentraSite. When the Web application is running, you can execute the following functions from any Web browser:

• Add and list users in the CentraSite password store.

• Obtain the state of the csconfig Web application.

For invoking administration functions, you enter a call with the following basic syntax in the address field of your Web browser: http[s]://<server>[:<port>]/csconfig/admin?ADM=<type>&CMD=<cmd>[&<param>]


<server> is the name or IP address of the Web/application server, <port> the port to address it. <type> specifies the type of administration function to call (suser or state), <cmd> is the name of the administration function, <param> are one or more parameters of the administration function.

Details of the suser administration functions and the appropriate call syntax are provided in Section 7.6 below.

With the following administration function, you can obtain the state of the csconfig Web application: http[s]://<server>[:<port>]/csconfig/admin?ADM=state&CMD=get

One of the following states is returned:

State Description

INIT The Web application is starting up.

OK The start-up has finished without problems.

WARNING The start-up has finished but parts of the system are not operational.

ERROR The start-up failed with a problem that cannot be solved. CentraSite cannot be used.

7.4 Creating a CentraSite Registry and Repository Creating a CentraSite registry and repository involves the following steps:

1. Creating the underlying datastore and initializing it with the CentraSite data model.

2. Defining an appropriate WebDAV share in the WebDAV interface.

These steps are described in detail in the following sections.

Step 1: Creating and Initializing the Datastore The datastore for the CentraSite registry and repository is created and initialized automatically, if it does not yet exist, when the csconfig Web application is started. This is determined by the setting of the enabler.autocreation property in the CentraSite.properties configuration file, which by default is yes (see Section 7.2).

The datastore is created with the name and on the Enabler server specified in the CentraSite.properties configuration file. The datastore parameters are set as described in Section 3.4.

Step 2: Defining the WebDAV Share For each datastore used as CentraSite registry and repository, a WebDAV share must be defined in the configuration file of the WebDAV interface, appconfig.xml. This is described in detail in Section 8.3.


After installation, the appconfig.xml file contains a default datastore and WebDAV share definition for CentraSite. These can be used without adaptation, if you keep the pre-set values for the datastore server and name in CentraSite.

If you do not use these defaults, for example, if you use a datastore with a different name, you have to:

• Create appropriate datastore and share definitions in the appconfig.xml file.

• Adapt the webdav.path setting in the CentraSite.properties configuration file accordingly.

7.5 Administering the Registry and Repository The datastore you use for the CentraSite registry and repository should be backed up, checked and reorganized at regular intervals. To do this, use the corresponding Enabler administration functions. See Section 3.7 and 3.8 for details.

Enabler functions can also be used for starting and stopping the datastore; see Section 3.6 for details.

If you no longer need the datastore at all, you can delete it using Enabler administration functions; see Section 3.11 for details.

7.6 Administering the CentraSite Password Store The CentraSite password store is a file which is used by the csconfig and csfederation Web applications to store users with their encrypted passwords and the federation user. The file is created automatically at the first start of the csconfig Web application, and the Interstage ASM system user, asmuser, and its initial password are stored in it. Any users you specify when defining federation sites (see Section 7.9) are also added to the password store.

By calling the following CentraSite administration function, you can list the users currently contained in the password store: http[s]://<server>[:<port>]/csconfig/admin?ADM=suser&CMD=list

With the following CentraSite administration function, you can add a user with his/her password to the password store or change the password of an existing user: http[s]://<server>[:<port>]/csconfig/admin?ADM=suser&CMD=set &user=<user ID>&password=<password>

<user ID> is the user's ID (format: <domain>\<user_name> or <user_name>), <password> is the plain-text password (max. 32 bytes). The password is encrypted automatically.

Adding a user to the password store or changing the password is required in the following situations:

• You want to change the password of the Interstage ASM system user, asmuser.


• You specify a user other than asmuser for the enabler.user setting in the CentraSite.properties configuration file of the csconfig Web application – see Section 7.2. In this case, you must add the specified user with his/her password to the CentraSite password store.

• You want to use a federation user other than asmuser. In this case, you must add the user with his/her password to the CentraSite password store. Additionally, you must add or edit the FEDUSER entry in the password store. For details, see Section 7.9.

• You change the location or name of the CentraSite password store. In this case, you must add all required users and passwords to the new password store.

7.7 Enabling Change Notifications CentraSite provides features and functions for notifying users about changes to registry objects: Users can register notification requests for any number of registry objects. Whenever such an object changes, the registered users are notified accordingly.

The notification functionality is provided by the csnotification Web application. In order to use it, you must:

1. Deploy the csnotification Web application.

2. Adapt the Web application's configuration file, notification.properties. In particular, you must activate the notification engine in the engine.autostart setting. For details, see below.

3. Switch on the "Object events" setting for the datastore used as the CentraSite registry and repository. You can do this by modifying the datastore's parameters using Enabler functions (see Section 3.4) or by the activate.objectevents setting in the configuration file of the csnotification Web application (see below).

The notification.properties configuration file of the csnotification Web application is located in the WEB-INF\conf subdirectory of the deployment directory. It has the following initial contents:

configuration.url=http://<server>:<port> centrasite.user=asmuser centrasite.password=<password> engine.autostart=no activate.objectevents=no


configuration.url

The URL to access the CentraSite.properties file in the csconfig Web application in the following format: http[s]://<server>[:<port>]

<server> is the name or IP address of the Web/application server where the csconfig Web application is deployed, <port> the port to address it. Both values are specified and set in the installation.


centrasite.user

The user ID with which the datastore for the CentraSite registry and repository is to be accessed. The user must be a datastore administrator. The default and recommended user ID is the Interstage ASM system user, asmuser.


centrasite.password

The user's password.

engine.autostart

Specifies whether the notification engine is to be started when the Web application is started. Valid values are yes and no. In order to use the notification functionality, you must set the value to yes. The default is no.

activate.objectevents

Specifies whether the "Object events" setting of the datastore used as the CentraSite registry and repository is to be switched on automatically by the notification engine, if required. Valid values are yes and no. The default is no. We recommend you keep this value and manually switch on the "Object events" setting for the datastore.

You can change the settings in the notification.properties file at any time. For changes to become effective, restart the csnotification Web application.

7.8 Configuring the UDDI Interface CentraSite comes with a UDDI interface by which it can be accessed and used like any standard UDDI registry. In this release, CentraSite supports UDDI Version 2.

The UDDI interface is provided by the csuddi Web application. In order to use it, you must deploy the Web application and adapt its configuration file, juddi.properties, if required.

The juddi.properties configuration file is located in the WEB-INF subdirectory of the deployment directory. The file defines various settings most of which must not be changed. Adaptations may be required for the following settings:

juddi.discoveryURL = http://<server>[:<port>]/UDDI/uddiget.jsp? juddi.proxy.adminURL = http://<server>[:<port>]/UDDI/admin juddi.proxy.inquiryURL = http://<server>[:<port>]/UDDI/inquiry juddi.proxy.publishURL = http://<server>[:<port>]/UDDI/publish datastore=CentraSite server=<server> port=<port> user=asmuser password=<password> webdav.url=<url>



juddi.discoveryURL, juddi.proxy.adminURL, juddi.proxy.inquiryURL, juddi.proxy.publishURL

URLs of the UDDI interface. In each of these URLs, <server> must be set to the name or IP address of the Web/application server where the csuddi Web application is deployed, <port> to the port to address it. Initial values are specified and set in the installation.

datastore

The name of the datastore used as the CentraSite registry and repository. The default is CentraSite.

server

The name or IP address of the Enabler server where the datastore for the CentraSite registry and repository is located. The server is specified and set in the installation.

port

The port to address the Enabler server. The port is specified and set in the installation.

user

The user ID with which the datastore for the CentraSite registry and repository is to be accessed. The user must be a datastore administrator. The default and recommended user ID is the Interstage ASM system user, asmuser.


password


webdav.url

The URL of the WebDAV share defined for CentraSite. See Section 8.4 for details.

You can change the settings in the juddi.properties file at any time. For changes to become effective, restart the csuddi Web application.


7.9 Setting up Registry Federations CentraSite provides support for federated registries. The registries participating in a federation can be different CentraSite registries as well as any UDDI-compliant registries.

Federation support in CentraSite is based on the replication of registry objects: From any remote CentraSite or UDDI registry, you can obtain read-only copies of registry objects you are interested in and store them in the registry of your local CentraSite environment where you intend to access and navigate them. Synchronization mechanisms ensure that your copies are always kept up-to-date as the original objects may undergo changes in their registry.

Federation in CentraSite is based on mediators which perform the data transfer and synchronization between the local and remote registries. For each type of registry (CentraSite, UDDI), a specific type of mediator is used.

The federation functionality is provided by the csfederation Web application which includes a Web service and the mediators. The Web service is initialized at the start-up of the csconfig Web application.

Setting up registry federations involves the following steps:

1. Deploy the csfederation Web application.

2. Adapt the Web application's configuration file, federation.properties.

3. Add the federation user to the CentraSite password store, if required.

4. Activate the federation functionality in the csconfig Web application.

5. Define federation sites in the local CentraSite registry.

The sections below describe how to execute each of these steps.

Step 1: Deploying the Federation Web Application You deploy the csfederation Web application on a Web/application server in the CentraSite environment of the local registry to which you want to replicate objects from remote CentraSite or UDDI registries. You must use the same Web/application server as for the csconfig Web application of this CentraSite environment (see Section 7.1).

Step 2: Adapting the Federation Configuration File The federation.properties configuration file defines the settings of the csfederation Web application. The file is located in the WEB-INF\conf subdirectory of the Web application's deployment directory. It has the following initial contents:

secureStore= removeSuccessfulJobsFromQueue=no localRegistryURL=http://<server>:<port>/CentraSite



secureStore

The absolute path and name of the CentraSite password store. This file is used by the csconfig and csfederation Web applications to store users with their encrypted passwords. For federations, it stores the federation user (see step 3 below) as well as the users specified when configuring federation sites.

Specify the same password store here as in the CentraSite.properties file of the csconfig Web application (see Section 7.2). The password store is created automatically at the first start of the csconfig Web application, and the Interstage ASM system user, asmuser, and its password are stored in it.

For details on how to administer the CentraSite password store, see Section 7.6.

removeSuccessfulJobsFromQueue

Specifies whether federation jobs are to be removed automatically from the job queue when they have been completed successfully. Valid values are yes and no. The default is no.

localRegistryURL

The URL of the local CentraSite registry to which objects of other registries are to be replicated. Specify the URL in the following format:

http://<server>:<port>/<datastore>

<server> is the name or IP address of the Enabler server hosting the datastore used for CentraSite, <port> is the port to address it, <datastore> is the name of the datastore (default: CentraSite). Values for <server> and <port> are specified and set in the installation.

You can change the settings in the federation.properties file at any time. For changes to become effective, restart the csfederation Web application.

Step 3: Adding the Federation User to the CentraSite Password Store The federation user is the user who is to become the owner of the replicated objects in the local CentraSite registry. The user must be a datastore administrator and should not work with the CentraSite registry as a normal user. The preset and recommended federation user is the Interstage ASM system user, asmuser.

The federation user must be entered in the CentraSite password store as follows:

• The user ID must be specified in the FEDUSER entry: FEDUSER=<user ID>

For example, FEDUSER=asmuser


If the required entry does not exist in the CentraSite password store, add or change it manually using a text editor of your choice. If you specify a user ID with a domain, enter a double backslash between the domain name and the user name: DOMAIN\\User.

• An entry for the user ID and its password must exist. To create or modify this entry, use the suser set CentraSite administration function. This is described in detail in Section 7.6.

Step 4: Activating Federation in the csconfig Web Application The Web service of the csfederation Web application is initialized and controlled by the csconfig Web application. For this to happen, federation must be activated in the csconfig Web application.

You do this by uncommenting the federation.url property in the CentraSite.properties configuration file and adapting its value as required. For details, see Section 7.2.

The next time you start the csconfig Web application, the federation Web service will be initialized properly.

Step 5: Defining Federation Sites After you have successfully deployed and configured the csfederation Web application, you can define the federation sites, i.e. the remote registries from where you want to retrieve objects, in your local CentraSite registry.

You can do this from any Interstage ASM client using the client interface. As a prerequisite, the CentraSite plug-ins including the federation user interface plug-in, com.centrasite.gui.federation, must be installed.

The federation user interface plug-in is required only for defining and maintaining federation sites and federation jobs. It is not required for standard CentraSite users who only want to navigate and access the replicated objects.

For details on defining and maintaining federation sites and on replicating objects, refer to the CentraSite User Guide.


8 WebDAV Interface Configuration The WebDAV interface of Interstage ASM is made available by the Enabler WebDAV services and used in SCM and CentraSite. The Enabler WebDAV services provide folder/file views of the data stored in a repository. Via WebDAV shares, the folders and files can be accessed from any WebDAV-compatible client (e.g. Microsoft Internet Explorer or Microsoft Office) in any Internet location. In SCM, you can define a WebDAV share for each protected configuration and access the folders and files in read-only mode. CentraSite uses WebDAV shares to provide its repository functionality.

The following sections describe concepts and tasks related to the installation and configuration of the Enabler WebDAV services in Interstage ASM:

• Installation and deployment of the WebDAV services

• General configuration settings for the WebDAV services

• Definition of WebDAV shares for CentraSite and SCM

• Access to WebDAV shares and the folders and files they contain

• Deletion of WebDAV shares

For details on the Enabler WebDAV services as such, refer to the Enabler WebDAV Services manual.

8.1 Installing and Deploying the WebDAV Interface The Enabler WebDAV services are provided by the EnWebDAV Web application. You can install and deploy this Web application in the same way as any of the Interstage ASM Web applications. This is described in detail in Chapter 6.

8.2 General Configuration of the WebDAV Interface After deploying the Web application, take the following steps in the deployment directory:

1. Delete any files in the WEB-INF\logs subdirectory.

2. Configure the logging of the Enabler WebDAV services as required in the following file in the deployment directory: WEB-INF\classes\log4j.properties At least enter the absolute path and name for the Enabler WebDAV services’ log file, EnWebDAV.log, in the following line. Use slashes (/) or double backslashes (\\) as separators in the path: log4j.appender.R.File = <path>\\EnWebDAV.log

You may additionally change the log level in the following line: log4j.rootLogger=<log_level>, stdout, R

The default log level is INFO, which means that information messages and errors are logged. You may change this to ERROR (log errors only) or DEBUG (log information messages, errors and debug information).


8.3 Defining WebDAV Shares The Enabler WebDAV services provide folder/file views of the data stored in a repository. You can define any number of so-called WebDAV shares, which specify the entry points to the repositories and thus the folder and file structures.

You define WebDAV shares in the Enabler WebDAV services configuration file, appconfig.xml. This file is located in the WEB-INF\conf subdirectory of the Web application's deployment directory.

You can use any XML or text editor to modify the configuration file. After editing the appconfig.xml file, restart the Web application for the changes to become effective.

The following sections describe the definitions required for WebDAV shares to be used with CentraSite and SCM. For more details on the sections and entries in the appconfig.xml file, refer to the Enabler WebDAV Services manual.

8.3.1 Defining a WebDAV Share for CentraSite A CentraSite environment includes one registry and repository in a single Enabler datastore. Accordingly, you define exactly one WebDAV share.

The table below describes the settings and values required for this WebDAV share in the individual sections of the Enabler WebDAV services configuration file, appconfig.xml. After installation, the appconfig.xml file contains a default datastore and WebDAV share definition for CentraSite. These can be used without adaptation, if you keep the pre-set values for the datastore server and name in CentraSite.

Section Attribute/Entry Description

Datastore Definition

id Unique alphanumeric identifier for this section

<server> Name and port of the Enabler server hosting the datastore used for CentraSite in the following format: <server>:<port>

<name> Name of the datastore used for CentraSite.

<uid> Name (without domain) of a datastore administrator. Recommendation: asmuser.

<password> Password of the datastore administrator.

<datastore> ... <datastore>

<domain> The logon domain of the datastore administrator, if required. Leave this empty if you use asmuser.

Share Definition

name Unique alphanumeric name of the WebDAV share. Recommendation: CentraSite

datastoreid Identifier of the <datastore> section which defines the datastore to be accessed by this share.

<share> ... </share>

dynamiccontext Specify no.

Entry Point Definition

<objclass> Specify ROOT_CLASS

<objname> Specify rootdir

<root> ... </root>

<objid> Delete this entry or comment it out.

Context Definition

<objclass> Specify Context

<context> ... </context>

<objname> Specify CS

Example  <datastore id="CentraSite"> <server>localhost:9500</server> <name>CentraSite</name> <dbuserinfo> <uid>asmuser</uid> <password>asmuserpasswd</password> <domain></domain> </dbuserinfo> </datastore>  <share name="CentraSite" mappingid="lock-mapping" datastoreid="CentraSite" dynamiccontext="no"> <root> <objclass>ROOT_CLASS</objclass> <objname>rootdir</objname> </root> <context> <objclass>Context</objclass> <objname>CS</objname> </context> </share>


8.3.2 Defining WebDAV Shares for SCM Configurations In SCM, the WebDAV interface can be used for enabling read-only access to protected configurations from any WebDAV client in any Internet location. You can define a WebDAV share for each protected configuration of any SCM project.

The following table describes the settings and values required for these WebDAV shares in the individual sections of the Enabler WebDAV services configuration file, appconfig.xml.


Datastore Definition

id Unique alphanumeric identifier for this section.

<server> Name and port of the Enabler server hosting the SCM repository in the following format: <server>:<port>

<name> Name of the SCM repository.

<uid> Name (without domain) of a datastore administrator. Recommendation: asmuser.

<password> Password of the datastore administrator.

<datastore> ... <datastore>

<domain> The logon domain of the datastore administrator, if required. Leave this empty if you use asmuser.

Share Definition

name Unique alphanumeric name of the WebDAV share.

datastoreid Identifier of the <datastore> section which defines the datastore to be accessed by this share.

<share> ... </share>

dynamiccontext Specify no.

Entry Point Definition

<objclass> Specify _SCM_Configuration

<objname> Specify the name of the SCM project to be accessed by this share.

<root> ... </root>

<objid> Delete this entry or comment it out.

Context Definition

<objclass> Specify _SCM_Context

<context> ... </context>

<objname> Specify a string in the following format consisting of the names of the SCM project, release and configuration to be accessed by this share:

<project>_<release>_<config>

Example

The following example shows the definition of a WebDAV share named SampleBuild1 for the Sample Project SCM project. It relates to the Build 001 configuration of release 1.0 in this project.  <datastore id="ds1"> <server>enabler1:9500</server> <name>Sample</name> <dbuserinfo> <uid>asmuser</uid> <password>asmuserpasswd</password> <domain></domain> </dbuserinfo> </datastore>  <share name="SampleBuild1" mappingid="lock-mapping" datastoreid="ds1" dynamiccontext="no"> <root> <objclass>_SCM_Configuration</objclass> <objname>Sample Project</objname> </root> <context> <objclass>_SCM_Context</objclass> <objname>Sample Project_1.0_Build 001</objname> </context> </share>


8.4 Working with WebDAV Shares In CentraSite, you can access the WebDAV share defined for the datastore directly at the client interface. For example, you can navigate and manipulate the folders and files in the Repository Explorer view and the Contents view. For details, refer to the CentraSite User Guide.

Additionally, the CentraSite WebDAV share as well as all other WebDAV shares defined with the WebDAV interface can be accessed from any WebDAV compatible client using a URL in the following format:

http://<server>[:<port>]/EnWebDAV/<share>

<server> is the name of the Web/application server where the WebDAV interface has been deployed, <port> the port used to address it, <share> the name of the share defined in the Enabler WebDAV services configuration file, appconfig.xml.

For example:

http://mywebserver:8080/EnWebDAV/SampleBuild1

On Windows, you can map a network drive to a WebDAV share, for example, using Tools > Map Network Drive in Windows Explorer. In the Map Network Drive dialog box, select the option to sign up for online storage or connect to a network server. In the Add Network Place wizard, specify the URL for accessing the WebDAV share. After entering your user ID and password valid for CentraSite or SCM, you can navigate the WebDAV share like any file system in Windows Explorer.

Another possibility is to access a WebDAV share in Internet Explorer: Choose File > Open. In the dialog box, enter the URL of the WebDAV share and specify that you want to access it as a Web folder. You can then navigate the share's contents like any file system.

Using WebDAV compatible tools like Microsoft Office tools, you can view the contents of the files on the WebDAV share.

8.5 Deleting WebDAV Shares To delete a WebDAV share, remove its definition from the Enabler WebDAV services configuration file, appconfig.xml. Stop and restart the Web application for the changes to come into effect.


9 Interstage BPM Integration In LCM, any work you carry out on applications, services, requirements, change requests, releases and iterations is controlled by processes. Process control ensures that all tasks are conducted properly, in time and by the appropriate persons.

With the Enterprise Edition of Interstage Application Development Cycle Manager, processes used in LCM can be defined and executed in Interstage BPM. Interstage BPM provides the tools to define the processes as well as the execution environment. LCM manages links to the processes and the data related to the activities in its repository. It also provides the user interface for working on the activities and the mechanisms to synchronize with Interstage BPM.

The following sections describe concepts and tasks which relate to setting up and maintaining the environment for the integration of LCM and Interstage BPM:

• Installation of the LCM/BPM integration software on a system

• Integration of LCM definitions and libraries in Interstage BPM

• Deployment of the LCM/BPM integration Web application

• Maintenance of the host name, user IDs and passwords required for LCM/BPM interaction

For details on how to define processes for LCM in Interstage BPM, refer to the Interstage ASM Customization Guide.

9.1 Installing the LCM/BPM Integration Software With the Interstage ADM server installer, you can install all the software, which is required to integrate LCM with Interstage BPM, to a single directory on a system of your choice. This can be the system where the Interstage BPM software is installed or any other system in your network. From this system, you can copy and integrate the LCM libraries and definitions into the appropriate Interstage BPM installation directories and deploy the LCM/BPM integration Web application.

The Interstage ADM server installer copies the libraries and definitions to the ibpm subdirectory of the server software installation directory on the target system. The ibpm directory has the following substructure:

• serverinstance : Contains directories with files which must be copied to the same directories in the Interstage BPM server installation directory.

• studio : Contains directories with files which must be copied to the same directories in the Interstage BPM Studio installation directory.

• webapps : Contains the LCM/BPM integration Web application, ilcm<version>.

For details of the installation, refer to the Interstage ADM Installation Instructions.


9.2 Integrating LCM Definitions and Libraries in BPM Interstage BPM processes which are to be used with LCM must follow certain conventions and apply specific custom nodes and actions which are provided by LCM. The definitions of the node and actions as well as the libraries required for their execution and for the synchronization between Interstage BPM and LCM must be integrated in the Interstage BPM environment.

This requires the following steps:

1. Copy the libraries and definitions to the Interstage BPM Studio and server installation directories.

2. Merge the LCM custom node definition into the Interstage BPM definitions.

3. Add LCM libraries to the library list of Interstage BPM Studio.

Each of these steps is described in more detail below.

Step 1: Copying Libraries and Definitions to Interstage BPM From the directory to which you have installed the LCM/BPM integration software (see Section 9.1), copy:

• The contents of the studio subdirectory to the installation directory of Interstage BPM Studio on each system where you want to design processes for LCM.

• The contents of the serverinstance subdirectory to the installation directory of the Interstage BPM server where the processes are to be executed.

The substructures of the studio and serverinstance directories are the same as those of the Interstage BPM directories. This means that you can simply copy each subdirectory to the corresponding Interstage BPM directory. Doing so will not overwrite or damage existing Interstage BPM structures or files.

Step 2: Merging Node Definitions LCM provides its own custom node for integration into Interstage BPM processes. Using Interstage BPM Studio, you can design processes which include this custom node. The definition of the custom node is stored in the following file in the Interstage BPM Studio installation directory:

ibpm\ApplicationCore\ledev\Config\CustomNodesDef.ASM-add.xml

You must merge the contents of this file into the following standard file of Interstage BPM Studio using any text or XML editor:

ibpm\ApplicationCore\ledev\Config\CustomNodesDef.xml


Step 3: Adding Libraries to the Library List of Interstage BPM Studio LCM provides libraries in the following directory of Interstage BPM Studio:

bin\plugins\com.fujitsu.iflow.studio_<version>\libCustomNodes

You must add these libraries to the library list in the Bundle-ClassPath parameter in the following manifest file:

bin\plugins\com.fujitsu.iflow.studio_<version>\META-INF\MANIFEST.MF

For your convenience, LCM provides the MANIFEST.ASM-add.MF file in the same directory from where you can copy the entries to the MANIFEST.MF file.

After the adaptation, the MANIFEST.MF file will look as follows:

Manifest Version: 1.0 ... Bundle-ClassPath: com.fujitsu.iflow.studio.jar, ... libCustomNodes/lcmprocessclient.jar libCustomNodes/persistence.jar libCustomNodes/core.jar libCustomNodes/org.eclipse.emf.common_<version>.jar ...

After you have made the above adaptations, you must restart Interstage BPM Studio with the –clean option, for example:

C:\Fujitsu\InterstageBPM_studio\bin\IBPMStudio.exe -clean

The LCM custom node is now available in Interstage BPM Studio in the palette for designing processes.

9.3 Deploying the LCM/BPM Integration Web Application For working with Interstage BPM processes in LCM and for constant synchronization of the process activities, the LCM/BPM integration Web application, ilcm<version>, is required.

When you install the LCM/BPM integration software, the .war file and directory of this Web application are made available in the ibpm\webapps subdirectory of the Interstage ASM server software installation directory (see Section 9.1).

From this directory, you can deploy the Web application in the same way as any of the Interstage ASM Web applications. This is described in detail in Chapter 6. Use the same or at least the same type of Web/application server as for the deployment of Interstage BPM.

You can check whether the deployment of the ilcm<version> Web application was successful by addressing the following URL in a Web browser: http[s]://<server>[:<port>]/ilcm<version>/lcmibpm?action=healthcheck

<server> is the name or IP address of the Web/application server, <port> the port to address it.


If the deployment was successful, the Web browser displays messages like: com.fujitsu.asm.lcm.process.ibpm.remif.LCMIBPMServlet is reachable Connection to LCM resource......not checked Connection to IBPM API......not checked

When you add the following parameters to the URL, the connection to the LCM repository and to the Interstage BPM server is checked in addition: &lcmhost=<rep_server>&lcmport=<rep_server_port> &lcmrepository=<rep_name>&lcmremifurl=<asmcore_url>

<rep_server> is the name or IP address of the Enabler server hosting the LCM repository, <rep_server_port> the port to address it. <rep_name> is the name of the LCM repository. <asmcore_url> is the URL to address the iasmcore<version> Web application in the format http[s]%3a//<server>[%3a<port>].

9.4 Maintaining Host Names, User IDs and Passwords For the interaction of Interstage BPM and LCM, two user IDs are required:

• Interstage BPM accesses LCM with the user ID of the Interstage ASM system user, asmuser.

• LCM accesses Interstage BPM with the ID of a valid Interstage BPM user with administrator privileges.

In addition, LCM must know the host name of the system where the Interstage BPM server is installed.

You can specify the host name, user IDs and passwords when you install the LCM/BPM integration software. For details, see the Interstage ADM Installation Instructions. The host name, user IDs and passwords are stored in the following files:

• asmlogin.properties – stores the Interstage ASM system user

• ibpmlogin.properties – stores the Interstage BPM host name and user

Both files are required and stored in the following locations:

• WEB-INF\lib subdirectory of the LCM/BPM integration Web application's deployment directory.

• server\instance\default\lib\ext subdirectory of the Interstage BPM server installation directory.

If you want to change the users' passwords or if you want to switch to a different Interstage BPM user or host name, you must edit the relevant .properties files in all places.

To change a user's password, type the new password in plain text in the following line: password=<type the new password here>

The new password is encrypted automatically when the .properties file is accessed for the first time by LCM or Interstage BPM. The encrypted password is written to the following line in the file, and the plain text password is removed. encodedPassword=<encrypted password>


10 Bugzilla Integration Bugzilla is one of the most popular bug tracking systems, which can be used for incident reporting and management. Bugzilla bugs provide status information that allows you to check how work on an incident progresses and who is responsible for it.

The change management of LCM can be integrated with Bugzilla: When a bug is reported in Bugzilla, a corresponding change request can be automatically created and linked to the bug in Bugzilla. Bugzilla is the master, and information about bugs (e.g. status, priority, assigned user) can be continuously synchronized in LCM. All change requests for Bugzilla bugs follow a predefined process, Bugzilla, which has one activity and several exits according to bug statuses.

For integrating Bugzilla with LCM, the following steps are required:

• Preparing the Bugzilla integration plug-in and the command line interface.

• Configuring applications, services and releases in LCM for the Bugzilla integration.

• Continuously synchronizing the information in LCM with Bugzilla.

The sections below describe how to execute each of these steps. They are preceded by a description of how actions and data in Bugzilla are reflected in LCM.

10.1 Mapping of Bugzilla Actions and Data to LCM When the Bugzilla integration has been configured correctly, each synchronization maps actions and data of Bugzilla bugs to the corresponding change requests of the relevant application or service in LCM.

Mapping of Actions Creating a new bug in Bugzilla does not automatically create a change request in LCM. Instead, a change request is created only when a bug's status is changed to ASSIGNED.

In LCM, the process for Bugzilla change requests, Bugzilla, is started. This process defines one activity, Implement, which is activated. The responsible user for the change request and the activity is set to the person having the same email address as the bug's assignee in Bugzilla. If this person does not exist, the responsible users are by default all users with the Developer role of LCM (see also Section 10.3.3 and 10.5).

When work for a bug is finished, the developer changes the bug's status in Bugzilla to RESOLVED with a corresponding resolution: FIXED, INVALID, WONTFIX, LATER, REMIND, DUPLICATE, WORKSFORME, or MOVED. With the next synchronization between LCM and Bugzilla, the process assigned to the change request in LCM is completed with a corresponding exit: Fixed, Invalid, WontFix, Later, Remind, Duplicate, WorksForMe, or Moved.


Other Bugzilla status changes (e.g. to VERIFIED or REOPENED) are not reflected in LCM, since these are not related to actual development or authoring work but rather to bug management.

Mapping of Data In LCM, properties and assignments of change requests are set and updated according to the data of the corresponding bugs in Bugzilla. Existing change requests are updated as long as they are not completed, i.e. as long as the Implement activity of the assigned process is active.

The following table provides an overview of the data mapping between bugs in Bugzilla and change requests in LCM:

Bugzilla Bug Change Request Remark

--- Name The change request name is generated by LCM.

Bug number and Summary

Short Description The Bugzilla bug number and summary are concatenated in the change request's short description, separated by a blank. The bug number is converted to a 5-digit number by prepending as many 0 characters as required. In the synchronization command, a prefix can be specified, which is prepended to this number. See the command description in Section 13.5 for details.

If the formatted bug number and summary exceed 128 bytes, the summary text is truncated accordingly in the change request's short description. This is indicated by three dots (...) at the end of the short description.

Priority Priority

Assigned to Responsible User The responsible user of the change request is set to the user having the same email address as the assignee of the Bugzilla bug. If this person does not exist, the responsible users are by default all users with the Developer role of LCM (see also Section 10.3.3and 10.5).

Product, Component

Assignment to an application or service

The mapping is as defined when configuring applications or services for Bugzilla in LCM (see Section 10.3.2 below).

Version, Target Milestone

Assignment to a release

The mapping is as defined when configuring releases for Bugzilla in LCM (see Section 10.3.2 below).


10.2 Preparations The following preparations are required to integrate Bugzilla with LCM:

• The Bugzilla system must run version 2.16.x, 2.20.x, 2.22.x or 3.0.x.

• The LCM Bugzilla integration plug-in, com.fujitsu.asm.lcmbugzilla, must be available at the client interface of at least one Interstage ASM client. The LCM Bugzilla integration plug-in is required for configuring applications, services and releases for Bugzilla in LCM (see Section 10.3 below). If users want to display Bugzilla bugs from the Interstage ASM client interface (Link to Bugzilla option in change request context menu), they also need this plug-in. To install the plug-in, proceed as described in Section 11.1.1.

• The Interstage ASM command line interface must be installed on at least one machine, and have access to the relevant LCM repositories as well as to Bugzilla (via HTTP or HTTPS). On this machine, the elcmbug.bat batch file (Windows) or elcmbug.sh shell script (UNIX/Linux), which is part of the command line interface, is executed to synchronize the information in LCM with Bugzilla (see Section 10.4 below). To install the command line interface, proceed as described in Section 11.2.1.

10.3 Configuring Applications and Services for Bugzilla In LCM, each application and service whose change requests are to be integrated with Bugzilla, must be configured accordingly. The following configuration steps are required:

• Specifying connection data.

• Mapping applications, services and releases to Bugzilla products, components, versions and target milestones.

• Specifying email addresses for users.

All these steps can be performed from the Interstage ASM client interface in the Navigator LCM view if the Bugzilla integration plug-in is available. Each step is described in detail in the following sections.

10.3.1 Specifying Connection Data For each application and service whose change requests are to be integrated with Bugzilla, you need to configure the options below for connecting to the Bugzilla system.

To specify the connection data, open the Properties of the application or service (Properties menu option) and select the Bugzilla page.

Bugzilla URL

The URL used to access the Bugzilla system.


Encoding

The encoding to be used for data transferred between Bugzilla and LCM. By default, the encoding set for the Interstage ASM command line interface is used where the elcmbug.bat batch file or elcmbug.sh shell script is executed.

Proxy Settings

If Bugzilla is to be accessed via a proxy, specify the required data: the user ID with which the connection is to be made, the user's password, the proxy server and its port.

The Check Connection option allows you to verify if your entries are correct and you can connect to Bugzilla.

10.3.2 Mapping Products, Components, Versions, and Milestones For each application and service in LCM, you must specify one or more Bugzilla products to which it is to be related. Additionally, you must specify one or more components of each product to be considered. Only bugs of the specified products and components are taken into account by the synchronization.

For each release of the LCM applications and services, you must specify the Bugzilla versions and milestones which are to be taken into account.

• To specify Bugzilla products and components for an application or service, open its Properties (Properties menu option) and select the Bugzilla page. Use Add to add products and components. With the Remove option, you can remove products and components from the list.

• To specify Bugzilla versions and milestones for a release of an application or service, open its Properties (Properties menu option) and select the Bugzilla page. Use Add to add versions and milestones. With the Remove option, you can remove versions and milestones from the list.

10.3.3 Specifying Email Addresses for Users When a change request is created or updated in response to a Bugzilla activity, LCM tries to set the responsible user to a user with the same email address as the assignee of the Bugzilla bug. To do this, it uses the email addresses that can be specified for each user in the user and role settings for LCM .

To specify or update the email address of a user, select the Applications and Services root node or the application or service in question, choose Users and Roles, and click Update Email.

If the email address of the assignee of a Bugzilla bug does not exist in LCM, the responsible users of the change request are by default all users with the Developer role of LCM.


10.4 Synchronizing Change Requests with Bugzilla For synchronizing the change requests in LCM with the information in Bugzilla, you execute the elcmbug.bat batch file (Windows) or elcmbug.sh shell script (UNIX/Linux), which is part of the Interstage ASM command line interface. The command creates new change requests and updates existing ones as required according to the information in Bugzilla and the configuration options set in LCM.

The syntax and parameters of elcmbug are described in detail in Section 13.6.

You have the following options of automating the synchronization to a great extent:

• Invoke elcmbug at regular intervals (e.g. every 5 minutes) via scheduling functions of the underlying operating system, for example, the AT command on Windows or the cron mechanism on UNIX/Linux.

• Add elcmbug as an extension to Bugzilla using the hook mechanism. In this way, elcmbug can be called each time a bug is updated in Bugzilla. For details on the Bugzilla extension mechanism, refer to the Bugzilla documentation.

10.5 Customizing the Bugzilla Integration Using the customization facilities of Interstage ASM, you can change the following features of the Bugzilla integration to suit your needs:

• Adapt the priorities available for change requests to Bugzilla priorities: By default, change requests and Bugzilla bugs can have a priority between P1 and P5. If Bugzilla defines more or different priorities, you can adapt the corresponding values for change requests accordingly. You do this by modifying the available values for the user-defined attribute, Priority, for change requests in a way that they match the priority values defined in Bugzilla.

• Change the user role of the Implement activity of the Bugzilla process: If the email address of the assignee of a Bugzilla bug does not exist in LCM, the responsible users of the corresponding change request are set to all users with the Developer role of LCM. You can change, extend or remove this default role setting by adapting the roleNames of the Implement activity in the definition of the Bugzilla process. For the Bugzilla integration to work properly, you must not change other elements of the process definition.

For details on how to carry out the above changes, refer to the Interstage ASM Customization Guide.


11 Client Administration The Interstage ASM client software consists of the client interface and the command line interface. The following sections describe tasks related to the installation and configuration of these interfaces.

11.1 Client Interface The Interstage ASM client interface is based on Eclipse technology and implemented as Eclipse plug-ins. As such, it can be installed and operated in the following ways:

• Stand-alone variant: The stand-alone variant is based on the Eclipse RCP (rich client platform) technology. It includes the Eclipse plug-ins of the Interstage ASM components you select for installation as well as all features of the Eclipse Workbench that are required to operate them. This means there is no need to separately install Eclipse.

• Existing Eclipse environment: The Interstage ASM plug-ins can be installed and used within an existing Eclipse environment. Eclipse 3.2 or higher is required.

The available plug-ins and their dependencies are described in detail in the Appendix of this manual.

11.1.1 Installing the Client Interface The installation of the client interface is described in detail in the Installation Instructions of the Interstage ASM products you are using. To summarize, you have the following options:

For installing the stand-alone variant of the Interstage ASM client interface, use the Interstage ASM client installers.

To add the Interstage ASM plug-ins to an existing Eclipse environment, use one of the following options:

• Use the Eclipse update manager (Help > Software Updates > Find and Install). Specify the eclipse directory of the installation media as a local site, and choose the features you want to install.

• Copy the plug-ins from the eclipse\plugins directory of the Interstage ASM installation media or from an existing installation to the plugins directory of your Eclipse installation directory. Eclipse should be stopped when doing this.

Note: You can copy the eclipse directory from the installation media to a central place in your file system or to a Web server. This allows you to update the client installations from this central location.


11.1.2 Configuring the Client Interface At the client interface, users can make various settings for each of the Interstage ASM components. For example, they can set the style sheets for reports or the character encoding for SCA. The settings and options are described in detail in the User Guides for the individual components.

In addition to the component-specific settings, the following general settings can be made:

• Local workspace and configuration directory

• Language of the client interface

• Directory for temporary files

These are described in the following sections.

Local Workspace and Configuration Directory Users of SCM and DMS edit folders and files in a local workspace. This workspace corresponds to the Eclipse workspace. Settings and adaptations users make to their working environment in the Interstage ASM client interface are also stored in this workspace or in the configuration directory set for Eclipse.

When using the plug-ins of the Interstage ASM client interface within an existing Eclipse installation, the workspace and configuration directory set for Eclipse are also used by Interstage ASM.

With the stand-alone variant of the Interstage ASM client interface, the following workspace and configuration directory are used:

• Workspace: You can specify the workspace when you start the Interstage ASM client interface. The workspace you specify can be set as the default one to be used in the future. In this case, you are not asked again for the workspace the next time you start the client interface. Within the Interstage ASM client interface, you can change the workspace at any time using the File > Switch Workspace menu option.

• Configuration directory: The configuration subdirectory of the client interface installation directory is used, for example, C:\Fujitsu\InterstageASM\client\configuration

In specific environments, this behavior may not be suitable. For example, you may want to define workspace directories for all users on a server to back them up regularly. Or, if different users are working on the same system, they may want to use different configuration directories because options and access rights to directories and files set for one user may not be sufficient for other users.


For these reasons, you can define the workspace and configuration directory to be used by default using one of the following options:

• You can call the executable to start the stand-alone variant of the Interstage ASM client interface or Eclipse with the –data and –configuration parameters. –data specifies the workspace, -configuration the configuration directory. For example: iasm.exe –data D:\Data\Smith\workspace –configuration D:\Data\Smith\configuration

• You can specify the –data and –configuration parameters described above in an .ini file, which has the same name and is located in the same directory as the executable used to start the stand-alone variant of the Interstage ASM client interface or Eclipse, for example, iasm.ini for iasm.exe. The .ini file is evaluated when you invoke the executable. For example, an iasm.ini file may have the following entries: -data @user.home\iasm\workspace -configuration @user.home\iasm\configuration

This means that the workspace and configuration directories are created and maintained in each user's home directory, which is identified by @user.home. Note the following:

• Parameters (e.g. –data) and each of their values must be specified in separate lines in the .ini file.

• The settings of a specific parameter in the .ini file are overridden by the settings of the same parameter at the call of the corresponding executable.

• The stand-alone variant of the Interstage ASM client interface comes with an initial .ini file. We recommend you use this file for making the required settings.

When you set a workspace using the –data option, users are not prompted for the workspace at startup of the Interstage ASM client interface. However, they can still switch to a different workspace from within the client interface.

Language of the Client Interface The texts (e.g. menu options, messages, dialogs) of the Interstage ASM client interface are available in English and Japanese. By default, they are displayed according to the language set for the current user in the underlying operating system (Windows: Regional and Language Options; UNIX/Linux: LANG environment variable).

You can explicitly specify the language in the –nl parameter, which is evaluated when you start the stand-alone variant of the Interstage ASM client interface or Eclipse:

–nl <locale>

<locale> is the locale to be set. Use en_US for English, ja_JP for Japanese.


You can set the –nl parameter in an .ini file or at the appropriate executable in the same way as the –data and –configuration parameters described above.

Directory for Temporary Files Interstage ASM stores temporary files in the temporary directory which is set for the Java virtual machine used by the client interface. Especially if you are accessing SCM or DMS repositories in remote mode from the client interface, the temporary directory must provide enough disk space for storing all the data being exchanged.

The temporary directory is specified in the java.io.tmpdir Java system property. On UNIX/Linux, the default value of this property is typically /tmp, on Windows it is often c:\temp.

You can set the system property to a different value in the –vmargs parameter, which is evaluated when you start the stand-alone variant of the client interface or Eclipse. Specify the property with the –D option, such as:

–vmargs –Djava.io.tmpdir=D:\Data\IASM\Temp

You can set the –vmargs parameter in an .ini file or at the appropriate executable in the same way as the –data and –configuration parameters described above.

11.2 Command Line Interface The Interstage ASM command line interface consists of batch files for Windows and shell scripts for UNIX/Linux. It offers the complete SCM functionality as well as basic functionality of other components. You can use the command line interface for batch processing (e.g. create builds in SCM or perform regular source code scans in SCA) as well as for integrating Interstage ASM functionality into third-party tools and solutions without the need for programming.

For details on the command line interface, refer to Chapter 13 and to the Interstage ADM Command Line Interface manual.

11.2.1 Installing the Command Line Interface The installation of the command line interface is described in detail in the Installation Instructions of the Interstage ASM products you are using. To summarize, you have the following options:

• You can install the command line interface using the Interstage ASM server or client installers.

• You can manually copy the contents of the commandline directory on the Interstage ASM installation media to a directory of your choice on any supported system. On UNIX/Linux make sure that all the script files (*.sh) in the installation directory have proper execute rights (x) set.


11.2.2 Configuring the Command Line Interface For optimum use of the command line interface, you can make the following settings:

• Environment variable settings

• Language settings

• Temporary directory settings

These are described in the following sections.

Environment Variables The following environment variables and settings may be useful when working with the command line interface:

PATH

For convenience reasons, the directory where the batch files and shell scripts of the command line interface are located, can be added to the PATH variable.

ASM_VMARGS

Options for the Java runtime environment can be set in this variable, for example, -Duser.language=<id> (see below). The command line interface calls the java executable with these options in the following way:

Windows: %JAVA_HOME%\bin\java %ASM_VMARGS%

UNIX/Linux: $JAVA_HOME/bin/java $ASM_VMARGS

Language of the Command Line Interface By default, the command line interface uses the language set for the executing user in the underlying operating system (Windows: Regional and Language Options; UNIX/Linux: LANG environment variable). If Interstage ASM data handled via the command line interface contain characters of other languages (e.g. Japanese characters), an appropriate language setting should be used. Otherwise, the data may be malformed.

You can use a different language by setting the user.language Java system property accordingly:

-Duser.language=<id>

<id> is the language identifier. It can be set to en for English or ja for Japanese.

You best set the user.language property in the ASM_VMARGS environment variable (see above). Alternatively, you can add it to the call to the java executable in the batch files or shell scripts of the command line interface.


Directory for Temporary Files Interstage ASM stores temporary files in the temporary directory which is set for the Java virtual machine used by the command line interface. Especially if you are using the command line interface in remote mode, the temporary directory must provide enough disk space for storing all the data being exchanged.

The temporary directory is specified in the java.io.tmpdir Java system property. On UNIX/Linux, the default value of this property is typically /tmp, on Windows, it is often c:\temp. You can change the temporary directory by setting the java.io.tmpdir property accordingly, for example:

–Djava.io.tmpdir=D:\Data\IASM\Temp

You best set the java.io.tmpdir property in the ASM_VMARGS environment variable (see above). Alternatively, you can add it to the call to the java executable in the batch files or shell scripts of the command line interface.


12 General Administration Tasks This chapter describes administration tasks which do not relate to a specific component or interface of Interstage ASM, but affect Interstage ASM in general:

• Changing the password of the Interstage ASM system user, asmuser

• Changing ports of server components

12.1 Changing the Password of asmuser You specify the password of the Interstage ASM system user, asmuser, when you install Interstage ASM server or Web components. The user ID and password are stored with several of these components. Therefore, if you want to change the password, you must do this in all of the relevant places.

The following list provides an overview of the places where asmuser and its password are stored. For details and information on how to change the password, refer to the given chapters and sections. The maximum length of the password is 32 bytes.

• user_ident files of Enabler servers. For details, see Chapter 2.

• asmlogin.properties files in the iasmcore<version> and ilcm<version> Web applications and the Interstage BPM server installation directory. For details, see Sections 6.1 and 9.4.

• appconfig.xml file of the WebDAV interface. For details, see Section 8.3.

• *.properties files and password store of CentraSite. For details, see Chapter 7.

• Calls to the commands of the command line interface which are, for example, stored in batch files or shell scripts. For details, see Chapter 13.


12.2 Changing Ports of Server Components The Interstage ASM server components use different TCP/IP ports for their operation. You specify these ports when you install the components.

The following list provides an overview of these ports and describes how you can change them, if required.

• Enabler servers: Each Enabler server has a TCP/IP port to address its service broker. The default port of Enabler servers installed for Interstage ASM is 9500. As long as no repositories exist on the Enabler server, you can change the port by repairing the server installation using one of the Interstage ASM server installers. For details, refer to the Installation Instructions of the Interstage ASM products you are using. After creation of the first repository, the port can no longer be changed. Each repository on an Enabler server has a TCP/IP port of its own. In Interstage ASM, these ports are in the range of 21000-22000. You can change a repository's port at any time by modifying the underlying datastore's parameters. Refer to the Enabler Administration manual for details.

• SCA server: Each SCA server has a TCP/IP port to address its analysis service (default: 9410). You can change this port by updating or repairing the server installation using the Interstage SQA server installer. For details, refer to the Interstage SQA Installation Instructions. Alternatively, you can change the analysis service port manually by editing the following files on the SCA server: WEB-INF\scan.properties in the deployment directory of the isca<version> Web application. analysis\bin\weasyserv.ini in the Interstage ASM server installation directory (e.g. C:\Fujitsu\InterstageASMServer): This file contains the port of the analysis service twice in hexadecimal notation. The changes become effective automatically with the next access to the analysis service.

If you change the port of a specific server component, you have to adapt all places where this port is referenced. This includes, for example, files and links where the port is stored such as configuration files of Web applications or links maintained in repositories. Additionally, all clients must address the server component with its new port.


13 Commands of the Command Line Interface The following sections describe the batch files, shell scripts and commands of the Interstage ASM command line interface, which are of particular relevance for this manual:

• esca scan – Scan Source Code

• esca disassemblejar – Disassemble Java Archives

• eqam collect – Create QAM Measurement

• esindex – Create/Maintain Search Index

• elcmbug – Synchronize LCM with Bugzilla

The command descriptions are preceded by general notes on how to use the command line interface.

For information on how to install and configure the command line interface, refer to Section 11.2. More commands of SCM, DMS and LCM are described in the Interstage ADM Command Line Interface manual.

13.1 Using the Command Line Interface The Interstage ASM command line interface consists of batch files for Windows and shell scripts for UNIX/Linux. The batch files/shell scripts can be called with a predefined set of commands and arguments as parameters. The output is returned via the default output stream and can be scanned and analyzed by the caller.

The following batch files and shell scripts are of relevance in this manual:

• SCA: esca.bat (Windows), esca.sh (UNIX/Linux bash)

• QAM: eqam.bat (Windows), eqam.sh (UNIX/Linux bash)

• Search Indexer: esindex.bat (Windows), esindex.sh (UNIX/Linux bash)

• LCM/Bugzilla Integration: elcmbug.bat (Windows), elcmbug.sh (UNIX/Linux bash)

Invoking Commands For executing a command of the command line interface, you invoke the appropriate batch file or shell script with the required parameters. With every call to a batch file or shell script, you can perform one Interstage ASM command.

A command call generally looks like this (example for SCA commands):

esca [global options] <command> [options] [arguments]

This invokes the command <command> with the esca.bat batch file or esca.sh shell script.


Getting Help A list of all available commands is displayed when you call a batch file or shell script without any options or arguments or with --help:

esca --help

Online help information for a specific command is displayed as follows:

esca –-help <command>

Error Handling The batch files and shell scripts of the command line interface return a value which indicates whether a command has been executed successfully. The following return values are supported:

0 – The command has been executed successfully. 1 – A problem occurred during the execution of the command.

If a problem occurs, an error message is sent to the default error output stream.

Every action, which adds or changes data in a repository, is executed within a transaction. This means that if the action fails, all changes are rolled back and the repository will be in the same state as before.

All actions that modify files or folders outside the repository in a file system (e.g. disassemble Java archives) are not transaction safe. If such an action is interrupted due to a problem, the resulting file system might be inconsistent and must be repaired manually.

Invoking Commands from Batch Files and Shell Scripts You can invoke the commands of the Interstage ASM command line interface from within your own batch files and shell scripts. This allows you, for example, to execute a sequence of commands on the same repository or on different repositories.

On Windows, be aware of the following: All Interstage ASM batch files turn off the command echoing (@echo off). If your batch files require echoing after a call to an Interstage ASM command, you need to turn it on again (@echo on).


13.2 esca scan – Scan Source Code The esca.bat batch file (Windows) or esca.sh shell script (UNIX/Linux) is called with the scan command in order to scan source code on an SCA server and create a corresponding SCA cube.

See Chapter 4 for details and background information on SCA administration and source code scanning.

Command Syntax esca scan -s <server> [-po <port>] -d <repository> -ru <remote URL> -eu <user> -ep <password> -a <sca cube>

Parameters

-s <server>

Name or IP address of the Enabler server hosting the repository which contains the item and configuration data for the SCA cube for which the scan operation is to be carried out.

-po <port>

Port to access the Enabler server. The default port is 9500.

-d <repository>

Name of the repository which contains the item and configuration data for the SCA cube for which the scan operation is to be carried out.

-ru <remote URL>

The URL of the remote interface in the following format:


<server> is the Web/application server where the iasmcore<version> Web application has been deployed, <port> is the port to address it (default: 80 for HTTP, 443 for HTTPS).

-eu <user>

User ID to be used for connecting to the repository. Use the format for Enabler user IDs.

-ep <password>


-a <sca cube>

Name of the SCA cube for which the scan operation is to be carried out.


13.3 esca disassemblejar – Disassemble Java Archives The esca.bat batch file (Windows) or esca.sh shell script (UNIX/Linux) is called with the disassemblejar command in order to disassemble the classes in Java archives (.jar files) and produce corresponding source definitions.

The SCA scanner for Java source code requires that referenced external classes are accessible as disassembled code, if dependencies to these classes are to be stored correctly in the resulting cube. The scanner requires the source definitions of public and protected members of Java classes as produced by the Sun Microsystems javap tool.

Usually, external classes are provided in Java archives (.jar files). With the disassemblejar command, you can disassemble a specific archive or all archives in a given directory and produce the corresponding source code.

At least the rt.jar of the JRE/JDK in use must be disassembled before scanning Java source code.

Note: The disassemblejar command requires the tools.jar of the Sun JDK. This is included in the JRE installed by the Interstage ASM installers on Windows. If you use your own JRE/JDK, make sure that the tools.jar is available and set the CLASSPATH in the esca.bat batch file or esca.sh shell script accordingly.

Command Syntax esca disassemblejar {-d <directory> | -f <jarfile>} [<output directory>]

Parameters

-d <directory>

Path and name of a directory. All .jar files in this directory are disassembled.

-f <jarfile>

Path and name of a single .jar file that is to be disassembled.

<output directory>

Path and name of the output directory for the disassembled classes. This directory must be specified in the Java Classpath directory setting of the scan configuration. By default, the ..\analysis\scansrc\java directory is used.

Example

Disassemble the rt.jar archive to the C:\InterstageASM\analysis\scansrcdir\java directory:

esca disassemblejar –f ..\jre\lib\rt.jar C:\InterstageASM\analysis\scansrcdir\java


13.4 eqam collect – Create QAM Measurement The eqam.bat batch file (Windows) or eqam.sh shell script (UNIX/Linux) is called with the collect command in order to create a measurement for a QAM assessment based on one or more SCA cubes.

See Chapter 4 for details and background information on SCA administration, source code scanning and QAM measurements.

Command Syntax eqam collect -s <server> [-po <port>] -d <repository> -ru <remote URL> -eu <user> -ep <password> -a <assessment> -mn <measurement name> [-md <measurement date>]

Parameters

-s <server>

Name or IP address of the Enabler server hosting the repository which contains the QAM assessment for which the measurement is to be taken.

-po <port>


-d <repository>

Name of the repository containing the QAM assessment for which the measurement is to be taken.

-ru <remote URL>




-eu <user>

User ID to be used for connecting to the repository. Use the format for Enabler user IDs.

-ep <password>


-a <assessment>

Name of the QAM assessment for which the measurement is to be taken.


-mn <measurement name>

Alphanumeric name for the new measurement.

-md <measurement date>

The date of the measurement in the format yyyy-MM-dd. The default is the current date.

Example

Create a measurement, “FirstMeasurement”, for the “Java” assessment:

eqam collect –s myserver –po 9500 –d sample -ru "http://myserver" –eu Analyst –ep mypassword –a Java –mn FirstMeasurement


13.5 esindex – Create/Maintain Search Index The esindex.bat batch file (Windows) or esindex.sh shell script (UNIX/Linux) is used to create and maintain search indices on a search server.

See Chapter 5 for details and background information on search servers and indices in Interstage ASM.

Note: esindex is not included when you install the command line interface using the client installer of Interstage ADM. The reason is that it can only be executed directly on a search server. To install the command line interface including esindex, use the server installer.

Command Syntax

esindex can be called with the following commands:

create – creates a search index:

esindex create -s <server> [-po <port>] -d <repository> -eu <user> -ep <password> [-p <project or library> [-i <item>]] [-t <index path>] [-l <log file>]

update – updates a search index with data added or changed since last execution

esindex update -s <server> [-po <port>] -d <repository> -eu <user> -ep <password> [-p <project or library>] [-t <index path>] [-l <log file>] [-visible]

delete – deletes data from a search index

esindex delete -s <server> [-po <port>] -d <repository> -eu <user> -ep <password> [-p <project or library>] [-t <index path>] [-l <log file>]

optimize – optimizes a search index

esindex optimize {-s <server> [-po <port>] -d <repository> -eu <user> -ep <password> | -t <index path>} [-l <log file>]


Parameters

-s <server>

Name or IP address of the Enabler server hosting the SCM or DMS repository for which the search index is to be created, updated, deleted or optimized. When optimizing a search index, this parameter need not be specified if the –t <index path> parameter is given.

-po <port>


-d <repository>

Name of the SCM or DMS repository for which the search index is to be created, updated, deleted or optimized. When optimizing a search index, this parameter need not be specified if the –t <index path> parameter is given.

-eu <user>

User ID to be used for connecting to the repository. Use the format for Enabler user IDs. The user must have read access to all data in the repository which are to be included in the index. When optimizing a search index, this parameter need not be specified if the –t <index path> parameter is given.

-ep <password>


-p <project or library>

Name of an SCM project or a DMS library. If specified, the search index will be created, updated or deleted for this project or library only. Otherwise, the index operation will cover all projects or libraries in the repository.

-i <item>

Path and name of a file (document) or folder in an SCM project or a DMS library. Use slashes (/) as path separators. If specified, the search index is created only for all versions of the file or for all file versions in the folder. This parameter requires specification of the relevant project or document library in the –p <project or library> parameter.

-t <index path>

Absolute path and name of the directory where the search index is to be located on the search server. If you do not enter this parameter, the index path specified in the corresponding repository property will be used (see Section 3.5.3).


-l <log file>

Absolute path and name of the log file for the index operation. If you do not specify this parameter, the log is written to the index.log file in the directory given by –t <index path>.

-visible

Updates the search index only for visible versions of files or documents. Without this option, the index for all versions is updated as required.

13.6 elcmbug – Synchronize LCM with Bugzilla The elcmbug.bat batch file (Windows) or elcmbug.sh shell script (UNIX/Linux) is used to synchronize change request information in LCM with Bugzilla.

See Chapter 10 for details and background information on the integration of Bugzilla into LCM.

Command Syntax elcmbug [-all] –s <server> [-po <port>] –d <repository> –p <application or service> -u <user> –w <password> [–f <prefix>] [-l <log file>] -r <remote interface URL>

Parameters

-all

Use this option to update the change requests in LCM with all available data of Bugzilla. Without this option, only data updated in Bugzilla since the last synchronization are taken into account. Use this option with care and in exceptional cases only, for example, when a change request has been deleted by mistake or could not be created due to errors.

-s <server>

Name or IP address of the Enabler server hosting the LCM repository.

-po <port>


-d <repository>

Name of the LCM repository which contains the application or service whose change requests are to be synchronized with Bugzilla.

-p <application or service>

Name of the application or service whose change requests are to be synchronized with Bugzilla.


-u <user>

User ID to be used for connecting to the LCM repository. Use the format for Enabler user IDs. The user must have a role which allows him/her to create and update change requests of the specified application or service.

-w <password>


-f <prefix>

Alphanumeric string to be prepended to the Bugzilla bug number in the short description of the corresponding change request. The bug number is additionally converted to a 5-digit number by prepending as many 0 characters as required. For example, if the bug number is 234, and you specify BUG as the prefix, the bug is identified as BUG00234 in the change request's short description.

-l <log file>

Absolute path and name of the log file for elcmbug. If you do not specify this parameter, the log is written to the bugzilla.log file in the directory where the lcm_bugzilla.jar file is located. This is usually the lib subdirectory of the directory where the Interstage ASM command line interface is installed and from which you call elcmbug.

-r <remote interface URL>





14 Troubleshooting This chapter describes problems you may encounter in Interstage ASM operation and provides details on how to resolve them.

14.1 Repository List Incomplete

Problem Repositories do not appear in a repository list on a client, and the list is shorter than expected.

Cause The length of a repository list is limited to 8 KB. This means that about 120 repositories can be listed.

Use the following formula to calculate in more detail how many repositories will fit in a list: 94 bytes + (34 bytes + <rep1> + <srv>) + ... + (34 bytes + <repn> + <srv>)

<srv> is the length of the repository server name in bytes, <rep1> and <repn> are the lengths of repository names.

Solution You can access repositories even if they do not appear in a list. To obtain complete lists, delete repositories which are no longer needed or move them to another server.

14.2 Insufficient Memory Errors

Problem 1 Searching a large amount of data aborts with a Java OutOfMemory error.

Cause 1 The search service, which is part of the iscm<version> Web application, requires more memory.

Solution 1 Increase the value for the maximum heap size of the Java virtual machine used by the Web/application server on the search server. To do this, use the standard interfaces and procedures of your Web/application server.


Problem 2 Scanning a large amount of source code aborts with a Java OutOfMemory error.

Cause 2 The SCA scan service, which is part of the isca<version> Web application, requires more memory.

Solution 2 Increase the value for the maximum heap size of the Java virtual machine used by the Web/application server on the SCA server. To do this, use the standard interfaces and procedures of your Web/application server.

Problem 3 Search index operations (esindex) or SCM/DMS actions (e.g. commit, update, report) for very large resource structures, or QAM measurements for large amounts of source code result in memory problems at the client (client interface or command line interface).

Cause 3 The Java virtual machine used by the client requires more memory or permanent generation space (PermGen).

Solution 3 Start the client's Java virtual machine with an increased Java heap size or permanent generation space by passing a corresponding value in the –Xmx or -XX:MaxPermSize arguments, respectively, for example, -Xmx1024m –XX:MaxPermSize=1024m.

To pass the arguments to the Java virtual machine, proceed as follows depending on the interface you are using:

• Client interface: Set the arguments in the –vmargs parameter, which is evaluated when you start the stand-alone variant of the client interface or Eclipse, for example: –vmargs –Xmx1024m -XX:MaxPermSize=1024m

You can set the –vmargs parameter in an .ini file that has the same name and is located in the same directory as the executable used to start the stand-alone variant of the client interface or Eclipse. Alternatively, you can specify the parameter with the call to the executable itself. See Section 11.1.2 for details. The initial .ini file which comes with the stand-alone variant of the client interface, sets the –Xmx and -XX:MaxPermSize arguments to 512 MB.

• Command line interface: You best set the –Xmx and -XX:MaxPermSize arguments in the ASM_VMARGS environment variable. For details, see Section 11.2.2.


Appendix: Interstage ASM Eclipse Plug-ins The following table provides an overview of the available Eclipse plug-ins that make up the Interstage ASM client interface. Information on plug-in dependencies (e.g. required plugins) can be found in the META-INF\MANIFEST.MF file of each plug-in.

Software

com.centrasite.gui

Provides the basic user interface of CentraSite.

com.centrasite.gui.adapttorep

Provides the basic functionality of CentraSite.

com.centrasite.gui.ena.ecl

Provides Eclipse extensions for CentraSite.

com.centrasite.gui.federation

Provides the federation user interface of CentraSite.

com.centrasite.jaxr.libs

Provides the JAXR-compliant Java API of CentraSite.

com.fujitsu.asm.chm

Provides the change management functionality of LCM.

com.fujitsu.asm.coc

Provides the basic functionality of COC.

com.fujitsu.asm.coc.ui

Provides the user interface of COC.

com.fujitsu.asm.core

Provides basic functionality for all Interstage ASM components.

com.fujitsu.asm.core.ui

Provides basic user interface features for all Interstage ASM components.

com.fujitsu.asm.dms

Provides the basic functionality of DMS.

com.fujitsu.asm.dms.ui

Provides the user interface of DMS.


com.fujitsu.asm.lcm

Provides the basic functionality of LCM.

com.fujitsu.asm.lcmbugzilla

Provides the functionality for integrating Bugzilla with LCM.

com.fujitsu.asm.lcm.ui

Provides the user interface of LCM.

com.fujitsu.asm.persistence

Provides the persistence layer for LCM, SCA, QAM and COC.

com.fujitsu.asm.qam

Provides the basic functionality of QAM.

com.fujitsu.asm.qam.ui

Provides the user interface of QAM.

com.fujitsu.asm.rcp.ui

Controls the appearance and working environment of the stand-alone variant of the Interstage ASM client interface; required only for the stand-alone variant.

com.fujitsu.asm.rlm

Provides the release management functionality of LCM.

com.fujitsu.asm.rqm

Provides the requirements management functionality of LCM.

com.fujitsu.asm.sca

Provides the basic functionality of SCA.

com.fujitsu.asm.sca.ui

Provides the user interface of SCA.

com.fujitsu.asm.sso

Provides the single sign-on functionality of Interstage ASM

com.fujitsu.asm.sso.ui

Provides the user interface for the single sign-on in Interstage ASM.

com.fujitsu.enabler.eclipse.scm

Provides the basic functionality of SCM.


com.fujitsu.enabler.eclipse.scm.admin

Provides the administration functions of SCM.

com.fujitsu.enabler.eclipse.scm.core

Provides common functionality for SCM and DMS.

com.fujitsu.enabler.eclipse.scm.cvsexport

Provides functions for the migration of CVS projects to SCM.

Note that this plug-in is installed neither with the stand-alone variant of the Interstage ASM client interface nor when using the Eclipse update manager. For using it, you have to copy it manually to an existing Eclipse installation.

com.fujitsu.enabler.eclipse.scm.prodmgmnt

Provides the product management functionality of SCM.

com.fujitsu.enabler.eclipse.scm.ui

Provides the user interface of SCM.

Documentation

com.centrasite.gui.doc

Provides the CentraSite User Guide.

com.fujitsu.enabler.eclipse.scm.doc

Provides the Interstage ADM Software Configuration Management User Guide.

com.fujitsu.asm.coc.ui.doc

Provides the Interstage ASM Control Center User Guide.

com.fujitsu.asm.dms.ui.doc

Provides the Interstage ADM Document Management User Guide.

com.fujitsu.asm.lcm.ui.doc

Provides the Interstage ADM Lifecycle Management User Guide.

com.fujitsu.asm.qam.ui.doc

Provides the Interstage SQA Quality Assessment User Guide.

com.fujitsu.asm.sca.ui.doc

Provides the Interstage SQA Source Code Analysis User Guide.


Glossary

Access Group

A group of users who are allowed to work on an SCM repository, project or product or a DMS repository or document library.

Access Right

The right a user has to an item. The following types of access rights are distinguished: read, write, owner.

Application

A collection of software, procedures and documentation which perform productive tasks for users.

Authority

The permission to execute a single action. Authorities are assigned to roles.

Branch

A development line in an SCM project. Any number of branches can be created based on the same snapshot allowing users to work in parallel on different versions and variants of the same software.

Change Request

A call for a specific adjustment of a service or application, for example, a request to fix a bug in a component of a software product or to modify a specific behavior of a service.

Configuration

A set of resource versions in an SCM project that are managed together. A configuration contains exactly one version of a resource. A specific resource version can be a member of several configurations.

DMS Library

See Document Library.


Document

A file in DMS.

Document Library

A structured collection of documents managed in DMS.

Eclipse

An open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software. For details, refer to http://www.eclipse.org/.

Indicator

A value that is derived from one or more metric values in a well-defined matter and describes the quality of source code.

JAXR – Java API for XML Registries

A standard API for Java platform applications to access and programmatically interact with various kinds of XML-based metadata registries.

Library Edition

A structured collection of document versions in DMS which cannot be changed. An edition serves to save a specific status of a document library. It corresponds to a snapshot in SCM.

Lifecycle

A description of the evolution of entities. A lifecycle defines stages or states that entities may go through as well as transitions between them.

OLAP – Online Analytical Processing

An approach to quickly provide answers to analytical queries that are multidimensional in nature. The core of any OLAP system is an OLAP cube (also called a multidimensional cube or a hypercube).

Process

A set of linked activities that take an input and transform it to create an output.

http://www.eclipse.org/�


Product

A collection of releases of different projects in SCM, which can be managed together.

Registry

A collection of object structures which represent SOA assets in CentraSite.

Release

In SCM, a collection of configurations which represents a specific version, variant or edition of a project. Each SCM project has at least one release.

In RLM, an initial or upgraded version of an application or service including all artifacts which make it complete and functional.

Repository

A logical unit for storing and managing entities as well as the underlying data model. A repository is based on an Enabler datastore, which forms the physical storage unit.

In CentraSite, the term repository is used for a structure of folders and files which describe SOA assets.

Requirement

A documented need of what a particular service or application should be or do in order for it to be of value or use to a stakeholder.

Resource

A folder or file in SCM.

Role

A collection of authorities that control which actions can be carried out by a user to whom the role is assigned.

SCA Cube

An OLAP cube which is the result of a source code scan and the base for source code analyses in SCA and quality assessments in QAM. An SCA cube includes entities that represent source code elements (e.g. programs, variables, statements) as well as their interrelationships.


SCM Project

A structured collection of resources that make up a software product or component managed in SCM. An SCM project has at least one release and one configuration.

Service

A discretely defined set of contiguous or autonomous business or technical functionality, for example, an infrastructure or Web service.

Snapshot

A protected configuration in SCM whose existing assignments of resource versions cannot be changed. A snapshot serves to save a specific status of an SCM project.

SOA – Service-Oriented Architecture

A software architecture that guides all aspects of creating and using business processes, packaged as services, throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes regardless of the operating systems or programming languages underlying those applications.

State

An individual stage of the lifecycle through which configurations pass in SCM.

UDDI – Universal Description, Discovery and Integration

An OASIS standard for Web-based registries that expose information about a business or other entity and their technical interfaces.

Version

An instance of an item serving to record a particular stage in the history of the item.

WebDAV

Web-based Distributed Authoring and Versioning. A set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote Web servers.

interstage application and service management v10 -...

Documents