Change Management in the SAP System Landscape
Posted:
Change Management in the SAP System Landscape
Before you can use the SAP software to control the business processes in your company, you must first adapt it to your own business needs. This is usually done in an SAP implementation project. Adapting and configuring is usually an ongoing process. Even after you start using the system productively, you still need to make changes to the SAP configuration. This may be due to business or organizational changes in your company, or due to the implementation of new SAP 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 the type and extent of your business requirements. Any modifications that you make with these tools are stored in certain tables in the SAP database.
Customizing Tools
The most important configuration tool is the Implementation Guide ( IMG). You can use the IMG to make all configurations possible in the SAP standard. Any modifications you make to the SAP software in the IMG are known as Customizing settings, or Customizing for short. This includes 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 a hierarchical overview. This overview shows the recommended process flow and assignment to the different applications of the SAP System. The IMG lets you filter out the relevant IMG activities for a particular section of the SAP applications. You can also group IMG activities logically into IMG Projects. These projects are then worked on as an implementation project by a particular team. You can document the requirements of a project and its progress in the IMG Project.
The changes that you make in the IMG are placed in the Customizing tables of the SAP database. The contents of these tables are known as Customizing data. When you use the SAP applications productively, the SAP runtime system analyzes this Customizing data and uses it to control your business processes.
Most Customizing data is client-specific. This means that you can choose different Customizing settings for each client in your SAP System that do not affect each other. Changes to the Customizing settings in one client have no effect on system actions in another client.
However, there is also a significant amount of cross-client Customizing data that is relevant for all clients (such as the factory calendar). Note that if you change these types of Customizing settings, it affects all clients in the SAP System.
ABAP Workbench
If the configuration options in the SAP standard are not enough to meet your requirements, you can also add to the SAP standard functions. SAP provides the ABAP Workbench as a complete programming environment. The ABAP Workbench includes tools for defining data structures (ABAP Dictionary), developing ABAP programs (ABAP Editor) and designing interfaces (Screen Painter and Menu Painter), as well as many other functions.
For example, you can use the ABAP Workbench to develop your own report programs or transactions, or to modify or make your own enhancements to existing SAP programs. These enhancements are known as customer exits. However, this does require experience of the ABAP Workbench and the SAP application where you want to develop.
The changes that you make in the ABAP Workbench are placed in the Repository tables of the SAP 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-client Customizing, 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 you make in the IMG or ABAP Workbench. The CTS records all changes in change requests. The changes in change requests can be linked together logically, or can be completely independent of each other. Developers in a team can use a common request. You can create documentation for a change request, where you can describe your changes in more detail. This makes it easier to 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 certain stage, you can release the request. The change request is then used to copy the changes from this 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 your development 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 program errors.
Transports of changes between clients and systems are subject to rules that are set in the CTS configuration in the system landscape. One rule may be that changes are transported into a test environment 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 whether there were any errors.
Application Data
In contrast to Customizing and Repository data, application data is not part of the configuration of the SAP software. Application data is the business data that the SAP applications process when you use them productively. It is split up into master data (such as material masters, customer masters 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 to transport application data into other clients or systems.
If you want to copy master data and movement data between clients in an SAP System, or from a non-SAP system into an SAP System, or if you want to set up this data automatically, you can use other tools, such as ALE ( Application Link Enabling), CATT ( Computer Aided Test Tool), or use the application interfaces of the BOR ( Business Object Repository).
Clients and Their Roles
When you log on to an SAP System, you log on to a particular client of this system. Any activities you carry out in the system are always carried out in one client. When you plan your SAP system landscape, 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. This section describes the most important client roles.
Since you need to adapt the SAP software for your own business needs, each SAP system landscape requires a client where Customizing settings, and possibly ABAP Workbench developments, can be made. This client is known as the Customizing and development client, or Customizing client for short. The abbreviation CUST is used for this client.
Before you can use the Customizing settings and Workbench developments productively, you need to test them extensively for errors. Any faulty settings can seriously disrupt productive operations, and at worst, lead to the loss of productive data. The integrated nature of the various SAP applications means that there are many dependencies between the different Customizing settings. Even an experienced Customizing developer may not discover these dependencies immediately. The correctness of the settings can only be guaranteed with extensive testing. The client 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 be used without disruption, it is essential that no Customizing settings or Workbench developments are made here, and also that no tests are carried out. This client is known as the Production Client, PROD for short.
These three clients, CUST, QTST and PROD, are the central clients that exist in every system landscape. 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, and then use the CTS to transport them to the other clients.
We also recommend that you do not make any Customizing settings or Workbench developments in the quality assurance or production clients. You can make sure of this by making appropriate client settings.
In addition to the central clients, you can also set up other clients for other tasks. However, you must remember that each extra client takes up additional system resources (main memory and database space). They also need to be administrated. For example, you need to set up and administrate access authorization for the users, and also distribute any changes to other clients with 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 Customizing settings and Workbench developments, before they release their change requests. In this client the developers can create test application data for realistic tests. If they discover errors, they can remove them in the Customizing client. A development test client is always set up in the same SAP 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 test client using a special client copy function. The client copy function uses the unreleased change requests from the Customizing client to do this. The development test client is set so that you cannot make changes to Customizing data and Repository objects.
Prototype or sandbox client (SAND): You can use this client to test any client-specific Customizing settings if you are not sure whether you want to use them in this form. Any settings that you want to keep are then entered in the Customizing client. To prevent conflicts between the prototype client settings and real settings in the Customizing client, you cannot make changes to cross-client Customizing data and Repository objects in the prototype client. The CTS does not record changes made to client-specific Customizing data, and does not transport them from 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 into the production client, you can set up a training client. The users can use the new functions in this client with specially created application data. This client is set so that you cannot make changes to Customizing data and Repository objects.
System Landscape
The system landscape contains all the SAP Systems that you have installed. It can consist of several system groups, whose SAP Systems are linked by transport routes.
Change & Transport System (BC-CTS)
All SAP Systems connected by transport routes.
A system group can include several transport groups or transport domains. While the transport domain is an administrative unit, and the transport group a technical unit, the system group is a logical unit.
After you decide which clients you need and which roles you want them to have, you need to decide how to distribute them amongst the different SAP Systems. You can set up multiple clients independently of one another in a single SAP System. However, when you configure the data, you must remember that cross-client Customizing settings and Repository objects are identical for all clients in a single SAP System. Changes made in one client apply immediately to all clients in the system.
Three-System Landscape
We recommend a three-system landscape in which each of the central clients has its own SAP System.
This consists of a development system DEV, a quality assurance system QAS and a production system PRD. The development system contains the Customizing client CUST, the quality assurance system contains the quality assurance client QTST and the production system contains the production client PROD.
Make all changes to Customizing data and Repository objects in the Customizing client. When you release the corresponding change requests, they are transported into the quality assurance client. This means that changes to cross-client data only appear in the quality assurance client after the transport. In the quality assurance client you can test whether the transports are complete, or whether any linked changes are missing and are still in unreleased change requests. 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 development system. Set up the training client (TRNG) in the quality assurance system.
Two-System Landscape
A two-system landscape is an alternative for smaller SAP implementations where little Workbench development takes place.
The two-system landscape does not include a separate quality assurance system QAS. The quality assurance client is also in the development system DEV.
As in the three-system landscape, the production client is completely separate from the other clients. The disadvantage of a two-system landscape is that cross-client data is used in both the Customizing 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 can also not guarantee that transports from the Customizing client will be complete. Although all tests in the quality assurance client were successful, errors could still occur after the transport into the production client. This problem is caused by changes being made to cross-client data and then not being transported.
________________________________________
One-System Landscape
We do not recommend a one-system landscape containing all central clients in a single SAP System. Joint usage of hardware resources and cross-client data places serious restrictions on how a single system operates. In particular, once the system is used productively, you can no longer develop in it, unless you stop productive operation for the development and test phases.
Transport Organizer - Concept
The Transport Organizer is fully integrated into the ABAP Workbench and Customizing tools. You can navigate between them in both directions. This enables you to:
• Switch to the Transport Organizer from all transactions of the ABAP Workbench and Customizing
• Switch to the appropriate Workbench editor by double-clicking individual objects in an object list
Recording Changes
The Transport Organizer records and documents all changes to objects in the Repository and Customizing:
• Repository objects, for example
o ABAP Dictionary objects
o ABAP programs
o Screens
o Interface definitions
o Documentation
• Customizing objects, for example
o Settings for organizational units (plants, company codes, and so on)
o Settings for control tables
The Transport Organizer helps you when you organize development projects by allowing you to distribute project work for individual developers or teams between different change requests. These change requests record all changes made to development objects and Customizing settings. Objects from the areas of Customizing and the ABAP Workbench are managed and recorded in separate requests. Special checks have been implemented for each of these applications.
You access the Transport Organizer from a request overview that clearly shows all change requests and allows you to display several levels of detail, right down to the object list itself.
Request Overview
You can access the request overview of the Transport Organizer directly from all ABAP Workbench transactions with Environment Transport Organizer (Requests) and from Customizing transactions with Utilities Transport Organizer (Requests).
You can access the request overview of the extended view of the Transport Organizer from the initial screens of Transaction SE01 by choosing Display.
The requests are grouped and displayed under a hierarchy of sort nodes, corresponding to the following request attributes:
• Source system
• Source client
• Transport target
• Request owner
• Request type
• Request status
• Project
In the Transport Organizer, only the levels project, request type and request status are normally active.
If the hierarchy selected by the SAP System does not suit your requirements, you can change the setting as follows:
• Temporary setting
By choosing Edit Sort sequence, you can add or remove sort levels, or change their hierarchy.
• Permanent setting
By choosing Utilities Settings, you can choose the following permanent settings:
o Display short texts of tasks
o Display change date of requests
o 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.
Developments, corrections, and repairs are recorded in tasks and transported using change requests.
Information carrier in the Transport Organizer for entering and managing all changes to Repository objects and Customizing settings performed by employees within a development project.
A task is assigned to a change request.
Change Request:An information source in the Transport Organizer that records and manages all modifications made to Repository objects and Customizing settings during a development project
The target system and type of transport are assigned automatically and no longer need to be maintained 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 Transport Organizer functions for different user groups by assigning appropriate authorizations.
Once you have included Repository objects in a change request, you can edit them in this request only. This means that until the change request has been released, they are locked against development work or maintenance by other developers not working on this change request. These developers are only allowed to display the objects.
This is how the Transport Organizer prevents uncoordinated, parallel changes from being made to objects. Only make changes to the original objects. A warning appears if you try and change a non-original object.
The Transport Organizer is activated automatically every time you edit a Repository object. An object has to be in a change request before a user can create or change it. Entering objects in requests ensures that all changes made in the ABAP Workbench are registered.
Changes to Customizing data are also registered by the Transport Organizer.
A package and the developer who is responsible for it are assigned to each Repository object. This development class indicates which area the object belongs to. This enables you to quickly contact a person in connection with any object. The structure of the entire ABAP Workbench is based on packages which can assist you in starting your work.
(PACKAGE: All Repository objects in the SAP System are classified according to packages. Packages are an enhancement of the former development classes with new and additional semantics.
All objects forming a functional unit, such as programs, ABAP Dictionary objects, and message classes, are grouped together in a package. The development classes are used to structure the Repository and assign the objects to the various SAP components. The assignment to a package also allows you to control the recording and transport of object changes by the CTS. (See the section Request Types and Task Types.)
The assignment of an object to a package is recorded in the Object Directory.
When development work starts, you must first create a package to which the new objects are assigned. When you create a new object in the ABAP Workbench, the SAP System asks which package you want the object to belong to.
The package also helps you when you navigate through the objects in the Object Navigator of the ABAP Workbench (Transaction SE80).
To improve clarity when objects are displayed in this way, SAP advises you not to let the number of objects in a package increase too much, but to distribute the objects to new packages according to appropriate criteria as a project progresses.
The packages are themselves objects in the ABAP Workbench. Changes to existing and newly created packages are, apart from a few exceptions (see also Naming Conventions for Packages), recorded by the Transport Organizer and can be transported into other SAP Systems. When the package is an object in the ABAP Workbench, it is always assigned to itself.)
The Transport Organizer provides version management for all Repository objects, enabling you to compare or retrieve previous versions of objects. This lets you document or restore versions released before or after a particular change request or development project.
All developers working on a change request are required to write structured documentation when releasing their tasks. This states the aims of the project, its status, and any special features it includes. In addition, all changed objects are automatically recorded in the object list of the change 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 computer configuration.
Development projects are not worked on in a production system, but in one or more development systems depending on their size. To ensure that objects remain consistent, each Repository object has a defined original location. Changes are generally made at the original location to prevent unintentional, parallel work on the same object. The original location of Repository objects can be changed with relocation transports.
If several development systems are being used, it may be necessary to transport objects specifically 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, package, transport layer). The transport types required for this are managed by the extended view of the Transport Organizer.
To transport Repository and Customizing objects from the development system to other SAP Systems in the system group, transport routes are used, which are defined when the system group is configured in the Transport Management System. The transport involves exporting objects from the source system in which the objects were changed and importing them into one or more target systems.
A transport log is created automatically for each change request. If errors occur in the production system after an import has taken place from a quality assurance system, the log enables you to immediately find out the following:
• Which objects were transported
• Who requested the transport
• Why the transport was performed
There are Transport Organizer tools available for searching for, displaying, editing, and analyzing change requests and transports.
Transport Management System - Concept
You use the Transport Management System (TMS) to model and manage your system landscape. It provides tools for configuring your system landscape, as well as for organizing, carrying out and monitoring transports.
Configuration of a System Landscape
All SAP Systems that are subject to the administration of the TMS form a transport domain. This is usually all SAP Systems in the system landscape. Certain system settings are the same for all systems within a transport domain, such as the transport routes. To achieve this, one SAP System in the transport domain has the reference configuration, with all other SAP Systems in the transport domain taking copies of this reference configuration. The system with the reference configuration is known as the Transport Domain Controller; only in this system can you make changes to the reference configuration. Each time you change the reference configuration, you must distribute the new configuration to all systems. The TMS automatically generates RFC connections between the systems in a domain so that they can communicate.
Transport Domain: All SAP Systems that are managed jointly by the Transport Management System.
All systems in a transport domain have the same settings as the Change and Transport System.
Transport Layers and Transport Routes
All development projects developed in the same SAP System and transported on the same transport routes are grouped together to form a transport layer.
Before you start the first development project, you create a transport layer in the TMS transport route editor. This transport layer is assigned to the development system as its standard transport layer. Objects delivered by SAP belong to the transport layer "SAP". Other transport layers are generally only needed when new development systems are included in the system group.
After you have set up the transport layer you set up the transport routes. There are two types of transport routes. First you set up consolidation routes, and then you set up delivery routes:
1. Consolidation routes
To make your changes transportable, set up a consolidation route for each transport layer. Specify your development system as the starting point (source) of these consolidation routes. Specify the quality assurance system as the transport target (in a two-system landscape, specify the production system as the transport target).
Any modified objects that have a consolidation route set up for their transport layer are included in transportable change requests. After the request has been released the objects can be imported into the consolidation system.
If you make changes to objects which have no consolidation route defined for their transport layer, then the changes are made automatically in local change requests (or in Customizing requests without a transport target). You cannot transport them into other SAP 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 you use Extended Transport Control.
2. Delivery routes
After you have imported your development work into the quality assurance system, you then want to transport it into your production system. You may even want to transport it into several SAP Systems (for example, additional training systems). To do this, you have 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 are imported into the route’s source system are automatically flagged for import into the route’s target system.
You can set up several delivery routes with the same source system and different target systems (parallel forwarding). You can also set up delivery routes in sequence (multilevel forwarding).
CTS transport control makes sure that all requests from the development system are flagged for import into all other SAP Systems in the same order in which they were exported. This is important, since different requests can contain the same Repository object or the same Customizing setting at different development levels, and you must avoid overwriting a more recent version with an older version.
Multilevel Delivery
Here you can activate multiple delivery routes in sequence. You can choose any SAP Systems in the system group as the source systems of the delivery routes; they do not have to be consolidation systems. This allows you to implement complex chains of transport routes.
Multilevel delivery is not required in a two- or three-system group. In more complex system landscapes, particularly in layered development projects that have each other as sources, multilevel delivery may prove to be a suitable solution:
If there are SAP Systems in the system group with releases prior to 4.0, you can only use multilevel delivery under particular conditions. The Transport Management System checks these conditions when you configure the transport routes in a mixed system group.
When you install an SAP System, a transport directory is set up for it. The CTS uses this directory to store transport data. In most cases, all SAP Systems in a transport domain have a common transport directory. However, there are situations where this is not possible, for example:
• 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 a common transport directory form a transport group. Data is exchanged between the systems using the RFC connections of the TMS.
Basics of Transport Control
This section suggests ways to organize development projects in a distributed environment, using the Change and Transport System (CTS).
The CTS enables you to organize development projects in complex distributed system landscapes.
For example, you can do the following:
• Transport and freeze completed development work and automatically distribute it to several production, test, training, or development systems.
• Distribute development projects among different SAP Systems on the basis of packages.
• Transfer critical development work to separate SAP Systems.
If you do not want to organize your own development projects using different systems, then you do not need all the functions provided by the CTS. In this case, you can set up a simple distributed environment consisting of two systems (development and production system) or three systems (development, quality assurance, and production system).
Transport domain A: This transport domain has one transport group. This means that all the systems access a common transport directory.
Transport domain B: This transport domain has several transport groups, each of which shares a transport directory.
All systems in Europe share a transport directory; this is transport group 2. All systems 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 Systems are available right from the beginning. The TMS allows you to define placeholders, or virtual systems. These take the place of systems that you want to include in the landscape at a later date. In this way, you can model the complete system landscape and make the settings for the CTS as soon as you have configured the TMS in one system. The virtual system is replaced when you install the real system.
If you administrate your SAP Systems locally in different locations, for example at head office and in different branches, it may be a good idea to configure several different domains. If you want to make transports between systems in different domains, you can use domain links to link the two domains. The data is transported between the domains using the RFC connections of the TMS, in the same way as transports are made between different transport groups.
If there is no permanent network connection between systems in different domains, you can use external systems in the TMS to make the transports instead. The transport data is exchanged using a transport directory that can be accessed by both domains, or by using a data volume. External systems offer fewer functions than domain links; for example, transport logs in a different domain can only be displayed using domain links.
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 the TMS.
Making Transports
You can use the Transport Management System to organize, carry out and monitor your transports. You no longer need to execute tp commands at the operating system level. You can start and monitor all imports from every system in the transport domain. The TMS uses the RFC connections that were created automatically when the transport domain was configured to display all information on the requests that are waiting for import.
When you make an import, the TMS starts the transport control program tp in the target system. This program imports the data that was earlier exported from the database of the source system. If the two systems do not have a common transport directory, the TMS copies the necessary 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 background job 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 this system. Even if there is a test system in your domain with free authorization for all users, imports into 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 the domain. All imports are logged, so that you can see which transport requests were imported into a system at which time.
For more information, see Performing Transports.
Assignment of Development Projects to Transport Layers
At the start of a development project, Packages are created for the Repository objects that are to be created as part of the project. When you create the package, you assign it to a transport layer. The SAP System proposes the standard transport layer. All Repository objects that you later create in this package belong to the transport layer of this package and are transported according to the routes set up for this layer.
Customizing settings are generally not Repository objects listed in the Object Directory and do not belong to a package. This means that you cannot assign them directly to a transport layer.
Customizing settings are always assigned to the standard transport layer of the SAP System in which they are valid (or of the client, if extended transport control is activated). They are then transported from this system (or client) according to the transport routes set up for the standard transport layer.
Repository objects of the SAP standard delivered by SAP or from SAP add-on components installed in your SAP Systems always belong to the pre-installed "SAP" transport layer. You cannot assign these objects to one of your own transport layers. If you want to patch or modify SAP standard objects in your development system, SAP recommends transporting these changes along the same routes as for your own developments. To do this, you need to set up the same consolidation route for the "SAP" layer as for the standard transport layer of the development system; this means that the source and destination of the two consolidation routes must be the same. (For more information, see Changing the SAP Standard.) 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-system group:
Distribution of IAC Objects
Internet Application Components (IACs) are complete business solutions for connecting SAP components to the Internet. You can also develop IAC objects outside of the SAP system in the SAP@Web Studio. However, to make sure that the data is distributed consistently throughout the system landscape, use the Change and Transport System to distribute your IAC objects.
When you transport IAC objects, you first import the data into the SAP system buffer. You must then publish the objects in the directories of the Internet Transaction Servers (ITS) connected to the system.
If you want to publish in an ITS directory from an SAP system, you must install the IAC Object Receiver (IACOR). If you have a virtual ITS instance, the IACOR distributes the objects from the SAP system to the correct location on the file system of the ITS instance.
When you install the IACOR, two RFC destinations are generated in the SAP system for each ITS instance linked to the IACOR. One of these RFC destinations is used to publish in the ITS AGate and one in the ITS WGate. You can combine multiple AGates and WGates into a site, for example, when load balancing.
RFC destinations are assigned to a site when you install the IACOR.
These sites determine the publishing functions of IACs in the SAP system.
• When you import IAC objects into the SAP system, each site defines whether the ITS instances linked to it publish these objects or not.
Since the IACOR is configured as part of the ITS outside the SAP system, sites created by installing an IACOR are not published, by default. The flag must be set in the SAP system.
• When you edit IAC objects in the SAP system, you can select these sites as the publication target of the IAC objects in the user-specific settings of the ABAP Workbench.
To do this, go to the SAP EasyAccess menu, and choose SAP Menu ® Overview ® Object Navigator ® Utilities ® Settings ® Internet Transaction Server ® Publish.
To edit a site, call the view maintenance functions (transaction SM30) and edit the view IACORSITE. You can now:
• define additional sites
• define the way IAC objects are imported for each site
To edit the individual destinations, call the view maintenance functions (transaction SM30) and edit the view IACORDES.
• Here you can change the assignment of a destination to a site.
For more information, see SAP@Web Installation Guide.
Transport Strategy in the CTS
The Change and Transport System provides a range of functions that help you to choose a transport strategy optimally suited to your requirements. We recommend that you follow the transport strategy while you plan and set up your system landscape.
The transport strategy may change during an SAP implementation project, depending which phase of the project you are in.
All users working as developers must know the transport strategy and stick to certain guidelines.
Client Landscape and Transport Routes
Before you start an SAP project, you must decide which clients and systems you need. Then decide which parts of the project are to be developed in which clients, and into which clients you want to transport your changes. To transport your changes, create transport routes between clients or systems.
You must always use transport routes, regardless of which transport strategy you choose.
You can define client-specific transport routes by using Extended Transport Control.
Transport Schedules
If different developers work on the same project, dependencies may arise between the objects that belong to the project. So that developments are consistent in other systems, all the changes made by the developers must be transported at the same time. Otherwise, you may cause inconsistencies; for example, if a developer creates a table that references a data element created by another developer. If the change request that contains the table is then imported into a target system in which the data element does not exist, the import will encounter errors.
One way of keeping these dependencies under control is to have a fixed transport schedule, in which all changes released up until a certain fixed date are transported into a client or SAP System.
This method is particularly suitable for the early phases of an SAP project when many changes are being made to the system. A transport schedule in a system landscape with a development system, quality assurance system and production system could be as follows:
• All changes are imported once an hour into the quality assurance system.
• All requests are imported once a week into the planned production system.
This schedule lets the developers test their changes almost immediately in the QA system, and correct any errors. The developers' aim is to consolidate their changes in the QA system before they are due to be imported into the production system. Business processes can be tested in the production system, and it may also be used for holding training courses. Periodic transports of all changes made to the system reduces the work of the system administrator, and keeps your systems synchronized.
For more information, see Transports with Import Queues.
Projects
If you are working on several different development projects at the same time, you cannot always estimate which of the projects will go live at which time. If your development projects do not overlap, or only overlap a little, you can use projects to control your transports, and then use different transport schedules for different projects. For example, if a component is just about to go live, you may need to import one project into the production system particularly frequently, with other projects only being imported into the QA system first, and into the production system later.
Quality Assurance
If you work with mass transports, all requests released by the developers are imported into production systems. You can implement the TMS Quality Assurance procedure to prevent unchecked changes from being transported. The procedure makes sure that each change request is approved before it is imported into the production system.
You should use the TMS Quality Assurance procedure even if you are using single transports.
Single Imports
If you want to maintain a production system with specific transports, it is best to import single requests rather than importing all changes waiting for import. Use single transports if you have fewer changes to transport and your organization prevents you from having a fixed transport schedule. This method usually entails extra work for the administrators compared to periodic imports. Developers need to pay extra attention to the consistency of their change requests, since the Change and Transport System does not offer as much support in this area.
If a small number of developers are working on a project, or if the developers work very closely with the administrator, they often make their own single transports.
Transport Workflow
You want to make specific single transports into your systems, but would rather have this done by the system administrator, we recommend that you use the transport workflow. This method automatically triggers a workflow when you release a change request. The workflow ensures close communication between development and administration.
When using the transport workflow, the administrator can react quickly to any requests from the developers and the project team.
Transport Workflow
Purpose
The transport workflow provides a framework for transporting enhancements or new developments of existing business functions in a system landscape. It provides a direct connection between development and transport administration. The transport workflow manages the transport process, determines the user for each individual step automatically, and then displays an interface which they can use to perform the task directly.
It is an efficient method of transporting a selected number of requests into a group of transport targets, and uses clearly defined approval steps to ensure the quality of your target systems. The requests can be transportable change requests, Customizing requests, relocation transports or transports of copies. The transport targets do not need to be located on defined transport routes. However, the transport workflow can involve some risks, caused by the dependencies between transport requests:
• Import sequence
It is important that you import requests in the correct order, so that development work is up-to-date in the target system.
• Incompleteness
It is important that the functions transported in the transport proposal are complete; otherwise errors may occur in the import system.
A request is not imported, but it contains an important data element. You use another request to transport a table that references this data element. Since the referenced data element does not exist in the target system, activation errors will occur when you import the second request.
The transport workflow is a generic workflow. Its ability to process the transport route configuration in TMS enables it to adapt itself to any system landscape. This means you can transport multiple requests into multiple targets, even if these targets are not located on the transport routes.
This reduces the amount of work for the transport administrator significantly. The automated nature of the workflow also reduces the likelihood of errors during transports.
You can use the transport workflow in two different ways.
• Transport workflow as a transport strategy
If you have production systems in your landscape that can only accept approved transports, we recommend that you use the transport workflow to organize and coordinate the transport process.
To do this, set Workflow-controlled transports as your transport strategy and configure the transport workflow.
When you release a transport request, the transport workflow starts automatically and the screen Create Transport Proposal appears. The requests are then released implicitly when the transport proposal is sent to the transport administrator.
• Special transport workflow (mass transports)
You can use the special transport workflow to make transports that do not follow the defined transport routes or that take place outside the normal transport schedule (part of the mass transport strategy). These transports may be corrections made in the development system that have to be transported into the production system without delay.
To use the special transport workflow, set Mass transports as your transport strategy and configure the transport workflow.
Prerequisites
• You have configured the transport workflow for your system.
• The users involved in the transport workflow have a user in the Workflow Engine system/client.
• One or more users have transport administration authorization.
Process Flow
The developer creates a transport proposal in the Transport Organizer. This proposal contains the required transport requests. The transport proposal then appears in the TMS worklist of the transport administrator. The administrator can then approve or reject the transport proposal. The transport administrator can also make changes to the transport proposal, for example change its contents and the transport target.
After a transport proposal has been approved, the TMS imports the transport requests automatically into the specified target systems. If the proposal is rejected, it is sent back to the transport proposal inbox for revision by the responsible developer. If the import is successful, the proposal is sent back to the transport proposal inbox to be confirmed by the creator of the proposal. The developer can complete the proposal by confirming it, or apply to have it transported into other systems.
We recommend that you only use the transport workflow to transport into those target systems defined by the direct transport routes. Only in the next step should you work out which are the next direct target systems, and then apply to transport into them. This is the best way to keep the transport landscape consistent and complete.
The transport administrator can also set the transport workflow so that only the direct target systems defined on the transport routes can be selected in the Create Transport Proposal step, and not the whole transport landscape. (See also Setting Direct Target Systems.)
The transport workflow writes an action log for each transport proposal. This log contains all 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 Transport Workflow (Administration).
For more information on the development team, see Transport Workflow (Development).
Transactions and Tools in the CTS
The Change and Transport System (CTS) provides you with tools for recording the changes you make to Repository objects and Customizing objects, and for distributing these changes within the system landscape. The CTS offers the team members of a software development or implementation project transactions in the SAP System and programs at the operating system level.
The Transport Organizer provides functions for creating, documenting and releasing change requests during the Customizing and development process. The Transport Organizer is designed specifically for use by the development team and the project managers of a development or implementation project.
The Transport Management System (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 tp and r3trans are programs at the operating system level. They do not usually have to be executed by the user directly since they are called automatically by the CTS. The transport tools communicate with the SAP System and the database, and export and import requests.
Functions in the Transport Organizer
You call the initial screen of the Transport Organizer with Transaction SE09 or SE10. You can also access the request overview of the Transport Organizer from all ABAP Workbench transactions by choosing Environment Transport Organizer (Requests).
The Display function lets you search for all requests that belong to the specified user and match the 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 can change this by going to the initial screen and choosing Settings Other settings.
Tasks that are not assigned to a request can no longer be created. This means that these tasks are no longer displayed as standard. If you still own tasks of this type, use the request search to display them.
The right side of the initial screen shows you cross-system information on the status of transports and repairs, and also lets you display the transport proposal inbox of the transport workflow.
You can find various tools for searching for, analyzing, and managing change requests by choosing Goto Transport Organizer tools.
Change Requests
Change requests are managed by the Transport Organizer. Changes to Repository and Customizing objects are recorded in change requests.
So that you can differentiate between global changes to the system and client-specific Customizing settings, the CTS records your changes in either a Workbench request or a Customizing request:
• Workbench Requests
When you change a Repository object of the ABAP Workbench, a query window appears in which you need to specify a Workbench request. You can only save the changes if you have assigned the object to a change request.
Workbench requests and the tasks assigned to them are normally used to record changes to Repository objects and Customizing for all clients. However, you can also include client-specific Customizing.
Whether the changes to Repository objects are transported depends on whether a transport route is defined from the current SAP System for the package of these objects. From the system settings, the system automatically determines whether the change requests are transportable and to which target system they should be transported.
• Customizing requests
Customizing requests record client-specific Customizing settings made in a single client (the source client of the request).
Automatic recording of configuration activities in the Customizing work for a client can be activated or deactivated for each client with Client Control. If automatic recording is active, a query window appears when you change Customizing settings, asking you to specify a Customizing 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 uses the standard transport layer to determine automatically whether the change requests are transportable and to which target system they should be transported. However, you can change this manually
Before you can use the SAP software to control the business processes in your company, you must first adapt it to your own business needs. This is usually done in an SAP implementation project. Adapting and configuring is usually an ongoing process. Even after you start using the system productively, you still need to make changes to the SAP configuration. This may be due to business or organizational changes in your company, or due to the implementation of new SAP 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 the type and extent of your business requirements. Any modifications that you make with these tools are stored in certain tables in the SAP database.
Customizing Tools
The most important configuration tool is the Implementation Guide ( IMG). You can use the IMG to make all configurations possible in the SAP standard. Any modifications you make to the SAP software in the IMG are known as Customizing settings, or Customizing for short. This includes 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 a hierarchical overview. This overview shows the recommended process flow and assignment to the different applications of the SAP System. The IMG lets you filter out the relevant IMG activities for a particular section of the SAP applications. You can also group IMG activities logically into IMG Projects. These projects are then worked on as an implementation project by a particular team. You can document the requirements of a project and its progress in the IMG Project.
The changes that you make in the IMG are placed in the Customizing tables of the SAP database. The contents of these tables are known as Customizing data. When you use the SAP applications productively, the SAP runtime system analyzes this Customizing data and uses it to control your business processes.
Most Customizing data is client-specific. This means that you can choose different Customizing settings for each client in your SAP System that do not affect each other. Changes to the Customizing settings in one client have no effect on system actions in another client.
However, there is also a significant amount of cross-client Customizing data that is relevant for all clients (such as the factory calendar). Note that if you change these types of Customizing settings, it affects all clients in the SAP System.
ABAP Workbench
If the configuration options in the SAP standard are not enough to meet your requirements, you can also add to the SAP standard functions. SAP provides the ABAP Workbench as a complete programming environment. The ABAP Workbench includes tools for defining data structures (ABAP Dictionary), developing ABAP programs (ABAP Editor) and designing interfaces (Screen Painter and Menu Painter), as well as many other functions.
For example, you can use the ABAP Workbench to develop your own report programs or transactions, or to modify or make your own enhancements to existing SAP programs. These enhancements are known as customer exits. However, this does require experience of the ABAP Workbench and the SAP application where you want to develop.
The changes that you make in the ABAP Workbench are placed in the Repository tables of the SAP 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-client Customizing, 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 you make in the IMG or ABAP Workbench. The CTS records all changes in change requests. The changes in change requests can be linked together logically, or can be completely independent of each other. Developers in a team can use a common request. You can create documentation for a change request, where you can describe your changes in more detail. This makes it easier to 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 certain stage, you can release the request. The change request is then used to copy the changes from this 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 your development 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 program errors.
Transports of changes between clients and systems are subject to rules that are set in the CTS configuration in the system landscape. One rule may be that changes are transported into a test environment 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 whether there were any errors.
Application Data
In contrast to Customizing and Repository data, application data is not part of the configuration of the SAP software. Application data is the business data that the SAP applications process when you use them productively. It is split up into master data (such as material masters, customer masters 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 to transport application data into other clients or systems.
If you want to copy master data and movement data between clients in an SAP System, or from a non-SAP system into an SAP System, or if you want to set up this data automatically, you can use other tools, such as ALE ( Application Link Enabling), CATT ( Computer Aided Test Tool), or use the application interfaces of the BOR ( Business Object Repository).
Clients and Their Roles
When you log on to an SAP System, you log on to a particular client of this system. Any activities you carry out in the system are always carried out in one client. When you plan your SAP system landscape, 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. This section describes the most important client roles.
Since you need to adapt the SAP software for your own business needs, each SAP system landscape requires a client where Customizing settings, and possibly ABAP Workbench developments, can be made. This client is known as the Customizing and development client, or Customizing client for short. The abbreviation CUST is used for this client.
Before you can use the Customizing settings and Workbench developments productively, you need to test them extensively for errors. Any faulty settings can seriously disrupt productive operations, and at worst, lead to the loss of productive data. The integrated nature of the various SAP applications means that there are many dependencies between the different Customizing settings. Even an experienced Customizing developer may not discover these dependencies immediately. The correctness of the settings can only be guaranteed with extensive testing. The client 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 be used without disruption, it is essential that no Customizing settings or Workbench developments are made here, and also that no tests are carried out. This client is known as the Production Client, PROD for short.
These three clients, CUST, QTST and PROD, are the central clients that exist in every system landscape. 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, and then use the CTS to transport them to the other clients.
We also recommend that you do not make any Customizing settings or Workbench developments in the quality assurance or production clients. You can make sure of this by making appropriate client settings.
In addition to the central clients, you can also set up other clients for other tasks. However, you must remember that each extra client takes up additional system resources (main memory and database space). They also need to be administrated. For example, you need to set up and administrate access authorization for the users, and also distribute any changes to other clients with 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 Customizing settings and Workbench developments, before they release their change requests. In this client the developers can create test application data for realistic tests. If they discover errors, they can remove them in the Customizing client. A development test client is always set up in the same SAP 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 test client using a special client copy function. The client copy function uses the unreleased change requests from the Customizing client to do this. The development test client is set so that you cannot make changes to Customizing data and Repository objects.
Prototype or sandbox client (SAND): You can use this client to test any client-specific Customizing settings if you are not sure whether you want to use them in this form. Any settings that you want to keep are then entered in the Customizing client. To prevent conflicts between the prototype client settings and real settings in the Customizing client, you cannot make changes to cross-client Customizing data and Repository objects in the prototype client. The CTS does not record changes made to client-specific Customizing data, and does not transport them from 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 into the production client, you can set up a training client. The users can use the new functions in this client with specially created application data. This client is set so that you cannot make changes to Customizing data and Repository objects.
System Landscape
The system landscape contains all the SAP Systems that you have installed. It can consist of several system groups, whose SAP Systems are linked by transport routes.
Change & Transport System (BC-CTS)
All SAP Systems connected by transport routes.
A system group can include several transport groups or transport domains. While the transport domain is an administrative unit, and the transport group a technical unit, the system group is a logical unit.
After you decide which clients you need and which roles you want them to have, you need to decide how to distribute them amongst the different SAP Systems. You can set up multiple clients independently of one another in a single SAP System. However, when you configure the data, you must remember that cross-client Customizing settings and Repository objects are identical for all clients in a single SAP System. Changes made in one client apply immediately to all clients in the system.
Three-System Landscape
We recommend a three-system landscape in which each of the central clients has its own SAP System.
This consists of a development system DEV, a quality assurance system QAS and a production system PRD. The development system contains the Customizing client CUST, the quality assurance system contains the quality assurance client QTST and the production system contains the production client PROD.
Make all changes to Customizing data and Repository objects in the Customizing client. When you release the corresponding change requests, they are transported into the quality assurance client. This means that changes to cross-client data only appear in the quality assurance client after the transport. In the quality assurance client you can test whether the transports are complete, or whether any linked changes are missing and are still in unreleased change requests. 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 development system. Set up the training client (TRNG) in the quality assurance system.
Two-System Landscape
A two-system landscape is an alternative for smaller SAP implementations where little Workbench development takes place.
The two-system landscape does not include a separate quality assurance system QAS. The quality assurance client is also in the development system DEV.
As in the three-system landscape, the production client is completely separate from the other clients. The disadvantage of a two-system landscape is that cross-client data is used in both the Customizing 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 can also not guarantee that transports from the Customizing client will be complete. Although all tests in the quality assurance client were successful, errors could still occur after the transport into the production client. This problem is caused by changes being made to cross-client data and then not being transported.
________________________________________
One-System Landscape
We do not recommend a one-system landscape containing all central clients in a single SAP System. Joint usage of hardware resources and cross-client data places serious restrictions on how a single system operates. In particular, once the system is used productively, you can no longer develop in it, unless you stop productive operation for the development and test phases.
Transport Organizer - Concept
The Transport Organizer is fully integrated into the ABAP Workbench and Customizing tools. You can navigate between them in both directions. This enables you to:
• Switch to the Transport Organizer from all transactions of the ABAP Workbench and Customizing
• Switch to the appropriate Workbench editor by double-clicking individual objects in an object list
Recording Changes
The Transport Organizer records and documents all changes to objects in the Repository and Customizing:
• Repository objects, for example
o ABAP Dictionary objects
o ABAP programs
o Screens
o Interface definitions
o Documentation
• Customizing objects, for example
o Settings for organizational units (plants, company codes, and so on)
o Settings for control tables
The Transport Organizer helps you when you organize development projects by allowing you to distribute project work for individual developers or teams between different change requests. These change requests record all changes made to development objects and Customizing settings. Objects from the areas of Customizing and the ABAP Workbench are managed and recorded in separate requests. Special checks have been implemented for each of these applications.
You access the Transport Organizer from a request overview that clearly shows all change requests and allows you to display several levels of detail, right down to the object list itself.
Request Overview
You can access the request overview of the Transport Organizer directly from all ABAP Workbench transactions with Environment Transport Organizer (Requests) and from Customizing transactions with Utilities Transport Organizer (Requests).
You can access the request overview of the extended view of the Transport Organizer from the initial screens of Transaction SE01 by choosing Display.
The requests are grouped and displayed under a hierarchy of sort nodes, corresponding to the following request attributes:
• Source system
• Source client
• Transport target
• Request owner
• Request type
• Request status
• Project
In the Transport Organizer, only the levels project, request type and request status are normally active.
If the hierarchy selected by the SAP System does not suit your requirements, you can change the setting as follows:
• Temporary setting
By choosing Edit Sort sequence, you can add or remove sort levels, or change their hierarchy.
• Permanent setting
By choosing Utilities Settings, you can choose the following permanent settings:
o Display short texts of tasks
o Display change date of requests
o 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.
Developments, corrections, and repairs are recorded in tasks and transported using change requests.
Information carrier in the Transport Organizer for entering and managing all changes to Repository objects and Customizing settings performed by employees within a development project.
A task is assigned to a change request.
Change Request:An information source in the Transport Organizer that records and manages all modifications made to Repository objects and Customizing settings during a development project
The target system and type of transport are assigned automatically and no longer need to be maintained 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 Transport Organizer functions for different user groups by assigning appropriate authorizations.
Once you have included Repository objects in a change request, you can edit them in this request only. This means that until the change request has been released, they are locked against development work or maintenance by other developers not working on this change request. These developers are only allowed to display the objects.
This is how the Transport Organizer prevents uncoordinated, parallel changes from being made to objects. Only make changes to the original objects. A warning appears if you try and change a non-original object.
The Transport Organizer is activated automatically every time you edit a Repository object. An object has to be in a change request before a user can create or change it. Entering objects in requests ensures that all changes made in the ABAP Workbench are registered.
Changes to Customizing data are also registered by the Transport Organizer.
A package and the developer who is responsible for it are assigned to each Repository object. This development class indicates which area the object belongs to. This enables you to quickly contact a person in connection with any object. The structure of the entire ABAP Workbench is based on packages which can assist you in starting your work.
(PACKAGE: All Repository objects in the SAP System are classified according to packages. Packages are an enhancement of the former development classes with new and additional semantics.
All objects forming a functional unit, such as programs, ABAP Dictionary objects, and message classes, are grouped together in a package. The development classes are used to structure the Repository and assign the objects to the various SAP components. The assignment to a package also allows you to control the recording and transport of object changes by the CTS. (See the section Request Types and Task Types.)
The assignment of an object to a package is recorded in the Object Directory.
When development work starts, you must first create a package to which the new objects are assigned. When you create a new object in the ABAP Workbench, the SAP System asks which package you want the object to belong to.
The package also helps you when you navigate through the objects in the Object Navigator of the ABAP Workbench (Transaction SE80).
To improve clarity when objects are displayed in this way, SAP advises you not to let the number of objects in a package increase too much, but to distribute the objects to new packages according to appropriate criteria as a project progresses.
The packages are themselves objects in the ABAP Workbench. Changes to existing and newly created packages are, apart from a few exceptions (see also Naming Conventions for Packages), recorded by the Transport Organizer and can be transported into other SAP Systems. When the package is an object in the ABAP Workbench, it is always assigned to itself.)
The Transport Organizer provides version management for all Repository objects, enabling you to compare or retrieve previous versions of objects. This lets you document or restore versions released before or after a particular change request or development project.
All developers working on a change request are required to write structured documentation when releasing their tasks. This states the aims of the project, its status, and any special features it includes. In addition, all changed objects are automatically recorded in the object list of the change 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 computer configuration.
Development projects are not worked on in a production system, but in one or more development systems depending on their size. To ensure that objects remain consistent, each Repository object has a defined original location. Changes are generally made at the original location to prevent unintentional, parallel work on the same object. The original location of Repository objects can be changed with relocation transports.
If several development systems are being used, it may be necessary to transport objects specifically 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, package, transport layer). The transport types required for this are managed by the extended view of the Transport Organizer.
To transport Repository and Customizing objects from the development system to other SAP Systems in the system group, transport routes are used, which are defined when the system group is configured in the Transport Management System. The transport involves exporting objects from the source system in which the objects were changed and importing them into one or more target systems.
A transport log is created automatically for each change request. If errors occur in the production system after an import has taken place from a quality assurance system, the log enables you to immediately find out the following:
• Which objects were transported
• Who requested the transport
• Why the transport was performed
There are Transport Organizer tools available for searching for, displaying, editing, and analyzing change requests and transports.
Transport Management System - Concept
You use the Transport Management System (TMS) to model and manage your system landscape. It provides tools for configuring your system landscape, as well as for organizing, carrying out and monitoring transports.
Configuration of a System Landscape
All SAP Systems that are subject to the administration of the TMS form a transport domain. This is usually all SAP Systems in the system landscape. Certain system settings are the same for all systems within a transport domain, such as the transport routes. To achieve this, one SAP System in the transport domain has the reference configuration, with all other SAP Systems in the transport domain taking copies of this reference configuration. The system with the reference configuration is known as the Transport Domain Controller; only in this system can you make changes to the reference configuration. Each time you change the reference configuration, you must distribute the new configuration to all systems. The TMS automatically generates RFC connections between the systems in a domain so that they can communicate.
Transport Domain: All SAP Systems that are managed jointly by the Transport Management System.
All systems in a transport domain have the same settings as the Change and Transport System.
Transport Layers and Transport Routes
All development projects developed in the same SAP System and transported on the same transport routes are grouped together to form a transport layer.
Before you start the first development project, you create a transport layer in the TMS transport route editor. This transport layer is assigned to the development system as its standard transport layer. Objects delivered by SAP belong to the transport layer "SAP". Other transport layers are generally only needed when new development systems are included in the system group.
After you have set up the transport layer you set up the transport routes. There are two types of transport routes. First you set up consolidation routes, and then you set up delivery routes:
1. Consolidation routes
To make your changes transportable, set up a consolidation route for each transport layer. Specify your development system as the starting point (source) of these consolidation routes. Specify the quality assurance system as the transport target (in a two-system landscape, specify the production system as the transport target).
Any modified objects that have a consolidation route set up for their transport layer are included in transportable change requests. After the request has been released the objects can be imported into the consolidation system.
If you make changes to objects which have no consolidation route defined for their transport layer, then the changes are made automatically in local change requests (or in Customizing requests without a transport target). You cannot transport them into other SAP 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 you use Extended Transport Control.
2. Delivery routes
After you have imported your development work into the quality assurance system, you then want to transport it into your production system. You may even want to transport it into several SAP Systems (for example, additional training systems). To do this, you have 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 are imported into the route’s source system are automatically flagged for import into the route’s target system.
You can set up several delivery routes with the same source system and different target systems (parallel forwarding). You can also set up delivery routes in sequence (multilevel forwarding).
CTS transport control makes sure that all requests from the development system are flagged for import into all other SAP Systems in the same order in which they were exported. This is important, since different requests can contain the same Repository object or the same Customizing setting at different development levels, and you must avoid overwriting a more recent version with an older version.
Multilevel Delivery
Here you can activate multiple delivery routes in sequence. You can choose any SAP Systems in the system group as the source systems of the delivery routes; they do not have to be consolidation systems. This allows you to implement complex chains of transport routes.
Multilevel delivery is not required in a two- or three-system group. In more complex system landscapes, particularly in layered development projects that have each other as sources, multilevel delivery may prove to be a suitable solution:
If there are SAP Systems in the system group with releases prior to 4.0, you can only use multilevel delivery under particular conditions. The Transport Management System checks these conditions when you configure the transport routes in a mixed system group.
When you install an SAP System, a transport directory is set up for it. The CTS uses this directory to store transport data. In most cases, all SAP Systems in a transport domain have a common transport directory. However, there are situations where this is not possible, for example:
• 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 a common transport directory form a transport group. Data is exchanged between the systems using the RFC connections of the TMS.
Basics of Transport Control
This section suggests ways to organize development projects in a distributed environment, using the Change and Transport System (CTS).
The CTS enables you to organize development projects in complex distributed system landscapes.
For example, you can do the following:
• Transport and freeze completed development work and automatically distribute it to several production, test, training, or development systems.
• Distribute development projects among different SAP Systems on the basis of packages.
• Transfer critical development work to separate SAP Systems.
If you do not want to organize your own development projects using different systems, then you do not need all the functions provided by the CTS. In this case, you can set up a simple distributed environment consisting of two systems (development and production system) or three systems (development, quality assurance, and production system).
Transport domain A: This transport domain has one transport group. This means that all the systems access a common transport directory.
Transport domain B: This transport domain has several transport groups, each of which shares a transport directory.
All systems in Europe share a transport directory; this is transport group 2. All systems 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 Systems are available right from the beginning. The TMS allows you to define placeholders, or virtual systems. These take the place of systems that you want to include in the landscape at a later date. In this way, you can model the complete system landscape and make the settings for the CTS as soon as you have configured the TMS in one system. The virtual system is replaced when you install the real system.
If you administrate your SAP Systems locally in different locations, for example at head office and in different branches, it may be a good idea to configure several different domains. If you want to make transports between systems in different domains, you can use domain links to link the two domains. The data is transported between the domains using the RFC connections of the TMS, in the same way as transports are made between different transport groups.
If there is no permanent network connection between systems in different domains, you can use external systems in the TMS to make the transports instead. The transport data is exchanged using a transport directory that can be accessed by both domains, or by using a data volume. External systems offer fewer functions than domain links; for example, transport logs in a different domain can only be displayed using domain links.
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 the TMS.
Making Transports
You can use the Transport Management System to organize, carry out and monitor your transports. You no longer need to execute tp commands at the operating system level. You can start and monitor all imports from every system in the transport domain. The TMS uses the RFC connections that were created automatically when the transport domain was configured to display all information on the requests that are waiting for import.
When you make an import, the TMS starts the transport control program tp in the target system. This program imports the data that was earlier exported from the database of the source system. If the two systems do not have a common transport directory, the TMS copies the necessary 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 background job 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 this system. Even if there is a test system in your domain with free authorization for all users, imports into 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 the domain. All imports are logged, so that you can see which transport requests were imported into a system at which time.
For more information, see Performing Transports.
Assignment of Development Projects to Transport Layers
At the start of a development project, Packages are created for the Repository objects that are to be created as part of the project. When you create the package, you assign it to a transport layer. The SAP System proposes the standard transport layer. All Repository objects that you later create in this package belong to the transport layer of this package and are transported according to the routes set up for this layer.
Customizing settings are generally not Repository objects listed in the Object Directory and do not belong to a package. This means that you cannot assign them directly to a transport layer.
Customizing settings are always assigned to the standard transport layer of the SAP System in which they are valid (or of the client, if extended transport control is activated). They are then transported from this system (or client) according to the transport routes set up for the standard transport layer.
Repository objects of the SAP standard delivered by SAP or from SAP add-on components installed in your SAP Systems always belong to the pre-installed "SAP" transport layer. You cannot assign these objects to one of your own transport layers. If you want to patch or modify SAP standard objects in your development system, SAP recommends transporting these changes along the same routes as for your own developments. To do this, you need to set up the same consolidation route for the "SAP" layer as for the standard transport layer of the development system; this means that the source and destination of the two consolidation routes must be the same. (For more information, see Changing the SAP Standard.) 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-system group:
Distribution of IAC Objects
Internet Application Components (IACs) are complete business solutions for connecting SAP components to the Internet. You can also develop IAC objects outside of the SAP system in the SAP@Web Studio. However, to make sure that the data is distributed consistently throughout the system landscape, use the Change and Transport System to distribute your IAC objects.
When you transport IAC objects, you first import the data into the SAP system buffer. You must then publish the objects in the directories of the Internet Transaction Servers (ITS) connected to the system.
If you want to publish in an ITS directory from an SAP system, you must install the IAC Object Receiver (IACOR). If you have a virtual ITS instance, the IACOR distributes the objects from the SAP system to the correct location on the file system of the ITS instance.
When you install the IACOR, two RFC destinations are generated in the SAP system for each ITS instance linked to the IACOR. One of these RFC destinations is used to publish in the ITS AGate and one in the ITS WGate. You can combine multiple AGates and WGates into a site, for example, when load balancing.
RFC destinations are assigned to a site when you install the IACOR.
These sites determine the publishing functions of IACs in the SAP system.
• When you import IAC objects into the SAP system, each site defines whether the ITS instances linked to it publish these objects or not.
Since the IACOR is configured as part of the ITS outside the SAP system, sites created by installing an IACOR are not published, by default. The flag must be set in the SAP system.
• When you edit IAC objects in the SAP system, you can select these sites as the publication target of the IAC objects in the user-specific settings of the ABAP Workbench.
To do this, go to the SAP EasyAccess menu, and choose SAP Menu ® Overview ® Object Navigator ® Utilities ® Settings ® Internet Transaction Server ® Publish.
To edit a site, call the view maintenance functions (transaction SM30) and edit the view IACORSITE. You can now:
• define additional sites
• define the way IAC objects are imported for each site
To edit the individual destinations, call the view maintenance functions (transaction SM30) and edit the view IACORDES.
• Here you can change the assignment of a destination to a site.
For more information, see SAP@Web Installation Guide.
Transport Strategy in the CTS
The Change and Transport System provides a range of functions that help you to choose a transport strategy optimally suited to your requirements. We recommend that you follow the transport strategy while you plan and set up your system landscape.
The transport strategy may change during an SAP implementation project, depending which phase of the project you are in.
All users working as developers must know the transport strategy and stick to certain guidelines.
Client Landscape and Transport Routes
Before you start an SAP project, you must decide which clients and systems you need. Then decide which parts of the project are to be developed in which clients, and into which clients you want to transport your changes. To transport your changes, create transport routes between clients or systems.
You must always use transport routes, regardless of which transport strategy you choose.
You can define client-specific transport routes by using Extended Transport Control.
Transport Schedules
If different developers work on the same project, dependencies may arise between the objects that belong to the project. So that developments are consistent in other systems, all the changes made by the developers must be transported at the same time. Otherwise, you may cause inconsistencies; for example, if a developer creates a table that references a data element created by another developer. If the change request that contains the table is then imported into a target system in which the data element does not exist, the import will encounter errors.
One way of keeping these dependencies under control is to have a fixed transport schedule, in which all changes released up until a certain fixed date are transported into a client or SAP System.
This method is particularly suitable for the early phases of an SAP project when many changes are being made to the system. A transport schedule in a system landscape with a development system, quality assurance system and production system could be as follows:
• All changes are imported once an hour into the quality assurance system.
• All requests are imported once a week into the planned production system.
This schedule lets the developers test their changes almost immediately in the QA system, and correct any errors. The developers' aim is to consolidate their changes in the QA system before they are due to be imported into the production system. Business processes can be tested in the production system, and it may also be used for holding training courses. Periodic transports of all changes made to the system reduces the work of the system administrator, and keeps your systems synchronized.
For more information, see Transports with Import Queues.
Projects
If you are working on several different development projects at the same time, you cannot always estimate which of the projects will go live at which time. If your development projects do not overlap, or only overlap a little, you can use projects to control your transports, and then use different transport schedules for different projects. For example, if a component is just about to go live, you may need to import one project into the production system particularly frequently, with other projects only being imported into the QA system first, and into the production system later.
Quality Assurance
If you work with mass transports, all requests released by the developers are imported into production systems. You can implement the TMS Quality Assurance procedure to prevent unchecked changes from being transported. The procedure makes sure that each change request is approved before it is imported into the production system.
You should use the TMS Quality Assurance procedure even if you are using single transports.
Single Imports
If you want to maintain a production system with specific transports, it is best to import single requests rather than importing all changes waiting for import. Use single transports if you have fewer changes to transport and your organization prevents you from having a fixed transport schedule. This method usually entails extra work for the administrators compared to periodic imports. Developers need to pay extra attention to the consistency of their change requests, since the Change and Transport System does not offer as much support in this area.
If a small number of developers are working on a project, or if the developers work very closely with the administrator, they often make their own single transports.
Transport Workflow
You want to make specific single transports into your systems, but would rather have this done by the system administrator, we recommend that you use the transport workflow. This method automatically triggers a workflow when you release a change request. The workflow ensures close communication between development and administration.
When using the transport workflow, the administrator can react quickly to any requests from the developers and the project team.
Transport Workflow
Purpose
The transport workflow provides a framework for transporting enhancements or new developments of existing business functions in a system landscape. It provides a direct connection between development and transport administration. The transport workflow manages the transport process, determines the user for each individual step automatically, and then displays an interface which they can use to perform the task directly.
It is an efficient method of transporting a selected number of requests into a group of transport targets, and uses clearly defined approval steps to ensure the quality of your target systems. The requests can be transportable change requests, Customizing requests, relocation transports or transports of copies. The transport targets do not need to be located on defined transport routes. However, the transport workflow can involve some risks, caused by the dependencies between transport requests:
• Import sequence
It is important that you import requests in the correct order, so that development work is up-to-date in the target system.
• Incompleteness
It is important that the functions transported in the transport proposal are complete; otherwise errors may occur in the import system.
A request is not imported, but it contains an important data element. You use another request to transport a table that references this data element. Since the referenced data element does not exist in the target system, activation errors will occur when you import the second request.
The transport workflow is a generic workflow. Its ability to process the transport route configuration in TMS enables it to adapt itself to any system landscape. This means you can transport multiple requests into multiple targets, even if these targets are not located on the transport routes.
This reduces the amount of work for the transport administrator significantly. The automated nature of the workflow also reduces the likelihood of errors during transports.
You can use the transport workflow in two different ways.
• Transport workflow as a transport strategy
If you have production systems in your landscape that can only accept approved transports, we recommend that you use the transport workflow to organize and coordinate the transport process.
To do this, set Workflow-controlled transports as your transport strategy and configure the transport workflow.
When you release a transport request, the transport workflow starts automatically and the screen Create Transport Proposal appears. The requests are then released implicitly when the transport proposal is sent to the transport administrator.
• Special transport workflow (mass transports)
You can use the special transport workflow to make transports that do not follow the defined transport routes or that take place outside the normal transport schedule (part of the mass transport strategy). These transports may be corrections made in the development system that have to be transported into the production system without delay.
To use the special transport workflow, set Mass transports as your transport strategy and configure the transport workflow.
Prerequisites
• You have configured the transport workflow for your system.
• The users involved in the transport workflow have a user in the Workflow Engine system/client.
• One or more users have transport administration authorization.
Process Flow
The developer creates a transport proposal in the Transport Organizer. This proposal contains the required transport requests. The transport proposal then appears in the TMS worklist of the transport administrator. The administrator can then approve or reject the transport proposal. The transport administrator can also make changes to the transport proposal, for example change its contents and the transport target.
After a transport proposal has been approved, the TMS imports the transport requests automatically into the specified target systems. If the proposal is rejected, it is sent back to the transport proposal inbox for revision by the responsible developer. If the import is successful, the proposal is sent back to the transport proposal inbox to be confirmed by the creator of the proposal. The developer can complete the proposal by confirming it, or apply to have it transported into other systems.
We recommend that you only use the transport workflow to transport into those target systems defined by the direct transport routes. Only in the next step should you work out which are the next direct target systems, and then apply to transport into them. This is the best way to keep the transport landscape consistent and complete.
The transport administrator can also set the transport workflow so that only the direct target systems defined on the transport routes can be selected in the Create Transport Proposal step, and not the whole transport landscape. (See also Setting Direct Target Systems.)
The transport workflow writes an action log for each transport proposal. This log contains all 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 Transport Workflow (Administration).
For more information on the development team, see Transport Workflow (Development).
Transactions and Tools in the CTS
The Change and Transport System (CTS) provides you with tools for recording the changes you make to Repository objects and Customizing objects, and for distributing these changes within the system landscape. The CTS offers the team members of a software development or implementation project transactions in the SAP System and programs at the operating system level.
The Transport Organizer provides functions for creating, documenting and releasing change requests during the Customizing and development process. The Transport Organizer is designed specifically for use by the development team and the project managers of a development or implementation project.
The Transport Management System (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 tp and r3trans are programs at the operating system level. They do not usually have to be executed by the user directly since they are called automatically by the CTS. The transport tools communicate with the SAP System and the database, and export and import requests.
Functions in the Transport Organizer
You call the initial screen of the Transport Organizer with Transaction SE09 or SE10. You can also access the request overview of the Transport Organizer from all ABAP Workbench transactions by choosing Environment Transport Organizer (Requests).
The Display function lets you search for all requests that belong to the specified user and match the 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 can change this by going to the initial screen and choosing Settings Other settings.
Tasks that are not assigned to a request can no longer be created. This means that these tasks are no longer displayed as standard. If you still own tasks of this type, use the request search to display them.
The right side of the initial screen shows you cross-system information on the status of transports and repairs, and also lets you display the transport proposal inbox of the transport workflow.
You can find various tools for searching for, analyzing, and managing change requests by choosing Goto Transport Organizer tools.
Change Requests
Change requests are managed by the Transport Organizer. Changes to Repository and Customizing objects are recorded in change requests.
So that you can differentiate between global changes to the system and client-specific Customizing settings, the CTS records your changes in either a Workbench request or a Customizing request:
• Workbench Requests
When you change a Repository object of the ABAP Workbench, a query window appears in which you need to specify a Workbench request. You can only save the changes if you have assigned the object to a change request.
Workbench requests and the tasks assigned to them are normally used to record changes to Repository objects and Customizing for all clients. However, you can also include client-specific Customizing.
Whether the changes to Repository objects are transported depends on whether a transport route is defined from the current SAP System for the package of these objects. From the system settings, the system automatically determines whether the change requests are transportable and to which target system they should be transported.
• Customizing requests
Customizing requests record client-specific Customizing settings made in a single client (the source client of the request).
Automatic recording of configuration activities in the Customizing work for a client can be activated or deactivated for each client with Client Control. If automatic recording is active, a query window appears when you change Customizing settings, asking you to specify a Customizing 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 uses the standard transport layer to determine automatically whether the change requests are transportable and to which target system they should be transported. However, you can change this manually