Extended transport control has the following functions:
Extended transport control makes daily transport tasks easier, and it increases security. It also reduces the need for communication between project leaders and system administrators, since the transport routes can now be configured completely. No additional details about the target client need to be given at the time of import.
You can make use of the following extended functions when you configure transport routes in Transport Management.
When you create Customizing requests, the default transport target of the requests is determined by the standard transport layer. When you use extended transport control, you can set a different standard transport layer for individual clients from that set in the SAP System. This means that you can forward Customizing requests from different clients into different transport targets.
The client-specific standard transport layer is also the default transport layer for new packages that have been created in a client. If you accept this default, then the cross-client objects that have been created in cross-client Customizing are transported along the same route as the corresponding client-specific Customizing.
The transport targets of consolidation and delivery routes do not just specify a system, they also specify a client. Client-specific transport targets are entered in the form:
Target groups combine several client-specific transport targets under a symbolic name. You can specify target groups when you define consolidation and delivery routes.
To differentiate them from traditional transport targets you must start and end the names with "/" (for example,
When you release a request which has a transport group as a transport target, then the request is flagged for import into every individual transport target<system_name>.<client> in the group.
Consolidation routes determine (for each transport layer) where changes made in the SAP System are transported after the request has been released.
If you have activated extended transport control, then the transport target can be a particular client in a target system or target group.
If you do not activate extended transport control, you can specify systems only as consolidation targets. This means that the transport administrator has to specify the correct target client at the time of import.
Delivery routes determine whether change requests are to be flagged for import into subsequent systems/clients, after they have been imported into a system.
If you have activated extended transport control, then you can set the delivery routes as client-specific. This makes it possible to supply several clients in one system in sequence.
You can also specify a target group as the target of a delivery route.
If you work with extended transport control, you can import requests into different clients in a system without using
When you first import a request into a system, all the objects are imported completely. Any subsequent imports into other clients in the system only import client-specific components.
This makes it possible to set up consolidation routes and delivery routes between different clients in the same system.
This means that you can also transport client-specific objects (Customizing) into another client in the development system. Client-specific Customizing and Repository objects are ignored by the import.
The following graphic shows an example of two production systems, PR1 and PR2, linked by ALE. Both of the production systems are preceded by a QA system (Quality Assurance System). The two QA systems are also linked by ALE.
The example merely portrays the options available with extended transport control. It is not a recommendation for setting up your own system landscape.
Development takes place in three clients in the system DEV.
The latter two transport targets are the development clients for country-specific settings. Requests with the transport target
Alternatively, you can specify just the targets "system DEV, client 100" and "system DEV, client 300" in the target group/COMMCUST/, and set up a delivery from "system DEV, client 100" to "QA1, client 010" and a delivery from "system DEV, client 300" to "QA2, client 312". This defers the imports into the QA systems.
In both cases, the ALE functions remain stable, since both QA-PRD routes are being supplied in parallel.
The QA systems automatically deliver to the correct target clients in the production systems, since the target client is specified when the delivery routes are defined.
Transport route configurations are activated according to an 'all or nothing' rule; either the parameter is set in all systems connected by transport routes, and these systems only use transport routes with specified target clients, or the parameter is deactivated for all systems, and only target systems are specified.
You can, however, configure two separate system groups, only one of which uses extended transport control.
The buffer format that has been used until now does not include target clients (buffers are the operating system files in which the transport requests are flagged for import).
Extended transport control introduces a new format for the buffer lines. This format has, among other things, space for the target client.
For security, versions of the transport control programtp that do not recognize this new format are not permitted to process the new buffers. An appropriate entry in the transport profile prevents this in the system.