Development Steps in the Scenarios 2+ and 3 

The most important steps in the software development with the SAP NetWeaver Java Development Infrastructure for you as a developer in scenarios 2+ and 3 are:

...

       1.      Import of 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 development infrastructure. By importing a development configuration you get access to all resources relevant for your work without the usually tiresome search for the right sources, libraries and servers known from the more traditional environments. The SAP NetWeaver Developer Studio supports the work with development configurations in the Development Configurations  perspective. It offers different views of the components that belong to the development configuration and of the development activities under way. For more information, see Working with Development Configurations.

       2.      Selection of the components you want to develop.

       3.      In the Development Configurations perspective, you can create projects for existing components in order 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 components locally. Depending on the component type, switch to a perspective suited for editing and start with the development (see step 6).

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

The development infrastructure distinguishes between the ”active” and ”inactive” sources of a component. When you change a component and check in the changes into the repository, you have changed the “inactive” sources of the component. By releasing the changes to the build service (”activation”), the sources become ”active” provided that the service can compile the component without errors. The activation thus is the first step of the quality assurance, because the active state of a component is at least formally correct.

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

       4.      Creation of new components. You can use theDevelopment Configurations perspective also to create new components. You have these options:

                            a.      Create the new component locally. All changes to this component then only affect your local development environment and the local file system. At a later time, you can add the component to the Repository and make it available to all developers.

                            b.      Create the new component directly in the Repository. The development environment may propose a change list (“activity”) or prompt you to create a new change list to be used to record the creation of the component. Note that you need a connection to the Repository. Then you edit the component in an appropriate perspective (see 6).

       5.      Synchronization of source files and libraries.

From time to time you should resynchronize your local sources and libraries with the infrastructure to receive the most up-to-date changes of other developers. How often you do this is up to you. 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 component contains errors. Use the Development Configurations perspective to synchronize sources and libraries.

       6.      Changes of component sources.

Before you can change a source file, you must make the intended change known to the Repository (check out the file) and agree on a change list (“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 Configurations perspective to check out files (or add new files to a component), but also a number of other perspectives and views offer this option. The Design Time Repository perspective is specialized for all tasks related to the Repository.

After having checked out the required data, you can develop without a connection to the Repository 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 Repository.

The changes to your components take effect in the Repository when you release activities ("check-in"). Use the Open Activities view to see which activities you can check in at a certain point in time (“open activities“).

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

After checking them in, your changes become visible to all deverlopers who work with the sources of the respective component.

       7.      Editing components.

Depending on the type, you can develop components using the Java, J2EE, WebDynpro, Dictionary or any other suitable perspective.

Before you check in your changes, check them in a local build of the changed components. Most of the perspectives for editing components offer this function.

If possible, before you check them 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 (see step 6).

       8.      Release of changes for the central build.

After checking the changes in, you can pass them to the Component Build Service (“activation”). To do this, use the Activation View. The responsible Component Build Service will try to recompile all components affected directly or indirectly by the changes. Only if this can be done without errors, are your changes accepted and the results are made available to all developers in the same development configuration in the form of libraries or deployable archives. If the activation fails, correct the errors in a new activity and activate it together with the previous ones.

You can activate activities individually or together, 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.

       9.      Release of the changes in the development landscape.

After a successful activation, pass your changes to the Change Management Service of the development infrastructure, which transports your changes within the development landscape, for example, between a development system and a consolidation system. Use the Transportation view to release the changes. In the menu, choose Window ® Show View ® Other... ® CMS ® Transportation View.