Configuring Friends and Consumers

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:

• Outgoing link: is the Collaboration Link that was created on its own.
• Incoming link: is the Collaboration Link that was created as the back link of the other link.

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 OSLC Remote 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 OSLC Remote 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 a OSLC Remote Application, the OSLC Remote Application would need to be registered in Jira as a friend, and at the same time, Jira would need to be registered in the OSLC Remote Application as a consumer... All this would be good enough if only Jira required to create Collaboration Links, but what about if the OSLC Remote Application 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 the OSLC Remote Application, and at the same time, the OSLC Remote Application would need to be registered as a consumer in Jira.

There are normally two ways to establish this connectivity:

• By requesting a provisional key.
  1. The friend application is registered first on the consumer.
  2. While registering, the consumer asks the friend to generate a provisional key working for a given password.
  3. If the friend application accepts the request, it registers the consumer on its side and returns the provisional key to it.
  4. The consumer will be able to use this key and password to access the friend once the provisional key becomes authorized.
   
• By reusing an authorized key.
  1. The consumer application is registered first on the friend.
  2. While registering, the friend administrator sets an authorized key and password for the consumer.
  3. The friend administrator needs to communicate, to the consumer administrator, the key and password set.
  4. The consumer administrator registers the friend using the given key and password.

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. Considering Jira will be the consumer and the OSLC Remote Application the friend, if you choose to use:

• Requesting a provisional key.
  1. You need to register the OSLC Remote Application as a friend of Jira first.
  2. While registering, you need to request a provisional key working for a password you choose.
  3. If the OSLC Remote Application accepts the request, it registers Jira as a consumer of it and returns the provisional key to it.
  4. You need to call/wait for the OSLC Remote Application administrator to change the provisional key to an authorized key before you can access the OSLC Remote Application.
   
• Reusing an authorized key.
  1. You ask the OSLC Remote Application administrator to register Jira as a consumer first.
  2. While registering, the OSLC Remote Application administrator sets an authorized key and password for Jira.
  3. The OSLC Remote Application administrator needs to communicate you the key and password set.
  4. You can now register the OSLC Remote Application as a friend of Jira using the given key and password.

This would be a good moment to get in touch with the OSLC Remote 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, different OSLC Remote Applications may support only one of them. But wait a moment, which remote 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:

1. Refer to related tasks in order to know how to manage (register) friends and consumers on Jira ^[1].
2. Get in touch with Jira project administrators and ask them:
   1. which OSLC Remote Applications need become friends of Jira ^[2].
   2. if latter friends are IBM Engineering Lifecycle Management (ELM) applications, whether the use of Global Configurations is required.
   3. whether they require to use IBM Jazz Reporting Service and/or IBM Engineering Lifecycle Optimization - Engineering Insights (ENI).
    
3. Get in touch with corresponding OSLC Remote Applications administrators to agree which method to use for becoming your applications friends each other.
4. Register, with the aid of OSLC Remote Applications administrators, required friends and consumers according to Jira project administrators needs.
5. Ask OSLC Remote Applications administrators to register required associations according to Jira project administrators needs.
6. If either Global Configurations or IBM Jazz Reporting Service/IBM Engineering Lifecycle Optimization - Engineering Insights are required, you need to follow the steps described on the Configuring Consumers for TRS topic.

Linking with IBM Rhapsody Model Manager artifacts
If the OSLC Remote Application is IBM Engineering Workflow Management and Jira users are planning to create Collaboration Links with IBM Rhapsody Model Manager artifacts, the TRS functional user must be associated to the Jira consumer corresponding to the IBM Engineering Workflow Management application; follow the Configuring Consumers for TRS topic to know how to associate the TRS functional user to a given consumer.

OSLC Schemes

Finally, it is worth mentioning that several rules can be applied when linking with a given friend or link type, please refer to the OSLC Schemes topic for details.

^[1] If your Jira instance is using an SSO plugin, follow first the steps of Whitelisting Jira OSLC discovery URLs in SSO environment topic. ^[2] Do not forget this implies Jira needs become friend of them as well.