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" />
|