Datasheet

12 chAPter 1
confIgurAtIon toolS
All programs and a small amount of tables are shared among the clients within an
environment. ese are known as client-independent objects. For example, table
(view) V_T021S is client independent, meaning that, when this table is changed in
the conguration client, the setting automatically takes eect in all clients in that
environment because there is only one V_T021S that is used by all clients in that
environment. A change to a client-independent table should be made only in the
conguration client; the Basis group controls this setting when it sets up the cli-
ent. e option to allow client-independent changes is set at the client level in table
T000. Sometimes, when testing new design and development in the sandbox, you
are required to make a change in the conguration client. It is ne to design in the
conguration client as long as you are making only client-independent changes.
Each consultant/developer is responsible for keeping track of their individual trans-
ports. Transaction code SE10 allows you to view and manage all transports you have
created. You can also view transports created by other developers. is transac-
tion allows viewing of only modiable (unreleased), only released, or both released
and unreleased transports. e default is set to modiable (unreleased) transports.
Figure 1.1 shows the initial Transport Organizer screen.
FIgurE 1.1 You can use transaction code SE10 to view and manage transports on the Transport Organizer
screen.
Once you are ready to unit-test your conguration, the related transports must be
released so that the changes can move from the conguration client to the devel-
opment-testing client. It is normally the responsibility of the consultant/developer
to release their own transports and let the Basis group know that they are ready
to move via the procedures set forth in their project. is is an implementation
23288c01.indd 12 2/19/09 10:55:35 PM