Product Documentation

Legacy Data Issues

Importing data from a legacy system is often problematic, for a number of reasons. These include –

The ID Field

• Data in legacy systems is rarely “clean”. For example, you may have been required to type in entries that become list values in ExtraView. Typing data often leads to mistakes, making it difficult to map different entries. ExtraView allows you to map more than one input value to a list value
• You may not want to carry over all users from a legacy system to ExtraView. For example, you may not want to purchase an ExtraView license for an ex-employee who was the creator of an issue in ExtraView. You can either create a user account in ExtraView and deactivate the account, or you can map the name to a different person in ExtraView
• To take advantage of all the exciting features in ExtraView, you may be changing your workflow and data items that you capture in a significant way. Not all legacy data will have value in these circumstances, but you may want to import it for historic purposes. ExtraView allows you to do this
• If you want to import data that is read-only when in the mode of updating an issue, temporarily alter the field to be read-write, import your data, then reset the field to be read-only.
• One field of particular note when importing data from a legacy system is the ID field. ExtraView licensees may want to retain the legacy number. ExtraView must use its own sequence of numbers. To facilitate this requirement, a text field named ALT_ID is defined in the ExtraView data dictionary. Map your legacy field to this ExtraView field and retain it on the layouts while you make the transition. Eventually, you may remove this field from the ExtraView layout.
  

  Other Fields with Special Treatment

  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
  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.

  Business Areas and Projects

  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.

  Read-only Fields

  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:

  • The business area defined in the import template (if you are using business areas in your installation)
  • The project defined in the import template (if you are using business areas and projects in your installation)
  • The current role of the user performing the import. Normally this is an administrative role, such as admin.

  Import Strategy

  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:

  • Create a new user role named import or similar
  • For this new user role create a new add screen layout. The speediest way of doing this is to choose the an add or edit screen layout for a role with a layout close to what you need, to then alter the user role on the edit screen for the layout to the new user role, then save the layout as the add screen for this role
  • Make sure that the fields are writeable on this new layout
  • Alter your current role to the new user role
  • Perform the import