Вы находитесь на странице: 1из 16

12/20/2019

Client Concept
Generated on: 2019-12-20

SAP NetWeaver 7.5 | SPS16

PUBLIC

Original content: https://help.sap.com/viewer/27812d1fd8db4cdf98b4f25994e717ea/7.5.16/en-US

Warning

This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product
documentation. The information included in custom documentation may not re ect the arrangement of topics in the SAP Help
Portal, and may be missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.

For more information, please visit the https://help.sap.com/viewer/disclaimer.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a4… 1/16
12/20/2019

Client Concept
Use
The operator of a multiclient system (such as an application service provider (ASP)), must be able to provide a large number of
customers with system resources and administration at minimum cost.

The SAP client concept allows you to map each customer to one client, without having to install and administer a separate
(physical) system for each customer. This makes it possible for the provider to install a small number of SAP Systems, but still
cater to a large number of customers. Costs are not only saved by sharing hardware and software, multiple customers also use the
same application solution, including administration and support. To guarantee the secure and reliable co-existence of customers
under a common system umbrella, certain rules must be followed.

The growth of the small and medium business market requires an analysis that weighs up the possible cost savings of multiple
clients against the restrictions for SAP solutions. It is important at this stage that reliable statements are made about the ability of
SAP components to deal with multiple clients.

This documentation describes the most important guidelines that you need to follow if you want to operate reliable multiple SAP
clients. These include requirements both for SAP products and for all add-on products, project solutions, and customer
developments.

This documentation is also a useful starting point for analyzing the multiclient compliance of a SAP solution before going live.

Client and Multiclient Operation


Use
SAP's client concept allows you to split an SAP System into multiple logical sub-systems - or clients. You can isolate these sub-
systems and operate them as separate business units. The following discussion is based on the case in which each customer is
mapped to exactly one client. This document focuses only on the production client role, and does not discuss other client roles,
such as test, training, or quality assurance (QA).

Multiclient Compliancy

All data in a system with multiple clients is located in a common database. An SAP solution can operate with multiple clients if
each customer has exclusive access to his or her data in an installation with a shared system platform, database, and central
services.

Integration
These requirements lead to three basic questions:

1. What consequences does the common storage of customer data have on the security and protection of business
information? Can the system forbid unauthorized access to data by other clients, particularly with regard to accidental or
intentional deletion of data?

For more information, see Data Administration Requirements.

2. What consequences does having more than one client active simultaneously have for system response times? What effects
does the extra client have on performance?

For more information, see In uence on Processes and Runtime.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a4… 2/16
12/20/2019
3. What consequences do multiple clients have on administration and the Service Level Agreements (SLAs) guaranteed by
the service provider?

For more information, see Multiclient Administration.

The multiple client analysis of an SAP solution must answer these three questions. The speci ed sections discuss these questions
in detail.

Since the way in which we answer these questions often depends on the strategy of the basic business scenario, we need to
differentiate between two different scenario types:

Provider operations

The provider sets up a precon gured system solution, customized according to the needs of the industry. In this way, customers
buy a complete solution. They are not usually authorized to customize the solution themselves, except for a small number of
settings. It may also be necessary to differentiate between the following groups of customers:

ASP operations with friendly customers (such as a parent company with many subsidiaries)

In this case, each subsidiary has a strictly de ned eld, and is not in direct competition with the other subsidiaries.

ASP operations with competitors as end customers

IT service operations with independent companies (group subsidiary scenario)

Unlike ASP operations, the services offered by the provider are restricted to the technical infrastructure, with the application only
partly precon gured by the provider, if at all. The customizing of the solution is left to the customers, there being no difference
whether they use the service of a host provider, or organize the application themselves. In this case, customers must be allowed to
make customizing changes.

You must take into account the guidelines for multiclient operations that apply to cross-client changes. It is safe to say that
systems operating with many different types of customers will place higher demands on how they coexist, than for customers with
standardized pro les and little need to make changes.

Data Administration Requirements


Use
An SAP product can operate with multiple clients if the following two requirements are met:

All application tables are de ned as client-speci c.

For more information, see Client-Speci c Data.

