Interstage Application and Service Management V10

Interstage Application and Service Management V10.0

Customization Guide

B1WD-2481-01ENZ0(00)October 2008

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.

Interstage ASM Customization Guide 2

Contents

1 Customizing Defaults ....................................................... 9

1.1 Roles and Authorities...........................................................................10 1.1.1 Roles and authorities for SCM and DMS................................................11 1.1.2 Roles and authorities for COC, LCM, SCA, QAM and CentraSite .........12

1.2 Repository Settings for SCM ...............................................................13

1.3 SCM Project and DMS Library Settings..............................................14

1.4 SCM Configuration States....................................................................15

1.5 SCM File Type Definitions....................................................................16

2 Localizing Interstage ASM ............................................... 19

2.1 Language-Specific Files.......................................................................19 2.1.1 About Properties .....................................................................................19 2.1.2 Plug-in Properties....................................................................................20 2.1.3 Messages Properties ..............................................................................20 2.1.4 Online Help .............................................................................................22 2.1.5 Report Style Sheets and Phrase Books .................................................24 2.1.6 Web Interface..........................................................................................24

2.2 Translating and Using Language-Specific Files................................25 2.2.1 Properties Files .......................................................................................25 2.2.2 Online Help .............................................................................................25 2.2.3 Report Style Sheets and Phrase Books .................................................25 2.2.4 Web Interface..........................................................................................26

3 Customizing LCM Items and Behavior............................ 27

3.1 Item Types .............................................................................................27

3.2 Association Types ................................................................................29

3.3 Attribute Groups ...................................................................................30

3.4 Attributes ...............................................................................................31

3.5 Dynamic User-Defined Attributes........................................................34

3.6 Attribute Display in Dialog Boxes .......................................................35

3.7 Attribute Display in Views....................................................................37

3.8 Labels for New Attributes and Association Types ............................39


4 Customizing LCM Processes........................................... 41

4.1 Default Processes.................................................................................41

4.2 Process Definitions ..............................................................................42

4.3 Interstage BPM Processes...................................................................44

4.4 Defining Interstage BPM Processes ...................................................45

4.5 Labels for New Process Definitions....................................................46

5 Customizing SCM Behavior ............................................. 48

5.1 Introduction ...........................................................................................48

5.2 Client Interface Properties ...................................................................48 5.2.1 Selectable Repositories ..........................................................................48 5.2.2 Idle Repository Connections ...................................................................49 5.2.3 Partial Check-Out....................................................................................49 5.2.4 Assignment of Non-Browseable Releases .............................................49 5.2.5 Linked Releases......................................................................................49 5.2.6 Interstage Studio.....................................................................................50 5.2.7 Folder Decoration....................................................................................50 5.2.8 Customized Label Decoration.................................................................50

5.3 Client-Specific Properties ....................................................................51 5.3.1 Local Mail Settings..................................................................................51 5.3.2 Line Break Character ..............................................................................51

6 Extending SCM.................................................................. 52

6.1 Extension Hook Types .........................................................................52 6.1.1 BEFORE Extension.................................................................................53 6.1.2 DURING Extension .................................................................................53 6.1.3 AFTER Extension....................................................................................53 6.1.4 Example ..................................................................................................53

6.2 Architecture ...........................................................................................54

6.3 Interface .................................................................................................55

6.4 Defining Extensions .............................................................................55 6.4.1 Local Definition........................................................................................55 6.4.2 Global Definition......................................................................................56 6.4.3 XML Syntax of an Extension Hook Definition File ..................................56

6.5 Implementing Extensions ....................................................................57 6.5.1 Interface ..................................................................................................57 6.5.2 Data Exchange........................................................................................57 6.5.3 Error Handling .........................................................................................60 6.5.4 Logging ...................................................................................................60 6.5.5 Template .................................................................................................63


6.6 SCM Actions Supporting Extensions .................................................64 6.6.1 Assign Subrelease ..................................................................................64 6.6.2 Check Out ...............................................................................................64 6.6.3 Change Item Rights ................................................................................64 6.6.4 Change Project Access Groups..............................................................65 6.6.5 Change Configuration State....................................................................65 6.6.6 Close Release.........................................................................................65 6.6.7 Close Working Branch ............................................................................65 6.6.8 Commit Resources..................................................................................66 6.6.9 Configuration Locks ................................................................................67 6.6.10 Create Release .......................................................................................67 6.6.11 Create Snapshot .....................................................................................67 6.6.12 Create Working Branch...........................................................................68 6.6.13 Create Workspace (Local Resource Monitor).........................................68 6.6.14 Delete Configuration ...............................................................................68 6.6.15 Delete Intermediate Versions..................................................................68 6.6.16 Delete Project..........................................................................................69 6.6.17 Delete Release........................................................................................69 6.6.18 Delete Workspace (Local Resource Monitor) .........................................69 6.6.19 Empty Lost & Found Folder ....................................................................69 6.6.20 Get File Content ......................................................................................69 6.6.21 Mark Resource As Merged .....................................................................69 6.6.22 Reactivate Release.................................................................................69 6.6.23 Rename Configuration ............................................................................70 6.6.24 Rename Project ......................................................................................70 6.6.25 Rename Release ....................................................................................70 6.6.26 Resource Locks ......................................................................................70 6.6.27 Resource Notification Interests ...............................................................70 6.6.28 Retrieve Resources.................................................................................71 6.6.29 Share Project ..........................................................................................71 6.6.30 Update Configuration ..............................................................................71 6.6.31 Update Resources ..................................................................................72

6.7 Core Actions Supporting Extensions .................................................73 6.7.1 Protect Object .........................................................................................73 6.7.2 Delete Object or Version.........................................................................73 6.7.3 Create Object or Version ........................................................................73



About this Manual This manual describes how to customize the components 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 Customizing Defaults Describes how to customize default settings of Interstage ASM components to your own needs.

Chapter 2 Localizing Interstage ASM Describes which files of Interstage ASM contain language-specific entries and how to translate these entries.

Chapter 3 Customizing LCM Items Describes how to customize LCM items and to define how they appear at the client interface.

Chapter 4 Customizing LCM Processes

Describes how to customize the predefined processes of LCM and how to define your own processes.

Chapter 5 Customizing SCM Behavior Describes how to customize default settings for repositories, SCM projects and DMS libraries.

Chapter 6 Extending SCM Describes how to extend the functionality of SCM and how to integrate third-party tools.

Readers of this Manual This manual is written for system administrators and developers who want to change the default behavior of Interstage ASM, extend its functionality, or localize it for a specific national language.

The manual requires basic knowledge of the following:

• Interstage ASM and its components

• The Eclipse software development environment

• Software dialog labels, messages, HTML files, and JSPs

• The Java programming language

• Interstage BPM, if you want to use Interstage BPM processes in LCM and/or model your own Interstage BPM processes

Notational Conventions This manual uses the following notational conventions:

Add The names of graphical user interface elements like menu options and the names of properties in XML files 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

CVS Concurrent Version System

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 Administration Guide: A PDF manual describing the administration and configuration of 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 Customizing Defaults This chapter describes how you can customize the defaults for:

• User roles and authorities which are created for the different Interstage ASM components.

• Settings which are applied when an SCM repository is created.

• Settings which are applied when an SCM project or DMS library is created.

• Configuration states which are defined for a new SCM project.

• File type definitions which are applied to a new SCM project.

XML Files All defaults are defined in XML files, which are described in detail in the sections below. The XML files must be available at least on the Interstage ASM clients from which repositories and component-specific items are created. They must be located in the following directories, depending on the interface being used:

• Client interface (Eclipse): Settings for COC items: plugins\com.fujitsu.asm.coc_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory. Settings for LCM applications and services: plugins\com.fujitsu.asm.lcm_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory. Settings for QAM assessments: plugins\com.fujitsu.asm.qam_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory. Settings for SCA cubes: plugins\com.fujitsu.asm.sca_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory. Repository settings and settings for SCM projects: plugins\com.fujitsu.enabler.eclipse.scm.core_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory. Settings for DMS libraries: plugins\com.fujitsu.asm.dms_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory.

• Command line interface: Settings for DMS libraries: templates\DMS subdirectory of the command line interface installation directory. Settings for LCM applications and services: templates\LCM subdirectory of the command line interface installation directory. Repository settings and settings for SCM projects: templates\SCM subdirectory of the command line interface installation directory.


• Web interface and remote interface: Settings for COC, LCM; SCA and QAM items: templates subdirectory of the iasmcore<version> Web application deployment directory on the Web/application server. Repository settings and settings for SCM projects: templates subdirectory of the iscm<version> Web application deployment directory on the Web/application server. Settings for DMS libraries: templates subdirectory of the idms<version> Web application deployment directory on the Web/application server. Settings for CentraSite registries and repositories: WEB-INF\AttrTempFiles subdirectory of the csconfig Web application deployment directory on the Web/application server.

After installation, these directories contain all XML files which define the defaults for the Interstage ASM components.

Usage of Default Files Do not change any settings directly in the original files, because these may be overwritten when you install a newer version of Interstage ASM. Instead, copy any file you want to change to a new file in the same directory and adapt the new file as required. The new file must have the following name:

<original>_customized.xml

<original> is the name of the XML file provided by Interstage ASM.

The settings in the XML files are read when required, for example, when creating a new repository, project or library. Interstage ASM first tries to read the <original>_customized.xml file. If this file does not exist, it reads the <original>.xml file.

This approach does not apply to CentraSite. Here you carry out customizations in the original files.

1.1 Roles and Authorities When a repository, SCM project or DMS library is created, an initial set of roles and authorities is loaded from the following file and stored in the repository:

roles.xml (or roles_ja.xml for Japanese language setting)

The file defines roles with their assigned authorities. In SCM and DMS it can also be used to define user/role assignments.


You can adapt the default roles by directly editing the roles_customized.xml file. Alternatively, you can export the role definitions of a repository, SCM project or DMS library and copy the results to the roles_customized.xml file. In CentraSite, you always edit the original file.

1.1.1 Roles and authorities for SCM and DMS The roles.xml file for SCM and DMS has the following syntax and contents: <!ELEMENT role> <!ATTLIST role name CDATA #REQUIRED default CDATA #IMPLIED > • name – Unique name of a role.

• default – If set to "1", the role is defined as the default role which is automatically assigned to all users who are not given a role explicitly (default: "0").

<!ELEMENT authority> <!ATTLIST authority name CDATA #REQUIRED > • name – Name of an authority assigned to the role. To obtain all available authorities,

you can use the command line interface. Another way is to define a role with all authorities in a project or library and export this role to an XML file.

<!ELEMENT user> <!ATTLIST user name CDATA #REQUIRED > • name – ID of a user to which a role is to be assigned. <!ELEMENT assignedrole> <!ATTLIST assignedrole name CDATA #REQUIRED > • name – Name of the role which is to be assigned to the user.

Example <roles> <role name="Developer"> <authority name="ACTION_RES_COMMIT"/> <authority name="ACTION_RES_UPDATE"/> <authority name="ACTION_RES_COMMIT_OVR"/> <authority name="ACTION_RES_UPDATE_OVR"/> <authority name="ACTION_RES_REGISTER"/> <authority name="ACTION_RES_CHECK_OUT"/> <authority name="ACTION_CFG_SNAPSHOT"/> <authority name="ACTION_RES_MARKASMERGED"/> <authority name="ACTION_RES_COMPARE"/> <authority name="ACTION_RES_NOTIFICATIONS"/> <authority name="ACTION_RES_LOCK"/> </role> <user name="SERVER1\UserA"> <assignedrole name="Developer"/> </user> </roles>


1.1.2 Roles and authorities for COC, LCM, SCA, QAM and CentraSite The first part of the roles.xml file for COC, LCM, SCA, QAM or CentraSite contains the role definitions. It has the following syntax and contents: <!ELEMENT roles> <!ATTLIST roles name CDATA #REQUIRED creatorGetsRole CDATA #REQUIRED defaultRole CDATA #IMPLIED > • name – Unique name of the role.

• creatorGetsRole – This property is only relevant for LCM and QAM. If set to “true”, the user who creates an application, service or assessment gets the role automatically (default: “false”).

• defaultRole – If set to “true”, the role is defined as the default role which is automatically assigned to all users who are not given a role explicitly (default: “false”).

<!ELEMENT authorities> • authorities – Authority which is assigned to the role (default: EMPTY).

Example <roles name="ProjectManager" creatorGetsRole="true"> <authorities>ViewRelease</authorities> <authorities>EditRelease</authorities> <authorities>ViewChangeRequest</authorities> <authorities>EditChangeRequest</authorities> <authorities>EditAnyChangeRequest</authorities> </roles> <roles name="Guest" defaultRole="true" > <authorities>ViewApplication</authorities> <authorities>ViewService</authorities> <authorities>ViewChangeRequest</authorities> <authorities>ViewRequirement</authorities> <authorities>ViewRelease</authorities> </roles>

The second part of the XML file contains all predefined authorities. They must not be changed. The XML file has the following syntax and contents: <!ELEMENT authorities> <!ATTLIST authorities name CDATA #REQUIRED permission CDATA #IMPLIED > • name – Unique name of an authority.

• permission –Defines whether the authority is valid for a create, delete, write or read action. The PrivilegedRead and PrivilegedWrite permission types represent special privileges for read or write operations. The default setting is Read (default: EMPTY).


