A Collaboration Link is a link between two elements that belong to different applications. Typically, when a Collaboration Link is created from one Application A to one Application B, a back link is created (automatically) from Application B to Application A, so both elements may have a way to navigate to each other. In this scenario, where a link can exist either because it was created on its own, or because it was created as the back link of the other link, it is often useful to distinguish their nature with a role name:
Henceforth, when a Collaboration Link in Jira is said to be an outgoing link, it means it is a link whose creation was triggered from Jira (creating a back link on the CLM Application), whereas if it is an incoming link it means it is a link that was created as back link on Jira (due to a creation triggered from the CLM Application).
Creating Collaboration Links is speaking about trust between different applications. The triggering application of the Collaboration Link creation must access to the resources (artifacts) of the other application, and this one must allow the modification of them in order to create the link. All this must happen in an atmosphere of trust: applications must be registered in each other to allow this behavior only between registered applications. Now, the application allowing the access/modification of its resources is called the friend application, whereas the one requesting such access/modification is called the consumer application.
In this scenario, if Jira wanted to access/modify the resources of DOORS Next Generation (DNG), for example, DNG would need to be registered in Jira as a friend, and at the same time, Jira would need to be registered in DNG as a consumer... All this would be good enough if only Jira required to create Collaboration Links, but what about if DNG users also wanted to create links from their side? In this case, and to allow bidirectional creation of links, Jira would need to be registered also as a friend in DNG, and at the same time, DNG would need to be registered as a consumer in Jira.
There are normally two ways to establish this connectivity:
As you can see, everything is about a key and a password, the difference between last approaches is how they generate and share the key. Getting back to the Jira-DNG example, and considering Jira will be the consumer and DNG the friend, if you choose to use:
This would be a good moment to get in touch with the CLM Application administrator and agree on which method you both will use, keep in mind that whereas OSLC Connect for Jira supports both methods of making friends, most CLM Applications just support the method of requesting provisional keys. But wait a moment, which CLM Applications need become friends of Jira? And how is a friend or consumer registered on Jira?
Following is what you need to do to complete this configuration:
If Global Configurations are needed, you need also to:
||Leave it empty, system will create a key for you.|
||Whatever you want that you don't forget.|
||The same as
CLM LDXconsumer. This user is the one LDX will use when trying to fetch data from Jira, you need to make sure it will have enough access rights to see issues modified with Collaboration Links.
CLM LDXconsumer credentials .
If Jazz Reporting Service and/or RELM are required, you need also to:
CLM LDXconsumer credentials .