Show TOC

Components Development with the NWDILocate this document in the navigation structure

Use

This scenario describes the usage of the SAP NetWeaver Development Infrastructure (NWDI) when you develop business applications for the SAP NetWeaver technology platform based on the principles linked with the SAP's component model. In other words, you develop using development components (DCs) to wrap your development project(s). With the DC you can integrate your development inside a software component (SC) and with that ensure the smooth integration of development and transports or versioning of the software you are working on. Note that:

  • Development of DCs 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 a versioning system as a repository for their sources and artifacts. The developers divide the software into DCs following SAP's component model, and use development configurations to define the developer's view of the development infrastructure.

  • The central build process uses the Component Build Service (CBS). The CBS builds DCs 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.

  • Landscape management can be done with:

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

    • CMS can also be integrated with CTS to perform the transports with CTS

    • With CM Services integrated in CTS you can manage your Java transports without CMS. See Using CM Services.

Figure 1: 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 repository server.

  2. Configure the repository's client definitions for all instances of the SAP NetWeaver Developer Studio.

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

Prerequisites

  • The AS Java with NWDI is installed.

  • The Developer Studio is installed on every developer PC.

Development Steps

For more information, see Development Steps in Component Development with the NWDI .

Activities

The following figure is only valid for CMS. For CM Services, each development configuration represents a development system.

Figure 2: Overview of the processes in a track

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

Note

Valid if CMS is used:

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

The usual track consists of two logical systems that are connected by change propagation. The first system is used for development (DEV), the second for consolidation of the changes (CONS). Note that you can still create single system tracks that consist of a single DEV system.

Every logical system is described by a development configuration and consists of repository workspaces, its own build environment (buildspace), and AS Java.

For more information about the 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 either locally or from a central SLD server.

Once the developer import the development configuration, he or she can download locally the software to work on from the repository server. Then he or she can start to make changes to the software. The Developer Studio automatically retrieves the libraries of used DCs that are needed to compile the software from the build server. The Name Service of the SLD is used to guarantee unique naming inside the DCs.

After the changes have been checked in to the repository 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 DCs. 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

Only valid for CMS.

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 repository workspace of the consolidation system and the build server compiles the changed DCs. 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.

SAP NetWeaver Development Infrastructure Architecture

The usage type Development Infrastructure (DI) is also referred to as SAP NetWeaver Development Infrastructure (NWDI). NWDI provides an infrastructure for developing applications on the SAP NetWeaver platform and is responsible for versioning, build and 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.

  • (We recommend that you use CM Services instead of CMS for new landscapes. Use CMS only for already set up landscapes, that you do not plan to change. See Using CM Services ) 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 interface 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 have better control over the development versions and the exact source development.

Design

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

Figure 3: NWDI Architecture

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 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 application developers' point of view, the Developer Studio also serves as an interface to the NWDI services to facilitate large-scale development projects.

Note

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 Developer 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 workspace 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, see Design Time Repository Architecture .

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.

For more information, see Component Build Service Architecture .

Change Management Service

The Change Management Service (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 about CMS, see Central Landscape and Transport Management .