change and transport system overview

™

Change and Transport System -Overview

HE

LP

.BC

CT

S

Re lease 4 .6B

Change and Transport System - Overview SAP AG

2 December 1999

Copyright

© Copyright 2000 SAP AG. All rights reserved.

No part of this brochure may be reproduced or transmitted in any form or for any purpose withoutthe express permission of SAP AG. The information contained herein may be changed withoutprior notice.

Some software products marketed by SAP AG and its distributors contain proprietary softwarecomponents of other software vendors.

Microsoft®, WINDOWS®, NT®, EXCEL®, Word® and SQL Server® are registered trademarks ofMicrosoft Corporation.

IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®,AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

ORACLE® is a registered trademark of ORACLE Corporation, California, USA.

INFORMIX®-OnLine for SAP and Informix® Dynamic ServerTM

are registered trademarks ofInformix Software Incorporated.

UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of The Open Group.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World WideWeb Consortium, Laboratory for Computer Science NE43-358, Massachusetts Institute ofTechnology, 545 Technology Square, Cambridge, MA 02139.

JAVA® is a registered trademark of Sun Microsystems, Inc. , 901 San Antonio Road, Palo Alto,CA 94303 USA.

JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license fortechnology invented and implemented by Netscape.

SAP, SAP Logo, mySAP.com, mySAP.com Marketplace, mySAP.com Workplace, mySAP.comBusiness Scenarios, mySAP.com Application Hosting, WebFlow, R/2, R/3, RIVA, ABAP, SAPBusiness Workflow, SAP EarlyWatch, SAP ArchiveLink, BAPI, SAPPHIRE, ManagementCockpit, SEM, are trademarks or registered trademarks of SAP AG in Germany and in severalother countries all over the world. All other products mentioned are trademarks or registeredtrademarks of their respective companies.

SAP AG Change and Transport System - Overview

December 1999 3

Icons

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Tip


4 December 1999

Contents

Change and Transport System - Overview.......................................................5Basics of the Change and Transport System............................................................................. 6Change Management in the SAP System Landscape................................................................ 7Clients and Their Roles................................................................................................................. 9System Landscape ...................................................................................................................... 11Change and Transport Organizer - Concept............................................................................. 14Transport Management System - Concept ............................................................................... 17Basics of Transport Control ....................................................................................................... 20

Transport Layers and Transport Routes .................................................................................. 21Assignment of Development Projects to Transport Layers ...................................................... 24Extended Transport Control ..................................................................................................... 26

Transport Strategy in the CTS.................................................................................................... 30Using Projects to Control Transports ....................................................................................... 31TMS Quality Assurance............................................................................................................... 32Special Transport Workflow ....................................................................................................... 34Transport Strategy for Individual Transports ........................................................................... 35Transactions and Tools in the CTS ........................................................................................... 37Change and Transport Organizer .............................................................................................. 38

Workbench Organizer............................................................................................................... 39Change Requests................................................................................................................ 40

Customizing Organizer ............................................................................................................. 41Customizing Requests ........................................................................................................ 42

Transport Organizer ................................................................................................................. 44Transports of Copies and Relocations ................................................................................ 45Piece Lists ........................................................................................................................... 47Client Transports ................................................................................................................. 48Delivery Transports ............................................................................................................. 49

Request Overview .................................................................................................................... 50Functions in the Request Overview .................................................................................... 52

Organizer Tools ........................................................................................................................ 54Transport Management System (TMS) ...................................................................................... 55Authorizations in the CTS........................................................................................................... 56

Authorizations in the CTO ........................................................................................................ 59Authorizations in TMS .............................................................................................................. 61

TMS Trusted Services......................................................................................................... 63Setting Authorizations for TMS ........................................................................................... 64


Change and Transport System - Overview

December 1999 5

Change and Transport System - OverviewThe Change and Transport System (CTS) is a tool that helps you to organize developmentprojects in the ABAP Workbench and in Customizing, and then transport the changes betweenthe SAP Systems and clients in your system landscape.

This documentation provides you with an overview of how to manage changes with the CTS andessential information on setting up your system and client landscape and deciding on a transportstrategy. Read and follow this documentation when planning your development project.

For practical information on working with the Change and Transport System, see Change andTransport Organizer [Ext.] and Transport Management System [Ext.].


Basics of the Change and Transport System

6 December 1999

Basics of the Change and Transport SystemThis section contains essential information on organizing your development and Customizingprojects. It describes the change tasks organized by the Change and Transport System andgives an overview of the roles of systems and clients within a system landscape. It introducesand explains important terms and concepts.


Change Management in the SAP System Landscape

December 1999 7

Change Management in the SAP System LandscapeBefore you can use the SAP software to control the business processes in your company, youmust first adapt it to your own business needs. This is usually done in an SAP implementationproject. Adapting and configuring is usually an ongoing process. Even after you start using thesystem productively, you still need to make changes to the SAP configuration. This may be dueto business or organizational changes in your company, or due to the implementation of newSAP functions. This is often linked to an upgrade to a new SAP Release.

SAP provides various tools for modifying the SAP software. Which tools you use depends on thetype and extent of your business requirements. Any modifications that you make with these toolare stored in certain tables in the SAP database.

Customizing ToolsThe most important configuration tool is the Implementation Guide (IMG [Ext.]). You can use theIMG to make all configurations possible in the SAP standard. Any modifications you make to theSAP software in the IMG are known as Customizing settings, or Customizing [Ext.] for short. Thisincludes setting up organizational units (company codes, plants, sales organizations, and so on)and making settings for controlling business processes.

The IMG splits the various Customizing settings into IMG activities and displays them in ahierarchical overview. This overview shows the recommended process flow and assignment tothe different applications of the SAP System. The IMG lets you filter out the relevant IMGactivities for a particular section of the SAP applications. You can also group IMG activitieslogically into IMG Projects. These projects are then worked on as an implementation project by aparticular team. You can document the requirements of a project and its progress in the IMGProject.

The changes that you make in the IMG are placed in the Customizing tables of the SAPdatabase. The contents of these tables are known as Customizing data. When you use the SAPapplications productively, the SAP runtime system analyzes this Customizing data and uses it tocontrol your business processes.

Most Customizing data is client-specific. This means that you can choose different Customizingsettings for each client in your SAP System that do not affect each other. Changes to theCustomizing settings in one client have no effect on system actions in another client.

However, there is also a significant amount of cross-client data that is relevant for all clients(such as the factory calendar). Note that if you change these types of Customizing settings, itaffects all clients in the SAP System.

ABAP WorkbenchIf the configuration options in the SAP standard are not enough to meet your requirements, youcan also add to the SAP standard functions. SAP provides the ABAP Workbench as a completeprogramming environment. The ABAP Workbench includes tools for defining data structures(ABAP Dictionary), developing ABAP programs (ABAP Editor) and designing interfaces (ScreenPainter and Menu Painter), as well as many other functions.

For example, you can use the ABAP Workbench to develop your own report programs ortransactions, or to modify or make your own enhancements to existing SAP programs. Theseenhancements are known as customer exits. However, this does require experience of the ABAPWorkbench and the SAP application where you want to develop.


Change Management in the SAP System Landscape

8 December 1999

The changes that you make in the ABAP Workbench are placed in the Repository tables of theSAP database. The contents of these tables are known as Repository data or Repository objects.Apart from a few exceptions, the Repository data is cross-client. As with cross-clientCustomizing, changes to Repository objects affect all clients of an SAP System.

Change and Transport System (CTS)The CTS is the central tool for managing changes to Customizing and Repository data that youmake in the IMG or ABAP Workbench. The CTS records all changes in change requests. Thechanges in change requests can be linked together logically, or can be completely independentof each other. Developers in a team can use a common request. You can create documentationfor a change request, where you can describe your changes in more detail. This makes it easierto see which data was changed by which user, and to what purpose.

When you have finished your work in the IMG or ABAP Workbench, or have reached a certainstage, you can release the request. The change request is then used to copy the changes fromthis client to other clients or systems. This automatic procedure is known as a transport.Transports of changes by the CTS allow you to develop in one environment, test yourdevelopment work in a test environment, and then, if the tests are successful, use it productively.This makes sure that productive operations are not placed at risk by faulty settings or programerrors.

Transports of changes between clients and systems are subject to rules that are set in the CTSconfiguration in the system landscape. One rule may be that changes are transported into a testenvironment before they can be copied to the production environment. All transports are logged,so that you can see when a change request was imported into a client or system, and whetherthere were any errors.

