Mysap CRM System Landscape Copy: Best Practice For Solution Management

mySAP CRM System Landscape Copy
Best Practice for Solution Management

Version Date: November 2002.
The newest version of this Best Practice can always be
obtained through the SAP Solution Manager

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

Best Practice: mySAP CRM System Landscape Copy
2002 SAP AG
2
Applicability, Goals, and Requirements
A Best Practice may not be applicable in some situations. To ensure that this Best Practice is the one
that is needed in your situation, consider the following goals and requirements
Goal of Using this Service
Within an existing mySAP Customer Relationship Management (CRM) solution environment, you can
use the system copy technique to set up one or more additional (or duplicate) mySAP CRM system
landscapes. The goal of using this Best Practice is to perform a system copy in accordance with the
required procedures for the SAP CRM server and SAP R/3 OLTP system of a mySAP CRM system
landscape.
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
Backend SAP R/3 OLTP System
for Online Transaction Processing
System copy Customizing

Staff and Skills Requirements
To apply this Best Practice, you must have experience in copying systems and be familiar with the
administration of the operating system, the database, the ABAP Dictionary, and the SAP CRM
middleware.

A technical consultant who is specifically certified for system copy should carry out the system copy
procedure onsite. This holds irrespective of whether the system to be migrated is a development
system, a test system, or a production system. This ensures that sufficient know-how is available to
handle the complexity of the procedure.

2002 SAP AG
3
You must have a contact person available onsite who can process SAPNet R/3 Frontend messages
concerning problems with system landscape copy.
Duration and Timing
When copying a system containing production data, choose a well-defined starting time for executing
the copy. This is important for maintaining data consistency between the "old" and "new" systems. If
you choose to allow data inconsistencies, these must not affect business processes. For each system
to be copied, decide which one of the following requirements apply:
You need the system copy to result in a system with data consistency. If so, all systems should
be shut down during the copy procedure.
You do not need data consistency. For example, this may apply for demo systems. Here you
can run the copy in online mode, that is, the systems involved may be left running during the
system copy.
How to Use this Best Practice
This Best Practice document consists of two main parts: a theoretical part and a description of the
practical steps. The theoretical part provides the background information on SAP system copy and the
main differences between copying a mySAP CRM system landscape and a standard SAP R/3
System. It also lists the potential problems and risks that are specific for mySAP CRM system copy.
This part ends with a discussion of the possible workarounds.
The practical part starts with a general overview of the mySAP CRM system copy procedure and
divides it into phases and steps. Then a detailed description of each individual step is provided.
Normally, to perform a mySAP CRM system copy you should perform the following steps:
Read the background information provided in this Best Practice
Define the potential risks in your particular case and choose the procedure to be implemented
Register the Pilot Project in accordance with SAP Note 543715
Before starting a system copy, create a detailed project plan describing your mySAP CRM
system landscape copy and including the systems and hardware involved, methods of copy,
milestones, test procedures for important transactions, people responsible for each phase, and
so on
Perform the practical steps of the mySAP CRM system landscape copy
Verify the success of your use of this Best Practice as described in section Verification

Best Practice Procedure and Verification
Introduction

