I want to share our implementation of automated service BOM updates using ENOVIA’s REST API in R2020x. Previously, our field technicians manually updated service BOMs after equipment repairs, which was time-consuming and error-prone. Technicians would complete repairs, document parts used on paper forms, and then office staff would manually enter this data into ENOVIA - often days later. This delay caused inventory discrepancies and made it difficult to track actual parts consumption. We developed a mobile app that field technicians use to scan parts and submit repair data. The app calls ENOVIA’s REST API to update service BOMs in real-time. We implemented nightly sync jobs to reconcile any failed transactions and validation rules to ensure data quality. The results have been impressive - BOM accuracy improved from 78% to 96%, and the time from repair completion to BOM update dropped from 3-4 days to under 10 minutes. I’ll detail the technical implementation for anyone interested in similar automation.
Let me provide comprehensive details on our implementation covering REST API integration, nightly sync jobs, and validation rules:
REST API Integration: Our mobile app integrates with three primary ENOVIA REST endpoints. First, the authentication endpoint for OAuth token management:
POST /auth/oauth/token
Grant_type: refresh_token
This handles token refresh automatically every 90 minutes. Second, the Part search endpoint to validate scanned part numbers:
GET /resources/v1/modeler/parts/{partNumber}
This confirms the part exists and retrieves current inventory status. Third, the BOM update endpoint:
POST /resources/v1/modeler/boms/update
Body: {serviceOrder, partNumber, quantity, technicianId, timestamp}
All API calls include retry logic with exponential backoff - if a call fails, the app retries after 2, 4, then 8 seconds before queuing for later sync.
Nightly Sync Jobs: We implemented a scheduled job that runs at 2 AM daily to reconcile failed transactions. The job queries our local transaction database for any updates with status ‘pending’ or ‘failed’. It attempts to resubmit these transactions to ENOVIA, logging the results. The job also performs a reconciliation check - it queries ENOVIA for all service BOM updates from the previous 24 hours and compares them against our local transaction log. Any discrepancies generate alerts for the operations team to investigate. This dual approach (retry failed transactions + verify successful ones) ensures no updates are lost. The sync job uses the same REST endpoints as the mobile app but includes additional error handling for bulk operations.
Validation Rules: We implement validation at three levels. At the mobile app level, basic checks occur immediately - part number format validation (must match our numbering scheme), quantity must be positive integer, service order must be active in local cache. These checks provide instant feedback to technicians. At the API gateway level (before reaching ENOVIA), we validate that the part exists in the master data, the service order is open and assigned to the requesting technician, and the part is approved for use in service operations. This prevents invalid data from reaching ENOVIA. At the ENOVIA level, business rules validate that adding the part doesn’t violate inventory policies, the part’s lifecycle state allows it to be used, and the service BOM structure remains valid after the update.
For substitute parts, we implemented a substitution approval workflow. When a technician indicates they’re using a substitute part, the transaction is flagged for review. The update still processes immediately (we don’t want to delay field work), but it creates a task for the service engineering team to approve or reject the substitution. If rejected, they can correct the BOM and update the approved parts list. This balances operational speed with data governance.
Implementation Results: Beyond the accuracy and timing improvements I mentioned, we’ve seen other benefits. Inventory forecasting improved because we have real-time visibility into parts consumption patterns. Technician productivity increased by about 15% because they spend less time on paperwork. The data quality improvement enabled us to implement predictive maintenance - we can now identify parts that fail frequently and proactively replace them during scheduled maintenance.
Technical Recommendations: If you’re implementing something similar, invest heavily in the offline capability and sync logic. Field environments are unpredictable, and your app must work reliably without connectivity. Keep the mobile UI simple - technicians are focused on repairs, not data entry. Use barcode scanning wherever possible to minimize manual input. Implement comprehensive logging - you’ll need detailed logs to troubleshoot issues when technicians are remote. Finally, involve field technicians in the design process - they understand the practical constraints and workflow requirements better than IT teams.
This sounds like exactly what we need. What mobile platform did you use for the field app? And how did you handle authentication for the REST API calls from mobile devices? We’ve been struggling with secure API access from field applications.
We primarily use the Part and BOMLine endpoints. For offline capability, the app queues transactions locally when connectivity is unavailable. When connection is restored, it automatically syncs queued transactions. The nightly sync job I mentioned also catches any transactions that failed during the day and retries them. We track sync status in a separate database table so we can monitor and troubleshoot any persistent failures.
How do you handle validation? Field technicians might scan the wrong part or enter incorrect quantities. Do you validate at the mobile app level, at the API level, or both? And what happens if validation fails - does the transaction get rejected or queued for manual review?