REST API validation fails during automated BOM sync in sbom-mgmt testing

PLM Windchill
, , , , , , , ,
1

Our automated BOM synchronization tests are failing at the validation stage when using the REST API for SBOM management. The API accepts the payload and returns 200 OK, but subsequent validation queries show the BOM structure wasn’t created correctly.

The JSON schema validation appears to pass, but when we query the created BOM, several child components are missing. We suspect data type consistency issues between what we’re sending and what Windchill expects.


POST /Windchill/servlet/odata/BOM/BOMs
Status: 200 OK
GET /Windchill/servlet/odata/BOM/BOMs('BOM-12345')/Components
Result: Only 3 of 7 components present

This is blocking our regression suite. Has anyone experienced issues with API payload encoding or validation in SBOM operations?

system 2

I’ve debugged this exact scenario for SBOM operations. Here’s the complete solution addressing all three focus areas:

For JSON schema validation, the API’s initial validation is superficial - it only checks top-level structure. The deep validation happens during persistence, which is where your components are failing. Your payload structure needs to explicitly define the component relationships:

{
  "Components": [
    {"@odata.bind": "Parts('OR:wt.part.WTPart:12345)"},
    {"@odata.bind": "Parts('OR:wt.part.WTPart:12346)"}
  ]
}

For data type consistency, this is critical and often overlooked. Quantity fields must be numeric, not string. Reference fields must use proper OData bind syntax. Date fields must be ISO 8601 format. Your payload likely has mixed types:

// WRONG
{"Quantity": "5.0", "Unit": "EA"}
// CORRECT
{"Quantity": 5.0, "Unit": "EA"}

For API payload encoding, the component references must be URL-encoded if they contain special characters. The OData key format ‘OR:wt.part.WTPart:12345’ contains colons which need proper encoding in navigation bindings. Use a proper JSON library that handles encoding automatically.

The root cause of your missing components: the API accepts the POST because the BOM object itself is valid, but the component relationships fail silently during the transaction. The 200 OK response indicates the BOM was created, not that all nested operations succeeded.

Here’s the validation approach we use:

// After POST, verify each component explicitly
for (String componentId : expectedComponents) {
  Response check = given().get(
    "/Windchill/servlet/odata/BOM/BOMs('" + bomId + "')/Components"
    + "?$filter=ComponentPart eq '" + componentId + "'");
  assertTrue(check.path("value.size()") > 0);
}

Implement batch validation immediately after the POST to catch these silent failures in your test automation. Also enable detailed OData logging in Windchill to capture the actual validation errors - they’re not included in the HTTP response by default.

One final critical point: if you’re creating components and BOM structure in a single payload, use the $batch endpoint instead of individual POSTs. This ensures transactional consistency and will give you proper error responses if any component fails validation.

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

3

Check your JSON payload structure carefully. The SBOM API in 12.0 is strict about the component relationship format. Are you including the proper navigation properties for parent-child relationships? Also verify that all component references use the correct OData format with proper entity keys.

4

I’ve seen this when the component objects exist but the BOM links aren’t created. The API might be accepting your payload but silently failing on the relationship creation. Check the method server logs for any warnings about constraint violations or referential integrity issues. Sometimes the API returns 200 even when backend validation fails on secondary operations.

5

Checked the logs and found warnings about ‘Invalid component reference format’ for 4 of the 7 components. The error messages mention OData entity key format, but I’m using the same format for all components. Why would some succeed and others fail if they’re all structured identically?

marktechie 6

“Confirmed this resolves the deep validation failure in Windchill SBOM sync—explicitly defining @odata.bind component relationships in the JSON payload eliminated our persistence-layer errors immediately.”

7

The inconsistency suggests special characters or encoding issues in the component identifiers. OData keys are URL-encoded, so if some of your component IDs contain characters that need escaping (like spaces, slashes, or special symbols), they might be getting corrupted during the POST. Verify that you’re properly URL-encoding all entity keys in your JSON payload, especially in the navigation property references.

8

Also check the data types for quantity and unit fields. The SBOM API expects specific numeric types for quantities - using strings instead of numbers will cause silent validation failures. We had a similar issue where our JSON had quantity as “5.0” (string) instead of 5.0 (number), and the API accepted it but didn’t create the relationships properly.