A short description exists for all cross-client Customizing objects. This description tells you which function is realized by
the object, and how the operator of a multiclient system must react to different requirements from competing clients. If
needed, you can call up a list of all cross-client Customizing objects included in an SAP component.

When you operate a multiple client system, it is important to know which Customizing settings apply to all clients, since
changes to these objects will always affect every client. This means that providers must know about the functions
contained in all cross-client customizing tables maintained in their solutions, so that they can react to the competing
demands made by multiple clients. Changes to these objects requested by a single customer can only be incorporated
after synchronizing them with the settings in all other clients. The provider might need to de ne multiple Customizing
settings to meet different requests, and then offer these settings to all customers.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a4… 3/16
12/20/2019

Customer Data and System Data


A client is de ned as a self-contained commercial, organizational, and technical unit within an SAP System. This means that all
business data within a client is protected from other clients. Each client has its own customer data, which can be considered as
the exclusive property of this client.

However, the SAP System offers a system solution that is implemented for all clients in a central repository and cross-client tables
(central data source).

As far as data administration is concerned, a multiple client option means that the data required for operating the system is well-
de ned and assigned either to central data or customer data. The following basic guidelines apply:

Only the assigned client can read or write to customer data, and in occasional cases (troubleshooting, background job
administration, or change management) the provider. Customers can never read or write to the data of another customer.

All clients can read the centrally stored data, however, only the provider can make changes, not any of the clients (end
customers).

Integration
SAP data models map customer data to client-speci c tables, and central data to cross-client (or client-independent) tables. The
cross-client data includes the Repository itself, but also a set of cross-client control data, which is described in more detail later in
the document.

Note
The client is included in the data model as a mapping of the Customer entity, in addition to the business application solution.
This means that the client does not contribute to the modeling of the application solution. Instead, it makes sure that all data
created during business processes is assigned exclusively to its owners (clients).

Client-speci c customer data includes all application tables (master data and transaction data), as well as a large number of
Customizing settings.

Application Tables

These are tables that hold business data such as master data or transaction data. This data can be created, changed, or deleted at
any time by regular business processes. Application tables have the attribute Delivery Class and attribute value A in the ABAP
Dictionary.

Customizing Tables (business-relevant)

These tables contain data that can be used to control the business processes:

Data that represents the organizational structures of the enterprise

Parameters that control business processes.

Customizing tables, there is also a range of cross-client Customizing tables. Because Customizing objects are numerous and
varied we will categorize and explain them in more detail, including their relationships with clients, in the following section.

Note
There are often strong mutual dependencies between Customizing tables. For this reason, tables are not maintained
individually, but as Customizing objects. The formal relationships integrated into a Customizing object makes sure that it

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a4… 4/16
12/20/2019
remains consistent in its table group when you edit its entries. In the following we speak about Customizing objects when we
mean the representation of Customizing tables on the user interface, and about Customizing tables when we mean their
concrete form on the database.

A Customizing object can contain both client-speci c tables and cross-client tables. We speak of client-speci c objects if all
tables maintained through this object are client-speci c. Likewise, if at least one cross-client table maintained through the
object can be changed, then the object itself is cross-client. Remember that an object is client-speci c if it contains one or
more cross-client tables whose values can only be displayed or read, and not changed.

More Information
Client-Speci c Data

Cross-Client Customizing

Client-Speci c Data
Application Data

To be able to guarantee the multiclient compliance of an SAP solution, the application tables must be client-speci c. This is an
essential prerequisite for the isolated data needed by multiple clients. The existence of cross-client application data would mean
that you have write access to this data from all clients. This would contradict the multiple client operations of the corresponding
sub-application.

Client-Speci c Customizing

The majority of business Customizing data is client-speci c. This client-speci c data includes:

Parameters relating to organizational structures, since the organizational structure belongs only to the enterprise.

Parameter tables that control business processes de ned in client-speci c Customizing. Each customer must be able to
de ne this data individually. Typical multiclient scenarios will usually combine clients that have very similar requirements,
and that do not make changes to the program logic of the SAP solution. Also, all technical system administration tasks are
performed by the provider, who is usually also the owner of the required technical settings. Despite the similarity of the
customer requirements, it is still a good idea not to restrict the customer too much with prede ned Customizing. You can
then react to individual requests in emergencies. This is particularly useful in scenarios where the clients are competitors,
since optimized business processes often form the basis of a pro table enterprise in a competitive market.

