Importing data from a legacy system is often problematic, for a number of reasons. These include –
When a record is inserted into ExtraView or updated by ExtraView there are several fields which are maintained automatically, and cannot be inserted or updated via the web-based interface, the API or the CLI. However, when importing legacy data, you may need to import values from these fields. ExtraView supports this. However, the fields must be on the add screen layout, and must have write access to accommodate the import utility. This table specifies the treatment of these fields:
Data Dictionary Field Name | Treatment |
DATE_CREATED | If this exists in the import file and is mapped, the value provided will be inserted, else the current date and time will be used |
DATE_CLOSED | If this exists in the import file and is mapped, and the STATUS of the issue equals the STATUS defined in the behavior setting named STATUS_CLOSED_NAME, the value provided will be inserted, else no value will be inserted |
DATE_LAST_STATUS_CHANGE | If this exists in the import file and is mapped, the value provided will be inserted, else the current date and time will be used |
ID |
The ID field is always created by ExtraView, without exception. It is provided a sequential value when the issue is first created. When you are using the file import utility to update data, this is normally used as the key field upon which you map the record being imported to the existing issue within ExtraView.
If your installation is configured to use ALT_ID as the primary means of identifying an issue, then you can expect ExtraView to create this from records within the import file, and you will use this as the key field upon which to map issues being updated |
LAST_CHANGE_USER | If this exists in the import file and is mapped, the value provided will be inserted, else the current user ID will be used |
ORIGINATOR | If this exists in the import file and is mapped, the value provided will be inserted, else the current user ID will be used |
TIMESTAMP | This field cannot be mapped when importing data. If you want to preserve the timestamp, or an issue's last date updated, it is suggested you create a user defined field and import the data into this field. |
The import utility will only import data into a single business area and project. It is not possible to map and import data into multiple business areas and projects, or into the main item structure and the repeating record structure at the same time with the import facility. Other methods exist within ExtraView to handle complex structures; the utility described here is intended for the import of simple structures (this method handles about 80% of requirements), and it is quick and simple to use. For complex data migration purposes, consider the XML import utility or the CLI evimport function. The strategy to import data into multiple areas and projects is to segment your data by area and project in your import file, and to import each one separately.
Most of the time, the data you import will be writeable through the add screen layout that you are using. The layout selected for the import is defined by:
If you have a straightforward file to import, simply use the add screen layout you have created, and create an import file to upload that reflects its contents. However, if your administrative role does not have all the fields on the add screen and they are not all writeable, or you have a relatively complex system with multiple Business Areas and Projects, the following strategy is good to follow. This is especially true for companies needing to import data from other sophisticated tracking systems which contain a good deal of metadata about each issue:
If you have a very large volume of data to import, ExtraView supports some advanced features which allow you to import many files in parallel. These features are described here.