Are there known performance issues with BAPI_CONTRACT_CREATEFROMDATA related to SD_COND_ACCESS?

[BaerbelWinkler]

Hi All!

We are currently investigating why the creation of contracts with BAPI_CONTRACT_CREATEFROMDATA is causing extreme performance issues. The BAPI gets triggered from an outside system via a Webservice and we've been testing the creation of one contract with 46 line items where the contract runs for 5 years. Each item comes with a special price condition which - as far as I understand - overwrites whatever else the condition schema would provide, so should be fairly straightforward.

Because the process takes extremly long (we are talking hours for just this one contract!) I was able to grab some snapshots of what is happening in the background via SAT executed in a parallel session. I also kept an eye on the SCMOND data captured in the test system while the process was running. The latter provided some interesting input related to the number of times some routines get called - and the numbers look weird to say the least:

(1) - the 8 about matches the times the webservice process got triggered during testing with only one of the executions progressing (the others had some data issues which needed to be fixed first)

(2) - the 46 could be related to the number of line items (or is just a big coincidence!)

(3) - the 32+ million times both SD_COND_ACCESS and SD_COND_GET_CALL_MODE look completely out of place. Why would anything trigger this many calls to function modules to set up one contract?

The very high number of calls to SD_COND_ACCESS is also visible in SAT-snapshots where I had it collect data for +/- 2 minutes a couple of times:

I didn't pay too much attention to the overall runtime but after 3 to 4 hours a contract with 46 line items had finally made an appearance in the system with the creation time fitting the time we had started the testing.

We had also saved the importing parameters for BAPI_CONTRACT_CREATEFROMDATA and I used that to rerun the process via SE37 to take a closer look and debug the process. This again showed the regular calls to SD_COND_ACCESS but also that internal table KOMT2 kept growing and growing.

At one point it had 92,278 entries:

A short while later this had grown to 101610 lines:

So, what I'm wondering is if anybody else has run into comparable issues performance-wise with BAPI_CONTRACT_CREATEFROMDATA and SD_COND_ACCESS? Searching OSS or SAP Community didn't produce anything thus far. It would already help to at least know if the above is expected behaviour or really as weird as I think it is. Any pointers what else to check are obviously appreciated!

We are on NW 7.50 EHP8 SP22.

Thanks much and cheers

Bärbel

[FredericGirod]

Hi 8b889d0e8e6f4ed39f6c58e35664518f, did you try to stop during the call of the FM SD_COND_ACCESS ? To check the call stack. Maybe it is called directly from user exit.

Did you check also, if SD_COND_ACCESS make some change and it trigger an action on an user-exit, and this action for the SD_COND_ACCESS to run again ......

[BaerbelWinkler]

frdric.girod

Thanks for your quick reply, Fred!

Yes, I did keep at least a bit of an eye on the call stack and we are mostly in SAP-standard territory with no direct calls to SD_COND_ACCESS from a user-exit or enhancement. One call to the FM is from here:

And the call stack looks pretty "clean":

In the overall scheme, there are obviously activities in our SAPMV45A-enhancement where Z-tables and ZZ-form routines are called, but I haven't (yet) spotted a direct link to SD_COND_ACCESS.

[FredericGirod]

in your trace, looks like a SAT trace, did you check if there are other codes called with a great number of time like SD_COND_ACCESS ?

Could be also strange customizing, remember: Never trust functional team !

[BaerbelWinkler]

The screenshots are from SCMOND and snapshots from SAT to see how often various routines are called. The SCMOND data should be fairly "clean" as there weren't many other processes running in the system when we did the testing. When I restrict the SCMOND selection to entries related to our incoming webservice I see this with two extreme outliers SD_COND_ACCESS and SD_COND_GET_CALL_MODE:

Update: Somebody seems to have triggered the webservice yesterday for a smaller contract with just 3 items (possibly in preparation for another test session we have later today) and the discrepancy for the number of calls is visible there as well, just with lower numbers:

There is one Z-Function Module but if I search for its name in the corresponding SAT-snapshots, I don't find any hits, so it doesn't seem to be directly related to the SD_COND modules. And the IWOL-function module gets called from the Z-FM.

[SimoneMilesi]

Hello 8b889d0e8e6f4ed39f6c58e35664518f !

