Releasing the Software to the Transport System 

Use

Once you have successfully finished your development, you have to trigger the transport of these changes into the transport system predefined by the administrator. The transport system is defined by the development configuration under which you are working, and this does not affect the steps that you take to trigger this transport.

Prerequisites

You work in the Transport view of the SAP NetWeaver Developer Studio.

Procedure

...

1. Check in your changes to the DTR

       1.      Navigate to the activity that describes your changes in the Open Activities view.

       2.      From the activity’s context menu, choose Checkin.

       3.      Confirm the activity’s description with choosing the OK pushbutton.

The activity is now moved to the Activation view.

2. Activate the activities

Activating your changes means that you send them for central build. If your changes registered inside the activity are successfully built by the central build system, they are moved from the inactive to the active state inside the DTR. This means that they become available to all other developers who are using the same DTR server.

...

       1.      Navigate to your activity in the Activation view.

       2.      From the activity’s context menu, choose Activate.

The Activation dialog appears

       3.      (Optional) To activate the activities together with all its predeceasing activities, choose the Calculate predecessor activities based ONLY on overlapping files checkbox.

Predecessor activities are activities that have been checked in before the selected activities, but are not yet activated. They can be of the following types:

■       Predecessors based ONLY on overlapping files (file predecessors) are activities, which contain the same files as in selected activities.

■       Predecessors based on involved Development Components (DC predecessors) are activities, which contain files from the same DCs as in selected activities. This includes all activities of type 1.

Choosing type 2 (deselected checkbox) increases the likelihood of the DCs involved being successfully activated, since all DC predecessors are considered. Therefore the probability of semantic (that is, non compile time) errors are reduced. Note that predecessors may also be from other users.

If the Activate or Activate with all Predecessors button is chosen, all displayed activities (calculated depending on the state of checkbox) will be used for activation. After activation, either all displayed activities are active or (if activation fails) none of them.

       4.      (Optional) If  you know that your activities will not be successfully built, but still for some reason you want the changes to be activated, choose the Advanced pushbutton and activate Activate even if build fails checkbox. In the dialog that appears, choose OK.

       5.      Choose Activate pushbutton and complete the dialog.

Your activation request is now sent for build and you can monitor the build status in the Activation Requests view.

3. Release for transport

The steps below are for releasing changes to the Change and Transport System (CTS) of AS ABAP using CM Services. For CMS use case the steps are the same but in step 3 there will not be a CTS Transport Page tab because the activities are always released as new Change Request to CMS.

Once the development has reached a phase in which it makes sense to send the changes to the central transport system, you can release the activities for transport using the Transport view.

...

       1.      Navigate to your activity in the Transport View tab page.

The activity should be located under the Waiting flag.

       2.      From the activity’s context menu, choose Release.

The Release for Transport dialog appears.

       3.      The activities selected for release and also all predecessor activities are displayed. For activity-based SDA transport you can see also all SDAs that will be exported during release.

Depending on how the development configuration is configured in the configuration, the behavior varies when you release an activity in the Developer Studio and attach it to the transport request. There are two options:

○       Activity-based SDA transport: the system calculates all dependent runtime objects and includes them in the transport request. Only the runtime objects and a pointer to the activity are transported. Deployment takes place in the target system.

○       Pure activity transport: only the changed sources are included in the transport request. Sources need to be rebuilt in the target system.

You can display additional information about each activity’s details in the Properties view.

In the CTS Transport tab page you see the transport request details. In case you want to change the retrieved transport request, select the Create/Select pushbutton, which will bring you to the Transport Organizer Web UI. Here you can create a new transport request or set an other transport request as preselected.

If you activate the Monitor Request checkbox, you will be able to monitor your request in the Transport Organizer Web UI inside a Web browser after the release. If you do not activate this option, the activities simply will be released to the transport system and there will not be any additional popups. Note that the state of this check button is persisted, that is, your choice here is preserved for future sessions.

       4.      Choose Release.

The release process starts. Depending on the development configuration’s type, the Developer Studio connects to the corresponding transport system and sends the changes for release. During release, a DI package with the extension .DIP is created and attached to the TMS transport request.

For more Information about CM Services, see Using Change Management Services.

For more information about the transports in the Developer Studio, see Transport View.