To define a reasonable mySAP CRM system copy procedure, many topics need to be considered, for
example:
The purposes of the target system landscape
The exact changes that should be made during the system copy
The methods to be used
Whether a consistent system landscape copy is needed
How to ensure data consistency in the copied system
The following sections guide you through these questions.
2002 SAP AG
4
General Background Information
Reasons for Copying a mySAP System Landscape
In addition to the standard procedures for installing, setting up, and Customizing SAP systems, you
can use the SAP system copy procedure to create all the kinds of complex system landscapes that
are required for consistency, security, and high availability. These complex landscapes are typical for
mySAP.com solutions including mySAP Enterprise Portal, mySAP CRM, mySAP SCM, mySAP SRM,
or mySAP BI.
For example, using system copies, you can set up landscapes for:
Development
Quality assurance
Testing
Training
Demonstration
Operating system migration
Database migration
Change of hardware
Upgrades should first be performed in a test system. Software development and modifications should
be performed in a development system, then tested in a quality assurance system, before being
transported to the production system. This lets you identify any problems that may impact your
production system. Many administrators create a copy of the production system to build a test system
that contains data similar to the production system data. To create a new SAP system for any of these
reasons, you can perform a system copy.
The advantage of a system copy is that it enables you to perform many system setup activities at
once, because the whole system environment with its Customizing, Support Packages, modifications,
corrections, Plug-Ins and other technical settings are all copied to the target system (instead of being
manually recreated). After the copy, these settings need only to be adjusted.
General Aspects of mySAP CRM System Landscape Copy
System copies of non-R/3 systems (such as mySAP Enterprise Portal, SAP CRM, SAP EBP, SAP
APO, or SAP BW) may only be performed as Pilot Projects.
For more 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.
Regarding the system copy of an SAP R/3 OLTP system, refer to the standard System Copy Guide
corresponding to your SAP R/3 release. To access this guide, go to the Installation/Upgrade Guides
page in SAP Service Marketplace (http://service.sap.com/instguides) and choose SAP R/3 Release
<your R/3 Release> R/3 Homogeneous System Copy / R/3 Heterogeneous System Copy.
One way of performing a database copy is using data backup and restore. Here you can choose
between the different methods and concepts described in the Best Practice Backup and Restore for
mySAP.com. You can access that Best Practice through SAP Solution Manager or SAP Service
Catalogue in SAP Service Marketplace. It provides all the technical information you need to perform
backup and restore for multi-component mySAP.com solution landscapes.
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
5
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?
What should be copied first?
What is the recommended procedure?
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:
How do I copy this live system?
How should I stop the connection?
What should I do if there is some data in the outbound queues?
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:
How will changing these parameters affect the target systems?
If these parameters are used as part of the data, how can I ensure data consistency
after the system copy?

2002 SAP AG
6
Based on these issues, the actions required for a mySAP CRM solution landscape copy can be
divided into two parts:
SAP system copy procedure
Data handling procedures specific to mySAP CRM
SAP System Copy Procedure
Main tasks of this procedure
This procedure was developed for copying SAP R/3 and Basis systems (such as the SAP Web
Application Server) with relatively few components and uncomplicated relationships, and handles the
technical questions of system copy, such as:
Which methods should be used for each particular release?
Which system copy tools can be used?
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.
Data Handling Procedures Specific to mySAP CRM
The main tasks of these procedures:
Ensure data consistency before and after the system copy
Avoid immediate communication between the systems after the first startup
Provide the ability to copy the SAP R/3 OLTP system and SAP CRM server with nonempty
queues and process the entries after the system copy
All the actions required for a mySAP CRM system landscape copy can be illustrated as follows:

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

Preliminary
preparations
Prepare the
source systems
for copy

mySAP CRM specific data handling procedures
Common procedures for copying SAP CRM
and standard SAP R/3 Systems
Downtime
2002 SAP AG
7
Main Focus of this Best Practice

Among all of the components in a mySAP CRM system landscape, the system copy of the SAP CRM
server and the SAP R/3 OLTP system is usually the most critical. This is because of the need to
ensure data consistency between the systems during the system copy.
This Best Practice only deals with procedures for preparing the middleware of the source systems
before and after the system copy and with issues regarding data consistency.
Procedures for the technical part of system copy, copy methods, installation tools, and so on are
explained in the relevant installation guides.
At present, the SAP system copy procedure is not generally released. Therefore, you need to perform
the preparation phase and technical part of system copy together with an SAP Development team as
pilot project.
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:
Changing the logical system names
System copy with nonempty inbound or outbound queues
Changing the Logical System Names
In any complex landscape where data is distributed and exchanged between different systems, there
is a potential risk when changing the parameters responsible for data exchange configuration. These
parameters include RFC destination, host names, and logical system names.
Among all these parameters, changing the logical system names has the strongest impact on the
systems.
Definition of logical systems
To prevent confusion, participating systems in a distributed environment must each have a unique ID.
The name of the logical system is used as the unique ID. This name is assigned explicitly to one client
in an R/3 System.
A logical system is an application system in which the applications work together in a common
database. In SAP terms, a logical system is a client in a database. Every system within the SAP CRM
solution landscape is a logical system. It is either a client in the CRM system, a client in a standard
SAP OLTP system, or a non-SAP system. Messages are exchanged between the logical systems.
A logical system may be compared with an address on a letter. To ensure that data is sent to the
correct recipient (or to the correct address), logical system names must be unique among the systems
exchanging the data.
To change a logical system name that is already used or defined in a system to a new name, you can
use transaction BDLS. This program finds all relevant tables and converts the corresponding entries.
Problem description
In an ideal case, the logical system names are stored in a few known tables. These database tables
are dynamically determined by certain domains (LOGSYS and EDI_PARNUM). But if there are
applications where the tables do not reference these domains, the data is not converted. Also, some
data may be saved as part of fields in cluster or pool tables with regard to the logical system. Such
data, too, is not converted.
2002 SAP AG
8
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.
System Copy with Nonempty Inbound or Outbound Queues
Normally, the qRFC inbound and outbound queues are unregistered before beginning the database
copy procedure. If the queues have not been unregistered, they can continue to be filled with RFC
data. In the newly created system, these queues may contain valid data.
A potential problem arises when the inbound or outbound queues contain entries before system copy
and the logical system names are changed after the system copy. The problem is that the entries
contain the reference to the old logical system names as a part of their fields. If the logical system
names are changed after the system copy, these entries cannot be processed. Thi can lead to data
loss or inconsistency.
In an ideal situation, all the queues are fully processed and contain no entries. In this case, potential
data loss is minimal. In fact, it is not always possible to empty all the queues for business reasons. For
example, there may be a high load in the system 24 hours per day and it may take too long for all the
queues to be fully processed, so to minimize downtime you may need to copy the systems with entries
in the queues and process them after the system copy.
Currently, no automatic tools or methods are available that can process entries in the queues after
changing logical system names. So the question of how to proceed in case there are some entries in
the outbound or inbound queues before system copy is critical.
Let us consider the cases mentioned above.
Building up a Production System
In this case, because the logical system names are not changed after the system copy, the newly
copied systems are identical to the source ones and the queues can be processed by the normal
workflow after system startup.
2002 SAP AG
9
Building up a DEV, QA, or Test System from the Production System
In this case, to process the queues, the old logical system names are required, yet the logical system
names must be changed after the system copy. A possible workaround is to start the newly copied
systems initially with the old (unchanged) logical system names. Then, after adjusting the RFC
destinations and starting the inbound and outbound queues, there are no differences between source
and target systems from the communication point of view. Entries in the queues can be processed by
the normal workflow.
After all the entries have been successfully processed, the logical system names can be changed.
Since the newly copied systems are not production systems, it is possible to wait until the queues are
empty.
Possible System Copy Procedures
Based on the considerations described above, two possible procedures are considered:
Production Production
Production/QAS/ QAS/Test/Dev/other non-Production
Procedure: Production Production
Requirements:
Data must be consistent and identical in target and source systems
Downtime must be minimal
Main aspects of system copy procedure:
No changes to the SID, logical system names, or RFC destination name
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:
Data should be consistent and identical in target and source systems
Downtime should be minimal
SID and logical system names may be changed in the target system
Main aspects of system copy procedure:
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
Procedure for System Copy of SAP CRM Server
and SAP R/3 OLTP System
Preliminary Tasks
Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks
in the system:
Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations
resulting from customer problem messages
Implement all currently available SAP Support Packages
Check all the documents and SAP Notes mentioned in this document
Preparations for mySAP CRM System Copy
Before starting the system copy, you need to understand clearly how it will be performed in your
particular case. To be sure you understand, perform the following actions:
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.
General Description of System Copy Procedure
Once you have planned and prepared the system copy, you can begin with the actual steps. In
general, the task of copying an SAP CRM system landscape can be subdivided into a number of
phases. These are:
1. Preliminary preparations: Plan and prepare the system copy procedure. Install the new
complete system environment using the standard installation tools and installation guides.
Install and configure all the non-ABAP components to minimize potential downtime.
2. Prepare the source systems for system copy: Perform general and technical preparations
in the source systems in accordance with the System Copy Guides: check for canceled or
pending requests, update the statistics, check for data consistency, and so on.
3. Prepare the middleware of the source systems for system copy: Prepare the middleware
responsible for communication between the source systems and break the connection
between them.
4. Perform the system copy: Run a homogeneous or heterogeneous system copy of the
source SAP systems, as described in the standard System Copy Guides. In the newly copied
systems, perform the subsequent technical actions and post-installation steps.
5. Adjust the middleware: Adjust the middleware at operating system level so that it has the
same status as the source system. Set up the connection between the systems. Adjust the
SAP server settings in the new CRM server and core SAP R/3 System and perform the
subsequent technical actions in the standard System Copy Guide.
6. Start the source systems (if required)
2002 SAP AG
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.
You can perform a homogeneous or a heterogeneous system copy.
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.
We recommend that you document all the actions performed.
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:
Install the new CRM server in its own network environment.
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 Target Landscape
Prepare the hardware and environment
for the target systems
Install all the non-R/3 components (IPC,
TREX, J2EE, Web AS, )
Preliminary configuration of all the non-
R/3 components
Perform backup of all the components in
mySAP CRM solution landscape
Perform the actions required to prepare
system for copy procedure (check for
canceled or pending update requests,
update the statistics, check for
consistency, and so on)
Save the initial configuration of all the
parameters, queues, RFC destinations,
and so on before changing them
Phase1: Preliminary
preparations
Phase 2: Preparing
the source systems
for system copy
procedure
Unregister the inbound and outbound
queues in SAP R/3 and CRM systems
Change the RFC destinations in SAP
R/3 and CRM systems
Copy the systems by means of the
recommended methods
Adjust RFC destinations and establish
communication between the SAP R/3
and CRM systems
Register and start the inbound and
outbound queues on SAP R/3 and CRM
systems
Production
Phase 3:
Preparing the
middleware
before system
copy
Phase 4: System
copy procedure
Phase 5: Middleware adjustment after
the system copy
1
2
3 4
5
6
7
8
9
10
11
Production
2002 SAP AG
13
Production/QAS/Test/ Test/QAS/Dev/other non-Production

Source Landscape Target Landscape
Prepare the hardware and environment
for the target systems
Install all the non-R/3 components (IPC,
TREX, J2EE, Web AS, )
Preliminary configuring of all the non-R/3
components
Perform backup of all the components in
mySAP CRM solution landscape
Save the initial configuration of all the
parameters, queues, RFC destinations,
and so on before changing them
Phase1: Preliminary
preparations
Phase 2: Preparing
the source systems
for system copy
Unregister the inbound and outbound
queues in SAP R/3 and CRM systems
Change the RFC destinations in SAP
R/3 and CRM systems
Copy the systems by means of the
recommended methods
Adjust RFC destinations on SAP R/3 and
CRM systems
Phase 3:
Preparing the
middleware
before system
copy
Phase 4: System
Copy procedure
Phase 5: Middleware adjustment after
the system copy
5
1
2
3 4
6
7
8
9
10
11
12
Set up the RFC destinations on SAP R/3
and CRM side to their initial state
outbound queues on R/3 and CRM
systems
Production/QA/DEV/
Phase 6: Start
Production
System
Queues are
empty?
Yes
No
Monitor the queues, correct the errors,
and wait until the queues are empty
Convert the logical system names
Delete the old logical system names
Stop and unregister the inbound and
Check for possible data inconsistency
Change the RFC destinations on R/3
and CRM systems
13
14
15
16
17
18
19
23
24
QA/Test/DEV/
Adjust the site attributes
20
Production/QA/DEV/
Perform the actions required to prepare
system for copy procedure (check for
canceled or pending update requests,
update the statistics, check for
consistency and so on)
Assign the new logical system names
21
Adjust RFC destinations on R/3 and CRM
22
outbound queues on R/3 and CRM sides
2002 SAP AG
14

Detailed Description of System Copy Steps
This section describes each step in detail.
Procedure: Production Production
Step 1: Prepare the hardware and environment for the target systems
Task of step
As the system configuration fundamentally influences the installation and system copy procedures, it
is important to have a clear configuration plan before you start the system copy. Before you can begin
with the practical tasks of installing or copying the main components of the CRM system landscape,
you need to plan the configuration of the landscape and prepare the environment accordingly.

What to do
Decide which components you need in your new SAP CRM system landscape, work out how these
components must be distributed to hosts, and calculate the sizing of the hardware involved.

What to do in case of problems
For detailed information, refer to the installation and configuration guides. Normally, on the basis of
information about the expected workload, applications to be implemented, and number of users, an
SAP hardware partner can recommend a feasible configuration.

Step 2: Install all the non-R/3 components (IPC, TREX, J2EE, )
Task of step
Once the configuration of the new landscape is clear, install all the components that build up this
landscape.

What to do
Currently, there is no released procedure for copying non-ABAP components together with the SAP
CRM server and SAP R/3 OLTP systems. Therefore, all the non-ABAP components, such as IPC or
DCom, should be newly installed in the target landscape and configured as required.

To obtain the detailed procedures, refer to the installation guides for the individual components.
See also the Best Practice Backup and Restore for mySAP.com. It lists ways of performing backup
and restore for the individual components of a mySAP.com system landscape, and includes the
relevant backup methods, intervals, and recovery procedures for software and data.

Step 3: Preliminary configuration of all the non-R/3 components
Task of step
Since installing and configuring the SAP CRM system landscape is a time-consuming process, it is a
good idea to perform a preliminary configuration of its components to minimize the downtime for
system copy.

To obtain the detailed procedures, refer to the configuration guides for each individual component. You
can also compare the configuration of a component in the target landscape with configuration of the
same component in the source landscape.
To be sure that Support Packages and versions of all the new installed components correspond to
each other, check the Support Package Guide. This guide is a central starting point for the technical
implementation of Support Packages for SAP CRM 3.0. You can find it in SAP Service Marketplace,
alias /instguides (http://service.sap.com/instguides), by choosing mySAP CRM SAP CRM 3.0.

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.

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.
Cancel all released and periodic jobs (transaction SM37).
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.
Make sure that:
o No upgrade-prepare is performed
o No incremental conversion is in progress (to test if an incremental conversion is in
progress, start transaction ICNV)
Update the statistics.
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

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

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

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.

SMQS
SMQR
2002 SAP AG
18
How to check that step is successfully performed
All the queues and destinations should have type U.
Check the SAP Notes:
484753 Importance of entry categories in SMQS
438015 Latest qRFC version and supplement for 3.x, 4.x, 6.
400330 Outbound Scheduler/qOUT Scheduler
369007 qRFC: Configuration for the QIN Scheduler
460235 tRFC/qRFC: Low-speed processing
480543 CRM MW R&R queues in status STARTING (no processing)

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

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.

You can test the connection by choosing Test connection.

2002 SAP AG
19

Step 9: Copy the systems by means of the recommended methods
Task of step
Execute the technical part of the SAP system copy procedure.

Where

What to do
Contact the SAP Development team for the recommendations and the details regarding this step.
To perform export and import for the CRM server, you need templates DBEXPORT.R3S and
DBMIG.R3S. You can order these from SAP by creating an SAPNet R/3 Frontend message for the
component BC-INS-MIGR3.
Use R3SETUP from the EBP/CRM Installation CD. Regarding the export, see the SAP Web AS 6.10
Homogeneous System Copy Guide. Regarding the import, see the EBP/CRM Installation Guide.

Contact the SAP Development team by creating an SAPNet R/3 Frontend message for the component
BC-INS-MIGR3.
SM59
2002 SAP AG
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

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.

You can test the connection by choosing Test connection.

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
Normally, you have entries in the queues before the system copy. You should be able to see that the
entries are being processed.

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

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.

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.

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

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:
Never change the logical system names in production systems!
Before you run transaction BDLS, check the online documentation.
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 run four times in this process:
1. In the SAP R/3 backend system: LOGSYS OLTP old LOGSYS OLTP new
2. In the SAP R/3 backend system: LOGSYS CRM old LOGSYS CRM new
3. In the SAP CRM system: LOGSYS CRM old LOGSYS CRM new
4. In the SAP CRM system: LOGSYS OLTP old LOGSYS OLTP new
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.

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.

BDLS
2002 SAP AG
24
Where
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

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

Step 19: Check for possible data inconsistency
Task of step
To prevent unexpected data inconsistency and ensure proper application functionality after converting
logical system names, we recommend that you check all the CRM and R/3 tables that may contain the
old values of the changed logical system names, RFC destinations, SID, host names, and so on.

Where

What to do
Start the report ZSCAN_LOGSYS on both sides (SAP CRM Server and SAP R/3 OLTP). This report
scans all the application tables for entries that may contain the old logical system names. The result of
this database scan is a list of the tables in which the old values still exist.
You can find the report in SAP Note 564435.
How to use the report:
1. Start the report in transaction SM38.
2. Enter the old logical system name:
2002 SAP AG
26

3. Execute the report.
4. After the report is executed, you will find in the directory /usr/sap/trans/tmp/ three files with
the following names: notchecked, checked_nothing_found, checked_and_found. File
checked_and_found lists the tables that can contain the entries with the old logical system
names. You should analyze these tables. The other files (notchecked,
checked_nothing_found) are not important for the analysis.
After you have the list of the tables, see SAP Note 564435 for information about how to proceed with
them.

Step 20: Adjust RFC destinations and establish communication between the SAP R/3 and SAP
CRM systems
Task of step
The newly copied systems are unable to communicate with each other because the RFC destinations
point to nonexistent servers and the inbound or outbound queues are unregistered. The main purpose
of this step is to maintain the parameters responsible for communication between the SAP R/3 OLTP
system and the CRM component system.

Where

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. Change RFC physical destinations
(host name or IP address), not the RFC destination name. Then test the connections.
Normally, you should check and maintain all the RFC destinations of type R/3 and TCP/IP.

Note: In general, to change fewer Customizing objects, you can work with the original RFC destination
names and logical system names and only change the physical destinations themselves.

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.

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 required
2002 SAP AG
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.
SAP R/3 OLTP System
Adjust Table CRMRFCPAR
Check or define the communication parameters. In transaction SE16, ensure that the table
CRMRFCPAR has the correct settings.
Adjust Table CRMCONSUM
In transaction SM30, check or define the communication parameters in tables CRMCONSUM and
CRMRFCPAR.
For more information on the CRM/EBP server, in the IMG, see Customer Relationship Management
CRM Middleware and Related Components Communication Setup Define OLTP R/3
Parameters. EBP customers should use Consumer "EBP" instead of Consumer "CRM".
2002 SAP AG
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 Inst: 4.6D SAP BASIS Heterogeneous System Copy
316355 Inst: 4.6D SAP BASIS Homogeneous System Copy
89188 R/3 System Copy
121163 BDLS: Converting logical system names
369758 BDLS: New functions and better performance
564435 Additional information on CRM System copy
547314 FAQ: System Copy procedure
82478 R/3 OS/DB migration
Database-Specific SAP Notes
129352 SAP DB: Homogeneous system copy with SAP DB (ADABAS)
151603 MS SQL: Copying an SQL Server 7.00 database
147243 NT Oracle R3COPY under NT Oracle
89698 Informix: R/3 System Copy
173970 Informix: Copying and renaming an 4.x R/3 DB
111206 DB2/390: Homogeneous System Copy
122222 DB2/UDB: Redirected restore via DB2 CLP
91976 DB2/UDB: Database copy with ADSM backup
76577 DB2/CS: BRDB6 Tools for Redirected restore
36862 AS/400: Copying an R/3 System
Application-Specific SAP Notes
418886 Products not found or not changeable

2002 SAP AG
29
Feedback and Questions
Send any feedback by formulating an SAP customer message for component SV-GST-SMC. You can
do this at http://service.sap.com/message.

Copyright 2002 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.

INFORMIX
-OnLine for SAP and Informix
Dynamic Server
TM
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.

Mysap CRM System Landscape Copy: Best Practice For Solution Management

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Mysap CRM System Landscape Copy: Best Practice For Solution Management

Hochgeladen von

Copyright:

Verfügbare Formate

mySAP CRM System Landscape Copy

Best Practice for Solution Management

are registered trademarks of

are registered trademarks of IBM Corporation.

is a registered trademark of ORACLE Corporation.

-OnLine for SAP and Informix

are registered trademarks of the Open Group.

, World Wide Web Consortium, Massachusetts

is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT

is a registered trademark of Sun Microsystems, Inc., used

Das könnte Ihnen auch gefallen