Development Steps in Component Development with the NWDI 

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

...

       1.      Import a development configuration.

The first step for you as a developer is to 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.

       2.      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 (see step 6).

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.

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.

       3.      Create new DCs. 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.

       4.      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.

       5.      Change the DC sources.

Before you can change a source file, you must make the intended change known to the DTR (to check out the file) and agree on an activity to record the change. You can create a new activity or use an existing one.

Try to assign logically related changes to the same activity. This facilitates the release and tracking of the changes in the development landscape.

You can use the Development Infrastructure perspective to check out files (or add new files to a DC), but a number of other perspectives and views also offer this option. The Design Time Repository perspective is the specialized perspective for all tasks related to the DTR.

After having checked out the required data, you can develop without a connection to the DTR  or to a network. You need to connect to the infrastructure only to resynchronize your development objects or to check your changes back in to the DTR.

The changes to your DCs take effect in the DTR when you release the activities, that is, when you check them in. You can use the Open Activities view to see which activities you can check in at a certain point in time, that is, you see the open activities.

You can check in your activities at any time, either individually or in a group of activities. Make sure you release logically related changes together, as otherwise you may provoke inconsistent DCs or DCs that contain errors. If, for example, you change an interface and extend the user of this interface accordingly, you should check in both these changes together, otherwise your DC may no longer be buildable.

After checking them in to the DTR, your changes become visible to all developers who work with the sources of the respective DC.

       6.      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.

       7.      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 activationprocess. 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.

       8.      Release the changes in the development landscape.

After a successful activation, pass your changes to the Change Management Service (CMS) of the NWDI, which transports your changes within the development landscape, for example, between a development system and a consolidation system.