Importing product content

Administrators can import product data from other tools into Rational® Engineering Lifecycle Manager if the imported data is described using the Resource Description Framework (RDF) format.

You can migrate data from other tools into Rational Engineering Lifecycle Manager by importing data as products. The user who imports the data is associated with the new product, rather than the user who originally created the data. Similarly, creation, modification, and audit history dates and times are based on when the import created or updated the product

Import product trees from data files in the RDF format by using one of these serialization formats: RDF/XML, N-3, N-Triple, Turtle, or JSON. The last two formats are simple enough to construct by using a text editor.

Identifiers and dcterms:identifier

Product definition resources have a unique identifier that never changes. The identifier supports reusing products from a previous import without creating new instances of them. When a product is created from imported data, the user-specified identifier is stored as its dcterms:identifier value. The import process queries for and finds a product that was created by a previous import that matches the identifier in the import data for that product.

Important: Identifiers starting with the prefix relm_ are reserved. Do not use them when creating your own import data.

Product identification

A product tree consists of one or more nodes that are organized as parents and child products. Each node represents a product version. A product version represents the state of a product at some time. As a product changes, new versions might be created. The product versions form a history of that product.

Each product version has a unique identifier. Identifiers must be long enough to avoid accidental collisions. For example, a Java™ application that produces the import data might use UUID.randomUUID().toString() to generate unique identifiers. The product definition import treats identifiers as opaque strings, so you can choose any values within journaled file system (JFS) length restrictions.

Note: By default, JFS indexing excludes strings that are longer than approximately 1023 characters. Strings of less than 200 characters are usually allowed. You can change string length limits that are eligible for indexing. The property to change is Maximum RDF literal size. The property is located on the JTS server admin page, on the Advanced Properties page, in the com.ibm.team.jfs.indexing.service.internal.HttpIndexingService section.

All of the versions of a specific project are associated with one concept identifier. All product versions that have the same concept identifier are versions of the same product concept resource. If the tool you are importing from has a real concept resource, use it to provide the concept identifier; otherwise, create a concept identifier to be shared across the versions of that product.

Predecessor identifiers

A product version can specify a predecessor identifier. For example, consider the following three product versions.
Table 1. Example of predecessor identifiers
Product identifier Concept identifier Title Predecessor identifier
Abc1234 xyz9876 First version  
Def3456 xyz9876 Second version abc1234
Ghi6789 xyz9876 Third version def3456
The predecessor identifiers form a history sequence of First version, Second version, and Third version. These are versions of the same product, so all three versions must use the same concept identifier. Each product must be defined with the following information:
  • Title
  • Product identifier
  • Concept identifier

About product definition resources

Product versions can have user-defined properties that have a name (used as a display label) and a single value. For example, a product might have a property named color with the value red.

Product versions might have zero, one, or more links. A link is a reference to an external artifact in the form of a URI. For example, a product might link to work items, change requests, requirements, model elements, and test cases.

Product versions can optionally have dimensions and dimensions values. Dimensions describe variants of a product. For example, different product variants might represent geographic locations for a market for the product. A product might use a dimension named geo. A product version might use geo=US for the North American market, and a different version might use geo=EUfor the European market.

Branches for product variants

The Rational Engineering Lifecycle Manager definition of a product uses branches to express variants. Different product versions that have the same collection of dimensions and dimension names are imported as different versions along the same branch. Rational Engineering Lifecycle Manager uses the business logic that all versions along a branch are sequential versions. Parallel versions are only permitted when the parallels are on different branches. Therefore, import takes any predecessor globally unique identifier (GUID) as a hint to create an appropriate history. However, if the import data tries to violate the parallel versions rule, the resulting history along a particular branch is sequential.

A product version can specify zero, one, or more, child identifiers. For example, consider the following product versions.
Table 2. Example of child identifiers
Product identifier Title Child identifiers
abcd123 Car bcde234, defg456
bcde234 Body cdef345, cdef345, cdef345, cdef345
cdef345 Wheel  
defg456 Engine  
Table 2 represents the following product hierarchy.
Image showing the hierarchy of the parent and child products

Feedback