Client copy 1.

1 Client overview

o A client is a self-contained unit in commercial, organizational, and technical terms, with its own user master data and set of table key ranges. o ata from different clients is kept separate at the kernel level. !"# statements e$ecuted by an application use the client number in the where-clause. Although a table may contain data from several different clients, the where-clause limits access to particular clients. o %$amples of client-specific data include&

'ser master data ( such as parameters, authorization, user groups Customizing data ( such as organizational units, assignments, and document types Application data ( such as business transaction data, and material master data

o )he !A* client concept can integrate several companies or subsidiaries in a single client ( by using company codes and the !A* authorization concept.

o Company codes define the smallest corporate organizational units for which a complete self-contained set of accounts can be drawn up for e$ternal reporting.

o )he !A* authorization concept enables the parent company to access all subsidiaries for report purposes, while subsidiary-specific data is protected against access from other subsidiaries through company code definition.

ata of a !A* !ystem can be divided into two categories&

o Client-specific data is data affecting only one client, such as user master and application data. o Cross-client data is data affecting the whole system environment, such as crossclient Customizing data and all +epository ob,ects.

)he A-A* ictionary is a data dictionary that is part of the A-A* +epository&

o %ach piece of A-A* ictionary information is entered only once and is then available anywhere in the system at any time. )he A-A* ictionary automatically supplies all new or changed information, thus providing current runtime ob,ects and ensuring data consistency and security.

o )he !A* runtime environment consists of all A-A* programs re.uired during e$ecution. )he A-A* interpreters in the runtime environment do not use the original of an A-A* program. +ather, they use a copy generated once only during runtime /early binding0. +untime ob,ects, such as programs and screens, are automatically regenerated /late binding0 when a time stamp comparison between the ob,ect and the A-A* ictionary detects a difference.

o )his combination of early binding and late binding ensures that the active integration of A-A* ictionary information does not affect system-wide performance. All performancecritical information is stored in the runtime ob,ects and is always kept up-to-date.

1.1 Client Copy

!A* delivers 2 client copy methods & o #ocal client copy in order to perform client copies inside a given instance,

o +emote client copy in order to copy client beetween different !A* instances, o Client e$port 3 import also to perform client copies beetween different

!A* instances.

o )he difference beetween the remote client copy and the client e$port 3 import lies in the way the data is transfered & o 4n remote client copies the data is transfered immediately across the network using +5Cs. o 'sing client e$port3import, the data is e$ported in files to the transport directory. )he import is done in a second time.

o Client copy tools let you copy the following data types & users data, cross client customizing, application data and client dependant customizing.

o )he ob,ects from the A-A* dictionnary like A-A* reports, table definitions and so on , are not handled by the client copy tools. )hese ob,ects can only be transported through transport re.uests accross the instances.

1.1.1

Client copy pre re.uisites

)he client copy should be performed on a low system activity timeframe. )o have a consistent client copy you should not have any activity on the source system. )herefore, it is recommended to &

isconnect and lock dialog users.

!uspend background ,obs &

)his can be done using report -)C)+6!1. )he ,obs will be released afterwards using report -)C)+6!1.

o 5or remote client copies, the data dictionnaries beetween the source and target systems should be the same. 4f not, in case of client copy beetween a production and development system ,you can e$clude tables from the client copy using report +!CC%7*). 8ou have to be sure that your target client will still be usable and consistent compared to your needs depending on the table e$cluded.

1.1.1

#ocal client copy

#ocal client copy is performed using )code sccl. )he client copy logs are available using tcode scc2. #ocal client copy steps &

#og on to the target system

o o o o o o

Create an entry for your new target client using scc9 #og on to this new target client with user !A*: and default password pass. !tart the client copy using transaction sccl. !elect the source client and the copy profile. !chedule the client copy in bacground )he client copy logs are available in scc2.

1.1.2

+emote client copy

)his method uses +5Cs. )he network must have good performances in order for the client copy to be as fast as possible. An +5C must have been declared in sm;< to access the source client. +emote client copy steps &

o o o o

#og on to the target system Create an entry for your new target client using scc9 #og on to this new target client with user !A*: and default password pass. !tart the remote client copy tcode & scc<.

o o o

!elect the source client / select the right rfc destination 0 and the copy profile. !chedule the client copy in background )he client copy logs are available in scc2.

6=)% &)he first step is the dictionnary comparison beetween the source and target system. 4f these are not identical, the client copy will be canceled. !till, it is possible to e$clude the tables that are not the same using +!CC%7*). -ut this must be done carefully as it can have a negative impact on the data consistency in the target client. 8ou have to make sure that this will not have any impact on the target client usability.

1.1.9

Client %$port 3 import

)he copy is performed in 1 steps &

o )he client e$port during which the source client is e$ported to files in 3usr3sap3trans3data > cofiles. o )he client import during which data is imported in the target client.

8ou must have enough space in the 3usr3sap3trans file system to perform the client e$port.

1st step & e$port

o o o o o o o

#og on to the target system Create an entry for your new target client using scc9 #og on to the source system 3 source client. !tart )code scc? !elect the target system and e$port profile !chedule the e$port in background )he transport re.uest containing the client e$port are then shown

o epending on the choosen e$port profil there can be up to 2 transport re.uests created &

+e.uest @!-!4 AB=@numberA will hold the cross client data, +e.uest @!-!4 AB)@numberA will hold the client dependant data, +e.uest @!-!4 AB7@numberA will also hold some client dependant data.

1nd !tep & import

o o o

#og on to the newly created target client using !A*: and password pass. !tart the stms transaction isplay the target systemCs import .ueue,

o !elect the transport re.uests generated by the client e$port and import theses transport re.uests on the target client. o )he transport re.uests will be imported in the following se.uence &

re.uest @!-!4 AB=@numberA /client independant0, re.uest @!-!4 AB)@numberA /client dependant0, re.uest @!-!4 AB7@numberA /client dependant0.

o )he system automatically detects these are client e$port transport re.uests and automatically performs the import of the 2 re.uests. o )he import logs can be seen in stms.

2rd step & post import phase&

o =nce the import is done, start the sccD )code to perform the post client import actions, o !chedule the post import ,ob,

)he log will be available in scc2.