We successfully implemented an automated BOM synchronization solution between Teamcenter and ENOVIA R2022x using REST APIs. Our engineering team needed real-time BOM updates flowing from Teamcenter (our mechanical design hub) to ENOVIA (our enterprise PLM backbone) without manual data entry.
The challenge was handling incremental updates efficiently. We built a middleware service that polls Teamcenter every 15 minutes for BOM changes, maps attributes between the two systems, and pushes updates to ENOVIA via REST endpoints. The attribute mapping was crucial - Teamcenter’s “Item ID” maps to ENOVIA’s “Part Number”, quantities need unit conversion, and custom attributes require transformation logic.
Key implementation aspects: REST API authentication with OAuth tokens, JSON payload construction for ENOVIA’s BOM structure endpoints, and handling parent-child relationships during incremental syncs. We process only changed items rather than full BOMs, dramatically improving performance.
The solution reduced BOM sync time from 4 hours (manual) to 15-minute cycles (automated) and eliminated data entry errors. Happy to share technical details about our REST integration approach and attribute mapping strategies.
For OAuth token management, we implemented a token refresh mechanism in our middleware. The service checks token expiration before each API call and automatically refreshes if within 5 minutes of expiry. We store tokens securely in memory with fallback to encrypted config files.
We primarily use ENOVIA’s standard 3DSpace REST APIs for BOM operations - specifically the /resources/v1/modeler/dseng:EngItem endpoints for parts and /resources/v1/modeler/dseng:EngItemInstance for BOM relationships. The standard endpoints covered 90% of our needs. We only created one custom web service for our specific attribute transformation logic that couldn’t be handled client-side efficiently.
Excellent question - relationship changes were tricky. We implemented a delta detection algorithm that compares current Teamcenter BOM structure against the last synced snapshot stored in our middleware database. For each parent assembly, we identify three change types: new children (create relationships), removed children (delete relationships), and modified children (update quantities or reference designators).
When a component moves between parents, our algorithm detects it as a remove operation on the old parent and an add operation on the new parent. We execute these as separate REST API calls to maintain data integrity. For quantity or position number changes, we update relationships in place using PUT operations on the existing EngItemInstance objects. This approach minimizes API calls while ensuring accurate BOM structure replication.
Great use case! How do you handle the attribute mapping complexity? We have over 50 custom attributes in Teamcenter that need mapping to ENOVIA. Did you hardcode the mappings or use a configuration-driven approach?
This is exactly what we’re planning for our Siemens-to-ENOVIA integration. How did you handle authentication refresh with the OAuth tokens? We’re concerned about token expiration during long-running sync operations. Also, did you use ENOVIA’s standard REST endpoints or did you need custom web services?
We went fully configuration-driven. Created an XML mapping configuration file that defines source-to-target attribute pairs, data type conversions, and transformation rules. Each mapping entry includes source attribute name, target attribute name, data type, default values, and optional transformation functions (like unit conversions or value lookups).
Our middleware reads this config at startup and builds a mapping engine that applies transformations during sync. This approach means business users can modify mappings without code changes - they just update the XML and restart the service. We also built a validation layer that checks if target attributes exist in ENOVIA before attempting updates, which prevents sync failures from schema mismatches.
How do you handle incremental BOM updates when parent-child relationships change? For example, if a component moves from one parent assembly to another, or quantity changes occur. Do you delete and recreate relationships or update in place?