We’re architecting a bidirectional EBOM synchronization between Aras 13.0 and our ERP system. The integration needs to handle complex BOMs with 5000+ line items and maintain real-time consistency between systems.
I’m evaluating REST API versus SOAP API for this integration. REST seems more modern and lightweight, but SOAP has built-in WS-Security and better transaction handling. The data mapping complexity is significant - we need to transform hierarchical BOM structures while preserving relationships and handling part substitutions.
Performance with large BOMs is critical since our manufacturing planning depends on up-to-date BOM data. Has anyone implemented large-scale EBOM sync using either API approach? What were the trade-offs in terms of performance, reliability, and handling complex data transformations? Particularly interested in experiences with batch operations versus incremental updates.
For 5000+ line EBOM synchronization at this scale, the choice between REST and SOAP in Aras Innovator isn’t purely philosophical — each has concrete implications across your three criteria.
Criteria
REST (OData/JSON)
SOAP (AML/XML)
Payload performance
Lighter per-request overhead; JSON parsing faster for flat structures
XML verbosity increases payload size ~30–40%; heavier parsing under load
Hierarchical BOM fidelity
Requires multiple requests or custom expansion parameters to walk BOM levels
Native AML handles recursive BOM structures and relationships in a single envelope
Transaction handling
Stateless by design; partial failures require compensating logic
WS-AtomicTransaction support gives rollback semantics across multi-item operations
WS-Security with message-level signing; stronger for regulated environments
Batch operations
Batch endpoint available but less mature in Aras 13 (verify in your version)
AML <ApplyItems> supports multi-item operations natively in one call
Part substitution mapping
Requires explicit relationship traversal calls
Relationship items (Substitute) included inline in AML query results
Tooling/ecosystem
Broader modern tooling (Postman, OpenAPI spec generation)
More stable in legacy ERP middleware stacks (SAP PI, MuleSoft SOAP connectors)
Error granularity
HTTP status codes + custom error body; inconsistent across endpoints
Structured SOAP faults with Aras-specific fault codes; easier to parse programmatically
Key architectural considerations for your scenario:
For bidirectional sync at this scale, the change token / config_id + generation pattern matters more than the transport protocol. Regardless of which API you use, your sync engine needs to track Aras’s modified_on and not_lockable flags to avoid overwriting in-flight ECO changes.
For incremental updates (recommended over full BOM pushes), REST’s stateless model is cleaner — you query deltas using OData $filter on modified_on. For initial load or full reconciliation passes on deep multi-level BOMs, SOAP AML is operationally simpler because a single <Item type="Part BOM" action="get"> with <Relationships> can traverse the hierarchy without N+1 call patterns.
Reliability under load: REST’s stateless nature means your ERP-side orchestrator owns retry logic entirely. SOAP doesn’t eliminate this requirement — WS-AtomicTransaction is rarely implemented end-to-end across Aras and ERP middleware in practice (verify in your version and ERP connector support).
Data mapping complexity for substitutes and phantom assemblies is non-trivial in both, but AML’s inline relationship model reduces the join logic you’d otherwise build in a REST orchestration layer.
If your ERP middleware already speaks SOAP natively and you need deep BOM traversal with relationship fidelity, SOAP reduces integration surface area. If you’re building a modern event-driven integration with a middleware like MuleSoft or Azure Integration Services, REST aligns better with those patterns.
Ultimately depends on context / your requirements.
This draft is based on general Aras Innovator knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
We implemented EBOM sync using REST API for Aras 13.0 to SAP integration. For large BOMs, we use batch operations with pagination - fetching 500 line items per request. REST performance is excellent, but you need to implement your own transaction handling and error recovery. We built a state machine that tracks sync progress and can resume from failures. The JSON payload for REST is more compact than SOAP XML, which helps with network transfer times. However, REST doesn’t have native support for distributed transactions, so you need to implement compensating transactions if the sync fails partway through.
SOAP API has advantages for complex EBOM scenarios. The WS-ReliableMessaging standard ensures message delivery even if network issues occur. We use SOAP for our aerospace EBOM integration where reliability is paramount. The data mapping complexity is similar regardless of API choice - you’ll need transformation logic either way. SOAP’s schema validation catches data issues earlier in the process. Performance-wise, SOAP overhead is only about 15-20% compared to REST for our 3000-item BOMs, which is acceptable given the reliability benefits. The built-in transaction support in SOAP is valuable when you need atomic operations across multiple BOM levels.
From a development perspective, REST API is much easier to work with. Modern tools and libraries have excellent REST support. For BOM data mapping, we use JSON transformations with JSONPath expressions to navigate hierarchical structures. Performance tuning is straightforward with REST - you can implement parallel requests for different BOM branches, implement caching strategies, and use HTTP/2 multiplexing. The challenge with REST is implementing reliable batch operations. We use a queue-based approach where BOM changes are queued and processed in batches every 5 minutes, with retry logic for failures.
Consider your ERP system’s capabilities too. If your ERP has better REST support, that might drive your decision. We sync BOMs between Aras and Oracle ERP using REST because Oracle’s REST APIs are more mature than their SOAP offerings. For performance with large BOMs, we implemented delta synchronization - only syncing changed items rather than full BOMs. This reduced sync times from 15 minutes to under 2 minutes for typical changes. The key is maintaining a change tracking mechanism in both systems so you know what needs to sync.
Don’t underestimate data mapping complexity regardless of API choice. BOM hierarchies, effectivity dates, alternate parts, and reference designators all need careful transformation logic. We built a mapping engine that sits between Aras and ERP, translating between their different BOM models. This abstraction layer made it easier to switch from SOAP to REST later when requirements changed. For 5000+ line item BOMs, consider using message queuing middleware like RabbitMQ or Azure Service Bus to handle the async processing. This decouples the API calls from the business logic and provides built-in retry and dead letter handling.
Having implemented both REST and SOAP integrations for EBOM synchronization across multiple industries, I can provide comprehensive guidance on all three focus areas:
REST vs SOAP Comparison:
For EBOM synchronization specifically, both APIs have distinct advantages:
REST API Strengths:
30-40% better performance for large payloads due to JSON’s compactness vs XML
Simpler development and testing with modern tools (Postman, Swagger)
Better caching support using HTTP headers (ETags, Cache-Control)
Easier to implement parallel processing for BOM branches
Native support in most modern ERP systems
Lower bandwidth consumption (important for cloud deployments)
SOAP API Strengths:
Built-in WS-Security for message-level encryption and signing
WS-ReliableMessaging for guaranteed delivery
Native transaction coordination with WS-AtomicTransaction
Schema validation catches data errors before processing
Better for complex operations requiring stateful conversations
More mature error handling standards (SOAP Faults)
For Aras 13.0 EBOM sync with 5000+ line items, I typically recommend REST API unless you have specific requirements for distributed transactions or need WS-Security compliance. REST’s performance advantage becomes significant at scale.
Data Mapping Complexity:
This is independent of API choice but critical for success. Key challenges with EBOM mapping:
Hierarchical Structure Preservation: BOMs are trees, but APIs work with flat data. You need to either flatten the hierarchy (with parent references) or use nested JSON/XML. For 5000+ items, flattening performs better.
Relationship Management: Part-to-part relationships, quantity per assembly, reference designators, and find numbers must maintain integrity. Use a two-phase approach: first sync parts, then sync relationships with validation.
Effectivity Handling: Date effectivity and unit effectivity require careful transformation. Map Aras effectivity to ERP effectivity models explicitly, don’t assume they align.
Alternate Parts and Substitutions: These often don’t map directly between systems. We typically create a mapping table that translates Aras alternate part structures to ERP-specific equivalents.
Implementation pattern that works well:
Use a canonical data model as an intermediate format
Transform Aras EBOM → Canonical → ERP format
This makes it easier to add additional systems later
Store mapping rules in a configuration database, not hardcoded
Performance with Large BOMs:
For 5000+ line items, performance optimization is critical:
Batch Processing: Never sync one item at a time. Use batch operations with 200-500 items per batch. REST batch endpoints in Aras 13.0 support this well.
Delta Synchronization: Only sync changed items. Implement change detection using:
Aras History tables to track modifications
Timestamp-based queries to fetch items modified since last sync
Hash-based change detection for BOM structures
Parallel Processing: For REST, you can parallelize requests for independent BOM branches. This can reduce total sync time by 60-70% for wide BOMs.
Caching Strategy: Cache part master data (doesn’t change often) and only sync BOM structure changes frequently. This reduces payload size significantly.
Async Processing: Use message queues for large BOMs. Post BOM changes to a queue, process asynchronously, and notify systems when complete. This prevents timeout issues.
Benchmark from recent implementation (Aras 13.0 to SAP):
REST API with batching: 5000 items in 3.5 minutes
SOAP API with same batching: 5000 items in 4.8 minutes
Delta sync (typical 200 changed items): under 30 seconds for both
Practical Recommendation:
Use REST API with the following architecture:
Implement delta synchronization based on modification timestamps
Use batch operations with 300-500 items per batch
Build a transformation layer that handles data mapping separate from API calls
Implement retry logic with exponential backoff for transient failures
Use message queuing for async processing of large BOMs
Monitor sync performance and implement alerting for failures
This gives you the performance benefits of REST while addressing reliability concerns through proper error handling and retry mechanisms. The data mapping complexity is the same either way, so don’t let that drive your API choice.