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.
- The friend application is registered first on the consumer.
- While registering, the consumer asks the friend to generate a provisional key working for a given password.
- If the friend application accepts the request, it registers the consumer on its side and returns the provisional key to it.
- 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.
- The consumer application is registered first on the friend.
- While registering, the friend administrator sets an authorized key and password for the consumer.
- The friend administrator needs to communicate, to the consumer administrator, the key and password set.
- 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.
- You need to register the OSLC Remote Application as a friend of Jira first.
- While registering, you need to request a provisional key working for a password you choose.
- If the OSLC Remote Application accepts the request, it registers Jira as a consumer of it and returns the provisional key to it.
- 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.
- You ask the OSLC Remote Application administrator to register Jira as a consumer first.
- While registering, the OSLC Remote Application administrator sets an authorized key and password for Jira.
- The OSLC Remote Application administrator needs to communicate you the key and password set.
- 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:
- Refer to related tasks in order to know how to manage (register) friends and consumers on Jira .
- Get in touch with Jira project administrators and ask them:
- which OSLC Remote Applications need become friends of Jira .
- if latter friends are IBM Engineering Lifecycle Management (ELM) applications, whether the use of Global Configurations is required.
- whether they require to use IBM Jazz Reporting Service and/or IBM Engineering Lifecycle Optimization - Engineering Insights (ENI).
- Get in touch with corresponding OSLC Remote Applications administrators to agree which method to use for becoming your applications friends each other.
- Register, with the aid of OSLC Remote Applications administrators, required friends and consumers according to Jira project administrators needs.
- Ask OSLC Remote Applications administrators to register required associations according to Jira project administrators needs.
- 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
users are planning to create
Collaboration Links with IBM Rhapsody Model Manager
artifacts, the TRS functional user
must be associated to the Jira
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.
Finally, it is worth to mention that when creating an incoming link, the OSLC Remote Application may request the creation of more than one link on
Jira; normally for specifying other relevant artifacts and their relationships. To learn more about a specific scenario when this occurs and how you
can prevent it, in case those extra artifact links are not relevant/required for you, please refer to the Setting Up Linking Mode topic.