Stabilizing a high-volume EDI integration and restoring ERP processing
Resolving long-running Boomi executions, controlling concurrency into NetSuite and recovering a backlog of financial transactions.
- Boomi
- NetSuite
- EDI X12
- Process Reporting
- Event notifications
- Longest executions
- 18–20+ hrs
- Invoices backlogged
- ~19,000
- Bills backlogged
- ~17,000
- Reading time
- 8 min
A production degradation that kept feeding itself
A high-volume enterprise integration environment experienced a critical production degradation in which multiple Boomi processes responsible for EDI and ERP transactions began running for several hours instead of completing within their normal processing window.
Some executions remained active for approximately 18–20+ hours, while duplicate and overlapping executions accumulated. As the workload increased, the integrations consumed shared runtime and ERP resources, resulting in processing delays, connection contention and a growing transaction backlog.
The integration team performed a production-level investigation, identified the interaction between long-running executions and downstream ERP connection capacity, terminated redundant executions, controlled concurrent processing, manually recovered affected transactions and introduced additional monitoring and operational controls.
The result was restoration of normal transaction processing and a more resilient operating model for high-volume EDI workloads.
Business-critical flows, backing up by the hour
The customer operated a business-critical integration landscape connecting its ERP platform with external applications, trading partners, databases and EDI networks.
- EDI purchase orders
- Invoices
- Vendor bills
- Shipment and fulfillment transactions
- Order acknowledgements
- Advance shipment notices
- ERP-to-external-system synchronization
Because these integrations supported operational and financial processes, a degradation in integration performance could quickly become a business issue.
- 1Boomi executions remaining active for many hours
- 2Multiple executions of the same integration overlapping
- 3ERP connections becoming increasingly constrained
- 4Transactions remaining pending instead of completing
- 5EDI and ERP processing backlogs increasing
- 6Operations teams having to manually intervene to restore processing
Processes that normally completed within a reasonable operational window were observed running for approximately 18–20+ hours, occupying runtime resources far longer than expected.
At the peak of the incident, the environment had accumulated approximately 19,000 invoices and 17,000 bills awaiting processing.
The problem was not caused by a single failed EDI document.
It was a system-level interaction between integration execution behavior, runtime capacity, process concurrency and downstream ERP limits.
A conventional troubleshooting approach would focus on individual failed documents and retry them. That would not solve the underlying problem — indiscriminate retries could increase the workload and make the situation worse.
Runtime capacity
Boomi documentation confirms that runtime execution capacity and process concurrency directly affect CPU, memory, queues and throughput, and that leaving maximum simultaneous executions unlimited can exhaust resources under high load.
ERP connection limits
Boomi’s NetSuite documentation states that concurrent connections are subject to the customer’s NetSuite licensing and account-level limits, and that processes running on different runtime nodes can compete for them.
The investigation had to consider the entire integration chain, rather than treating each failed transaction independently.
Four factors, one feedback loop
The investigation identified a combination of contributing factors.
- 01
Long-running process executions
Certain integration executions were taking substantially longer than their expected processing duration.
A long-running execution is not simply a slow transaction. It can keep consuming runtime resources while new scheduled executions begin.
- 02
Overlapping and duplicate executions
Additional executions were triggered while previous executions were still active.
This increased the amount of work competing for the same runtime and downstream resources.
- 03
Downstream ERP connection contention
Multiple processes were attempting to interact with the ERP while the ERP account had finite concurrent-request capacity.
Boomi’s NetSuite guidance recommends controlling concurrent connections, noting that processes running across nodes can hit connection limits.
- 04
Increasing transaction backlog
As processing slowed, transactions accumulated — and the backlog fed back into the pressure that created it.
This was the key architectural insight.
- Long-running execution
- Resource consumption
- Overlapping executions
- Downstream contention
- Slower processing
- Larger backlog
- Additional processing pressure
“Some EDI transactions failed.”
“The integration platform was processing workloads faster than the combined runtime and downstream systems could sustainably complete them.”
Telling a bad document from an overloaded platform
Boomi Process Reporting was used to analyse process execution and identify:
- Long-running executions
- Pending executions
- Failed executions
- Duplicate execution patterns
- Execution durations
- Document volumes
- Runtime assignment
- Process-level and document-level errors
Boomi provides execution-level and document-level logs for investigating process behavior, and execution details show the duration and processing sequence of individual steps.
One document fails because of bad business data.
The integration environment itself is becoming overloaded.
That distinction prevented the team from treating symptoms instead of the underlying problem.
Stabilise first, then recover in a controlled sequence
Four steps, in order — each one releasing pressure before the next put load back on the platform.
- Step 1
Identify and terminate redundant executions
The team reviewed active executions and identified duplicate or excessively long-running instances. Redundant executions were terminated to release runtime and downstream resources.
This was performed carefully, because terminating an integration execution without understanding its processing state can create duplicate or missing transactions.
- Step 2
Restore the critical transaction flows
After reducing the execution pressure, the team manually re-triggered critical integrations. The priority was not simply to clear the largest number of records — it was to restore business-critical transaction paths in a controlled sequence.
This included recovering blocked financial transactions and validating that the downstream ERP was again accepting transactions normally.
- Step 3
Control concurrency
The integration configuration was reviewed to prevent excessive simultaneous calls into the ERP — particularly important for NetSuite, where the maximum concurrent connection setting must stay within the account’s available connection capacity.
- The objective was not
- “Process everything as fast as possible.”
- The objective was
- “Process as much as the complete integration ecosystem can reliably sustain.”
- Step 4
Reduce unnecessary downstream pressure
The team reviewed opportunities to reduce repeated connector calls and unnecessary concurrent processing, in line with Boomi’s design guidance: limit connector calls, batch requests where possible, schedule appropriately and prevent unnecessary simultaneous executions.
This matters in EDI because one business transaction can trigger several downstream operations.
One EDI 850 purchase order may require- Item validation
- Customer validation
- Pricing lookup
- Inventory processing
- ERP order creation
One EDI 856 shipment may require- Shipment retrieval
- Item / UOM transformation
- Tracking information
- Downstream ERP updates
A seemingly small increase in concurrency can therefore multiply the number of downstream calls.
Proving the recovery, then watching for the next one
- Successful process completion
- ERP transaction creation
- Pending transaction reduction
- EDI document processing
- Error rates
- Runtime health
- Duplicate execution behavior
The team also manually recovered affected transactions after stabilizing the environment.
records were successfully synchronized during one of the manual recovery activities, helping validate that the downstream processing path had been restored.
Knowing that an integration failed is not enough.
Operations teams need to know when an integration is becoming unhealthy before it becomes a business-impacting outage. The team therefore worked toward proactive runtime and integration monitoring, covering:
- Atom / runtime availability
- Process execution status
- Long-running executions
- Failed executions
- Runtime resource utilization
- Disk capacity
- Memory / heap behavior
- Integration backlog
Boomi recommends monitoring runtime status, memory, machine resources, disk space and the number of processes running on a machine.
Boomi event notifications can report runtime online/offline status and process execution events — an opening for proactive operational alerting.
Integration performance is an end-to-end capacity problem.
Optimizing the Boomi process alone is not sufficient. The effective processing capacity is constrained by the weakest component in the chain:
- EDI Network
- Boomi Runtime
- Integration Process
- Database / API
- ERP
- Downstream Business Process
If any one component becomes a bottleneck, increasing concurrency elsewhere can make the overall situation worse.
Boomi’s own performance guidance emphasizes that process performance depends on infrastructure, runtime, JVM resources, network conditions, the process itself and connected systems.
Processing restored — and an operating model that holds
- Long-running and redundant executions were removed
- Critical integration flows were restored
- ERP transaction processing resumed
- The accumulated backlog began clearing
- Critical financial transactions were recovered
- Integration operations returned to a controlled processing state
- Concurrency management
- Runtime monitoring
- Execution monitoring
- Backlog detection
- Operational recovery procedures
- ERP connection management
- Proactive alerting
- Production incident troubleshooting
What the incident taught
- 01
More concurrency does not always mean more throughput
Parallel processing improves performance until a downstream system becomes the bottleneck. Beyond that point, more concurrency can reduce overall throughput.
- 02
Retry is not a recovery strategy by itself
Blindly retrying failed transactions can amplify an existing capacity problem. Stabilize the platform first, then reprocess in a controlled manner.
- 03
Monitor the runtime, not just the transaction
An integration can appear healthy while its runtime is gradually approaching memory, disk, execution or connection limits.
- 04
EDI reliability requires end-to-end observability
Successful EDI processing depends on multiple systems working together. Monitoring only the EDI document status is insufficient.
- 05
Production stability requires capacity-aware design
The correct architecture balances every factor in the chain, not just the speed of one process.
- The correct architecture balances
- Transaction volume
- Runtime capacity
- Connector concurrency
- Downstream system limits
- Recovery strategy
From incident to a more resilient platform
A structured integration engineering approach turned a potentially severe production incident into an opportunity to improve platform reliability. Rather than simply resolving individual failed EDI transactions, the team addressed the underlying operational model:
- Detect
- Diagnose
- Stabilize
- Recover
- Validate
- Prevent
The result was a more controlled and resilient integration environment capable of supporting high-volume EDI and ERP workloads while reducing the risk of recurring production degradation.
- Integration platform
- Dell Boomi / Boomi Enterprise Platform
- ERP
- NetSuite
- Integration patterns
- Scheduled processing, API/ERP integration, EDI transaction processing
- EDI transactions
- Orders, invoices, shipments, acknowledgements and related documents
- Operational capabilities
- Process monitoring, runtime monitoring, execution analysis, controlled reprocessing and alerting
This was not simply an EDI mapping problem.
It was a real-world example of how integration architecture, runtime capacity, transaction volume, downstream system governance and operational monitoring interact in a production environment — and of the value of combining Boomi development expertise with production operations and EDI domain knowledge to maintain reliability at scale.
AD Infosystem supports high-volume Boomi, EDI and ERP integration estates — from design and build through production operations, incident recovery and proactive monitoring.
- Boomi
- EDI
- NetSuite
- Integration
- Monitoring
- Managed support
Keep your integrations running at volume
If your integrations are slowing down, backing up or needing manual intervention to keep moving, AD Infosystem can help stabilize the platform, recover the backlog and put the monitoring in place to catch the next issue early.