Library > Articles >

Rational Solution for Collaborative Lifecycle Management 3.0.1 Installation – Frequently Asked Questions

Srikanth Bhushan, IBM
Last updated: February 20, 2012
Build basis: CLM 2011, Rational Team Concert 3.0.1, Rational Quality Manager 3.0.1, Rational Requirements Composer 3.0.1

This article provides all the information that is required for you to know before planning your CLM Deployment . The article tries to answer the common and critical questions which are significant for the deployment. This article also introduces some capabilities that should help you in the long run. If you are planning for an upgrade or migration, you can take a look into CLM 2011 Upgrade Frequently Asked Questions

The article is grouped into three sections:

Must Know’s to begin Installation

Back to top

Making the Right Choices

Back to top

Making Life Easier

Back to top

What are the Hardware and Software System Requirements for CLM 3.0.1?

The Comprehensive and up to date CLM System Requirements can be found here . The article provides the information about the Supported OS, Application Servers , Databases , Browsers, Memory Requirements and much more.

Back to top

Which version of Installation Manager is required to Install CLM 3.0.1?

You will need Installation Manager 1.4.3 or later to Install CLM 3.0.1.

Back to top

Where is the installer for CLM 3.0.1?

You can download the CLM 3.0.1 Installer here . Download the Installer which contains, Jazz Team Server,CCM, QM and RM Applications, specific to your Operating System. The installer will also include the Trial Licenses.

Back to top

What are the different ways of Installing CLM 3.0.1?

There are 2 ways:

Back to top

What is the Recommended order of Steps of Installation?

The Recommended order of Steps for Installation when you are using

1) CLM with the default Derby Database and Tomcat Application Server

2) CLM with any other supported Enterprise database and IBM WAS as the Application Server

Back to top

What is Public URI and Its significance?

The Wikipedia definition of URI – Uniform Resource Identifier is a string of characters used to identify a name or a resource on the Internet. Such identification enables interaction with representations of the resource over a network (typically the World Wide Web) using specific protocols. Schemes specifying a concrete syntax and associated protocols define each URI.

Architecturally, Jazz-based products use OSLC and RESTful interfaces. This means that artifacts (data) are referenced with URLs. When a dashboard shows information from a work item, it�s getting that work item information by traversing a URL. When you get a list of dashboards to choose from, each dashboard is referenced internally by a URL. All those URLs are written into the database. They�re not dynamically calculated. The actual URL is placed into the database. Jazz-based products construct these URLs by using the public URI and the root context.

Back to top

Can public URI be changed?

Once set, you Can’t Change the Public URI of CLM Applications. There is a comprehensive discussion around this – to see more click here

Back to top

What to consider when choosing a Public URI?

Its very important to plan and choose the right public URI since it cannot be changed later. Choose a public URI with a hostname that is

  • Fully Qualified
  • Stable over Time and
  • accessible from anywhere in the network.
Note that the URI that is based on a stable hostname can be rerouted to a different IP address through DNS.

Here are few things to consider before choosing :

  • Choose your protocol (http vs. https): By default the Jazz Team Server and applications use https for all protected resources and https is strongly recommended for secure communications within your network.
  • Determine your hostname: Choose a hostname that is unlikely to change, and that is resolvable via DNS within your network. This gives you the option to move the server to a machine with a different IP address and still maintain a stable URL. Ensure the hostname is fully qualified. Avoid using hostnames that cannot be resolved via DNS.Avoid hostnames such as ‘localhost’, or an IP address.
  • Determine the server port: By default the Jazz Team Server and applications use port 9443 for https communications. If you prefer to run on a different port, plan this ahead of time.
  • Determine the context root: The context root is determined when web-applications are deployed within the application server. This is the first segment after the host and port segment of the URL. For example, for the URL ‘https://u1.example.com:9443/ccm’ the context root is ‘ccm’.
  • Use the public URL of the JTS server if located on another machine: When you plan to have multiple applications on differnet servers and the Jazz Team Server on a different server, while setting up the applications you always have to use the public URL of the server where JTS is located.

