SAP Interface Volume and Storage Sizing Worksheet
Interface volume drives work process load, middleware licensing and database growth. This worksheet turns the few numbers you already know into daily volume, peak rate and retained storage per interface.
| Interface | Message type | Messages per day | Average size (KB) | Peak factor | Retention (days) | MB per day | Peak msgs per hour | Retained MB | |
|---|---|---|---|---|---|---|---|---|---|
24.6094 | 525 | 2,214.84 | |||||||
7.0313 | 300 | 632.81 | |||||||
12.207 | 260 | 2,197.27 | |||||||
10.5469 | 150 | 316.41 | |||||||
17.5781 | 1,313 | 1,054.69 |
These are payload estimates. Database storage for IDocs is larger because each segment is stored with control and status data, so multiply by a factor measured in your own system. Check real table growth for EDIDC, EDID4 and EDIDS before committing to a number.
Measured interface volume report
Get actual hourly IDoc volumes extracted from your system for realistic sizing.
Optional. The tool and every export work without this. No spam.
How to use the worksheet
Enter one row per interface. Messages per day and average size can be taken from existing statistics: count IDocs per message type per day from EDIDC and take sizes from your middleware message monitor. For new interfaces, ask the business for order, shipment or invoice counts and use a similar existing message as a size proxy. The peak factor captures bursts, such as an EDI batch arriving at 06:00. Retention is how long you keep messages online before archiving. The sheet then computes daily megabytes, peak messages per hour and total retained megabytes.
- Use actual averages over a busy month, not a quiet one
- Set the peak factor from hourly counts if you have them
- Include test and retry traffic for noisy interfaces
The arithmetic behind each column
Megabytes per day is messages times average kilobytes divided by 1024. Peak messages per hour is messages per day divided by 24, multiplied by the peak factor. Retained megabytes is daily megabytes times retention days. The summary converts retained megabytes to gigabytes and back calculates the weighted average message size. These are simple payload figures. IDoc storage in the database carries additional overhead per segment and status record, so treat the output as a lower bound and calibrate with your own table growth.
Reading the results
Look first at the peak column. A workload that averages 400 messages per hour but peaks at 2,000 needs enough dialog or background work processes to absorb the burst, or a queue that drains in a reasonable time. Then look at retained storage: long retention on a high volume, low value interface is the usual place to save space by shortening retention or archiving earlier. Compare totals with the capacity of your middleware tenant or licence tier, since many have message count limits.
- Check peaks against available work processes
- Shorten retention on high volume, low value messages
- Revisit sizing before large customer onboarding
Frequently Asked Questions
How big is a typical IDoc?
It varies widely. A small status message can be a few hundred bytes, an ORDERS IDoc with many line items can reach tens of kilobytes and a large MATMAS with many views can be larger still. Measure your own traffic rather than relying on a general figure.
Which tables grow because of IDocs?
EDIDC holds control records, EDID4 holds data records and EDIDS holds status records. EDID4 is usually the largest. Archiving with object IDOC and deleting old records keeps them in check.
What is a good peak factor?
There is no universal value. Divide the busiest hour count by the average hourly count from a real month. Interfaces fed by batch EDI or file drops often have much higher factors than interactive ones.
Does this cover CPI or PO message limits?
It gives you daily message counts, which you can compare with your middleware licence or tenant limits. Check your contract and monitor for the exact metering rules.
Netray can extract real IDoc volumes by message type and hour from your system so the sizing uses measured peaks rather than estimates.
Related Tools
SAP IDoc Backlog Clearance Time Calculator
Work out how many hours a backlog of unprocessed IDocs will take to drain, based on throughput per job, parallel jobs and new IDocs still arriving.
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.
SAPSAP Integration Technical Specification Template
A technical specification document for one SAP interface: purpose, data flow, technology, error handling, security and monitoring.
SAPSAP IDoc Error Incident Ticket Template
A structured ticket for IDoc failures: control record details, status history, root cause, fix and prevention actions.