Example <authorities name="ReviewRequirement" permission="PrivilegedWrite"/> <authorities name="ViewRequirement"/> <authorities name="CreateChangeRequest" permission="Create"/> <authorities name="DeleteChangeRequest" permission="Delete"/>

1.2 Repository Settings for SCM When you create a repository in SCM or DMS, the default settings defined in the following file are applied:

datastore.xml

XML Syntax and Contents

The XML file has the following syntax and contents: <!ELEMENT settings property*> <!ELEMENT property EMPTY> <!ATTLIST property name CDATA #REQUIRED value CDATA #REQUIRED > • name – Name of a property.

• value – Value of the property.

The following properties are supported:

• mail.enabled – If set to "1", the sending of notification emails is enabled (default: "0").

• mail.host – Name of the SMTP server to be used (default: EMPTY).

• mail.sender – User name under which emails are to be sent (default: "SCM.Mailer").

• mail.senderpwd – User password, if required by the SMTP server (default: EMPTY).

• project.creationRestriction – If set to "1", the creation of new projects is restricted to repository administrators (default: "0").

• deltastorage.enabled – If set to "1", the delta storage for file versions is enabled (default: "0").

• readaccesslogging.enabled – If set to "1", every read access to files is logged, even if the file access was successful. Consider that this function may decrease performance and increase the disk space requirement for log files (default: "0").

Example <settings> <property name="mail.enabled" value="1" /> <property name="mail.host" value="smtpserver1" /> <property name="mail.sender" value="SCM.Mailer" /> <property name="mail.senderpwd" value="12345" /> <property name="project.creationRestriction" value="0" /> <property name="deltastorage.enabled" value="0" /> <property name="readaccesslogging.enabled" value="0" /> </settings>


1.3 SCM Project and DMS Library Settings When you create an SCM project, the default settings defined in the following file are applied and stored with the project in the repository:

project.xml

The file defines default settings for basic project properties as well as name patterns for resources which are to be ignored by the "add to version control" action.

The settings of the taskcontrolled.enabled and adminrolecheck.enabled properties are also applied when you create DMS libraries. The remaining definitions in the XML file are ignored in DMS.


The XML file has the following syntax and contents: <!ELEMENT project property*> <!ELEMENT property EMPTY> <!ATTLIST property name CDATA #REQUIRED value CDATA #REQUIRED > • name – Name of a property.

• value – Value of the property.

The following properties are supported:

• taskcontrolled.enabled – If set to "1", strict change request control will be enabled, which enforces specification of at least one change request for every commit action (default: "0").

• adminrolecheck.enabled – If set to "1", the role check will be enabled for repository administrators (default: "0").

• monitoringrequired.enabled – If set to "1", the monitoring of local changes will be enforced (default: "0").

<!ELEMENT project ignoredresource*> <!ELEMENT ignoredresource EMPTY> <!ATTLIST ignoredresource pattern CDATA #REQUIRED > • pattern – Name pattern with or without wildcards (*, ?) specifying resources which are

to be ignored by the "add to version control" action.


Example <project> <property name="taskcontrolled.enabled" value="0"/> <property name="adminrolecheck.enabled" value="0"/> <property name="monitoringrequired.enabled" value="1"/> <ignoredresource pattern="*.obj"/> <ignoredresource pattern="*.tmp"/> <ignoredresource pattern="*.class"/> <ignoredresource pattern="*~"/> <ignoredresource pattern="*.bak"/> <ignoredresource pattern="Debug"/> </project>

1.4 SCM Configuration States When you create an SCM project, an initial set of configuration states is loaded from the following file and stored with the project in the repository:

states.xml (or states_ja.xml for Japanese language setting)

You can adapt the default configuration states by directly editing the states_customized.xml file. Alternatively, you can export the state definitions of an existing project and copy the results to the states_customized.xml file.


The XML file has the following syntax and contents: <!ELEMENT states cfgstate*> <!ELEMENT cfgstate EMPTY> <!ATTLIST cfgstate name CDATA #REQUIRED type CDATA #IMPLIED unique CDATA #IMPLIED > • name – Unique name of a state.

• type – Identifier of an SCM system state which is represented by this state (default: EMPTY). The following system states and identifiers are available: I – Initial state (in development) R – Released state (released) A – Archived state (archived)

• unique – If set to "1", the state is defined as "unique" (default: "0"). Only one configuration in a release can have such a state at a time. The unique property cannot be changed for system states.

Example <states> <cfgstate name="in development" type="I"/> <cfgstate name="released" type="R"/> <cfgstate name="archived" type="A"/> <cfgstate name="qa" unique="1"/> <cfgstate name="userstate1" unique="0"/> <cfgstate name="userstate2" unique="0"/> </states>


1.5 SCM File Type Definitions When you create an SCM project, an initial set of file type definitions is loaded from the following file and stored with the project in the repository:

filetypes.xml

The file type definitions specify which files are to be handled as text files by SCM. Text files can be merged automatically and be scanned in order to create reports which include statistics information on file contents. File type definitions include name patterns for the files to be considered as well as specifications of which texts to treat as comments instead of source code.

You can adapt the default file type definitions by directly editing the filetypes_customized.xml file. Alternatively, you can export the file type definitions of an existing project and copy the results to the filetypes_customized.xml file.


The XML file has the following syntax and contents: <!ELEMENT filetypes filetype> <!ELEMENT filetype type*> <!ELEMENT type extension* comment* subtype* area param*> <!ATTLIST type name CDATA #IMPLIED > • name – Unique name of a file type definition. This is only required if the file type is

referenced as a subtype in another file type definition. <!ELEMENT extension> <!ATTLIST extension pattern CDATA #REQUIRED > • pattern – Name pattern with or without wildcards (*, ?) specifying the files which are to

be covered by the file type. The association of extensions to file types must be unique. <!ELEMENT comment> <!ATTLIST comment type CDATA #REQUIRED begin CDATA #IMPLIED end CDATA #IMPLIED char CDATA #IMPLIED indicatorcolumn CDATA #IMPLIED match CDATA #IMPLIED >


• type – Type of comment which is described by this element. The following comment types are available: line – Single line comment; all characters from the beginning sequence (begin) until the end of the line are handled as a comment. section – Section comment; all characters between the beginning sequence (begin) and the end sequence (end) are handled as a comment. column – Column comment; if the character in the indicatorcolumn is one of the defined comment characters (char), the whole line is handled as comment.

• begin – One or more characters describing the beginning of the comment (valid for comment types line and section).

• end – One or more characters describing the end of the comment (valid for comment type section).

• char – Comma-separated list of characters which are to be handled as comment characters (valid for comment type column).

• indicatorcolumn – Column number (starting with 1) which is to be checked for the comment characters defined by char (valid for comment type column).

• match – Defines how a given sequence of characters is to be detected within a line (valid for comment types line and section (begin)). The following values can be specified: all – The given sequence may be surrounded by other letters (default). wholeword – The given sequence must be preceded and followed by a whitespace character (space, tab, newline or end-of-line).

<!ELEMENT subtype> <!ATTLIST subtype name CDATA #REQUIRED begin CDATA #IMPLIED end CDATA #IMPLIED match CDATA #IMPLIED > • name – Name of the file type which is described by this subtype.

• begin – Sequence of characters describing the beginning of the subtype (e.g. JAVA within JSP).

• end – Sequence of characters describing the end of the subtype.

• match – Defines how a given sequence of characters is to be detected within a line The following values can be specified: all – The given sequence may be surrounded by other letters (default). wholeword – The given sequence must be preceded and followed by a whitespace character (space, tab, newline or end-of-line).


<!ELEMENT area> <!ATTLIST area startcolumn CDATA #IMPLIED endcolumn CDATA #IMPLIED > • startcolum – First column (starting with 1) of each line in a file to be taken into

account (e.g. COBOL starts at column 7).

• endcolumn – Last column (starting with 1) of each line to be taken into account (e.g. COBOL ends at column 72)

<!ELEMENT param> <!ATTLIST param name CDATA #REQUIRED value CDATA #IMPLIED > • name – Name of a parameter for the file type.

• value – Value of the parameter.

The following parameter is supported:

• linecommentbeforestartcolumn – Defines whether a line comment may occur before the start column (e.g. free style format of COBOL). The value can be “true” (default) or “false”.

Example <filetypes> <type name="java"> <extension pattern="*.java"/> <comment type="section" begin="/*" end="*/"/> <comment type="line" begin="//"/> </type> <type name="jsp"> <extension pattern="*.jsp"/> <comment type="section" begin="<%--" end="--%>"/> <comment type="section" begin=""/> <subtype name="java" begin="<%=" end="%>"/> </type> <type name="cobol"> <extension pattern="*.cbl"/> <extension pattern="*.cobol"/> <area startcolumn="7" endcolumn="72" /> <param name="linecommentbeforestartcolumn" value="true" /> <comment type="column" char="*,/" indicatorcolumn="7"/> <comment type="line" begin="*>"/> </type> </filetypes>


2 Localizing Interstage ASM This chapter describes how to localize and translate the language-specific parts of Interstage ASM to a language of your choice. By default, Interstage ASM is available in English and Japanese.

2.1 Language-Specific Files All language-specific parts of the Interstage ASM client interface (Eclipse plug-ins), such as messages, menus or dialog labels, are stored in the corresponding plug-in directories in one of the following text files:

• about.properties: This file is stored directly in each plug-in directory or the corresponding .jar file.

• plugin.properties: This file is stored directly in each plug-in directory.

• messages.properties: These files are stored in the Java archives (.jar files) in the plug-in directories. The same archives are used by the Interstage ASM Web applications for the Web interface and remote mode connections. In this case, the Java archives are stored in the WEB-INF\lib subdirectory of the relevant Web application deployment directory on the Web/application server.

Additional files to be considered for localization are online help files, report style sheets and the JSP files of the Web interface.

2.1.1 About Properties The following about.properties files exist in the plug-in directories provided by Interstage ASM or in .jar files of CentraSite. The plug-in directories and .jar files are located in the plugins subdirectory of the Eclipse or Interstage ASM client installation directory.

.\com.centrasite.gui_#.jar: about.properties

.\com.fujitsu.enabler.eclipse.scm_#\about.properties

.\com.fujitsu.enabler.eclipse.scm.admin_#\about.properties

.\com.fujitsu.enabler.eclipse.scm.core_#\about.properties

.\com.fujitsu.enabler.eclipse.scm.cvsexport_#\about.properties

.\com.fujitsu.enabler.eclipse.scm.prodmgmnt_#\about.properties

.\com.fujitsu.enabler.eclipse.scm.ui_#\about.properties

.\com.fujitsu.asm.chm_#\about.properties

.\com.fujitsu.asm.coc_#\about.properties

.\com.fujitsu.asm.coc.ui_#\about.properties

.\com.fujitsu.asm.core_#\about.properties

.\com.fujitsu.asm.core.ui_#\about.properties

.\com.fujitsu.asm.dms_#\about.properties

.\com.fujitsu.asm.dms.ui_#\about.properties

.\com.fujitsu.asm.lcm.ui_#\about.properties

.\com.fujitsu.asm.lcmbugzilla_#\about.properties

.\com.fujitsu.asm.persistence_#\about.properties

.\com.fujitsu.asm.qam_#\about.properties

.\com.fujitsu.asm.qam.ui_#\about.properties

.\com.fujitsu.asm.rlm_#\about.properties

.\com.fujitsu.asm.rqm_#\about.properties

.\com.fujitsu.asm.sca_#\about.properties

.\com.fujitsu.asm.sca.ui_#\about.properties

.\com.fujitsu.asm.sso_#\about.properties

.\com.fujitsu.asm.sso.ui_#\about.properties


2.1.2 Plug-in Properties The following plugin.properties and fragment.properties files exist in the plug-in directories or the corresponding .jar files provided by Interstage ASM. The plug-in directories and .jar files are located in the plugins subdirectory of the Eclipse or Interstage ASM client installation directory.

.\com.centrasite.gui_#.jar: plugin.properties

.\com.centrasite.gui.adapttorep_#.jar: plugin.properties

.\com.centrasite.gui.ena.rcp_#.jar: fragment.properties

.\com.centrasite.gui.federation_#\plugin.properties

.\com.fujitsu.centrasite_#\plugin.properties

.\com.fujitsu.enabler.eclipse.scm_#\plugin.properties

.\com.fujitsu.enabler.eclipse.scm.admin_#\plugin.properties

.\com.fujitsu.enabler.eclipse.scm.core_#\plugin.properties

.\com.fujitsu.enabler.eclipse.scm.cvsexport_#\plugin.properties

.\com.fujitsu.enabler.eclipse.scm.prodmgmnt_#\plugin.properties

.\com.fujitsu.enabler.eclipse.scm.ui_#\plugin.properties

.\com.fujitsu.asm.chm_#\plugin.properties

.\com.fujitsu.asm.coc_#\plugin.properties

.\com.fujitsu.asm.coc.ui_#\plugin.properties

.\com.fujitsu.asm.core.ui_#\plugin.properties

.\com.fujitsu.asm.dms.ui_#\plugin.properties

.\com.fujitsu.asm.lcm_#\plugin.properties

.\com.fujitsu.asm.lcm.ui_#\plugin.properties

