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.
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.
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.
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.
| Product identifier | Concept identifier | Title | Predecessor identifier |
|---|---|---|---|
| Abc1234 | xyz9876 | First version | |
| Def3456 | xyz9876 | Second version | abc1234 |
| Ghi6789 | xyz9876 | Third version | def3456 |
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.
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.
| Product identifier | Title | Child identifiers |
|---|---|---|
| abcd123 | Car | bcde234, defg456 |
| bcde234 | Body | cdef345, cdef345, cdef345, cdef345 |
| cdef345 | Wheel | |
| defg456 | Engine |