Application DataIn contrast to Customizing and Repository data, application data is not part of the configuration ofthe SAP software. Application data is the business data that the SAP applications process whenyou use them productively. It is split up into master data (such as material masters, customermasters and vendor masters) and movement data (such as contracts and financial documents).Application data is always client-specific.

The CTS does not manage changes to application data. It is also impossible to use the CTS totransport application data into other clients or systems.

If you want to copy master data and movement data between clients in an SAP System, or froma non-SAP system into an SAP System, or if you want to set up this data automatically, you canuse other tools, such as ALE (Application Link Enabling), CATT (Computer Aided Test Tool), oruse the application interfaces of the BOR (Business Object Repository).


Clients and Their Roles

December 1999 9

Clients and Their RolesWhen you log on to an SAP System, you log on to a particular client of this system. Any activitiesyou carry out in the system are always carried out in one client. When you plan your SAP systemlandscape, you must consider which clients you need for which activities.

By assigning activities to be performed in a client, you give each client a particular role. Thissection describes the most important client roles.

Since you need to adapt the SAP software for your own business needs, each SAP systemlandscape requires a client where Customizing settings, and possibly ABAP Workbenchdevelopments can be made. This client is known as the Customizing and development client, orCustomizing client for short. The abbreviation CUST is used for this client.

Before you can use the Customizing settings and Workbench developments productively, youneed to test them extensively for errors. Any faulty settings can seriously disrupt productiveoperations, and at worst, lead to the loss of productive data. The integrated nature of the variousSAP applications means that there are many dependencies between the different Customizingsettings. Even an experienced Customizing developer may not discover these dependenciesimmediately. The correctness of the settings can only be guaranteed with extensive testing. Theclient where these tests are made is the Quality Assurance Client, QTST for short.

A separate client is required for productive use of the SAP System. So that this client can beused without disruption, it is essential that no Customizing settings or Workbench developmentsare made here, and also that no tests are carried out. This client is known as the ProductionClient, PROD for short.

These three clients, CUST, QTST and PROD, are the central clients that exist in every systemlandscape. Standard system landscapes have precisely one client for each of these client roles.

We recommend that you make all your Customizing settings in a single Customizing client, andthen use the CTS to transport them to the other clients.

We also recommend that you do not make any Customizing settings or Workbenchdevelopments in the quality assurance or production clients. You can make sure of this bymaking appropriate client settings [Ext.].

In addition to the central clients, you can also set up other clients for other tasks. However, youmust remember that each extra client takes up additional system resources (main memory anddatabase space). They also need to be administrated. For example, you need to set up andadminister access authorization for the users, and also distribute any changes to other clientswith the CTS. You must weigh up the advantages and disadvantages of setting up other clients.

Examples of other client roles are:

Development test client (TEST): Developers can use this client to test their Customizingsettings and Workbench developments, before they release their change requests. In this clientthe developers can create test application data for realistic tests. If they discover errors, they canremove them in the Customizing client. A development test client is always set up in the sameSAP System as the Customizing client. This means that any changes that are made to cross-client data in the Customizing client are also immediately visible in the development test client.Changes to client-specific data are copied from the Customizing client to the development testclient using a special client copy [Ext.] function. The client copy function uses the unreleasedchange requests from the Customizing client to do this. The development test client is set so thatyou cannot make changes to Customizing data and Repository objects.


Clients and Their Roles

10 December 1999

Prototype or sandbox client (SAND): You can use this client to test any client-specificCustomizing settings if you are not sure whether you want to use them in this form. Any settingsthat you want to keep are then entered in the Customizing client. To prevent conflicts betweenthe prototype client settings and real settings in the Customizing client, you cannot makechanges to cross-client Customizing data and Repository objects in the prototype client. The CTSdoes not record changes made to client-specific Customizing data, and does not transport themfrom the prototype client. You can make sure of this by making appropriate client settings.

Training client (TRNG): To prepare end users for new functions that are to be transported intothe production client, you can set up a training client. The users can use the new functions in thisclient with specially created application data. This client is set so that you cannot make changesto Customizing data and Repository objects.


System Landscape

December 1999 11

System LandscapeThe system landscape contains all the SAP Systems that you have installed. It can consist ofseveral system groups [Ext.], whose SAP Systems are linked by transport routes.

After you decide which clients [Page 9] you need and which roles you want them to have, youneed to decide how to distribute them amongst the different SAP Systems. You can set upmultiple clients independently of one another in a single SAP System. However, when youconfigure the data, you must remember that cross-client Customizing settings and Repositoryobjects are identical for all clients in a single SAP System. Changes made in one client applyimmediately to all clients in the system.

Three-System LandscapeWe recommend a three-system landscape in which each of the central clients has its own SAPSystem.

This consists of a development system DEV, a quality assurance system QAS and a productionsystem PRD. The development system contains the Customizing client CUST, the qualityassurance system contains the quality assurance client QTST and the production systemcontains the production client PROD.

Make all changes to Customizing data and Repository objects in the Customizing client. Whenyou release the corresponding change requests, they are transported into the quality assuranceclient. This means that changes to cross-client data only appear in the quality assurance clientafter the transport. In the quality assurance client you can test whether the transports arecomplete, or whether any linked changes are missing and are still in unreleased changerequests. If the test is successful, the change requests are transported into the production client.The production client is completely separate from the other clients as regards cross-client data.

If you need other clients with additional roles you can set them up in one of the three systems.Set up the development test client (TEST) and the prototype client (SAND) in the developmentsystem. Set up the training client (TRNG) in the quality assurance system.


System Landscape

12 December 1999

DEV QAS PRD

Developmentsystem

Quality assurancesystem

Productivesystem

CUST

TEST

SAND

QTST

TRNG

PROD

Two-System LandscapeA two-system landscape is an alternative for smaller SAP implementations where littleWorkbench development takes place.

The two-system landscape does not include a separate quality assurance system QAS. Thequality assurance client is also in the development system DEV.

As in the three-system landscape, the production client is completely separate from the otherclients. The disadvantage of a two-system landscape is that cross-client data is used in both theCustomizing and quality assurance clients. This means that any changes that are made to cross-client data in the Customizing client can affect the tests in the quality assurance client. You canalso not guarantee that transports from the Customizing client will be complete. Although all testsin the quality assurance client were successful, errors could still occur after the transport into theproduction client. This problem is caused changes being made to cross-client data and then notbeing transported.


System Landscape

December 1999 13

DEV

Developmentsystem

Productionsystem

CUST

TEST

TRNG

PRD

PROD

QTST

One-System LandscapeWe do not recommend a one-system landscape containing all central clients in a single SAPSystem. Joint usage of hardware resources and cross-client data places serious restrictions onhow a single system operates. In particular, once the system is used productively, you can nolonger develop in it, unless you stop productive operation for the development and test phases.


Change and Transport Organizer - Concept

14 December 1999


The Change and Transport Organizer is referred to as the CTO in thisdocumentation.

The CTO comprises the following transactions:

• Workbench Organizer [Page 39] (SE09)

• Customizing Organizer [Page 41] (SE10)

• Transport Organizer [Page 44] (SE01)

The Workbench and Customizing Organizers are fully integrated into the ABAP Workbench andCustomizing tools. You can navigate between them in both directions. This enables you to:

• switch to the Workbench or Customizing Organizer from all transactions of the ABAPWorkbench and Customizing

• switch to the appropriate Workbench editor by double-clicking individual objects in an objectlist.

Recording ChangesThe CTO records and documents all changes to objects in the Repository and Customizing:

• Repository objects, for example

− ABAP Dictionary objects

− ABAP programs

− Screens

− User interface definitions

− Documentation

• Customizing objects, for example

− Settings for organizational units (plants, company codes, and so on)

− Settings for control tables

The Workbench Organizer helps you when you organize development projects by allowing you todistribute project work for individual developers or teams between different change requests.These change requests record all changes made to development objects and Customizingsettings. Objects from the areas of Customizing and the ABAP Workbench are managed andrecorded in separate requests. Special checks have been implemented for each of theseapplications.



December 1999 15

PDPersonnel Planning

& Development

PDPersonnel Planning

& DevelopmentDevelopmentProject

ChangeRequest

User

Task Task Task Task

FIFinancial Accounting

FIFinancial Accounting

SDSales & Distribution

SDSales & Distribution

You access the CTO from a Request Overview [Page 50] that clearly shows all change requestsand allows you to display several levels of detail, right down to the object list itself.

Developments, corrections, and repairs are recorded in tasks [Ext.] and transported usingchange requests [Ext.].

The target system and type of transport are assigned automatically and no longer need to bemaintained by the user.

Several users can work together on a project by organizing their development work in tasks.These tasks belong to a common change request.

