Development Steps in Component Development with the NWDI

Use

These are the steps you take when developing software with the SAP NetWeaver Development Infrastructure (NWDI) based on the SAP component model:

Create from scratch or import an existing development configuration.

The first step for you as a developer is to create or import an appropriate development configuration. The development configuration is your connection to the NWDI. By importing a development configuration, you get access to all resources relevant for your work without having to search for the right sources, libraries and servers. The SAP NetWeaver Developer Studio supports the work with development configurations in the Development Infrastructure perspective. It offers different views of the development components (DCs) that belong to your development configuration and of the development activities under way.
Create or select the software component (SC) for development.

You have to either create a new one or select an existing SC in which you will perform the development. The SC is the unit that will be used from the development infrastructure for software logistics of your software.
Create or select the DCs you want to develop.

In the Development Infrastructure perspective, you can create projects for existing DCs to add them to your development list. The development environment automatically loads the required source files and archives into your local file system and tries to build the selected DCs locally. Depending on the DC type, switch to a perspective suited for editing and start with the development.

The Development Infrastructure perspective additionally allows you to load the sources of a used DC instead of the libraries (provided that this DC is built by the build service of your development configuration). This is an advantage if you are troubleshooting or testing locally.

Note
The NWDI distinguishes between the active and inactive sources of a DC. When you change a DC and check in the changes into the repository, you have changed the inactive sources of the DC. By releasing the changes to the build service ( activation ), the sources become active if the service can compile the DC successfully. The activation is thus the first step of the quality assurance process, because the active state of a DC is at least compliable.

Note that it is not possible to work simultaneously with the inactive and the active sources of a DC.

You can use the Development Infrastructure perspective also to create new DCs.

You have these options:
- Create the new DC locally. All changes to this DC then only affect your local development environment and the local file system. At a later time, you can add the DC to the DTR and make it available to all developers.
- Create the new DC directly in the DTR. The development environment may propose a change list ( activity ) or prompt you to create a new activity to be used to record the creation of the DC. Note that you need to have a connection to the DTR first. Then you edit the DC in an appropriate perspective.
Synchronize the source files and libraries.

From time to time, you should resynchronize your local sources and libraries with the DTR to receive the most up-to-date changes of other developers. You have to decide how often to do that. This allows you to become independent of the general development for a certain period of time, for example, if the commonly available state of a DC contains errors. You use the Development Infrastructure perspective to synchronize sources and libraries.
Edit DCs.

Depending on the type of the DC you develop, you can perform component development using the suitable perspective.

If possible, before you check the changes in, test your changes in a local runtime system or using the test tools of the development environment. For large applications, local tests are often not possible. To be able to deploy your changes to a central test system, you must first activate them.

It is possible that different developers have checked out and are working on one and same file at the same time. When you decide to check the files in back to the DTR, one of these developers will manage to submit his or her version of the file before the other developer. This means you will have conflicting versions of these files.
Perform local build and testing of the DCs.

Build your changes locally to test and analyze the source behavior before testing it centrally.
(Optional) Release the changes for the central build.

After checking the changes in, you can pass them to the Component Build Service (CBS), that is, you perform the activation process. The responsible CBS will attempt to recompile all DCs affected directly or indirectly by the changes. Only if this is done successfully are your changes accepted and the results made available to all developers who are using the same development configuration in the form of libraries or deployable archives. If the activation process fails, then you should correct the errors in a new activity and activate it together with the previous activity.

You can activate the activities individually or in a group, if the changes are logically related. Note that the activation of a change to a particular source file takes for granted that possible earlier changes of the same file have been activated before or are activated together with the new change.
(Optional) Release the changes in the development landscape.

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. Note that what you see in the Transport view upon release depends on the way the administrator has set up the development configuration. The type of the transport (activity or DC) and the transport system (CMS or CM Services - CTS) is set upon the creation of the development configuration. You either see only activities or also the deployable DCs that are possibly changed by these activities.

There are different types of development configurations from this point of view:
- For pure AS Java landscapes, you can use the development configurations that were created during the creation of the track inside the CMS of the NWDI,
- For system landscapes that consists of AS Java and AS ABAP CTS can be used for transports. Depending on whether you use CMS with CTS or CM Services the development configurations can either be managed by CMS or CM Services
The origin of the development configuration affects only the tool that the administrator of the landscape can use to manage the different landscape system, but does not affect the way you as a developer transport your software. That is, you do not need to worry about the origin of the development configuration. All you have to do is to trigger the transport in the Developer Studio Transport view.

After you successfully activate your activities, pass your changes to the corresponding transport system, which will transport your changes within the development landscape, for example, between a development system and a consolidation system.
(Optional) Should be used only when working with a local development configuration created in the Developer Studio

Export the software directly from the Developer Studio.

You can export the developed software directly from the Developer Studio in SCA files.
(Optional) Should be used only when working with a local development configuration created in the Developer Studio.

Release the SCAs to the enhanced CTS.

You can attach the SCA from step 9 to a transport request to be transported through an application landscape in the enhanced CTS.