Sap Crm Landscape

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 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 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

34

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

34

6

7

8

9

10

11

12

Set up the RFC destinations on SAP R/3 and CRM side to their initial state

Register and start the inbound and outbound queues on R/3 and CRM systems

Production/QA/DEV/

Phase 6: Start Production System

Register and start the inbound and outbound queues on R/3 and CRM

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 outbound queues on R/3 and CRM

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

Register and start the inbound and 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. What to do in case of problems 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. What to do in case of problems

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

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 "" 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

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.

What to do in case of problems

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 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 CLNT and CLNT, 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

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 On both sides (SAP R/3 OLTP and SAP CRM server) 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. What to do in case of problems

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 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

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.

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:

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 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

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 On both sides (SAP R/3 OLTP and SAP CRM server) 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 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. 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 ServerTM

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.

Sap Crm Landscape

Documents

Transcript of Sap Crm Landscape