cancel
Showing results for 
Search instead for 
Did you mean: 

SRM_RECORD_GETELEMENTS performance

former_member182371
Active Contributor
0 Kudos

Hi,

im working on a report where there is a call to an RFC function module.
Within this RFC function module there is a call to fm SRM_RECORD_GETELEMENTS:

  CALL FUNCTION 'SRM_RECORD_GETELEMENTS'
    EXPORTING
      OBJECTID               = OBJECTID
      DOCUMENTCLASS          = DOCUMENTCLASS
    TABLES
      ELEMENT                = IT_ELEMENT
      ELEMENT_IDENTIFICATION = IT_ELEMENT_IDENTIFICATION
      ELEMENT_PROPERTIES     = IT_ELEMENT_PROPERTIES
      ELEMENT_VISIBILITY     = IT_ELEMENT_VISIBILITY
      ELEMENT_RELATIONS      = IT_ELEMENT_RELATIONS
    EXCEPTIONS
      NOT_AUTHORIZED         = 1
      PARAMETER_ERROR        = 2
      CONTAINER_NOT_FOUND    = 3
      INTERNAL_ERROR         = 4
      OTHERS                 = 5.

This fm call takes too long.


i´ve used ST12 transaction and the bottleneck is here:


INCLUDE      LSDCLF01
FORM            properties_get

        SELECT prop_name prop_index prop_value FROM (property_table)
          APPENDING CORRESPONDING FIELDS OF TABLE l_sdokphnmprs
          FOR ALL ENTRIES IN prop_names
          WHERE object_id EQ u_object_id-objid
            AND prop_name EQ prop_names-name.

where (property_table) is a Z table where the key fields are:


MANDT
OBJECT_ID
PROP_NAME
PROP_INDEX

is there a way to improve the performance of this fm call?
is there another way to get the same data but with better performance?

Best regards.

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member184455
Active Participant
0 Kudos

Hi Pablo,

What does it mean, "it takes too long"?. How long is this?

Why is the form routine PROPERTIES_GET a bottleneck?

Is it called too often (how many times?), or is the single execution too slow?

What is the content of the FOR ALL ENTRIES driver table PROP_NAMES at runtime?

The WHERE-clause of the SELECT-statement should be able to make use of the index, so it should not be too slow.

Best Regards,

Randolf

former_member182371
Active Contributor
0 Kudos

Hi Randolf,

the report does this call within a LOOP:

LOOP

CALL FUNCTION 'ZWHATEVER'DESTINATION L_DEST_RFC

ENDLOOP

Within this rfc fm 'ZWHATEVER' it does this:

CALL FUNCTION 'SRM_RECORD_GETELEMENTS'


LOOP AT IT_ELEMENT_IDENTIFICATION WHERE VALUE = 'ZXX'.

  CALL FUNCTION 'BAPI_RECORD_GETPROPERTIES'

ENDLOOP.


1.- What does it mean, "it takes too long"?. How long is this?
I´ve done ST12 several times for this report and if i order the results from highest to lowest values in Net(Microseconds) column
it always shows the rfc call ZWHATEVER on top. In percentage it is a 84% of the total execution time.

2.- Why is the form routine PROPERTIES_GET a bottleneck?
i´ve gone to the remote destination and executed the fm with ST05, ST12 AND SE30 and it points to that routine.

3.- Is it called too often (how many times?), or is the single execution too slow?
Obviously within a loop it is called too often but unfortunately the requirement is this way.

4.- What is the content of the FOR ALL ENTRIES driver table PROP_NAMES at runtime?
The content of internal table PROP_NAMES[] (for a single value of the fm, it is not the case of a complete LOOP):

1 SRM_DOCUMENT_ID
2 SRM_MODEL

1 SRM_CURRENT_ONLY
2 SRM_DOCUMENT_ID
3 SRM_DONT_ARCHIVE
4 SRM_EXPIRATION_DATE
5 SRM_IS_TRANSPORTED
6 SRM_LICENCE_UNIT
7 SRM_LOG_VERSION
8 SRM_MODEL
9 SRM_REC_RETENTION_PERIOD

1 SRM_ALT_DOC_ID
2 SRM_CURRENT_ONLY
3 SRM_DOCUMENT_ID
4 SRM_FILEPLAN_POS
5 SRM_KEYWORD
6 SRM_LOG_VERSION
7 SRM_REF_RULE
8 SRM_STATE
9 ZBM_ASSET

1 SRM_CURRENT_ONLY
2 SRM_DOCUMENT_ID
3 SRM_DONT_ARCHIVE
4 SRM_EXPIRATION_DATE
5 SRM_IS_TRANSPORTED
6 SRM_LICENCE_UNIT
7 SRM_LOG_VERSION
8 SRM_MODEL
9 SRM_REC_RETENTION_PERIOD

1 SRM_ALT_DOC_ID
2 SRM_CURRENT_ONLY
3 SRM_DOCUMENT_ID
4 SRM_FILEPLAN_POS
5 SRM_KEYWORD
6 SRM_LOG_VERSION
7 SRM_REF_RULE
8 SRM_STATE
9 ZBM_ASSET

MORE THAN 20 TIMES IT DOES THIS

1 SRM_CURRENT_ONLY
2 SRM_DOCUMENT_ID
3 SRM_DONT_ARCHIVE
4 SRM_EXPIRATION_DATE
5 SRM_IS_TRANSPORTED
6 SRM_LICENCE_UNIT
7 SRM_LOG_VERSION
8 SRM_MODEL
9 SRM_REC_RETENTION_PERIOD

1 SRM_ALT_DOC_ID
2 SRM_CURRENT_ONLY
3 SRM_DOCUMENT_ID
4 SRM_FILEPLAN_POS
5 SRM_KEYWORD
6 SRM_LOG_VERSION
7 SRM_REF_RULE
8 SRM_STATE
9 ZBM_ACTIVITY
10 ZBM_ASSET
11 ZBM_CENTER
12 ZBM_EMAIL_MANAGER
13 ZBM_EMPLOYEE_MANAGER
14 ZBM_DELIVERYDATE
15 ZBM_ENDAUTHOTIZATION
16 ZBM_BEGINDATE
17 ZBM_CONSTRUCTION
18 ZBM_VENDOR
19 ZBM_ANSWER_PO
20 ZBM_ANSWER_PO_VENDOR


5.- The WHERE-clause of the SELECT-statement should be able to make use of the index, so it should not be too slow
Theoretically yes and in ST12 i can see it is using the standard index.

Best regards.

former_member184455
Active Participant
0 Kudos

Hi Pablo,

How often is ZWHATEVER called?

RFC-calls should not be too fine granular, since there is quite some overhead involved.

Since 'SRM_RECORD_GETELEMENTS' is only capable to work on one OBJECTID I guess your RFC-call ZWHATEVER is also only reaching down one OBJECTID at a time?

This is not very efficient and instead you should think about reaching down a package of 50-100 OBJECTIDs instead.

Maybe you should also extend FAE driver table PROP_NAMES so that it contains OBJECTID-PROP_NAMES pairs which would allow to retrieve data for several OBJECTIDs in the SELECT.

Best Regards,

Randolf

former_member182371
Active Contributor
0 Kudos

Hi Randolf,

thanks for all.
I´ve tried to assign some points to your answers but the option seems not available.
The moment it´s available again i will assign them to you.

Best regards.