Cross-Client Customizing
The following requirements must be ful lled for cross-client Customizing if an SAP product is to be considered as multiclient
compliant.

A short description exists for all cross-client Customizing objects. This description tells you which function is realized by the
object, and how the operator of a multiclient system must react to different requirements from competing clients. If needed, you
can call up a list of all cross-client Customizing objects included in an SAP component.

When you operate a multiple client system, it is important to know which Customizing settings apply to all clients, since changes
to these objects will always affect every client. This means that providers must know about the functions contained in all cross-
client customizing tables maintained in their solutions, so that they can react to the competing demands made by multiple clients.
Changes to these objects requested by a single customer can only be incorporated after synchronizing them with the settings in

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a4… 5/16
12/20/2019
all other clients. The provider might need to de ne multiple Customizing settings to meet different requests, and then offer these
settings to all customers.

Note
A customer can assume that the client dependency requirement for application tables described under Client-Speci c Data is
ful lled in the standard SAP delivery, and does not need to take any further action. However, the requirements of cross-client
Customizing described in this section are also signi cant for customers.

Categorization by Usage Type

You can use system tools to help determine an object list. For a description of these tools, see Tool Support for Generating Object
Lists. A list of cross-client Customizing objects is generated for a speci ed component (either software component or application
hierarchy component). The objects are categorized by usage type to give you a better overview of which objects are relevant. The
usage type is a very generic category that speci es whether the object has a more technical or more business nature. There are
six different usage types.

The rst two categories belong to the technical settings of the system or its infrastructure (system pro le parameters).

Usage Category 1: System Parameters (SYP)

This category contains the settings of system pro le parameters. These parameters tune the system to available resources
and the technical infrastructure. These parameters have no effect on the business functions of the application.

Technical settings need to be made in contexts such as RFC destinations, client-server con gurations, buffers, and the
de nition of the system clients themselves.

A special form of system pro le parameters are those that cannot be changed by the customer, but which the customer is
noti ed of during the IMG implementation of the system. These settings are agged with the additional ID ro (read only),
which makes the ID SYP-ro.

Usage Category 2: Technical Organizational Support (ORG)

These settings are needed for controlling technical processes. This includes all tasks involved in setting up network
connections, and also the control parameters for background job scheduling.

The next two categories are closely related with programming logic. In some cases, the process ow control is extracted from the
programs and stored in tables. This makes modi cations much simpler. Some tables contain metadata for generating Repository
objects.

Category 3: Control Data with Program Characteristics (PCH)

This category contains cases where the programming logic is stored in Customizing tables. This makes transaction logic
more transparent, and easier for non-programmers to understand. This data is interpreted by the programs at runtime,
and controls the responses of these programs. This not only simpli es modi cations to the shipped SAP solution; by
separating modi ed ow logic and coded programs, the effort required to restore modi cations in update cycles is also
reduced considerably. This contributes to a great reduction in costs.

These tables are usually cross-client because they have direct references to Repository objects. Control logic is only
located in client-speci c tables in exceptional cases, such as screen ow control or screen eld control. In this cases, the
process ow can be in uenced on a client-by-client basis.

Category 4: Meta Data for Generating Repository Objects (MGR)

Some applications have extremely customer-speci c functions and interfaces, and cannot be shipped as a complete,
prede ned system solution. One example is the area Condition Tables for Pricing. All these applications are shipped only
as basis software, together with tools for tailoring the application to the needs of the customer. The software is modi ed
using Customizing generation technology; during Customizing, software developer tasks are performed with automated

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a4… 6/16
12/20/2019
support, but at a level close to the application. This approach makes it possible to adapt the software exibly to individual
applications that cannot be easily standardized, but still provide easy-to-use interfaces with high performance. The
generation of program parts ranges from individual functions (reports, program modules) to entire subapplications
(pricing, condition tables with dictionary objects, maintenance interfaces, and analysis programs).

Depending on the sensitivity of the data, or with regards to modi ed interfaces, you can also use client lters. For more
details, see Supporting Individual Customer Requirements.

The last two categories represent globally valid rules and characteristics.

Category 5: Basic Business Standards (BBS)

