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