Skip to end of metadata
Go to start of metadata

Introduction

This page is intended to collect hints on what you can do in order to avoid performance problems when implementing CRM. Important hints are indicated by this icon (thumbs up) .

If you have tips to add don't hesitate to do so!

Performance Hints

General

(plus)

Buffer your read accesses, especially in performance critical places, like the field check. Avoid database selects.

 

(plus)

Try to put everything in one CRM_ORDER_MAINTAIN call in order to avoid unnecessary overhead. This is also true when editing several documents, then these should be placed into one call.

 

(minus)

Don't use SAP internal APIs carelessly, e.g. read only the data you need and not the complete business transaction.

 

(plus)

Always keep performance in mind, especially when implementing coding in frequently called coding. This also includes to determine beforehand when this coding will be called.

 

(minus)

Don't forget to use the CRM_ORDER_INITIALIZE after maintaining business transactions, e.g. during migration or other reports in order to free the memory in the buffer.

 

(plus)

Consider general performance guidelines (avoid nested loops, avoid database selects...).
More information: ABAP Programming and Performance Notes

 

(minus)

Don't use the function module CRM_ORDERADM_I_READ_OB with header guid when processing on item level (e.g. Eventcallbacks on item level).
This is very crucial for performance especially when processing a large number of items.
Instead use function module CRM_ORDERADM_I_STRUCT_READ_OB in order just to read the hierarchy for this item.

 

System Settings

(plus)

Have a look at note 1162685 for general information about settings for CRM WebClient UI.

(thumbs up)

(plus)

Have a look at note 1162605 on how to improve network performance when using CRM WebClient UI.

 

(plus)

Have a look at note 1281896 for information on how to set the shared memory size when using CRM WebClient UI.

 

Extensibility

(minus)

Don't put expensive coding into field checks.

(thumbs up)

(plus)

Do runtime measurements for enhancements (consider the whole runtime including APIs that are called, it is not only the additional coding that causes performance problems, but the problems mights also result from an inappropriate use of APIs).

 

(minus)

Don't use generated table extensions to process mass data.

 

(plus)

For generated extensions you can think about switching the generic check off and implementing a specific check in order to gain performance.

 

Event Handler 

(minus)

Don't put item cross logic in immediately executed callbacks, use end of document processing instead.

(thumbs up)

(plus)

Always keep the concept of secondary transaction categories ("Nebenbus") in your mind. Make sure that newly registered EC function modules only run for the desired objects.

 

(plus)

Only request the old and new values in an event handler callback if you really need this data.

 

(plus)

Use CRMD_TRACE in order to find the right place for your event handler callback registration.

 

Reporting Framework

(plus)

When searching for customer-specific fields consider to extend the appropriate index tables. Have a look at note 1527039

 

(plus)

Consider that the authorization is already part of the selection. Have a close look at the effects of the selected authority checks on the database selects.

 

 

 h3. Pricing, VMC, Product Configuration

(plus)

Reduce the complexity of your pricing procedure as much as possible: question group conditions, check for unused condition types, restrict number of accesses in the pricing procedure, use suitable requirements to suppress conditions, which are not required in a process.

(thumbs up)

(plus)

Check out note 1269480 for performance issues related to configuration, VMC and IPC.

 

(plus)

Check note 1005457 for VMC Settings (Java Heap).

 

(plus)

VMC Logging should only be active for ERROR.

 

(minus)

Basic rules for implementations of CRM IPC pricing formulas:
- Do not implement table accesses. Custom build table reads will not be buffered by IPC. Instead implement in pricing prepare step on CRM server side.
- Avoid runtime errors (NullPointerExceptions) in user exit implementations
- Avoid loops in user exits

 

Customizing of CRM Functions

(plus)

Actions: Keep the conditions as simple as possible, irrespective if it is a scheduling or a starting condition. This keeps the action determination and the selection report fast.

(thumbs up)

(plus)

Actions: For complex plan and start conditions use the option to implement the respective BAdI EVAL_SCHEDCOND_PPF or EVAL_STARTCOND_PPF to get a higher performance than by using the workflow based conditions. Workflow based conditions need to be interpreted with a parser and the data is accessed generically which can become critical for performance.

(thumbs up)

(plus)

Actions: Use different PPF profiles for different business scenarios. This keeps the runtime fast, since there are fewer conditions to check and less configured action definitions to load.

 

(plus)

Actions: Status checks should be modelled as scheduling conditions and not as starting conditions. Actions with a fulfilled scheduling condition are persisted and exist until the application initiates their deletion. In some cases, this can lead to unnecessary long runs of the PPF selection report.
A start condition should only cause a delayed execution of the action. Any other part of the condition must be part of the scheduling condition.

 

(plus)

Appointments: Remove the unnecessary dates for your date profile, e.g if you are not using billing plans.

 

(plus)

Change Documents: Check if it is possible to deactivate change documents for a business transaction  (they can be deactivated in the transaction type customizing, flag 'No Change Documents').

 

Web Client UI Framework

(minus)

Only put the views/assignment blocks on the UI that are necessary. If views/assignment blocks are not needed very often use the lazy load mode.

(thumbs up)

(minus)

Don't put expensive coding into the DO_PREPARE_OUTPUT method of your view controller since it is processed every roundtrip.

(thumbs up)

(minus)

Don't just bypass the BOL buffer in case the data in the buffer is not up to date. Rather search for the reason for this inconsistency and correct the issue there.

 

(minus)

Don't use complex binding (the update of one node, will then lead to an update of several other nodes and/or a chain of other nodes).

 

(plus)

When registering for an event, don't forget to deregister again (otherwise the handler will still be called, even if it is not necessary anymore).

 

(minus)

Don't use component set ALL in UI components. This costs unnecessary memory.

 


Further Links

  •  
  • No labels

3 Comments

  1. Unknown User (ilqp4l3)

    Hello Anne Fish ,

    Very Nice points to not down while coding :-). Also I can think of the following points.

    1)      Don’t overload the component controller by adding the context nodes which are not used in the cross component data transfer.  As component controller will be called always, use of custom controller must be used when sharing data between views of same component.

    2)      Avoid over Coding in DO_PREPARE_OUTPUT as it will affects the performance some times.

    3)      It is also advisable to get the Edibility/Non Edibility of the field from GENIL instead of doing it in GET_I_XXXX if there are more conditions / Authorizations to check for a particular field.

    4)      DO_INIT_CONTEXT should be utilized for initializing any values as this method gets loaded first when a view is loaded. I often see these things done in do_prepare_output / .HTM page etc ..

    Thanks and regards,

    Nikhil Kulkarni

  2. Former Member

    helped a lot

  3. Nice document, it would help any CRM Developer...thanks for sharing.