Show TOC Start of Content Area

Background documentation Components Development with the NWDI  Locate the document in its SAP Library structure

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’s 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 Transport Management System (TMS) is responsible for transporting the software within the landscape, including the source code and libraries. Note that CM Services support automated deployment.

 

This graphic is explained in the accompanying text

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

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: Development Steps in Component Development with the NWDI.

Prerequisites

      The AS Java with NWDI is installed.

      The Developer Studio is installed on every developer PC.

Activities

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 Development Configuration Service to create a new development configuration while creating the non-ABAP system of type DI in TMS.

The landscape can consist of an arbitrary number of systems. For more information, see Transport Management System (BC-CTS-TMS). A development configuration is created for each non-ABAP system of type DI. It consists of DTR workspaces, its own build environment (buildspace). In addition, an AS Java can be named as the deploy target. The CM Services automatically create the required workspaces and buildspaces and publish the development configuration in the System Landscape Directory (SLD).

For more information about development configurations, see Development Configurations.

Development

The developer imports a development configuration into the Developer Studio. The Developer 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 that is assigned to the non-ABAP system. After successful testing on the central development runtime system, the developer releases the changes for transport.

Transport

Once the transport request is released, the import into the central quality assurance system and after that into the productive system can be executed in the TMS.

End of Content Area