Validation webservice fails on attribute mapping in multi-site deployment with custom integration

PLM ENOVIA
, , , , , , , ,
1

We’re running ENOVIA R2020x in a multi-site deployment and encountering validation failures when external systems invoke our custom validation webservice. The issue appears related to custom attribute registration and site context propagation.

The webservice validates part attributes before creation, but we’re getting inconsistent results across sites:

<ValidationRequest>
  <Part site="EU_SITE">
    <Attribute name="CustomMaterial" value="STEEL_316L"/>
  </Part>
</ValidationRequest>

Error: “Attribute ‘CustomMaterial’ not registered for site context EU_SITE”

The attribute is registered in the primary site but validation fails when the payload includes site-specific context. Has anyone dealt with custom attribute registration across multiple sites in webservice integrations? The webservice payload structure seems correct but site propagation isn’t working as expected.

2

Check your type and attribute registration carefully. In R2020x, custom attributes on business objects need proper site propagation rules defined. Run this to verify: Use the Type and Attribute Management utility to check if CustomMaterial has ‘All Sites’ visibility or is restricted to specific sites. If it’s site-restricted, you’ll need to either expand its visibility or implement site-specific attribute sets in your validation service.

3

I’ve seen this before. The attribute registration is likely site-specific in your setup. Check if CustomMaterial is registered globally or only for specific organizations. You might need to verify the attribute’s organization context matches the site context in your validation logic.

4

Thanks for the quick response. I checked the attribute registration and it’s set to the root organization. The webservice is hosted on the primary site server. Could the issue be related to how the site context is being passed in the SOAP header versus the payload body? We’re using a custom validation service that extends the standard ENOVIA webservice framework.

5

Your site context propagation is the problem here. In multi-site deployments, ENOVIA webservices need explicit site context in the security header, not just in the payload. The validation framework checks attributes against the session’s site context, which defaults to the hosting server’s site if not explicitly set. You need to ensure your webservice client sets the site context in the authentication header before making the validation call. Also verify that your custom validation service properly inherits the site context from the session rather than hardcoding it.