# SAP IDoc Work Process Sizing Calculator

> Source: https://netray.co/tools/sap-idoc-processing-work-process-sizing-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Work out how many work processes inbound IDoc processing needs at peak, and what throughput your current setup can sustain.

## Category

sap

## Erp

SAP ECC / S/4HANA

## Audience

- SAP Basis admin
- SAP integration developer
- SAP performance engineer

## Tool

**Kind:** calculator

**Inputs:**

#### Average IDocs per hour

**Key:** idocs_per_hour

**Type:** number

**Default:** 20000

**Min:** 0

**Step:** 500

**Unit:** IDocs/h

#### Peak to average factor

**Key:** peak_factor

**Type:** number

**Default:** 2.5

**Min:** 1

**Step:** 0.1

**Help:** Month end, promotions and batch window releases concentrate load. Take it from a busy day in your own statistics.

#### Average processing time per IDoc

**Key:** avg_proc_sec

**Type:** number

**Default:** 1.5

**Min:** 0.05

**Step:** 0.05

**Unit:** sec

**Help:** Application posting time, not just IDoc layer time. Check STAD or ST03N for the inbound function module.

#### Target work process utilization

**Key:** target_util

**Type:** slider

**Default:** 60

**Min:** 30

**Max:** 90

**Step:** 5

**Unit:** %

**Help:** Leave headroom for queueing delay and other workloads.

#### Work processes you can dedicate

**Key:** available_wp

**Type:** number

**Default:** 8

**Min:** 1

**Step:** 1

**Unit:** WP

**Outputs:**

#### Peak arrival rate

**Key:** peak_per_sec

**Expr:** idocs_per_hour * peak_factor / 3600

**Format:** decimal

**Description:** IDocs per second at peak.

#### Work processes busy at peak

**Key:** busy_wp

**Expr:** peak_per_sec * avg_proc_sec

**Format:** decimal

**Description:** Offered load, by Little's law: arrival rate times service time.

#### Work processes needed at target utilization

**Key:** wp_needed

**Expr:** ceil(busy_wp / (target_util / 100))

**Format:** integer

**Primary:** true

#### Utilization with available work processes

**Key:** util_now

**Expr:** busy_wp / available_wp * 100

**Format:** percent

**Description:** Above 100 percent a backlog builds up during the peak.

#### Sustainable throughput at target utilization

**Key:** max_per_hour

**Expr:** available_wp * (target_util / 100) / avg_proc_sec * 3600

**Format:** integer

**Primary:** true

**Description:** IDocs per hour the available work processes can absorb.

#### Backlog growth at peak

**Key:** shortfall

**Expr:** max(0, idocs_per_hour * peak_factor - max_per_hour)

**Format:** integer

**Description:** IDocs per hour added to the backlog during the peak when demand exceeds capacity.

**Chart:**

#### Work processes needed vs average IDocs per hour

**Type:** line

**X:** idocs_per_hour

**From:** 1000

**To:** 100000

**Steps:** 40

**Series:**

- busy_wp
- wp_needed

**Disclaimer:** Queueing model for planning. Confirm with load tests, and remember that locking on the same master data object can limit useful parallelism.

## Content

**Intro:** When inbound IDocs pile up in status 64, the question is usually whether you need more work processes, a faster posting routine, or less lock contention. This calculator applies a simple load model so you can see which lever matters.

**Sections:**

#### How to use it

**Body:** Take average hourly volume from WE02 statistics, choose a peak factor from your busiest day, and enter the average time the inbound function module takes to post one IDoc. The tool returns the work processes busy at peak and the number you need at your chosen utilization target. Enter the work processes you can dedicate, for example the background processes assigned to parallel jobs of RBDAPP01, to see utilization and sustainable throughput.

#### The formula

**Body:** The model is Little's law. Offered load in busy work processes equals the arrival rate in IDocs per second multiplied by the service time in seconds. Dividing by the target utilization gives the required work processes, because a pool running near 100 percent queues badly. A target of 60 to 70 percent is a typical planning point. The model assumes IDocs are independent. If many IDocs update the same material, customer or account, row locks serialize them and extra work processes will not help.

#### Reading the output

**Body:** If utilization with available work processes is under your target, you have headroom. Between target and 100 percent, queues form at peak but drain afterwards. Above 100 percent the backlog grows during the peak and the backlog growth figure shows how fast it builds. Use the chart to see where your volume crosses the capacity of your current setup, and where an application-level improvement would help more than another process.

#### Common mistakes

**Body:** Teams often use the IDoc layer time instead of total posting time, which understates load. Others size for the daily average and miss the spike when several partners send files together. A third mistake is sizing dialog work processes for a job that runs in background. Check the actual processing path in your partner profile in WE20 and process code in WE42 before you decide where capacity belongs.

**Cta:** If your IDoc inbound is slow and you want a second pair of eyes on the posting routine and parallelization design, Netray can review it with your SAP team.

**Faq:**

#### What does status 64 mean?

**Answer:** Status 64 means the IDoc is ready to be passed to the application. If many sit there, inbound processing is not keeping up or the background job that processes them is not running or is too limited.

#### How do I get processing time per IDoc?

**Answer:** Use transaction STAD or workload statistics in ST03N for the inbound function module, or compare timestamps in the status records of a sample of IDocs in WE02.

#### Why not just add more work processes?

**Answer:** More processes help only when the work is parallelizable and the system has CPU and memory. Lock contention on shared master data, or a slow custom enhancement, will cap the gain.

#### Is the queue model exact?

**Answer:** No. It is a first-order planning model using averages. Real arrivals are bursty, so use a conservative utilization target and validate with a load test.

## Search terms

sap idoc performance sizing, idoc work process calculator, idoc throughput calculator, sap background work process sizing, idoc processing time, rbdapp01 parallel processing, sap inbound idoc capacity, sap integration capacity planning

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json