Intiail Download Guide

Best Practice: mySAP CRM Initial download configuration 1
mySAP CRM Initial Download Configuration
Best Practice for Solution Management
Version Date: November 2004

The newest version of this Best Practice can always be obtained through the SAP Solution
Manager or the SAP Service Marketplace.
Contents
Applicability, Goals, and Requirements........................................................................................................2
Best Practice Procedure and Verification .....................................................................................................2
Preliminary Tasks......................................................................................................................................2
Procedure..................................................................................................................................................3
Optimizing the Initial load from an R/3 based OLTP system to CRM online ........................................4
Initial load from a non-R/3 based OLTP............................................................................................. 22
Optimizing the Initial load from CRM online to CDB .......................................................................... 26
Initial download of objects after the primary initial download ............................................................. 30
Further Information .................................................................................................................................... 31
© 2004 SAP AG
Applicability, Goals, and Requirements

To ensure that this Best Practice is the one you need, consider the following goals and requirements.
Goal of Using this Best Practice

The goal of this Best Practice is to document and recommend procedures:
• For the configuration of the initial download of business data in a way that the planned volume
can be downloaded in the available time frame. The procedures focus especially on how to
handle the download of huge data volumes.
• To ensure the optimum performance for the initial download of business data
• To avoid unnecessary business data being downloaded
• For monitoring the initial download and taking corrective actions in case of errors and
performance loss
• How to handle errors occurring during the initial download of business data
• Minimize performance bottlenecks
Staff and Skills Requirements

• System administrators with training for the mySAP CRM middleware
• Application team members to define which business data has to be exchanged
System Requirements
MySAP CRM solution landscape including CRM Release 4.0 and either an R/3 based OLTP or a non-
SAP based OLTP system.
How to Use this Best Practice

To apply this best practice, follow the steps in the document, and implement and test the applicable
recommendations.
Best Practice Procedure and Verification

Preliminary Tasks
Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks in
the system:
• Complete all installation and post-installation actions and procedures including customizing.
• Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations
resulting from customer problem messages.
• Implement all current SAP Support Packages upon availability.
• If an R/3 based OLTP system is connected to the CRM, implement the highest available Plug-In and
patch on the R/3 server.
© 2004 SAP AG
Procedure
Communication OLTP system – CRM Middleware
The communication between the OLTP system and the CRM middleware is necessary to provide both
systems with the necessary data to run the different business scenarios. For the CRM Solution this may
be mainly selling goods, for the OLTP system this may be mainly producing and distributing goods.
With CRM 4.0 it is possible to perform this data exchange between the CRM system and an R/3 based
OLTP system or between the CRM system and a non-R/3 based OLTP system using the External
Interface Adapter (XIF).
Two different methods of exchange exist to handle the data transfer between CRM and OLTP systems:
the one-time initial load before GoLive and the permanent exchange of data during the operation of the
CRM solution.
The XIF can be used both for the initial load as well as for the permanent exchange of data. In fact, the
exchange of Business Partners, Business Partner Hierarchies, Business Partner Relationships,
Products, Price Conditions, and One-Order objects such as orders and contracts is supported (see CRM
table CRMXIF_BDOCIF and SAP note 561321 for details).
Where there is a mobile scenario or groupware connection via sBDocs, a data transfer between CRM
online and the consolidated database (CDB) of the CRM system is needed. For mobile sales the data is
then distributed to the mobile clients.
If a BW connection exists, data exchange between CRM online and the BW is also carried out.
The communication between CRM, OLTP system and the CDB supports three different types of data
exchanges: The Initial load to be performed once before GoLive, the Delta down and upload to be
performed after GoLive and the Synchronization download:
• Initial load: The initial load from an R/3 based OLTP system is used to download all business,
customizing and condition data and insert it into CRM online with a deactivated mobile bridge. The
initial load from a non-R/3 based OLTP system is used to download a part of the business and
condition data and insert it into both CRM online with a deactivated mobile bridge. With a mobile
sales scenario the mobile bridge has to be activated after this first step and the data have than to be
downloaded from the CRM online to the CDB. The Initial load from a non R/3 OLTP can be run
either instead of the initial load from an R/3 based OLTP system or to download additional data, e.g.
business partner data only. The next step is then the initial distribution to the mobile clients. If a BW
connection is used the initial distribution to BW should be carried out after the initial download to
CRM online and CDB.
• Delta down and upload: The delta down and upload is used to keep the business and master data
in CRM, the OLTP system, and CDB in sync during normal operation. Therefore all new and
changed data relevant for the connected systems have to be exchanged. Download means that data
is transferred from the OLTP to the CRM system and then via the mobile bridge to CDB for Mobile
Sales; upload means transferring data from the CRM to the OLTP system. The Delta down- and
upload procedure can be either setup between a CRM and an R/3 based OLTP system or between
a CRM and a non-R/3 based OLTP system using the XIF. When using the Adapter technology for
the data exchange, only a limited range of business objects is supported.
• Synchronization download: This type of download is used for customizing data and is only possible
between CRM and an R/3 based OLTP system. In contrast to the delta download for business
objects, customizing data is not downloaded automatically. Instead, the synchronization download
has to be started manually or should be scheduled for fixed time intervals (e.g. weekly or monthly) in
a productive system. The queue name for these queues starts with R3AI* and can be monitored in
the monitor for initial download. With Request selected data can be downloaded from the R/3
backend to the CRM database (or vice versa) or from the CRM database to the CDB or external
systems
.
© 2004 SAP AG
Main Focus of this Best Practice

The initial load is the most critical and challenging data transfer procedure between the OLTP system
and the CRM Middleware, especially if a large amount of data has to be transferred to the CRM
Middleware in a restricted time frame. For mobile sales the initial load from the CRM online to the CDB is
also needed. Therefore, we will focus on the initial load in this best practice document. The performance
optimization of the delta down and upload and the Synchronization download are not currently covered in
this document.
The initial load itself contains 3 different download procedures:
• Initial load of customizing data (only from an R/3 based OLTP system)
• Initial download of condition data such as pricing conditions
• Initial download of business data such as material, customers, sales orders
The Initial load of business data is usually the most critical part due to the amount of data that has to be
transferred.
For mobile sales the following steps should be followed for the first initial download:
• Download from OLTP system to CRM online
• Download from CRM online to CDB
• Distribution of data to the mobile clients.
As the procedures for the initial load from an R/3 based OLTP system and from a non-R/3 based OLTP
system to CRM online are different, this best practice document is split in two major sections for the
download to CRM online. For mobile sales we have a third section for initial download from CRM online
to CDB. The distribution to the mobile clients and the initial load to BW is not part of this document.
In the first section of this best practice we discuss procedures for optimizing the initial load from an R/3
based OLTP system to CRM online, e.g. by reducing the data volume to be transferred to the CRM
system and by setting up parallel processing.
In the second section we give a brief overview of the procedures for optimizing the initial load from a non-
R/3 based OLTP system using the External Interface Adapter (XIF)
The third section discusses a procedure for optimizing the initial load from CRM online to CDB.
Optimizing the Initial load from an R/3 based

OLTP system to CRM online
To optimize the performance of the initial load from an R/3 based OLTP system to CRM online several
actions have to be considered. Reducing the amount of data to be transferred can shorten the runtime.
This is described in the next paragraph. Additional technical tuning is described in the following
paragraph. The major performance gain in the initial load can be achieved by using parallel processing.
The procedure how to setup and test parallel processing is described in detail at the end of this chapter
Reducing Data Volume during the Initial Download

One major factor impacting on the runtime of the initial download is the data volume that has to be
downloaded to CRM online. Filter settings can be used to reduce the downloaded data volume. Filter
criteria are easy to implement, as no programming is required. The procedure for applying filters and
some recommendations regarding filter settings are given in this chapter.
© 2004 SAP AG
Using filter Settings for the Initial Download

The transaction you use to specify the filter criteria for the various business objects can be found under:
CRM 4.0: Middleware >>Data Exchange >> Object Management >>
• Business Objects (Transaction R3AC1 )
• Customizing Objects (Transaction R3AC3 )
• Condition Objects (Transaction R3AC5 )
Filter criteria can be defined for business objects, customizing objects and condition objects. The
business objects usually have the highest data volume to be downloaded.
Some general remarks regarding filter settings:
• Filter options allow the filtering of business objects at the source, at the target or at both the
source and the target for business objects. However, business data are usually filtered at the
source. Customizing or condition objects can be filtered at the source only.
• Filter settings are stored in the table SMOFFILTAB on CRM site, CRMFILTAB on OLTP site and
refer to table fields.
• Filters for the initial download are also used for the delta download
• If you use more than one filter entry per object, filters to the same table field are linked with an
OR, e.g. the filter condition VKORG = 0001, VKORG = 0002 results in a set that contains either
the first or the second sales organization.
• Filters to different table fields are linked by AND, e.g. the filter condition VKORG = 0001, VTWEG
= 01 results in objects that fulfill both conditions at the same time.
• Filter conditions are only stored locally and are not contained in the transport of adapter objects.
In this way filters are not transported from the development system to the production system.
New filter settings have to be defined in each system.
Activation object specific

