Cross-Client Customizing
Cross-Client Customizing
Definition
The following requirements must be fulfilled for cross-client Customizing if a mySAP.com 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 a mySAP.com 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 you must know about the functions contained in all cross-client Customizing tables maintained in your solution, so that you can react to the competing demands made by multiple clients. Changes to these objects requested by a single customers can only be incorporated after tuning them with the settings of all other clients. The provider might need to define multiple Customizing settings to meet the requirements of different customers, and then offer these settings to all customers.
A customer can assume that the client dependency requirement for application tables described under
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 specified 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 specifies whether the object has a more technical or more business nature. There are six different usage types.The first two categories belong to the technical settings of the system or its infrastructure (system profile parameters).
This category contains the settings of system profile 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 configurations, buffers, and the definition of the system clients themselves.
A special form of system profile parameters are those that cannot be changed by the customer, but which the customer is notified of during the IMG implementation of the system. These settings are flagged with the additional ID ro (read only), which makes the ID SYP-ro.
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 flow control is extracted from the programs and stored in tables. This makes modifications much simpler. Some tables contain metadata for generating Repository objects.
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 makes it easier to modify the shipped mySAP.com solution, the split between modified flow logic and coded programs also significantly reduces the work needed to restore modifications when upgrading the system. 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-specific tables in exceptional cases, such as screen flow control or screen field control. In this cases, the process flow can be influenced on a client-by-client basis.
Some applications have extremely customer-specific functions and interfaces, and cannot be shipped as a complete, predefined system solution. One example is the area Condition Tables for Pricing. All these applications are shipped only as basis software, together with assembly kits for tailoring the application to the needs of the customer. The software is modified using Customizing generation technology. The customizer works as a software developer with automated support, but at a level close to the application. This approach makes it possible to adapt the software flexibly to individual applications that cannot be easily standardized, but still provide easy-to-use interfaces with high performance. The parts of a program that can be generated range from individual functions (reports, programming modules) to entire sub-applications (pricing, condition tables with ABAP Dictionary objects, maintenance interfaces, and analysis programs).
Depending on the sensitivity of the data, or with regards to modified interfaces, you can also use client filters. For more details, see
The last two categories represent globally valid rules and characteristics.
These are fixed parameters for the business processes established in the installed system. These parameters complete the installed mySAP.com solution and cannot be modified for each client.
These settings are usually independent of a specific enterprise, which means that they are independent of a specific client. Examples of this are currency definitions 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.
See also:
For more information, see
Tool Support for Generating Object Lists.