.\com.fujitsu.asm.lcmbugzilla_#\plugin.properties

.\com.fujitsu.asm.persistence_#\plugin.properties

.\com.fujitsu.asm.qam_#\plugin.properties

.\com.fujitsu.asm.qam.ui_#\plugin.properties

.\com.fujitsu.asm.rcp.ui_#\plugin.properties

.\com.fujitsu.asm.rlm_#\plugin.properties

.\com.fujitsu.asm.rqm_#\plugin.properties

.\com.fujitsu.asm.sca_#\plugin.properties

.\com.fujitsu.asm.sca.ui_#\plugin.properties

.\com.fujitsu.asm.sso_#\plugin.properties

.\com.fujitsu.asm.sso.ui_#\plugin.properties

2.1.3 Messages Properties The following messages.properties files exist in the specified .jar files or plug-in directories provided by Interstage ASM:

CentraSite – com.centrasite.gui_#.jar:

com/centrasite/gui/messages.properties

CentraSite – com.centrasite.gui.adapttorep_#.jar:

com/centrasite/gui/adapttorep/messages.properties

CentraSite – com.centrasite.gui.ena.rcp_#.jar:

com/centrasite/gui/ui/i18n/roles\messages.properties

CentraSite – com.centrasite.gui.federation_# directory

\com\centrasite\federation\ui\util\INMMessages.properties

CentraSite –com.fujitsu.centrasite_#\lib\CentraSiteJAXR.jar:

com/fujitsu/centrasite/resources/messages.properties

com/fujitsu/centrasite/resources/errorMessages.properties

com/fujitsu/centrasite/util/INMMessages.properties


CentraSite – com.fujitsu.centrasite_#\lib\CentraSiteUtils.jar:

com/centrasite/importexport/INMMessages.properties

COC – coc.jar, cocui.jar:

com/fujitsu/asm/coc/i18n/messages.properties

com/fujitsu/asm/coc/ui/i18n/messages.properties

Core – core.jar, coreui.jar, persistence.jar, rcpui.jar:

com/fujitsu/asm/core/cmdline/messages.properties

com/fujitsu/asm/core/i18n/messages.properties

com/fujitsu/asm/core/ui/i18n/messages.properties

com/fujitsu/asm/persistence/ui/i18n/messages.properties

com/fujitsu/asm/rcp/ui/i18n/messages.properties

DMS – dms.jar, dmsui.jar:

com/fujitsu/asm/dms/clif/messages.properties

com/fujitsu/asm/dms/i18n/messages.properties

com/fujitsu/asm/dms/webif/i18n/messages.properties

LCM – lcm.jar, lcmui.jar:

com/fujitsu/asm/lcm/clif/messages.properties

com/fujitsu/asm/lcm/i18n/messages.properties

com/fujitsu/asm/lcm/ui/i18n/messages.properties

LCM Bugzilla integration – lcmbugzilla.jar:

com/fujitsu/asm/lcm/bugzilla/messages.properties

com/fujitsu/asm/lcm/bugzilla/ui/messages.properties

LCM Interstage BPM integration – lcmprocess.jar:

com/fujitsu/asm/lcmprocess/ibpm/client/i18n/ messages.properties

QAM – qam.jar, qamui.jar:

com/fujitsu/asm/qam/i18n/messages.properties

com/fujitsu/asm/qam/ui/i18n/messages.properties

SCA – sca.jar, scaui.jar:

com/fujitsu/asm/sca/cmdline/messages.properties

com/fujitsu/asm/sca/error/messages.properties

com/fujitsu/asm/sca/i18n/messages.properties

com/fujitsu/asm/sca/ui/messages.properties

com/fujitsu/asm/sca/ui/i18n/messages.properties

Search Indexer – indexer.jar:

com/fujitsu/enabler/scm/search/indexer/messages.properties


SCM core – enascm.jar:

com\fujitsu\enabler\scm\messages.properties

com\fujitsu\enabler\scm\navig\messages.properties

com\fujitsu\enabler\scm\cmdlineif\messages.properties

com\fujitsu\enabler\scm\reporting\messages.properties

SCM Web interface – enascmweb.jar:

com\fujitsu\enabler\scm\webif\messages.properties

SCM Client – enascmui.jar:

com\fujitsu\enabler\eclipse\scm\ui\messages.properties

SCM Product Management – escm_prodmgmnt.jar:

com\fujitsu\enabler\eclipse\scm\prodmgmnt\messages.properties

SCM Administration – escm_admin.jar:

com\fujitsu\enabler\eclipse\scm\admin\messages.properties

SCM Migration – escmmigration.jar:

com\fujitsu\enabler\eclipse\scm\Migration\messages.properties

SCM CVS Migration – escmcvsmigration.jar:

com\fujitsu\enabler\eclipse\scm\cvsexport\messages.properties

SCM VSS Migration – escmvssexport.jar:

com\fujitsu\enabler\eclipse\scm\vssexport\messages.properties

SSO – ssoui.jar:

com/fujitsu/asm/sso/ui/i18n/messages.properties

2.1.4 Online Help The online help for the Interstage ASM client interface is provided in separate plug-ins. Language-specific texts are stored in HTML or XML format in files in the corresponding plug-in directories. The plug-in directories are located in the plugins subdirectory of the Eclipse or Interstage ASM client installation directory.

CentraSite:

com.centrasite.gui.doc_#\doc.zip

com.centrasite.gui.doc_#\toc.xml

com.centrasite.gui.doc_#\contexts.xml

com.centrasite.gui.doc_#\contexts_fed.xml

com.centrasite.gui.doc_#\contexts_sso.xml

COC:

com.fujitsu.asm.coc.ui.doc_#\doc.zip

com.fujitsu.asm.coc.ui.doc_#\toc.xml

com.fujitsu.asm.coc.ui.doc_#\contexts_coc.xml

com.fujitsu.asm.coc.ui.doc_#\contexts_core.xml

com.fujitsu.asm.coc.ui.doc_#\contexts_sso.xml


DMS:

com.fujitsu.asm.dms.ui.doc_#\doc.zip

com.fujitsu.asm.dms.ui.doc_#\toc.xml

com.fujitsu.asm.dms.ui.doc_#\contexts_dms.xml

com.fujitsu.asm.dms.ui.doc_#\contexts_addon.xml

LCM:

com.fujitsu.asm.lcm.ui.doc_#\doc.zip

com.fujitsu.asm.lcm.ui.doc_#\toc.xml

com.fujitsu.asm.lcm.ui.doc_#\contexts_lcm.xml

QAM:

com.fujitsu.asm.qam.ui.doc_#\doc.zip

com.fujitsu.asm.qam.ui.doc_#\toc.xml

com.fujitsu.asm.qam.ui.doc_#\contexts_qam.xml

SCA

com.fujitsu.asm.sca.ui.doc_#\doc.zip

com.fujitsu.asm.sca.ui.doc_#\toc.xml

com.fujitsu.asm.sca.ui.doc_#\contexts_sca.xml

SCM:

com.fujitsu.enabler.eclipse.scm.doc_#\doc.zip

com.fujitsu.enabler.eclipse.scm.doc_#\plugin.properties

com.fujitsu.enabler.eclipse.scm.doc_#\toc.xml

com.fujitsu.enabler.eclipse.scm.doc_#\contexts.xml

com.fujitsu.enabler.eclipse.scm.doc_#\ tutorialsExtensionContent32.xml

com.fujitsu.enabler.eclipse.scm.doc_#\cheatsheets\*.xml

The online help of the SCM or DMS Web interface is provided in HTML files which are stored in the help subdirectory of the Web application deployment directory on the Web/application server, for example, <catalina_home>\webapps\idms100\help. For the online help of the SCM Web interface, only the WebInterface.html file is relevant.


2.1.5 Report Style Sheets and Phrase Books The default style sheets (.xsl files) and phrase book (phrasebook.xml) used for the output of component-specific reports are located in the following directories depending on the interface being used:

• Client interface (Eclipse), for client/server and remote access mode: plugins\com.fujitsu.asm.core_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory for COC, LCM, SCA and QAM log reports. plugins\com.fujitsu.asm.dms_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory for DMS reports. plugins\com.fujitsu.asm.lcm_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory for LCM reports. plugins\com.fujitsu.asm.qam_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory for QAM reports. plugins\com.fujitsu.asm.sca_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory for SCA reports. plugins\com.fujitsu.enabler.eclipse.scm.core_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory for SCM reports.

• Command line interface for LCM in general and for client/server access mode in SCM and DMS: templates\DMS templates\LCM templates\SCM subdirectory of the command line interface installation directory.

• Web interface and remote access mode of the SCM or DMS command line interface: templates subdirectory of the iscm<version> or idms<version> Web application deployment directory on the Web/application server.

2.1.6 Web Interface The JSPs (.jsp files) and style sheets (.css files) for the SCM or DMS Web interface are located in the web subdirectory of the corresponding Web application deployment directory on the Web/application server:

..\iscm<version>\web

..\idms<version>\web


2.2 Translating and Using Language-Specific Files The following sections describe how to proceed in order to translate and use language-specific files.

2.2.1 Properties Files Each line in an about.properties, fragment.properties, plugin.properties or messages.properties file contains a key-value pair with the following syntax:

Key = Value

You can change the Value part as required, but never change the Key!

After you have translated all values in a file to the desired national language, save the modified file as a language-specific file at the same location as the original file. The names of language-specific files have the following format:

<name>_<language>.properties

Examples

plugin_ja.properties messages_de.properties

In order to use the new language-specific files, restart the Interstage ASM client interface or Eclipse, or the changed Web application with the appropriate language settings. For details on how to set a specific language for each interface, refer to the Interstage ASM Administration Guide.

2.2.2 Online Help In order to create online help for a specific language, translate the texts in the *.html, *.htm and *.xml files accordingly. Do not change any HTML or XML tags, paths or file names.

For the Interstage ASM client interface, you can create and maintain online help for several languages in parallel. To do this, create a subdirectory nl\<language> in the original plug-in directory, for example, nl\de or nl\ja. Copy the files you have translated to this directory, using the same file names and structures as in the original plug-in directory. For examples, refer to the nl\ja (Japanese) directory available in the Interstage ASM documentation plug-in directories.

The Interstage ASM client interface displays the online help in the language set when it is started. For details on how to set a specific language for the client interface, refer to the Interstage ASM Administration Guide.

2.2.3 Report Style Sheets and Phrase Books For generating reports, you can use your own style sheets and phrase books or adapt the files provided by Interstage ASM to your requirements. If you adapt the Interstage ASM style sheets and phrase books, save your changes under new names or at least create backup copies of the changed files, because installation of a new Interstage ASM version may overwrite the files with the original paths and names.

The style sheets and phrase books to be used for report generation in SCM and DMS can be specified as follows:

• Client interface: Adapt the settings in the Preferences of the Workbench (menu option Window > Preferences).

• Command line interface: Specify the style sheet and/or phrase book with the command for generating a specific report.


2.2.4 Web Interface In the JSP files of the SCM and DMS Web interface, you can, for example, change images or logos according to your requirements. You should never change the logic or structure of the JSPs.

In the style sheets (.css files), you can change the appearance of the Web interface.

Before you change JSPs or style sheets, you should create backup copies of the original files. Also create backups of any changes you have made.


3 Customizing LCM Items and Behavior This chapter describes how you can customize the items, client interface and behavior of LCM.

The settings are defined in an XML file, which must be available on each LCM client in one of the following directories depending on the interface being used:

• Client interface (Eclipse): plugins\com.fujitsu.asm.lcm_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory.

• Command line interface: templates\LCM subdirectory of the command line interface installation directory.

The default settings of LCM are defined in the following file in this directory:

model.xml

Do not change any settings directly in this file, because it may be overwritten when you install a newer version of LCM. Instead, copy the file to the following file in the same directory and adapt the new file as required:

model_customized.xml

The settings are read when logging on to a repository for the first time, and stored in the repository. LCM first tries to read the model_customized.xml file. If this file does not exist, it reads the model.xml file.

The following items are defined and can be customized:

• Item types.

• Association types for associations between LCM items.

• Attribute groups which specify the property pages or sections where attributes are displayed in the New wizards, the Properties dialog boxes and the Details LCM view at the client interface.

• Attributes to be displayed as properties on the property pages or sections of the New wizards, the Properties dialog boxes and the Details LCM view.

• Attributes to be displayed in the Complete Activity and Change State of Subactivity dialog boxes.

• Attributes to be displayed as columns in the Contents LCM and Activities LCM views.

3.1 Item Types The coreEntityTemplates sections of the XML file contain the definitions of item types, for example, Application, Requirement or Change Request. You can specify new attributes for predefined item types and customize the appearance of the attributes at the client interface. The definition of new item types is not supported.



The XML sections has the following syntax and contents: <!ELEMENT coreEntityTemplates> <!ATTLIST type name CDATA #REQUIRED associations CDATA #IMPLIED > • name – Name of the item type.

• associations – Association types that can be created for items of this type (default: EMPTY). For details on association types, refer to Section 3.2, Association Types.

<!ELEMENT attributeGroups> • attributeGroups – Attribute groups to be shown for items of this type (default:

EMPTY). For details on attribute groups, refer to Section 3.3, Attribute Groups. <!ELEMENT authorities> • authorities – Authorities required for accessing items of this type (default: EMPTY).

