Import / Export Menu

This section of administration deals with the import and export of data and metadata with ExtraView. The available functions are:

  • Metadata export - Exports the configuration, or part of the configuration of the installation to a local file
  • Metadata import - Imports a previously exported file into an installation
  • File Import - Issue Data - Imports issue data from a CSV or TSV file
  • File Import - User Information - Imports and creates users from a CSV or TSV file
  • File Import - Data Dictionary - Imports and create new user defined fields in the data dictionary from a tab-delimited or comma-delimited file

Note: It is strongly recommend that you backup your entire database using its standard features, before you use the import facility. Importing metadata, layouts, reports and user data is irreversible, and it is possible that failures can occur during the process.

Note than exporting metadata is different from backing up your entire database. This should be performed with the tools that are provided by your database vendor, or third party tools that are specifically developed for the task.

Data within ExtraView is split into two parts, metadata and item data. Metadata is the supporting data for the application, such as information supplied as part of the product, data you supply such as the entire list of available product names, the entire list of possible status values, and the screen layouts you design. Item, or issue, data is the physical data relating to the items being tracked. This will contain the attributes of a specific issue such as its ID, its specific product name, specific status currently assigned, and all the history information relating to the issue.

There are several reasons to export and import just the metadata, within an ExtraView instance:

  • To produce a backup of all or part of the metadata in a form that can be restored. This is separate from performing a backup of the database instance itself, as the metadata is exported in XML format.
  • To transfer the metadata from a test or staging environment to a production database. Upon transfer, operations such as update or update and merge can be selected.
  • To obtain the data in a standardized format (XML) that can be used to interface to other systems.

When exporting the metadata, there is an import overall option to understand. You may check the option box titled Minimize the user information exported. Doing so serves the purpose of leaving the data associated with users undisturbed on the production server. User data such as passwords and each user’s personal options is dynamic and you most often want to leave the production version of the user information alone.

It helps, but is not essential, to have an understanding of the ExtraView schema when using the metadata transfer utility. When you export information, all the tables that are associated with the family are also exported, including subordinate information. When you import information, there are three modes, as follows:

  • Update – modify existing objects of same name and type from the export image
  • Update / Merge – this is a combination of update plus a merging of new data items in the export file.
  • Localization Merge – import only the messages for all languages, which were exported as a family

Note: For most common import purposes, you should use the Update / Merge facility, as this is most likely to produce the desired results of adding new data, whilst updating existing data.

When an object is loaded from the saved disk image to the instance, all necessary referential integrity and uniqueness constraints are maintained. Maintaining uniqueness constraints necessarily involves incrementing or modifying the sequence values for specific objects in the instance appropriately. Maintaining referential integrity constraints implies that multiple tables may be updated, because rows on which the new values depend must be added, if they are not already there.

When deleting objects in the target database, all referential integrity constraints are maintained, using a cascade deletion policy. That is, if an import results in the removal of an object, the metadata object references to that object must be removed as well. This strategy is designed to ensure information is unlikely to be lost, since dependent objects are likely be restored during the import.

When adding new metadata, additional rules may be imposed on the data relationships for user problem data. In these cases, all existing issue data is checked against the new relationships.

When you move the business rules from one instance to another as part of the export / import process, the rules are never merged with the existing rules in the target database. The old rules are always overwritten with the new rules.

Export Family Information

