Activity-Based SDA Transports 
It is not the sources of the activities themselves that are automatically added to the transport request for activity-based SDA transports, but all runtime objects (SDAs) that are possibly affected by the changed sources. You can start activity-based SDA transports directly from SAP NetWeaver Developer Studio. All runtime objects that belong to the activity are determined when an activity is released and added to the transport request. Activity-based SDA transports are transported using .DIP files (Development Infrastructure Package). The .DIP file contains the affected, deployable SDAs and a reference to the released activity.
You need a development configuration for the development system to be able to execute the activity-based SDA transport. You also need an upload system to be able to load the basis libraries and their sources delivered by SAP to your development system. A deployment takes place when transporting into the follow-on system. For this reason, follow-on systems may only be runtime system and not DI type systems.
Advantages
In contrast to activity transports, no rebuild takes place for imports. You only need the development configuration in the development system and the import time is reduced.
The consistency of the target system is ensured by transporting all dependent runtime objects automatically.
Disadvantages
No sources exist in the follow-on systems.
If you want to use this type of transport, you can configure it in the Development Infrastructure - Configuration Service.
Example landscape: Activity-Based SDA Transports
The figure shows an example transport landscape for activity-based SDA transports. The transport landscape consists of a development, a test, and a productive system and associated runtime systems. The development system is connected with the Java development environment. The Java development environment consists of SAP NetWeaver Developer Studio along with SAP NetWeaver Development Infrastructure, Design Time Repository, and Component Build Service. The CM Services belong to the Java development environment.
All runtime objects that belong to the activity are evaluated when releasing an activity in the Developer Studio. The objects are attached to a transportable .DIP file. The .DIP file is added to a transport request. You can import this into the follow-on systems in your transport landscape. At import, the runtime objects are deploed onto the runtime system.