Importing Requests
You can use three different methods in the TMS import queue to import requests into the target system. You can choose between performing any of the three methods in dialog, or in the background. The best method for you depends on your system landscape and your transport strategy. In practice, you will find that a combination of these methods is the most effective way of working with the TMS.
If you only want to import individual requests or projects into a system, you can change the transport strategy.
Before you import the requests from an import queue into an SAP System, ensure that no users are working in this SAP System. Therefore, inform your users about the import times early on, for example by creating a system message.
To prevent change requests from still being placed in the import queue shortly before the mass import, and perhaps being imported unintentionally, we recommend closing the import queue before the import.
Also read the notes on Precautionary Measures in the Target System.
Starting the Import of All Requests in an Import Queue (Mass Transport Strategy)
When you import all the requests from an import queue, they are imported in the order in which they are placed in the queue. Each import step is performed for all requests. First, all the Dictionary objects in the requests are imported, then all the Dictionary objects are activated, and then the main import is performed for all requests.
If you use this method to export all your requests from your development system into your quality assurance and production systems, then you are assured of keeping the Customizing and Workbench objects in your systems synchronized. However, this method is less suitable if you develop in different projects at the same time, test them in the QA system, and then import the projects into your production system at different times. This applies especially to the production system.
Starting the Import of All Requests in One or More Projects
If you have assigned your transport requests to projects (see Using Projects to Control Transports), you can import all requests that belong to a single project together. The requests are imported in the order in which they are placed in the import queue. This also applies if you want to import all the requests from multiple projects together. All the requests in one project are not imported first, followed by all the requests in the next project. Instead they are imported in the order in which they are placed in the import queue. Each import step is performed for all requests, just like when you import all requests from a queue. First, all the Dictionary objects in the requests are imported, then all the Dictionary objects are activated, and then the main import is performed for all requests.
Starting the Import for Individual Requests (Single Transport Strategy)
As well has having the option of importing all requests in the import queue, or all requests in a project, the TMS also allows you to import individual requests from the import queue. The requests you choose are imported in the order in which they are placed in the import queue.
The order of the import steps corresponds to an import of all requests.
Importing single requests can either be
- an exception, if you usually use mass transports
- or the rule if you usually use single transports.
Examples for using single transports:
- Every week, you import changes into your production system that you have previously tested in your QA system. To do this, you have scheduled an import that periodically imports all waiting requests. If you want to correct an error in the production system between these import times, you can import the request into your quality assurance and production system at an earlier time. As standard, the TMS imports a request of this type as a preliminary transport. This means that it stays in the import queue after it has been imported, and is imported again in the next scheduled import of all requests, to avoid inconsistencies.
In this scenario you can also use the Transport Workflow.
Developers make the transports into a test system. Developers have the authorization to import their own requests. Since only individual transports are made into the system in this case, the system administrator sets the system so that the requests do not remain in the import queue after the import (see Starting the Import for Single Requests).
To find out about the requirements you need to meet, we recommend that you read the following information:
Test Imports
Before you start or schedule any of the import methods discussed above, you can test them with a test import. This lets you recognize any conflicts with original objects and repairs.