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 .
If you have tips to add don't hesitate to do so!
Performance Hints
General
Buffer your read accesses, especially in performance critical places, like the field check. Avoid database selects.
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.
Don't use SAP internal APIs carelessly, e.g. read only the data you need and not the complete business transaction.
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.
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.
Consider general performance guidelines (avoid nested loops, avoid database selects...).
More information: ABAP Programming and Performance Notes
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
Have a look at note 1162685 for general information about settings for CRM WebClient UI.
Have a look at note 1162605 on how to improve network performance when using CRM WebClient UI.
Have a look at note 1281896 for information on how to set the shared memory size when using CRM WebClient UI.
Extensibility
Don't put expensive coding into field checks.
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).
Don't use generated table extensions to process mass data.
For generated extensions you can think about switching the generic check off and implementing a specific check in order to gain performance.
Event Handler
Don't put item cross logic in immediately executed callbacks, use end of document processing instead.
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.
Only request the old and new values in an event handler callback if you really need this data.
Use CRMD_TRACE in order to find the right place for your event handler callback registration.
Reporting Framework
When searching for customer-specific fields consider to extend the appropriate index tables. Have a look at note 1527039
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
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.
Check out note 1269480 for performance issues related to configuration, VMC and IPC.
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
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.
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.
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.
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.
Appointments: Remove the unnecessary dates for your date profile, e.g if you are not using billing plans.
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
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.
Don't put expensive coding into the DO_PREPARE_OUTPUT method of your view controller since it is processed every roundtrip.
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.
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).
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).
Don't use component set ALL in UI components. This costs unnecessary memory.
.