flag filters
Here are some typical examples illustrating how filter settings are used to reduce the data volume:
© 2004 SAP AG
Filters for Material Master

• Filter out material that is not sold directly, using your CRM solution. For example, if you are
producing pumps, you normally only sell the finished products and some spare parts but not the
raw material and all components. In this case, use a filter on the field MARA-MTART (material
type) for the download object MATERIAL in order to only download this material type from the
OLTP.
• Filter out configurable materials if you do not need them in your CRM solution. To do this, set a
filter on field MARA-SATNR.
See also SAP note 526980 for details about the functionality of filtering Material master.
To accelerate the initial download of objects, such as the material master, see SAP Note 350176
(CRM/EBP: Performance improvement during exchange of data).
The SAP Note 418886 (Download: Products not found or not changeable) explains some error
messages which occur during a further download of materials after the materials or services have
been replicated to the CRM/EBP System successfully.
Filters for Customer Master
Filter out customers that are not required for your CRM application. For example, if you are only selling to
customers assigned to the distribution channel "direct selling", create a filter to download only these
customers. To do this, create a filter on the field MVKE-VTWEG (distribution channel) for the download
object CUSTOMER_MAIN.
Filter conditions defined for CUSTOMER_MAIN are automatically taken into account during the
download of object CUSTOMER_REL.
Filters for Sales Documents

• Filter out old sales documents that are not relevant for your CRM solution. For example, you decide
that for running your CRM solution it is only necessary to have the sales documents of the current
business year which started for your company on 01.01.2003. In this case create a filter on the field
VBAK-ERDAT (creation date) for the download object SALESDOCUMENT with operator GT. Enter
the value 20030101 (date format YYYYMMDD has to be used) in the field ‘Low’. In this case only
sales documents created from the 1st of January 2003 onwards will be downloaded to the CRM
server. For more details regarding filter setting for sales documents see SAP Note 213733
• Filter out sales documents for customers to whom you are not selling in your CRM solution. Carry
this out by using a general filter.
Note: Be aware that changing filter settings on an already productive system is critical. E.g. if you are
further restricting filter criteria after the initial load this may lead to data inconsistencies between the CRM
and the OLTP system.
Filters for keys
Please keep in mind that you have to use the keys in the filters as they are defined in the data dictionary
table in R/3. For example for customer, which has 10 digits, see OLTP table KNA1 field KUNNR. This
means you have to fill the filter entries with leading zeros. For material, which has 18 digits, see OLTP
table MARA field MATNR.
Performance of the initial download

In this Section you will find the most important recommendations for achieving good performance during
the initial download. Read all sub-sections carefully and verify that the performance recommendations
can be applied to your CRM solution. In the Appendix you find a list of further SAPNet notes regarding
performance optimization. The main Note for performance issues regarding the initial download is SAP
Note 350176
© 2004 SAP AG
Initial download after a test of the initial download

After a test of the initial download the application tables are already filled with business data. Should you
test the initial download for a second time within this system you will, for example, have updates on the
tables instead of inserts as during the first download. Please delete the data before you make a second
test of the initial download or use a backup which was made before the first initial download.
Setting the middleware trace level parameters
In order to log CRM application errors, the middleware trace must be switched on during the initial load.
As only error information is required, the middleware trace level can be reduced to level "1" for all trace
environments of the Middleware trace except for 'G' (generation). For this purpose, choose the following
path in the SAP Menu 'Architecture and Technology -> Middleware -> Monitoring -> Message Flow ->
Set up Middleware Trace' and choose 'Set default settings'.
Recommendation: Delete outdated trace and log information, schedule report SMO6_REORG on a
regular basis as described in SAP Note 206439. Please take into account that the standard settings
retain the data from the last 7 days. Therefore, for the initial download it makes sense to reduce the
“days to hold” to one. To avoid problems with error analysis, regularly monitor the BDoc errors.
Delete trace data and BDOC message administration tables before and after the
initial download has successfully completed
During an initial download, large data sets may be written in the middleware trace and the BDoc
message store.
Recommendation: Delete the data before or after the initial download has successfully completed,
schedule report SMO6_REORG for the reorganization of the log tables as described in SAP Note
206439. The reorganization job deletes data in the tables. Please take into account that the standard
variant holds the data from the last 7 days. Therefore, in the case of the initial download it makes sense
to reduce the value “days to hold” to one after you have checked that the initial download has worked
correctly. To avoid problems with error analysis regularly monitor the BDoc errors.
For Oracle the indexes should be rebuilt as described in SAP note 435125.
Reorganize BDOC message related object links before and after the initial
download completed successfully
During the initial download many entries may be written to the tables SMW0REL and SRRELROLES due
to BDOC message related object links. If you have already carried out a test download on the system,
these tables may already be full.
Recommendation: Reorganize the data before or after the initial download has completed successfully,
by scheduling the report RSRLDREL as described in SAP note 493156. In this special case of the initial
download you should set the end date in such a way that as many links are reorganized as possible.
CRM Server Performance: RFC Queue processing
The qRFC is part of mySAP Basis Technology. qRFC releases are independent of the CRM release
cycle and ongoing performance improvements are realized in the different versions. Prior to Basis
Release 6.20 the qRFC version is an extra transport. For Basis Release 6.20 or higher, you can only
import the current qRFC version via a Support Package.
Recommendation: Always use the latest qRFC version. Always update qRFC on the CRM server AND
on the connected OLTP R/3 system.
Implementation: To obtain the newest qRFC release, see SAP Note 438015.
Note: After the implementation of a new basis support package, verify if the qRFC version is still the
newest. Some basis support packages may contain older qRFC versions.
See the Appendix for a list of the actual SAP Notes containing program enhancements related to qRFC.
Recommendation: For a general overview on queuing in CRM and R/3 and information on queue
names used and their respective functions in the CRM server and R3 backend, see SAP Note 765236
© 2004 SAP AG
Data transfer using XML

