We’ve successfully implemented an automated BOM synchronization solution between Teamcenter PLM and Oracle Fusion Cloud SCM using REST APIs. The business driver was reducing our engineering change cycle time from 48 hours to under 4 hours.
Our architecture uses a middleware service that polls Teamcenter for BOM changes every 15 minutes, transforms the data structure to match Oracle’s ImportBOM schema, and pushes updates via REST endpoints. Key challenge was mapping Teamcenter’s hierarchical part structure to Oracle’s flat BOM format while preserving parent-child relationships.
The solution handles component additions, deletions, and quantity changes. We’re processing approximately 350 BOMs daily with 99.2% success rate. Implementation reduced manual data entry by 85% and eliminated duplicate entry errors that were causing production delays.
How are you handling the REST API authentication and token refresh? We’ve had issues with OAuth tokens expiring mid-batch when processing large BOM updates. Also, what’s your error handling strategy when the Oracle API returns validation errors?
What about engineering change orders? When an ECO affects multiple BOMs in Teamcenter, how do you ensure atomic updates in Oracle? We can’t have situations where some BOMs update successfully while others fail, leaving the system in an inconsistent state.
We use OAuth 2.0 with client credentials flow. The middleware maintains a token cache and proactively refreshes tokens 5 minutes before expiration. For large batches, we chunk the BOMs into groups of 50 and process them sequentially with fresh token validation before each chunk.
Error handling has three tiers. First, schema validation happens client-side before API calls to catch obvious issues. Second, we parse Oracle’s error responses and categorize them as recoverable (retry after correction) or fatal (manual intervention needed). Recoverable errors like duplicate item numbers trigger an automatic query to check if the item already exists with matching attributes - if so, we skip it. Fatal errors get logged to our monitoring dashboard with the full payload for troubleshooting. We also maintain a dead letter queue for failed BOMs that get reprocessed after fixes.
I’d also like to understand your approach to component substitutions and alternate parts. Teamcenter allows complex substitution rules that might not map directly to Oracle’s substitute components. How did you handle this in your data transformation?
Excellent questions that get to the heart of our implementation challenges. Let me address both systematically.
Engineering Change Automation:
We implemented a transaction-style approach for ECO processing. When Teamcenter releases an ECO affecting multiple BOMs, our middleware creates a change batch record with all affected BOM identifiers. We then process these in a specific sequence:
1. Extract all BOMs associated with ECO from Teamcenter
2. Validate each BOM transformation can succeed
3. Create staging records in middleware database
4. Begin Oracle API calls in dependency order (parent BOMs before child BOMs)
5. Track success/failure for each BOM in the batch
6. If any BOM fails after 3 retries, rollback the entire batch
The rollback mechanism uses Oracle’s REST API to revert BOMs to their pre-change state by posting the previous version’s data. We maintain a 30-day history of all BOM states in our middleware to enable this. This ensures atomic updates across the ECO scope.
BOM Data Mapping for Substitutions:
For component substitutions, we leverage Oracle’s SubstituteComponentNumber field in the ImportBOM structure. Our mapping logic handles three Teamcenter substitution scenarios:
Direct substitutes: Map to Oracle’s primary substitute with SubstituteType=‘Direct’
Alternate parts: Create separate BOM lines with same parent but different alternates
Conditional substitutes: We extract the condition logic from Teamcenter and encode it in Oracle’s SupplySubInventory field as a reference code, then maintain the actual logic in our middleware for future queries
For complex substitution rules that don’t map cleanly, we flag them during transformation and create reference documents that manufacturing can access through Oracle’s attachments. This was a pragmatic compromise - about 8% of our substitutions fall into this category.
REST API Integration Details:
Our integration uses Oracle’s /fscmRestApi/resources/11.13.18.05/items and /fscmRestApi/resources/11.13.18.05/bills endpoints. Key integration patterns:
Batch processing with 50-item chunks to avoid timeout issues
Parallel processing for independent BOMs using thread pool of 5 workers
Real-time status updates pushed to Teamcenter via callbacks to close the feedback loop
The cycle time reduction from 48 to 4 hours came primarily from eliminating manual review queues and duplicate data entry. Engineers now release changes in Teamcenter and manufacturing sees updates in Oracle within 15-30 minutes depending on the polling cycle.
Lessons Learned:
Invest heavily in data validation before API calls - it’s much cheaper than handling failures
Maintain detailed audit logs of every transformation for troubleshooting
Build comprehensive monitoring dashboards - we track API response times, error rates, and transformation success rates in real-time
Start with a pilot group of simple BOMs before tackling complex assemblies
Document your mapping decisions extensively - you’ll need to reference them during troubleshooting
We’re now extending this pattern to synchronize engineering changes and routings. Happy to share more specific implementation details if helpful.
This is impressive work! I’m curious about your BOM data mapping strategy. Did you handle unit of measure conversions between systems? We’re facing similar challenges where Teamcenter uses metric units but our Oracle instance requires imperial for certain manufacturing sites. Also, how do you manage effectivity dates during the transformation?