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


SRM.jpg


MM.png


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…  

  1. 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.


To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply