Validation webservice fails on attribute mapping in multi-site deployment

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.

system 2

I’ll provide a comprehensive solution addressing all three focus areas:

1. Custom Attribute Registration First, verify and fix your attribute registration. Custom attributes in multi-site deployments must have proper visibility:

AttributeType attrType = AttributeType.toAttributeType("CustomMaterial");
Site[] visibleSites = attrType.getVisibleSites();
// Ensure all required sites are included

If visibility is restricted, update it through Type and Attribute Management or programmatically to include all sites where validation will occur.

2. Site Context Propagation The critical issue is ensuring site context flows from the webservice call to the validation logic. Modify your webservice client to include site context in the security header:

<SecurityContext>
  <Site>EU_SITE</Site>
  <User>integration_user</User>
</SecurityContext>

In your validation service implementation, retrieve and set the site context before attribute validation:

String siteId = getSecurityContext().getSite();
SessionHelper.manager.setSite(siteId);
// Now perform validation

3. Webservice Payload Structure Ensure your payload structure aligns with ENOVIA’s multi-site expectations. The site identifier in the payload should match ENOVIA’s internal site naming. Create a mapping configuration if external systems use different site identifiers:

// Site mapping utility
String enoviaSite = SiteMapper.mapExternalToInternal("EU_SITE");

Complete Solution Approach:

  1. Update attribute registration to ‘All Sites’ visibility or create site-specific attribute sets
  2. Modify webservice client to pass site context in security header
  3. Update validation service to extract and apply site context before attribute lookups
  4. Implement site identifier mapping if external and internal naming differs
  5. Add logging to track site context throughout the validation flow

Test thoroughly across all sites. The validation should now correctly resolve custom attributes within each site’s context. If you still encounter issues, verify that the integration user has appropriate access rights in each site’s security configuration.

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 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.

8

Adding to the previous comment - we had exactly this issue last year. The webservice payload structure needs to align with how ENOVIA’s attribute framework resolves site-specific configurations. Make sure your attribute definitions include site visibility settings and that your validation logic explicitly queries attributes with site context. We ended up creating a site context resolver utility that maps incoming site identifiers to ENOVIA’s internal site representation before attribute validation.

9

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.

10

Update: Following the suggestions, I discovered our custom attributes were registered with site restrictions we weren’t aware of. Checking the visibility settings revealed the issue.