Family Tables exported
All Metadata
ALLOWED_FUNCTIONS LAYOUT_TYPE
ALLOWED_VALUE_TYPE MODULE
ALLOWED_VALUES MODULE_TYPE
APPLICATION_DEFAULT OUTPUT_TYPE
AREA PRIORITY
CATEGORY PRIVACY_GROUP
CHART_TYPE PRIVACY_GROUP_USER
CUSTOMER PRODUCT
DATA_DICTIONARY PRODUCT_LINE
ESCALATION_RULE PRODUCT_PRODUCT_LINE
ESCALATION_RULE_ACTION PRODUCT_RELEASE
ESCALATION_RULE_ELEMENT PROJECT
ESCALATION_RULE_USER RELATIONSHIP_GROUP
EV_FILE_IMPORT RESOLUTION
EV_HIERARCHY SECURITY_GROUP
EV_HIERARCHY_LEVEL SECURITY_GROUP_USER
EV_LIST_MAP SECURITY_MODULE
EV_RULE_TEXT SECURITY_PERMISSION
EV_TEMPLATE SECURITY_USER
EV_TEXT_LOOKUP SEVERITY_LEVEL
INTEREST_LIST START_PAGE
INTEREST_LIST_ELEMENT STATUS
INTEREST_LIST_USER STATUS_RULE
ITEM_GROUP_TYPE TITLE_MAP
ITEM_TYPE UDF
LAYOUT UDF_LIST
LAYOUT_ELEMENT  
LAYOUT_ELEMENT_ATTRIBUTE  
All metadata minus reports
ALLOWED_FUNCTIONS LAYOUT_TYPE
ALLOWED_VALUE_TYPE MODULE
ALLOWED_VALUES MODULE_TYPE
APPLICATION_DEFAULT OUTPUT_TYPE
AREA PRIORITY
CATEGORY PRIVACY_GROUP
CHART_TYPE PRIVACY_GROUP_USER
CUSTOMER PRODUCT
DATA_DICTIONARY PRODUCT_LINE
ESCALATION_RULE PRODUCT_PRODUCT_LINE
ESCALATION_RULE_ACTION PRODUCT_RELEASE
ESCALATION_RULE_ELEMENT PROJECT
ESCALATION_RULE_USER RELATIONSHIP_GROUP
EV_FILE_IMPORT RESOLUTION
EV_HIERARCHY SECURITY_GROUP
EV_HIERARCHY_LEVEL SECURITY_GROUP_USER
EV_LIST_MAP SECURITY_MODULE
EV_RULE_TEXT SECURITY_PERMISSION
EV_TEMPLATE SECURITY_USER
EV_TEXT_LOOKUP SEVERITY_LEVEL
INTEREST_LIST START_PAGE
INTEREST_LIST_ELEMENT STATUS
INTEREST_LIST_USER STATUS_RULE
ITEM_GROUP_TYPE TITLE_MAP
ITEM_TYPE UDF
LAYOUT UDF_LIST
LAYOUT_ELEMENT  
LAYOUT_ELEMENT_ATTRIBUTE  
Layout
AREA PROJECT
DATA_DICTIONARY SECURITY_GROUP
LAYOUT SECURITY_MODULE
LAYOUT_ELEMENT SECURITY_PERMISSION
LAYOUT_ELEMENT_ATTRIBUTE TITLE_MAP
LAYOUT_TYPE UDF
MODULE UDF_LIST
PRODUCT  
Report
AREA PROJECT
CALCULATED_FIELD RELATIONSHIP_GROUP
CATEGORY REPORT
CHART REPORT_ATTRIBUTE
CHART_PROPERTY_GROUP REPORT_GROUP
CHART_TYPE REPORT_LAYOUT
DATA_DICTIONARY REPORT_SECURITY_GROUP
EV_HIERARCHY RESOLUTION
EV_HIERARCHY_LEVEL SECURITY_GROUP
FILTER SECURITY_MODULE
FILTER_CRITERIA SECURITY_PERMISSION
FILTER_GROUP SECURITY_USER
ITEM_TYPE SEVERITY_LEVEL
LAYOUT SORT_ORDER
LAYOUT_ELEMENT SORT_ORDER_FIELD
LAYOUT_ELEMENT_ATTRIBUTE START_PAGE
LAYOUT_TYPE STATUS
MODULE SUBREPORT
OUTPUT_TYPE TITLE_MAP
PRIORITY UDF
PRIVACY_GROUP UDF_LIST
PRODUCT  
User
AREA START_PAGE
PROJECT TITLE_MAP
SECURITY_USER  
Text Messages
EV_TEXT_LOOKUP TITLE_MAP

List Value Migration

The default export and import of list fields and their values moves all values in all lists from the source to the target instances.  There are some circumstances where you do not want to migrate any or all of the list values within fields.  For example, if you are creating field list values through the use of the OBJECT business rule, this might be test data and not data that you want to replicate in the target system.  To accommodate this requirement, two features are available.

First you may use the DO_NOT_MIGRATE=true parameter within an OBJECT rule.  This flags the values created for special treatment with the XML Export / Import process.  Second, the Manage List Values utility accessible through the administration utility, the data dictionary and the design center allows you to set any list value with a flag so that it will not be migrated.

Because values being migrated may have dependencies, such as being used in interest lists and escalations, the flagged items are first migrated to the target system, and are then deleted, with the deletion also removing the dependencies.