REST endpoint returns 500 error when updating custom supplier object

PLM ENOVIA
, , , , , , , ,
1

Our supplier portal integration uses REST API to update custom supplier objects, but we’re getting 500 Internal Server errors on PUT requests. GET requests work fine and return the supplier data correctly, but any update attempt fails.

The error response:


HTTP 500 Internal Server Error
{"error": "Failed to process update request"}

We’ve extended the standard Supplier type with custom attributes for certification tracking and performance metrics. The REST endpoint is /enovia/resources/v1/suppliers/{id} and we’re sending properly formatted JSON payloads. The same data structure works when updating through the UI. This is blocking our automation where supplier performance scores need to be updated nightly based on delivery metrics. Any ideas what could cause REST updates to fail while UI updates succeed?

system 2

Perfect, the server log analysis confirmed the issue - your custom attributes aren’t registered in the REST resource schema. Let me walk through all three critical areas: REST resource mapping, API schema updates, and proper server log analysis for troubleshooting.

First, understand REST resource mapping. ENOVIA’s REST API doesn’t automatically expose all object attributes. It uses explicit resource mapping files that define which attributes are accessible through the API and how they’re serialized. These mapping files are located in <install>/Windchill/codebase/rest/config/resources/. For supplier objects, you’ll need to modify or extend the supplier resource definition.

Second, update the API schema for your custom attributes. Create or modify the supplier resource mapping XML file (supplier-resource.xml):

<Resource type="Supplier">
  <Attribute name="certificationLevel" type="string"/>
  <Attribute name="performanceScore" type="double"/>
</Resource>

This registers your custom attributes with the REST API framework. However, you also need to ensure the attributes are included in the update operation’s allowed fields. In the same resource file, locate or add the update operation definition:

<Operation name="update" method="PUT">
  <AllowedAttributes>
    <Attribute name="certificationLevel"/>
    <Attribute name="performanceScore"/>
  </AllowedAttributes>
</Operation>

Without this explicit declaration, the REST endpoint won’t accept these attributes in PUT requests even though they exist in the object model.

Third, proper server log analysis is crucial for diagnosing REST API issues. The generic 500 error masks the real problem. Enable detailed REST API logging by adding this to your log4j configuration:


log4j.logger.com.ptc.windchill.rest=DEBUG

This provides detailed traces of REST request processing, including attribute mapping failures, validation errors, and serialization issues. When analyzing logs, look for these patterns:

  • “Attribute X not found in resource schema” - Missing resource mapping
  • “Validation failed for attribute Y” - Constraint violation
  • “Permission denied for operation Z” - Authorization issue
  • “Serialization error for type T” - Data type mismatch

For your specific case, the complete solution involves several steps:

  1. Update resource mapping: Modify supplier-resource.xml to include certificationLevel and performanceScore attributes with correct data types

  2. Register custom serializers: If your custom attributes use complex data types (not simple strings/numbers), you may need custom serializers:

public class SupplierAttributeSerializer {
  public String serialize(Object value) {
    // Convert custom type to JSON-compatible format
  }
}

  1. Update API schema documentation: Regenerate the REST API schema to include your custom attributes. Run the schema generator utility: `windchill com.ptc.windchill.rest.util.SchemaGenerator

  2. Clear API cache: ENOVIA caches resource definitions, so after updating the mapping files, clear the REST API cache through the admin console or by restarting the application server

  3. Test with detailed logging: Make a test PUT request with logging enabled and verify that your custom attributes are now recognized and processed

The reason UI updates work while REST updates fail is that the UI uses ENOVIA’s internal object APIs that have full access to all attributes regardless of resource mapping. The REST API layer adds an abstraction that requires explicit attribute registration for security and schema validation purposes.

Additional considerations for your nightly automation:

  • Implement proper error handling to catch 500 errors and log the full response body
  • Use the REST API’s batch update endpoint if updating multiple suppliers to improve performance
  • Consider implementing retry logic with exponential backoff for transient failures
  • Monitor the application server’s memory and thread pool during bulk updates to avoid resource exhaustion

After implementing these changes, your supplier portal integration should successfully update certification tracking and performance metrics through the REST API. The key is ensuring that every custom attribute you want to update via REST is explicitly declared in the resource mapping files and included in the update operation’s allowed attributes list.

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

500 errors from ENOVIA REST endpoints usually indicate a server-side processing exception. Check the application server logs for detailed stack traces. The generic error message you’re getting is masking the actual problem. Look for exceptions related to object serialization or attribute validation in the logs around the timestamp of your failed PUT requests.

4

Custom attributes on extended types often aren’t mapped in the default REST resource definitions. ENOVIA’s REST API uses resource mapping files to define which attributes are exposed and how they’re serialized. If your custom certification and performance attributes aren’t in the supplier resource mapping, the API won’t know how to process them in update requests. You need to update the REST resource configuration XML to include your custom attributes.

5

I’ve seen this when custom attributes have validation rules or constraints that aren’t properly communicated through the REST API schema. The UI knows about these constraints because it loads the full object metadata, but the REST endpoint might be trying to set attribute values that violate validation rules. For example, if your performance metrics have range constraints or required field dependencies, the API update could fail validation even though the JSON structure is correct. Check if your custom attributes have any special validation logic that might not be accessible to the REST layer.

6

Also consider authentication and authorization. Sometimes REST endpoints fail with 500 errors when the API user doesn’t have proper permissions to update certain attributes, even though they can read them.

sqlace 7

Tested this on ENOVIA R2022x and adding our custom supplier attributes to the REST resource mapping files in Windchill/codebase/rest/config/resources/ immediately resolved the 500 errors.

8

I checked the server logs and found this exception: ‘Attribute certificationLevel not found in resource schema’. So it looks like the custom attributes aren’t mapped in the REST resource definition. Where exactly are these resource mapping files located, and what’s the syntax for adding custom attributes?