These are xed parameters for the business processes established in the installed system. These parameters complete the
installed SAP solution and cannot be modi ed for each client.

Category 6: Global Entities (GLO)

These settings are usually independent of a speci c enterprise, which means that they are independent of a speci c client.
Examples of this are currency de nitions or municipality keys. This reduces the amount of work needed to operate a
multiple client system, since the setting only needs to be made once in each physical system, and does not need to be
repeated for each client.

More Information
Tool Support for Generating Object Lists

Tool Support for Generating Object Lists


Use
The following tools are available for generating the object list described under Cross-Client Customizing.

ABAP program MULTICLIENT ANALYSIS: This program lists the application and Customizing objects for a speci ed
component. Customizing objects are listed with the table objects they contain. This means that you can recognize the
context in which a physical database table is used. For more information, see the report documentation on this program.

Multiclient Manager (Transaction MCLIMAN): This transaction also lists the Customizing objects for a speci ed
component, but only on one level. The usage type is also speci ed for each object. After you call the transaction you can
optimize the width of the columns. You can also use all List Viewer functions, such as sorting by columns, ltering by
column values, de ning individual views, and downloading to Excel (with the Export button).

Supporting Individual Customer


Requirements
Use
If the provider decides that competing demands from different clients will have to be accommodated in the Customizing settings,
this can be achieved only by de ning different object entries under different keys.

In extreme cases, large numbers of Customizing settings can be created for controlling identical business process steps. This can
make the selection using F4 help unmanageable. To make this data more manageable, the provider can de ne key namespaces for
each customer, if this is allowed by the key structure.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a4… 7/16
12/20/2019
In some SAP solutions client lters are already being used to reduce the amount of Customizing functions that are visible for each
client. This means that although an entry has been made available from a technical perspective, it is not initially visible on the
transactional end user interface; it rst has to be activated for each client. The corresponding lter tables are themselves de ned
as client-speci c. Some objects use authorizations as lters. For example, spool transaction display only those printers for which
the user has an authorization; the others are ltered out in the F4 list.

In multiclient systems, changes to cross-client Customizing settings can be made by the provider only, and not by end users.
However, changes must not be made in the production environment, as in single client systems. Customizing settings control the
way in which business transactions are processed; any changes to these settings can often have the same effects on transaction
logic as changes to programs. This means that you must make the changes rst in a development system.

The question arises of whether the multiclient structure should be replicated in the development/test, QA and production
systems, or whether its complexity can be reduced in the predecessor systems. The answer to this question depends on the
business scenario: An ASP scenario with standardized business processes (with practically identical Customizing) only needs a
template client in both the development/test and QA systems, in which the Customizing changes are tested. A group scenario
involving multiple independent clients needs as many clients in the test and QA system as there are production clients.

Checking the Multiclient Compliance of Add-


On Products
Use
Two analysis tools are available for checking whether multiple clients in an SAP solution or add-on product could cause problems,
and where.

Report TRANSPORT_TABKEY_ANALYSIS

In the ASP environment, a product (an ASP solution) is often represented by a set of precon gured Customizing settings
for a particular industry, without any changes being made to Repository objects. In this case, you can use the report
TRANSPORT_TABKEY_ANALYSIS. This tool is typically implemented in the Precon gured Systems area, where a third-
party vendor delivers a complete set of Customizing settings for an industry solution. An ASP with multiple clients
obviously needs to know which of these settings are cross-client, since these settings apply to all ASP customers, and
cannot simply be modi ed for each individual customer.

Report MULTICLIENT_ANALYSIS

In other cases, the solution also contains program developments. This means that the piece list contains entries for
Repository objects (ABAP Dictionary objects, programs and/or Customizing object de nitions). You can use the report
MULTICLIENT_ANALYSIS to check whether these developments are compatible with multiple client operations.

For more information on the report MULTICLIENT_ANALYSIS, see Tool Support for Generating Object Lists.

Both tools generate a result list, which you can then analyze for multiclient compliance purposes.

If the piece list contains both Customizing entries and Repository objects, then you must use both analysis programs. Each
program lters and evaluates the relevant entries from the speci ed piece list to see whether there might be any con icts with
multiple clients.

