„The client“ – Grisham’s classic about the Mafia is definitely worth reading material for thriller fans. The stuff that administrators‘ nightmares can be made of, on the other hand, unfortunately sometimes also has to do with clients: „Client Management“. To free the proverbial book from at least a few seals, here is a brief overview.
Clients?
Many people wonder about this term „clients“ when they first hear it. This one has grown historically, you just have to know where it came from. About the time Bill Gates allegedly made the quote „640 kB ought to be enough for anybody.“ (1981 – so very long ago, and also repeatedly denied), SAP decided to create a system that is „multi-client capable“.
Based on the assumption that a mainframe server is strong enough for several customers and often too expensive for a single one, the idea was conceived to accommodate „business“ delimited sub-units in one SAP system. In practical terms, this means that several customers can be packed into one system, saving money on expensive hardware resources and conserving the market for system administrators. Hosting was born.
The result: An SAP system has
- a single database,
- only one kernel (technical connection to the database),
- a single (DEFAULT) parameterization, and
- in the database
- o a single cross-client system configuration (cross client customizing)
- o R/3 Repository (types, reports, table structures, etc.)
Each client for itself has in this global SAP framework:
- own configuration settings (= client dependent customizing),
- its own client dependent table contents (application data),
- its own user master, and
- as an important configuration feature : a logical system.
Nowadays, it has become common practice to provide each customer with its own system, often with several clients for this one customer that fulfill different purposes. Business processes, at least in large companies, are almost always split across several system landscapes (HR, FI, etc.). This is also in line with SAP’s product philosophy of outsourcing functions to its own products (PI, BW, Portal, etc.).
However, one or the other service provider can be found in the wild that successfully offers „client hosting“. This is subject to some restrictions (I have to coordinate password lengths with the other clients), but is still technically feasible without any problems.
How do you deal with clients?
The mapping of the clients in the common database is done by client keys in the tables (client key exists => client dependent table). The keys themselves are maintained in table T000 :
A client copy or export consequently creates an image in the target of only those tables that contain a client key (client-dependent), and those rows from these tables that match the specified key. Exceptions to this are the impractical tables (because they are large and largely useless in the target), such as change documents. These are not copied by the SAP tools by default.
Since a client is part of a system environment tailored to it (see above), it is strongly discouraged to copy clients back and forth between heterogeneous system landscapes for serious purposes (Release! Repository! Customizing!). Often, however, one wants to create a second, independent data environment temporarily within a homogeneous landscape in test systems. Or you simply want to mirror the data from production into the test environment without completely overwriting the target system.
The client copy functions are very useful in these homogeneous environments if
- small amounts of data are involved (better < 100GB, in no case > 500GB)
- for certain reasons the client-independent contents of the target must be preserved.
- For example, only users are to be transferred to an existing client.
- Complete data consistency is not required, or the source system is not used.
- The release status is identical (export system > import system is technically possible, but causes serious problems during post-processing and should therefore never be carried out).
In all other cases, a system copy is simply recommended (shorter runtime, less effort, consistent in itself, source system is not burdened).
The client management
SCC3 client protocols
Central point of contact, if you are looking for protocols for client management. Please also note the buttons at the top („All clients“, „Exports“). Attention : when importing, there will be a log only when the technical import is finished and the postprocessing has been started. Until then, the TMS has the say, and it must be monitored there.
SCC4 creation, maintenance of clients.
Maintenance of table T000, among other things status, protection level (customizing / repository from this client changeable; overwriteability by client copy; deletion allowed etc.) adjustable. Currency and logical system are also maintained here.
Delete SCC5 clients.
If a client is no longer needed, it can be deleted here. Also useful for carve out projects, where individual parts of the company are spun off and „take“ their client with them (system copy -> delete remaining clients -> database reorganization if necessary -> migration export).
SCC7 Follow-up of a client import.
Always necessary when the transport system (TMS) is used to bring clients from A to B. After the import has been completed, the postprocessing must be started directly in the imported client.
SCC8 Client Export.
Uses the TMS to export clients to the file system. Specification of one of the copy profiles is necessary. Check space in file system before export, transport directories are usually not suitable to host 500GB clients without adjustments. It will be compressed, but often not significantly.
SCC9 Remote client copy (RFC)
Prerequisite : working RFC connection to source, external availability configured (SCC4), client not too large, source system can handle copy load, source and target have sufficiently large rdisp/max_wprun_time. Attention : you pull the data, which means the SCC9 is started in the target.
SCCL – Local client copy
Is often used in the construction of new systems. Copies tables locally (also possible in the background using one of the copy profiles. For empty setup of a new client e.g. SAP_CUST with source client 000 (Attention, used to be 001).
STMS_IMPORT
The transaction of the local import queue, here among other things client imports can be started and monitored. After import the SCC7 must be executed, only after successful completion the client is considered as completely imported.
Further terms
A copy profile always defines the set of client dependent tables that are copied / exported. SAP_CUST for example copies only customizing (no users), SAP_UCUS would additionally bring the users. SAP_ALL copies the complete client, SAP_USER only users and their authorizations. SAP_USER also has a special function: all other profiles empty the target client during the copy, but SAP_USER copies leave the target client as it is, and only overwrite the user masters and roles / profiles.
A logical system normally defines a client uniquely within the customer landscapes (keyword ALE). With its help, documents can still be assigned to a source client in communication scenarios. Since SAP recommends one SID per system, the log. Name the standard according to PE5CLNT100 (or optionally German : PE5MNDT100) has been established. After client copies/system copies, a conversion of the logical system may be necessary depending on the purpose of the copy (attachment : BD54, conversion : BDLS).
Tips..
The NRIV table is the central number range table (transaction SNUM) in the SAP system. If a client copy takes several days, it may be that after copying the NRIV (all tables A* to N) until the copy is completed, the number ranges of the tables (O to Z*) have already continued – then the manual transport (of copies, SE01) of the NRIV may be necessary.
The user SAP* (pass) exists as a technical user (included in the kernel, no user master record in the DB necessary) in every empty client (whether newly created or freshly deleted). It is needed to be able to do anything at all in an empty client without user master records. Prerequisite for logging on with this technical user is the profile parameter login/no_automatic_user_sapstar = 1 (since WebAS 6.20). If a „real“ user name „SAP“ is created in the client, the technical SAP is no longer activated.
If you copy for a long time and then want to abort, you may have to deal with remaining locks that successfully prevent any further client management action. Solution : SM12 -> table „rstable“, argument „rsclicopy“. Attention at detail text „backup“ do not abort (#43614).
RSCCEXPT is a report for configuration of client copies. You can exclude single tables (because you copy them separately or you don’t need them in the target) and configure parallelization, the latter is also possible in many SCC transactions directly (e.g. SCCL, SCC9).
The Mandatory
This documentation is a collection of empirical values, and has not been tested or released in any form by the product manufacturers (SAP, Oracle, ..). No liability can be assumed for damages resulting from (partial or complete) following of this documentation.
Of course I am happy about questions, comments or additions.
