Professional Documents
Culture Documents
New Landscape of Sap
New Landscape of Sap
Contents
Applicability, Goals, and Requirements ....................................................................................................2
Best Practice Procedure and Verification .................................................................................................3
Introduction.........................................................................................................................................3
General Background Information .......................................................................................................4
Main Focus of this Best Practice..................................................................................................7
Potential Risks..............................................................................................................................7
Possible System Copy Procedures..............................................................................................9
Procedure for System Copy of SAP CRM Server and SAP R/3 OLTP System ...............................10
Preliminary Tasks .......................................................................................................................10
Preparations for mySAP CRM System Copy .............................................................................10
General Description of System Copy Procedure .......................................................................10
Detailed Description of System Copy Steps...............................................................................14
Verification ........................................................................................................................................28
Further Information .................................................................................................................................28
Applicability
This Best Practice is valid only for making a system copy of a complete mySAP CRM system
landscape (both SAP CRM server and SAP R/3 OLTP system). Copying only the SAP CRM server or
only the SAP R/3 OLTP system is not covered by this document.
All the non-ABAP components, such as IPC and Communication Station, should be newly installed in
the target landscape and configured if required.
This Best Practice is valid only for an SAP CRM 3.0 system landscape. System copy procedures for
SAP APO, SAP BW, and so on are not covered by this document.
This Best Practice does not describe the procedure and post-customizing of a client copy within a
mySAP CRM system landscape.
Updates and corrections to this document can be found in SAP Note 564435.
Caution
Up to now, mySAP CRM system landscape copy is not generally released and can be performed
only as a Pilot Project.
For detailed information, see SAP Notes 543715 and 82478 and the SAP OS/DB Migration page
in SAP Service Marketplace (http://service.sap.com/osdbmigration).
The SAP Notes contain the most recent information regarding the system copy of a non-R/3
system (such as SAP APO, SAP BW, SAP CRM, SAP EBP) and the methods recommended for
the system copy.
Components in this Guide
SAP CRM Server
System copy
Customizing
System copy
Customizing
You must have a contact person available onsite who can process SAPNet R/3 Frontend messages
concerning problems with system landscape copy.
2002 SAP AG
OS/DB Migration Procedure for SAP BW, EBP, CRM, SCM, and Enterprise Portal
If you want to change the operating system or the database system during a copy of a mySAP.com
component system (SAP BW, EBP, CRM, SCM, or mySAP Enterprise Portal) you need to order and to
use the SAP OS/DB Migration Service.
2002 SAP AG
The SAP OS/DB Migration Service is also available for customers with mySAP.com solutions. Based
on experience with the already established procedure for the SAP R/3 environment, SAP has
extended the procedure for SAP BW, EBP, CRM, SCM, and mySAP Enterprise Portal.
The rules of the migration procedure are also valid when executing a heterogeneous system copy of a
mySAP.com component. This system landscape copy guide must be used in conjunction with the
standard Heterogeneous System Copy Guide.
The migrations must be performed by consultants who have been specifically trained for these types
of migrations.
For information concerning the migration procedure, see SAP Note 82478 and the SAP OS/DB
Migration page in SAP Service Marketplace (http://service.sap.com/osdbmigration). This page also
contains the SAP OS/DB Migration Fact Sheet and the SAP OS/DB Migration Planning Guide.
Difference Between Copy of mySAP CRM Solution and Copy of SAP R/3
System
In contrast to the SAP R/3 OLTP system, the mySAP CRM solution uses several SAP and non-SAP
components to implement cross-system processes. SAP systems are part of a system group of many
different components and hosts. Data is not held centrally in a single SAP R/3 System but is
distributed between several SAP systems. Data is often held redundantly, but each system may also
hold originals of some pieces of data. Data transfer between the systems is automated and must
ensure that data is always consistent between the participating systems. There may be different input
sources for the same type of data in the same system. For example, sales orders in the OLTP system
can originate from the Internet via the SAP CRM server or can be entered directly in the OLTP
system.
From a technical point of view, data may be held in databases provided by different database vendors
or may even be held directly in files without using a database at all. There is no common checkpoint
between the component systems and thus no common point of consistency, because data is
constantly and automatically exchanged between systems.
From that point of view, a copy of a mySAP CRM system landscape is different from a standard SAP
R/3 System copy. To determine what additional requirements an SAP CRM system copy procedure
must fulfill, consider the new questions that may arise beyond those for an SAP R/3 System copy.
1) A mySAP CRM solution landscape consists of many different components that have
dependencies between each other. So questions such as the following arise:
Is there any procedure to copy all these components together with their dependencies
and current configuration or should they be newly installed and configured
afterwards?
2) All the components in a mySAP CRM solution landscape are connected each other and
exchange data constantly. So questions such as the following arise:
3) Normally, during the system copy, some of the parameters, such as SIDs, host names, logical
system names, and RFC destinations, are changed. These parameters are used in the system
for defining communication configuration, layout configuration, and so on. So questions such
as the following arise:
If these parameters are used as part of the data, how can I ensure data consistency
after the system copy?
2002 SAP AG
Which combinations of release and platform are supported for these tools?
Note: The larger volume of individual components and their more complicated relationships in non-R/3
systems (for example, data is exchanged between the individual system components) place much
greater demands on the copy procedure. Improper use of the copy procedure can corrupt data, or can
cause data to be sent to an incorrect system component (this cannot be corrected later). Because of
these special features, which are not supported by tools and not documented, this type of system copy
cannot be generally released. For this reason, a pilot phase has been defined for copying non-R/3
systems. In this pilot phase, the migration tool development team gathers non-R/3 system copy
requirements. This information is gathered by taking part in customer projects, finding solutions, and
integrating them into the tools.
For detailed information, see SAP Notes 543715 and 82478 and SAP Service Marketplace
(http://service.sap.com/osdbmigration). These SAP Notes contain the most recent information
regarding the system copy of a non-R/3 system and the methods recommended for the system copy.
Preliminary
preparations
Prepare the
source systems
for copy
Prepare the
middleware of the
source systems
Before system
copy procedure
SAP system
copy procedure
Adjust the
middleware of the
target systems
After system copy
procedure
Downtime
mySAP CRM specific data handling procedures
2002 SAP AG
Potential Risks
This section defines some key requirements for the system copy procedure. For example, one of
these may be data consistency in the target system. To meet these requirements, we need to examine
the entire procedure and outline possible problems. After that, we can consider how these problems
may be solved and whether we need to change the system copy procedure.
For an SAP CRM system landscape copy, there are two main potential problems:
2002 SAP AG
For these reasons, changing the logical system names in these unknown tables can lead to
unexpected data inconsistency or improper application work. The results are unpredictable and may
have a big impact on business processes.
From this point of view, it is very important to analyze the potential risks before the system copy and
answer the question:
Is it always necessary to change the logical system names after the system copy?
The answer depends on the type of the target system.
Building up a Production System
You may plan to change the hardware, SAP System ID, database, or operating system used in the
production environment. In this case, the new production system is built up from the old one by means
of system copy. The main requirement for the system copy procedure is that the new production
system is identical to the old one in all respects.
For this reason, after the system copy the new production system must have the same logical system
names.
Building up a DEV, QA, or Test System from the Production System
Normally, in a new CRM system landscape, you should avoid renaming any logical systems. Instead,
you should redefine all RFC destinations so that there is no longer a connection to the original system
landscape. On the other hand, for test, QA, and development systems, data consistency is not such a
strict requirement. For these systems, if you change the logical system names, there is time to detect
possible inconsistencies and convert the relevant tables.
In most cases of database migration or hardware changes, the SAP System ID does not need to be
changed. In these cases, there is no need to change the logical system names and the Customizing.
The system copy is a purely technical procedure.
Conclusion
Never change the logical system names in production systems!
For non-production systems, you may change the logical system names, but this may not be
necessary.
Production Production
Inbound and outbound queues (R/3 CRM, CRM CDB, CDB Contrans) do not
need to be processed fully before starting the system copy, as they will be processed
afterwards. If possible, for R/3 CRM, it is recommended to empty the inbound and
outbound queues by the normal workflow.
Procedure: Production/QAS/
QAS/Test/Dev/other non-Production
Requirements:
SID and logical system names may be changed in the target system
It is not necessary to process inbound and outbound queues (R/3 CRM, CRM CDB,
CDB Contrans) fully before starting the system copy. They will be processed afterwards.
The newly copied system is run initially with the old logical system names until the queues are
empty. After the queues are fully processed, the logical system names are changed. During
this initial procedure, before the logical system names are changed, the newly copied system
should run in its own network environment that is separated from the source system. This
prevents it from sending data to the source system.
If you change logical system names and RFC destination names, you can create inconsistencies!
2002 SAP AG
10
Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations
resulting from customer problem messages
Check all the documents and SAP Notes mentioned in this document
Define the key requirements that the newly copied systems should meet.
Define the exact changes that will be made during the system copy to hardware, host names,
operating system, database, SID, logical system names, and so on.
Estimate the potential risks created by these changes: analyze the possible workarounds and
ask if it is really necessary to make the changes.
Define the system copy procedure based on the key requirements and potential risks.
Contact the SAP Development team to verify the system copy procedure and potential risks.
Prepare the detailed project plan for system copy, including the verification procedures after
the system copy.
11
Notes:
To avoid data inconsistency, never copy an individual CRM system but always the entire
system landscape (both SAP CRM server and SAP R/3 OLTP system).
Copying CRM server and SAP R/3 OLTP system consists of similar steps. Therefore, the
following procedures are written to be valid for copying both CRM server and SAP R/3
OLTP system. If some actions should be performed only for the CRM server or if they are
performed differently on the two components, the corresponding step is marked
accordingly.
During the new installation of a component, you can choose the new host name and SAP
System name <TARGET_SAPSID> freely.
The system copy templates for using the R3load method (DBEXPORT.R3S and
DBMIG.R3S) have not been released officially and therefore are not delivered with the
CRM installation CDs or the migration CDs. These templates are delivered after you
have registered for a pilot project.
Generally, all non-ABAP components (such as IPC and TREX) must be preinstalled
manually using the standard Installation Guides.
Use an SAP-standard database copy procedure to provide source data to the CRM
server and the SAP R/3 OLTP system.
If you require a data-consistent system copy, the source system must be in offline mode
and contain no open tasks, update requests, or other open activities. When copying a
multiple-system environment, all involved systems must fulfill this requirement.
After you have executed the technical installation and database copy, you can adjust the
new CRM system, the R/3 backend system, and the other CRM components to the new
environment as described in this document.
A technical consultant who is specifically certified for system copy should carry out the
system copy procedure onsite.
We recommend that you perform the actions as they are described in this document. If
you want to perform a procedure that deviates from the ones listed in this document,
please contact SAP first.
All system copy procedure corrections and updates can be found in SAP Note 564435.
Important: After the system copy, the new CRM server must not be able to connect to
the production servers. Otherwise, at the first CRM system startup, data can be transferred
automatically to the production system, thus making the production data inconsistent.
To deactivate the automatic server connection, use one of the following methods:
Deactivate the network route on the new server to the production systems.
Prohibit the connection within the SAProuter (see SAP Note 30289).
Remove the new server from the Name Server service (DNS / WINS) and delete entries
for the source systems from the hosts / lmhosts file, to prevent any network connection to
the source system.
The phases and subsequent steps for each procedure are illustrated in the following diagrams.
2002 SAP AG
12
Production Production
Source Landscape
Phase1: Preliminary
preparations
Target Landscape
1
Production
Phase 2: Preparing
the source systems
for system copy
procedure
5
Phase 3:
Preparing the
middleware
6
before system
copy
Phase 4: System
copy procedure
10
Copy the systems by means of the
recommended methods
Production
2002 SAP AG
13
Source Landscape
Phase1: Preliminary
preparations
Production/QA/DEV/
Phase 2: Preparing
the source systems
for system copy
5
Phase 3:
Preparing the
6
middleware
before system
copy
7
11
12
13
Yes
Phase 4: System
Copy procedure
9
Phase 6: Start
23
Production
System
24
Production/QA/DEV/
2002 SAP AG
No
14
Stop and unregister the inbound and
outbound queues on R/3 and CRM
15
Queues are
empty?
16
17
18
19
20
21
22
14
2002 SAP AG
15
Step 4: Perform backup of all the components in the mySAP CRM solution landscape
Task of step
Before beginning the SAP CRM system landscape copy, we recommend that you perform a full
backup of all the components that are involved in the system copy. This step is optional and may be
skipped.
What to do in case of problems
Check the Best Practice Backup and Restore for mySAP.com.
Step 5: Preparing the source systems for export
Task of step
To make a consistent copy of the database, you need to prepare the source system and carry out the
subsequent actions on the target system.
Where
On both sides (SAP R/3 OLTP and SAP CRM server)
What to do
Generally, these preparations for both of the system consist of the following actions:
Check that no canceled or pending update requests exists in the system (transaction SM13).
If canceled or pending updates exist, these must be updated again or deleted from all clients.
Adapt the operation mode timetable to make sure that no switching of operating modes takes
place while a system is being copied (transaction SM63).
Make sure you have deleted QCM tables from your system as described in SAP Note 9385.
No upgrade-prepare is performed
Check the consistency of the database and the ABAP dictionary (transaction DB02).
Ensure that the ABAP Dictionary contains all the database tables.
Check SAP Note 407123 regarding SAP Web AS 6.10 system copy and SAP Note 89188
regarding SAP R/3 System copy.
Caution: This action list is only a general summary to give an indication of what is required.
In actual practice, you should prepare the source CRM server and SAP R/3 OLTP systems for the
export procedure in accordance with the SAP Web Application Server Homogeneous/Heterogeneous
System Copy Guide (Chapter General Preparations) for the CRM server and the System Copy Guide
corresponding your SAP R/3 release for the SAP R/3 OLTP system. Take care to check the latest
version of these guides and also all the SAP Notes mentioned in these guides.
Perform the system copy of the CRM server as described in the standard SAP R/3 System Copy
Guide.
To access the installation guide, go to Installation/Upgrade Guides in the SAP Service Marketplace:
http://service.sap.com/Instguides.
R/3 OLTP: Path: SAP R/3 Release "<your R/3 Release>" Chose Installation/ Copy Guide
CRM Server: Path: mySAP CRM SAP CRM 3.0 Installation Guides"
2002 SAP AG
16
Step 6: Save the initial configuration of all the parameters, queues, RFC destinations, and so
on before changing them
Task of step
We recommend that you save the information about the initial state of the parameters to be changed
before system copy. This information may be useful, for example, to start the source production
system after the copy or to compare the source and target systems. In this case, you need the
information about the parameter values before the copy.
Where
On both sides (SAP R/3 OLTP and SAP CRM server)
What to do
You can save the screen shots of the transactions SMQR, SMQS, SM59, as images or text files.
Step 7: Unregister the inbound and outbound queues on SAP R/3 and SAP CRM sides
Task of step
Break the connection between the systems to prevent automatic start of RFC data processing
between the systems at the first startup of the newly copied systems. This helps to preserve data
consistency in the source and target systems.
Where
On both sides (SAP R/3 OLTP and SAP CRM server)
What to do
1) Start transaction SMQS on both sides and unregister all the destinations of the connected systems
(R/3 CRM, CRM CDB, CDB Contrans). In this case, the destination is temporarily
unregistered. All entries with these destinations remain in the recorded transmission state until either
the destination has been registered or the entries have been manually activated using transaction
SM58 (for tRFC) or SMQ1 (for qRFC).
Normally, you can see in transaction SMQS only the destinations that are manually registered.
Therefore, make sure that you unregistered the outbound destinations for all the connected systems
(CRM, R/3, BW, APO, ).
2002 SAP AG
17
SMQS
2) Start transaction SMQR and unregister all the inbound queues in both SAP R/3 and SAP CRM
systems. We recommend that you can use wildcards in queue names (for example, BASIS_TEST_*)
to improve the performance of the QIN Scheduler.
SMQR
2002 SAP AG
18
438015
400330
369007
460235
480543
Step 8: Change the RFC destinations on SAP R/3 and SAP CRM side
Task of step
Change all RFC destinations that can be used by the SAP CRM server and SAP R/3 OLTP system to
communicate with each other and with other systems (SAP APO, SAP BW, external non-R/3
systems).
You need to prevent the new systems from sending data to the source systems after system copy.
Where
On both sides (SAP R/3 OLTP and SAP CRM server)
What to do
To change RFC destinations, use transaction SM59. For example, you can change the host name by
adding a string like .syscopy. Then the host name points to a nonexistent server and communication
is impossible via this destination.
Note: If you have only the SAP CRM server and SAP R/3 OLTP system, change the RFC destinations
responsible for communication between SAP R/3 OLTP and SAP CRM on both sides. Normally, these
are <CRM SID>CLNT<CRM Client> and <R/3 OLTP SID>CLNT<R/3 OLTP Client>, but the names
may be different.
If you have other systems, such as SAP APO or SAP BW, you should also change the RFC
destinations pointing to these systems.
Remember to unregister the queues before changing the RFC destinations. This prevents
communication errors during the processing the queue entries.
How to check that step is successfully performed
You can test the connection by choosing Test connection.
2002 SAP AG
19
SM59
20
Step 10: Adjust RFC destinations and establish communication between the SAP R/3 and SAP
CRM systems
Task of step
The new systems (SAP CRM server and SAP R/3 OLTP) are unable to communicate each other
because RFC destinations point to nonexistent servers and the inbound and outbound queues are
unregistered. The main purpose of this step is to adjust the parameters responsible for communication
between the SAP R/3 OLTP system and the SAP CRM component system.
Where
On both sides (SAP R/3 OLTP and SAP CRM server)
What to do
In the new system environment, use transaction SM59 to check the RFC destination entries and make
sure that the correct host names and user logon data are used.
We recommend that you change RFC physical destinations (host names and IP addresses) but not
the RFC destination name. Then test the connections.
If you want to change the names of the RFC destinations, check all the Configuration Guides
corresponding to your scenarios and perform all the required Customizing steps.
Caution if ALE is used in the copied system:
If ALE is used, do not create new RFC destinations and logical systems in the new landscape!
ALE may be used, for example, for exchanging IDocs between the systems, downloading
organizational units from the backend OLTP system, or for central user administration. If new
destinations are created, ALE distribution no longer works. If ALE is used, only the values and
parameters such as the host names, IP addresses, and logon data within the existing RFC
destinations should be modified to match the new environment.
How to check that step is successfully performed
You can test the connection by choosing Test connection.
What to do in case of problems
Since the scenarios provided by the mySAP CRM solution landscape are different for each individual
case, it is impossible to give full recommendations on maintaining RFC destinations in this document.
SAP Configuration Guides provide detailed information on maintaining the RFC destinations for each
individual scenario. Check the guides corresponding to your scenarios and maintain the RFC
destinations as recommended. Normally, you should check and maintain all the RFC destinations of
types R/3 and TCP/IP.
Step 11: Register and start the inbound and outbound queues on SAP R/3 and SAP CRM sides
Task of step
After the middleware communication parameters are adjusted, the systems are ready for data
exchange. Now you should set up the connection between the systems.
Where to do it
On both sides (SAP R/3 OLTP and SAP CRM Server)
What to do
Start transactions SMQS and SMQR and register all the inbound and outbound queues and
destinations that are required for communication (R/3 CRM, CRM CDB, CDB
Contrans).
Since some of the queues were already unregistered in the source system, it may be useful to check
the screen shots made for these transactions before system copy in order to get the correct status for
each individual queue.
Important: Do not start the queues before adjusting the new RFC destinations!
2002 SAP AG
21
Procedure: Production/QAS/
Test/QAS/Demo/other non-Production
If you require a data-consistent system copy, the source system must be in offline mode and contain
no open tasks, update requests, or other open activities. When copying a multiple-system
environment, all involved systems must fulfill this requirement.
Steps 1-10 are identical to steps 1-10 of the previous procedure
Step 11: Register and start the inbound and outbound queues on R/3 and CRM sides
Task of step
After the middleware communication parameters have been adjusted, the systems are ready for data
exchange. Now you should set up the connection between the systems.
Where
On both sides (SAP R/3 OLTP and SAP CRM server)
What to do
Start transactions SMQS and SMQR and register all the inbound and outbound queues and
destinations that are required for communication between the OLTP system and CRM server.
Before starting the queues, make sure that the systems are separated from the source mySAP CRM
solution landscape.
Important: Do not start the queues before adjusting the new RFC destinations!
Important: The logical system names are not changed before this step.
How to check that step is successfully performed
Normally, you have entries in the queues before the system copy. You should be able to see that the
entries are being processed.
Step 12: Monitor the queues, correct the errors and wait until the queues are empty
Task of step
After the inbound and outbound queues are registered, the normal workflow is started. Since the
logical system names have not yet been changed, the target system landscape is identical to the
source one. Therefore, the entries in the inbound and outbound queues are processed by the normal
workflow. The main task of this step is to monitor the queues and correct any errors.
Where
On both sides (SAP R/3 OLTP and CRM server)
What to do
Check the qRFC queues as follows:
1. On the CRM middleware server, choose Middleware Monitoring Queues
Display qRFC Scheduler information or
Display Inbound RFC Queues
or
Display Outbound RFC Queues
or
Monitor R&R Queues.
Alternatively, use transactions SMQ1, SMQ2
2002 SAP AG
22
2. Unregister all the qRFC queues that are not needed so that the data they contain cannot be
processed after restarting the queues.
3. On the SAP R/3 OLTP side, start the transactions SMQ1 and SMQ2 to monitor inbound and
outbound queues.
To prevent creation of new entries, there must be no workload. For this reason, make sure that no-one
is logged on and no background jobs are running.
How to check that step is successfully performed
All the inbound and outbound queues are empty on both sides (SAP R/3 OLTP and CRM server).
Step 13: Make sure that all the queues are empty
Start report ZCHECK_EMPTY_QUEUES to make sure that all the entries are processed and TRFC*,
ARFC* tables contain no entries that refer to the old logical system names. Correct any errors.
You can find this report in SAP Note 564435.
Step 14: Stop and unregister the inbound and outbound queues on SAP R/3 and CRM sides
Task of step
The queues are empty and all the entries that refer to the old logical system names are processed.
We can assume that the systems are in a consistent state and it is time to convert the logical system
names. Before the conversion, we should break the connection between the systems once again, to
prevent any data exchange during the conversion.
This step is identical to Step 7 of the previous procedure.
Step 15: Change the RFC destinations on SAP R/3 and CRM sides
This step is identical to Step 8 of the previous procedure.
Step 16: Convert the logical system names
Task of step
Normally, in the new CRM system landscape, you should avoid renaming any logical systems. If you
change logical systems names and/or RFC destination names, this may create inconsistencies.
Instead, you should redefine all RFC destinations in such a way that there is no longer a connection to
the original system landscape. If this is too restrictive (for example, if you need to use ALE between
the source and target landscapes), convert the logical system names in the target landscape.
Where
On both sides (SAP R/3 OLTP and SAP CRM server)
What to do
Start transaction BDLS. This transaction converts the logical system names in all application and
Customizing tables.
To obtain the latest version of the transaction, see SAP Note 369758.
Important:
During a run of the changing transaction, no other activities should be performed anywhere in
the system, and there should be no communication with other systems.
The processing of all IDocs in the system must be completed, since the logical system name
may be contained in the IDoc data record and this is not modified by the change transaction.
2002 SAP AG
23
Avoid making manual changes to logical system names in the relevant tables, otherwise the
application documents can no longer be fully located - use only transaction BDLS!
Enter the old and the new logical systems and select Conversion of Client-Dependent and
Client-Independent Tables.
Transaction BDLS must be started for every client on the SAP CRM server and SAP R/3
System. The logical system name is an attribute that can be set for every client.
BDLS
Note: You can start the transaction first as a test run. In this case, no conversion is performed but the
list of relevant tables is displayed.
Step 17: Delete the old logical system names
Task of step
During the conversion of the logical system names, the old system names are not changed. Instead,
the new system names are entered. The old logical system names must be deleted in the target
system landscape.
2002 SAP AG
24
Where
On both sides (SAP R/3 OLTP and SAP CRM server)
What to do
Start transaction BD54 and delete all the logical system names that were changed in the previous
step.
Step 18: Assign the new logical system names
Task of step
Normally, during the conversion of the logical system names, the new system names are assigned
automatically to the corresponding clients, but it is a good idea to check that all the new logical system
names are assigned correctly.
Where
On both sides (SAP R/3 OLTP and SAP CRM server)
What to do
You can start the transactions via the following paths:
CRM server: SPRO IMG Basis Distribution (ALE) Sending and Receiving Systems
Logical Systems Assign Client to Logical Systems
2002 SAP AG
25
SAP R/3 OLTP: SPRO IMG Basis Components Distribution (ALE) Sending and Receiving
Systems Logical Systems Assign Client to Logical Systems
2002 SAP AG
26
27
for each individual scenario. Check the guides corresponding to your scenarios and maintain the RFC
destinations as recommended.
Step 21: Adjust the site attributes on the SAP CRM side
Task of step
Adjust the site attributes on the SAP CRM side.
What to do
Start Administration Console (transaction SMOEAC) on the SAP CRM system and adjust the site
attributes for SAP R/3, CDB, and CRM. Make sure that the logical system names and RFC
destinations are correct.
If any mobile clients connected to the source system are not going to be used in the new mySAP CRM
solution landscape, they should be first released from the client, by means of Administration Console,
and then deleted. After a mobile client is deleted, the corresponding entries in the outbound queue are
deleted automatically. Later, you can maintain any new mobile clients as usual.
Step 22: Register and start the inbound and outbound queues on the SAP R/3 and SAP CRM
sides (on the target side)
This step is identical to step 11 from the previous procedure.
Step 23: Set up the RFC destinations on the SAP R/3 and SAP CRM sides to their initial state
Task of step
Now that the source system has been copied, all the changed parameters can be set back to their
initial state.
What to do
Start transaction SM59 and adjust the RFC destinations that have been changed on both sides
(SAP R/3 OLTP and SAP CRM server).
Step 24: Register and start the inbound and outbound queues on the SAP R/3 and SAP CRM
sides (on the source side)
This step is identical to step 11 from the previous procedure.
Post-Installation Adjustment
SAP CRM Server
After the system copy, make sure that all the middleware parameters are set in accordance with the
configuration guide corresponding to your scenario.
28
Verification
After you execute this Best Practice, check whether you produced the desired results as follows:
1. Check that each single component of your landscape operates in accordance with its tasks.
Normally, for each component you should check its availability, configuration, ability to connect
to another components, performance, and so on. In case of problems, check the relevant
configuration or installation guides and compare the affected component with the same one in
the source landscape.
2. Check the configuration guides again to ensure that the Customizing in the new landscape is
fully completed.
3. After you are sure that your landscape is configured completely and each component is
running normally, you can test the functionality of the scenarios you use. To do so, you should
prepare the procedure templates for business processes and other normal tasks. These
procedure templates should enable you to monitor the execution of each step and verify the
consistency of your data.
Further Information
SAP Notes for System Copy
316353
316355
89188
121163
369758
564435
547314
82478
SAP DB:
151603
MS SQL:
147243
NT Oracle
89698
Informix:
173970
Informix:
111206
DB2/390:
122222
DB2/UDB:
91976
DB2/UDB:
76577
DB2/CS:
36862
AS/400:
2002 SAP AG
29
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
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.
2002 SAP AG