Optimizing CRM Middleware: Resolving Data Errors & Improving Performance

Below is a snippet from one of hundreds of articles available to ERPtips subscribers. If you would like a complimentary copy of the full article, please email

Mark.Downs@ERPtips.com(include the title of the article in your email)

To subscribe to ERPtips, go to www.ERPtips.com/Subscribe.asp.

ERPtips Journal is published by Klee Associates, Inc. ERPtips University provides both public and onsite training for SAP clients.

For more about ERPtips University, including the current schedule, click here:www.ERPtips.com/WorkshopSchedule.asp

Optimizing CRM Middleware: Resolving Data Errors & Improving Performance

CRM Editor Scott Cameron teams up again with SAP`s Dan Callahan to continue (from ourOctober/November 2005 issue) their discussion of CRM Middleware. They address some of themost common issues faced when employing middleware with SAP and CRM. There is theproblem of data integrity, which is always a concern when sharing data between two systems. Interms of data integrity, They identify “out of synch configuration data” and “out of synch master data” as the primary enemies to smooth CRM/Middleware/SAP integration. They discuss the numerous potential contributors to these conditions and suggest actions to mitigate or eliminate the problems.

Click here to read this Snippet

SAPtips

Page

3

SA

Pti

ps J

ourn

alFe

brua

ry 20

06 V

olum

e IV

Issue

1

SAPtips.com SAPtips © 2006 Klee Associates, Inc.

To improve performance, you can run parallel processes between your systems.

Steps to Streamline Data Flows

To set your parallel processing between R/3 and CRM, you can set the parameter within R/3 in the table CRMPAROLTP. You can set the num-ber of queues within this table. This will give you additional queues when you run your initial load objects.

Like between R/3 to CRM, you can also improve the data transfer between CRM and your mobile solu-tion (with parallel processing).

The parallel processing can be set by putting a parameter entry into the SMOPARSFA table. This will allow you to parallel process between CRM and the R&R queue. (The R&R queue or Request and Realignment queues, are the queues used between CRM and the mobile solution.).

OSS Note 453882 outlines all of the steps needed to set this up.

A cautionary note: more queues do not necessarily contribute to optimal performance. There is a balancing act to avoid poor system response; usually 2-6 additional queues will reduce your initial load times. This should be tweaked during your QA initial loads.

After you have completed your ini-tial download, you can consolidate your delta queues. Standard middle-ware settings generally use the full object key in generating the queue name. For example, for a customer coming from R/3 to CRM, the queue will be named R3AD_CUSTOM-ER0000005001. If you have a mass update to 10,000 customers, 10,000 queue messages will be created.

You can consolidate your delta queues by altering the queue-naming convention within the updating con-trol tables. For R/3 to CRM the table is CRMQNAMES, and for the CRM to CDB, the table name is SMOFQ-FIND.

At the end of the article I will list some OSS notes that will outline additional information in setting these parameters.

You can configure the delta queue to use the last two digits of the customer number. For example, the queue will

look like R3AD_CUSTOMER01, if we use the same example as above.

The result, if we use the previous example of a mass update of 10,000 records, will result in a maximum of 100 queues, which will evenly process all of the entries across the queues.

Thus higher volumes of data can be processed quicker. Please note, as with the initial download, a bal-ancing act is needed to optimize the system performance. The timing and system performance should be a proj-ect activity, planned and executed for during the QA or Staging builds.

After the initial load of data is completed, delta queues are used to transfer data changes between your systems, Once you have set the delta queues, you can control the process-ing frequency of updating and queue usage. These parameters are con-trolled in the Scheduler (QIN and QOUT). This Scheduler controls how many processes are used to send data process data from the queues. This Scheduler also controls how often the queues should be read and proceed. OSS Note 369007 outlines how to set this up and optimize the Sched-uler for your system configuration. Figure 2 shows an example of the Scheduler.

4On CRM

Figure 2: Scheduler

To improve

performance, you

can run parallel

processes between

your systems.

SAPtips

Page

4

SA

Pti

ps J

ourn

alFe

brua

ry 20

06 V

olum

e IV

Issue

1

SAPtips.com SAPtips © 2006 Klee Associates, Inc.

Now that you have optimized your queues, how do you optimize your CRM system? You can optimize your SAP CRM system by creating indices. Optimize your Basis configuration, and test, test, and retest your RFC connections.

To improve system performance and maintain the quality of the qRFC and the BDoc indices, you need to regularly (weekly) rebuild the index (or coalescing, for Oracle databases). OSS Note 435125 outlines the pro-cedure and provides some additional information on this.

To optimize your Basis configura-tion, you should create enough dia-log processes to support your online user base and queue processing. An important note: remember dialog processes, not background or update processes, are used to process queues and BDocs. If you do not have enough dialog processes, you could run into system performance problems. These problems will be visible to online users in the form of slow system pro-cessing time.

Lastly, to ensure that your RFC/Gateway configuration is valid, you will need to test the connections. This is not just testing the connection within the RFC call, but an actual

shut-down of the server. One of the benefits of the RFC connection is that you can still process if R/3 is down.

To test the RFC configuration, shut down the CRM server (while R/3 is still running). Execute an R/3 trans-action, and save. This will create an outbound queue that will process once the CRM system is brought back up. If the R/3 transaction “hangs” while waiting for an RFC connection, you have an issue. You will need to create an OSS message to solve this

issue. The solution for this problem will depend on a number of factors between Basis and network settings.

The last couple of tips to improve system performance include the reprocessing of errored\incomplete BDocs, rebuilding buffers, and deac-tivating change logs.

You should reprocess errored or incomplete BDocs. These BDocs are usually caused by an error, due to temporary conditions such as miss-ing configuration or data. You can just reactivate the BDoc, and the error will process.

There is a middleware program to rebuild the buffer. More importantly, for the CRM organizational model, the program is HRBCI_BUFFER_UPDATE. This improves the query time against the organization model; for example, if you are organization determination for sales transactions.

Note: Organization determination is used to identify or classify informa-tion, this information attached to the transaction for later reporting or for further data processing, such as pric-ing. OSS note 737315 outlines more details around the buffer rebuilding process.

Lastly, you should address the deactivation of the change log for sales and service transactions. This is only recommended if a large number of sales transactions are processed in the system. There are many reasons why, and why not, to keep the change records. I will not go into all of them here. The reason to turn it off (with high transaction volumes), is to help constrain the change log table, which usually is one of the largest and fast-est growing tables within the SAP CRM databases. Figure 3 outlines the Configuration changes on the trans-action record needed to turn off the change records.

4On CRM

Figure 3: Removal of the Change Record Flat (from the transation configuration.

If you do not have

enough dialog

processes, you could

run into system

performance

problems.