Accepted Solutions (1)
Hi Koushik,
The below recommendations are assuming the business rules themselves are all ok, as you have stated.
The business rules might not always be updating the P table, due to the way the code flows, specifically the way it is doing it's block processing of the datasets. These recommendations focus on the way the data in the internal tables is being processed (Loops, Ladders, Sorts, Reads, etc).
Action Recommended 1: Update the sort it_42_22 statement to be the exact four fields used in the BINARY SEARCH.
sort it_42_22 by kunnr spart vkorg vtweg.
Tip: Where a READ TABLE ... BINARY SEARCH is done, the preceding SORT statement must be an exact match (all fields listed & in order) of the WITH KEY parameters listed. If this is not honoured, then the BINARCH SEARCH results will occasionally return an incorrect answer in sy-subrc. It is not because the data wasn't there but because the data was not sorted by following the READ TABLE ... WITH KEY ... BINARY SEARCH expectations.
Action Recommended 2: Remove the sort it_42_22 by msnum DESCENDING statement.
Tip: This statement appears to be completely redundant. Any benefit obtained by the sorted order is immediately overridden/wiped out/never used by the sort it_42_22 by statement 3 lines below it.
Action Recommended 3: Change the continue statement to be a break statement.
Tip: The nested loop (loop at it_42_22) seems to be written to process only a single master data value of 0CUST_SALES (its full key of 0CUST_SALES, 0DIVISION, 0SALES_ORG, 0DISTR_CHAN) as a time through each iteration of the outer loop (loop at result_package). This implies that when the business rules have finished doing their processing for a single master data value of 0CUST_SALES (because it was sorted properly) then the nested loop is only wasting CPU by iterating to the end of the nested loop (loop at it_42_22) internal table. I recommend using a break statement, instead of continue statement, as we want the loop processing to continue iterating through the outer loop.
Action Recommended 4: Have an open discussion with you're fellow ABAPers in the team, specifically discussing the processing logic issue of dataset granularity, fundamentally embedded in the use of a BINARY SEARCH versus the actual records in the it_42_22 internal table.
Consideration 4.1: The internal table has many records in it that have the same primary key of the read table ... with key kunnr spart vkorg vtweg. Which is why it_sort_2242 is being used to capture the smaller datasets of that same key.
Consideration 4.2: A binary search is not guaranteed to return the very first record in the sorted order of the it_42_22 table. A binary search only guarantees that it found at least one matching record, not the 'first one of the sorted internal table'.
Consideration 4.3: Add a small loop to traverse/iterate backwards to meet the condition ... "lv_index = the first matching record in the sorted it_42_22 table".
Tip: While it might be tempting to ignore this subtle distinction of 'a matching record' versus 'the first record'; it is exactly what drives your original question of why sometimes it doesn't work, but most of the time it does. Given that most organisations have a decent sized master data list in 0CUST_SALES (+1 million records), I strongly recommend you keep the current BINARY SEARCH technique with the nested ladder (loop at it_42_22) and just add a new small piece of code to traverse/iterate backwards to identify the true 'first record in the small subset'.
This is general advice only; please ensure you debug all changes applied in the target system to ensure there are no unintended consequences.
Hope this helps.
Kind regards,
john.lang.
Answers (1)
| User | Count |
|---|---|
| 78 | |
| 11 | |
| 9 | |
| 8 | |
| 7 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.