Back to top

Which Database to use?

If you want to use a CLM Evaluation Deployment (for Evaluation demo or training purposes), you can use the Derby Database. The Derby database is limited to 10 users in an evaluation environment. Note that the reporting solution RRDI requires an enterprise database and will not work with the Derby database.

For medium and large scale deployments it is suggested to use any of the supported Enterprise Databases.

CLM 3.0.1 is supported with IBM Derby, DB2 Enterprise/Work Group/Express Server Editions V 9.5, V 9.7 , Microsoft SQL Server 2005, 2008, Oracle Database 10g, 11g.
For the detailed information on the Supported database please look into the System Requirements.

Back to top

How many Databases are Required?

For a full / new CLM deployment, you will need 4 databases:

  • One each for the QM and CCM applications,
  • One for the Jazz Team Server (JTS) and
  • One for the Data Warehouse – A common storage facility for reporting.
RM uses the JTS for its storage and does not require a seperate DB.

Note: All CLM applications require the databases use UTF-8 for character encoding.

Back to top

What is shared JTS? What are the Advantages?

A shared Jazz Team Server (JTS) is one to which more than one application are connected, usually from different computers.

Shared JTS for multiple applications include these advantages:

  • Central user and license administration
  • Lifecycle project administration (LPA)
  • Improved web-application navigation between applications
  • A Common data warehouse
  • Fewer administration and configuration duties

Note:

  • When an application has been connected to a JTS, it cannot later be connected to a different JTS.
  • Two instances of the RM application cannot be deployed onto the same JTS. Multiple RM instances will require separate JTS instances.
  • From reporting perspective, Rational Insight is the solution when multiple JTSs are used

Back to top

When do you need explicit instances of JTS?

If you require complete isolation between the users of different apps, or separate realms altogether, then separate JTS instances would be appropriate. If there is a logical affinity between the application instances, a shared JTS is recommended.

Back to top

What are the primary Deployment Topologies?

There are three primary deployment topologies

  • Evaluation Topology : Useful for demonstrations or training.
  • Departmental Topology: Useful for small teams that use single Application and DB server deployments.
  • Enterprise Topology: Useful for medium and large or production-sized teams that use multiple Application and DB Servers.

Back to top

Which Topology best suites me?

The answer to this question largely depends on your User, Usage requirements. The Sizing Guide gives the tested results for different Toplogies.
You should prepare and plan your deployments in such a way that you can migrate to higher topologies as the users and assets starts increasing.

If you are using CLM for evaluations, demonstration or training purposes with less than 10 users, you can use the Evaluation Topology. This topology is a general representation of an evaluation installation where all of the application and database software is installed on the same server. This topology is most suited for a single server architecture with Tomcat as the Application Server and Derby (which has 10 user limit) as the Database.

If you have a small to medium deployment use Departmental Topology. Here all the CLM applications are installed on a single app server and all DBs in another dedicated DB server. It is recommended to deploy using WebSphere Application Server and an enterprise database management system. For medium to large deployments Tomcat and Derby are not suitable.

If you have a production or medium-sized to enterprise sized teams with large volume deployments choose to use Enterprise /Fully Distributed CLM Deployment. Here the JTS is installed on one server and the CCM, QM, and RM applications are installed separately on their own servers. This deployment provides better scalability, Distributes processing, isolated memory consumption and has more multi-threading capacity. It is recommended to deploy using WebSphere Application Server and an enterprise database management system.

Back to top

Deployment evolutions? Can I change/evolve my deployments?

It is very important to understand that once the public URI root is set, it cannot be modified. There may be instances where you start with an Evaluation topology with all the applications installed on a same server but then later wish to change it. As your needs change and your project grows, you may decide later that you need to distribute the applications on separate hosts, to handle higher loads and provide greater throughput. Please note that the applications can move to other hosts, as long as the public URI root is preserved.

