From: Wang, Jerry

Sent: Friday, July 11, 2014 9:38 AM

I have researched the related code and I have a quick solution which needs just 1 ~ 2 hours effort to add several additional lines of code in FM CRM_PR_DISTR_CHAIN_GET_ALL.

Background

Seen from the callstack of your ST22 screenshot, I can judge that all the materials are updated via Material validation API one by one during the download.
Inside the execution the organization description is retrieved from database table, see one example from our internal system, column PR_ORG_ID_DESC.

Since the FM will directly go to database table to retrieve the org description without buffer logic, so for customer use case, the DB table is queried again and again. For example we have 10000 materials and customer currently have 10000 sales org in their system, so totally CRM_PR_DISTR_CHAIN_DESCR_GET will be called 10000 * 10000 = 100 million times! This does not make sense. If we simply add the buffer logic inside the FM CRM_PR_DISTR_CHAIN_GET_ALL, we can reduce the number of DB call from 100 million times to only 1 time.

Minor side effect of this solution

For example it takes 2 hours for the material download to finish. During these 2 hours, if someone has changed the description of several sale org,
the downloaded material will still have the old description. The new change during that 2 hours will not be writtren to material. However, I don’t think this will be a big problem for our customer, as the org management is master data and should be stable.

Please kindly communicate my proposal and potential side effect to customer and check whether they could accept, then I can share my solution with IMS support colleague.

同事的分析

I agree that this should be rewritten right away. Although, I cannot find additional costs for this FM in my traces (FM may be buffered and bring no costs).

            Pls. check transaction SAT, there are 2 traces for the material:

            From my view, it is FM SET_ALL_ORG_UNITS, which spoils processing time.

From: Wang, Jerry

Sent: Friday, July 11, 2014 3:47 PM

Thank you for your SAT screenshot. Here below is the SAT from our internal system.

Here is yours:

We can see in customer system, subroutine MAP_DC_TO_ORG_FORMAT and FM CRM_PR_DISTR_CHAIN_MAP_TO_ORG took lots of time.
Let’s see the parameter for MAP_DC_TO_ORG_FORMAT:

Inside this function module, the input & output also does not contain any product specific information.
So I would assume for all the material, the same input would lead to the same output. Then I am considering to add the buffer logic inside this subroutine to avoid the repeated call on FM.

However, after I have looked into the code of CRM_PR_DISTR_CHAIN_MAP_TO_ORG, I could not find any expensive operation inside, if customer didn’t switch on ECM. This is strange. I will call you.

From: Wang, Jerry

Sent: Friday, July 11, 2014 2:04 PM

Thanks a lot for your credential. I have done investigation on DCR/100. Things are clear now.

From your SAT, we can know that although there is no expensive call inside MAP_DC_TO_ORG_FORMAT and FM CRM_PR_DISTR_CHAIN_MAP_TO_ORG,
but the number of calls on both are too much – more than 130 millions.

So the question for us is how to avoid such huge number of calls on both.

I still propose to add a buffer table to avoid the unnecessary LOOP calls:

Please let me know your feedback.

I have done a prototype in AG3/001 , function module:ZCRM_PR_DISTR_CHAIN_GET_ALL.

All my enhancement are wrapped with BUFFER_ENHANCEMENT_BEGIN and BUFFER_ENHANCEMENT_END.

Feel free to contact me if case help is needed.

要获取更多Jerry的原创文章，请关注公众号"汪子熙":