We were once handling a high profile Customer who implemented SRM Central Contracts and replicated them to ECC. They faced many issues related to data consistency between the 2 systems particularly in the MM-Services module. This is one such case where the added services in SRM went missing in ECC.
Basically when you create a contract and change it by adding an outline and some services under it from SRM , the services under the new outline went missing. Initially it started off that only bigger contracts with many outlines were causing the issue but also for very simple structures also this occured like,
Main Outline
- First Outline ==> with services
- Second Outline
-->Sub outline
We could not reproduce by blocking the queue and re-running it (or) via SPROXY debugging, it happened when the outbound and inbound queue processing was really fast i.e., when we execute the end-end process from SRM.
But luckily we found a pattern and we tried to re-create it whilr debugging and it indeed reproduced the same issue.
Root Cause
In all working scenarios in table ESLL , SUB_PACKNOs are generated in ascending order,
PACKNO INTROW EXTROW DEL SRVPOS RANG EXTGROUP PACKAGE SUB_PACKNO
0031843468 0000000001 0000000000 0 0000000000
0031843468 0000000002 0000000001 1 13.13 X 0031843469
0031843468 0000000011 0000000001 1 90000 0000000000
0031843468 0000000012 0000000011 2 70000 X 0031843475 >> sub_packno is generated in ascending…
0031843469 0000000007 0000000010 13019828 0 0000000000
0031843469 0000000008 0000000020 13019829 0 0000000000
0031843469 0000000009 0000000030 13019830 0 0000000000
0031843469 0000000010 0000000040 13019831 0 0000000000
0031843475 0000000013 0000000010 13019742 0 0000000000
In all NOT working cases , SUB_PACKNO were generated in descending order…
- Table: ESLL
PACKNO INTROW EXTROW SRVPOS EXTGROUP PACKAGE SUB_PACKNO SRVMAPKEY
0031844534 0000000001 0000000000 0000000000 0000000001
0031844534 0000000002 0000000001 13.13 X 0031844535 0000000137
0031844534 0000000011 0000000001 98765 X 0031844499 0000000142 > sub_packno in descending order
0031844535 0000000007 0000000010 000000000013019828 0000000000 0000000138
0031844535 0000000008 0000000020 000000000013019829 0000000000 0000000139
0031844535 0000000009 0000000030 000000000013019830 0000000000 0000000140
0031844535 0000000010 0000000040 000000000013019831 0000000000 0000000141
Debugging Analysis:
After create,
PACKNO INTROW EXTROW DEL SRVPOS RANG EXTGROUP PACKAGE SUB_PACKNO
0031844634 0000000001 0000000000 0 0000000000
0031844634 0000000002 0000000001 1 13.13 X 0031844635
0031844635 0000000007 0000000010 000000000013019828 0 0000000000
0031844635 0000000008 0000000020 000000000013019829 0 0000000000
0031844635 0000000009 0000000030 000000000013019830 0 0000000000
0031844635 0000000010 0000000040 000000000013019831 0 0000000000
During change New PACKNO is generated from below FUNCTION,
SAPLSNR3 FUNCTION NUMBER_GET_NEXT
CL_PUR_PC_MAPPING_XI_TO_ERP===CP METHOD MAP_PC_ITEM_XI_2_ERP_WITH_HIER
CL_SE_PUR_PCSRMRPLCTNRQ=======CP METHOD MAPPING_IN
CL_SE_PUR_PCSRMRPLCTNRQ=======CP METHOD PROCESS_IN
CL_SE_PUR_PCSRMRPLCTNRQ=======CP METHOD EXECUTE
CL_PUR_PURGCONTRTSRMRPLCTNRQ==CP METHOD II_PUR_PURGCONTRTSRMRPLCTNRQ~PURCHASING_CONTRACT_SRMREPLICA
CL_PROXY_INBOUND_AGENT========CP METHOD IF_PROXY_INBOUND_AGENT~EXECUTE
Since I suspected that if the generated number from the FM is not in ascending order from the previously generated service package then the following thing happens, I changed the number to ‘0031844633’, one number prior to the first outline '0031844634.'.
So the programs came to the below flow,
SAPLMLSP FORM UPDATE_IX_CONTR
SAPLMLSP FORM ROW_IN_CONTR
SAPLMLSP FUNCTION MS_CHANGE_SERVICE_PACKAGE_CONT
SAPL2014 METHOD CHANGE_PACKAGE
SAPL2014 METHOD IF_BAPI_MEOUT~SET_ATTRIBUTE
SAPL2014 METHOD POST_PROCESS
SAPL2014 METHOD SET_OBJECT_ATTRIBUTES
SAPL2014 METHOD PROCESS
SAPL2014 METHOD IF_PURCHASE_OUT_BAPI~PROCESS
There is a READ table with Binary search
READ TABLE ix_esll WITH KEY packno = esll-packno
introw = esll-introw
BINARY SEARCH.
Internal table ix_esll[]
0031844634|0000000001|000000000< |0031844635 |U |
0031844634|0000000000|000000000< |0000000000 | |
0031844634|0000000001|000000000< |0031844635 |U |
0031844634|0000000001|000000001< |0031844633 |I |
0031844635|0000000010|000000000<000000000013019828|0000000000 | |
0031844635|0000000020|000000000<000000000013019829|0000000000 | |
0031844635|0000000030|000000000<000000000013019830|0000000000 | |
0031844635|0000000040|000000001<000000000013019831|0000000000 | |
0031844633|0000000010|000000001<000000000013014792|0000000000 |I |
Since IX_ESLL is not in sorted order the read table failed with SY-SUBRC = 4. But since there was no SY-SUBRC check, the next statement where ESLL held the new service line Information got overwritten to IX_ESLL structure
MOVE-CORRESPONDING esll TO ix_esll.
MANDT C 3 100
PACKNO N 10 0031844633
INTROW N 10 0000000012
EXTROW N 10 0000000010
DEL C 1
SRVPOS C 18 000000000013014792
, and later the content is updated into IX_ESLL internal table but the KZ flag is ‘U’ because it has the flag of the previous read outline.
We had a discussion with Development and came up with a logic in the calling subroutine and created note 2110200 for this rare case.
Hope the above information would be useful in such kind of weird cases where blocking queues would not reproduce the issue but only when queue processing is very fast.
- SAP Managed Tags:
