ENOVIA VPM V5 Connection (E5M) PE

 

General Issues

Managing export data inconsistencies
  • In some cases, if a user is modifying the ENOVIA product structure while ProductDataGen is being executed, the resulting xml can contain some inconsistencies (i.e., bad links.  The default behavior is to allow ProductDataGen to continue the export, and manage these inconsistencies on the import. 

    However, it is also possible to enforce a stricter behavior by ProductDataGen to force the export process to exit when these inconsistencies occur.  This behavior can be enabled by setting the following environment variable in the environment where ProductDataGen is executed:

    ENOVIA_LCAIPD_FORCE_EXIT=TRUE
  • In the case that bad links do exist in an EH-MH export xml, the default behavior is for the lcaloader to 'delete' these links in the Manufacturing Hub.
    An alternate behavior is possible where the bad links will be identified in the pprloader.log, but not deleted in the Manufacturing Hub.  With this new behavior, if a 'bad link' is identified in the xml, then the corresponding link in the M-Hub will be ignored ( i.e., not deleted, not updated ).
    To enable this behavior, the following registry setting must be defined:

    [HKEY_CURRENT_USER\Software\Delmia\ergoplan\pprloader\VPM]
    "ignorebadlinks"="

 

Instance export unique file naming
  • ProductDataGen instance export by default uses the following naming convention:

    <Instance ID>_<Instance modified date and time>.xml

    This is a problem when exporting instances that have identical attributes.  For example a child of an assembly that has been multi-instanced.  All of the matching instances will be exported, but the resultant xml files will overwrite each other due to the non-unique naming.  The naming convention can be made unique by setting the following environment variable in the environment where ProductDataGen is executed:

    ENOVIA_LCAIPD_NEW_MULTI_INSTANCE=TRUE

    The naming convention with this setting will be:

    <Instance ID>_<InstanceUUID>_<Instance modified date and time>.xml
Effectivity import filtering
  • There is a ProductDataGen export configuration flag, "filter-on-effectivity", that will identify in the export xml whether a component has a null, or unresolved effectivity.  This allows the user to define an import filter to avoid importing null or unresolved effectivities.  In some cases, a component may be identified incorrectly as 'unresolved' ( i.e., the child of an unconfigured parent with an effectivity ).

    To ensure correct "filter-on-effectivity" behavior, the following environment variable must be defined in the environment where ProductDataGen is executed:

    COMPUTED_EFF_STATUS=1
Block Mode
  • 2 issues were introduced with block mode enhancement in R19:
    1. For very broad structures ( greater than 40000 root links ), the buffer could be exceeded causing ProductDataGen to fail.
    2. Effectivities were computed twice, once during the retrieval of the root links, and again during the traversal of blocks.  This issue caused poor export runtime for very broad structures.
    Both of these issues are resolved since R19SP5.
  • In some cases, it is not necessary to use the split processing of block mode (small prcs for example ).  For these cases there is a new attribute that can be defined in the global properties section of the export configuration xml:

    <block-operation enabled="yes" />

Open Issues

None

 

Documentation

None