CLIENT COPIES

After a “new” SAP R/3 installation, the SAP system is only delivered with the so-called delivery clients: 000, 001, and 066.

The client “000” is empty, which means that there is no master or transaction data stored in this client. It is primarily used to manage Data Dictionary objects. In the past, this client was also used to apply Support Packages and to correct Data Dictionary changes through SPDD and SPAU.

Client 000 – SAP Reference Client

The “SAP Reference Client” is shipped by default in any SAP system and contains a copy of all default SAP customizing settings. It contains sample entries for organizational structures and other module-specific customizing. The SAP Reference Client contains settings like:

 Tables with default settings. (The content of these tables are independent of the organizational units.)

 No master or transaction data (application data)

 Default settings for all customizing objects

 Examples of organizational units (company codes, business area, sales areas, purchase organizations, controlling areas, etc.)

During SAP release upgrades, new default settings are written to this client, which may overwrite or replace existing ones.

TIP You should not make changes to client 000 as it may be overwritten by applying Support Packages or during SAP release upgrades.

Client 001 – Production Preparation Client

The “Production Preparation Client” is identical to the client 000 “SAP Reference Client,” which means that table entries (rows) are similar. The only major difference between client 000 and client 001 is the existence of additional example customizing in client 001: tax rules, sample charts of accounts, and certain validation and substitution rules. Client 001 remains untouched during the implementation of Support Packages or a SAP release upgrade.

Client 066 – EarlyWatch Client

The “SAP EarlyWatch Client” is exclusively used by the “SAP Global Active Support” organization to run “GoLive” and “EarlyWatch” reports. This client only contains user-master records and authorization profiles.

To prevent customers from using client 000 and 001 for productive usage, SAP provides the ability to create new clients and copy client-specific content from one client to the other. SAP supports different methods to copy content between clients: per table basis, per group of tables, or through an entire client copy. When a client copy is done, SAP offers the ability to do this even between different SAP systems.

Figure 4.27: “Local” client copy versus “Remote” client copy.

The recommendation would be to leave all client numbers between 000 and 099 exclusively to SAP, and start numbering clients used by the customer at 100 and above.

A typical client layout would look like this:

Figure 4.28: SAP client landscape example.

This example with three SAP instances, named Development, Quality Assurance, and Production contains nine clients. There is a separation of clients for business configuration customizing, development of reports and transactions, development of interfaces, and testing. The “Gold Config” client contains the initial content before a new development life cycle is started. The QAS instance contains three clients for the acceptance process of development and customizing (test against production data), unit testing (both integration testing and data conversion testing), and a separate training client, if required. In some cases it is recommended to have a separate SAP instance for training purposes. And lastly we have the production instance with one single “production” client.

TIP In cases where the client numbers are kept the same throughout the landscape, such as 100-100-100, it is easier to refresh instances by making use of complete database copies.

For SAP applications that make use of InfoCubes, such as BW, SEM, or APO, it’s not possible to have multiple clients in one single SAP instance; therefore, it’s recommended to use:

Figure 4.29: SAP client landscape for InfoCube-based applications.

Also, for these systems, it’s important to keep the client numbers the same in case you would like to use “entire database copies” for system refreshes.

TIP When designing new InfoCubes, add the source-system info-object as field. In this case it’s possible to use one development and test client in BW for multiple development clients. Otherwise you have to run multiple BW systems in order to support multiple clients in R/3.

The client copy process itself consists of four major steps:

(1) Manual preparation

This step is executed by the system engineer and consists of the addition of the new client to the client table, followed by the configuration and scheduling of

the client copy. The engineer also has to take care of the database in terms of space requirements.

(2) Initialization

When the client copy is actually started, it first creates a list of all tables that need to be copied. If table field DD02L.CLIDEP = “X”, the table will be copied unless the table is added to the client copy exception table by the system engineer. Also, a list of XPRAs is created that are executed after the copy process.

(3) Actual copy process

During this step, which can take hours, each row of the table belonging to the source client is copied over to the target client. So the copy is within the same table, only the client number (TABNAME.MANDT) is changed.

