The interface of the Customizing maintenance to the Transport System is described in a separate release note Customizing Request Management . This means that now all changes to customizing settings can be recorded in a change request (former long name: transport request). The numerous changes to setting parameters which are made in the course of a customizing project no longer need to be laboriously noted and then reassigned for transport. Rather, the work of a customizer or a Customizing team is recorded on the transport side automatically.
Transporting the customizing settings into another system is thus already completely prepared and it only needs the release of the transport request. The same applies to transferring into another client of the same system since a tool for copying a client is available for this (see release note Copying clients.
However, it is not now always required that every single change should be recorded in the system. There are also test, training or demonstration clients in many systems in addition to the production client. Recording changes would miss the point and be annoying here. In the extreme case, it would even lead to an unintentional transport, and could therefore cause the disruption of a target client.
To be able to control these partially competing requests simply and clearly, the client was extended by corresponding operative attributes which can be included in table T000 for Release 3.0A.:
Please note:
Activating the transport connection for a chosen client only affects changes
to its client-specific Customizing settings, however not client-independent
ones. These are always recorded together with changes to Repository objects
(programs, screens...) and need no client-specific specification in table T000
(which would also be inconsistent).
To make this distinction more transparent, a new transport type of the Customizing request was implemented for 3.0A, which now exists for Repository objects and Customizing for all clients in addition to (normal) change requests. Customizing requests (request category CUST) contain exclusively client-specific objects, while system requests (category SYST) contain any objects as are known from preceding releases.
If you activate the transport recording in your client, Customizing requests are predominantly generated by it. This then ensures that the result of a customizing project can be transported into the target client of another system without affecting other clients there.
Ensuring the effect restriction to only one client cannot occur during system transports. Rather, this would have to be checked for objects for all clients before the import. If client-independent objects are contained in this, an adjustment of the corresponding settings would be effective in the source system and target system, to be able to estimate the effect on all remaining clients.
Further control characteristics of the client are:
Please maintain the above-mentioned client attributes in your client table T000, in particular the following attributes according to:
The client table was extended for 3.0A with just these client fields so that they are initial in your system.