Introduction
This page is intended to collect considerations that can be used to avoid performance issues in the SAP CRM implementation, and important items are identified by the icon.
If you have other tricks you want to talk about, don't hesitate!
Performance Considerations General
|
Cache read class Access, especially where performance is critical, such as field checking, to avoid database queries. |
|
|
Try to put everything in the same crm_order_maintain call to avoid unnecessary overhead. The same is true when editing multiple documents, and needs to be replaced with a call. |
|
|
Don't use SAP internal APIs indefinitely, for example, to read only the data you need, not the entire business. |
|
|
Always take performance into heart, especially when implementing code that is often called. This also includes scenarios in which the good code is expected to be called beforehand. |
|
|
After you maintain your business, don't forget to use the Crm_order_initialize function to free up cached memory. |
|
|
ABAP programming and Performance Notes to take into account common performance guidelines (avoid nested loops, database queries) for more information see: ABAP Programming and performance Notes. |
|
|
When working with line items, do not use function crm_orderadm_i_read_ob (such as line item-level event callbacks) through the header GUID, which is critical for performance, especially when dealing with a large number of projects. The function Crm_orderadm_i_struct_read_ob should be used only when reading the level of the current project. |
|
System settings
|
Read Note 1162685 for general information about the CRM WebClient UI settings. |
|
|
Read note 1162605, about how to improve network performance in CRM WebClient UI usage. |
|
|
Read note 1281896 to get information about the CRM WebClient UI shared memory size setting. |
|
Scalability
|
Do not place expensive code in field checks. |
|
|
Run-time performance evaluations for enhancements (taking into account the full runtime of the API call, not only the additional code can cause performance problems, but also the problem may be caused by inappropriate API calls). |
|
|
Garbage data is not processed using the generated table extension. |
|
|
When you build an extension, you can consider turning off generic checks and implementing a specialized check to improve performance. |
|
Event handlers
|
Instead of crossing the line items into the individual callback functions that are immediately executed, you should place them at the end of the document processing. |
|
|
Always keep the concept of secondary transaction categories ("Nebenbus") in your mind. Make sure this newly registered EC function modules only run for the desired objects. |
|
|
You should only request data in an event handler callback if you really need a value. |
|
|
Use Crmd_trace to find the correct location for the event handler callback registration (which should be placed). |
|
Reporting framework
|
When searching for a user-specified field, consider extending the appropriate index table. Read Note 1527039. |
|
|
Consider that permission checking is also part of the query process, and examine in detail the impact of query permission checks on database queries. |
|
Pricing, VMC, product configuration
|
Minimize the complexity of price processing: Examine a variety of situations, check for infrequently used case types, limit the number of visits to price processing, and use appropriate requests to prohibit certain situations that are not needed in processing. |
|
|
Check out note 1269480 for performance issues with configuration, VMC, and IPC. |
|
|
Query Note 1005457 get VMC settings (Java heap). |
|
|
The VMC log only needs to record errors. |
|
|
The basic principles of the implementation of the CRM IPC pricing formula: -Do not make table access. The self-built table reads are not cached by the IPC, so the pricing preparation steps should be implemented on the CRM server. I -In the implementation of user exit, avoid run-time errors (null pointer exceptions). -Avoid using loops at the user's exit. |
|
CRM Functionality Customization
|
Actions: Keep the condition as simple as possible, whether it is a plan (scheduling condition) or an initial condition (starting conditions). This makes the actions and report queries faster. |
|
|
Actions: Use the respective Badi EVAL_SCHEDCOND_PPF or EVAL_STARTCOND_PPF for complex planning and starting conditions to achieve higher performance than using workflow-based conditions. Condition-based workflows are often interpreted by an interpreter and access to data, which can be a key to performance. |
|
|
Actions: Action: Use a different PPF configuration for different business scenarios. This can make the operation time-varying, because the conditions and fewer checks are checked, and fewer actions are required to load the configuration. |
|
|
Actions: A status check should be considered a plan condition modeling, not an initial condition. Actions that are filled with scheduled conditions persist until the app initializes its deletion. In some cases, this can lead to unnecessary PPF selection reports for long runs. An initial condition should only cause the delay that causes the action to run, and the rest of the condition must be part of the scheduling condition. |
|
|
Appointment: Remove unwanted dates from the date configuration information, for example, if you are not using a billing plan |
|
|
Modify a document: Check to see if you can invalidate a document's modification functionality. (Can be customized by business type to invalidate it, identity is ' No Change docunments ') |
|
For more information on actions, please refer to action profiles in SAP CRM
Web Client UI Framework
|
Just place the desired view/assignment blocks on the UI. If the view/assignment blocks is not frequently required, use lazy load mode. |
|
|
Expensive code is not used in the Do_prepare_output method in the component controller because it is processed in each round trip. |
|
|
Do not just bypass the BOL cache, in case the data in the cache is not updated. To find out why the data is inconsistent, and to modify the problem. |
|
|
Do not use complex bindings (updating a node will cause updates to multiple other nodes, and/or a string of other nodes). |
|
|
When registering an event, do not forget to unregister it (otherwise, the event handler will still be called, even if it is no longer needed). |
|
|
In the UI component, the all component set is not used. Otherwise, unnecessary memory is consumed. |
|
This article link: http://www.cnblogs.com/hhelibeb/p/6103685.html
English Original:performance Tips and Tricks
SAP CRM Performance Tips