Development Infrastructure (DI)

The usage type Development Infrastructure (DI) is also referred to as the SAP NetWeaver Development Infrastructure (NWDI). NWDI provides an infrastructure for developing Java-based applications on SAP NetWeaver and is responsible for versioning, build and the life cycle management of the applications.

You can work with NWDI using the SAP NetWeaver Developer Studio (an integrated development environment for local application development) or the NWDI Web-based administrative tools.

The SAP NetWeaver Developer Studio and the NWDI are seamlessly integrated to allow a combined approach for a local development and testing environment and centrally synchronized, team-oriented development. You can use the NWDI for custom development, modification management or pure source control.

The NWDI takes care of all parts of the development process in a project-specific way:

?     Central source file management – in the Design Time Repository (DTR), a file storage in a database with export mechanisms that allow you to synchronize the instances of the DTR in a distributed development.

?     Central build and archive management – in the Component Build Service (CBS), gives developers access to the latest archive versions in a central DB storage and a central build triggered by the developer.

?     Central landscape and transport management – in the Change Management Service (CMS), gives administrators a central service to set up development landscapes for all development tasks and manage all transport processes for these tasks in the same UI.

All the development processes in the NWDI are based on SAP's component model, which enhances the public/private concept of Java by metadata regarding the use of objects without implying any changes to the development objects themselves: a Java interfaces stays an interface, a public class stays a public class. By clearly defining the visibility of and the dependencies between objects, the component model helps you structure applications into reusable components. Development according to this model is implemented in the Developer Studio.

The applications you develop are split into software components (SCs) (the installation units) and development components (DCs) (which are exactly on the granularity of projects and contain all development objects plus the aforementioned metadata).

In addition, the development is performed in what is called a “track”. The track abstraction allows you to develop different maintenance context for the development of specific releases of your software. The track also takes care of the phases development and consolidation and all transport processes from start to finish when the application is deployed to the productive system or delivered to customers. In this way you can have better control over the development versions and the exact source development.


The following figure shows the main components of the Usage Type DI and the relationships between them throughout the development process:

CMS defines source management (DTR) and archive management (CBS) for the new development project. Usually, almost everything you develop is stored in a database. A connection to the database for the software catalog is obtained to keep a track of what is developed. There are also runtime systems for automated deployment during all project phases. They are accessed by the developers either using the Developer Studio or the workplace.

The administrator defines the development landscape for the development. All objects initially available are defined and centrally provided.

The application developers structure their applications into DCs and SCs according to the component model defined and used by the usage type DI. They develop their application objects in the local Developer Studio using the comprehensive tools provided there. Once an application’s source files are developed and tested locally, they are stored in the DTR. Sources are built by the CBS, which is provided centrally, and deployed (if the build is successful) on the central Application Server Java (AS Java).

SAP NetWeaver Developer Studio

The Developer Studio is SAP’s development environment based on the Eclipse Foundation’s Eclipse platform. With its comprehensive set of development tools and wizards, it is a robust environment for developing and running large-scale enterprise applications based on both standard (J2EE, J2SE) and SAP-proprietary (for example, Web Dynpro) Java models. From an application developers’ point of view, the Developer Studio also serves as an interface to the NWDI services to facilitate large-scale development projects.

The Developer Studio is not part of the installation of usage type DI. The NWDI is a server-side installation, which can be accessed by multiple Development Studios.

For more information about the architecture of the Developer Studio, see Concepts of the Developer Studio.

Design Time Repository

The DTR overcomes many of the limitations of file-based versioning systems for all kinds of development objects required in the Java development process. Java sources, XML files, and so on, are stored in a database, but still they are exposed to the client as files and folders, visible in the Developer Studio. The limitation we overcome is that the file version history is always transported together with the file, so that we can synchronize different DTR over repository boundaries by simple file transports.

Each file or folder has its own version history. The definition of workspaces allows you to group sets of files in a particular version for a specific purpose (for example, development, maintenance of delivered releases, and so on).

Developers access the DTR simply by checking out source files or by synchronizing files for read access to their local hard disks. After local development and testing, they check their changes in. The DTR manages distributed versions and is capable of resolving version conflicts when integrating changes from other workspaces.

For more information about the architecture of the DTR, see Architecture of the Design Time Repository.

Component Build Service

The CBS is responsible for building the sources that are stored in the DTR and is the central build environment. Unlike in other central builds, the CBS also centrally hosts and makes available the latest archives and build results for all developers. The CBS also makes the integration available on the archives level, even for those objects that are still under development. The build is component-based; if a build fails, only a component is delayed. All other components will simply use the latest valid (that is, the successfully built) version in a central build.

In contrast to the conventional build tools, the goal of the CBS is to automate the build process in an incremental fashion. That is, only the changed files, as well as files that have a dependency on them, are built instead of building all sources from scratch.

This “incremental builds” concept dramatically reduces the source code correction cycles.

In addition in CBS, dependent objects are only rebuilt if the public parts they use have been changed.

For more information about the architecture of the CBS, see Component Build Service Architecture.

Change Management Service

The CMS is responsible for transporting and setting up the logical development landscapes and then for transporting the software changes centrally to various systems or tracks within the development landscape. For more information, see Central Landscape and Transport Management.


The usage type Application Server Java (AS Java) is a prerequisite for the usage type DI.

There are usage types that also use the DI functionality:

?     Process Integration (PI)

?     Enterprise Portal (EP)

You can also use the NWDI for custom development and Web Dynpro development.

See also:

?     Component Model – for information about the different components the NWDI uses and the concepts behind the component model.

?     Administration of the Development Infrastructure

?     Working with the Development Infrastructure