SAP IDoc Backlog Clearance Time Calculator
When an interface stops for a few hours, IDocs pile up and everyone asks how long recovery will take. This calculator answers with simple arithmetic: backlog divided by the difference between what you can process and what keeps arriving.
Your numbers
Count of IDocs waiting, for example status 64 or 30
Measure from a recent run of RBDAPP01 or your dispatch job
Background work processes you can safely dedicate
Current inbound rate while you drain the backlog
Your results
Estimates assume steady throughput. Real rates change with IDoc size, locking on the same master records and database load. Measure a short test run before relying on the result. When the net rate is zero or negative, the hours output is shown as 0 and the backlog will not clear.
Hours to clear vs parallel jobs
Sweeps Parallel jobs from 4 to 20, holding your other inputs fixed.
IDoc throughput tuning review
Share your measured rates and lock waits and get suggestions for splitting and tuning.
Optional. The tool and every export work without this. No spam.
How to use the calculator
Count the backlog using WE02 or BD87 selected by status, or count rows in EDIDC for the message type and status. Measure throughput per job from a recent run, for example the IDocs processed per hour by a single instance of RBDAPP01 or the dispatch job. Set how many parallel jobs you can run without hurting dialog users, and enter the current inbound rate. The result is hours to clear. If the net drain rate is zero or negative, the backlog will not shrink and you must add capacity or pause the source.
- Measure throughput with a short test run
- Do not count dialog work processes as free capacity
- Update the inflow figure as the source recovers
The formula
Total capacity equals throughput per job times the number of parallel jobs. Net drain rate equals capacity minus the incoming rate. Hours to clear equals backlog divided by net drain rate. Utilisation equals inflow divided by capacity, and it shows how close you run to the limit. For example, 45,000 IDocs, 1,200 per job per hour, six jobs and 3,000 arriving per hour give capacity 7,200 and net 4,200, so about 10.7 hours. Doubling the jobs to twelve gives net 11,400 and about 3.9 hours.
Why more jobs does not always help
Throughput rarely scales linearly. Parallel jobs processing sales orders for the same customer or material contend for the same locks, and the database may become the limit. Splitting jobs by message type, partner or package size usually scales better than running many identical jobs. Watch for lock waits in SM12 and runtime in SM66 when you add jobs. If the chart flattens, you have found the real limit, and the next step is tuning the posting function module rather than adding workers.
- Split by partner or message type to reduce lock contention
- Use package size settings in the partner profile
- Watch database load while draining
Frequently Asked Questions
How do I measure IDocs processed per hour?
Run the processing job on a sample of a few hundred IDocs, note the runtime in SM37 and divide count by hours. Alternatively compare IDoc status change timestamps in EDIDS for a recent period.
What if the net drain rate is negative?
The backlog will grow even while you process. Increase capacity, reduce incoming volume by pausing or throttling the sender, or fix a slow posting step. The calculator shows 0 hours in this case, so check the net rate output.
Should I process in the foreground or background?
Use background jobs for large backlogs so you can control parallelism and avoid dialog timeouts. Foreground processing from BD87 is fine for small sets or single IDoc tests.
Does this apply to outbound IDocs?
Yes. For outbound, the rate is how fast jobs dispatch IDocs to the port, and the backlog is IDocs in status 30. Receiver capacity also limits the real result.
Netray can add monitoring that estimates backlog drain time continuously from your IDoc tables and warns before the queue becomes a business problem.
Related Tools
SAP Interface Volume and Storage Sizing Worksheet
An editable worksheet that turns messages per day, average size and retention into daily megabytes, peak hourly load and total storage.
SAPSAP IDoc Reprocessing Runbook Template
A fill-in runbook that tells support staff how to select, check and reprocess failed IDocs for one interface, with approvals and rollback notes.
SAPSAP IDoc Error Incident Ticket Template
A structured ticket for IDoc failures: control record details, status history, root cause, fix and prevention actions.
SAPSAP Interface Inventory Register Worksheet
An editable register of every interface touching SAP, with technology, owner, frequency and business criticality, ready to export to Excel.