High volume of IDocs currently stuck in 'Pending' status

 Issue: Slow performance in delivery update batch job. 

Context: 1000 deliveries processed for pick/pack and PGI.

Impact: High volume of IDocs currently stuck in 'Pending' status.

 

Solution:
To address the slow processing of delivery updates and the backlog of IDocs for 1000 deliveries, we can look into several performance optimization strategies in SAP.

1. Enable Parallel Processing for IDocs (Recommended)

If your IDocs are stuck in status 64 (ready for transfer to application), the background job (transaction RBDAPP01) can be configured for parallel processing.

• How to do it: When scheduling the background job for RBDAPP01, check the "Parallel Processing" flag in the selection screen.
• Server Group: You will need to specify a server group (defined in transaction RZ12) to distribute the load across multiple application servers.
• Packet Size: Adjust the "Packet Size" (usually 20-50). Smaller packets allow for better distribution but more overhead; larger packets reduce overhead but can cause "bottlenecks" on a single process.

2. Optimize Collective Processing for Deliveries (VL06G / VL10CU)

If the bottleneck is the actual PGI/Delivery update (and not just the IDoc layer), you should verify the configuration for collective processing.

• Parallel Processing Profile: Go to transaction VL10CU (or via SPRO: Logistics Execution > Shipping > Deliveries > System Modifications > Specify Parallel Processing).
• Application: Create or update a profile for application V5 (Shipping). Here, you can define how many parallel processes the system is allowed to spawn during collective PGI.

3. IDoc "Inbound" Processing Mode

Check how your partner profile is set up in transaction WE20.

• Processing Selection: Ensure that the "Inbound Options" are set to "Trigger by background program" rather than "Trigger immediately."
• Why: "Trigger immediately" forces the system to process IDocs one by one as they arrive, which can lock the delivery table (LIKP/LIPS) and cause sequential wait times. Using a background job allows you to control the timing and use the parallel processing mentioned in Step 1.

4. Check for Database Locks (SM12)

With 1000 deliveries being updated simultaneously, you are likely to have significant contention for the LIKP (Delivery Header) and VBFA (Document Flow) tables.

• The Issue: If your IDocs are trying to update the same document or related documents (e.g., shipments), they will wait for each other.
• Resolution: Check transaction SM12 to see if there are many entries for table LIKP. If one large job is locking many deliveries, parallelizing the IDoc processing into smaller, distinct "packets" of delivery numbers will help reduce lock contention.

5. Review System Resources (SM50 / ST03N)

• SM50: Check if your background work processes (Type: BGD) or Update processes (Type: UPD) are all "Private" or "Full." If they are, parallel processing won't help because there are no available slots.
• ST03N: Look at the "Roll-in" and "Wait" times for your background jobs. High wait times indicate that the system is CPU-bound or I/O-bound.

Summary of Next Steps:

1. Stop the current single-threaded job if it is barely moving.
2. Split the IDocs into smaller batches.
3. Restart the processing using RBDAPP01 with the Parallel Processing flag enabled and a valid RZ12 Server Group.