A data source is a TRS (Tracked Resource Set) feed provided by an external application. This feed reports, in real time, any additions, updates, or deletions of resources within that external application. When such a change occurs, SECollab (or any client application) can access and read the content of the affected resources. For more information about TRS feeds, refer to the Configuring Consumers for TRS.
Reading the content of resources from external applications enables, within the context of a global configuration, the discovery of back (or "incoming") links. A SECollab resource displays its back links if the declared data sources expose:
To read a TRS feed from an external application, a friend link with that application must first be established.
In general, TRS feeds are declared by application root services. If this is the case, and the “Data source declared by friend” option is selected, they will automatically appear in the “Data Source” field. Otherwise, the TRS feed URL can be entered manually by selecting “Undeclared friend data source”.
A data source can only be added if the TRS feed is accessible to SECollab. A functional user must be assigned to the SECollab consumer within the application that exposes the TRS feed.
After a data source is added, it must be fully read before it can process live event updates. This process is called indexing. It can be postponed by deselecting the option “Perform initial indexing after addition” when adding the data source.
Reindexing may be necessary if indexing was previously completed but the TRS feed has been rebuilt, for example, due to corruption. The indexing or reindexing action is available for each data source.
Once indexing (or reindexing) has successfully completed, the data source is considered active. New events are detected periodically according to the “Read frequency” setting.
Reading resources from the TRS feed may occasionally fail, for instance, due to a brief network issue. In such cases, the resource is marked as skipped, and the data source status column reports it to the administrator. The administrator can then initiate recovery of the skipped resources. During this recovery process, regular reading operations are suspended. If the resources remain inaccessible after recovery, they continue to be marked as skipped.
Deactivating a data source interrupts any ongoing operation. No operations are executed while the data source remains deactivated. Reactivation is possible at any time. If the initial indexing was not yet completed, it is automatically triggered upon reactivation. Otherwise, the data source simply becomes active again.
When a data source is deleted, its graph of read resources is cleared. The duration of this operation depends on the number of resources that were read. During deletion, no operations are allowed on the affected data source.
If an ongoing operation fails for the first time since the last successful read, it is very likely that the TRS feed could not be reached. The data source remains active and attempts to access the TRS feed again after 60 seconds. The error can be viewed via a link displayed in the data source’s status.
After several consecutive failures, the data source deactivates (pauses) and is marked as “Failed.” Between each retry, the waiting time is respected in case the TRS feed becomes accessible again. This waiting time doubles before each new attempt following an error. The number of retries allowed is defined by the “Retry attempts if data source is temporarily unavailable” parameter. A failed data source can be reindexed or simply reactivated.
The following parameters are defined through environment variables and apply to all data sources.
| Name | Description | Variable | Recommended default value |
| Reading frequency (seconds) | Minimum duration between two successive reads of the latest events for the same active data source. | clm.trs.client.refreshRate | 60 |
| Execution units for artifact extraction during data source addition or reindexing | Indexing or reindexing certain TRS feeds can take time. Increasing the units (threads) speeds up the process. | clm.trs.client.threadsToFetchArtifactsOnAddOrReindex | 2 |
| Execution units for artifact extraction from change logs | Some TRS feeds may emit a large number of events. Increasing the number of units (threads) accelerates event processing and therefore the reading of affected resources. | clm.trs.client.threadsToFetchArtifactsOnProcessingChangeLogs | 2 |
| Continue processing change logs if a resources is skipped | An error on the data source will be reported if even a single resource is skipped. | clm.trs.client.continueChangeLogsProcessingIfSkippedResources | true |
| Retry attempts if data source is temporarily unavailable | A waiting period is observed between each attempt, which doubles after every failure. | clm.trs.client.numberOfRetriesIfDataSourceIsTemporarilyUnavailable | 6 |