Introduction
A transport request is a package that is used to collect developed objects and move them from one SAP system to another. It is not encouraged to implement newly created objects directly in the production environment to prevent risk factors like loss of data, data flow changes etc., and hence transport request is used. The required developed objects are included in the transport request and transported from development systems to many testing systems (like Quality Assurance, Regression, Pre-Production), tested and finally moved to Production. So initially the required object(s) is included in the transport request and released from the source system then it is imported in the target system.
Including a BW object into a transport request
There are many ways to include a BW Object in a request of which one is shown here. Call T-Code RSA1 in the Source system (here DEV) > Transport Connection functional area > Search for the object that needs to be transported and drag/drop it on the right side of the screen as shown in Figure 1. Consistent requests that take object dependencies into consideration are especially important in BI because the metadata objects are activated in the import post processing step. If dependent objects are missing in the transport request, this results in errors during activation. These dependencies are mapped to the grouping modes when the objects are collected.
Figure 1
Grouping Mode
Only Necessary Objects:
Only those objects that are really required for the action (copying or transporting the selected objects) are taken into account (minimal selection).
In Data Flow Before:
The objects that pass data to a collected object are collected. For an InfoCube, for example, all the objects those are in the data flow before the InfoCube, and are therefore necessary for providing data to the InfoCube, are collected. This includes transformation rules and InfoSources, for example.
In Data Flow Afterwards:
The objects that get their data from a collected object are collected. For an InfoCube, for example, all the objects that are in the data flow after the InfoCube, and are therefore reporting objects that display the data stored in the InfoCube, are collected. This includes queries and Web templates, for example.
In Data Flow Before and Afterwards:
All objects that provide or pass on data are collected. For example, if you are using an InfoCube, the objects required to activate the InfoCube are collected together with other objects that are required to activate those objects as well. This includes objects positioned both before and after the InfoCube in the data flow.
Save for System Copy:
This setting is used when a source system needs to be copied and renamed. Hence having to re-create objects for both SAP systems and BI systems and be avoided.
Collection Mode
Collect Automatically (default setting): The data is collected as soon as the objects are selected.
Start Manual Collection: The data is not collected until you choose 
Collect Dependent Objects.
Collect Dependent Objects.
Once Grouping and Collection modes are selected, click on 
symbol to create a transport request (see Figure 2), select the Package name (Specific for a project, get it from the Basis Team) and save. Request ID is generated as SIDKXXXXXX, (SID-System ID). By default all the objects are included in the package $TMP.
symbol to create a transport request (see Figure 2), select the Package name (Specific for a project, get it from the Basis Team) and save. Request ID is generated as SIDKXXXXXX, (SID-System ID). By default all the objects are included in the package $TMP. 
Figure 2
Release a transport request
Use: Initially the request will be in Modifiable state, it should be released from the development system to move it into further systems.
Procedure
Call T-Code SE01/SE09 in the source system (here DEV) > Enter the transport request, release the task (here DEVK123452) and then the main transport (here DEVK123456) as shown in Figure 3.
Figure 3
To release a request Click on 
Release directly. As soon as the transport request is released, it should be available in the Import Queue of the target system (here testing system). Make sure that the connection exists between these two systems.
Release directly. As soon as the transport request is released, it should be available in the Import Queue of the target system (here testing system). Make sure that the connection exists between these two systems.
Import queue
Use: The import queue displays all transport requests flagged for import for a particular SAP System.
Procedure
To check the Import queue Call T-Code STMS in the target system (here TST). It will take you to the TMS screen shown in Figure 4. Now click on 
symbol, it will take you to Import Overview (Figure 5) where all the systems defined can be seen. Double click on target system (here testing system) to check the import queue.
symbol, it will take you to Import Overview (Figure 5) where all the systems defined can be seen. Double click on target system (here testing system) to check the import queue.
Import queue is shown in Figure 6, where
Number- Serial number
Request- Transport request
Clt- Client ID
RC-Return Code (Explained in further section)
Owner- Developer name
Project- Project ID
Short Text- Description of the transport request
For performance reasons, the data required in the queue is read from the transport directory the first time the TMS is called. After that, information buffered in the database is always shown. To refresh the buffered information, choose Edit > Refresh (F5). Sometimes even after refreshing the queue 
appears next to the transport request as shown in Figure 7. Click on 
(Adjust Import Queue) and choose ‘Yes’ (Figure 8). Here TMS transfers the data files and co-files belonging to this project and confirms the transfer in the import queue. Now the transport request is ready to be imported into the target system.
appears next to the transport request as shown in Figure 7. Click on 
(Adjust Import Queue) and choose ‘Yes’ (Figure 8). Here TMS transfers the data files and co-files belonging to this project and confirms the transfer in the import queue. Now the transport request is ready to be imported into the target system.
Importing requests
Before you import the requests from an import queue into an SAP System, ensure that no users are importing other objects in this SAP System because only one transport request can be imported at a particular instant of time. If multiple transports are imported simultaneously then the transports are imported only one after the other i.e. in parallel. There are three ways to import the request.
a) Starting the Import for Individual Requests (Single Transport Strategy)
The TMS allows importing individual requests from the import queue. The requests you choose are imported in the order in which they are placed in the import queue. Select the Transport request and click on Transport Request as shown in figure 5. The screen displayed (Figure 9) helps you in choosing the options to import the transport request which is explained below.
Starting an Import: Date Tab
All the options for starting an import in TMS are listed here.
Figure 9
The options you have depend on which import type you have chosen (project or individual import, import all requests, transport workflow).
1. Immediate: If you want the import to start immediately in a dialog, choose Immediate.
2. At start time: If you want the import to start at a later time, choose this option. The import is scheduled as a background job in the target system. If you enter a date and time in the field No start after, the import is started in the time frame between Planned start and No start after. If there is no background process available in this window, the import will not happen. If you want the import to be performed regularly, you must choose a period in the field Period. The Period option does not exist for single transports and the transport workflow.
3. After event: If you want the import to start only after an event is triggered, choose this option. If you choose the option Execute import periodically, the import is started each time the specified event is triggered. Otherwise, the import is started only when the event is triggered the first time. The Execute import periodically option does not exist for single transports and the transport workflow.
Starting an Import: Execution Tab
On the tab page Execution, you can specify how you want the transport control program tp to start:
1. Synchronously: If you want the dialog or background process to wait until the import has been completely performed by tp, choose this option (figure 10). It is useful, for example, if subsequent actions are to be performed in the system after the import. If you schedule the import to run synchronously in the background, the background job, which performs the subsequent actions, can wait until the end of the import. A dialog process or background process is blocked until the import has ended.
2. Asynchronously: If you want to release the dialog or background process after the transport control program has been started, choose this option (figure 11). It is useful if there are a lot of requests waiting for import, which would make the import take a long time. After tp has been started by the dialog or background process on the operating system level, the SAP process ends and tp imports the requests.
The option Asynchronously is the default setting for importing projects or importing all the requests in an import queue. However, the option Synchronous is the default setting for importing single requests. For other import types, it is always asynchronous.
Starting an Import: Options Tab
All the options for starting an import in TMS are listed here (Figure 12). The options you choose depend on which import type you have chosen (project or individual import, import all requests, transport workflow).
Figure 12
1. Leave transport request in queue for later import: This causes these requests to be imported again in the correct order with the next import of all the requests. This option is useful if you have to make preliminary imports for individual requests. This prevents older objects from being imported at the next regular import of all the requests.
2. Import transport requests again: The transport control program also imports the transport request if it already has been completely imported.
3. Overwrite originals: The transport control program also imports objects if the objects are the originals in the target system. The object directory entry determines the SAP System where the original version of an object is located.
4. Overwrite objects in unconfirmed repairs: The transport control program also imports objects if they were repaired in the target system and the repair is not yet confirmed.
5. Ignore unpermitted transport type: The transport control program imports the transport request if this transport type was excluded by particular settings in the transport profile.
6. Ignore predecessor relations: You can choose this option if you want to import all the requests for one or several projects, but additional requests from other projects exist for which there are dependencies. This option is switched off by default, which means the predecessor's relationships are checked before the import. The import only occurs if the predecessor's relationships will not be damaged.
Here in our case, we select only the option Ignore predecessor relations and proceed.
b) Starting the Import of All Requests in an Import Queue
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
c) Starting the Import of All Requests in One or More Projects
If you have assigned your transport requests to project, 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.
Import History and Return Codes
Import History
Use: In the import history, all the requests imported into a particular system for a specific time interval, and their maximum return codes are displayed.
Procedure:
To check the import history, Go to Import Queue > Click on 
(Import History).
(Import History).
Return Codes
Use: To check whether a transport request has been successful imported, the return codes (Figure 13) are generated by the programs used for the transport.
Procedure:
Click on 
(Import History) in the Import Queue Screen. Return code for a particular request can be seen next to it.
(Import History) in the Import Queue Screen. Return code for a particular request can be seen next to it.
Figure 13
Re-import a transport request
Use: Sometimes there exists a situation where the transport request needs re-import. So the transport request should be moved from history to the import queue.
Procedure
Go to History > Extras > Other Requests > Add.
Enter the transport request needs re-import, Target Client and check the Import again as shown in Figure 14 and Figure 15.
Now the transport request will be ready in the import queue for importing again. Select the request and click on 
Transport Request > Now select required options in Date and Execution Tab. In Options tab you need to select the below options (Figure 16) because the request needs re-import. The use of each option is same as explained in previous section.
Transport Request > Now select required options in Date and Execution Tab. In Options tab you need to select the below options (Figure 16) because the request needs re-import. The use of each option is same as explained in previous section.
Figure 16
Delete a transport request from the Import Queue
Use: In exceptional cases, you may have to delete a transport request from the import queue so that the request is not imported into the target system. If you delete change requests from the import queue, inconsistencies may occur during the next import due to shared objects. Suppose you delete request 1 containing a data element which is not imported. In request 2, you transport a table that references this data element. Since the referenced data element does not exist in the target system, there is an Activation error when request 2 is imported.
Procedure
To Delete a Request from the queue > Select the transport request (F9) > Request (Menu) >Delete
Updating the Import Overview and the Import Queues
Use: You can refresh the display of the import overview and individual import queues. However, it is more convenient to update the import queues periodically in the background.
Procedure
To update import queues in the background > Enter transaction STMS > Choose The Import Overview appears > Choose Extras > Update all import queues. The dialog box Update All Import Queues in Background appears. > Choose the correct option (from Immediate, At start time, Period) and enter the required data. Use input help to select a period > Choose Continue.
Schedule a periodic update of the import queues, at least in the SAP System where you use TMS the most (default period Daily is recommended).