For details on authorities, refer to Section 1.1, Roles and Authorities. <!ELEMENT attachmentAuthorities> • attachmentAuthorities – Authorities required for defining and accessing attachments

of items of this type (default: EMPTY). For details on authorities, refer to Section 1.1, Roles and Authorities.

Example <coreEntityTemplates name="ExternalLink" associations="DependentReleases DependentIterations RelatedReleases"> <authorities>CreateRelease</authorities> <authorities>EditAnyRelease</authorities> <authorities>ViewRelease</authorities> <authorities>EditRelease</authorities> <attributeGroups name="Info" positionInUI="1" expandedInUI="true" > <attributes name="Name" positionInUI="1" numberOfHistoryLines="10" maxStringLength="64" mandatory="true" searchable="true"/> ... </attributeGroups> </coreEntityTemplates>


3.2 Association Types The associationTypes sections of the XML file contain the definitions of association types for LCM items. Associations of the defined types can be created between items of item types to which the association types are assigned in the coreEntityTemplates sections of the model.xml file (see Section 3.1, Item Types). You can customize existing association types as well as create new ones.

In LCM, you can define internal and external associations:

• Internal associations are associations between LCM items, for example, the association between a change request and a requirement. Internal associations must always be defined in pairs: The name property determines the regular direction of the association. The inverseName property specifies the association running in the opposite direction. Accordingly, the sourceEntity and the targetEntity properties much match, and the inverseAssociation property of one of the association types must be set to “true”. For details on the properties, see below.

• External associations are links from LCM items to items of other Interstage ASM components or external systems. They are used, for example, to integrate SCM with LCM.


The XML sections have the following syntax and contents: <!ELEMENT associationTypes> <!ATTLIST associationTypes name CDATA #REQUIRED inversename CDATA #REQUIRED sourceEntity CDATA #REQUIRED targetEntity CDATA #REQUIRED maxEntries CDATA #IMPLIED pasteAllowed CDATA #IMPLIED inverseAssociation CDATA #IMPLIED intraAppService CDATA #IMPLIED external CDATA #IMPLIED checkProtection CDATA #IMPLIED searchable CDATA #IMPLIED > • name – Name of the association type.

• inverseName – Name of the inverse association type.

• sourceEntity – Name of the item type for the source item of an association of this type.

• targetEntity – Name of the item type for the target item of an association of this type.

• maxEntries – Number of target items which can be associated to a source item. If set to “-1”, any number of target items can be associated. If set to a positive value, the number of items that can be associated is restricted to this value (default: "-1").

• pasteAllowed – If set to “false”, the Paste menu option at the client interface is disabled for the source item (default: "true"). In this case, an association of this type can only be created from the source item to the target item and not in the opposite direction.

• inverseAssociation – If set to “true”, the association type is regarded as an inverse association type (default: "false").


• intraAppService – If set to “true”, an association of this type can only be created between items that belong to the same application or service (default: "true").

• external – If set to “true”, the association type is regarded as an external link which has no inverse association type (default: "false").

• checkProtection – If set to “false”, the protection type of a source item of an association of this type is not checked when creating or deleting the target item (default: "true"). This is, for example, needed when a successor release is to be created for an already protected release. For this purpose, the checkProtection property for the SuccessorReleases association type is set to “false”.

• searchable – If set to “true”, the association type can be used in filters (default: "false").

<!ELEMENT authorities> • authorities – Authorities required for accessing associations of this type. For details

on authorities, refer to Section 1.1, Roles and Authorities.

Example <associationTypes name="RequisiteRequirements" inverseName="DependentRequirements" sourceEntity="Requirement" targetEntity="Requirement" maxEntries="-1" searchable="true" checkProtection="false" pasteAllowed="true"> <authorities>ViewRequirement</authorities> <authorities>EditRequirement</authorities> <authorities>EditAnyRequirement</authorities> <authorities>DeleteRequirement</authorities> </associationTypes>

3.3 Attribute Groups The attributeGroups sections of the XML file contain the definitions of attribute groups for structuring the attributes of LCM items. Attribute groups can be displayed at the client interface as property pages or sections of the New wizards, the Properties dialog boxes and the Details LCM view.


The XML sections have the following syntax and contents: <!ELEMENT attributeGroups> <!ATTLIST attributeGroups name CDATA #REQUIRED displayAreaName CDATA #IMPLIED positionInUI CDATA #IMPLIED expandedInUI CDATA #IMPLIED visibility CDATA #IMPLIED >


• name – The name of the attribute group.

• displayAreaName – Name of the New wizard page on which the attribute group is to be displayed (default: EMPTY). All attribute groups which have the same value for this property are displayed on the same wizard page. By default, each attribute group is displayed on a separate page which gets the name of the attribute group.

• positionInUI – Integer value which defines the sequence of the attribute groups in the New wizards, the Properties dialog boxes and the Details LCM view (default: EMPTY). By default, the sequence is that of the attributeGroups sections in the model.xml file.

• expandedInUI – If set to “true”, the corresponding section of the attribute group in the Details LCM view is expanded (default: “false”).

• visibility – Defines the visibility of the attribute group in the Properties dialog box and the Details LCM view (default: “PropertiesAndDetailsView”). The following values can be specified: PropertiesAndDetailsView – The attribute group is displayed in the Properties dialog box and the Details LCM view. PropertiesPageOnly – The attribute group is only displayed in the Properties dialog box. DetailsViewOnly – The attribute group is only displayed in the Details LCM view. NotVisible – The attribute group is neither displayed in the Properties dialog box nor in the Details LCM view. An attribute group is visible in the New wizards if it contains at least one attribute whose editOnCreate property is set to “true”.

<!ELEMENT attributes> • attributes – Attribute definitions for the given attribute group. For details, refer to

Section 3.4, Attributes.

Example <attributeGroups name="Info" positionInUI="1"> expandedInUI="true"> <attributes name ...

3.4 Attributes The attributes sections of the XML file contain the definitions of predefined and user-defined attributes for LCM items. Attributes can be displayed at the client interface as properties of LCM items in the New wizards, the Properties dialog boxes and the Details LCM view.

You can customize the presentation of attributes at the client interface, the access authorities, default values and value restrictions as well as define your own (user-defined) attributes for an item type.



The XML sections have the following syntax and contents: <!ELEMENT attributes> <!ATTLIST attributes name CDATA #REQUIRED searchable CDATA #IMPLIED maxStringLength CDATA #IMPLIED outputFormat CDATA #IMPLIED protection CDATA #IMPLIED maxValue CDATA #IMPLIED minValue CDATA #IMPLIED stringConstraint CDATA #IMPLIED mandatory CDATA #IMPLIED editOnCreate CDATA #IMPLIED visibleInUI CDATA #IMPLIED defaultValue CDATA #IMPLIED copyable CDATA #IMPLIED positionInUI CDATA #IMPLIED numberOfHistoryLines CDATA #IMPLIED numberOfTextAreaLines CDATA #IMPLIED numberOfViewAreaLines CDATA #IMPLIED dataType CDATA #IMPLIED visibility CDATA #IMPLIED authorities CDATA #IMPLIED indexed CDATA #IMPLIED >

Definitions of user-defined attributes must start with the following element definition in the XML file: <attributes xsi:type="ILCMC:UserDefinedAttributeTemplate"> • name – Name of the attribute.

• searchable – If set to “true”, the attribute can be used in filters (default: "false").

• maxStringLength – Maximum length of “String” attributes. If set to “-1”, the length is not restricted. If set to a positive integer value, the length is restricted to this value (default: “-1”).

• outputFormat – Output format for “Date” attributes. If set to a value, this value is used as the date format (default: EMPTY). By default, the format is set to yyyy-MM-dd.

• protection – If set, this property defines the protection type of the attribute (default: “Editable”). The following values can be specified: Editable – All users with the appropriate authority can change the attribute. EditableByResponsibleUser – Only users who are assigned as responsible users to the related item and have the appropriate authority can change the attribute. ImplicitlyEditable – The attribute cannot be changed at the user interface. Only the related process can set the value. NotEditable – The attribute value cannot be changed at all.

• maxValue – Maximum value for “Float” and “Integer” attributes. If set, the attribute value must not exceed the defined maximum (default: EMPTY).

• minValue – Minimum value for “Float” and “Integer” attributes. If set, the attribute value must not be below the defined minimum (default: EMPTY).

• stringConstraint – If set to a regular expression, the attribute value must match the regular expression (default: EMPTY).


• mandatory – If set to “true”, the user must specify an attribute value at the client interface (default: “false”).

• editOnCreate – If set to “true”, the attribute is displayed in the New wizard (default: “false”).

• visibleInUI – If set to “false”, the attribute is not displayed at the client interface (default: “true”).

• defaultValue – If set to a value, this is used as the default value for the attribute when an item is created (default: EMPTY). For “Date” attributes, the value is interpreted as a day offset relative to the current date at the time of creation. For example, a value of “1” sets the date of the next day.

• copyable – If set to “true”, the attribute value is copied when a copy of the related item is created (default: “false”).

• positionInUI – Integer value which defines the sequence of the attributes in the attribute group (default: EMPTY). By default, the sequence is that in the attributeGroups sections in the model.xml file.

• numberOfHistoryLines – If set to a positive integer value n, the attribute is presented as a combo box which contains the last n values entered by the user as possible values (default: EMPTY). The user can either select a value previously entered or enter a new value. By default, the attribute is presented as a simple text field.

• numberOfTextAreaLines – If set to a positive integer value n, the attribute is presented as a text field with n lines for values (default: EMPTY). By default, the attribute is presented as a simple text field.

• numberOfViewAreaLines – If set to a positive integer value n, this value defines the number of lines for the display area of attributes of type “AppendString” (default: EMPTY), for example, the previously entered comments for a change request. By default, the display area is not shown.

• dataType – If set, this property defines the data type of the attribute (default: “String”). The following data types can be specified: String – The attribute is presented as a text field. Boolean – The attribute is presented as a check box. Date – The attribute is presented as a date field. Duration – The attribute is presented as a combination of a text field for typing the time duration and a combo box for selecting the unit, for example, hours or days. AppendString – The attribute is presented as a text field. New values are appended to the existing text. Integer – The attribute is presented as a text field for integer values. Float – The attribute is presented as a text field for floating-point numbers.

• visibility – Defines the visibility of the attribute in the Properties dialog box and the Details LCM view (default: “PropertiesAndDetailsView”). The following values can be specified: PropertiesAndDetailsView – The attribute is displayed in the Properties dialog box and the Details LCM view. PropertiesPageOnly – The attribute is only displayed in the Properties dialog box. DetailsViewOnly – The attribute is only displayed in the Details LCM view. NotVisible – The attribute is neither displayed in the Properties dialog box nor in the Details LCM view. An attribute is visible in the New wizard if its editOnCreate property is set to “true”.

• authorities – Authorities required for accessing the attribute. For details on authorities, refer to Section 1.1, Roles and Authorities.


• indexed – Specifies which Enabler index is created for the attribute. (default: EMPTY). This property cannot be used for user-defined attributes. For details on Enabler attributes, refer to the Enabler documentation. The following values can be specified: NO – No index is created for the attribute. INDEX – A non-unique index is created for the attribute. UNIQUENDEX – A unique index is created for the attribute.

<!ELEMENT valueSet> • valueSet –Possible attribute value. The values are presented in a combo box at the

client interface (default: EMPTY).

Example <attributes xsi:type="ILCMC:UserDefinedAttributeTemplate" name="Priority" positionInUI="3" maxStringLength="128" numberOfHistoryLines="0" searchable="true" copyable="true" editOnCreate="true" mandatory="true" defaultValue="undefined" authorities="EditChangeRequest ViewChangeRequest"> <valueSet>undefined</valueSet> <valueSet>P1</valueSet> <valueSet>P2</valueSet> <valueSet>P3</valueSet> <valueSet>P4</valueSet> <valueSet>P5</valueSet> </attributes>

3.5 Dynamic User-Defined Attributes In the attributes sections of the XML file, you can also define dynamic user-defined attributes of LCM items.

Dynamic user-defined attributes are user-defined attributes whose values are calculated at run time. All properties described in Section 3.4, Attributes, can be set for dynamic user-defined attributes. Additionally, the following XML attribute must be specified:

• targetClass – Fully qualified name of the Java class which dynamically calculates the attribute value at run time. (default: EMPTY).

Java Classes for Calculating Dynamic User-Defined Attributes

To calculate the values for user-defined attributes in LCM, you must perform the following steps:

1. Write a Java class for calculating the value of the attribute in question. The class must implement the following interface of the Interstage ASM Java API:

com.fujitsu.asm.lcm.extension.DynamicUserDefinedAttribute

2. Create a Java archive (.jar file) containing the Java classes for calculating attribute values as well as the .properties files containing the attribute labels (see Section 3.8, Labels for New Attributes and Association Types).

3. Upload the new Java archive (.jar file) to the LCM repository. For details on uploading Java archives, refer to the Interstage ADM Lifecycle Management User Guide.


All Java classes and other files required for dynamic user-defined attributes are stored in a directory on the LCM client which depends on the user interface being used:

• Client interface (Eclipse): plugins\com.fujitsu.asm.lcm_#\templates\customize subdirectory of the Interstage ASM client or Eclipse installation directory.

