Is there an option to improve performance of sales order selection with RV_SALES_DOCUMENT_VIEW_3?

[BaerbelWinkler]

Hi All!

We have a regularly used Z-program which users run - often as a batch job - to select and analyze sales orders. As one of the first activities done in the program, the function module RV_SALES_DOCUMENT_VIEW_3 gets called with - unfortunately - very little restrictions apart from a fairly long date range often spanning multiple months and more than a year. The main purpose seems to be to identify not yet completed sales orders "across board" to then reshuffle things as needed.

Searching for the FM's name didn't really net any results pointing to general performance issues. What I however noticed during fairly extensive debugging and peeking under the hood with transaction SAT is, that the FM apparently first reads everything and only afterwards decides which items to keep. Almost always when I execute SAT in a parallel session for a short time while the program is running, the resulting hit lists looks like this:

Here is the corresponding snippet of code from where these routines are called:

From what I was able to see during debugging, it looks as if the status of the selected orders is only checked after this quite elaborate processing involving several additional data retrievals, including some done in Z-enhancements to get custom fields. This - to me - indicates that a lot of processing power esp. for older orders is done in vain as the further back an order was created the more likely it is already closed.

Does anybody have some feedback about the number of items internal table vbak_tab ideally shouldn't exceed for the function module to work properly? I'm fairly certain that the way this is utilized is not necessarily the intended usage but I a) didn't yet find anything definitive or promising and b) am wondering if there are alternatives somebody has tried?

And yes, I know that the FM is "not released" and what that means as far as support goes!

I guess what I'm looking for with this question are some ideas of what we could try to improve the overall performance, esp. as I'm not convinved that running it multiple times for shorter time ranges will really help with the gross time for the whole job.

We are on SAP NW 7.50 EHP8 and HANA DB

Any thoughts, ideas and/or feedback?

Thanks much and cheers

Bärbel

[maulik · Accepted solution]

If you are up to it, try adding a sort on lvbkd in one of the enhancement spots after line 463.

The read table with binary search requires a sort and it's most likely missing it.

sort lvbkd by vbeln posnr

[BaerbelWinkler · Accepted solution]

Thanks for the tip, Maulik!

I'll check in debugging if the READs on LVBKD in our own enhancement code may be part of the issue.

[BaerbelWinkler · Accepted solution]

maulik25

I checked and the SELECT from VBKD in the standard code looks fine as it uses "ORDER BY PRIMARY KEY":

Subsequent READs from the table in the standard code use BINARY SEARCH, but one of the READs in our Z-enhancement doesn't yet. And it's exactly that read which - according to SAT data is the main performance issue in this part of the code, namely almost 87%. As soon as I get the chance, I'll update that READ statement to see if it has any effect.

Could you please convert your comment to a proper answer? It may well lead to at least alleviating the issues we have with this process.

Thanks and Cheers

Bärbel

[maulik · Accepted solution]

Order by primary key will only bring the data from VBKD in a sorted order and store it in a table. It does not convert this table LVBKD to a sorted table.

When you explicitly sort the table using the sort command the compiler builds an index for the binary search to work during the execution of READ command.

Without the execution of the sort command, the binary search will not work.

I hope this explains the difference. Try it and drop a note whether it made a difference.

[BaerbelWinkler · Accepted solution]

maulik25

Considering that SAP's code uses the BINARY SEARCH addition in their own code without a preceeding SORT statement, it works and it will not hurt to just add this in our own code.

I just tweaked the FM's execution a bit to make it also read the internal table LVBKD with the BINARY SEARCH option to directly compare their and our access to the itab. The difference couldn't be much clearer of which works better:

Our READ is the first line which gets executed twice for each time SAP's statement is accessed. And SAP's READ happens just a bit earlier than ours:

FORM move_vbak_tab_to_lvbmtv.
.....
  IF bstkd_flag = 'X'.
    CLEAR lvbkd.
    READ TABLE lvbkd WITH KEY vbeln = vbak_tab-vbeln
                              posnr = 0
                              BINARY SEARCH.
    IF sy-subrc = 0.
      lvbmtv-kursk = lvbkd-kursk.
      lvbmtv-prsdt = lvbkd-prsdt.
      IF NOT lvbkd-bstkd IS INITIAL.
        lvbmtv-bstkd = lvbkd-bstkd.
      ELSE.
        lvbmtv-bstkd = lvbmtv-bstnk.
      ENDIF.
    ENDIF.
  ENDIF.

  MOVE-CORRESPONDING vbak_tab TO lvbak.
  APPEND lvbak.
  PERFORM move_userfields USING 'VBAP'. 
  PERFORM move_userfields USING 'VBAK'.

ENDFORM.                               " MOVE_VBAK_TAB_TO_LVBMTV

Our READ to LVBKD happens within the MOVE_USERFIELDS logic where the Z-enhancement is invoked.

[BaerbelWinkler · Accepted solution]

maulik25

Hi Maulik,

adding BINARY SEARCH to our READ statement for internal table LVBKD in the enhancement "did the trick" and brought the runtime down considerably. While the READ statement had taken up between 60 and 70 percent of the measured runtime in SAT before the code change it went down to below 1 percent afterwards!

Could you please convert your comment mentioning "BINARY SEARCH" to an asnwer so that I can then accept it? It definitely was the trigger leading me to resolve this issue!

Thanks much and Cheers

Bärbel

[Lakshmipathi]

If the requirement is to pull out the open sale orders from that customized report and you feel that it is having performance issue, you can consider table vbbe where the coding can validate OMENG which should be greater than or equal to 1. Not sure, this validation is there currently.

[Lakshmipathi]

In va05, you can add lot of fields like Partner Functions, Plant etc., with the standard configuration itself

[BaerbelWinkler]

Yes, I'm aware of that and we already use that option - enhancement(s) related to that are executed from the function module as mentioned in my question. VA05 just doesn't do everything our users expect to be able to select and get reported which is why the Z-program was developed 10 years ago as far as I know or guess.

[Lakshmipathi]

The main purpose seems to be to identify not yet completed sales orders "across board"

Did you execute va05 where you have the option to select "Open Orders" ?

[BaerbelWinkler]

I don't know the history of the Z-report but I "suspect" that it was created because VA05 didn't allow all the select options the users wanted to do and/or didn't retrieve all the data they wanted to get in one go. VA05 may however have served as a starting point of sorts.