BOM synchronization incomplete when variant parts contain unresolved external references

PLM Windchill
, , , , , , , ,
1

Our variant configuration workflows are failing during BOM synchronization when parts contain external references that aren’t fully resolved. The process times out after 10 minutes, leaving the BOM in an inconsistent state.

We’ve noticed this particularly affects assemblies with 200+ variant parts where external reference resolution is needed. The asynchronous processing queue shows tasks stuck in ‘RUNNING’ state indefinitely.


BOM Sync Error: Timeout after 600000ms
at wt.part.PartHelper.syncBOM(PartHelper.java:892)
Caused by: External reference resolution incomplete

Reference caching appears to be working for simple parts, but fails with complex variant structures. Any insights on tuning the timeout settings or improving external reference resolution performance?

2

External reference resolution in variant contexts is notoriously slow because Windchill has to evaluate all possible variant combinations to determine which references are valid. If your external references span multiple product contexts, this gets exponentially worse. Consider pre-resolving references during the CAD check-in process rather than waiting for BOM sync.

3

Check if your external references are using absolute or relative paths. Relative references require additional context resolution that can timeout in complex structures.

4

We had the exact same issue. The problem was that some external references were pointing to parts that had been moved or deleted, causing the resolution process to hang while it searched. Run a reference validation report to identify broken references before attempting BOM sync.

5

The 10-minute timeout is controlled by the wt.bom.syncTimeout property in site.xconf. However, simply increasing this won’t solve the underlying problem. You need to look at why external reference resolution is taking so long. Are these references pointing to parts in different contexts or product structures? That can significantly slow down the resolution process.

6

Your BOM synchronization timeout issue with variant parts requires a multi-faceted approach addressing all the key areas:

1. External Reference Resolution Optimization The core issue is inefficient reference resolution for variant configurations. Modify your site.xconf:


<Property name="wt.bom.externalRef.resolveDepth" value="2"/>
<Property name="wt.bom.externalRef.parallelThreads" value="8"/>

This limits resolution depth and enables parallel processing. For 200+ part assemblies, parallel resolution is essential.

2. BOM Synchronization Timeout Configuration Increase the timeout, but also enable progress monitoring:


<Property name="wt.bom.syncTimeout" value="1800000"/>
<Property name="wt.bom.syncProgressInterval" value="30000"/>

This extends timeout to 30 minutes and logs progress every 30 seconds, helping identify exactly where the process stalls.

3. Asynchronous Processing Queue Tuning Your stuck ‘RUNNING’ tasks indicate queue saturation. Increase queue capacity:

  • Navigate to Site > Utilities > Queue Management
  • For the BOMSync queue, increase max concurrent tasks from default 5 to 15
  • Set task timeout to 45 minutes
  • Enable task priority so variant BOM syncs get precedence

4. Reference Caching Enhancement Variant parts need larger cache allocation. Update xconf.properties:


wt.cache.externalRef.size=5000
wt.cache.externalRef.ttl=3600
wt.cache.variant.enabled=true

The variant-specific cache prevents constant re-evaluation of reference validity across configurations.

5. Pre-Resolution Strategy Implement a pre-sync validation step:

  • Create a scheduled job that runs reference validation nightly
  • This populates the cache during off-hours
  • BOM sync operations then use cached resolution results

Monitoring and Validation: After implementing these changes:

  • Monitor MethodServer logs for resolution timing per part
  • Check queue metrics to ensure tasks complete within timeout
  • Run test sync on a 50-part subset before full assembly

The combination of parallel processing, extended timeouts, and proactive caching should resolve your variant BOM synchronization issues. Start with queue and cache tuning, then adjust timeouts based on observed performance.

7

Are you using the standard BOM sync or a custom implementation? We found that breaking large variant assemblies into smaller chunks and syncing them separately improved performance dramatically. The asynchronous processing queue has limits on how many concurrent reference resolutions it can handle. You might be hitting that limit with 200+ parts. Monitor the queue manager metrics to see if tasks are waiting for available threads.

8

I’ve dealt with this in large assemblies. The issue is that reference caching doesn’t work efficiently when you have variant parts because each variant configuration requires a separate cache entry. The cache gets overwhelmed and starts evicting entries before the BOM sync completes. Check your cache size settings and consider increasing the reference cache pool.