A prerequisite for using this tool is that the product you are analyzing can be identi ed within the SAP System. Products are
mostly de ned by one or more transport requests, since they contain a complete piece list of all objects belonging to the product.
In more unusual cases you can put together a piece list for the product from a list of packages or components. Most importantly,
the resulting piece list must describe the product exactly, which means the following:

The piece list is complete.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a4… 8/16
12/20/2019
The piece list does not contain any objects that do not belong to the product.

This means, for example, that the transport requests of a client transport is not a permitted piece list, since it contains the entire
SAP System, and you cannot recognize the product.

Data Isolation in Multiclient Systems


Use
To guarantee exclusive access to the data of a client, you need to take extra data access logic precautions as well as categorizing
the data correctly. A user who logs on to his or her client in the system must have all activities restricted to his or her customer
data, and be denied access to the data of other clients.

Data isolation is guaranteed if each time you access client-speci c tables, you are implicitly restricted to the active logon client
within the database interface, and unable to manipulate this access from the application program level or at runtime. Four
questions arise from this:

Question 1: Is there a way to prevent the implicit selection of clients?

The logic of the database interface is a piece of xed code and cannot be accessed from outside. Dynamic client selection
is triggered only by the table attribute client-speci c table, which is a xed attribute of the table in the ABAP Dictionary.
There is no way of temporarily removing this attribute.

Question 2: Is there a way to manipulate the active logon client from outside, so that you can access the data of another
client?

During a session, a user addresses the client only once, when entering the client explicitly in the logon window (if Single
Sign-On is used this is done implicitly using Central User Administration). It is not possible to log on to an SAP system
without selecting a client.

Once you have logged on, the client eld does not appear on the user interface again, and cannot be manipulated with
application transactions. This means that the client cannot be changed during a session.

Technical details: Once you have logged on to a client in a system, you remain in this client until the end of the session. You
can use the system variable SY-MANDT to query the active logon client in ABAP programs, however, this variable is
updated with the internally active logon client in each dialog step, making it impossible to be overwritten. Therefore, even
overwriting this ABAP variable externally has no effect. This means that even an ingenious application of breakpoint and
replace techniques cannot overwrite the active logon client from the outside.

Question 3: Are there generic tools in the SAP System that can be used to access any table?

There are generic tools that give you free access to table data, however, if multiple client operations are organized
correctly, they do not place client data at risk. One of these tools is the Data Browser. To access the Data Browser, choose
Tools ABAP Workbench Overview Data Browser (or call Transaction SE16). This tool xes the active logon client, which
means that the client is ltered in the same way as at the database interface. Client comparison functions are also
available, which are either included in the standard view maintenance functions or which can be accessed as a standalone
transaction (Customizing Cross-System Viewer (Transaction SCU0) and View/Table Comparison (Transaction SCMP)).
This functions are not functions that are permitted in production operation of the system. You can also lock them at the
transaction level. Accessing a different client requires two additional authorizations S_TABU_CLI and S_TABU_CMP, neither
of which may be assigned in a production system. In this way, you can protect data in a sensitive client from being
accessed. This can be controlled in the client settings in the client maintenance functions. To call this transaction, choose

Tools Administration Administration Client Administration Client Maintenance (SCC4).

The generic tools can be used to control access to different clients at several different levels of authorization. All tools also
guarantee that access to other clients is read-only access. Write-access is only possible in the client where you are
currently logged on.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a4… 9/16
12/20/2019
Question 4: What is the technical basis of the data isolation?

Viewed technically, each time a client-speci c table is accessed, the database interface implies an additional selection of
the active logon client, meaning that the WHERE clause is added to the SQL statement.

WHERE <client-field> = <login-client>

This substitution is made dynamically in the database interface at runtime.

The following summary can be derived from these four questions:

Access to client-speci c tables is carefully restricted to the currently active logon client, using the access concept
described above.

This client ltering affects both read and write access.

This logic is realized as part of the database interface, which makes it inaccessible to both programmers and end users.

Open SQL provides the language supplements CLIENT SPECIFIED and USING CLIENT (Basis 740, SP5), which can be used
to specify the client explicitly. In CDS views as well, where the value false is speci ed in the annotation @ClientDependent, the
client has to be speci ed in the selection condition. In contrast to Open SQL, Native SQL (EXEC SQL, ADBC, AMDP) does not have
automatic client control, which means that the programmer is responsible for client handling in these cases as well.

