Avoiding Test Vault Pitfalls in SmarTeam

With any enterprise system like SmarTeam, being able to create and maintain a test or development environment is essential. It is only prudent to test system configuration changes in a “sandbox” prior to risking production system downtime and the ire of angry users. 

To successfully duplicate a SmarTeam environment, administrators need to have a good understanding of the system’s architecture and components. An incorrectly configured test environment can be a dangerous thing. 

The components required for environment duplication include the database (metadata), the vaults (files), the contents of the scripts and icons directories, the NLS XML files and the configuration XML files.

After acquiring and duplicating all of these items, there are additional critical steps to perform. In particular, there are some environment-specific settings that, if left unchanged, could cause users in the test system to modify or delete production data. A few of these settings are specific to individual SmarTeam implementations—such as directories or file locations specified in a customization—but there are other settings that are fairly universal. 



One of the most common pitfalls related to SmarTeam environment duplication is failure to reconfigure the SmarTeam vaults. If the configuration of the vaults is left unchanged, system administrators will frequently incorrectly assume that the environment has been duplicated and everything is operating properly.

The reason for this is that the test database is a copy of the production database, and the production database points to the production vault locations. Without making the required modifications, the test database will continue to point to the production vaults. 

The impact of this may not be immediately obvious, but consider the scenario of deleting an object and its file in the test environment. Certainly the object in the test system would be deleted, but so too would the vaulted file, only the file would be deleted from the production vaults.

The trickiest part of this problem is that there is no good trail to follow to determine where the mistakes were made so that you might attempt to repair them. The deleted object in the test system no longer exists, and the matching object in the production system is totally unaware that its file is missing so there is no indication of a problem until a production user attempts to access the file of an object that has fallen victim to this unfortunate situation. 



The procedure for avoiding this common pitfall is not overly complex but easy for new administrators to overlook. To properly configure test vaults, once the vault folder structure and contents are copied, the administrator needs to point the test database to the new vaults using the Vault Server Setup utility. If a new set of vaults was needed in this process, a further step to update file-managed records in the database may be required, however, this can be accomplished through a series of basic SQL statements run through the database management utility. 



To learn more about this process, and about test systems and disaster recovery in general, consider attending our Environment Duplication & Recovery course (ED&R).

Tags: disaster recovery, duplication, ENOVIA SmarTeam, PDM, SmarTeam, test systems, test vaults, testing, XML