There are couple of techniques that can help you in planning your Deployment Evolutions.

  • Using Reverse Proxy ,which provides a web server, on a single host, that forwards requests to the applications.
  • Using Virtual Hosts server, which provides a separate host name for each application, even when the applications are installed on the same application .

Back to top

What are Virtual Host Names? How does it help my CLM Deployments?

Virtual hosts enable you to manage a single application server on a single machine as if the application server were multiple application servers each on their own host machine. It provides a separate host name for each application, even when the applications are installed on the same application server. You must decide and configure this when you deploy initially, because the public URI roots cannot be changed later.

Virtual hosts is one of the Techniques that can be helpful you need to change your topologies. By configuring a virtual host for each application, the public URI can remain stable in the case of a configuration change. For example, if the applications are moved to different servers, the public URIs can be preserved by using a virtual host in the public URIs hostname. You would simply redeploy the applications to the new machines, and preserve the original configuration files.

Know more about Using Virtual Host and Configuring Virtual Hosts in InfoCenter. .

Back to top

What is a Reverse Proxy? How does it help?

A reverse proxy is a proxy server that logically sits in front of a set of other servers and determines where to route a particular request.

Using this technique will be usefull in your CLM Deployment if you want to start off with a simple topology and redeploy to a more complex topology at a later date.For example, suppose you have installed CCM and JTS on the same physical host, ‘clmserver’ with the public URIs for CCM and JTS being configured as ‘https://clmserver:9443/ccm’ and ‘https://clmserver:9443/jts’ respectively. At a later stage, your requirement changes and you have to deploy them on separate hosts and on a new hardware. The URI stability has to be maintained since there is already existing data in the CCM and JTS repositories. To resolve this, you can setup a reverse proxy at the host ‘clmserver’, and then configure the proxy to route the requests for the ‘/ccm’ and ‘/jts’ context roots to separate hosts on which they are deployed. From the outside world, everything continues to be addressable using ‘clmserver’ even though the physical topology now uses multiple nodes.

The IBM� HTTP Server version 2.0.47.1 and higher supports reverse proxy with back-end secure socket layers (SSL) enabled configuration. To know how to configure reverse proxy, check the Infocenter.

Back to top

Can I manage CLM users using LDAP ? How?

Yes. You can manage users using LDAP. You must configure your Apache Tomcat or WebSphere Application Server to use an LDAP registry to authenticate users. For more information click here

Back to top

What is Single Sign On (SSO)? Is it supported with CLM?

In a multiple application environment, depending on which application server you have, you can simplify user access to the servers by implementing single sign-on (SSO). With SSO, users can sign on once to gain access to all servers without having to reauthenticate for each server. Tomcat and IBM Websphere Application Server are setup for single sign-on when the applications are installed onto the same server. However, on Websphere Application Server you can configure SSO in a distributed environment.

SSO is supported with CLM 3.0.1. To know more about how to Deploy Applications to use SSO on Tomcat and IBM Websphere Application Server, click here

Back to top

What are the backup considerations?

For each database, use the capabilities of your enterprise db vendor for backup/restore

  • For DB2 online backup solution, see here
  • For Oracle backup agent, see here

Note: Repotools export/import is not a backup and restore solution; it is for migration between vendors/servers.

Backups for CLM deployments need to manage multiple DBs for consistency between them. There are links between the repositories, and references from the data warehouse.Even a silo�ed product will have at least two databases (e.g., RRC-only requires JTS DB, DW DB).

Back to top

Should I Worry about the Security Certificates?

The JTS includes a self-signed certificate for SSL with the Apache Tomcat server. Some browsers and clients might display a warning when accessing your Jazz repository. To stop the warnings, Purchase a certificate from a well-known trusted Certificate Authority and install it.

To know how to install the Security Certificates click here

Back to top

Useful Links

About the author

Srikanth Bhushan is part of the Rational Support team in Bangalore. He can be contacted at srikanth.bhushan@in.ibm.com.

© Copyright 2011 IBM

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Feedback
Was this information helpful? Yes No 1 person rated this as helpful.