Development Infrastructure (DI) Architecture 

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

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

Design

The following figure shows the main components of the NWDI and:

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 NWDI. They develop the application objects in the local Developer Studio. 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 (Java EE, J2EE) and SAP-proprietary (for example, Web Dynpro) 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.

Design Time Repository

The DTR overcomes many of the limitations of file-based versioning systems for all kinds of development objects required in the 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. DTR 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.

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

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 old versions of NWDI landscapes.

Integration

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

You can use NWDI for example for Java custom development or to modify SAP-delivered components.

In heterogeneous SAP system landscapes, you can manage your transports also with the CTS of Application Server ABAP. For more information on what to use in which scenario, see Organizing the Transports in the Landscape.