Rebuilding TRS Feeds

To reach the TRS Feeds page, log-in as an administrator and click on JIRA ADMINISTRATION > Manage apps in the banner. Then, locate the OSLC Connect section and click on Tracked Resource Set.

As stated in the parent topic, the Tracked Resource Sets (TRS) specification allows an application to expose a set of resources to external clients. Depending on its nature/domain, these resources are grouped to be exposed in different TRS feeds. In other words, a TRS feed is a TRS implementation (service) that exposes certain kinds of resources; this way, remote clients can then subscribe to it to be informed about these resources and their changes whenever they fetch the service.

OSLC Connect for Jira provides two TRS feeds to support Collaboration Links in a Global Configuration environment and to support reporting on IBM Jazz Reporting Service and/or IBM Engineering Lifecycle Optimization - Engineering Insights (ENI):

TRS Feed Name Required to Support Exposed Resources
OSLC Connect for Jira CM Resources (TRS 2.0)
  • Collaboration Links in a Global Configuration environment.
  • Reporting on IBM Jazz Reporting Service and/or ENI.
  • Issue
    • Key
    • Summary
    • Description
    • Status
    • Issue Type
    • Priority
    • Resolution
    • Created date
    • Updated date
    • Due date
    • Resolution date
    • Time Spent
    • Reporter
    • Assignee
    • Creator
    • Labels
    • Components
    • Environment
    • Affects Version/s
    • Fix Version/s
    • Original Estimate
    • Remaining Estimate
    • Collaboration Links
  • Version
    • Id (internal)
    • Name
OSLC Connect for Jira Process Resources (TRS 2.0)
  • Reporting on IBM Jazz Reporting Service and/or ENI.
  • Project
    • Id (internal)
    • Name
    • Description
  • User
    • Username
    • Full name
    • Email
Exposing additional properties for Issue Resources
If for any reason, reporting especially, additional (custom) fields are required to be exposed in the TRS feed, please refer to the Configuring Issue Shapes topic.

Regarding what specific issues/projects will be exposed it's a matter of access rights and what projects have been associated with external applications. The first condition for a project to be exposed is to have at least one OSLC association to an external application. This is a configuration done at a project specific level and it determines what Collaboration Links types can be created from Jira. If the Jira project administrator has not configured any association yet, this project will not be exposed to external data sources. The second condition is that the TRS Functional user must be assigned and have the "Browse Projects" permission granted on it. This is a configuration done at server level and it's a way to prevent some associated projects be exposed to external data sources. If the Jira server administrator does not grant this permission (or revokes it), external data source(s) may show warning messages about not being able to get/fetch some resources. It is worth to say that not all exposed information will be visible to all external data source users (e.g. ELM users). External applications have their own means to grant (or deny) access rights to their users. In the case of LQE, you can check the Configuring LQE Permissions for Jira Projects topic for details.

Information fetched by external data sources is copied and maintained by them. External data sources normally feed other tools with this data (reports for example) and to prevent performance hits with the information source, it is preferable they have their own copy. Now you may be wondering, if they work with a copy, what happens when the original information changes? For this scenario, external data sources need to constantly check if source information has changed. Default refresh setting on LQE/LDX is one minute for example. Every minute they ask to the corresponding TRS feed what resources have changed and only that resources are retrieved again to keep their copy updated. This means a TRS feed background implementation is a set of resource events, it tracks what resources have been changed, created or deleted since a moment in time.

The very first time OSLC Connect for Jira is installed, both TRS feeds are empty, and it's only until a consumer's first request arrives that they got ready (built automatically) to provide their information to their clients. From that moment in time, it is expected that both, the TRS feeds and their clients be synchronized with the resources (and their events) they are tracking. However, and although unlikely, it might happen from time to time, that a client gets de-synchronized from its feed [1], in which case a manual rebuild may be required [2].

To rebuild a TRS feed:

  1. Locate the TRS Feeds section and hover the one you want to rebuild.
  2. Click on the rebuild link that appears in the Action column.
  3. Confirm this action by pressing the OK button in the opened dialog.

Rebuilding a feed should be only performed when it is really necessary: either because a client got de-synchronized or other problem occurred. Doing it without a good reason will just cause all remote data sources have to re-index to be synchronized again. Be also aware that changing the TRS Functional user requires to rebuild both feeds.

Once a TRS feed is built, you can know how many resources are exposed, but just the most representative one: in the case of OSLC Connect for Jira CM Resources (TRS 2.0), you can know how many issues are being exposed and in the case of OSLC Connect for Jira Process Resources (TRS 2.0), you can know how many projects are exposed. This is done by inspecting the statistics column of the corresponding feed. In the latter case, you can even know which projects are those by clicking in corresponding link.