Incorrect client handling could be a potential approach for anyone attempting to misuse programs.

For example, a non-privileged user could intentionally use a client ID to read, misuse, or falsify the client data. The service provider
is the only administrator of the repository and therefore has a special responsibility for checking the use of the language
statements speci ed above when importing modi ed or additional programs. You should adhere to the programming guideline
that normal application programs should only be allowed to use Open SQL, without the language supplements CLIENT
SPECIFIED and USING CLIENT. In fact, for data buffering reasons, this guideline should be obligatory.

In principle, this applies to all standard SAP application programs, except the following:

Special functions: Upgrade utilities, comparison tools, and ALE communication functions use a range of special functions
that access data in other clients. These, however, are individual technical service functions whose code must never be part
of an application program. Acceptance tests before shipment of an SAP Release ensure that even in these exceptions the
current logon client (SY-MANDT) is used, and not hard-coded client values.

A prerequisite for the reliable client check is the correct classi cation of the database tables in the dictionary. The corresponding
checks are described in section Checking the Multiclient Compliance of Add-On Products.

In uence on Processes and Runtime


Use
This sections describes the in uence that multiclient operations have on processes and runtime.

More Information
How Do Extra Clients Affect Performance?

What Extra Load Does a Client Place on an Upgrade?

How Do Extra Clients Affect Performance?


https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a… 10/16
12/20/2019

Use
From the point of view of the operating system and the database system, the client is just a key eld of the application and
Customizing tables. Performances depends solely on the following:

How many users are active in the system

What their application behavior is, that is, how many different business transactions or evaluations are made by these
users

How much data is being addressed, and its distribution in the physical memory

The database resources and hardware performance required is derived from the information above, and not from the number of
clients. When you size the database, calculate an initial volume of between 1 and 4 GB of Customizing data for each client,
depending on the SAP components you have installed.

The number of clients does, however, have direct in uence on the following two aspects, and must be taken into account.

Upgrade: More clients lead to longer runtimes.

Buffer: More clients use more main memory (buffer demand), since the client is mapped in the buffer directory structure.
This affects both buffer types: Keyrange Buffer and Single Record Buffer. The amount of extra memory needed varies
hugely of course from case to case. We recommend a guideline of 10 MB for each client.

What Extra Load Does a Client Place on an


Upgrade?
Use
The extra upgrade load is caused by importing client-speci c table entries for the Customizing settings. The more clients in a
system, the more imports, since these entries must be distributed to all customer clients (cascaded).

Note
New tables for new functions are usually shipped with content. Client-speci c tables, whose delivery class (E, G, S, or W)
cascades them into all customer clients, contain data that must be imported into all clients, and not just into a single target
client. The overhead rises in an approximately linear relationship with the number of clients. The extra load is mainly
concentrated in the upgrade phases TABIM, XPRAS, and LANG_IMP.

You must take extra clients into consideration when you size your database. If the data of the basis database system is
structured in tablespaces, then the following tablespaces are affected:

PSAPSTABD +2%

PSAPSTABI +4%

PSAPPOOLD/-I +8%

PSAPBTABD/-I +1%

The actual increase in imported data varies of course from case to case.

This estimate was derived from various measurements, but can vary slightly. It is always a good idea to limit the number of clients
at an initial stage, so that you are not confronted with unacceptably long upgrade downtimes at a later point.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a… 11/16
12/20/2019
You must evaluate the costs you save when operating a system with multiple clients against the increase in system downtime, and
come to an appropriate decision.

The main phase of the upgrade, in which the system shuts down, substitutes the production database with the prepared tables
with relatively little effort. This also reduces the total length of downtime. However, when you plan your system operations, you
must remember that the cascade overhead described above remains an issue. The cascade phase is just relocated from downtime
to the upgrade preparation phase, which means it competes with production operation of the system. However, you can usually
solve this con ict by organizing your system operation effectively.

Multiclient Administration
Use
This section summarizes the most important administration tasks necessary for the smooth operation of a multiclient system.

Prerequisites
The following discussion is based on a system/client landscape in which n clients are set up in m systems, where m is kept as
small as possible.

