JSON schema validation fails when pushing manufacturing BOM data

PLM Windchill
, , , , , , , ,
1

Our REST API integration pushes manufacturing BOM data from MES to Windchill, but JSON schema validation fails with cryptic error messages. The validation rejects payloads that seem perfectly valid according to the published schema documentation.

Example error:


Validation failed: $.components[12].quantity
Expected type: number, found: string
Schema path: #/definitions/BOMComponent/properties/quantity

The quantity field is sent as “10.5” (string) from our MES system, but Windchill’s strict schema validation expects numeric types. We also have issues with optional fields-sometimes they’re required, sometimes not, depending on component type.

Has anyone dealt with JSON schema validation inconsistencies? Should we transform data client-side to match exact schema expectations, or is there a way to configure more lenient validation on the Windchill side?

system 2

Here’s a comprehensive solution addressing all the validation challenges:

JSON Schema Strict Validation Rules: Windchill enforces JSON schema validation with zero tolerance for type mismatches. The schema defines explicit types for each field, and runtime validation rejects any deviation. Your error shows the core issue-quantity sent as string “10.5” when schema expects numeric type.

Field Mapping and Transformation: Implement a transformation layer that maps MES data to Windchill’s schema requirements:


// Transform quantity from string to number
const transformed = {
  quantity: parseFloat(mesData.quantity),
  componentType: mesData.type,
  partNumber: mesData.part_id
};

Key transformations needed:

  • Numeric fields: Parse strings to numbers (parseFloat/parseInt)
  • Date fields: Convert to ISO 8601 format (YYYY-MM-DDTHH:mm:ssZ)
  • Boolean fields: Convert string “true”/“false” to actual booleans
  • Null handling: Omit optional fields entirely rather than sending null values

Optional vs Required Field Handling: The schema distinguishes between optional and required fields, but with nuances:

  • Required fields must always be present and non-null
  • Optional fields can be omitted entirely from the payload
  • If an optional field IS included, it must match the defined type
  • Conditional requirements use “dependencies” or “if/then/else” schema constructs

For your componentType scenario, examine the schema for dependency rules:


"dependencies": {
  "componentType": {
    "oneOf": [
      { "properties": { "componentType": { "const": "manufactured" } },
        "required": ["manufacturingProcess"] }
    ]
  }
}

Implement conditional logic in your transformation layer to include required fields based on component type.

Schema Compliance Testing: Build a validation pipeline before sending data to Windchill:

  1. Load the official JSON schema from Windchill (available via GET /schema endpoint)
  2. Use a validation library (AJV, jsonschema, etc.) to validate transformed payloads locally
  3. Log validation errors with detailed field paths and expected vs actual values
  4. Fix transformation logic based on validation feedback
  5. Only send payloads that pass local validation to Windchill

Example validation setup:


// Pseudocode - Key implementation steps:
1. Fetch current schema: GET /Windchill/servlet/odata/$metadata
2. Initialize JSON schema validator with fetched schema
3. For each MES record, apply transformation rules
4. Validate transformed payload against schema
5. If validation passes, POST to Windchill API
6. If validation fails, log error details and queue for manual review
// See Windchill Integration Guide Section 9.4 for schema endpoint details

This approach catches 95%+ of schema validation errors before they reach Windchill, significantly improving integration reliability.

Additional Recommendations:

  • Request the exact schema version from your Windchill administrator-documentation often lags behind actual implementation
  • Test with a variety of component types to identify all conditional requirements
  • Implement comprehensive error logging that captures both the original MES data and the transformed payload
  • Consider caching schema definitions locally and refreshing periodically (daily) rather than fetching on every request

By implementing client-side transformation and validation, you’ll eliminate schema validation errors and gain much clearer visibility into data quality issues originating from the MES system.

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

JSON schema validation in Windchill is strict by design. You’ll need to transform your data client-side to match the schema exactly. For numeric fields, parse strings to actual numbers before sending. For optional fields, check the schema definition carefully-“optional” often means the field can be omitted entirely, but if present, it must match the specified type and format.

4

We built a transformation layer specifically for this. The MES system exports data in its native format, and our middleware transforms it to match Windchill’s schema requirements before making the API call. This decouples the systems and makes debugging easier-you can validate transformed payloads independently before sending them to Windchill.

5

That makes sense. What’s the best way to handle conditional required fields? Our schema shows some fields as required only when componentType equals “manufactured”. Do we need to implement schema-aware validation logic in our transformation layer?

6

Yes, implement schema-aware validation. Use a JSON schema validation library (like AJV for JavaScript or jsonschema for Python) to validate your transformed payload before sending it. This catches errors early and gives you clearer error messages than Windchill’s validation failures. For conditional requirements, the schema should define these using “oneOf”, “anyOf”, or “if/then/else” constructs.

fernandolead 7

Confirmed this resolves our MES integration failures—transforming quantity fields from string to numeric type in the JSON schema mapping eliminated all Windchill BOM push validation errors immediately.

8

Check if your Windchill version supports schema versioning. Newer versions allow you to specify which schema version you’re targeting in the API request header (X-Schema-Version). This can help if the documentation you’re following doesn’t match your Windchill instance’s actual schema.

10

Don’t forget about field mapping documentation. Windchill’s REST API often uses different field names than the UI displays. The schema defines technical field names (like “quantityValue”) while documentation might reference business terms (like “quantity”). Always validate against the actual schema definition, not the documentation.