Links across project areas after enabling configuration management
To work with links across project areas, team members must work in the context of a
global configuration. If they do not see the expected links between artifacts, they should refresh
their browser page. Administrators must ensure that the Global Configuration Management (GCM) and
Link Index Provider (/ldx) applications are installed, and that the ldx.log
file does not indicate errors.
For details about supported OSLC link
relationships and how they appear in Rational® solution for
applications after you enable configuration management, see Table 1 in this article on Jazz.net.
see, use, and create cross-project area links between artifacts, as
a Jazz® administrator, you must
install the Link Index Provider and GCM applications.
If one or more Requirements Management (RM), Quality Management (QM), or Design Management (DM)
project areas will use configuration management and link across project areas, ensure that the
following applications are installed and registered:
Link Index Provider
Builds and maintains an index of links between artifacts in different project areas. The first
time the index is built (after you activate configuration management in QM and RM, and enable it for
at least one RM or QM project) might take a while, especially for a large project. By default, the
link index refreshes its information every 60 seconds. You can specify a more frequent refresh rate
so that team members see the links that they expect without a delay, but this might decrease system
performance. You can change this setting for each data source in the Link Index Provider
application. See Changing the frequency of link index updates
Global Configuration Management (GCM)
Provides the configuration context for resolving the links in the index. To see links between
artifacts in different applications, team members set their current configuration context to a
To ensure that team members do not lose their configuration
context when they switch among CLM
applications, the GCM application caches the links between global configurations their local
configurations. By default, this caching occurs asynchronously every 5 seconds. You can change this
setting in the GCM application's Advanced Properties > Global Configuration SDK section. This property is separate from and does not affect the refresh rate of the
link index. See Server settings for configuration management for guidance.
Single JTS server: In a single-server environment where all CLM
applications are on one Jazz Team Server (JTS) instance, go to
https://hostname:9443/jts/admin and in the left navigation
pane, click Registered Applications. Verify that Link Index Provider (/ldx)
and GCM applications (/gc) are in the list.
members must be in a global configuration to work with links to artifacts
in other project areas.
To create, see, or remove these links, you must set your current configuration context to a
global configuration. If you work only in a local configuration context, the links do not
If team members do not see the links that they expect between artifacts,
they should refresh their browser. There might be a delay in showing cross-project area links
because the link index provider has not finished building or refreshing its index.
You cannot create outgoing links from artifacts in a baseline. See the related topic about cross-project linking.
Linking before configurations
If you do not enable configuration management,
applications use back linking between artifacts in different project
When there is a link between two artifacts in associated CLM project
areas, each application stores a link to the other's artifact. This process is often called
back linking. For example, when you link a requirement to a work item, the RM
application stores a link to the work item, and the Change and Configuration Management (CCM)
application stores a link to the requirement.
This behavior is unchanged from version 5.0 and earlier, except for links between RM and DM,
which do not use back linking.
Linking after enabling configurations
After you enable configuration management, linking behavior appears the same as before, but only
one CLM application stores a link; the link in the other direction comes from the link index.
Understanding which applications store links helps you understand how and when to link to baselined
artifacts. To read about linking to baselined artifacts, see the related topic about cross-project
Rational Team Concert® and the
DM application do not require any activation or enablement steps to support configuration
RM and QM applications require a key to activate configuration management capabilities. See the
After you activate configuration management in RM and QM, you must also enable configuration
management in project areas. If you have links between RM and QM project
areas, both project areas must be enabled, or neither be enabled. You cannot link between
configuration-enabled and non-enabled project areas. Carefully plan which project areas to
enable, and consider enabling them at the same time. See the related topic.
After you enable
configuration management for RM and QM project areas, you cannot disable it.
Plan which local configurations to add to global configurations so that you link to the correct
versions of artifacts in other CLM project
areas. See the related topic about planning the global configuration hierarchy.
After you enable configuration management in at least one RM and QM project area, back links
between artifacts are removed. Links between CLM artifacts
across project areas are now owned by and stored in only one of the CLM
applications (products) involved in the link, as shown in the following table. For example, links
from tests to requirements are stored in and owned by the QM application because requirements are
typically baselined before tests are created. Therefore, you can link from a test case in a stream
to the baselined requirement that it validates.
Owns links to artifacts in these
Queries the link index for links to these artifacts
Requirements Management (RM, or RDNG)*
Design Management (DM, or RRDM)*
Quality Management (QM, or RQM)
QM, DM, RM
Change and Configuration Management (CCM, or RTC)
CCM, QM, DM, RM
An asterisk (*) indicates applications that do not contribute to, and are not polled by, the
DM stores its own links to design artifacts and requirements. It queries the index for links to
QM artifacts and RTC work item links.
RM owns only links to its own artifacts. Requirements are typically completed first in the
project lifecycle, when there might not yet be any related artifacts to link to. RM queries DM
directly for links to design artifacts.
A CLM application
that does not own links queries the link index for the links to its
artifacts in a given configuration context, and uses the information
to show the links back to the other artifacts.
Note: RM queries DM
directly to discover the links to RM artifacts, and uses that information
to show a link back to the DM artifact.
Consider the following example: when you link a requirement
to a work item, the link originates from, and is owned by, the CCM
application. When you open the requirement, the RM application queries
the link index for links to that artifact so it can provide the link
back to the work item.
The following diagram shows how links
work in a project that uses configuration management.
The thin solid lines show that each CLM
application (product) is registered with the Jazz™ Team
The dotted lines are queries from the Link Index Provider to build
the link index.
The thick solid arrows are
between artifacts in different applications (products). The origin of the arrow is the application
that owns the link.
Link x labels indicate a link direction that is stored in the index.
For example, Link 4: RQM->RDNG: RQM sends its links to all RDNG artifacts to the link index.
The Link Index Provider builds its link index:
by polling the GCM application to get the links between global and local configurations.
by polling the QM and CCM applications to find what artifacts they link to in associated
See the related topic for details about updating the link index refresh rate.
Continuing with the example, the following high-level steps describe how
the link index manages and resolves links. Assume that team members are working in a global
When a team member creates a link from a requirement to a work item, the link is created and
stored in CCM (RTC). As the table shows, CCM owns links to requirements in RM (RDNG).
The next time the link index polls link-owning applications (RTC and QM) to refresh its index,
it adds information about the link from the work item to the requirement. See this section for details about the
A team member opens the requirement and looks for a related work item:
Using the current global configuration context to resolve the links, RM queries the link index
for links from any work items to this requirement.
RM shows a link from the requirement to the corresponding work items. To team members, each
application seems to store a link to the other's artifact, similar to the back linking in previous