EWM Performance: Bug in TU / HU (DLV) Assignement

[Daniil]

A Small Typo That Caused Big Performance Issues in EWM

Once upon a time (October 2024), one of our clients encountered severe performance issues. Naturally, we investigated the problem, and I found it fascinating how a simple copy-paste mistake could have such a significant side effect. Unfortunately, I was too busy at the time to write about it immediately, but now I finally have the chance to share it.

The client experienced terrible performance when mass-processing delivery documents—specifically, during the mass assignment of multiple deliveries to a transportation unit (TU). The process was so slow that it resulted in a timeout short dump.

I generally find performance topics in EWM quite interesting because there's often room for a 10–50% improvement in execution time with minimal effort. This case was no exception: most of the effort was in understanding why the process was so slow. The fix itself was trivial—especially now, since SAP has already released a corresponding OSS Note.

During debugging, we noticed that the TU/Delivery was being read far more times than expected for this kind of operation.

Debugging the Issue

After further investigation, I discovered that a recently implemented cache in the class /SCWM/CL_SR_TUDLV wasn’t functioning as intended. This class is central for reading TU/Delivery assignments, and in our scenario, it was executing read operations for every single item—repeatedly, for all processed items.

The Bug

Here’s the issue:

Not so easy to spot, right? But with SAP’s correction, it becomes clearer:

The Fix

At the time we identified the problem, SAP had not yet released a fix, so we proceeded with a modification to correct the issue ourselves by replacing sy-subrc with sy-tabix.

A simple copy-paste error led to an incorrect index (lv_index_mtdlv), which caused the entire cache mechanism to fail. As a result, the cache table remained empty, preventing any caching from taking place.

Check If Your System Is Affected

If you want to verify whether this issue affects your system, you can check directly in the method /SCWM/CL_SR_TUDLV=>SETUP.

Alternatively, you can check if your system falls within the gap between the following OSS Notes:

2954670 ( Causing Side effect ) Version Components:

Spoiler

101 SAPK-10110INS4CORE
102 SAPK-10208INS4CORE
103 SAPK-10306INS4CORE
104 SAPK-10404INS4CORE
105 SAPK-10502INS4CORE
701 SAPK-70121INSCMEWM
702 SAPK-70226INSCMEWM
712 SAPK-71221INSCMEWM
900 SAPK-90024INSCMEWM
910 SAPK-91020INSCMEWM
920 SAPK-92016INSCMEWM
930 SAPK-93015INSCMEWM
940 SAPK-94014INSCMEWM
950 SAPK-95008INSCMEWM

and OSS 3516727 (Fixing Side effect) Version Components:

Spoiler

102 SAPK-10216INS4CORE
103 SAPK-10314INS4CORE
104 SAPK-10412INS4CORE
105 SAPK-10510INS4CORE
106 SAPK-10607INS4CORE
107 SAPK-10705INS4CORE
108 SAPK-10803INS4CORE
900 SAPK-90027INSCMEWM
930 SAPK-93022INSCMEWM
940 SAPK-94022INSCMEWM
950 SAPK-95016INSCMEWM