The XML interface consists of an XML generating program on the OLTP Plug-In and an XML parser on
the CRM. The generating program generates an XML document from the data stream to be sent to the
CRM system, where the XML parser converts the data back to the original data stream.
In a heterogeneous system landscape (for example, if servers with different CPU architecture are
involved), data inconsistencies during data transfer can occur caused by the Endian problem. The data
transfer in XML format solves both the Endian problem and the code page problem which may occur in a
data transport.
With regard to the performance: the XML format has the performance disadvantage that the XML parser
needs CPU time. In some special cases it may be possible to deactivate the XML Conversion during the
initial download to speed up the process. With CRM 4.0 and the applicable PI on the R/3 side the option
SEND_XML = M is possible. The option SEND_XML = M (=mixed) in the table CRMRFCPAR specifies
that only parts of the BAPI container used for the data exchange between the SAP R/3 System and the
CRM Server are sent using XML. Character-type fields are transferred to subsequent systems with high
performance. For non Character-type fields, an XML conversion occurs in spite of the 'M' entry which has
a negative impact on the performance.
Recommendation: To avoid performance problems the option SEND_XML = M should be used.
Information on the availability of this option can be found in SAP Note 442277. If the performance is not
sufficient with this option you can check if the XML Converter can be deactivated. For details see SAP
note 333008. As rule of thumb the SEND_XML = ` ´ is 6% faster than SEND_XML = M.
Note: Please be aware that deactivating the XML Converter may lead to data inconsistencies if the
preconditions are not met. If you change your hardware please again check if the conditions are met in
order to avoid problems after the hardware change.
Avoid initial download to CDB and BW
To take advantage of the parallel initial download and the filtering, the data should not be directly loaded
to the CDB in the initial load from R/3 to CRM online.
Recommendation: The mobile bridge needs to be switched off to avoid the load to the CDB. With CRM
4.0 it is possible to switch it off for all objects in transaction CMWC_SMW. If the flag “Data Sync Active”
is not set the mobile bridge is deactivated. In addition the creation of the CSA* queues for these objects
should be deactivated. With CRM 4.0 this is possible in transaction SMW3_00. The deactivation needs to
be carried out per BDoc type. For details see also SAP note 635697. This deactivation of the CSA*
queues also switches off the delta load to BW for objects which are transferred to the BW via m flow. In
general you should first make the initial load to the CRM server and then the initial load to the BW. If you
need the delta load to BW or other systems you have to reactivate the CSA* queues again after the initial
download.
Download of currencies
The initial download of currency data may terminate with a time-out. Currency data is contained in the
download objects DNL_CUST_CURREN and DNL_CUST_BASIS3. The reason for the timeout is that
the table TCURR containing the exchange rates has too many records.
Recommendation: Set the block size (that is, the number of data records per BAPI call) to 1. Filter out
exchange rates: Apply the filter to the field GDATU of the table TCURR.
Test runs and time frame for the initial download

To obtain an idea of how long the initial download will run (this can last several days, or even up to even
two weeks) testing is mandatory as runtime can be critical for the project time plan. For a high volume of
data, test phases of one or several weeks should be considered.
Procedure: Set up separate test runs for each download object for the initial download. For download
objects with a high volume (at least several 100 000), a test period of at least one week may be
necessary.
Be aware that the initial download cannot be run in "test mode." This means that during each test
run of the initial download, the data really are inserted into the CRM database. There is also no
tool available for "deleting" the downloaded data from the CRM system after a test run. This
© 2004 SAP AG
means that you either have to perform test runs with different filter settings for the same
business object or to delete the data manually before performing another test run. An easier
solution is to make a backup before the initial download test and restore this backup before the
next test.
After the initial download is started, entries in table TBE31 on the OLTP system are created in order to
trigger the download of delta information to synchronize the information on the OLTP and the CRM
system.
If you are performing test runs using an already productive OLTP system, please ensure that the event
entries are deleted after the test initial download is finished. Therefore use transaction R3AC4 and set
the flag "inactive" for the corresponding download object. Do not forget to remove the inactive flag for the
corresponding objects immediately before you start the productive initial download. Otherwise the delta
information will not be downloaded from the OLTP system to CRM which leads to inconsistency between
the two systems,
During the test runs, check for errors which occurred during the download. Errors may occur if the data
downloaded to the CRM system is not formatted in the way expected by the CRM system. For example,
when downloading business partners, the phone number must be in a specific format. If the phone
number has a different format in the OLTP system, an error will occur during the initial download of this
business partner, as the data cannot be entered into the CRM system.
Correct the errors which occurred during the initial download and repeat the download to check whether
the error correction worked. Afterwards correct the errors in the productive environment also. Try to
repeat the test runs until errors no longer occur.
Measure the runtime for the initial download for all download objects with a high volume. This is essential
for estimating the time necessary to download all business objects and to optimize the setup for parallel
processing. Please keep in mind that the extrapolation is only a rule of thumb because the download
slows down with increasing tables. You should also refresh the table statistics.
Parallel Processing of the Initial Download

Parallel Processing of the Initial Download is very effective for objects that have very extensive data sets,
for example, for the download of business partners, parallel processing of the initial download may be
necessary to process the data in the given time frame. Parallel processing is described in detail in SAP
Note 350176.
To configure parallel processing of the initial download you need to decide between two cases:
1. Data selection on the OLTP is faster than the processing on the CRM server (e.g. materials,
business partners, conditions). If the bottleneck is caused by processing on the CRM server, a
better performance can be achieved by increasing the number of qRFC inbound queues on the
CRM server as each queue is processed by one work process. Where there is a large data
volume it is possible that the time frame is not sufficient for finishing the initial download with one
selection process on the OLTP side. In this special case you could use requests in parallel. Per
request you can define the number of inbound queues on CRM used per request. For details see
SAP Note 426159.
2. Data selection on the OLTP is slower than the processing on the CRM server. (E.g. for sales
documents). In this case starting multiple downloads can increase the performance, since more
work processes are now used to select the data on the OLTP R/3 system. To do this you have to
define and start multiple requests with non overlapping parameters for the same download
object.
Procedure:
• To decide if the bottleneck is created more on the CRM server or on the OLTP server, perform
test runs of the initial download for selected data and measure the run time on both sides. The
runtime information can be retrieved by evaluating the statistical records using transaction STAD
or by directly monitoring the process using transaction SM50. Here you should check the
activities for the user defined in the rfc destination from R/3 to CRM. If you use the “Destination
with LOGON Data” in SMQR, the user is the user defined there.
© 2004 SAP AG
• To decide if parallel processing is necessary on the CRM server based on these measurements,
and to calculate how many parallel queues should be setup per download object, follow the
procedure described in the section Parallel Processing on the CRM Server
• To setup a parallel processing on the OLTP system, follow the procedure described in the
section Parallel Processing on the OLTP Server
Parallel Processing on the CRM Server

Time Frame for Initial Download - Parallel Processing
Procedure: Check whether the time frame planned for the productive initial download in the productive
environment is sufficient. Therefore use the data from the check table in the section "Test runs and time
frame for the initial download" and evaluate the data as follows:
1. Define the available time frame for the initial download of all required objects. This timeframe
does not include the time required for data verification and correction.
2. Calculate the time frame needed to download the given data volume to the CRM server.
Therefore divide the given data volume for the selected download object by the download rate
per hour and per job as measured in test runs and add up time per object to get the total time
required.
As the download rate depends on customizing settings and on the data structure itself, no
benchmark is available as yet. However, as a rule of thumb we expect that one data object (e.g.
one business partner or one line item of an order) can be downloaded in 1 second assuming that
the support package level is up to date, performance-relevant notes have been implemented and
all parameter recommendations given in the GoingLive Analysis session have been
implemented. This results in a download rate of around 3.600 data objects per hour.
3. Check whether the calculated time frame needed to download the given data volume to the CRM
server is shorter than the available time frame. If the calculated time frame is significantly longer,
i.e. more than 25%, we can assume that the required volume cannot be downloaded in the
available time frame. In these cases, parallel processing for this download object must be used.
To calculate the number of queues to be configured on the CRM server, see the section "Queue
set up for Parallel Processing."
Test measurements for the initial download

The average download rate per hour per job for each download object is dependent on the hardware,
parameter configuration and on the download data itself. To obtain exact figures for your own CRM
solution, you need to perform test downloads with a limited data volume. Please keep in mind that the
extrapolation is only a rule of thumb because the download slows down with increasing table size.
Procedure: To set up and perform test downloads for the initial download proceed as follows:
• Check if you can use the productive environment for the test measurement or set up a test
environment with similar hardware. (As we do not use parallel processing for the test run, the
number of CPUs in the test environment is not an issue and may differ significantly from the
number of CPUs in the productive environment. However, to use the measured runtime as a
basis for our estimation of the average download rate in the productive environment, the test
environment needs to have a similar CPU type (frequency and type)).
• Setup test data for each download object. To get a representative value for the average
download rate per hour per job, there should be at least 1000 data sets available for download
(for example, 1000 customers).
• Specify the block size in the same way that will later be used for the productive download. E.g. if
you will later download 100 customers per block set the block size to 100.
• Set up the filter criteria in a way that ensures that no more data than necessary will be
downloaded. Example: If you have 1320 customers in the OLTP system of your test environment
for the sales organization "0008" and you decide to download these customers for the test run,
© 2004 SAP AG
you must specify the filter condition for the download object CUSTOMER_MAIN as follows:
VKORG =0008.
• Be sure that the parameter settings are the same as will later be used for the initial download in
the productive environment, e.g. the setting for the flow trace level, log level…
• Start the test using transaction R3AS with only one queue in the CRM system (that is, without
parallel processing).
• Measure the time the job runs on the OLTP server. Use the system monitor SM50 for direct
measurement by monitoring the relevant process or evaluate the statistical records on the OLTP
server using transaction STAD
• Get the total time the download queue ran on the CRM server. For this purpose either use
transaction SM50 or evaluate the statistical records on the OLTP server using transaction STAD.
• For general recommendations regarding performance optimization on a test environment see for
example your GoingLive session. See also SAP note 429423 for “General analysis in the initial
Load”.
© 2004 SAP AG
Queue Setup for Parallel Processing

To optimize the runtime of the initial download on the CRM middleware server, the number of download
queues to be run should be high. On the other hand, the available hardware resources limit the number
of download queues you can run in parallel. Please keep also in mind that the disk I/O could limit the
number of queues which can be processed in parallel. In this section we will determine the optimum
queue set up for parallel processing.
Procedure: To setup and verify the scheduling for parallel processing of the initial download proceed as
follows:
1. Enter the information you have so far into the table below: Specify the object type and the
volume of the downloaded data (from the OLTP system to the CRM system).
2. Enter the value for the measured download rate per hour and per job. If you did not measure the
download rate, enter the default values from the table in the section above.
3. Calculate the needed download time for serial processing. Therefore, for each download object,
divide the value in the column ‘Volume’ by the value in the column ‘Download rate per hour and
per job’. Enter the calculated value in the column ‘Download time in h needed (seq)’.
4. Calculate the maximum number of queues to be run in parallel that can be configured on the
CRM server. Therefore consider two cases:
• The CRM server is a Central Instance: Multiply the number of CPUs on the server by 2/3.
Round to the next integer value and enter the value in the column ‘CRM: Max. no. of Queues
possible’. (For Example: Your CRM server is equipped with 8 CPUs. 2/3 of 8 CPUs would be
5,33. This value would be rounded to 5)
• The Database server is located on a separate machine than the application server(s): Add up
all CPUs on all application servers and enter the figure in the column ‘CRM: Max. no. of
Queues possible’. (For Example: One database server with 2 CPUs, two application servers
with 3 CPUs each. Together this would result in 6 CPUs available and therefore 6 queues
can be run in parallel.)
5. Calculate the estimated download time if using parallel processing. To do this, for each download
object, divide the value in the column "Download time in h needed (seq)" by the value in the
column "CRM: Max. no. of Queues possible." Enter the calculated value in the column
"Download time in h needed (parallel)." Please take into account that only the processing time on
the CRM side can be reduced by this parallel processing. With high parallelization you should
take this time into account.
6. Finally, enter a value for the available time frame for the initial download to the CRM system on
the last line. Calculate the sum of all values in the column "Download time needed (parallel)" and
enter the sum on the last line.
© 2004 SAP AG
SETUP OF PARALLEL DOWNLOAD ON CRM MIDDLEWARE

Object Name Volume Download Download CRM: max. No Download
Rate Per Hour Time in h of Queues Time in h
and Per Job Needed (Seq) Possible Needed
(Parallel)
Material Master 40 000 5 000 8 4 2
Customer Master 120 000 2 400 50 4 12,5
Contacts 240 000 3 600 67 4 16,7
Classification: Attributes
Classification: Classes
Bill of Material
Customer Master
Customer Hierarchy
Contacts
Sales Documents
Total time frame available 72 Total time 31,2

(Hours) (Parallel)
To check whether the system is able to perform the initial download in the available time frame, compare
the two values "Total time frame available" and "Total time (parallel)" and set a rating for your evaluation:
• RED: Set a red rating if the value for ‘Total time frame available’ is lower than 50% of the value for
‘Total time (parallel)’.
• YELLOW: Set a yellow rating if the value for ‘Total time frame available’ is between 50% and 100%
of the value for ‘Total time (parallel)’.
• GREEN: Set a green rating if the value for ‘Total time frame available’ is higher than 100% of the
value for ‘Total time (parallel)’
In addition to the above determined time you should consider time for unforeseen problems
which may occur in the productive initial download.
Procedure – Final Conclusion:

• With a green rating we can assume that the system will be capable of downloading the available
documents in the given time frame with the calculated number of queues in parallel. Therefore
continue with the procedures for the configuration for the parallel initial download on the CRM server.
• With a yellow rating we assume that the system will be capable of downloading the available
documents in the given time frame with the calculated number of queues in parallel. If the real
productive initial download performs as calculated is dependant on some issues:
o Did you make your calculation with assumptions for the download rate? If yes run
performance test measurements for at least the top 3 download objects with the highest
volume. Update your calculation with the download rates measured during the test runs.
o For some download objects such as customers, the degree of parallel processing is limited
by the complexness of the relationships between customers. E.g. If customer A is related to
customer B, customer B has to be download prior to customer A. To ensure this, customers
A and B have to be downloaded in one block and cannot be processed in parallel. Therefore,
if you know that you are using complex customer relations, the degree of parallel processing
for the download object CUSTOMER_MAIN may be lower than the amount of CPUs on the
system would allow.
Continue with the procedures for the configuration for the parallel initial download on the CRM server.
© 2004 SAP AG
• With a red rating we assume that the system will not be capable of downloading the available
documents in the given time frame with the maximum number of queues to be run in parallel as
calculated above. In this case you should proceed as follows:
1. If you not already performed test measurements for at least the 3 download objects with the top
volume you should perform them as described above. With the measured average download
time recalculate the estimated download time and recalculate your rating.
2. Check if you can further extend the available time frame for the initial download.
3. Check if you can further decrease the volume of data to be downloaded. See the procedure and
recommendation given in the section “Reducing data volume during the initial download”
4. If your available time frame is still smaller them the estimated download time, try to run the
download with a higher number of queues in parallel than calculated above. Running a higher
number of queues in parallel may lead to a CPU bottleneck situation on your CRM server. To find
the maximum number of download processes which can run in parallel, dedicated test runs are
necessary:
• Double the number of queues to be run in parallel above.
• Configure the system for parallel processing of the initial download as described in the
section “Configuration of the parallel download processing on the CRM server”.
• Carry out a test run with the doubled number of queues. During this test run verify that all
queues are running. Check the CPU and memory consumption during the test run using
transaction ST06 and ST02 on the CRM server. If the CPU & memory resources run at
100% during the whole test run you may have to repeat the test run with a lower number of
download queues. By doing this you find the maximum number of queues that can be run in
parallel on your CRM system.
• With the new number for the parallel download queues, recalculate the estimated download
time and recalculate your rating.
• If your available time frame is still smaller than the estimated download time you can be sure
that you will not be able to download the planned volume in the given time frame. In this case
you should contact your hardware partner to discuss a resizing of the CRM server
• Because this initial download is only a temporary process, a possible solution would be to
use the test system temporarily as an application server. You would then have additional
hardware for the initial download.
Configuration of the parallel download processing on the CRM server

If your CRM system consists of several servers (E.g. one database server and two application servers)
and you want to use several servers for parallel processing of the initial download on the CRM site, you
have to define an RFC server group on the CRM system including these servers and change the AS
group accordingly in SMQR.
Implementation: To define an RFC server group, use transaction RZ12. In the QIN scheduler
(transaction SMQR), you must assign this RFC server group by choosing "Edit" >> "Change AS groups."
In addition you should check that the “Max. Runtime“is set to 60s which is he default value. For large
queues it makes sense to set the value to 300s.
Configuration of parallel processing for all download objects

Implementation: Make a new entry in table CRMPAROLTP on the OLTP including the parameter name
"CRM_MAX_QUEUE_NUMBER_INITIAL" and consumer = "CRM." For the parameter value, enter the
number of queues you decided to run in parallel. For example, if you want to run 5 queues in parallel,
enter parameter value = 5.
Note: Parallel processing cannot be applied to all objects, e.g. for the initial download of CUSTOMIZING
objects, which R/3 directly writes to the CRM online database (for example DNL_CUST_BASIS) the
parallel processing can not be used. Therefore be sure that all necessary customizing objects have
© 2004 SAP AG
already been downloaded before configuring the parameters in table CRMPAROLTP for parallel initial
download. In order to avoid resulting problems, remove parameter
CRM_MAX_QUEUE_NUMBER_INITIAL from table CRMPAROLTP after the initial download has been
completed successfully. To avoid these problems define the configuration of parallel processing for
specific download objects as described below
Configuration of parallel processing for specific download objects

Parallel processing can be set up per download object.
Implementation: To process individual objects in parallel, make an entry in table CRMPAROLTP for
each download object (for example MATERIAL). For example, if you want to run 5 queues in parallel for
the download object MATERIAL, the entry in table CRMPAROLTP (Transaction SM30 in the OLTP)
should look like this:
Parameter name: CRM_MAX_QUEUE_NUMBER_INITIAL

Parameter name 2: MATERIAL
Parameter name 3:
Consumer: CRM
Parval1: 5
Note: For more detail, see SAP Notes 350176 and 510192.
Parameter settings for parallel processing of the initial download

In additional to the setup of the number of queues to be run in parallel, you have to check certain
parameters on the CRM server to be sure that the configured number of queues can really be processed
on the CRM server:
• Be sure that the number of dialog work processes configured on the CRM server is higher than
the number of queues you want to run in parallel. To have additional free work processes
available for administrative purposes such as monitoring the initial download, there should be at
least 3 more dialog work processes available than the number of queues to be run in parallel.
For example, if you want to run 10 queues in parallel you should have at least 13 dialog work
processes configured on the CRM server.
• Be sure that not all available dialog work processes are occupied by queue processing.
Therefore, check especially the setup of the RFC resource parameter
"rdisp/rfc_min_wait_dia_wp". This parameter describes the number of dialog work processes to
be kept free, so they cannot be used by incoming RFC calls. E.g. if you have 13 dialog work
processes configured and you want a maximum of 10 to be used by RFC calls, the parameter
"rdisp/rfc_min_wait_dia_wp" must be set to 3. As this parameter is set to 1 by default, you should
increase this parameter to at least 3 before starting the initial download. On the other hand the
parameter must not be set too high. If you have 13 dialog work processes configured and you
want 10 queues be processed in parallel, you must not set this parameter higher than 3.
• Please take into account that the maximum number of parallel initial loads is restricted by the
parameter MAX_PARALLEL_PROCESSES in table SMOFPARSFA. The delivered standard
value is 5. The number of processes contains initial loads and requests. See also SAP note
429423.
Parallel Processing on the OLTP Server

In some cases it may be necessary to have parallel processing on the OLTP. This can be carried out by
multiple request downloads with non-overlapping parameters in the OLTP system to shorten the runtime
of the initial download. One reason for parallel processing could be that for some download objects the
data selection on the OLTP is slower than the processing on the CRM server (e.g. for sales documents).
© 2004 SAP AG
Another reason can be that the daily backup, which has to be started at a fixed time, limits the available
time frame for the initial download of one download object.
To run the selection and the filling of the download queues in parallel on the OLTP system there is no
special configuration necessary.
To start the parallel processing on the OLTP server, start several request downloads with no overlapping
parameters in parallel using transaction R3AR4. The request function is described in detail in the R/3
Adapter documentation. You can, for example, request document numbers 1 to 1000, 1001 to 2000, and
so on from the OLTP ("Request"). Here, the general filters must fit the request filters. That means the
request filters must be a subset of the general filters.
Note: The maximum number of requests to be processed in parallel is limited by the parameter
MAX_PARALLEL_PROCESSES in table SMOFPARSFA. The default value for this parameter is 5. This
is described in SAP Note 429423.
Parallel Processing on OLTP and CRM Servers

In some cases, it may be necessary to use parallel processing of the initial download both on the OLTP
server and on the CRM server. One reason could be that the document volume is too high to use only a
single process for section on the OLTP site. To realize this you should use parallel requests. See details
and restrictions in SAP note 426159.
How to Start the Initial Download

In this chapter the procedure for starting the initial download is described. The transaction for starting the
Initial Download can be found under
• CRM 4.0: Middleware >> Data Exchange >> Initial Load >> Start (Transaction R3AS).
Procedure: In order to ensure a correct initial download, perform the steps described in the following
sections.
© 2004 SAP AG
Deregistering the delta download queues

If you want to start the parallel initial download for a download object, you have to first deregister the
delta download queue for this download object. For a non-parallel initial download, this is not necessary
as the delta download is automatically stopped when the initial download is started. With an initial
download using several download queues in parallel, the delta download for the selected download
object is also stopped. But in this case the download display in transaction R3AM1 can change to green
too early and the block for the delta download is released, because the system may process the last
block faster than earlier blocks. If the released delta download queue contains changes for the same
data object which is actually being processed in the running queue of the initial download, this situation
can lead to data inconsistencies. After parallel initial download you must again restart the delta queues.
Starting the initial download

Before starting the initial download, verify if the parent objects were successfully loaded. For example, if
you want to download MATERIAL parallel within an object, you must first start parent objects
"DNL_CUST_PROD0" and "CUSTOMER" separately, then wait for completion and then start the
dependent object "Material." For dependencies, refer to the entries in table SMOFOBJPAR.
After starting the download for a selected download object in parallel, the system processes in parallel by
block number: For example, the first material block runs into the server inbound queue SMQ2 having the
name R3AI_MATERIAL01, the second block into R3AI_MATERIAL02, and so on. The Queue Scheduler
on the CRM server processes these blocks at the same time.
Recommendation: Monitor the initial download using the procedure described in the section ‘Monitoring
the initial download’
Note: With parallel initial downloads, the download display in transaction R3AM1 can change to green
too early because the system may process the last block faster than the block prior to the last one. For
this reason, you have to check not only the download display but also the inbound queue and the number
of data in the database (Transaction SE16) before you start additional objects. In order to avoid resulting
problems, remove parameter CRM_MAX_QUEUE_NUMBER_INITIAL from table CRMPAROLTP after
the initial download has been completed successfully.
Initial load of Customers

To load the customer data into the CRM system, there are two different types of customer master data
according to the OLTP systems. One is ‘Business partner’ master data for an Industry solution (e.g.:
Automotive, Pharmaceutical, Media, High Tech, Aerospace…) R/3 system, and the other ‘is Customer’
master data for a standard R/3 OLTP system.
The download object used for Industry solution R/3 and non R/3 OLTP systems is ‘BUPA_MAIN’ for the
business partners and ‘BUPA_REL for contact persons.
The download object used for standard R/3 systems is ‘CUSTOMER_MAIN’ for the business partners
and ‘CUSTOMER_REL’ for contact persons.
To clarify if you have to use download objects ‘BUPA_MAIN’ or CUSTOMER_MAIN’ for the initial load
from the OLTP, proceed as follows: If your customer data is stored in tables KNA1, KNVV, KNBK and
KNB1, use CUSTOMER_MAIN’ to download customer master data. If your customer data is stored in
table BUT000 and subsequent BUT* tables use BUPA_MAIN’ to download customer master data.
For example in an IS-Retail solution, customer master data is stored in the KN*-tables, which indicates
that CUSTOMER_MAIN has to be used.
Note: If you are using an IS-Media solution as a backend system, please see also SAP Note 0436843 for
detailed requirements for the Initial download.
© 2004 SAP AG
Monitoring the initial download

In this section the procedure for monitoring the initial download is described. To understand what has to
be monitored first, a description is given of how the initial download works and in which way the data
flows during the initial downloads.
A short overview over the most important monitors used during the initial download is also given.
Finally a description of what to do should errors occur during the initial download is provided.
How the initial download works

In this section we describe how the initial download works, based on the example of the download object
CUSTOMER:
Before the initial download of customers (and also contact persons), the system checks various important
default settings. In particular, these are the consistency of organizational management and the settings
for the download of customers as they are described in the setup and download guide. If these default
settings are not correct, the system immediately issues a corresponding error message and the initial
download is not started. In this case, the errors must first be corrected before the initial download can be
performed.
If no errors occur during this preliminary check, the initial download is started. All customers which
correspond to the filter criteria are selected from the R/3 system and sent in blocks of the defined block
size (default setting 100) to the CRM system. There, the system fills the inbound queue with the names
R3AI_CUSTOMERXX. The "XX" in the queue name refers to the queue number, for example, if you set
up 5 queues to run in parallel, the queues will be named "R3AI_CUSTOMER01","R3AI_CUSTOMER02",
… ,"R3AI_CUSTOMER05." If not previously carried out manually, all delta downloads from the R/3
system are stopped. Therefore, during the initial download, delta downloads will not work. However, after
the initial download is started, entries in table TBE31 on the OLTP system are created to trigger the
download of delta information to synchronize the information on the OLTP and the CRM system. The
entries in the inbound queue in the CRM system are processed sequentially.
The following diagram describes the dataflow during the initial download from OLTP to CRM online:
CRM
5
qRFC
Inbound
Qutbound qRFC BAPI
qRFC R/3 Adapter
6 mBDoc
Plug-In
1
R3AS
OLTP Trigger Inbound
Download 7
processing CRM
R/3 Proxy
Adapter
Extractor Extract Outbound
processing Validation
3 BAPI Send
qRFC
Outbound
4 2 qRFC
Inbound qRFC
© 2004 SAP AG
The data flow consists of the following steps:

1. With the CRM transaction R3AS an initial download trigger is raised.
2. The RFCs are queued and processed in a sequence (dependent or independent objects).
3. In the backend system a function module call (extractor module call) is used to extract the
requested data.
4. A data container is created with the selected data to be sent to the CRM Middleware server.
5. The data is transferred using qRFC in the form of tables to the CRM.
6. In the R/3 Adapter the BAPI is mapped to an mBDoc and then passed to the CRM Adapter.
7. After successful validation the BDoc is stored in the CRM database.
The initial load from OLTP to CRM online is finished with step 7 in case the mobile bridge and the
creation of CSA* queues are switched off.
Tools for monitoring the initial download

In general, there are 4 kinds of tools that can be used to monitor the initial download:
Status monitoring:
• The download monitor (R3AM1) described in chapter The Download Monitor (R3AM1) gives a
general overview of the actual status of the initial download per download object.
Error monitoring and analysis:
• The monitoring of the outbound queue in the OLTP backend described in the section "Monitoring
the outbound queues in the OLTP” allows you to detect and analyze errors which occurred in the
OLTP server.
• The monitoring of the inbound queue in the CRM middleware described in the section
"Monitoring the inbound queues in the CRM middleware" allows you to detect and analyze errors
which occurred in the CRM server
• Additional monitoring tools used to detect and analyze errors which occurred during the initial
download are described in SAP Note 429423. See also SAP Note 768503 “Documentation for
CRM Administration which refers to the “Best Practice for BDoc Message Analysis”. You should
monitor status E* and I* in SMW01.
Performance monitoring and analysis:

• The execution of SQL statements can be monitored using the database monitor ST04 as
described in the section "Monitor the database cursor cache."
• To find expensive SQL statements executed on the CRM server during the initial download the
ST05 trace tool can be used as described in the section "Performing an SQL Trace."
CRM Middleware Alert Monitoring
The CRM Middleware Alert Monitoring is based on the CCMS Alert Monitoring infrastructure. It is
accessed via transaction RZ20, where it is available under the "SAP CRM Monitor Templates" monitor
sets with the name "CRM."
The CRM Middleware Alert Monitor generates alerts if critical situations occur. The processes are
displayed as a tree structure in the monitor and the alerts are assigned to the nodes of the corresponding
processes. The responsible person can then be informed automatically.
For more details see SAP Note 437187.
The Download Monitor (R3AM1)
The main tool to be used for monitoring the initial download is the Download Monitor on the CRM
Middleware:
• CRM 4.0: Middleware >> Data Exchange >> Initial Load >> Monitor objects
© 2004 SAP AG
Time: The displayed time stamp corresponds to the start time of the processing of the recent block.
Block Nbr.: The number represents a counter for the number of successfully processed blocks.
P: a flag is set in case a parent object exist for this object.
If all the traffic lights are green, the download has completed successfully.
If a traffic light is yellow, choose Refresh and observe whether the block number increases. If so, the
download is still in progress. If not, an error has occurred during the initial download. To find and analyze
the error, check the monitors described in the following sections or follow the procedure given in the
section “Correcting errors in the processing of the inbound queue.”
Monitoring the outbound queues in the OLTP

To check the outbound queues on the OLTP server, execute transaction SMQ1 from the OLTP. To check
all outbound queues, enter "R3AI*" as queue name and press execute (F8). This gives a list of all active
outbound queues with their actual number of entries in the OLTP R/3. For each download request
started, there will be an active download queue. If the number of entries for a selected download queue
is increasing, the selection of the data in the OLTP is still active and the writing of the data in the CRM
server is slower than the selecting and preparing the data in the OLTP.
When double-clicking on a single ‘Queue name’ field, additional details are displayed. In this view you
can also reactivate a queue. If capacity overload situations occur, a second attempt to execute the queue
processing may be successful. If a second start of the queue is not successful and leads to a short
dump, you can find additional information in the short dump information displayed using transaction ST22
in OLTP.
By double-clicking on the Status field additional status information is displayed
Monitoring the inbound queues in the CRM Middleware

To check the status of the inbound queues in the CRM server, use transaction SMQ2. To check all
outbound queues, enter "R3AI*" as queue name and press execute (F8). This gives you a list of all active
outbound queues with their actual number of entries in the CRM server.
© 2004 SAP AG
When double-clicking on a single "Queue name" field, additional details are displayed. In this view you
can also reactivate a queue. By double-clicking on the "Status" field additional detailed information is
generated. By double-clicking on the "Queue name" field, an additional detail display is generated where
you can execute a transaction by selecting function module "BAPI_CRM_SAVE" and choosing
"EXECUTE LUW F6."
If the queue has the status "STOP" this may indicate a Customizing problem in the CRM application. For
further analysis, use transaction SMW01 as described in SAP Note 429423. See also SAP Note 768503
“Documentation for CRM Administration which refers to the “Best Practice for BDoc Message Analysis”.
Another example for a queue with the status "STOP" is the queue "R3AI_DNL_CUST_PROD2", which
stops with the status detail "the numbering scheme specified in table COMS_HIER_R3IMP does not
exist."
This is a Customizing problem in the CRM/EBP application. The solution is to correct and finalize the
Customizing before continuing the initial download by restarting the queue. Please keep in mind that the
Inbound queue on CRM site is used only if the flag “USE IN Q” is set in OLTP table CRMRFCPAR. This
flag is default delivered by SAP AG and recommended.
Monitoring the database cursor cache

To analyze the database cursor cache, use transaction ST04 and choose "Detailed Analysis" >> "SQL
request." This shows a list of all accesses to the database since database startup. To view the most
expensive SQL statements issued on the database, sort this list either by "buffer gets" or "disk reads."
If you mark one of these SQL statements and choose "Goto" >> "Explain SQL" from the menu, you can
view the Execution Plan for the statement. If you cannot find a suitable index, you can view the statistics
by means of the "Analyze" button. For tables with statistics which are empty or nearly empty before the
initial download, you should refresh the statistics from time to time during the download in order to see
the correct statistics.
Performing an SQL Trace

Perform a detailed analysis using an SQL trace (transaction ST05). These can be carried out by stopping
the queue and executing one LUW with an SQL trace in parallel. After this trace the queue should be
restarted. In transaction ST05, the SQL trace highlights in red those tables for which performance-critical
statements were run. You should then run a new SQL trace using Transaction ST05 to check that your
resolution of performance critical issues was successful and identify other performance critical tables.
Correcting errors in processing of the inbound queue

To correct the errors occurring during the processing of the inbound queue, read the error messages in
SMW01. The queue name gives information on the object for which the error has occurred. (For
example, queue name 'R3AI_CUSTOMER' indicates that the error has occurred in the BDOC with the
name CAPGEN_OBJECT_WRITE.) The error messages can be checked in the BDOC viewer
(Transaction SMW01) in the error segments.
Now edit these error messages. If you can correct all errors by correcting the Customizing in the CRM
system, you can simply restart the stopped entry from the inbound queue in the CRM system and the
system continues the initial download with the block that contains the incorrect customers.
If, however, you must correct one of the errors by correcting customer master data in the R/3 system,
you must delete all entries from the inbound queue in the CRM system and then restart the initial
download.
Note: For more details on correcting errors in the processing of the inbound queue, see SAP Note
306567. For a general overview of how to perform an error analysis of an initial load, see SAP Note
429423 and 768503.
© 2004 SAP AG
Initial load from a non-R/3 based OLTP

The communication between the non-R/3 OLTP system and the CRM middleware is necessary to
provide both systems with the necessary data to run the different business scenarios. The initial load
from a non-R/3 based OLTP system to a CRM system is possible as of Release CRM 3.0 using the
External Interface Adapter (XIF).
The CRM Middleware provides the following interfaces for initial or delta loads from/towards non-SAP
systems:
• XML messages / Intermediate Documents (IDocs) via ALE;
Business partner, hierarchy, relation – import / export
Business Transaction (sales / service order, activity) – import / export
Product – import
Condition – import
Invoice – export
• File based import;
SAP Data Transfer (DX) Workbench
ASCII Adapter
These interfaces allow data to be exchanged with legacy backend systems initially and on a regular
basis. Delta loads take place when changes to existing objects are made or when new objects are
created. The exchange of customizing data is not relevant to the data exchange with non-SAP backend
systems. Product configuration and marketing data is also not exchanged. The mapping between for
example legacy and SAP CRM has to be defined by the customer.
In inbound transactions, incoming messages in XML or IDoc format are received by the XIF adapter
via the basic services (SOAP, ALE) and converted into the structures in the mBDoc. The CRM
Middleware then starts calling an appropriate application validation service that updates the application
after successful checks on the message.
In outbound transactions, creating or changing a data object within an application transaction, an

mBDoc is created and transferred to the CRM Middleware. Possible external receivers for the mBDoc
are determined within the CRM Middleware and are transferred to the XIF adapter together with the
mBDoc. The data in the mBDoc is converted in the XIF adapter into an XML-like complex Data Structure
and an appropriate basic service (SOAP, ALE) is started that sends the Data Object to the external
receiver; for example, via a third party Middleware Tool.
© 2004 SAP AG
mBDoc flow
When you create or change data objects, the system generates a messaging BDoc (mBDoc) in the
outbound and passes it to the CRM Middleware. For the mBDoc, possible external recipients are
determined within the CRM Middleware and passed to the XIF adapter. In accordance with the
Customizing settings, the messages are distributed by means of IDocs or XML/SOAP outbound
processing. The function module CRMXIF_*_SAVE defines the CRM Online interface for the business
transaction for external systems. The interface is implemented as an adapter for CRM Middleware (XIF)
and provides both IDOC processing and processing for XML/SOAP calls. The corresponding IDOC
message type is: CRMXIF_*_SAVE_M. The business transaction interface functions as an inbound- as
well as an outbound transaction interface and is capable of handling mass data. There you are informed
about the required Customizing. If you do not want to be informed about each change, you have to define
corresponding filter criteria in the middleware.
ASCII file
The ASCII file is written from the legacy system. This file has the structure of the legacy system. The
Data Transfer Workbench (DX-WB) calls the Legacy System Migration Workbench (LSMW) for mapping
in the form of a job. The LSMW reads the ASCII file and converts it into the IDoc or XIF format. Then the
IDoc has the structure of the complex XIF structure. Thus, the only condition for the ASCII file is that it
can be represented on the IDoc by means of LSMW.
XML/SOAP
XML/SOAP is more general. Therefore, potentially more EAI tools can offer an XML/SOAP connection. In
this case it is important that the 3rd-party EAI (enterprise application integration) tool can offer
reasonable error handling because the XML/SOAP call may also return application errors. In this case,
the processing is synchronous. In general, the IDoc has a better performance. The error handling occurs
in the ALE inbound processing layer. That is, the 3rd party EAI does not have to have a detailed error
handling.
In this section are the most important recommendations for achieving good performance during the initial
load to CRM using the External Interface Adapter (XIF). Go through all subsections and verify if the
performance recommendations can be applied to your CRM solution.
Deactivation of status check and generation of change documents
When loading a large number of business partners into the CRM server, the following recommendations
have to be applied:
Recommendation: Deactivate the status check and deactivate the generation of change documents for
the business partner as described in SAP notes: 493026, 456929 and 493343.
During the data transfer via the XIF adapter, the system cannot decide automatically whether this is an
initial data transfer or an exchange of changes. Thus the status check and the writing of change
documents are always activated here. The deactivation of these two actions could improve the
performance. After the initial data transfer, it is necessary at least to deactivate the call indicator and to
activate the writing of change documents and the status check again.
See also SAP note 561321.
Recommendations when using the DX Workbench
If you use the DX Workbench apply the following recommendations:
• Do not set the block size in DX workbench to a value higher than 100. This is, however, only a
rule of thumb and depends on the object.
• Set the logging in the DX workbench to 'only errors'.
• The split of the data into several files can further improve the throughput. However, this involves
an increased administrative effort for the provision of the files, scheduling of the jobs and so on.
© 2004 SAP AG
• Set up a server group that is provided with as many dialog processes as possible. Use this
server group in the DX workbench. See also the DX workbench documentation. During parallel
processing, you must make sure that the limit for MAX ENQUEUE on the system side is set to a
high value.
For additional details regarding performance optimization when loading business partner data via
DXWB/XIF see SAP note 561321
Avoid initial download to CDB or BW
To make full use of the advantages of parallel initial download the data should not be directly loaded to
the CDB or BW during the initial load to CRM online.
Recommendation: The mobile bridge needs to be switched off to avoid the load to CDB. With CRM 4.0
it is possible to switch it off for all objects in transaction CMWC_SMW. If the flag “Data Sync Active” is
not set, the mobile bridge is deactivated. In addition the creation of the CSA* queues for these objects
should be deactivated. With CRM 4.0 this is possible in transaction SMW3_00. The deactivation needs to
be carried out per BDOC type. For details see also SAP note 635697. This deactivation of the CSA*
queues also switches off the delta load to BW for objects which are transferred to the BW via m flow. In
general you should make the initial load to the CRM server first and then the initial load to the BW.
For some cases you may decide to have the CSA* queue active. In these cases avoid creating too many
CSA*-queue entries. Therefore change the data type related entry in Table SMOFQFIND.
As an example: one CSA-queue will be generated containing one entry for each activity document when
loading activities occur in the CRM system and the creation of CSA-queues for the activities is not
switched off as described in SAP note 635697.
Recommendation: From a performance point of view it is more efficient to have a low number of queues
containing several entries. To reduce the number of queues for activities adjust the entry for TR_GNAME
= BUS_TRANS_MSG in table SMOQFIND. To have a maximum of 99 entries per queue by using the
last 2 characters of the object instance, set FLDOFFSET to 8 and LENGTH to 2. This procedure can be
used also for other object types.
Notes have to be implemented in addition to the customizing settings which have to be performed in
transaction SMW3_00 for some application Objects. The Notes are described in the table below:
SAP Note Content BDOC Included in
650624 Suppressing BDOC generation in CRM Server BUPA_MAIN, 4.0 SP03
BUPA_REL
738562 Create no BDOCs for TGs if MSA is not installed TG_MSG 4.0 SP07
705953 CRM Standalone: Deactivate messaging flow for BUS_TRANS_MSG 4.0 SP06
BUS_TRANS_MSG
711267 MSA is not active -> suppression of BDOC creation CHAR_MSG, 4.0 SP06
PFTPL_MSG
710606 No MSA in use, no creation of Bdocs desired CHARVAL_MSG 4.0 SP06

Testing is mandatory in order to get an idea of how long the initial download will run (this can take
several days, or even up to two weeks) as runtime can be critical for the project time plan. Test phases of
one or several weeks should be considered because different errors (especially because of missing
customizing) can occur.
For details on the recommended procedure please refer to the section “Test runs and time frame for the
initial download”

Parallel processing has to be used to increase the throughput on a multiprocessor server. When loading
data from an external system to CRM, at least two different methods of parallel processing have to be
taken into account.
© 2004 SAP AG
Parallel processing when using the Data transfer workbench

When using the Data transfer workbench (SXDA) parallel processing has to be implemented by creating
several run definitions with different file names in one sub-project and then starting runs in parallel.
In the SXDA the actual data transfer from a file is carried out in a run. When the run is started, all the
tasks of the run definition are carried out in sequence when the associated programs are called.
Parallel processing when using IDOCs
Another way of loading data is using IDOCs. If the needed message type is not available you have to
developed it yourself. The IDOCs can be created in several ways, e.g. using the SAP Business
Connector. To load the data to the CRM database the IDOCs have to be processed using report
RBDAPP01. The make use of parallel processing using report RBDAPP01 proceed as follows:
1. Start report RBDAPP01 using transaction SE38
2. Switch to the tab ‚Parallel Proc.’
3. Mark the Checkbox ‚ Parallel Proc. Active’
4. Use the F4-help to select a server group.
5. Switch to the tab ‚IDOC selection’
6. Enter the IDOC numbers to be processed or any other selection criteria you need in order to specify
which IDOCs are to be processed
7. Define a useful package size and enter it in the field ‘Pack size’
8. Start the run
Definition of the Package size
The Package size defines how many IDOCs are processed in one package. To optimize the runtime you
should bundle IDOCs in packages of 10 IDOCs or more. The optimum package size can only be
determined by a test run. For sales orders you should normally use package size 1. For another object it
may be appropriate to use a package size of 1000.
When using the parallel processing option the packages will be distributed to all available work
processes for RFC processing when report RBDAPP01 is started. When a work process has finished the
processing of a package, the report will dispatch the next package to the free work process. This
continues until all packages have been processed.
The only way to define the degree of parallel processing is by limiting the available work processes for
RFC processing and to define RFC server groups
RFC Parameter settings for parallel processing
To limit the available work processes for RFC processing check the setup for the RFC resource
parameter "rdisp/rfc_min_wait_dia_wp". This parameter describes the number of dialog work processes
to be kept free, so they cannot be used by incoming RFC calls. E.g. if you have 13 dialog work processes
configured and you want a maximum of 10 to be used by RFC calls, the parameter
increase this parameter to at least 3 before starting the initial download. On the other hand the parameter
must not be set too high. If you have 13 dialog work processes configured and you want 10 work
processes for RFC processing in parallel, you must not set this parameter higher than 3.
To avoid overloading of your CPU resources you have to adjust this parameter according to the available
CPU resources on the server. In general the number of work processes for RFC processing should not
exceed 1.5 times the number of available CPUs.
Configuration of the parallel processing on the CRM server
and you want to use several servers for parallel processing of the initial load, you have to define an RFC
server group on the CRM system which includes these servers.
© 2004 SAP AG
Note: If you have several Application servers and one Database server we recommend excluding the
database server from the RFC server group to avoid overloading the database server.
Optimizing the Initial load from CRM online to

CDB
If you want to setup a mobile sales scenario, the data has to be not only loaded to the CRM server but
also to the mobile client. This makes the initial load process more complex and may also increase the
need for performance optimization for the initial load process. In the case of a mobile sales scenario, the
business data has to be transferred to the CRM Application tables, to the consolidated database (CDB)
and to the mobile clients. To avoid performance bottlenecks on the CRM server, these three steps have
to be separated and performed in a 3-step procedure:
1. Initial load to CRM Application tables (CRM Online)
2. Initial load to consolidated database (CDB)
3. Initial load to mobile clients
The second step is discussed in this section. For the first step see sections described earlier in this
document dependent upon the data source. The first paragraph has some general performance
recommendations.
Before you can start the initial download from CRM online to CDB you have to activate the mobile bridge
for the corresponding object and deactivate the general switch for the mobile bridge. The CSA* queues
also have to be reactivated. See also the section “Avoid initial download to CDB”.

In this section you will find the most important recommendations for achieving a good performance
during the initial download. Go through all subsections and verify if the performance recommendations
can be applied to your CRM solution. The main Note for performance issues regarding the initial
download is SAP Note 350176
Setting the middleware trace level parameters

In order to log CRM application errors, the middleware trace must be switched on during the initial load.
As only error information is required, the middleware trace level can be reduced to level "1" for all trace
environments of the Middleware trace except for 'G' (generation). For this purpose, choose the following
path in the SAP Menu 'Architecture and Technology -> Middleware -> Monitoring -> Message Flow ->
Set up Middleware Trace' and choose 'Set default settings'.
To regularly delete outdated trace and log information, schedule report SM06_REORG on a regular basis
as described in SAP Note 206439
Delete trace data and BDOC message administration tables before and after the
initial download has successfully completed
During an initial download, large data sets may be written in the middleware trace and the BDoc
message store. During the first part of the initial download the load from R/3 to CRM online, the
SMWT_TRC and the BDoc store tables SMW3_BDOC*, may already be filled.
Recommendation: To delete the data before or after the initial download was completed successfully,
schedule report SM06_REORG for the reorganization of the log tables as described in SAP Note
206439. The reorganization job deletes data in the tables. Please take into account that the standard
variant holds the data from the last 7 days. Therefore with the initial download it makes sense to reduce
the value “days to hold” to zero after you have checked that the initial download has functioned correctly.
For Oracle the indexes should be rebuilt as described in SAP note 435125.
© 2004 SAP AG
Reorganize BDOC message related object links before and after the initial
download completed successfully
During the initial download many entries may be written to the tables SMW0REL and SRRELROLES due
to BDOC message related object links. These tables may already be filled during the first part of the
initial download the load from R/3 to CRM online.
Recommendation: To reorganize the data before or after the initial download has completed
successfully schedule the report RSRLDREL as described in SAP note 493156. In this special case (the
initial download) you should set the end date in such a way that as many links are reorganized as
possible.
Please see also SAP note 691628. With this note you can deactivate the writing of links between
outbound mBdoc messages and sBDoc messages.
CRM Server Performance: RFC Queue processing

The qRFC is part of mySAP Basis Technology. qRFC releases are decoupled from the CRM release
cycle and ongoing performance improvements are realized in the different versions. For releases lower
than Basis Release 6.20 the qRFC version is an extra transport. For Basis Release 6.20 or higher, you
can only import the current qRFC version via a Support Package.
Recommendation: Always use the latest qRFC version. You should update qRFC on both the CRM
server AND the connected OLTP R/3 system.
Implementation: To obtain the newest qRFC release, see SAP Note 438015.
Note: After the implementation of a new basis support package, verify if the qRFC version is still the
latest. Some basis support packages may contain older qRFC versions. For Oracle DB with Supplement
11please implement SAP note 742950 to avoid performance problems.
In this section you find a list of the actual SAP Notes containing program enhancements related to qRFC.
SAP Note Content Release
539917 SQL error 601 in accessing "ARFCRSTATE" table 6.20
683459 qRFC performance improvements in the inbound scheduler 6.20, 6.30
697884 Queues in SMQ2 are not processed 6.20
742950 Performance affected on Oracle DB with Supplement 11 6.20
744869 Optimizing the performance of inbound scheduler 6.20, 6.40
Recommendation: For a general overview on queuing in CRM and R/3 and information on queue
names used and their respective functions in the CRM server and R3 backend, see SAP Note 765236
Reorganize Key-Gen Table

Table SMO9_KYTBL contains GUID keys and is used temporarily during the initial download. A
performance loss during table lookups can occur when table SMO9_KYTBL contains too many entries
(for example, more than 50 000).
Recommendation: Start report SMO9_CLEAR_KYTBL manually (via transaction SE38).
SMO9_CLEAR_KYTBL is part of the report SMO6_REORG, which should be scheduled every night.
Optimizing the performance for Oracle Database
To prepare an Oracle database for the initial download proceed as follows:
• To optimize "FOR ALL ENTRIES" statements set the parameters as described in SAP note 634263.
• Schedule Report SMO6_MAINT_STATISTIC in such a way that it is exited before the regular
"update statistics run" begins. It could also make sense to run this report and "update statistics run"
between two initial downloads.
© 2004 SAP AG
Inactive sites
If you already have sites with assigned subscriptions you should deactivate these sites in SMOEAC to
avoid filling the outbound queues. If you have not set up the assignment of subscriptions to mobile clients
you should do this after the initial download to CDB.

To get an idea of how long the initial download will run (this can take up to several days, or even two
weeks) testing is mandatory as runtime can be critical for the project time plan. Test phases of one or
several weeks should be considered because different errors (especially due to missing customizing) can
occur.
For details on the recommended procedure please refer to the section “Test runs and time frame for the
initial download”

Parallel Processing of the Initial Download is very effective for objects that have very extensive data sets.
For example, for the download of business partners, parallel processing of the initial download may be
necessary to process the data in the given time frame. Parallel processing is described in detail in SAP
Note 350176.
Configuration
Configuration is analog to the Initial Download “Parallel Processing on the CRM Server”.
Queue Setup for Parallel Processing
To optimize the runtime of the initial download on the CRM middleware server, the number of download
queues to be run should be high. For information on how to determine the number of queues, see the
section entitled Parallel Processing on the CRM Server
Configuration of parallel download processing on the CRM server
and you want to use several servers for parallel processing of the initial download on the CRM site, you
have to define an RFC server group on the CRM system including these servers and change the AS
group accordingly in SMQR.
In addition you should check that the “Max. Runtime“is set to 60s which is the default value. For large
queues it makes sense to set the value to 300s.
Configuration of parallel processing for specific download objects

Parallel processing can be set up per download object.
Implementation: To process individual objects in parallel, make an entry in table CRMPAROLTP for
each download object (for example MATERIAL). For example, if you want to run 5 queues in parallel for
the download object PRODUCT_MAT, the entry in table CRMPAROLTP (SM30 in the CRM) should look
like this:
Parameter name: CRM_MAX_QUEUE_NUMBER_INITIAL
Parameter name 2: PRODUCT_MAT
Parameter name 3:
Consumer: CDB
Parval1: 5
Note: For more detail, see SAP Note 350176.
© 2004 SAP AG
Parameter settings for parallel processing of the initial download

In addition to the setup of the number of queues to be run in parallel some parameters must be checked
on the CRM server to ensure that the configured number of queues can really be processed on the CRM
server:
• Be sure that the number of dialog work processes configured on the CRM server is higher than
the number of queues you want to run in parallel. To have additional free work processes
available for administrative purposes such as monitoring the initial download, there should be at
least 3 more dialog work processes available than the number of queues to be run in parallel.
For example, if you want to run 10 queues in parallel you should have at least 13 dialog work
processes configured on the CRM server.
• Make sure that not all available dialog work processes are occupied by queue processing.
Therefore, check especially the setup of the RFC resource parameter
"rdisp/rfc_min_wait_dia_wp". This parameter describes the number of dialog work processes to
be kept free, so they cannot be used by incoming RFC calls. E.g. if you have 13 dialog work
processes configured and you want a maximum of 10 to be used by RFC calls, the parameter
increase this parameter to at least 3 before starting the initial download. On the other hand the
parameter must not be set too high. If you have 13 dialog work processes configured and you
want 10 queues be processed in parallel, you must not set this parameter higher than 3.
• Please take into account that the maximum number of parallel initial loads is restricted by the
parameter MAX_PARALLEL_PROCESSES in table SMOFPARSFA. The delivered standard
value is 5. The number of processes contains initial loads and requests. See also SAP note
429423.
• Refresh the DB statistics during the initial download.
How to Start the Initial Download

In this section the procedure for starting the initial download is described. The transaction for starting the
Initial Download can be found at
• CRM 4.0: Middleware >> Data Exchange >> Initial Load >> Start (Transaction R3AS).
The initial download from CRM online to CDB is started in the same manner as the download from OLTP
to CRM online. However, load object sender and receiver are different.
© 2004 SAP AG
Initial download of objects after the primary

initial download
It is possible that you will need to replicate the initial download after you have carried out the initial
download for the entire object. Normally this system is already live. In this case you should not switch
off the mobile bridge again in order to make the initial download in two sections. The SMW3_00 for
switching off the CSA* queues should also not be used. When starting the download from OLTP to CRM
online, the mobile bridge is activated to avoid problems with delta processing because the system is
already live.
© 2004 SAP AG
Further Information
SAP Notes
SAP Note Content Release
539917 SQL error 601 in accessing "ARFCRSTATE" table 6.20
683459 qRFC performance improvements in the inbound scheduler 6.20, 6.30
697884 Queues in SMQ2 are not processed 6.20
742950 Performance affected on Oracle DB with Supplement 11 6.20
744869 Optimizing the performance of inbound scheduler 6.20, 6.40
Background Information and References

Additional Information can be found in the following documents
• SAP Configuration Guide in solution manager
Feedback and Questions
Send any feedback by formulating an SAP customer message to component SV-GST. You can do this at
http://service.sap.com/message.
© 2004 SAP AG
© Copyright 2005 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of
SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software
vendors.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of
Microsoft Corporation.
IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400®
are registered trademarks of IBM Corporation.
ORACLE® is a registered trademark of ORACLE Corporation.
TM
INFORMIX®-OnLine for SAP and Informix® Dynamic Server are registered trademarks of Informix Software Incorporated.
® ® ® ®
UNIX , X/Open , OSF/1 , and Motif are registered trademarks of the Open Group.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium,
Massachusetts Institute of Technology.
JAVA® is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT® is a registered trademark of Sun Microsystems,
Inc., used under license for technology invented and implemented by Netscape.
SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI,
SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in
Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks
of their respective companies.
Disclaimer: SAP AG assumes no responsibility for errors or omissions in these materials. These materials are provided “as is”
without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability,
fitness for a particular purpose, or non-infringement.
SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages
that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text,
graphics, links or other items contained within these materials. SAP has no control over the information that you may access
through the use of hot links contained in these materials and does not endorse your use of third party Web pages nor provide any
warranty whatsoever relating to third party Web pages.
© 2004 SAP AG

Intiail Download Guide

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Intiail Download Guide

Transféré par

Droits d'auteur :

Formats disponibles

Best Practice: mySAP CRM Initial download configuration 1

mySAP CRM Initial Download Configuration

Best Practice for Solution Management

Version Date: November 2004

Applicability, Goals, and Requirements

Goal of Using this Best Practice

Staff and Skills Requirements

How to Use this Best Practice

Best Practice Procedure and Verification

Main Focus of this Best Practice

Optimizing the Initial load from an R/3 based

Reducing Data Volume during the Initial Download

Using filter Settings for the Initial Download

Activation object specific

Filters for Material Master

Filters for Sales Documents

Performance of the initial download

Initial download after a test of the initial download

Data transfer using XML

Test runs and time frame for the initial download

Parallel Processing of the Initial Download

Parallel Processing on the CRM Server

Test measurements for the initial download

Queue Setup for Parallel Processing

SETUP OF PARALLEL DOWNLOAD ON CRM MIDDLEWARE

Total time frame available 72 Total time 31,2

Procedure – Final Conclusion:

Configuration of the parallel download processing on the CRM server

Configuration of parallel processing for all download objects

Configuration of parallel processing for specific download objects

Parameter name: CRM_MAX_QUEUE_NUMBER_INITIAL

Parameter settings for parallel processing of the initial download

Parallel Processing on the OLTP Server

Parallel Processing on OLTP and CRM Servers

How to Start the Initial Download

Deregistering the delta download queues

Starting the initial download

Initial load of Customers

Monitoring the initial download

How the initial download works

The data flow consists of the following steps:

Tools for monitoring the initial download

Performance monitoring and analysis:

Monitoring the outbound queues in the OLTP

Monitoring the inbound queues in the CRM Middleware

Monitoring the database cursor cache

Performing an SQL Trace

Correcting errors in processing of the inbound queue

Initial load from a non-R/3 based OLTP

In outbound transactions, creating or changing a data object within an application transaction, an

Test runs and time frame for the initial download

Parallel Processing of the Initial Download

Parallel processing when using the Data transfer workbench

Optimizing the Initial load from CRM online to

Performance of the initial download

Setting the middleware trace level parameters

CRM Server Performance: RFC Queue processing

Reorganize Key-Gen Table

Test runs and time frame for the initial download

Parallel Processing of the Initial Download

Configuration of parallel processing for specific download objects

Parameter settings for parallel processing of the initial download

How to Start the Initial Download