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.
The specific local exposed artifacts types (and their properties) depend on each feed (and are listed below) but in general, the exposed artifacts are those of the OSLC-enabled projects to which the TRS Functional user has access to. If the TRS Functional user has no access to some OSLC-enabled projects, these projects' artifacts won't be able to be fetched by the TRS client and they may be reported as skipped 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 may have their own means to grant (or deny) access rights to their users.
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 whether 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.
On a fresh install, the ${local-app} TRS feeds are empty until they are built either manually by a server administrator or automatically on the next run of the TRS Repair Job if it is not disabled [1]. Consuming applications like LQE/LDX can still register the feeds even if they are not built. A service-not-available error message will be reported by them until the feeds are built but they will automatically recover from that when it occurs and start indexing the resources. From that moment in time, it is expected that both the TRS feeds and their clients are synchronized with the resources (and their events) they are tracking.
In general, TRS feeds are kept up-to-date without any manual intervention from an administrator.
There are some occasions where repairing feeds is necessary, as they are no longer accurate, due to important changes
in the application, such as:
Repairing a TRS feed analyzes and adjusts the feed's content to be consistent with the current functional user's permissions and the other changes mentioned above. Repairing doesn't break the TRS feed for consuming applications. Applications will automatically handle the latest content on the subsequent TRS state request.
As stated before, there is a configurable TRS Repair Job to automatically repair all the
${local-app} feeds daily at 10 p.m. If not disabled,
this scheduled job will find all the changes that need to be incorporated on the feeds and will add them without requiring
additional input from the server administrator. Repair results can be tracked on the Audit Log with the messages
TRS repair triggered and TRS repair completed. To change the schedule time of the repairing job,
locate the text Repairing all TRS feeds executes in the background every day at followed by the current
scheduled time below the feeds table and click on the Edit... link. In the opened dialog, choose the desired time
and click the OK button. It is recommended to schedule the repairing job outside of business hours to avoid
the network traffic this may generate when there are a lot of changes. Unless requested by a support team member, or due to
really needed maintenance activity, the repairing job should never be disabled for long periods.
If any of the important changes mentioned above can't wait for the next day to get incorporated on the feed automatically, server administrators can always manually repair or validate a given feed (validate is the process of finding all the changes but without adding them to the feed).
To repair a TRS feed:
TRS Feeds section and click the three-dots button in the Actions column of the one you want to validate/repair.Validate... option.All.Validate button.
Be aware this process can take some time to complete, depending on the number of resources the project/feed has. This number is
enclosed in parenthesis next to each project in the selecting combo. Once the selection is made and the Validate button
is pressed, the dialog is closed and the progress can be monitored in the feeds table. When completed, the validation results
will be displayed in the table and clicking on them (or in the Review... option in the Actions column
after clicking on the three-dots button) opens a dialog detailing the results and allowing to apply them (if there are differences found)
or discard them. If validation results are applied, the repair process completes and the dialog is closed. If they are discarded,
they are removed and the dialog is closed as well. Keep in mind that validation results are stored in the server only for 1 hour
after of which they are automatically discarded. The remaining time before this happens is displayed along with the validation
results when the validation is completed. Finally, an undergoing validation can be aborted by clicking the Abort option
in the Actions column after clicking on the three-dots button. A feed can only process a single validation at a time.
Results need to be discarded to start a new validation on the same feed.
There are very rare cases where rebuilding a TRS feed is necessary. Rebuilding a TRS feed is a significant event that involves emptying its content and then adding every accessible artifact. This process should only be undertaken in rare cases, such as data corruption, or when specifically instructed by product support.
Once the rebuild is complete, the applications consuming the TRS feed must perform a reindex. This reindexing process, particularly with a high volume of data, can be a long-running process that generates significant network traffic. It is advisable to schedule the rebuild and reindex outside of regular business hours.
To rebuild a TRS feed:
TRS Feeds section and click the three-dots button in the Actions column of the one you want to rebuild.Validate... option.rebuilding the feed link.Rebuild (Confirmation required) option in the opened dialog.Rebuild button.
Similarly to a validation, the progress can be monitored in the feeds table after the dialog is closed but no Abort option is available.
Sometimes, server administrators may want to force consuming applications to re-fetch all the resources of a project in the feed to ensure
they get the most recent data. This can be accomplished by selecting the Force Update option in the step 4 above and selecting the project
before clicking the Force Update button (no check box confirmation is required in this case). Depending on the amount of the selected project
resources, listed again in parenthesis next to each project, this may potentially generate network traffic but do not require to re-index the consuming
applications. Unlike Rebuild, a Force Update can be aborted in the same way a Validation can.
Keep in mind a single process (Validation, Rebuild, or Force Update) can be executed per feed at a time. All these processes are tracked in the Audit Log
and can be found with the corresponding message: TRS validation triggered/completed, TRS rebuild triggered/completed or
TRS force update triggered/completed.
Sometimes it may be helpful to download a feed to check what consuming applications can see. To download a feed:
TRS Feeds section and click the three-dots button in the Actions column of the one you want to download.Download option.A zip file containing the following is downloaded:
changelog folder.base folder.zstats.log file with debugging download times.
No Download option is available while rebuilding a feed.