Does Rally provide a data dictionary with table layouts, data types, and relationships to other tables?
Because Rally does not provide direct database access and only provides access via its API, Rally does not publish a traditional data dictionary but instead provides an object model which can be used to piece together the information, however, it takes some parsing to understand what we are doing with the object model. The object model can be found here: https://rally1.rallydev.com/slm/doc/webservice/objectModel.sp
To determine field definitions on a per-object basis, we have extrapolated the fields from the schema and provided them in the attached HTML file. The field definitions are laid out as shown in the screen snippet below:
If you need this run for your own subscription for custom fields, you can find the schema conversion script here: https://github.com/davidledeaux/PublishSchema. This script is provided without any support.
Our object model follows an inheritance model, much like with object-oriented programming. At upper levels, we define high-level objects that contain attributes that will be common to all descendant objects. Attached to this article is a flowchart to assist with the visualization of inheritance. So, for example, at the top is PersistableObject. While you will never directly work with the PersistableObject type, its attributes are common to all sub-objects. Every object in Rally, regardless of whether it is a defect, an objective, or a user, maintains a handful of values such as when it was created, its unique IDs, and what version of the object we have stored in our database. In the object model, you can see these represented here:
Looking at the PDF, you can see that because PersistableObject is at the very topmost level of the object model, its attributes are inherited by all descendant objects such as in this Tag object:
It is important to recognize that when working with the API you won't be working with many of these upper-level objects. For example, you will never interface directly with the PeristableObject level. These types of objects are abstract types and are represented with a dashed outline in the PDF. In most cases, you will be more interested in working with the solid outlined objects as those represent an end piece of data that forms a complete picture of all attribute types and their values and these would represent individual tables in a database. The biggest exception to this is Artifact while allows attributes to "bubble up" from descendants, however this is more for ease of use in apps such as the Custom List, or the Work Views page where we need to support multiple work item types from a single interface.