• Command line interface: templates\LCM\customize subdirectory of the command line interface installation directory.

Example

Define the Java class in model.xml: <coreEntityTemplates name="Application"> ... <attributeGroups name="Categories" displayAreaName="Categories" positionInUI="3"> <attributes xsi:type="ILCMC:UserDefinedAttributeTemplate" dataType="Categories" name="Categories" maxStringLength="256" searchable="true" editOnCreate="false" authorities="CreateApplication EditAnyApplication EditApplication ViewApplication" targetClass="com.fujitsu.asm.lcm.extension.impl.CoreEntityDudas"/>

/>

Implement the interface in the referenced Java class: package com.fujitsu.asm.lcm.extension.impl; import com.fujitsu.asm.lcm.extension.DynamicUserDefinedAttribute; import com.fujitsu.asm.persistence.config.UserDefinedAttributeTemplate; /** * Dynamic User Defined Attributes of applications */ public class CoreEntityDudas implements DynamicUserDefinedAttribute { public String getValue(CoreEntity pCoreEntity, UserDefinedAttributeTemplate pAttributeTemplate) { ...

3.6 Attribute Display in Dialog Boxes The dialogTemplates sections of the model.xml file specify which attributes are to be displayed in the Complete Activity and Change State of Subactivity dialog boxes at the client interface.



The XML sections have the following syntax and contents: <!ELEMENT dialogTemplates> <!ATTLIST dialogTemplates name CDATA #REQUIRED > • name – Name of the dialog box in which the attributes are to be displayed. The

following names are available: CompleteActivity – The attributes are displayed in the Complete Activity dialog box. ChangeStateOfSubactivity – Attributes are displayed in the Change State of Subactivity dialog box.

<!ELEMENT attributeGroups>

For details, refer to Section 3.3, Attribute Groups. <!ELEMENT attributes>

For details, refer to Section 3.4, Attributes.

Example <dialogTemplates name="ChangeStateOfSubactivity"> <attributeGroups name="Info" positionInUI="1"> <attributes name="SuccessorActivity" positionInUI="1"

numberOfHistoryLines="1" referenceType="true" mandatory="true" dataType="SuccessorActivity"/> <attributes name="Name" positionInUI="2" protection="NotEditable"/> <attributes name="ShortDescription" positionInUI="3" protection="NotEditable"/> <attributes xsi:type="ILCMC:UserDefinedAttributeTemplate" name="Comments"

positionInUI="4" numberOfTextAreaLines="3" numberOfHistoryLines="10" dataType="AppendString" outputFormat="yyyy-MM-dd HH:mm:ss"/> </attributeGroups> </dialogTemplates>


3.7 Attribute Display in Views The columnTemplates sections of the model.xml file specify which items and attributes of an item are to be displayed as columns in the Contents LCM and Activities LCM views. You can define which attributes are to be displayed and specify the column width for each attribute.


The XML sections have the following syntax and contents: <!ELEMENT columnTemplates> <!ATTLIST columnTemplates name CDATA #REQUIRED > • name – Name of the column template defining which item types are to be shown in a

view. The following names are available: ChangeRequestFolder – All change requests in the Change Requests folder are shown in the Contents LCM view. RequirementFolder – All requirements in the Requirements folder are shown in the Contents LCM view. ReleaseFolder – All releases in the Releases folder are shown in the Contents LCM view. IterationFolder – All iterations in the Iterations folder are shown in the Contents LCM view. ActivitiesViewColumns – All activities and related items are shown in the Activities LCM view.

<!ELEMENT columnGroups> <!ATTLIST columnGroups name CDATA #REQUIRED > • name – Name of the item type to be shown in the view. The following names are

available: ChangeRequest – The attributes of change requests are shown in the Contents LCM view. Requirement – The attributes of requirements are shown in the Contents LCM view. Release – The attributes of releases are shown in the Contents LCM view. Iteration – The attributes of iterations are shown in the Contents LCM view. Activity – The attributes of activities are shown in the Activities LCM view. WorkItem – The attributes of items related to the activity are shown in the Activities LCM view.

<!ELEMENT columns> <!ATTLIST columns name CDATA #REQUIRED defaultColumnWidth CDATA #IMPLIED visibleByDefault CDATA #IMPLIED >


• name – Name of an attribute to be shown in the view as a column.

• defaultColumnWidth – If set to a positive integer value, it defines the default column width of the attribute column (default: “0”) The default column width is set to "100".

• visibleByDefault – If set to “false”, the attribute column is not shown by default (default: “true”).

Example <columnTemplates name="ChangeRequestFolder"> <columnGroups name=" ChangeRequest"> <columns name="Name" defaultColumnWidth="70"/> <columns name="ShortDescription" defaultColumnWidth="100"/> <columns name="ProcessState" defaultColumnWidth="100"/> <columns name="Priority" defaultColumnWidth="50"/> <columns name="PlannedEffort" defaultColumnWidth="80"/> <columns name="ChangeType" defaultColumnWidth="80"/> <columns name="DueDate" defaultColumnWidth="80"/> <columns name="ChangeRequestReleases" defaultColumnWidth="40"/> <columns name="ImplementedRequirementCHM" defaultColumnWidth="40"/> <columns name="ChangeRequestIterations" defaultColumnWidth="40" visibleByDefault="false"/> <columns name="Categories" defaultColumnWidth="80" visibleByDefault="false"/> <columns name="Description" defaultColumnWidth="200" visibleByDefault="false"/> <columns name="CreationID" defaultColumnWidth="80" visibleByDefault="false"/> <columns name="CreationDate" defaultColumnWidth="100" visibleByDefault="false"/> <columns name="ModificationID" defaultColumnWidth="80" visibleByDefault="false"/> <columns name="ModificationDate" defaultColumnWidth="100" visibleByDefault="false"/> </columns Groups> </columnTemplates> <columnTemplates name="ActivitiesViewColumns"> <columnGroups name="WorkItem"> <columns name="WorkItemType" defaultColumnWidth="100"/> <columns name="Name" defaultColumnWidth="70"/> <columns name="ShortDescription" defaultColumnWidth="100"/> <columns name="Description" defaultColumnWidth="180" visibleByDefault="false"/> </columnGroups> <columnGroups name="Activity"> <columns name="Name" defaultColumnWidth="100"/> <columns name="State" defaultColumnWidth="100"/> <columns name="ShortDescription" defaultColumnWidth="100"/> <columns name="CreationID" defaultColumnWidth="80" visibleByDefault="false"/> <columns name="CreationDate" defaultColumnWidth="100" visibleByDefault="false"/> <columns name="ModificationID" defaultColumnWidth="80" visibleByDefault="false"/> <columns name="ModificationDate" defaultColumnWidth="100" visibleByDefault="false"/> </columnGroups> </columnTemplates>


3.8 Labels for New Attributes and Association Types By default, all association types and attributes are labeled for presentation at the client interface with their name defined in the model.xml file.

The labels for the client interface are specified in a corresponding messages.properties file which can be localized. For details on localization, refer to Section 2.2, Translating and Using Language-Specific Files. For any association type and attribute you define, you should add new labels to the corresponding messages.properties file and upload this file to the LCM repository.

Proceed as follows:

1. Create a messages.properties file. This file is the default file and contains the labels in English. For localization, create a corresponding file for each language by adding the appropriate language code to the file name, for example, messages_ja.properties for Japanese.

2. In the messages.properties file, define a header and a label property for the new attribute or association type. A header is presented at the client interface as a heading, for example, in wizards or views. A label is presented as a field name, for example, in dialog boxes. The properties are defined according to the following rules:

• Header for association types: <AssociationType>.attribute.nofentries.header = <value> Replace <AssociationType> with the name of the new association type in lower-case letters. For <value>, type the label text which is to be shown at the client interface, for example: requisiterequirements.attribute.nofentries.header = Number of Entries

• Label for association types: NavigationView.Tree.<AssociationType>.label = <value>: Replace <AssociationType> with the name of the new association type as defined in model.xml in its genuine case. For <value>, type the desired label text which is to be shown at the client interface, for example: NavigationView.Tree.RequisiteRequirements.label = Requisite requirements:

• Header for user-defined attributes: <CoreEntityTemplate>.attribute.<Name>.header = <value> Replace <CoreEntityTemplate> with the name of the item type and <Name> with the name of the new attribute specified in model.xml in lower-case letters. For <value>, type the label text which is to be shown at the client interface, for example: application.attribute.modificationdate.header = Modification Time

• Label for user-defined attributes: <CoreEntityTemplate>.attribute.<Name>.label = <value>: Replace <CoreEntityTemplate> with the name of the item type and <Name> with the name of the new attribute specified in model.xml in lower-case letters. For <value>, type the label text which is to be shown at the client interface, for example: application.attribute.modificationdate.label = Modification time:

3. Create a Java archive (.jar file) containing the .properties file(s). The .properties file(s) must be stored in a directory with the same name as the corresponding .jar file. For example, the directory which contains the .properties file(s) for the MyClass.jar file must be named MyClass.


4. Upload the new Java archive (.jar file) to the LCM repository. For details on uploading Java archives, refer to the Interstage ADM Lifecycle Management User Guide. After uploading a .jar file, it is additionally stored in the com.fujitsu.asm.lcm_#\templates\customize subdirectory of the Interstage ASM client or Eclipse installation directory.


4 Customizing LCM Processes This chapter describes how you can customize the predefined LCM processes and create your own ones. Additionally it describes how to define and use Interstage BPM processes.

The processes are defined in an XML file, which must be available on each LCM client in one of the following directories depending on the interface being used:

• Client interface (Eclipse): plugins\com.fujitsu.asm.lcm_#\templates subdirectory of the Interstage ASM client or Eclipse installation directory.

• Command line interface: templates\LCM subdirectory of the command line interface installation directory.

The default processes of LCM are defined in the following file:

processes.xml

Do not change any settings directly in this file, because it may be overwritten when you install a newer version of LCM. Instead, copy the file to the following file in the same directory and adapt the new file as required:

processes_customized.xml

The processes are read when logging on to a repository for the first time and stored in the repository. LCM first tries to read the processes_customized.xml file. If this file does not exist, it reads the processes.xml file.

The following can be defined and customized:

• Specification of default processes for applications, services, requirements, change requests, releases and iterations.

• Definitions of properties for processes and process steps for applications, services, requirements, change requests, releases and iterations.

• References to Interstage BPM processes.

4.1 Default Processes The first part of the XML file contains the specification of the default processes. When an application, service, requirement, change request, release or iteration is created automatically, for example, when creating a release in SCM, the default process is assigned to it. When an application, service, requirement, change request, release or iteration is created explicitly in LCM, the default process is preselected and can be changed by the user.

Specifying the default processes is mandatory.


The sections in the XML file have the following syntax and contents: <!ELEMENT defaultApplicationProcessName> <!ELEMENT defaultServiceProcessName> <!ELEMENT defaultRequirementProcessName> <!ELEMENT defaultChangeRequestProcessName> <!ELEMENT DefaultReleaseProcessName> <!ELEMENT DefaultIterationProcessName>


• defaultApplicationProcessName – Default process for applications (default: applicationStandard).

• DefaultServiceProcessName – Default process for services (default: serviceStandard).

• DefaultChangeRequestProcessName – Default process for change requests (default: changeRequestStandard).

• DefaultRequirementProcessName – Default process for requirements (default: requirementStandard).

• DefaultReleaseProcessName – Default process for releases (default: releaseStandard).

• DefaultIterationProcessName – Default process for iterations (default: iterationStandard).

Example <defaultApplicationProcessName>applicationStandard</defaultApplicationProcessName> <defaultServiceProcessName>serviceStandard</defaultServiceProcessName> <defaultChangeRequestProcessName>changeRequestStandard</defaultChangeRequestProcessName> <defaultRequirementProcessName>requirementStandard</defaultRequirementProcessName> <defaultReleaseProcessName>releaseStandard</defaultReleaseProcessName> <defaultIterationProcessName>iterationStandard</defaultIterationProcessName>

4.2 Process Definitions The simpleProcessTemplates sections of the XML file define processes and process steps for applications, services, requirements, change requests, releases and iterations. These processes can be used in any environment and independent on whether Interstage BPM is available.

In these sections, you can change the predefined processes and define your own ones.


The sections have the following syntax and contents: <!ELEMENT simpleProcessTemplates> <!ATTLIST property name CDATA #REQUIRED startNodeID CDATA #REQUIRED > • name – Name of the process. For the client interface, the process name can be

customized.

• startNodeID – ID of the node that defines the process start.


<!ELEMENT nodes> <!ATTLIST nodes name CDATA #REQUIRED choiceName CDATA #IMPLIED nodeID CDATA #REQUIRED successorIDs CDATA #REQUIRED roleNames CDATA #IMPLIED protectWorkItem CDATA #IMPLIED deleteableWorkItem CDATA #IMPLIED protectActivity CDATA #IMPLIED notificationMails CDATA #IMPLIED > • name – Name of the process step. A process step can be the process start, an activity

or an exit. For the client interface, the names of the process steps can be customized.

• choiceName –Name of the process step which is displayed at the client interface for selection when completing a predecessor activity. If not specified, the name of the process step is displayed as the choice name. For the client interface, the choice name can be customized. It is recommended to omit the choiceName attribute in the processes.xml file and only define an appropriate label for the client interface. For details, refer to Section 4.5, Labels for New Process Definitions.

• nodeID – Unique ID of the process step.

• successorIDs – ID of the available successor steps. The user must select one of these successor steps when completing a process step. If no successor step is defined, the step is regarded as an exit of the process.

• roleNames – List of user roles which are assigned to the process step. The users responsible for the process step can be selected from all users who are assigned any of the given roles. If not specified, all users assigned to the application are assigned to the process step.

• protectWorkItem – Protection type of the related item when the process step is activated (default: "EditableByResponsibleUser"). The following values can be specified: Editable – All users with the appropriate authority can change the item. EditableByResponsibleUser – Only users who are assigned as responsible users to the related item and have the appropriate authority can change it. ImplicitlyEditable – The item cannot be changed at the user interface. Only the related process can change the item. NotEditable – The item cannot be changed at all.

• deleteableWorkItem – If set to “true”, the related item is deleteable (default: “false”).

• protectActivity – Protection type of the activity when it is activated (default: "EditableByResponsibleUser"). The following values can be specified: Editable – All users with the appropriate authority can change the activity. EditableByResponsibleUser – Only users who are assigned as responsible users to the activity and have the appropriate authority can change it. ImplicitlyEditable – The activity cannot be changed at the user interface. Only the related process can change the activity. NotEditable – The activity cannot be changed at all.

• notificationMails – If set to "true", the mail notification feature is activated for the process step (default: “true”). In this case, users can be notified by email when activities are completed and transitions to subsequent activities or process exits are performed. For this purpose, the mail settings must be specified for the repository.


<!ELEMENT applicableTypes> • applicableTypes – List of item types (see Section 3.1, Item Types) the process can

be used for (default: EMPTY).

Example <simpleProcessTemplates name="applicationStandard" startNodeID="1001"> <applicableTypes>Application</applicableTypes> <nodes name="Development" choiceName="Develop" nodeID="1001" deleteableWorkItem="true"> <successorIDs>1002</successorIDs> <roleNames>Manager</roleNames> </nodes> <nodes name="Completed" choiceName="Complete" nodeID="1002" protectWorkItem="NotEditable"/> </simpleProcessTemplates>

4.3 Interstage BPM Processes The ibpmProcessDefinitions sections of the processes.xml file contain the references to Interstage BPM process definitions which can be used for LCM items. A reference is provided by the name of a process definition in Interstage BPM.


The XML sections have the following syntax and contents: <!ELEMENT ibpmProcessDefinitions> <!ATTLIST ibpmProcessDefinitions name CDATA #REQUIRED description CDATA #IMPLIED applicableTypes CDATA #IMPLIED > • name – Name of the process definition. This name must match the name of the

process definition in Interstage BPM. Special characters, such as : , ; < > ! / \, are not allowed in names for Interstage BPM process definitions.

• description – Description of the Interstage BPM process definition (default: EMPTY).

• applicableTypes – List of item types (see Section 3.1, Item Types) the process can be used for (default: EMPTY).

Example

<ibpmProcessDefinitions name="LCM Application Process">

<applicableTypes>Application</applicableTypes>

</ibpmProcessDefinitions>


4.4 Defining Interstage BPM Processes To define an Interstage BPM process for use with LCM, you must perform the following steps:

1. Perform the necessary steps for integrating LCM with Interstage BPM. For details, refer to the Interstage ASM Administration Guide.

2. Design the process in Interstage BPM Studio using the custom node predefined for LCM. As examples, you can use the Interstage BPM sample processes provided by Interstage ASM (see below). For details on modeling processes in Interstage BPM, refer to the Interstage Business Process Manager Studio User’s Guide. When you model processes with Interstage BPM, consider that Email Nodes and Voting Activity Nodes cannot be used for LCM processes. Take the following steps in Interstage BPM Studio:

• When using the LCM custom node, open the Properties dialog box and select the LCM Settings tab. You must at least open and close the dialog box to activate the settings.

• In the Protection of LCM item area, specify the protection type for the LCM item

when the process reaches the step described by this node. In the Protection of LCM activity area, specify the protection type for the LCM activity representing this node: Editable by all users – All users with the appropriate authority can change attributes of the related item or activity. Editable by responsible users only – Only users who are assigned as responsible users to the related item or activity and have the appropriate authority can change the item or activity. Not editable – The related item or activity cannot be changed at all. Editable by process only – The item or activity cannot be changed at the client interface but only by the process. Deleteable – The related item is deleteable.


• In the User roles area, select Send notification mails to users to activate the mail notification feature. If the feature is activated, users are notified by email when activities are completed and transitions to subsequent activities or process exits are performed. For this purpose, the feature must also be activated in the LCM repository by defining the mail settings.

• In the Role name field, specify the possible responsible users for the activity by their role. These are the roles defined in LCM, not Interstage BPM. To add a role, type the name of the LCM user role in the Role name field, and click Add. The role is added to the Assigned roles list. To remove a role, select the role in the Assigned roles list and click Remove.

3. Save the process definition. Names of process definitions are case-sensitive and must not contain whitespace characters. Special characters, such as : , ; < > ! / \, are also not allowed in names of Interstage BPM process definitions.

4. Upload the process definition to the Interstage BPM server. For details, refer to the Interstage Business Process Manager Studio User’s Guide.

5. Reference the process definition in the processes.xml file of LCM. For details, refer to Section 4.3, Interstage BPM Processes.

6. In LCM, import the process definitions to the LCM repository. For details on using Interstage BPM processes in LCM, refer to the Interstage ADM Lifecycle Management User Guide.

Interstage BPM Sample Processes

Interstage ASM provides a sample XPDL file for each Interstage BPM process which is predefined in the processes.xml file. The XPDL files can be imported to Interstage BPM Studio. The XPDL files are located in the same directory as the processes.xml file. You can use these sample processes as examples for modeling your own processes with Interstage BPM. The following processes are available:

• LCM_Application_BPM.xpdl: Sample process for applications

• LCM_Service_BPM.xpdl: Sample process for services

• LCM_Requirement_BPM.xpdl: Sample process for requirements

• LCM_Change_Request_BPM.xpdl: Sample process for change requests

• LCM_Release_BPM.xpdl: Sample process for releases

• LCM_Iteration_BPM.xpdl: Sample process for iterations

4.5 Labels for New Process Definitions By default, all process definitions are labeled for presentation at the client interface with their names defined in the processes.xml file.

The labels for the client interface are specified in a corresponding messages.properties file which can be localized. For details on localization, refer to Section 2.2, Translating and Using Language-Specific Files. For any process you define, you should add new labels to the corresponding messages.properties file and upload this file to the LCM repository.You can specify new labels for the process definitions, the names of the process steps and their choice names.


1. Create a messages.properties file. This file is the default file and contains the labels in English. For localization, create a corresponding file for each language by adding the appropriate language code to the file name, for example, messages_ja.properties for Japanese.

2. In the messages.properties file, define label properties for each of your own process definitions, the process steps and their choice names according to the following syntax:

• Process definitions: proctpl.name.<process definition>.value = <value> Replace <process definition> with the name of the new process definition as it is specified in processes.xml. For <value>, type the label text which is to be shown at the client interface, for example: proctpl.name.applicationStandard.value = Standard process

• Names of process steps: process.nodenames.<name>.name = <value> Replace <name> with the name of the process step as it is specified by the name attribute of the nodes element in processes.xml in lower-case letters. For <value>, type the label text which is to be shown at the client interface. For process steps, you usually use nouns, for example: process.nodenames.development.value = Development

• Choice names of process steps: process.chiocenames.<choice name>.name = <value> Replace <choice name> with the name as it is specified by the chioceName attribute of the nodes element in processes.xml in lower-case letters. For <value>, type the label text which is to be shown at the client interface. For choice names, you usually use verbs, for example: process.choicenames.development.value = Develop

3. Create a Java archive (.jar file) containing the .properties file(s).

4. Upload the new Java archive (.jar file) to the LCM repository. For details on uploading Java archives, refer to the Interstage ADM Lifecycle Management User Guide. After uploading a .jar file, it is additionally stored in the com.fujitsu.asm.lcm_#\templates\customize subdirectory of the Interstage ASM client or Eclipse installation directory.


5 Customizing SCM Behavior This chapter describes how you can customize the behavior of SCM and DMS.

5.1 Introduction SCM comes with some configuration files, which define properties that influence the default behavior of SCM and/or its graphical user interface. These properties can be adapted to meet individual requirements.

If not described differently, all settings are evaluated independent of the type of connection (client/server or remote mode).

DMS is based on SCM functionality. Therefore, some adaptations in SCM affect DMS as well. This is indicated by the "Affecting DMS" line in each of the following sections.

5.2 Client Interface Properties The subsequent sections describe the properties that can be modified for changing the behavior of the SCM client interface in Eclipse.

The properties are defined in an XML file, which must be available on each client in the following subdirectory of the Eclipse or Interstage ASM client installation directory:

plugins/com.fujitsu.enabler.eclipse.scm_#

The default settings of SCM are defined in the following file in this directory:

settings.xml

Do not change any settings directly in this file, because it may be overwritten when you install a newer version of SCM. Instead, copy the file to the following file in the same directory and adapt the new file as required:

settings_customized.xml

The settings are read once during the startup of the client interface. SCM first tries to read the settings_customized.xml file. If this file does not exist, it reads the settings.xml file.

5.2.1 Selectable Repositories Property name: repositories_selectable

Possible values: true or false

Default value: true

Affecting DMS: true

Description:

For security reasons, it may be necessary to disable the possibility to see all repositories located on a specific server. When set to false, any repository select lists will be hidden, i.e. the user must know the exact name of the repository to address.


5.2.2 Idle Repository Connections Property name: idleSecondsBeforeDBConnCut

Possible values: 0 … <MAX_INT>

Default value: 900

Affecting DMS: true

Description:

The SCM client interface comes with an automatic repository connection management component. This component is used to automatically close open repository connections that have been idle for a specified time.

This property defines the number of seconds until an idle connection is closed. If you specify "0", idle connections will never be closed automatically.

5.2.3 Partial Check-Out Property name: pc


Default value: true

Affecting DMS: false

Description:

SCM provides the possibility to check out a substructure of a configuration with or without its parent folders (partial check-out). This property defines whether partial check-out is supported. When set to false, partial check-out is not supported.

5.2.4 Assignment of Non-Browseable Releases Property name: ur


Default value: true


Description:

A linked release can be "browseable". A browseable release resides in a repository, and you can navigate it like any other release. If a release is defined as non-browseable, it usually does not reside in a repository.

This property defines whether non-browseable releases can be assigned to projects or products. When set to false, non-browseable release assignments cannot be created.

5.2.5 Linked Releases Property name: ps


Default value: true



Description:

You can establish relations between releases of different projects. By linking releases, you can model dependencies and store them in SCM, for example, for documentation purposes. The SCM product management functionality uses linked releases as its technical basis.

When this property is set to false, linked releases cannot be created for projects. This means that the assignment of linked releases is only allowed for product releases and not for project releases.

5.2.6 Interstage Studio Property name: isstudio


Default value: false


Description:

When set to true, several restrictions that apply to Fujitsu Interstage Studio will be activated.

5.2.7 Folder Decoration Property name: folder_decoration


Default value: true


Description:

Folder decorations allow additional information to be displayed in a folder's label and icon. When set to false, the folder decoration (“>”) in Eclipse will be omitted. This decreases CPU usage.

5.2.8 Customized Label Decoration Property name: decoration_extension


Default value: false

Affecting DMS: true

Description:

When set to true, the SCM extension point for customized label decorations in the navigation tree is enabled. This extension point supports user-defined extensions to the textual and graphical representation of SCM-specific entities. However, enabling this property may result in worse navigation performance. Therefore, the property is disabled by default.


5.3 Client-Specific Properties The subsequent sections describe the client-specific properties that can be modified for changing the behavior of SCM core functionality.

The properties are defined in an XML file, which must be available on each SCM client in one of the following directories depending on the interface being used:

• Client interface (Eclipse): plugins\com.fujitsu.enabler.eclipse.scm.core_# subdirectory of the Interstage ASM client or Eclipse installation directory.

• Web interface and remote mode: WEB-INF subdirectory of the iscm<version> Web application deployment directory on the Web/application server.

• Command line interface: Root of the command line interface installation directory.

The default settings of SCM are defined in the following file in this directory:

appsettings.xml

Do not change any settings directly in this file, because it may be overwritten when you install a newer version of SCM. Instead, copy the file to the following file in the same directory and adapt the new file as required:

appsettings_customized.xml

The settings are read once during the startup of an SCM interface or application, for example, when you start the SCM client interface or when you call a command at the command line interface. SCM first tries to read the appsettings_customized.xml file. If this file does not exist, it reads the appsettings.xml file.

5.3.1 Local Mail Settings Property names: mail.host; mail.sender; mail.senderpwd

Possible values: string values

Default value: none

Affecting DMS: true

Description:

If you specify values for these properties, they override the corresponding mail settings in the repository.

5.3.2 Line Break Character Property name: character.linebreak

Possible values: string values

Default value: ¶ character

Affecting DMS: true

Description:

With this property, you define the textual representation of line breaks within commit comments if their value must be displayed in a single line.


6 Extending SCM SCM provides a Java API which allows you to develop custom applications that access the repositories and use the software configuration management functions of SCM. The user interfaces of SCM are based on this API.

You can use the API functions for extending the existing SCM functionality: Most of the SCM actions offer predefined "extension hooks" where one or more user-defined methods can be registered. The methods receive all existing information about the affected entity and the parameters of the action (e.g. commit comment) through a defined interface. The methods can modify the values or even abort the whole process.

Examples for possible extensions are:

• Check whether a commit operation is allowed.

• Execute validation rules before a specific action can be invoked.

• Perform additional actions during a commit, such as counting the number of changed lines or reformatting the source code according to company-specific rules.

• Synchronize third-party tools after an SCM action has been invoked, for example, for integrating problem reporting systems.

• Send emails to project members after an SCM action has been executed successfully.

Note: Extensions you make to SCM also apply to DMS because DMS is based on SCM.

6.1 Extension Hook Types The following types of extension hooks are supported by most of the SCM actions:

Start

CheckPreconditions

BEFORE

Initial Actions

Process Item

DURING

AFTER

Final Actions

End

for allaffected items

RepositoryTransaction

SCM Action

OfferedExtension

Hooks



6.1.1 BEFORE Extension This type of extension offers the possibility to perform additional checks before a specific SCM action is executed. It is called before the action is executed, but after major preconditions, such as authorities and access rights, have been checked.

Use this type of extension, for example, for the following:

• Modification of action arguments (e.g. commit comment)

• Check of additional preconditions

6.1.2 DURING Extension This type of extension offers the possibility to perform additional steps or modifications for every item that is affected by a specific SCM action. It is called for every item which is affected by an action, but before the action itself is executed for the item.

Use this type of extension, for example, for the following:

• Modification of the action arguments if they are item-specific (e.g. modify a commit comment depending on the item's content)

• Execution of additional item-specific operations (e.g. automatic source code formatting)

If an extension needs to access each item affected by an operation, always use the DURING extension instead of implementing and invoking a second recursion through the entire item structure.

Note: Your implementation of a DURING extension must take care of performance issues, because it will be called for every item.

6.1.3 AFTER Extension This type of extension offers the possibility to perform additional steps after a specific SCM action has been executed successfully. It is called after the action has been processed successfully, but before a corresponding transaction is committed in the repository. At this time, it is still possible to roll back all changes in the repository.

Use this type of extension, for example, to check for successful execution of an action before work is continued.

6.1.4 Example The following picture shows a sample commit action, which demonstrates the behavior described above:

Commit ( <File A; File B>; “Comment” )

t SCM API

Extension 1 (before & during)

Start BeforeDuringFile A

DuringFile B After End

Extension 2 (during & after)


6.2 Architecture User-defined extensions are executed on the client where the corresponding SCM action is invoked. This is because:

• SCM is designed as client/server application for balanced and high-performance resource handling. All SCM actions are executed on the SCM clients.

• Almost all SCM actions are executed in transactions, which are client-specific and cannot be shared between different machines.

For these reasons, all Java classes and other files required for user-defined extensions must be available on the relevant SCM clients in a directory which depends on the user interface being used:

• Client interface (Eclipse): plugins\com.fujitsu.enabler.eclipse.scm.core_#\hooks subdirectory of the Interstage ASM client or Eclipse installation directory.

• Command line interface: hooks subdirectory of the command line interface installation directory.

• Web interface and remote mode: hooks subdirectory of the iscm<version> Web application deployment directory on the Web/application server.

You can distribute your extension implementations manually to each of the clients, or make use of the automatic deployment features of SCM. For details, see Section 6.4 Defining Extensions.

Note: Extension hooks are offered by the SCM API. The interfaces based on this API, like the client interface do not provide extension mechanisms.

SCM API

Extensions

Client Interface (Eclipse plug-ins)

Command Line Interface

Remote Mode

Web Interface

Extension Hooks

6.3 Interface Every extension must provide a hook listener, which must be developed as a Java class and implement a predefined interface. This is necessary for passing the SCM entities (which might exist only logically in a transaction) as arguments to the extension. If the extension consists of functions that must be called in any other way (e.g. a command line call), a wrapper class must be provided, which implements the predefined interface and invokes the functions.

The class name of the interface is:

com.fujitsu.enabler.scm.IEScmExtensionHook

Refer to the javadoc documentation of the SCM API or the delivered sample extensions for implementation details.

6.4 Defining Extensions Any extensions made to SCM must be defined in an XML file. This file as well as the implementations of the extensions can be stored locally on the clients, or centrally in each repository to which the extensions are applicable.

Local storage of the files is recommended for testing purposes during the extension development phase. Repository-based storage can be used when the extensions have been released.

SCM always checks first whether the repository contains any extension definitions. If no definition file is found, a local file will be used.

6.4.1 Local Definition SCM includes a sample extension hook definition file:

sample_hooks.xml

This file is installed in one of the following directories, depending on the interface

• Client interface (Eclipse): plugins\com.fujitsu.enabler.eclipse.scm.core_#\hooks subdirectory of the Interstage ASM client or Eclipse installation directory.

• Command line interface: hooks subdirectory of the command line interface installation directory.

• Web interface and remote mode: hooks subdirectory of the iscm<version> Web application deployment directory on the Web/application server.

The hooks directory must also contain the Java archives (.jar files) which include the extension implementations. SCM provides some sample extensions whose implementations are stored in the sample.jar file in the hooks directory. The extensions are defined in the sample_hooks.xml file, but commented out by default.

If you want to define extensions, copy the sample_hooks.xml file to the following file in the same directory and adapt the new file as required:

hooks_customized.xml


The hooks_customized.xml file is read once during the startup of an SCM interface or application, for example, when you start the SCM client interface or when you call a command at the command line interface.

6.4.2 Global Definition If extension hooks are to be activated for all users of a repository, the repository administrator can import the corresponding extension hook definition file and all required Java archives into the repository. To do this, the client or command line interface can be used. For details, refer to the Interstage ADM Software Configuration Management User Guide or to the Interstage ADM Command Line Interface manual.

The extension hook definition file in a repository is read once when an SCM interface or application connects to the repository, for example, when you access the repository at the SCM client interface for the first time or call a command at the command line interface.

SCM automatically copies the Java archives containing the extension implementations from the repository to all SCM clients where and when they are required.

On the client, the archives are stored in the corresponding hooks subdirectory. A log file, escmdeploy.log, in the same directory records each deployment of a Java archive.

6.4.3 XML Syntax of an Extension Hook Definition File The extension hook definition uses the following XML syntax: <!ELEMENT extensions (jarfile | extension)*> <!ELEMENT jarfile*> <!ATTLIST jarfile name CDATA #REQUIRED crc32 CDATA #IMPLIED >

• name – The name of a required .jar file (relative to the /hooks folder).

• crc32 – Optionally, the CRC32 checksum of the .jar file (in hexadecimal notation).

Note that all SCM-specific .jar files are automatically included in the classpath. <!ELEMENT extension (action | hook)*> <!ATTLIST extension name CDATA #REQUIRED > • name – Unique name for this extension (user-defined). <!ELEMENT action> <!ATTLIST action id CDATA #REQUIRED > • id – ID of the SCM action for which the extension is provided. Refer to Section 6.6,

SCM Actions Supporting Extensions, for a list of all supported actions.


<!ELEMENT hook> <!ATTLIST hook class CDATA #REQUIRED before CDATA #IMPLIED during CDATA #IMPLIED after CDATA #IMPLIED > • class – Java class implementing the extension (must implement

com.fujitsu.enabler.scm.IEScmExtensionHook). This class must be available in one of the required .jar files specified by their name (see above).

• before – Defines whether the extension attaches to the BEFORE hook (0 or 1).

• during – Defines whether the extension attaches to the DURING hook (0 or 1).

• after – Defines whether the extension attaches to the AFTER hook (0 or 1).

Example <extensions> <jarfile name="sample.jar” crc32=”BF54352A0” /> <extension name="LineCounter"> <action id="ACTION_RES_COMMIT" /> <hook class="com.fujitsu.escm.samplehooks.LineCounter" before="1" during="1" /> </extension> </extensions>

6.5 Implementing Extensions This section describes important interfaces, classes and methods of the SCM API which you will use for implementing extensions.

6.5.1 Interface Every extension must provide an extension hook listener, which must be developed as a Java class and implement the following interface:

com.fujitsu.enabler.scm.IEScmExtensionHook

Refer to the javadoc documentation of the SCM API or the delivered sample extensions for implementation details.

6.5.2 Data Exchange The data exchange between SCM and the extension is handled by the following class:

com.fujitsu.enabler.scm.EScmExtensionHookArguments

This class provides the following common properties:

a. Action Identifier

int getAction();

This property returns the action identifier (ID) of the underlying SCM action as an integer value. Refer to Section 6.6, SCM Actions Supporting Extensions, for a list of all supported identifiers.


Example

Check whether the current action is a commit operation:

public void during(EScmExtensionHookArguments args) throws Exception { if (args.getAction() == EScmConstants.ACTION_RES_COMMIT) { ... } }

b. Repository

EScmDatastore getDatastore();

This property returns the current repository as an EScmDatastore object.

Example

Get the name of the current repository and the user connected to it:

public void during(EScmExtensionHookArguments args) throws Exception { EScmDatastore db = args.getDatastore(); String currentUser = db.getUserName(); ... }

c. Root entity

Object getRootEntity ();

This property contains the root entity of the underlying SCM action. The type and value of the returned entity is action specific as described in Section 6.6, SCM Actions Supporting Extensions (column “Entity Type”).

Example

Get the destination path of an export action (ACTION_RES_RETRIEVE):

public void during(EScmExtensionHookArguments args) throws Exception { EScmLocalResource destination = (EScmLocalResource) args.getRootEntity(); System.out.println("Export goes to:" + destination.getPath()); ... }

Example

Enforce a short description for every release which is to be closed (ACTION_REL_CLOSE):

public void before(EScmExtensionHookArguments args) throws Exception { EScmRelease release = (EScmRelease) args.getRootEntity(); if (release.getComment().length() == 0) { throw new Exception("Release description missing."); } ... }

d. Current entity

Object getEntity ();

This property contains the entity with is currently processed by the underlying action. The type and value of the returned entity is action specific as described in Section 6.6, SCM Actions Supporting Extensions (column “Entity Type”).


Example

Get the currently exported file (ACTION_RES_RETRIEVE):

public void during(EScmExtensionHookArguments args) throws Exception { EScmLocalResource destination = (EScmLocalResource) args.getEntity(); if (destination.isFile()) { EScmLocalFile file = (EScmLocalFile) destination; ... } }

e. Other values

Object getArgument (<key>);

This property returns any available data, which is offered by the underlying action. The available arguments, their data types and values are action specific as described in Section 6.6, SCM Actions Supporting Extensions.

Example

Get the comment specified for a commit operation:

public void before(EScmExtensionHookArguments args) throws Exception { EScmCommitDescription dscr = (EScmCommitDescription) args.getArgument("dscr"); System.out.println("Entered comment: " + dscr.getComment()); ... }

Example

Get the type of the commit operation (sample for casting numeric values):

public void during(EScmExtensionHookArguments args) throws Exception { int cmType = ((Integer) args.getArgument("cm")).intValue (); ... }

Depending on the argument, its value may be read-only (R), write-only (W), or read/write (R/W). For details, refer to Section 6.6, SCM Actions Supporting Extensions.

Example

Add some characters to every commit comment:

public void before(EScmExtensionHookArguments args) throws Exception { EScmCommitDescription dscr = (EScmCommitDescription) args.getArgument("dscr"); dscr.setComment(dscr.getComment() + " (modified by Hook)"); ... }


6.5.3 Error Handling The error handling depends on the interface from which the SCM action is called. In the client or Web interface, a normal error message is displayed. At the command line interface, errors are printed to the error output stream. If an exception occurs WITHIN an extension, a short note is added to the end of the error message describing the origin of the problem:

Example:

----------------------------------------------------- This operation is not allowed.

[Extension hook - com.fujitsu.escm.samplehooks.Trace] -----------------------------------------------------

Attention! The whole operation is aborted if the extension hook causes any kind of error. It is not possible to skip parts of the processed items.

6.5.4 Logging SCM records all actions carried out in repositories in log files. The log’s content describes the affected entities of each action and the required parameters. For any operation carried out in an extension, you can:

• Add additional information to the log entry generated by the corresponding SCM action.

• Generate additional log entries which will be appended to the log file.

For this purpose, SCM provides two predefined arguments which can be set in extensions: The log_addon argument is used to add information to a log entry, the log_entries argument is used to generate additional log entries. These arguments can be combined in an extension.

There is no restriction concerning the type of characters used in log entries made by extensions. This means that the extension is responsible for using valid expressions.

Maximum Length of Log Entries

The length of log entries is restricted. Every entry is stored in a binary format specific for SCM. It must not exceed the maximum length of 1998 bytes. If a log entry exceeds the maximum length, it will be shortened. Shortened entries end with … characters. You have to consider this when defining the log arguments in your extensions.

The maximum length is calculated with the following formula: LDBENC( Long(Date) + UTF8(UID) + INT(Action) + UTF8(Description) )

LDBENC(exp) Length of the expression exp according to the encoding defined for the repository (e.g. UTF-8).

LONG(Date) Long value of the date and time of the log entry.

UTF8(UID) UTF-8 encoded user ID of the user who has carried out the action.

INT(Action) Integer value of the action ID of the SCM action.

UTF8(Description) UTF-8 encoded entity and additional information.


Adding Information to Log Entries

In an extension, additional log entry information can be passed to the SCM action as a string in the log_addon argument of the argument buffer. This applies to all available extension hooks.

The additional information is added to the log entry of the SCM action, preceded by the string {x}.

Example

Code example in an extension:

/** * Before hook */ public void before(EScmExtensionHookArguments arguments) throws Exception { arguments.setArgument("log_addon", "additional text"); }

Sample output of a log entry:

In this example, the extension adds the version number of the used SCM version to the log entry which is created by the SCM action for registering a project.

Generating Additional Log Entries

In an extension, you can also add complete log entries to the SCM log file. This can be useful especially if the SCM log entries already need most of the available space.

For security reasons, the log entry’s date/time, user, action ID and affected entity cannot be modified. They are set by the corresponding SCM action. This also allows for retrieving dependent log entries with log filters.

Any number of additional log entries can be passed to the SCM action as a string array in the log_addon argument of the argument buffer. This applies to all available extension hooks.

The additional information in the added log entries is preceded by the string {x}.

Example

Code example in an extension:

/** * Before hook */ public void before(EScmExtensionHookArguments arguments) throws Exception { String addLogs[] = new String[] { "Additional log entry 1", "Additional log entry 2" }; arguments.setArgument("log_entries", addLogs); }

The log entries of the extension are added to the relevant log file in the given order following the log entry of the SCM action.


Sample output of log entries:

In this example, an extension adds log entries for a commit operation.

Evaluating Log Arguments

It depends on the SCM action, at which time the specified log arguments are evaluated. In general, SCM looks for the arguments at the time a log entry is created.

Actions on Single Items (e.g. rename release):

For single-element actions, additional log entry content can be defined in the BEFORE or the DURING extension hook.

Actions on Multiple Items (e.g. commit):

To generate one log entry for all items, you define it in the BEFORE extension hook. To generate one entry for each item, you define it in the DURING extension hook.

A definition in the AFTER extension hook is not evaluated.


6.5.5 Template The following code can be used as a template for implementing extensions. The HookTemplate class implements the IEScmExtensionHook interface and provides methods for BEFORE, DURING and AFTER extensions.

/**+++***************************************************** * ESCM Extension Hook Sample * * Copyright (c) FUJITSU LIMITED 2008 * All rights reserved. * * Company: FUJITSU LIMITED **---****************************************************/ package com.fujitsu.escm.samplehooks; import com.fujitsu.enabler.scm.*;

/** * Extension Hook Template */ public class HookTemplate implements IEScmExtensionHook { /** * Before hook */ public void before(EScmExtensionHookArguments arguments) throws Exception { }

/** * During hook */ public void during(EScmExtensionHookArguments arguments) throws Exception { }

/** * After hook */ public void after(EScmExtensionHookArguments arguments) throws Exception { }

}


6.6 SCM Actions Supporting Extensions This section provides reference information on all SCM actions that support extensions.

6.6.1 Assign Subrelease Action ID Entity Type Description

ACTION_REL_ASSIGNREFRELEASES EScmRelease Assigns or deassigns a linked or member release to/from a project or product release

Arguments

Name Key Argument Type R/W Description

ReleaseInfo info EScmReleaseInfo R Assignment info

Deassign del Boolean R TRUE := deassign release FALSE := assign release

6.6.2 Check Out Action ID Entity Type Description

ACTION_RES_CHECK_OUT EScmLocalResource Completely or partially checks out configurations

Arguments


Configuration cfg EScmConfiguration R Working configuration

Item itm EScmItem R Affected item

WithParents wp Boolean R Rebuild parent structure (only for partial check-outs)

WithSubstructure ws Boolean R Check-out including substructure

ReadOnly ro Boolean R Check out in read-only mode

6.6.3 Change Item Rights Action ID Entity Type Description

ACTION_RES_SETACCESSRIGHTS EScmItem Changes access rights for an item

Arguments


ReadRights read Vector R/W Users & groups with read rights

WriteRights write Vector R/W Users & groups with write rights

OwnerRights owner Vector R/W Users & groups with owner rights

DefaultRights def Boolean R/W Set default rights


6.6.4 Change Project Access Groups Action ID Entity Type Description

ACTION_PRJ_CHANGERIGHTS EScmProject Changes the access groups of a project

Arguments


Rights rights String R/W New project access groups (separated by “;”)

6.6.5 Change Configuration State Action ID Entity Type Description

ACTION_CFG_STATECHANGE EScmConfiguration Changes the state of a configuration

Arguments


NewState state EScmState R Target state of the configuration

6.6.6 Close Release Action ID Entity Type Description

ACTION_REL_CLOSE EScmRelease Closes a release

Arguments


Configuration cfg EScmConfiguration R Released configuration

State state EScmState R/W Target state of the released configuration

6.6.7 Close Working Branch Action ID Entity Type Description

ACTION_CFG_CLOSEBRANCH EScmConfiguration Closes a working branch

Arguments


Name name String R/W New name of the closed branch

State state EScmState R/W Target state of the closed branch


6.6.8 Commit Resources Action ID Entity Type Description

ACTION_RES_COMMIT EScmLocalResource Commits new, changed or deleted resources to the repository

Arguments



Description dscr EScmCommitDescription R/W Commit description

Overwrite ovw Boolean R Override mode (Override & Commit)

The following arguments are valid only for a DURING extension:


New Version newvers String R Name of the new version

Mode cm Integer R Type of committed resource: 0 := Changed resource 1 := New resource 2 := Deleted resource

NewFilePath newfile String W Full path and name of a file, whose contents are to replace the contents of the committed file.

Use this option if the contents of the committed file are to be modified before it is stored as a new version (e.g. with modified line endings). You would create the new contents in a temporary file and set the file name afterwards in this key. If the commit succeeds, the original file contents will be replaced with the contents of the specified file.

Note that a file resource will always be committed if the local working version was changed compared to the repository version. This means that even if an extension reverts all local changes, the “unchanged” file will be committed as a new file version to the repository.

NewFile Deletion

Newfile delete

Boolean W TRUE := The temporary file, which has been specified with the “newfile” key, is to be deleted after the commit has succeeded (default: FALSE).

The given entity (EScmLocalResource) might sometimes be null, for example, when a new folder is created directly in the repository. For verifying the type or name of the entity, use the Item argument in the DURING extension.


6.6.9 Configuration Locks Action ID Entity Type Description

ACTION_CFG_LOCK EScmConfiguration Sets or clears configuration locks

Arguments


Clear clr Boolean R TRUE := Clear lock(s) FALSE := Set lock(s)

6.6.10 Create Release Action ID Entity Type Description

ACTION_REL_NEWBRANCH EScmConfiguration Creates a new release based on the given configuration

Arguments


Name name String R/W Name of the new release

FollowUp fup Boolean R Follow-up release

Description dscr String R/W Description of the new release

The following argument is valid only for an AFTER extension:

NewRelease rel EScmRelease R The new release

6.6.11 Create Snapshot Action ID Entity Type Description

ACTION_CFG_SNAPSHOT EScmConfiguration Creates a new snapshot of the given configuration

Arguments


Name name String R/W Name of the snapshot

State state EScmState R/W Target state of the snapshot


Base Configuration

cfg EScmConfiguration R Base configuration of this operation. The new created snapshot is available within the root entity property (getRootEntity)


6.6.12 Create Working Branch Action ID Entity Type Description

ACTION_CFG_NEWBRANCH EScmConfiguration Creates a new working branch based on the given snapshot

Arguments


Name name String R/W Name of the branch


NewBranch cfg EScmConfiguration R The new configuration

6.6.13 Create Workspace (Local Resource Monitor) Action ID Entity Type Description

ACTION_WSP_CREATE EScmConfiguration Creates a new workspace for the given configuration, which is used for monitoring local changes

Arguments


RootFolder root EScmLocalFolder R Root folder of the local project to be monitored

Host host String R Name of machine hosting the local project

Comment dscr String R/W Description of the workspace

Active active Boolean R Flag which defines whether the workspace should be set as active

6.6.14 Delete Configuration Action ID Entity Type Description

ACTION_CFG_DELETE EScmConfiguration Deletes an SCM configuration

6.6.15 Delete Intermediate Versions Action ID Entity Type Description

ACTION_REL_DELTMPVERSIONS EScmConfiguration Deletes intermediate versions in a configuration

Arguments


The following argument is valid only for a DURING extension:

Item itm EScmItem R Item version which will be deleted

The DURING extension is called for every item which will be deleted.


6.6.16 Delete Project Action ID Entity Type Description

ACTION_PRJ_DELETE EScmProject Deletes an SCM project

6.6.17 Delete Release Action ID Entity Type Description

ACTION_REL_DELETE EScmRelease Deletes an SCM release

6.6.18 Delete Workspace (Local Resource Monitor) Action ID Entity Type Description

ACTION_WSP_DELETE EScmWorkspace Deletes an SCM workspace which is used for monitoring local changes

6.6.19 Empty Lost & Found Folder Action ID Entity Type Description

ACTION_PRJ_EMPTYLOSTANDFOUND EScmProject Empties the Lost & Found folder of a project

6.6.20 Get File Content Action ID Entity Type Description

ACTION_RES_GETCONTENTS EScmFile Retrieves the contents of a file as an input stream without obtaining the file itself. This action is used, for example, in view and compare operations within Eclipse.

6.6.21 Mark Resource As Merged Action ID Entity Type Description

ACTION_RES_MARKASMERGED EScmLocalResource Marks a local file as merged

Arguments



The following argument is valid only for a DURING extension:

Item itm EScmItem R Item with which the local resource has been merged

6.6.22 Reactivate Release Action ID Entity Type Description

ACTION_REL_REACTIVATE EScmRelease Reactivates a closed release


6.6.23 Rename Configuration Action ID Entity Type Description

ACTION_CFG_RENAME EScmConfiguration Renames an SCM configuration

Arguments


Name name String R/W New name of the configuration

6.6.24 Rename Project Action ID Entity Type Description

ACTION_PRJ_RENAME EScmProject Renames an SCM project

Arguments


Name name String R/W New name of the project

6.6.25 Rename Release Action ID Entity Type Description

ACTION_REL_RENAME EScmRelease Renames an SCM release

Arguments


Name name String R/W New name of the release

6.6.26 Resource Locks Action ID Entity Type Description

ACTION_RES_LOCK EScmItem Sets or clears resource locks

Arguments


Clear clr Boolean R TRUE := Clear lock(s) FALSE := Set lock(s)

6.6.27 Resource Notification Interests Action ID Entity Type Description

ACTION_RES_NOTIFICATIONS EScmItem Registers or unregisters a notification interest for a resource

Arguments


Unregister ureg Boolean R TRUE := Unregister interest FALSE := Register interest


6.6.28 Retrieve Resources Action ID Entity Type Description

ACTION_RES_RETRIEVE EScmLocalResource Completely or partially exports configuration structures

Arguments




OnlyMarkedItems marked Boolean R TRUE := Export only resources marked for export

6.6.29 Share Project Action ID Entity Type Description

ACTION_PRJ_REGISTER EScmLocalResource Creates a new SCM project for the given local folder. Afterwards, the local folder will be under version control.

Arguments


Name name String R/W Name of new project

AccessGroups gids String R/W List of up to 8 project access groups (separated by “;”)

HiddenProject hide Boolean R/W TRUE := Create a hidden project (handled as a product)


NewProject prj EScmProject R The new project

6.6.30 Update Configuration Action ID Entity Type Description

ACTION_CFG_UPDATE EScmConfiguration Update configuration properties

Arguments


Properties props EScmProperties R/W Properties which are to be defined for the configuration

ChangedProperties changes String R Command line based string which describes the changed properties (for details on the syntax of this string, refer to the Interstage ADM Command Line Interface manual)


6.6.31 Update Resources Action ID Entity Type Description

ACTION_RES_UPDATE EScmLocalResource Updates a local workspace with new, changed or deleted resources.

Arguments



Overwrite ovw Boolean R Override mode (Override & Update)

The following arguments are valid only for a DURING extension:


Mode cm Integer R Type of updated item: 0 := Changed item 1 := New item 2 := Deleted item

AutoMerge am Boolean R TRUE := The file contents will be merged automatically



6.7 Core Actions Supporting Extensions This section describes core actions which are independent of specific SCM actions. Only DURING extensions are supported by the core actions.

6.7.1 Protect Object Action ID Entity Type Description

ACTION_CORE_PROTECT EObject Protects an Enabler object version

The DURING extension is called before the object version is protected. BEFORE and AFTER extensions are NOT supported.

6.7.2 Delete Object or Version Action ID Entity Type Description

ACTION_CORE_DELETE EObject Deletes an Enabler object or object version

The DURING extension is called before the object or object version is deleted. BEFORE and AFTER extensions are NOT supported.

6.7.3 Create Object or Version Action ID Entity Type Description

ACTION_CORE_CREATE EObject Creates an Enabler object or object version

The DURING extension is called after the new object or version is created. BEFORE and AFTER extensions are NOT supported.

Documents

Interstage Application and Service Management V10