The Enterprise PDM Administration tool contains the vault configuration (users/groups, data cards, templates, workflows, etc.). It is advisable to have multiple vaults to allow for separate testing, training, or development environments. This allows the EPDM administrator the ability to change configuration without impacting users working in the live environment. With this approach, changes to custom property mappings, automatic folder and file creation templates, implementation of release and change workflow processes, and permissions (as examples) can be made in isolation. These changes can then be tested and iterations performed as required until the configuration is as desired. Then, these changes can be migrated back into the production environment.
The first step in this process is exporting vault configuration to set up the separate testing, training, or development environment.
Since EPDM is configured with a SQL Server database, one approach is to restore a backup copy of the production environment into a separate vault. Then if needed, the physical vault files themselves can also be copied over. The result would be an exact copy of the production environment. This is very valuable if you need the full environment copied, but often is not needed when you are looking to make specific configuration changes. Also the database restore process often requires IT involvement.
The process of exporting vault configuration can be performed by the EPDM administrator. Let’s take a look at an example.
Here we have the EPDM Administration tool showing a ProductionVault and a TestVault. We would like to export some or all of the configuration data from Production to Test. Then we can make some changes and eventually re-import the changes into Production once they are tested successfully.
If we right-click on ProductionVault, one of the options is to Export. The result is the creation of an export file containing all the vault configuration. In this example, we have contracted the file types and variables for display purposes
This file can be saved locally as a .cex file (Conisio export file). These .cex files can be read by any EPDM client.
Another option would be to right-click on specific configuration and create more limited export files. In the following example, this is done for Workflows.
Notice that any dependencies are also exported, in this case the groups having workflow permissions, revision schemes used in workflow states, any variables being changed through workflow transitions, along with the workflow itself.
Now we’re ready to update the Test environment. There are a couple of options to import the .cex files that were generated from the Production environment. The most direct (and quickest) way is to simply right-click on the target vault (in this case TestVault) and select Import. Then select the appropriate .cex file to import.
Let’s do this with the ProductionWorkflow.cex we just created. Expanding TestVault we see that there currently is one workflow (Default Workflow). Click on Import and select ProductionWorkflow.cex, then click Open.
We now get a confirmation:
After clicking OK, expand the TestVault Workflows to see that both the original Default Workflow and newly imported CAPVault Workflow are there.
Finally, let’s say we now want to import some but not all the configuration data from the Production environment into the Test Environment. What is the easiest way to do this working from the full export file we created earlier?
If we follow the same import process substituting ProductionVault.cex, we would likely get some messages about replacing already configured data and also get a second copy of the CAPVault Workflow imported. A cleaner and more flexible approach is to open the .cex file instead of importing it, and then dragging and dropping selected configuration data into the target vault (TestVault in this case).
So now instead of right-clicking on TestVault and selecting Import, we simply go to File >> Open, and select ProductionVault.cex.
Click Open and we see the .cex file and all its configuration data.
We can now select the specific configuration that we want to import. In this example we choose to import the Engineering Documents category, CAPVault Folder Card, and Quick Search Search Card. These currently do not exist in TestVault.
We now click on each configuration element we want to import and drag/drop it into the target vault (TestVault). Do this for each one and the result is the migration of the configuration data into the Test environment.
Now we can safely make changes in TestVault without impacting users in ProductionVault.