Config management import fails due to object type and attrib

PLM ENOVIA
, , , , , , , ,
1

We’re experiencing consistent failures when importing configuration management data from our legacy system into ENOVIA R2020x. The import process runs but fails at the attribute mapping stage with schema validation errors.

The error trace shows:


Error: Attribute 'RevisionStatus' not found for type 'ConfigPart'
at ConfigImporter.validateMapping(line 234)
at ImportService.processAttributes(line 156)

We’ve verified the MQL schema shows ‘ConfigPart’ exists with different attribute names than expected. The attribute-to-type mapping seems inconsistent between our export format and ENOVIA’s schema. This is blocking our migration automation completely.

Has anyone dealt with similar object type and attribute mismatches during config imports? Need guidance on proper mapping validation approach.

system 2

I had the same configuration import failures and spent weeks debugging. Here’s what actually worked - addressing all three validation aspects systematically.

For attribute-to-type mapping validation, you need to build a comprehensive mapping dictionary first. Export your target ENOVIA schema:


print type ConfigPart select attribute dump |
print type ConfigPart select property dump

This shows ALL available attributes with their exact symbolic names. Your ‘RevisionStatus’ needs to map to ENOVIA’s actual attribute - likely ‘revision’ or ‘attribute[Status]’ depending on your configuration.

For MQL schema verification, create a validation script that runs before import:


temp query bus ConfigPart "*" "*" where "attribute[YourAttr] != ''"
print bus $1 select attribute[YourAttr] dump

This confirms the attribute exists and is accessible. Run this for EVERY attribute in your import file.

For import/export mapping consistency, the critical step is ensuring your import mapper uses the same symbolic names as the export. Create a mapping configuration file:

<attribute-map>
  <source name="RevisionStatus" type="string"/>
  <target name="attribute[Status]" type="string"/>
  <transform>direct</transform>
</attribute-map>

The transform can be ‘direct’, ‘lookup’, or ‘calculated’ depending on whether values need conversion.

Key insight: ENOVIA’s config import validates in this order: 1) Type exists, 2) Attributes exist on type, 3) Data types compatible, 4) Values within constraints. Your error at step 2 means the attribute name doesn’t match the schema. Use the MQL print commands above to get the exact names, then update your import mapping file with those exact symbolic names.

Also critical - if ConfigPart is a custom type, verify it’s properly registered in the import framework. Check wt.properties for ‘wt.load.ConfigPart’ entries. Missing registration causes the importer to skip attribute validation entirely, leading to silent failures or the errors you’re seeing.

After fixing the mapping, always do a dry-run import with validation-only mode enabled. This catches mapping issues before attempting actual data import. Your automation should include pre-import validation as a mandatory step - never skip straight to import without schema verification first.

This draft is based on general ENOVIA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen this exact issue. The problem is that ENOVIA’s configuration object types have specific attribute naming conventions that differ from custom implementations. Your ‘RevisionStatus’ attribute likely needs to map to ‘current’ or ‘policy’ depending on your schema version. Run an MQL describe on your target type first to see actual attribute names available.

ow_enov 4

Confirmed this resolves the symbolic name mismatch — running print type ConfigPart select attribute dump revealed our ‘RevisionStatus’ needed mapping to attribute[EngStatus] in our ENOVIA schema.

5

Check your import mapping file for case sensitivity issues too. ENOVIA R2020x is strict about attribute name matching. Also verify that your ConfigPart type hasn’t been customized with different symbolic names. I’d recommend exporting a sample ConfigPart from ENOVIA first, then compare the attribute structure with your source data schema. That usually reveals the mapping gaps quickly.

7

The attribute-to-type validation in R2020x config imports is particularly strict. Beyond just attribute names, you need to ensure data types match exactly - string to string, integer to integer, etc. I’ve found that creating a mapping matrix helps: source attribute name, source data type, target attribute name, target data type, transformation rule. Document every mapping explicitly before attempting the import. This prevents the cascade of errors you’re seeing.

8

Have you validated your MQL schema against the OOTB configuration model? Sometimes custom attributes get added to ConfigPart without proper registration in the import/export framework. Use ‘print bus ConfigPart * * select attribute dump’ to see all available attributes on existing objects. Compare that output with your import template. The discrepancy will show which attributes need remapping or which ones don’t exist in your target schema.

9

Your import/export mapping consistency issue is common with config management migrations. The key is understanding that ENOVIA uses symbolic names internally. When you export configuration data, it uses symbolic names, but your legacy system might use display names or custom identifiers. You need a translation layer in your import process that maps legacy attribute identifiers to ENOVIA symbolic names. Also check if your ConfigPart type inherits attributes from parent types - those inherited attributes won’t show up in direct type queries but are still required during import.