Blogs about Jazz

Blogs > Jazz Team Blog >

5 best practices for TRS Feeds Implementation for Reporting

Open Services for Lifecycle Collaboration (OSLC) Tracked Resource Set (TRS) protocol allows a server to expose a set of resources in a way that allows clients to discover the exact set of resources in the set, to track all additions to or removals from the set, and to track state changes to all resources in the set. The protocol is HTTP-based and follows RESTFul principles. The protocol is suitable for dealing with large sets containing a large number of resources, as well as highly active resource sets that undergo continual change. And thus is the best fit for maintaining the database of resources used for reporting.

Even though this specification is easier to implement, the key is implementing it right, otherwise, one would end up in all sorts of problems ranging from excessive exchange of data to inconsistent data between the provider of the resource set and reporting database. Lets look at the 5 best practices that one can follow as a provider of the Tracked Resource Set.

Expose just enough data

The primary database may have lot of resources with each resource having a bunch of properties, but it is not recommended to expose everything to the reporting database. Remember, the purpose here is not to duplicate the database but to maintain a database for reporting and to keep its state as close to the source database. The resource shapes (that defines what is published through the TRS document) have to be just enough for the reporting requirements. One can always change the resource shape to include newer properties such as when the reporting requirements change.

Store Changelog and Base log

Always store the Change log and the Base log locally so that it can be quickly retrieved as and when required. This also makes sure that there is no inconsistency in the response of the requests for these documents. Base log should be regenerated frequently as the newer resources are created and or deleted. This frequency should be higher for highly volatile database and may be lower for the databases which don’t see that many frequent changes. Either way it is beneficial to have a configuration to manage this frequency.

Order of the change log entry

The Order property of a change log entry defines the sequence of these entries for the consumer to sort and parse through. It can be a running number, but it is easier to manage if it is the timestamp of the change. A timestamp can be converted to a long number and this can be used as the property value. This could also help to figure out when a particular change took place.

Validate your feed

There could be issues during publishing of the TRS document or the resource documents due to various reasons ranging from a network issue to an internal server error. It is important to keep track of any such issue and flag it as soon as possible, as it could lead to inconsistent data or missing or additional data in the reporting database. Such a validation should be scheduled and monitored.

One resource or Multiple Resources

The easiest way to publish content is to wrap all related properties under a resource and publish, but this may not be the best approach. Publishing a resource with a large number of properties is not a good idea because any change to a property of this resource would need a change log entry being triggered, and the consumer would need to load the entire resource. That would mean a lot of data being transferred over the wire. On the other hand, a resource with just a couple of properties may not be a good idea either. The change log would become bigger and bigger because it has to publish a lot changes to an abundance of resources. There should be a balance, and this balance depends on factors such as the volatility of the resources and its properties. It’s important to strike a balance.

Sanjesh Raj Nair

Senior Architect, IBM Engineering Lifecycle Management