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.

View Entire Topic
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.