Professional Documents
Culture Documents
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 2
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.
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 3
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
Best Practice: mySAP CRM Initial download configuration 4
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 5
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.
Here are some typical examples illustrating how filter settings are used to reduce the data volume:
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 6
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 7
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 8
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 9
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.
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 10
• 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
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 11
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
Best Practice: mySAP CRM Initial download configuration 12
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 13
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.
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 14
• 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.
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 15
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
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 16
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.
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 17
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 18
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
Best Practice: mySAP CRM Initial download configuration 19
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 20
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.”
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 21
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.
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 22
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.
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 23
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.
Performance of the initial download
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
Best Practice: mySAP CRM Initial download configuration 24
• 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
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 25
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 26
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.
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
Best Practice: mySAP CRM Initial download configuration 27
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.
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
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 28
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.
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
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 the default value. For large
queues it makes sense to set the value to 300s.
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 29
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 30
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 31
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
© 2004 SAP AG
Best Practice: mySAP CRM Initial download configuration 32
© 2004 SAP AG