Components Development with the NWDI 

Use

You develop business applications for the SAP NetWeaver technology platform using the full-featured SAP NetWeaver Development Infrastructure (NWDI).

●      Development of components with the NWDI is based on the developing projects with central source file storage. This means that the developers work in a team, share source code using the Design Time Repository (DTR), divide the software into components following the SAP component model, and use development configurations to define the developer’s view of the development infrastructure.

●      The central build process here uses the Component Build Service (CBS). The CBS builds components and their dependants on demand and provides ready-to-use libraries and deployables for developers and runtime systems. The process of the software change management is automated. The Change Management Service (CMS) is responsible for transporting the software within the landscape, including the source code and libraries. Finally, CMS supports automated deployment of executables into central test servers and productive systems.

Overview of the individual parts of a complete NWDI-oriented development scenario and their interactions

You now define the development landscape as described in the SLD and in the Landscape Configurator of the CMS. The build process is executed centrally in the CBS. The Transport Studio of the CMS takes the place of the manual or automated processes in the change management.

Configuration Steps

To configure the development with a central storage for the source files, you have to:

...

       1.      Configure the DTR server.

                            a.      Configure the user management system and create the users and authorizations.

                            b.      Create workspaces in the DTR.

       2.      Configure DTR client definitions for all instances of the Developer Studio.

       3.      (Optional) Implement manual or automated processes for change management.

Development Steps

More information about the steps you have to take: Development Steps in Component Development with the NWDI.

Prerequisites

●      An AS Java with NWDI is installed.

●      The Developer Studio is installed on every developer PC.

Activities

Overview of the processes in a track of the CMS

Defining the Development Landscape

The development configurations take on a central meaning for the entire process. Development configurations define the developer’s view of the NWDI landscape. The configuration identifies components, sources, libraries and services relevant for the developer, selects the build plug-ins needed for translation and assembly of components, configures the build service and defines the overall development process for a certain piece of software.

When a development project is started, the landscape administrator initially uses the CMS to create a new track.

A track is a separate production line for a certain release of a software component. The track consists of two logical systems that are connected by change propagation. The first system is used for development, the second for testing. Every logical system is described by a development configuration and consists of DTR workspaces, its own build environment (buildspace) and an AS Java. The CMS automatically creates the required workspaces and buildspaces and adds the development configuration to a directory in the System Landscape Directory (SLD).

Development

The developer imports a development configuration into the Developer Studio. The Studio offers a list of available development configurations that is retrieved from the SLD.

Then you start to perform changes on the inactive stateof the software. This state is represented by a certain workspace in the DTR. The Developer Studio automatically retrieves libraries of used components that are needed to compile the software from the build server. The Name Service is used to guarantee unique naming.

After the changes have been checked in and tested successfully, the developer activates these changes. Sending a build request from the Developer Studio to the CBS triggers activation. The CBS tries to build the changed components. If the build succeeds, the changes are integrated into another workspace that contains the active state of the software. Following this process the active workspace always contains sources that have been successfully built by the CBS.

In parallel, new archives created by the build server can be automatically deployed to the AS Java assigned to the logical system for testing. If the tests are successful, the developer releases the changes for transport.

Consolidation

The CMS processes release requests by adding the changes to the import queue of the consolidation system of the track. At a certain point in time (for example every evening, every week or every hour) a system administrator uses the CMS to import the queued changes into the consolidation system. During this step, the changed sources are integrated into the DTR workspace of the consolidation system and the build server compiles the changed components. After the import into the consolidation system, the archives created by the build server are assembled to a new version of the software, which then waits for the deployment into the AS Java that acts as a test system.

Release

After deployment and successful testing, a member of the quality management team approves the new software version for productive usage. Finally the new version can be deployed to the productive system.