You can control access to CTO functions for different user groups by assigning appropriateauthorizations.

Once you have included Repository objects in a change request, you can edit them in thisrequest only. This means that until the change request has been released, they are lockedagainst development work or maintenance by other developers not working on this changerequest. These developers are only allowed to display the objects.

This is how the Workbench Organizer prevents uncoordinated, parallel changes from being madeto objects. Only make changes to the original [Ext.] objects. A warning appears if you try andchange a non-original object.

The Workbench Organizer [Page 39] is activated automatically every time you edit a Repositoryobject. An object has to be in a change request before a user can create or change it. Enteringobjects in requests ensures that all changes made in the ABAP Workbench are registered.

Changes to Customizing data are registered by the Customizing Organizer [Page 41].

A development class [Ext.] and responsible developer are assigned to each Repository object.This development class indicates which area the object belongs to. This enables you to quicklycontact a person in connection with any object. The structure of the entire ABAP Workbench isbased on development classes which can assist you in starting your work.



16 December 1999

The Workbench Organizer provides version management [Ext.] for all Repository objects,enabling you to compare or retrieve previous versions of objects. This lets you document orrestore versions released before or after a particular change request or development project.

All developers working on a change request are required to write structured documentationwhen releasing their tasks. This states the aims of the project, its status, and any special featuresit includes. In addition, all changed objects are automatically recorded in the object list of thechange request. This information, together with the documentation and version management,ensures that you have complete control over all revisions made in a single or multiple computerconfiguration.

Development projects are not worked on in a production system, but in one or moredevelopment systems depending on their size. To ensure that objects remain consistent, eachRepository object has a defined original location. Changes are generally made at the originallocation to prevent unintentional, parallel work on the same object. The original location ofRepository objects can be changed by Relocation Transports [Page 45].

If several development systems are being used, it may be necessary to transport objectsspecifically to SAP Systems that are not supplied with regular change transports. If necessary,you can also change the transport attributes of the object (original system, development class,transport layer). The transport types required for this are managed by the Transport Organizer.To transport Repository and Customizing objects from the development system to other SAPSystems in the system group, transport routes are used, which are defined when the systemgroup is configured in the Transport Management System [Ext.]. The transport involves exportingobjects from the source system in which the objects were changed and importing them into oneor more target systems.

A transport log is created automatically for each change request. If errors occur in theproduction system after an import has taken place from a quality assurance system, the logenables you to immediately find out the following:

• Which objects were transported

• Who requested the transport

• Why the transport was performed

There are tools [Ext.] available in the CTO for searching for, displaying, editing, and analyzingchange requests and transports.


Transport Management System - Concept

December 1999 17

Transport Management System - ConceptYou use the Transport Management System (TMS) to model and manage your systemlandscape. It provides tools for configuring your system landscape, as well as for organizing,carrying out and monitoring transports.

Configuration of a System LandscapeAll SAP Systems that are subject to the administration of the TMS form a transport domain [Ext.].This is usually all SAP Systems in the system landscape [Page 11]. Certain system settings arethe same for all systems within a transport domain, such as the transport routes [Page 21]. Toachieve this, one SAP System in the transport domain has the reference configuration, with allother SAP Systems in the transport domain taking copies of this reference configuration. Thesystem with the reference configuration is known as the Transport Domain Controller [Ext.]; onlyin this system can you make changes to the reference configuration. Each time you change thereference configuration, you must distribute the new configuration to all systems. The TMSautomatically generates RFC connections between the systems in a domain so that they cancommunicate.

When you install an SAP System, a transport directory [Ext.] is set up for it. The CTS uses thisdirectory to store transport data. In most cases, all SAP Systems in a transport domain have acommon transport directory. However, there are situations where this is not possible, forexample:

• A system has a 'slow' connection to the network

• The high security level of some systems does not allow file system access by other systems(NFS or shares)

• Different hardware platforms are used

TMS supports multiple transport directories within a transport domain. The systems that share acommon transport directory form a transport group [Ext.]. Data is exchanged between thesystems using the RFC connections of the TMS.



18 December 1999

Transport domain A Transport domain B

Transport group 1Transport group 1

Transport Domain Controller

Transport directory



Transport domain A: This transport domain has one transport group. This means that all thesystems access a common transport directory.

Transport domain B: This transport domain has several transport groups, each of which sharesa transport directory.

All systems in Europe share a transport directory; this is transport group 2. Allsystems in Asia share a transport directory; this is transport group 3. Together,transport groups 2 and 3 form a transport domain (transport domain B).

When you configure an SAP system landscape, it is usually the case that not all SAP Systemsare available right from the beginning. The TMS allows you to define placeholders, or virtualsystems. These take the place of systems that you want to include in the landscape at a laterdate. In this way, you can model the complete system landscape and make the settings for theCTS as soon as you have configured the TMS in one system. The virtual system is replacedwhen you install the real system.

If you administrate your SAP Systems locally in different locations, for example at head office andin different branches, it may be a good idea to configure several different domains. If you want tomake transports between systems in different domains, you can use external systems in theTMS. The transport data is exchanged using a transport directory that can be accessed by bothdomains, or by using a data volume.

When you configure your system landscape, you first have to configure the transport domain.Only then can you configure the transport routes. For more information, see Configuration of theTMS [Ext.].



December 1999 19

Making TransportsYou can use the Transport Management System to organize, carry out and monitor yourtransports. You no longer need to execute tp commands [Ext.] at the operating system level. Youcan start and monitor all imports from every system in the transport domain. The TMS uses theRFC connections that were created automatically when the transport domain was configured todisplay all information on the requests that are waiting for import.

When you make an import, the TMS starts the transport control program tp [Ext.] in the targetsystem. This program imports the data that was earlier exported from the database of the sourcesystem. If the two systems do not have a common transport directory, the TMS copies thenecessary files into the transport directory of the target system before the import.

If you want to schedule an import for a particular point in time, the TMS schedules a backgroundjob in the target system. This is then executed at the time you chose.

If the import accesses another system in the domain, you need to authorize yourself in thissystem. Even if there is a test system in your domain with free authorization for all users, importsinto the production system can only be made by users with special authorizations.

After you start or schedule an import, you can monitor the process from each system in thedomain. All imports are logged, so that you can see which transport requests were imported intoa system at which time.

For more information, see Performing Transports [Ext.].


Basics of Transport Control

20 December 1999

Basics of Transport ControlThis section suggests ways to organize development projects in a distributed environment, usingthe Change and Transport System (CTS).

The CTS enables you to organize development projects in complex distributed systemlandscapes.

For example, you can do the following:

• Transport and freeze completed development work and automatically distribute it toseveral production, test, training, or development systems.

• Distribute development projects among different SAP Systems on the basis ofdevelopment classes.

• Transfer critical development work to separate systems.

If you do not want to organize your own development projects using different systems, then youdo not need all the functions provided by the CTS. In this case, you can set up a simpledistributed environment consisting of two systems (development and production system) or threeSAP Systems (development, quality assurance, and production system).


Transport Layers and Transport Routes

December 1999 21

Transport Layers and Transport RoutesAll development projects developed in the same SAP System and transported on the sametransport routes are grouped together to form a transport layer [Ext.].

Before you start the first development project, you create a transport layer in the TMS TransportRoute Editor [Ext.]. This transport layer is assigned to the development system as its standardtransport layer [Ext.]. Objects delivered by SAP belong to the transport layer “SAP”. Othertransport layers are generally only needed when new development systems are included in thesystem group.

After you have set up the transport layer you set up the transport routes. There are two types oftransport routes. First you set up consolidation routes [Ext.], and then you set up delivery routes[Ext.]:

1. Consolidation routes

To make your changes transportable, set up a consolidation route for each transportlayer. Specify your development system as the starting point (source) of theseconsolidation routes. Specify the quality assurance system as the transport target (in atwo-system landscape, specify the production system as the transport target).

Any modified objects that have a consolidation route set up for their transport layer areincluded in transportable change requests. After the request has been released theobjects can be imported into the consolidation system.

If you make changes to objects which have no consolidation route defined for theirtransport layer, then the changes are made automatically in local change requests (or inCustomizing requests without a transport target). You cannot transport them into otherSAP Systems.

You can set up one consolidation route only for each SAP System and transport layer.

When you define consolidation routes, note the additional functions available when youuse Extended Transport Control [Page 26].

2. Delivery routes

After you have imported your development work into the quality assurance system, youthen want to transport it into your production system. You may even want to transport itinto several SAP Systems (for example, additional training systems). To do this, youhave to set up delivery routes.