Process
Preparing and Planning the Multiple Client System Landscape

When you distribute the n customers among the systems, it is a good idea to rst categorize the customers according to their
differing requirements, for example, by application solution.

Any decision you make must also be reversible, in case the basic conditions of your setup change. Relocating a complete client
from one node in a system landscape to another entails the same amount of time and effort as migrating an installation from one
host to another, but it can still be included in your calculations.

Setting Up the System Landscape

You can use the Transport Management System to help you map your scenario to a system/client landscape. To call the Transport
Management System, choose Tools Administration Transports Transport Management System (STMS).

Setting Up the New Client

Set up the new client with a template client as a basis, using the functions of the client copy tool. To call these functions, choose
Tools Administration Administration Client Administration Client Copy .

To prevent client settings from making changes to Repository objects and cross-client Customizing data, use the client
maintenance functions. To call client maintenance, choose Tools Administration Administration Client Administration Client
Maintenance (SCC4).

Note
You can set each client so that it is locked for comparison tools; it cannot even be viewed by them. This lock applies regardless
of the authorizations held by the user trying to access the data.

Note

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a… 12/16
12/20/2019
Note on assigning authorizations: We recommend that you do not assign the authorizations S_TABU_CLI and S_TABU_CMP,
since they allow access to cross-client objects, or read access to other clients for data comparison. This is a redundant
measure when you consider the lock protection mentioned above, however it does provide effective double security.

For more information, see BC - Client Copy and Transport (BC-CTS-CCO).

Deleting a Client

You can use the client copy tools to delete an obsolete client.

Migrating a Client

You can use the client copy tools to migrate a client from system A to system B.

Change Management (Central Customizing Changes)

We recommend that you use Business Con guration Sets (BC Sets) to make necessary changes to all clients, and then distribute
these changes.

Recovery

Make a normal recovery to another backup system, and then migrate the restored client from the backup system to the
production system.

For more information, see Recovery Solution.

Comparing Clients

The SAP Web Application Server contains dedicated functions for comparing the Customizing settings of one client with another
client or template client:

Cross-System Viewer Compares complex Customizing environments. To call the Cross-System Viewer, choose
Tools Accelerated SAP Customizing Customizing Cross-System Viewer (Transaction SCU0).

To compare individual tables or views, use the comparison function in the standard table maintenance transaction (SM30)
or the view/table comparison transaction for any number of tables (SCMP).

Client-Speci c Monitoring

The CCMS Monitoring tools also include some options for client-speci c online monitoring of certain transactions and clients (see
SAP Note 308048 ). These include the following:

Transaction load for each client (number of dialog steps)

Average response time for some or all transactions in a client

Client-speci c monitoring:

Choose Administration System Administration Monitor Performance Workload Analysis (ST03N). At the top left of
the navigation screen, choose Expert (other options are Administrator and Service Engineer). Choose TOTAL under
Today's Workload. Select a time period (such as this week). Then choose Analysis Views User and Settlement
Statistics Settlement Statistics in the bottom left navigation screen.

You have a restricted database space analysis option for each client, as described in SAP Note 118823 .

Background Job Support

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a… 13/16
12/20/2019
You use client-speci c services for administering background jobs. You can start and restart background jobs from the
logon client only. If you have sufficient administration authorizations you can also monitor jobs in other clients, however,
you cannot modify them. No options for monitoring jobs started in other SAP Systems are supported.

The background job administration functions offer a range of interfaces. These interfaces are already used in the context of
many SAP solutions. In addition, you can also choose from a range of established external administration tools offered by
third-party vendors, which offer cross-client and cross-system job administration. You integrate these external solutions
into SAP using the BC-XBP interface.

System Administration

Database and system maintenance functions are supported only at the physical system platform level, and not at the client level.
This affects the following:

Database reorganization

Data backup

Release upgrades

Hardware and software maintenance

More Information
For more information, see

BC - Client Copy and Transport (BC-CTS-CCO)

Recovery Solution

Security Measures for Multiple Client Operations

Recovery Solution
Use
Backup and recovery utilities are functional elements of every database system. Recovery utilities use their knowledge of the
physical database structures to allow you restore backed up data as quickly as possible. Using programs based on normal SQL
interfaces to restore backups would take signi cantly longer.