A couple of years ago i had a similar issue working with contracts and i remember i solved with some OSS notes.
Scratching the barrel, i found in my notes these 2 oss notes, but i do not remember why i saved them (they aren't even so recent)

https://launchpad.support.sap.com/#/notes/3043096
https://launchpad.support.sap.com/#/notes/2953640
Another one i found during a (really quick) search is

https://launchpad.support.sap.com/#/notes/1941199 but it's 4 years old...

[BaerbelWinkler]

simone.milesi

Hi Simone,

thanks for the list of OSS-Notes to check! As I'm not really familiar with our overall condition setup and handling, I'll pass these on to people more knowledgeable than me in this area.

I see that we don't yet have an implementation for BADI_SD_COND_ACCESS_BUFFER mentioned in 1941199 so that might be something to explore further.

Cheers

Bärbel

[BaerbelWinkler]

Here is a little update from today's testing:

Another contract with 46 items took about 90 minutes to process.

A contract with 3 items billible just once (IIRC) needed just a few minutes.

Looking at SAT still showed a disproportionally large number of calls to e.g. SD_COND_ACCESS.

[BaerbelWinkler]

We are going to give this another try later today, So I'm bumbing this question to see if anybody has some additional ideas of what we could be on the look out for while the process is running.

Thanks much and Cheers

Bärbel

[BaerbelWinkler]

An update: after taking a break from this while I was on vacation, I picked the issue up again last week still trying to get a better handle on what's happening. In the meantime we have an incident in process by SAP Support but it's not clear yet, how far we'll get with this because of the interwoven custom-code used in the overall processing of the contracts.

The process seems to happen in two steps:

1. The contract gets created in VBAK and VBAP and receives its order number (VBELN). The billing plan (FPLA) and details about the planned billing dates are created (FPLT). This happens fairly quickly.
2. Afterwards, the billing plan gets updated and this looks a bit weird and takes about 3 minutes per billing plan if that plan is for 13 months for each of 45 items. From the initial creation, there is a "block" of 13 items numbered 000001 to 000013 in FPLTR (#1 in the screenshot below). Once the update is complete, there are 13 new line items for the same billing plan numbered 000014 to 000026 (#2 in the screenshot):
   

   

These changes in FPLT are reflected in CDHDR/CDPOS where the initial 13 entries get deleted and 13 new entries get inserted:

I'd be interested to know if this behaviour is expected, i.e. if others see that in their systems as well?

Thanks much and cheers

Bärbel

[BaerbelWinkler]

Here is an update of what happened since August:

• Opened an OSS-incident and got some additional pointers from SAP
• we followed a suggestion to run the program CONDITION_PRESTEP_ANALYZE for optimizing the access sequences in our most used pricing and discount conditions (the program comes with pretty good documentation). This caused a drastic time reduction down to 10 minutes for a service contract with 46 items and a validity of a year with monthly billing.
• A change was also applied to set the Pricing Type in table TFPLT to space. This made the process go a lot faster and one item in a contract then took just about 3 seconds to process compared to up to 3 minutes earlier.
• At least part of the issue is related to our own Z-code and that we are working with fairly complex condition sequences
• Getting some consulting support from SAP also helped to identify an issue, where our code called standard function modules within a loop for each line item which should just be called once outside of the loop. Correcting this, also improved the performance.
• Next activity will be to try and streamline the access sequence of the condition schema used which is outside of ABAP-development.

Hope some of these pointers will help others running into comparable issues with contract creation!

[jeroen_cosijnse]

Hello Baerbel,

We face some huge problems with Pricing routine - SD_COND_ACCESS - it is called in some loops  for Salary components - about 1200 times which takes about 90 seconds. But the strange thing is we recently moved to S/4 and all transactions like DP91 / Proforma / VF04 / VK12  are much slower as on. ECC. Do you have any experience with this kind of slower behaviour on S/4 compared to ECC ?

Regards Jeroen Cosijnse

[Lakshmipathi]

Hi @jeroen_cosijnse 

The member created this discussion way back in 2022 and you inserted your query in such an old post.  Please create a new discussion by citing this thread as an additional information so that members will assist you.

[BaerbelWinkler]

Hi Jeroen,

I'm not (yet) able to answer your question because we are only now starting our move to S/4HANA. But thanks for raising the issue as this will most likely be something we'll also have to take into account.

Cheers

Bärbel