Following on from David Evans' blog on ways to improve performance of the SAP CRM order taking process in the ERP Order scenario, I wanted to share some imaginative approaches that we have taken to help improve performance further.
The ERP Order scenario relies on the SAP ECC Lean Order interface (LORD) which is on its second iteration from SAP (LORD2) due to performance issues in the initial version. However due to the reliance on RFC calls between SAP CRM and ECC, there are still some areas of the system that don't perform as well as they could. The good news is that SAP are releasing OSS Notes all the time to help improve the performance, but it is still worth analysing your particular implementation to see what further improvements could be made.
There are far too many techniques for analysis to go into here (see Note 1634757 - Guided Self Service 'Performance Optimization'), but in short some of the tools and techniques we used were:
- End-to-End performance Analysis via Solution Manager
- ST05 SQL and RFC tracing in CRM and ECC
- Roundtrip timings from the CRM Web UI using HTTP Watch (free version here)
- Base-lining traces and timings at peak hours with specific customers over a number of weeks
In our particular case there was a particular performance hit on the initial load of the order in CRM and we took the following approaches to help speed it up...
1. Don't assume the SAP way is the best way
Part of our business requirements for order entry in SAP CRM was to make available a product proposal based on past orders to speed up the order entry process for the agents. This is standard functionality in SAP CRM so was relatively easy to implement. However, the standard functionality calls an RFC function in SAP ECC that trawls through sales order table and brings back everything for the date range specified in the SAP CRM configuration, even if you only want a fraction of the orders in the final display. Not ideal for performance.
During the initial project we had already implemented a bespoke bit of middleware that populated a Z table in CRM with the last 12 order details for each customer in order that the CRM users could analyse ordering trends of each customer. Therefore we created a new query in CRM to read data from this table and plugged this into the product proposal functionality instead.
2. A problem shared is a problem halved
Another feature of the solution was the use of listings and exclusions to determine which products a customer can order. At any given time this could change and therefore a customer’s order history may not reflect what they can currently order. Therefore we had implemented a few checks in the UI to make sure product searches and product proposals only included allowed items. We used standard functions to read the listings condition records, but found that these were not performing very well.
So to combat this we now use a Shared Memory Object to hold the Listings records in memory and the solution can read these directly from here. Although this concept has been around for a long time, I'm not sure it is widely used and it is worth considering for relatively static data as the performance improvements can be fantastic. However ensure that the Basis guys are aware of your intentions as there can be consequences for the Memory settings of the system, especially if you are holding a lot of data. This is an approach that SAP themselves are also using for various data objects in SAP CRM (see OSS Note 1161923 and Note 1637489 for some examples).
3. ERP Data or CRM Data?
One of the unique features of the ERP Order scenario in SAP CRM is the fact that the data that is built up in the order is based on the ERP data model. So the fields in the order are mapped to the VBAK and VBAP tables rather than the CRMD_ORDERADM_H and CRMD_ORDERADM_I tables. However if introducing your own logic into the solution that relies on validating some of this data against SAP CRM, for example looking at Product attribute sets, then there is a need to constantly map the ERP values to the CRM ones. In the product example we found we were constantly having to look up Product GUIDS based on an ERP Material Number (MATNR).
Rather than use the shared memory object here we opted for buffering some standard tables (for example COMM_PRODUCT) and the Z tables generated when creating attribute sets in CRM to help speed up the accesses for this.
4. No-Value Value Helps
The RFC calls back to ECC always seem to be the steps that take the time. Having gotten rid of one call altogether with our new product proposal, we looked at ways to streamline those that had to remain. Before the new OSS Note to implement the value helps in a shared memory object (Note 1637489) which we are still testing, we did some analysis on the RFC call that reads the value help data from ECC. The standard solution retrieves 40 different value tables from ECC however our solution only needs 9 of them.
As it turns out the system decides which values to retrieve based on some hard-coding in the interaction layer of the ERP Order. We have implemented an implicit enhancement in the method with the hard-coding to remove those fields we didn't need a value help for in CRM and therefore speed up the call to SAP ECC.
5. Polling Opinion
The SAP CRM alerting functionality in the Interaction Centre is used in this solution to alert the business users to specific characteristics of the customer during the interaction. As standard the polling of these alerts is set up to run every 1 second. The upshot of this is that the HTTP traffic between the SAP CRM backend and the browser is vast and can clog up bandwidth. In conjunction with the business we determined that we could change this to be every 10 seconds without losing any functionality, therefore reducing this HTTP traffic by 90% in one go.
So what did we achieve?
Once we had done all of this, the results were pretty astounding - the Sales Order load time was reduced by up to 70% and the product searches by 50%. So what can some imaginative thinking do to help your SAP CRM performance?
