About Customizing the Import Process

The DesignSync and Defect Management and Collaboration apps allow you to customize your installation to extend the information that is exported from DesignSync module versions and imported to ENOVIA product revisions.

The customization process includes defining TCL code for DesignSync to export the required content (see API for Providing Additional Information from DesignSync), and JPO:methods (see ENOVIA API for Pre-processing and Post-processing JPOs) for Defect Management and Collaboration to process that content.

Note: You only need to use the information in this section if you intend to write custom programs to extend the process of importing module versions from DesignSync into ENOVIA product revisions.

This page discusses:

Content Passed from DesignSync

By default, DesignSync includes these details for the module version when importing module versions into product revisions:

  • Whether it is a version or a branch
  • The versions or branch numeric
  • The Derived From version
  • Any Merged From versions
  • Any tags
  • The Author of the version (the username as stored in DesignSync)
  • The checkin Comment
  • The Version creation date
  • For tags, the user that added the tag, the date the tag was added, and whether the tag is mutable

To extend this list, you need to write custom functions. The additional information is a set of name-value pairs.

Extended Information from DesignSync

You can define TCL functions to provide additional details to the ENOVIA app.

You must provide the functions as custom TCL code in packages in the custom/site/share/tcl areas. These are within a dscustom TCL package. The functions must use the exact names listed in this table:

Function NameDescription
importModuleVersionsStartExecutes setup tasks for the import. This function is executed once per operation.
importModuleVersionsProcessReturns the information for each module version. This function is run once for each module version being returned.
importModuleVersionsEndExecutes any required cleanup tasks. This function is run once at the end of the process.

See API for Providing Additional Information from DesignSync for details about these functions.

Pre-processing and Post-processing in ENOVIA

You define the pre-processing and post-processing functions to use the additional information that is passed back to ENOVIA to customize the existing or new Product Revisions. For example, an additional property passed back from the DesignSync system could be set as an attribute on the equivalent Product revision, or the "Revision" value could be modified to be something other than the dot-numeric value, or even the Type of the objects could be changed according to customer-specific criteria.

You define pre-processing and a post-processing methods to handle the additional content received from the custom TCL commands. You can name the JPO and method anything that makes sense for your installation.

JPO:methodDescription
pre-processing JPO:methodAllows additional checks or setup to be executed prior to the actual import of DesignSync module revisions.
post-processing JPO:methodAllows additional processing on the imported Product revisions.

For the methods to be called, these properties in emxSemiTeamCollab.properties must specify the required JPO:Method names:

emxSemiTeamCollab.HDM.ImportProductRevisions.PreProcess=
emxSemiTeamCollab.HDM.ImportProductRevisions.PostProcess=

See Configuring How Modules Are Imported From DesignSync for details on entering values for these properties.

This structure shows a sample sequence for a post-processing function:

  1. Extract the XML string from the arguments and pass it to the JAXB unmarshaller for parsing.
  2. Extract the HashMap of versions imported and whether the associated revisions already existed.
  3. Loop over the ModuleVersion elements from the XML using the JAXB classes.
  4. For each version, look up the numeric in the HashMap to see if it was one that was imported; if so apply special processing.