Link constraints in the RM application
Link constraints are rules that an administrator can set up to specify which kinds of links are allowed in a project or across projects. If no rules are created, all links are allowed. However, if you create rules, only the links in the rules are allowed.
Administrators can create link rules on the Link Constraints tab in the project properties. These rules govern the creation of links in Requirements Management (RM) projects and across RM projects on the same server.
- Link constraints cannot span applications.
- Link constraints are supported only for RM Link types such as Link To and RM user-defined link types. Link types that are OSLC-based such as Referenced By or Validated By or that are used for linking to other applications are not supported.
Link creation with link constraints
After you create link rules, the options for creating links from context menus and in the Create Link window are affected by those rules.
In the following example, a single rule specifies that a Business Goal artifact has a Satisfies link to a Vision artifact:
![New Rule window](../images/bus_sat_vis.gif)
Because this is the only rule in the project, no other links are allowed. If you are creating a link from a Vision artifact or Business Goal artifact, only the Satisfies and Satisfied By link types are available. No other link types are available from any other artifacts.
For example, if you create a link from a Business Goal artifact, only the Satisfies link type appears as a menu option:
![Menu option for Add a Link to the Artifact](../images/addlink_satisfies.gif)
In addition, in the Create Link window, you can select only those artifact types that are allowed based on the initial artifact type and the selected link type, as shown in the following image:
![Create Link window](../images/create_link_window.gif)
In the Create Link window, you can also select certain components and artifact types based on defined link constraints, including the artifact types that contain a cross-component artifact type.
Cross-project linking
To enable linking between artifacts in different projects, you must define a rule that allows linking for the particular link type in both projects, and the rules must match. When you create cross-project links, rather than using ANY as the link end, you can select a specific artifact type in target project.
For example, for the "Link (Link To/Link From)" link type, if you want Business Goal artifacts in Project 1 to link to Feature artifacts in Project 2 (which also implies that Feature artifacts in Project 2 can link from Business Goals in Project 1), you must define the rules as follows:
Project 1:
![Business Goal artifact links to any artifact type](../images/proj1_rule.gif)
Project 2:
![Any artifact type links from a Feature artifact](../images/proj2_rule.gif)
When you create link constraints, you can also select a cross-project or cross-component type as a link end. The cross-project or cross-component name is displayed after the artifact type name. For example, you can create a constraint such as Business Goal (Project A) Link To Vision (Project B), where Business Goal is the source artifact type, (Project A) is the source cross project type, Link To is the link type, Vision is the target artifact type, and (Project B) is the target cross project type.
Cross-component linking
To enable linking between components, you must define a rule that allows linking for the particular link type in both components. When you create cross-component links, you can select a cross-component type as a link end. The cross-component name is displayed after the type name in cross-component types.
Cross-project or cross-component linking is automatically enabled for system-defined link types. However, if link constraints are set the cross-project and cross-component linking is governed by the link constraint rules.
Cross-project linking and Cross-component linking for a custom link type
For cross-project or cross-component linking for a custom link type, you define a URI for the link type. For example, https://hostname.com/domain/myLabel. If you use link constraints, you must define equivalent URIs for the requirement types. If the URI of an artifact included in a link constraint is edited, the link constraint is not updated with the new URI. Since the link constraint is not updated the custom link type will no longer have the link constraint that is applied to. It is invalid since no type matches previous RDF URI and therefore it will not be displayed under link constraints section.
Flexibility for link rules
You can make link rules more flexible by using ANY as the target artifact type. For example, if you create a "Link" link type for a Business Process Diagram artifact, and you specify ANY as the target artifact type, you can create links from a Business Process Diagram artifact to any artifact type in the current project.
![Link Rules window](../images/link_any.gif)
In addition, you can specify ANY in a link rule to enable links to web resources or to artifacts in another RM project.
Automatic generation of link constraints
As a project administrator, you can automatically generate link constraint rules based on the existing link relationships by clicking Generate Rules. The link constraint rules that are required to satisfy existing link relationships are identified and appended to the list. If your project includes cross-project links, the cross-project rules are also automatically created for the specify project. To create the corresponding rule, you must click Generate Rules in the linked project.
You cannot automatically generate link constraints for custom types. If you create two projects that each have their own custom type, and create a link between them, when you click Generate Rules, the rules are created by using the ANY keyword. For example, the first project would contain a Project1CustomType Link to ANY rule, and the second project would contain an ANY Link To Project2CustomType rule.
Preferred link types
Preferred link types that you specify for an artifact type are subject to the link rules that are in effect. For example, if you have a preferred link type of Satisfies for an artifact type, but your link rules do not allow this link type, the Satisfies link type is ignored.
Versioning constraints
Constraints are versioned and handled by the configuration management capabilities; they can vary across configurations, be delivered in change sets, and can be compared and merged.