The SQL statement look likes this:

LOOP FOR ALL TABLES in DD02L do

IF DD02L.CLIDEP=’X’ and TABNAME not in ClientCopyExceptionTable do LOOP FOR ALL ROWS in TABNAME where MANDT=SOURCENUMBER do

INSERT VALUE (TABNAME.MANDT = TARGETNUMBER , TABNAME.FIELD-A = TABNAME.FIELD-A , TABNAME.FIELD-B = TABNAME.FIELD-B , TABNAME.FIELD-C = TABNAME.FIELD-C ,

So the copy process is a copy loop for rows into a copy loop for tables.

(4) Postprocessing

During the “postprocessing” phase certain XPRA programs are executed.

Besides using the “internal” client copy method, which is based on SCC3 and SCCL, it’s also possible to use R3trans. However, it’s not recommended to use R3trans for “internal” client copies.

The client copy process is executed through transaction code SCC1, which will eventually execute reports RSCLICOP for SAP R/3 releases below 4.6C or RSCLCCOP for higher releases. The steps executed by a client copy are stored in table CCCFLOW. This table, CCCFLOW, contains several fields to control the process. The output logs of the client copy can be viewed using transaction code SCC3.

Tables can be excluded from the client copy process using report RSCCEXPT, which offers the ability to add tables to a list of tables that are skipped during the client copy process. There are tables you might consider excluding from the client copy like CDCLS, CDPOS, and CDHDR. These tables are used by the ALE engine.

INFO For more information on client copies, have a look at SAP Note 552711—Client Copy FAQs

4.6.1 Remote Client Copies

The process of a “Remote Client Copy” is similar to the “Local Client Copy” except for a few differences. First of all, there are multiple ways of doing a “remote” client copy. The first method is based on transaction SCC9 – Remote Client Copy. The second method works with R3trans.

The SCC9 Remote Client Copy function has significantly improved over time.

This process uses an RFC connection between the source and target system. The initial release of the SCC9 functionality was only able to copy tables remotely in sequence. Later versions are able to copy tables in parallel.

Figure 4.30: Remote client copy using SCC9 RFC.

In order to run the SCC9 client copy over parallel RFC links, certain RFC groups need to be put in place.

The second option is to use R3trans instead of transaction SCC9.

The R3trans method works slightly different. This method uses two command files, one for export and one for import.

# R3trans export – called: exportclient100.r3t

export

client = 100

file = ‘/usr/sap/trans/data/clientexport100.dat’

use commandfile=’/usr/sap/trans/cofiles/<COMMANDFILE>’

Figure 4.31: Remote client copy using R3trans manually.

# R3trans import – called: importclient200.r3t

import

buffersync=yes

client = 200

file = ‘/usr/sap/trans/data/clientexport100.dat’

First export on source system:

source-host> cd /usr/sap/trans/bin source-host> R3trans exportclient100.r3t

copy over all files to target system; all logs are written to r3trans.log target-host> cd /usr/sap/trans/bin

target-host> R3trans importclient200.r3t

The tool R3trans can also be used to copy individual tables over from one system or client to another.

# R3trans export – Called: EKPO (client 100 only) table copy

export

client = 100

file ‘/usr/sap/trans/data/tableEKPOcl100.dat’

select * from EKPO

TIP For more information on the various aspects of using R3trans to export clients or individual tables, please have a look at SAP Note 1942.

4.6.2 Multiclient Manager

As of SAP Web Application Server 6.40, SAP started to support the MPC facility.

MPC, or Multiple Production Clients, offers you the ability to run multiple clients on one SAP system. Until SAP release 6.40, this option was not supported for production systems and was only used in non-production systems such as development, acceptance, and training.

The reason behind this strategy change is the so-called “ASP” (Application Service Provider) market, where different business applications from different companies are transparently hosted on a limited set of SAP instances. The ASP term is now also known as SaaS (Software as a Service).

In order to support ABAP programming in an MPC environment, SAP offers a set of tools and programs to prevent conflicts. Transaction MCLIMAN is one of them.