We’re experiencing BOM view revision synchronization failures after implementing a custom handler in TC 12.3. The handler is supposed to maintain consistency between structure and occurrence revisions during BOM updates.
The problem manifests when we modify BOM structures with more than 3 levels deep. Custom handler recursion seems to be the issue - it processes parent assemblies correctly but fails on sub-assemblies. Here’s the error pattern:
We’ve checked BOM API usage in our handler and believe we’re following standard patterns, but server log analysis shows the handler is being invoked multiple times for the same BOM line. This creates data inconsistencies where occurrence revisions don’t match their referenced part revisions.
Has anyone dealt with similar custom handler recursion issues in BOM synchronization workflows?
BOM view revision synchronization requires careful attention to all three focus areas you mentioned. Let me address each systematically:
Custom Handler Recursion:
The root cause is your handler triggering itself through BOM modification events. Implement this pattern:
private static ThreadLocal<Boolean> processing = new ThreadLocal<>();
public void syncRevisions(BOMLine line) {
if (Boolean.TRUE.equals(processing.get())) return;
try {
processing.set(true);
line.setEventSuppressionMode(true);
// Your sync logic here
} finally {
processing.remove();
line.setEventSuppressionMode(false);
}
}
BOM API Usage:
You must use TCComponentBOMLine.setWindow() to establish proper context before accessing revision data. Don’t directly modify occurrence revisions - instead, use the BOMView’s revision rule to control what gets displayed, then sync the underlying structure. The API expects you to work through the BOMWindow interface for all revision-related operations.
Server Log Analysis:
Enable debug logging for com.teamcenter.soa.server.internal and wt.epm.structure packages. You’ll see the event propagation chain. Look for patterns like:
Multiple MODIFY_BOMLINE events for same object
Transaction boundary violations (COMMIT before handler completion)
Revision rule evaluation failures
The key insight from the logs will be whether your handler is firing during the initial modification or during subsequent automated updates. If it’s the latter, you have an event filtering problem, not just a recursion issue.
Additional Recommendations:
Add validation to check BOM depth before processing (fail fast for depth > 10)
Use AIFComponent.setPropertyValue() instead of direct property access for better event control
Consider implementing a queue-based approach for deep structures rather than recursive processing
Review your custom preference settings - some organizations accidentally enable duplicate handler registrations through preference conflicts
This approach has resolved similar issues in TC 12.3 through 13.2 environments. The thread-local pattern combined with event suppression provides the most reliable solution for BOM synchronization handlers.
This draft is based on general Teamcenter knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen this before. Your handler is probably triggering itself through the BOM update events. Check if you’re using proper event filtering in your handler registration. You need to add a flag to prevent re-entry when your handler makes changes.
The recursive call depth issue typically happens when handlers don’t properly manage their execution context. When you update a BOM line, it fires events that can re-trigger your handler. You need to implement a thread-local flag or use Teamcenter’s event suppression mechanisms. Also verify your handler is registered at the correct event point - pre-event vs post-event matters significantly here. For BOM synchronization, post-event is usually safer because the transaction is already committed. Check your preference settings for wt.epm.structure.handlers.enabled and ensure you’re not doubling up handler registrations.
Thanks for the suggestions. I checked our handler registration and we are using post-event. However, I’m not sure how to implement the thread-local flag properly. Could you provide more details on the event suppression mechanism?
“Tested this on Teamcenter 13.2 with a custom ITK handler — the ThreadLocal recursion guard combined with setEventSuppressionMode(true) completely eliminated our BOM sync loop failures.”
For the thread-local approach, create a ThreadLocal variable in your handler class. Set it to true at the start of your syncRevisions method and check it before processing. If it’s already true, return immediately. This prevents the recursion. Don’t forget to reset it in a finally block. The event suppression is more elegant though - use TCComponentBOMLine.setEventSuppressionMode(true) before making changes and restore it afterward.
I’d also recommend reviewing your BOM API usage patterns. Are you using the proper transaction boundaries? If you’re calling PersistenceHelper.manager.save() within your handler without proper transaction management, you might be creating partial commits that trigger additional events. Also, the server log analysis should show you the exact event chain - look for TCComponentBOMLineRevisionRule evaluations in the logs.