Delivery routes have a source system and a target system.

When you set up a delivery route, you are making sure that all change requests that areimported into the route’s source system are automatically flagged for import into theroute’s target system.

You can set up several delivery routes with the same source system and different targetsystems (parallel forwarding). You can also set up delivery routes in sequence (multilevelforwarding).

CTS transport control makes sure that all requests from the development system are flagged forimport into all other SAP Systems in the same order in which they were exported. This isimportant, since different requests can contain the same Repository object or the same



22 December 1999

Customizing setting at different development levels, and you must avoid overwriting a morerecent version with an older version.

Multilevel DeliveryHere you can activate multiple delivery routes in sequence. You can choose any SAP Systems inthe system group as the source systems of the delivery routes; they do not have to beconsolidation systems. This allows you to implement complex chains of transport routes.

QASDEVZDEV

Consolidation route

for ZDEV

====

DEVQASPRnZDEV

Development systemQuality assurance systemProduction systemStandard transport layer

Delivery routes

Del. route

Del.route

Del.route

PRn

PRn PRn

PRn

Multilevel delivery is not required in a two- or three-system group. In more complex systemlandscapes, particularly in layered development projects that have each other as sources,multilevel delivery may prove to be a suitable solution:

QA1

QA2

QA3

QA4

PR2

PR3

PR4

DV1ZDV1

DV2ZDV2

DV3ZDV3

DV4ZDV4

Consolidation route

ZDV1

====

DVnQASPRnZDEV

Development systemQuality assurance systemProduction systemStandard transport layer

Delivery routes

ZDV2

ZDV3

ZDV4

If there are SAP Systems in the system group [Ext.] with releases prior to 4.0, you can only usemultilevel delivery under particular conditions. The Transport Management System checks theseconditions when you set up the transport routes [Ext.] in a mixed system group.



December 1999 23


Assignment of Development Projects to Transport Layers

24 December 1999

Assignment of Development Projects to TransportLayersAt the start of a development project, Development Classes [Ext.] are created for the Repositoryobjects that are to be created as part of the project. When you create the development class youassign it to a transport layer. The SAP System proposes the preset standard transport layer. AllRepository objects that you later create in this development class belong to the transport layer ofthis development class and are transported according to the routes set up for this layer.

Customizing settings are generally not Repository objects listed in the Object Directory [Ext.] anddo not belong to a development class. This means that you cannot assign them directly to atransport layer.

Customizing settings are always assigned to the standard transport layer of the SAP System inwhich they are performed (if extended transport control is activated). They are then transportedfrom this system (or client) according to the transport routes set up for the standard transportlayer.

Repository objects of the R/3 standard delivered by SAP or from SAP add-on componentsinstalled in your SAP Systems always belong to the pre-installed “SAP” transport layer. Youcannot assign these objects to one of your own transport layers. If you want to patch or modifySAP standard objects in your development system, SAP recommends transporting thesechanges along the same routes as for your own developments. To do this, you need to set up thesame consolidation route for the “SAP” layer as for the standard transport layer of thedevelopment system; this means that the source and destination of the two consolidation routesmust be the same. (For more information, see Changing the SAP Standard [Ext.].) When a two-or three-system group is configured automatically, this consolidation route is created for the“SAP” layer.

The following graphic shows the transport routes of an automatically configured three-systemgroup:

QAS PRDDEVZDEV

Consolidation route

for ZDEV

for SAP

=====

DEVQASPRDZDEVSAP

Development systemQuality assurance systemProduction systemStandard transport layerSAP transport layer

Delivery route


Assignment of Development Projects to Transport Layers

December 1999 25


Extended Transport Control

26 December 1999

Extended Transport ControlUseExtended transport control has the following functions:

• As well as specifying an SAP System as the transport target of a consolidation or deliveryroute, you can also specify a client. This means that you can configure the transport of client-specific objects just as securely as the transport of cross-client objects.

• You can set the standard transport layer that you use to define the transport target ofCustomizing requests, among other things, as client-specific.

• You can set up several parallel consolidation targets in target groups. This is often requiredby ALE.

Extended transport control makes daily transport tasks easier, and it increases security. It alsoreduces the need for communication between project leaders and system administrators, sincethe transport routes can now be configured completely. No additional details about the targetclient need to be given at the time of import.

FeaturesYou can make use of the following extended functions when you configure transport routes inTransport Management.

• Client-specific standard transport layer

When you create Customizing requests, the default transport target of the requests isdetermined 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 theSAP System. This means that you can forward Customizing requests from differentclients into different transport targets.

The client-specific standard transport layer is also the default transport layer for newdevelopment classes that have been created in a client. If you accept this default, thenthe cross-client objects that have been created in cross-client Customizing aretransported along the same route as the corresponding client-specific Customizing.

• Client-specific transport targets

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:<system_name> <client> (for example, QAS.013).

• Target groups

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 nameswith “/” (for example, /EUROPE01/).

When you release a request which has a transport group as a transport target, then therequest is flagged for import into every individual transport target<system_name>.<client> in the group.

• Client-specific consolidation routes



December 1999 27

Consolidation routes determine (for each transport layer) where changes made in theSAP System are transported after the request has been released.

If you have activated extended transport control, then the transport target can be aparticular client in a target system or target group.

If you do not activate extended transport control, you can specify systems only asconsolidation targets. This means that the transport administrator has to specify thecorrect target client at the time of import.

• Client-specific delivery routes

Delivery routes determine whether change requests are to be flagged for import intosubsequent systems/clients, after they have been imported into a system.

If you have activated extended transport control, then you can set the delivery routes asclient-specific. This makes it possible to supply several clients in one system insequence.

You can also specify a target group as the target of a delivery route.

• Improved import controls

If you work with extended transport control, you can import requests into different clientsin a system without using unconditional modes [Ext.].

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-specificcomponents.

This makes it possible to set up consolidation routes and delivery routes betweendifferent clients in the same system.

ExampleThe following graphic shows an example of two production systems, PR1 and PR2, linked byALE. 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. Itis not a recommendation for setting up your own system landscape.



28 December 1999

QA1010

QA2312

DEV100:ZDV1

222:ZDV2

300:ZDV3

PR1210

PR2003

Country 1

Country 2

ProductionTest/QADevelopment

ALE ALE

Client-specificstandard

transport layers

Client-specific

consolidationroutes

Client-specificdelivery-routes

Customizing country 1

Customizing country 2

General Customizing COMMCUST

Target group

Development takes place in three clients in the system DEV.

• Development, client-specific Customizing and general Customizing take place in client 222,and are released with transport target /COMMCUST/. The target group /COMMCUST/ containsfour elementary transport targets:

− QA1, client 010

− QA2, client 312

− System DEV, client 100

− System DEV, client 300

The latter two transport targets are the development clients for country-specific settings.Requests with the transport target /COMMCUST/ are flagged automatically for import intoall four targets.

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 beingsupplied in parallel.

• Country-specific settings are made in the clients 100 and 300 of the system DEV. They arethen released directly to the corresponding country QA systems (the target client isspecified). This is done with a client-specific standard transport layer.

The QA systems automatically deliver to the correct target clients in the productionsystems, since the target client is specified when the delivery routes are defined.



December 1999 29

ActivitiesTransport route configurations are activated according to an 'all or nothing' rule; either theparameter is set in all systems connected by transport routes, and these systems only usetransport routes with specified target clients, or the parameter is deactivated for all systems, andonly target systems are specified.

You can, however, configure two separate system groups, only one of which uses extendedtransport control.

Background:

The buffer format that has been used until now does not include target clients (buffers are theoperating 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, amongother things, space for the target client.

For security, versions of the transport control program tp that do not recognize this new formatare not permitted to process the new buffers. An appropriate entry in the transport profileprevents this in the system.


Transport Strategy in the CTS

30 December 1999

Transport Strategy in the CTSThe Change and Transport System provides a range of functions that help you to maketransports using SAP methods. We recommend that you follow the transport strategy while youplan and set up your system landscape.

The SAP transport strategy comprises the following procedure:

• Use of transport routes

Change requests are transported using predefined consolidation and delivery routes(see: Configuring the Transport Routes [Ext.]).

• Import all change requests in the import queue [Ext.]

Import all change requests that were exported from the development system. In this wayyou can avoid import errors caused by missing objects.

Import all change requests into the target system in the same order in which they wereexported. This makes sure that an 'older' version of an object does not overwrite a newerversion.

• Import all change requests of a project [Page 31]

If you want to organize your developments in different projects, use the IMG projectfunctions. If you do this, it is important that you keep your development projects distinctfrom each other. You can then import your requests in projects.

• Individual imports in special cases

Only import individual change requests before others in the queue in special cases.

Change requests that are imported in advance by the TMS are imported again in theregular import.

• Deletion of requests from the import queue in exceptional cases

Avoid deleting change requests from the import queue, particularly from the importqueue of the production system. Otherwise, the consistency of the systems cannot beguaranteed, resulting in serious problems for development, test and support.

If a change requests contains objects with errors, then you must correct these errors inthe development system. You need to import the change request with the correctedobject together with the faulty requests. The correct import sequence makes sure thatthe corrected version is used.

You can define client-specific transport routes by using Extended Transport Control [Page 26].

Certain circumstances may mean that it is a good idea to work with the Transport Strategy forIndividual Transports [Page 35].


Using Projects to Control Transports

December 1999 31

Using Projects to Control TransportsIf you work with the IMG Project Administration [Ext.] then you can use transport control to planyour development work and Customizing activities in structured projects. You can structurechanges independently of each other in different projects, and then import them independentlyinto target systems. We recommend this if, for example, you want to start using different projectsproductively at different times, or if you want to link development work in a single area.

If you go to the corresponding IMG nodes of an IMG project you can only make changes inrequests that are assigned to the project. The project to which a change request belongs isdisplayed in the import queue. This means that you can make imports [Ext.] into target systemsproject-by-project.

It is important that you make sure that projects are free from dependencies while you plan them.

However, the Change and Transport System does support small overlaps between projects. Ifyour projects do overlap, then you must define dependency relationships [Ext.] between theobjects that belong to different projects but contain some of the same objects. Theserelationships need to be defined to ensure that imports are made in the correct order.

In certain situations, project administrators need to restrict what work can be done in a project.They can control this with the project status switch [Ext.].

For more information, see Transport Strategy in the CTS [Page 30] and Working with Projects[Ext.].


TMS Quality Assurance

32 December 1999

TMS Quality AssuranceUseThe TMS Quality Assurance increases the quality and the availability of the production systemsby letting you check requests in the QA system before they are delivered to subsequent systems.

The system for which the QA approval procedure is activated is called the QA system. When theQA approval procedure is activated, transport requests are only forwarded to the deliverysystems if all the QA approval steps are processed for each request in the QA system and eachrequest has been approved. (When you configure the QA system, you determine how many QAapproval steps have to be processed for each request.) If a check for an approval step is notsuccessful, the entire request cannot be approved.

Rejected requests are not imported into the delivery systems of the QA system.

If you reject requests, there is the risk that errors may occur when they are importedinto the delivery systems. This is a result of the requests containing objects that arereferenced from other requests. It is safer to correct an error using a subsequenttransport (see Transport Strategy in the CTS [Page 30]).

IntegrationIn the TMS transport route configuration, you determine which system is the QA system, andwhich approval steps should apply to this system. When you perform these 2 steps, youconfigure the QA approval procedure. All the requests that are then imported into the QA systemare included in the QA worklist.

You can go from the TMS Import Overview to the QA Worklist where you have to check therequests for each approval step.

You can only import all requests into the delivery systems if all the requests ready for import havebeen checked (which means approved or rejected).

If all the requests for a project and target clients are checked, you can import them even ifrequests for other projects and target clients have not been checked yet.

PrerequisitesYour system landscape contains at least one QA system from which there are configureddelivery routes into other systems.

In a 3-system landscape, the requests from the development system are importedinto the QA system. There, the requests are checked and the approved requests areforwarded to the production system.

Functions• Configuring the QA approval procedure (determining the QA system and the approval steps)


TMS Quality Assurance

December 1999 33

You determine which system is the QA system, switch on the option Forward afterconfirmation for this system, and define which approval steps are valid for this system.

• Processing the QA worklist

After a system has been configured as the QA system, the QA worklist is built. You thenhave to check the requests in these views for the individual approval steps.

• Displaying the QA history

Using this history you can display the QA activities for a specific period.

Activities1. When you configure the QA approval procedure [Ext.], you determine the QA system, switch

on the option Forward after confirmation, and define the approval steps for that system.

2. You approve or reject requests [Ext.].

3. You display the QA history [Ext.] for a selected period.


Special Transport Workflow

34 December 1999

Special Transport WorkflowPurposeYou can use the special transport workflow to make transports that do not follow the defined transport routesor that take place outside the normal transport schedule. These transports may be corrections made in thedevelopment system that have to be transported into the production system without delay.

Prerequisites• You have configured the special transport workflow [Ext.] for your system.

• The users involved in the special transport workflow have a user in the Workflow Enginesystem/client.

• One or more users have transport administration authorization [Page 56].

ProcedureThe special transport workflow is a direct connection between development and transportadministration. The workflow determines the user for each individual step automatically, and thendisplays an interface which they can use to perform the task directly.

The developer creates a transport proposal [Ext.] in the Change and Transport Organizer. Thisproposal contains the required transport requests. The transport proposal then appears in theTMS worklist [Ext.] of the transport administrator. The administrator can then approve or rejectthe transport proposal [Ext.]. The transport administrator can also make changes to the transportproposal, for example change its contents and the transport target. After a transport proposal hasbeen approved, the TMS imports the transport requests automatically into the specified targetsystems. If the proposal is rejected, it is sent back to the transport proposal inbox [Ext.] forrevision by the responsible developer.

The special transport workflow writes an action log for each transport proposal. This log containsall development and transport activities, allowing you to check on the entire process.

Developers and transport administrators can communicate directly by writing notes.

For more information on transport administration, see Special Transport Workflow(Administration) [Ext.].

For more information on the development team, see Special Transport Workflow (Development)[Ext.].


Transport Strategy for Individual Transports

December 1999 35

Transport Strategy for Individual TransportsPurposeYou may want to use individual transports for the following reasons:

• You only make transports infrequently.

• You organization does not include fixed import times.

• You want to maintain production systems directly with corrections.

A strategy of individual transports has the following risks:

• Increased administration

If you import individual requests from the import queue into the target system, youmust yourself make sure that the objects in the requests are complete andconsistent. Unlike the import of individual projects [Ext.], the system does not provideautomatic support for dealing with relationships between requests.

• Relationships between transport requests can create inconsistencies in the target system:

− Import sequence

It is important that you import requests in the correct order, so that development workis up-to-date in the target system.

− Incompleteness

A request is not imported, but it contains an important data element. You use anotherrequest to transport a table that references this data element. Since the referenceddata element does not exist in the target system, activation errors will occur whenyou import the second request.

ProcedureThe individual transport strategy is defined as follows:

• Use of transport routes

Change requests are transported using predefined consolidation and delivery routes(see: Configuring Transport Routes [Ext.]).

• Import individual change requests from the import queue [Ext.]:

Select the change requests that you want to transport and then import them into thetarget system. The requests are imported in the order in which they are placed in theimport queue.

• Import all change requests of a project [Page 31]:

If you want to organize your developments in different projects, use the IMG projectfunctions. If you do this, it is important that you keep your development projects distinctfrom each other. You can then import your requests in projects.


Transport Strategy for Individual Transports

36 December 1999

For more information, see Specifying a Transport Strategy for Individual Transports [Ext.].


Transactions and Tools in the CTS

December 1999 37

Transactions and Tools in the CTSThe Change and Transport System (CTS) provides you with tools for recording the changes youmake to Repository objects and Customizing objects, and for distributing these changes withinthe system landscape. The CTS offers the team members of a software development orimplementation project transactions in the SAP System and programs at the operating systemlevel.

Change and Transport System (CTS)

Change and Transport Organizer (CTO)

WorkbenchOrganizer

(SE09)

CustomizingOrganizer

(SE10)

TransportOrganizer

(SE01)

TransportManagementSystem (TMS)

Transport Tools ( tp, R3trans)

The Change and Transport Organizer [Page 38] provides functions for creating, documentingand releasing change requests during the Customizing and development process. The CTO toolsare designed specifically for use by the development team and the project managers of adevelopment or implementation project.

The Transport Management System [Page 55] (TMS) supports administrators in organizing,performing and monitoring imports. The TMS also helps you to set up your system landscape,particularly the configuration of the transport routes.

The transport tools [Ext.] tp and r3trans are programs at the operating system level. They do notusually have to be executed by the user directly since they are called automatically by the CTOor TMS. The transport tools communicate with the SAP System and the database, and exportand import requests.


Change and Transport Organizer

38 December 1999

Change and Transport OrganizerThe Change and Transport Organizer [Ext.] (CTO) provides functions for creating, documentingand releasing change requests during the Customizing and development process. The CTO toolsare designed specifically for use by the development teams and the project managers of adevelopment or implementation project.

The Change and Transport Organizer consists of the following:

• Workbench Organizer [Page 39]

• Customizing Organizer [Page 41]

• Transport Organizer [Page 44]


Workbench Organizer

December 1999 39

Workbench OrganizerYou can access the initial screen of the Workbench Organizer by calling transaction SE09. Youcan also access the request overview of the Workbench Organizer from all ABAP Workbenchtransactions by choosing Environment →→→→ Workbench Organizer.

The Display function lets you search for all requests that belong to the specified user and matchthe standard selection criteria set. You can change the standard selection as required.

The status selection for requests is used by default for the task selection. However, you canchange this by going to the initial screen and choosing Request/task → Task selection.

Tasks that are not assigned to a request can no longer be created. This means thatthese tasks are no longer displayed as standard. If you own tasks of this type, usethe request search to display them.

The options have the following meanings:

Status

Modifiable Change requests that can be edited

Released Change requests where work has already been completed

Attribute

Transportable Change requests that can be transported

Local Change requests with local character (no transport)

The right side of the initial screen shows you cross-system information on the status of transportsand repairs [Ext.], and also lets you display the Transport Proposal Inbox [Ext.] of the SpecialTransport Workflow [Page 34].

You can find various tools for searching for, analyzing, and managing change requests bychoosing Goto → Tools [Page 54].

To go to the Customizing Organizer [Page 41], choose Environment → Customizing Organizer.

To go to the Transport Organizer [Page 44], choose Environment → Transport Organizer.


Change Requests

40 December 1999

Change RequestsChange requests are managed with the Workbench Organizer. Changes to Repository objectsare recorded in change requests.

Global SettingsGlobal Settings

Customizing Request Change Request Change Request

Customizingobjects Factory Calendar Material Group

Customer AccountAccount Payable

House Bank

Request

User

Task Task Task Task

LogisticsLogistics Financial AccountingFinancial Accounting

When you change a Repository object of the ABAP Workbench, a query window appears inwhich you need to specify a change request. You can only save the changes if you haveassigned the object to a change request.

Change requests and the tasks assigned to it are normally used to record changes to Repositoryobjects and Customizing for all clients. However, you can also include client-specificCustomizing.

Whether the system records changes to Repository objects in transportable or local changerequests depends on whether a transport route is defined from the current system for thedevelopment class of these objects. From the system settings, the system automaticallydetermines whether the change requests are transportable and to which target system theyshould be transported.

See also:Configuring Transport Routes [Ext.]

Request Types and Task Types [Ext.]


Customizing Organizer

December 1999 41

Customizing OrganizerYou can access the initial screen of the Customizing Organizer by calling Transaction SE10.You can access the Customizing Organizer from the Workbench Organizer or the TransportOrganizer by choosing Environment → Customizing Organizer.

The Display function allows you to search for all requests that belong to the specified user andmatch the standard selection criteria set.

Since Repository objects are also edited as part of Customizing and are recorded inchange requests, the Customizing Organizer can also display change requests, asan option.

If necessary, you can change the selection criteria.

For more complex selections, use the Find function.


Customizing Requests

42 December 1999

Customizing RequestsCustomizing requests are managed by the Customizing Organizer. Changes to Customizingsettings are recorded in the Customizing requests.

Global SettingsGlobal Settings

Customizing Request Change Request Change Request

Customizingobjects Factory Calendar Material Group

Customer AccountAccount Payable

House Bank

Request

User

Task Task Task Task

LogisticsLogistics Financial AccountingFinancial Accounting

Automatic recording of configuration activities in the Customizing work for a client can beactivated or deactivated for each client with Client Control [Ext.]. If automatic recording is active,a query window appears when you change Customizing settings, asking you to specify aCustomizing request.

To distinguish between global changes in the system and client-specific Customizing settings,modified objects are divided into different categories. Change requests and tasks are alsoassigned to these categories, depending on the objects they contain. There are two requestcategories:

• Customizing requests

Customizing requests record client-specific Customizing settings made in a single client(the source client of the request).

• Change requests

Change requests contain Repository objects and cross-client Customizing objects.Change requests can also be mixed. This means that they may contain client-specificCustomizing. However, as above, all the client-specific objects must only originate fromone client (the source client of the request).

Whether Customizing requests are transported or not, does not depend on the objects entered,as is the case with Workbench change requests. The Customizing requests in an SAP System(or in a client if you use Extended Transport Control) are either all transportable or all local,depending on the system setting. The system automatically determines whether objects can betransported and the transport system into which they are transported, however you can changethis manually. For more information, see Configuring Transport Routes [Ext.].


Customizing Requests

December 1999 43


Transport Organizer

44 December 1999

Transport OrganizerYou call the initial screen of the Transport Organizer with transaction SE01. You can access theTransport Organizer from the Workbench Organizer or the Customizing Organizer by choosingEnvironment → Transport Organizer.

Provided you have configured the system correctly, transportable change requests andCustomizing requests automatically ensure that the subsequent systems are suppliedconsistently with your development work.

Extra transport types are provided in the Transport Organizer to meet any special requirements:

• Transports of copies and relocations

• Piece lists

• Client transports

• Delivery transports (SAP/Partner → Customer)

• Individual display

Unlike the Workbench and Customizing requests, there are no automatically assigned transportroutes for the transport types described here. Similarly, these requests do not follow configureddeliveries.

Since some of these request types have their own naming conventions and you cannot search byowner for all request types, the Transport Organizer was designed with five different selectionscreens.

To display an individual selection screen, choose the appropriate tab page.

Depending on your area of work, you may prefer to use a particular selection screenof the Transport Organizer.

To access this selection screen directly when calling the Transport Organizer, youcan define this selection screen as your default initial screen. To do this, go to therequired screen and choose Settings → Define initial screen.

This setting applies until you overwrite it by defining another selection screen or theoverview screen as the initial screen.

You can find various tools for searching for, analyzing, and managing change requests bychoosing Goto → Tools [Page 54].


Transports of Copies and Relocations

December 1999 45

Transports of Copies and RelocationsThis selection screen covers the following request types:

• Transports of copies

You can use this request type to transport objects to a specified SAP System.

The objects are transported with the version they have in the current SAP System. Theoriginal location of the objects remains unchanged. There is no delivery to another SAPSystem.

• Relocations without development class change

You can use this request type if you want to develop objects in another SAP System ona temporary basis. For example, you may want to make special developments in aseparate SAP System so as not to interfere with the development process.

A relocation without development class change basically offers the same functions as atransport of copies. This request type allows you to move the original location of objectsto the target system.

• Relocations with development class change

You can use this request type when you want to change the development system ofindividual objects on a permanent basis.

This request type allows you to change the original location of objects to the targetsystem and change the development class of the objects at the same time.

The development class is changed automatically. If you choose a suitable developmentclass the objects have the right transport attributes immediately after you import theminto the target system of the request. Here you can edit them in transportable changerequests without needing to make any further settings.

• Relocations of complete development classes (with change of transport layer)

You can use this request type when you want to change the development system of acomplete development class on a permanent basis.

This request type allows you to automatically change the transport layer of thedevelopment class.

To do this, you only need to specify the development class and transport layer to whichyou want to assign the development class. The object list of the request is set upautomatically and contains all objects in the development class.

The transport layer is changed automatically. If you choose a suitable transport layer theobjects have the right transport attributes immediately after you import them into thetarget system of the request. Here you can edit them in transportable change requestswithout needing to make any further settings.

You have to set up the object list yourself for the first three request types. Forinformation on this, see Including Objects in a Request [Ext.].

You can only enter complete objects in the object list of relocations. If there are sub-objects (for example, from other requests), you can let the system convert them to


Transports of Copies and Relocations

46 December 1999

the corresponding parent objects. To do this, go to the Transport Organizer requestoverview and choose Request → Object list → Sub-objects → Complete objects.


Piece Lists

December 1999 47

Piece ListsYou can use this request type to set up your own object lists and save them under a name ofyour choice.

The first three characters must not be “SAP”, the fourth character must not be “K”.

You can use these piece lists as a template for the function Request/task → Object list → Includeobjects. The Include Objects in Request <Request Number> [Ext.] dialog box appears.

Piece lists have the following attributes:

• You cannot release them; this also means that you cannot transport them.

• They have an object directory entry and are therefore assigned to a development class.

They have the same transport attributes as all objects in this development class.

• If you have assigned the piece list to a transportable development class, then when youmake changes to the piece list the entry LIMU COMM <piece list name> is made in yourcurrent change request.

• After the change request has been imported, the piece list is also in the target system ofthe request; however, the objects entered in the piece list are not automatically includedin the transport.


Client Transports

48 December 1999

Client TransportsIn Release 4.0, the cross-system client transport was changed to this new transport type. Thisallows special security precautions to be implemented for such transports. For example, clienttransports are not included in a normal tp import all or tp put.

See also:Client Copy and Transports [Ext.]


Delivery Transports

December 1999 49

Delivery TransportsUse the Delivery selection screen to display transports that deliver software changes from SAPor SAP partners to customers.

This selection screen covers the following request types:

• Piece list for upgrade

This transport type imports new releases into your SAP System when you upgrade.

• Piece list for Support Packages

This transport type imports corrections into your SAP System.


Request Overview

50 December 1999

Request OverviewYou can access the request overview of the Workbench or Customizing Organizer directly fromall ABAP Workbench transactions and Customizing transactions with Utilities → Changerequests (Organizer).

You can access the request overview of the Transport Organizer from the initial screens ofTransaction SE01 by choosing Display.

The requests are grouped and displayed under a hierarchy of sort nodes, corresponding to thefollowing request attributes:

• Source system

• Source client

• Transport target

• Request owner

• Request type

• Request status

• Project

In the Workbench Organizer, only the levels project, request type and request status are normallyactive.

If the hierarchy selected by the SAP System does not suit your purposes, you can change thesetting as follows:

• Temporary setting

By choosing Edit → Sort sequence, you can add or remove sort levels, or change theirhierarchy.

• Permanent setting

By choosing Utilities → Settings, you can choose the following permanent settings:

− Display short texts of tasks

− Display change date of requests

− Sort by request owner

The objects contained in the requests and tasks are displayed below them, sorted by object type.Double-click an object to access the editor for displaying or editing the object.


Request Overview

December 1999 51

Screen

Report source

ZZABCDEFZZGHIJKLZZMNOPQRZZSTUVWX

Local Not transportable

Function module

Transportable Target System: BCO

Z11K000815 King Invoice

Z11K004711 King Warehouse

Z11K004712 Mayer

Z11K004713 King

Change requests involving user Lisa King


Functions in the Request Overview

52 December 1999

Functions in the Request OverviewThe hierarchical list presents you with a selection of functions that you can apply to therespective elements in the list. To do this, you first have to position the cursor on the relevantelement.

Then choose Request/task → ...

Other requests Selection of requests of another user; the selection criteriaspecified in the initial screen are used.

Display/change Display or change the header data of a request or task

Create Create a new request [Ext.]

Change owner Change the owner of a request or task

Release Release a request or task

Delete Delete a request or task

Change type Assign the task attributes:

• Development/correction

• Repairs

• Unclassified

Overall check

Objects (syntax check) Standard object checks [Ext.] are performed on all objectscontained in the request.

Check request consistency Each object list entry must be syntactically correct. The transportattributes of the objects must correspond to the requestattributes.

Reorganize

Reassign task Reassign a task to another request

Merge requests Move all objects and tasks to another request. The old (empty)request is then deleted.

Requests

Add user Add a user to a request A new task is created for this user.

Protect [Ext.] Only the owner of the change request can add users to aprotected change request.

Remove protection Remove protection for a change request

Request attributes [Ext.] Edit the attributes of a change request

Standard requests


Functions in the Request Overview

December 1999 53

Set Flag a change request as the standard request. When you haveflagged a request as the standard request, it is selectedautomatically when you edit objects. The request selection dialogdoes not take place.

Reset Remove flag that makes a change request the standard request

Validity period Place a limit on how long a request can be flagged as thestandard request. The flag is reset automatically when the validityperiod is over.

Object lists

Display/change object list Branch to the object list editor

Lock objects [Ext.] Lock objects entered manually in the object list

Sort and compress Delete redundant entries that resulted from creating object listsmanually

Object directory entries Display/change the object directory entries of all objects enteredin the request

Include objects [Ext.] Include objects in a request. You can choose from the followingfunctions:

• Include object list from another request

• Include object lists from multiple requests; make a selectionof requests.

• Free object selection; make a selection of objects.

You can find out what the colors used in the request overview mean under Utilities → Legend.


Organizer Tools

54 December 1999

Organizer ToolsIn the initial screen of the Workbench Organizer, choose Goto → Tools to display a collection oftools that support your work with the Change and Transport System.

If you are working with administrator authorization in the Change and Transport System(authorization S_CTS_ADMIN), you are allowed to use a wider range of tools.

As an administrator, you can make critical changes to system parameters.

Check the consequences of your changes beforehand.

For a detailed description of the function, click the appropriate tool.

To execute a tool, position the cursor on the tool and choose Execute.

For more information on the individual functions, see Organizer Tools [Ext.].


Transport Management System (TMS)

December 1999 55

Transport Management System (TMS)The Change and Transport Organizer [Page 39] supports the software development team in itswork until the release of a change request. Thereafter, the Transport Management Systemsupports the administration in importing the request into the target systems.

Use the Transport Management System (TMS) to organize, carry out and monitor transportsbetween SAP Systems.

No user actions at the operating system level are required, since all the required information andfunctions are provided in the SAP System.

The Transport Management System offers the following functions:

• Configuration of the transport routes with a graphical editor [Ext.]

• Display of the import queue [Ext.] for all SAP Systems in the transport domain

• Import of all requests in the import queue [Ext.]

• Import of all requests in a project [Ext.]

• Import of individual requests [Ext.]

• TMS Quality Assurance [Page 32]

• Special Transport Workflow [Page 34]

• Transports between SAP Systems without a common transport directory [Ext.]

To start the TMS, call the transaction STMS.


Authorizations in the CTS

56 December 1999


This section is intended for customers with longer experience of the SAP System. Ifyou have just installed the system, use the Profile Generator [Ext.] to maintainauthorizations.

All functions in the CTS are safeguarded by detailed authorization checks.

With the help of authorizations, you can specify whether a user may perform administrationfunctions and which request types this user can edit.

The profiles delivered by SAP include model authorizations which, from the CTS point of view,allow you to divide users into different groups.

In most cases, these preset profiles will be adequate for your work. If not, you can meet furtherrequirements by setting up your own authorizations based on the existing standardauthorizations.

If you want to set up your own authorizations, bear in mind that in addition to theCTS authorizations, users also require the following authorizations to work with theWorkbench Organizer:

• S_DATASET_AL (for accessing files)

• S_C_FUNCT_AL (for calling external programs)

• S_TCD_ALL (for calling transactions)

Since Release 4.0, the administration functions in the CTO have been safeguarded by a newauthorization object called S_CTS_ADMI. The authorization object S_TRANSPRT introduced in3.0 is now used exclusively to safeguard functions that directly change requests and tasks.

The authorizations are checked independently of the user name. User DDICtherefore does not automatically have administration rights. A user who wants toschedule the transport program (RDDIMPDP) needs administration authorization sothat the program can run without errors.

The role of Transport Manager (activity group SAP_BC_CTS_TRANSPORTMANAGER_AG)has all the authorizations required for administration and other operations in CTS. You canassign users to this role in the activity group maintenance transaction (PFCG).

The authorization object S_TRANSPRT consists of the fields Activity and Request type. Thefollowing values are used:

Activity Description

01 Add or generate

02 Change

03 Display



December 1999 57

05 Lock

06 Delete

23 Change/edit object list manually

43 Release

50 Change source client

60 Transport

65 Merge request

75 Release other user's requests

78 Include in transport proposal

90 Change owner

Request types Description

CLCP Client transports

CUST Customizing requests

DLOC Local change requests

DTRA Transportable change requests

MOVE Relocation transports

PATC Support Packages

PIEC Piece list

TASK Task (repair or correction)

TRAN Transports of copies

The authorization object S_CTS_ADMI, with safeguards administration functions, only has thefield CTS_ADMFCT, whose values describe the various administration activities. Use thefollowing values to assign the user authorization for particular administration functions.

Administration function Description

TABL Maintain the control tables of the Change and Transport Organizer(for example, configure the transport routes)

• Schedule the transport dispatcher RDDIMPDP

• Call certain administration tools (Transaction SE03)

• Extended maintenance authorization when changing the objectdirectory entries with the tool Change object directory entriesof objects (Transaction SE03).

INIT Initialize the Workbench Organizer, for example, after a systemcopy

SYSC Set the system change option



58 December 1999

PROJ Manage projects in the Change and Transport System

INBX Edit the TMS worklist

QTEA Approve transports into the production system

IMPA Import all requests in an import queue

IMPS Import individual requests into the target system

TADM Special transport functions in TMS

TDEL Delete transport requests from the import queue

TADD Forward transport requests to an import queue

TQAS Activate or delete inactive transport requests

IMPT Import requests into the target system using the TransportManagement System (obsolete)

EPS1 Generate EPS objects

EPS2 Change EPS objects


Authorizations in the CTO

December 1999 59

Authorizations in the CTODelivered Activity Groups

If you have just installed the system, use the Profile Generator [Ext.] to maintainauthorizations.

Delivered Profiles and AuthorizationsYou can use the basis profiles delivered by SAP to assign your users general basisauthorizations depending on their areas of responsibility.

The basis profiles are assigned these authorizations as follows:

Profile User type (global view) Functions in the WBO

S_A.SYSTEM System administrator (superuser) System administrator

S_A.ADMIN Operator Display only

S_A.CUSTOMIZ Customizer Project manager

S_A.DEVELOP Developer Developer

S_A.USER User Display only

S_A.SHOW Basis: Display only Display only

• System administrator: Authorizations S_CTS_TR_ALL, S_CTS_ADMIN

The authorization S_CTS_ADMIN allows you to use functions that have wide-reaching effects (such as Set system change option function). Therefore, only assignthis authorization to selected employees.

This user has all authorizations within the Change and Transport Organizer, for editingrequests (S_CTS_TR_ALL) as well as for the administration functions (S_CTS_ADMIN).

The administration functions include:

− Use of the Organizer tools, which cannot be accessed by a user withoutadministrator authorization.

− Extended maintenance authorization when changing the object directory entries withthe tool Change object directory entries of objects (Transaction SE03).

− All TMS functions such as maintaining the system landscape and the transport routeconfiguration.

• Project manager: Authorizations S_CTS_PROJEC, S_CTS_PIECLS, S_CTS_EPS andS_CTS_PRPS.


Authorizations in the CTO

60 December 1999

Project managers can perform all actions in the Change and Transport Organizerrequired for development projects.

Except for client transports, they can create, edit, lock, and release all types of requests.

The authorization S_CTS_PRPS is needed so that the project manager can use CTSproject functions [Page 31] when working with IMG Projects.

• Developer: Authorizations S_CTS_DEVELO, S_CTS_PIECLS

Developers can only work on developments at task level. They cannot create changerequests or tasks and cannot change the owner of a request or task.

When a developer has completed his or her development work, he or she can releasethe task to the higher-level change request. However, the developer may not release thechange request itself.

• Display authorization: S_CTS_SHOW

A user with this authorization can only obtain information on change requests and tasksand display corresponding logs.

The authorization concept described above lets you set up groups of users in thefollowing way:

A project manager defines a development project. He or she creates a changerequest for the development work in the Workbench Organizer. The project managercan then assign developers to this request, who will work on tasks within the changerequest.

Developers who do not have a task in a change request cannot create or changeABAP Workbench objects.

Project managers can transfer other requests and tasks to themselves with theChange owner function. They can also integrate their own change requests in one oftheir other change requests to combine various development projects (Mergerequest function).

When developers have completed their tasks, they release them to the changerequest. After all the tasks have been released, the project manager releases andexports the change request.


Authorizations in TMS

December 1999 61

Authorizations in TMSCommunication between SAP Systems is implemented using RFC connections, which aregenerated when the Transport Management System (TMS) is configured. Within a transportdomain, all the SAP Systems can communicate with each other using RFC.

The following principles apply in the TMS:

• When using TMS, SAP Systems cannot be accessed within the transport domain from anSAP System outside the transport domain.

• For each target system, two RFC connections are used (one for read access and one forchange access).

• The authorization check always occurs in the target system.

• You can only change the TMS configuration from the transport domain controller [Ext.].

To prevent unpermitted access to an SAP System, the two generated RFC connections and/ortheir users are used:

• A connection for read access (TMSADM@<SID>.<transport domain name>)

This connection is used for all system accesses that do not affect sensitive data. Theuser TMSADM is created in client 000 in each SAP System. This user has the followingauthorizations only:

− Read and write authorization for the common transport directory

− RFC authorization in TMS

− Display authorization in CTS

User TMSADM enables you to distribute the basis configuration to all SAP Systems inthe domain on the domain controller and to display the import queue.

• A connection for accesses that cause changes in the target system

If the authorization for user TMSADM are not sufficient for certain actions, this internalconnection always triggers a logon screen in the target system where you must identifyyourself with a user name and a password. (You can also change the target client in thislogon screen.) This user must be authorized to make changes. This means the usermust have greater authorization than that of the automatically created user TMSADM. Todo this, give the appropriate authorizations [Page 64].

This ensures that the user must log on in the target system with a user name andpassword as soon as a function is executed that causes a change in the target system(viewable on the Alert Viewer [Ext.]).

Because changes to the import queue and to imports are considered to be critical tosecurity, an explicit logon is needed to perform these changes.

If you have a large number of SAP Systems to manage, this logon procedure can betime-consuming. To combat this, you can activate TMS Trusted Services [Page 63] orprovide the user TMSADM generated in the SAP System with multiple authorizations[Page 64]. Change the user TMSADM in the SAP System in which you want to suppressthe logon procedure. This is generally not the transport domain controller. This enablesmultiple accesses via the connection and an explicit logon in the target system is notrequired for each access.


Authorizations in TMS

62 December 1999

If authorizations are extended, it is easier for an anonymous user to make changesto the system.

You can also reset user TMSADM to the default again [Ext.].

The special transport workflow [Page 34] uses two generated RFC connections and users, in thesame way as the RFC connections above.

• Connection for read access (TMSWF@WORKFLOW_ENGINE)

This connection is used for all read accesses that do not affect sensitive data. The userTMSADM_WF is created in the Workflow Engine system/client. This user has thefollowing authorizations:

− Read and write authorization for the common transport directory

− RFC authorization in TMS

− Display authorization in CTS

− Count the work items in the inbox

The user TMSADM_WF can create transport proposals in the Workflow Engine, andread transport proposals from the database.

• A connection for accesses that cause changes in the target system

If the authorizations of the user TMSADM_WF are not sufficient, the same applies as forthe user TMSADM.

Since you can change transport proposals in the transport proposal inbox or TMSWorklist [Ext.] only, you must log on to them explicitly.

For security reasons, we do not recommend extending the authorizations of the userTMSADM_WF.

You can also reset user TMSADM_WF to the default again [Ext.].


TMS Trusted Services

December 1999 63

TMS Trusted ServicesTo achieve the correct balance between the twin goals of data protection and usability, youcan choose between different levels of protection and usability in the Transport ManagementSystem (TMS).

The standard RFC connection settings in TMS guarantee maximum protection when reading andchanging data. If user TMSADM [Ext.], who only has authorization for read access and non-critical changes, remains unmodified, then the user cannot use TMS to obtain uncontrolledaccess from one system to another. This means that you can manage systems with differinglevels of protection in a transport domain without the 'non-secure' systems endangering the'secure' systems. The downside is that you must log on with user name and password each timeyou use TMS to access and make changes to the target system.

TMS Trusted Services suppress the logon procedures in the target systems, after you havesuccessfully logged on to a client in one of the systems in the transport domain. All otherauthorization checks in the TMS are then made on the user name that you used to start the TMSin the source system. This means that the identity of the user is not checked every time you useTMS to access a system, only when the user first logs on to a client in the transport domain. Theonly check made in the target system is to see whether the user has the correct authorization forthe particular action (such as importing a transport request). TMS Trusted Services must only beused if the user names are the same in all clients in all SAP Systems in the transport domain.

This also applies to the test systems in the transport domain. Users who haveadministration authorization in the test system could obtain unauthorized access toother systems in the transport domain under certain circumstances.

For more information, see Activating TMS Trusted Services [Ext.].


Setting Authorizations for TMS

64 December 1999

Setting Authorizations for TMSUseAs an alternative to the TMS Trusted Services [Page 63], you can give the user TMSADMauthorizations in one or several systems. This is useful, for example, if you want to allow all themembers of the development team to import requests into the quality assurance system, withouthaving to give each person a user password in the QA system.

ProcedureIf you want to extend the default authorizations for user TMSADM or give another userauthorizations for TMS, proceed as follows:

1. Use the authorization object S_CTS_ADM to create the appropriate authorizations.

2. Assign the authorizations to authorization profiles.

3. Give the user the required authorization profiles.

For more information on authorizations, see Users and Authorizations [Ext.] and Authorization inthe CTO [Page 59].

change and transport system overview

Documents

workflow engine

query window

operating

quality assurance

special transport

object directory

common transport

quality assurance