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 |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| All metadata minus reports |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Layout |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Report |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| User |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Text Messages |
|
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.