Each client represents only a small section of the entire data. This leads to the question of whether and how to reset a single client.
This section only deals with recoveries for multiple client systems, when the data of a single client has been totally destroyed by
handling errors (for example, by a background job with incorrect parameters). A normal database recovery would also reset all the
other (undamaged) clients to an older state. This action could lose data in these clients, since all entries made after the reset time
would be lost, and need to be repeated. This is often not possible.

A single client recovery solution, however, is possible, using client transport tools; although it requires more time and effort than
using the database recovery utilities. When recovering a single client, the backup is located on a separate standby host. This
restores the data back to consistency. The modi cations are repeated for the affected client (under corrected conditions) and
updated. As soon as possible (in the following night or on the weekend) the updated client is restored to its original system. See
also SAP Note 31496 . If necessary, all system activity must take place on the replacement host until the data can be
transported back. This places more strain on network and communications. Until the client is restored, all changes to cross-clients
must be made in parallel in both systems, or, if possible, delayed.

As already stated, this emergency solution demands more effort than a database recovery:

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a… 14/16
12/20/2019
The standby host must have a least the same dimensions as the production host, so that the backup can be located there.

The nal transport back to the production host cannot be made by database utilities. Instead a client transport is used; a
program that is based on the SQL interface. Even though this transport is restricted to client-speci c tables, it will be
considerably slower than the restore time of the database utilities.

If the client you are repairing needs to be used in the recovery system temporarily, then you must schedule extra time for
setting up network and communication links, and testing them.

Other recovery scenarios, in which the entire database is destroyed, will always affect all clients, even in a multiple client system,
and require the use of database utilities.

The following diagram shows a single client backup scenario based on a client copy:

Security Measures for Multiclient Operation


Use
In general, users and authorizations can be maintained only by the provider, and not by customers.

When looking at the ways in which multiple client systems differ from single client systems, we need to ask ourselves how hackers
can exploit the transactional interface of the SAP System. This involves the implicit and automatic restriction of all access to the
customer's own client at the database interface. You cannot break this restriction by modifying elements of the user interfaces of
SAP solutions. This means that access to data in other clients can be prevented reliably at the transaction user interface level.

The next questions is how to guarantee security at the database level. The setup must make sure that a user logged on to the
system can only call SAP transactions, and cannot access database or operating system services. This is not a problem speci c to
multiple clients, however, the risks are particularly high when competitors save their data in the same database. In a single client
solution it is possible to access customer data once you have access at the database or operating system level. However, with a
large number of customers the effort required is much greater, due to the separate databases. ASP customers must not have
authorization to access the database and operating system level. The standardized programming interface ODBC (Open Database
Connectivity) can be used to regulate access to databases. SAP solutions already contain these security precautions as standard.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a… 15/16
12/20/2019
Only the provider may customize and develop programs. If customers still need to access the development or test systems, a
detailed authorization concept must prevent them from assigning additional authorizations in the production system. Customers
must also not have programming authorizations, otherwise they could program their own evaluations for the production system.
For more information on options for securing multiple clients with regard to modi cations and the import of additional program
objects, see the section Checking the Multiclient Compliance of Add-On Products.

As in single client systems, no authorizations for Customizing and development must be assigned in production systems. This
usually affects the provider's employees. Particularly critical are authorizations for debugging transactions and runtime analyses.
Access to external commands and le systems must also be refused. For more information on the security of production systems,
see the SAP Security Guide, which is available free of charge in the SAP Service Marketplace.

In an ASP environment, ASP customers will only require access to background jobs in very rare cases. However, if access is
required, background authorizations must be restricted to the individual clients (authorization object s_admi_fcd). Spool
authorizations must be de ned so that each customer is assigned his or her printer only, to avoid spool requests being printed on
the wrong printers by mistake. For a better overview of authorizations, the ASP should choose a suitable naming convention for
printers, such as <client><id>. In this way you can easily and reliably use the authorization object s_spo_dev to restrict
access to those printers assigned to a particular client. The authorization also restricts the search help of a customer to his or her
printers only.

https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000404&topics=4ec36e34d8f9657fe10000000a… 16/16

Оценить