Understand linking across project areas in configurations
To link across project areas in IBM Engineering Lifecycle Management (ELM), you must work in the context of a global configuration so that the links can be resolved. If you do not see the expected links between artifacts, refresh the browser page. A delay is possible as the link index might be updating.
For more information 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 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. A delay in showing cross-project area links might be because the Link Index Provider (LDX) did not finish building or refreshing its index.
You cannot create outgoing links from artifacts in a baseline. For more information, see Cross-project links to versioned artifacts after enabling configuration management.
Linking before configurations are enabled
IBM Engineering Test Management (ETM or QM) and IBM Engineering Requirements Management DOORS® Next (DOORS Next or 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 IBM Engineering Workflow Management (EWM or 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 IBM Engineering Systems Design Rhapsody® - Design Manager (RDM or DM) applications, which do not use back links.
IBM Engineering Systems Design Rhapsody - Model Manager (RMM or 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 configurations are enabled
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 to know how and when to link to baselined artifacts.
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.
Link owner | Owns links to artifacts in these applications | Queries the link index for links to these artifacts |
---|---|---|
Architecture Management (AM, or IBM Engineering Systems Design Rhapsody - Model Manager)* | RM | CCM, QM |
Requirements Management (RM, or IBM Engineering Requirements Management DOORS Next)* | RM | CCM, QM |
Quality Management (QM, or IBM Engineering Test Management) | QM, AM, RM | CCM |
Change and Configuration Management (CCM, or IBM Engineering Workflow Management) | CCM, AM, QM, RM |
- 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 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 3: 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 more information about updating the link index refresh rate, see Changing the frequency of link index updates.
- 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.
- 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 more information about the polling frequency, see Link Index Provider (LDX).
- A team member opens the requirement and looks for a related work item:
- 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.
- 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.