Links across project areas after enabling configuration management

To link across project areas in IBM® Engineering Lifecycle Management (ELM), 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.
Note: Link management and link validity are separate but related concepts:
  • Link management refers to where links are stored and built. For details, see the Linking after enabling configurations section.
  • Link validity status, sometimes called validity status, refers to the status of links between artifacts, which indicates whether the contents of two artifacts meet the intended meaning of the link between them. For details, see Link validity.

    Link validity information is stored separately from links: it is not stored in the link index.

    Not all applications provide validity status information on all link types.

For details about supported OSLC link relationships and how they appear in ELM applications after you enable configuration management, see Table 1 in Enabling your application to integrate with configuration-management-enabled ELM applications on Jazz.net.

Linking for administrators

To see, use, and create cross-project area links between artifacts, as a Jazz™ administrator, you must install the LDX and GCM applications.

If one or more Requirements Management (RM), Quality Management (QM), or Architecture Management (AM) project areas will use configuration management and link across project areas, ensure that the following applications are installed and registered:
Link Index Provider (LDX)
Builds and maintains an index of links between artifacts in different project areas. The first time the index builds (after you activate configuration management in the QM and RM applications, and enable it for at least one RM or QM project area) can 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 an increased frequency might decrease system performance. You can change this setting for each data source in the LDX application. For details, 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 global configuration.

To ensure that team members do not lose their configuration context when they switch between applications, the GCM application caches the links between global configurations and 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. For details, see Server settings for configuration management.

Note:
  • Upgrading from version 5 releases: If you upgrade a version 5 release to a version 6 release by using the command line or silent upgrade option, see Upgrading ELM. Complete the steps to register the LDX and GCM applications.
  • Single Jazz Team Server instance: In a single-server environment where all applications are on one Jazz Team Server instance, go to https://hostname:9443/jts/admin and in the left navigation pane, click Registered Applications. Verify that the LDX (/ldx) and GCM (/gc) applications are in the list.
  • Multiple Jazz Team Server instances: For a topology with multiple Jazz Team Server instances, see Getting started for application administrators (global configurations).

Linking for team members

To link to artifacts in other project areas, team members must work in a global configuration.

To create, see, or remove these links, you must set the current configuration context to a global configuration. If you work only in a local configuration context, the links do not resolve.

If you do not see the links that you expect between artifacts, refresh your 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. For details, see Cross-project links to versioned artifacts after enabling configuration management.

Linking before configurations are enabled

QM and RM applications: If you do not enable configuration management, the QM and RM applications use back links between artifacts in different project areas.

When a link exists between two artifacts in associated project areas, each application stores a link to the other's artifact. This process is 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 the RM and DM applications, which do not use back links.

AM application: If you do not enable configuration management, the application runs an OSLC query to obtain links to CCM and QM artifacts.

Linking after enabling configurations

After you enable configuration management, linking behavior appears the same as before, but only one application stores a link. For some applications, 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.

Important:
QM and RM applications: After you enable configuration management in at least one QM and RM project area, back links between artifacts are removed. Links between artifacts across project areas are now owned by and stored in only one of the 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.
Details:
  • An asterisk (*) indicates applications that do not contribute to, and are not polled by, the link index.
  • The RM application owns links only 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.

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 area that uses configuration management.
  • The thin solid arrows show that each application (product) is registered with Jazz Team Server.
  • The dotted lines are queries from Link Index Provider to build the link index.
  • The thick solid arrows show links 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. Link 4: RQM->RDNG: This label shows that, when polled, the QM application sends its links to RM artifacts to the link index.
  • Link Index Provider builds its link index in this way:
    • By polling the GCM application to get the links between global and local configurations
    • By polling the QM and CCM applications to find which artifacts they link to in associated project areas
    For details about updating the link index refresh rate, see Changing the frequency of link index updates.
Figure 1. Link storage and management in applications that are enabled for or are compatible with configuration management.

In the diagram, the abbreviations represent the following applications: RDNG = IBM Engineering Requirements Management DOORS Next, RMM = IBM Engineering Systems Design Rhapsody - Model Manager, RDM = Rational® Rhapsody Design Manager, RTC = IBM Engineering Workflow Management, RQM = IBM Engineering Test Management.


Architecture diagram of link management in ELM applications

In 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 configuration context.
  1. When a team member creates a link from a requirement to a work item, the link is created and stored in the CCM application. As the table shows, the CCM application owns links to requirements in the RM application.
  2. The next time the link index polls link-owning applications (the CCM and QM applications) to refresh its index, it adds information about the link from the work item to the requirement. For details about the polling frequency, see Link Index Provider (LDX).
  3. A team member opens the requirement and looks for a related work item:
    1. Using the current global configuration context to resolve the links, the RM application queries the link index for links from any work items to this requirement.
    2. The RM application 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 behavior in previous product versions.

video icon Video

Jazz.net channel
Software Education channel

learn icon Courses

IoT Academy
Skills Gateway

ask icon Community

Jazz.net
Jazz.net forums
Jazz.net library

support icon Support

IBM Support Community
Deployment wiki