Scenario 2+: Development with a Track 
Overview
The customer develops business applications for the SAP NetWeaver technology platform using the complete SAP NetWeaver Java Development Infrastructure (SAP NW JDI).
This scenario is based on scenarios 1 and 2. This means that developers work in a team, source code is shared using the Design Time Repository (DTR), the software is divided into components, and development configurations are used to define the developer’s viewpoint on the development infrastructure.
The
central component build is no longer based on the command line tools and
individual make scripts, but uses the 
Component Build
Service (CBS), which is part of the JDI. 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 automatized. The Change Management Service (CMS) is responsible for the transport of software within the landscape, including source code and libraries. Finally CMS supports automated deployment of executables into central test servers and productive systems.
Configuration
In this
scenario, the development
configurations take on a central meaning for the entire
process.
Configurations define the developer’s view on the JDI landscape. The
configuration identifies components, sources, libraries and services relevant
for the developer, selects the build plugins 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 define a new track. A track
is a separate production line for a certain release of a software component. A
track consists of two logical systems, which 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 a SAP NetWeaver
J2EE Engine. The CMS
automatically creates the required workspaces and buildspaces and adds the
development configuration to a directory in the SAP System Landscape
Directory (SLD).
Development Flow
As in scenario 2 a developer imports a development configuration into SAP NetWeaver Developer Studio. The Studio offers a list of available development configurations that is retrieved from the System Landscape Directory.
The developer then starts to perform changes on the so-called inactive state of the software. This state is represented by a certain workspace in the DTR. The SAP NetWeaver Developer Studio automatically retrieves libraries of used components that are needed to compile the software from the build server. Like in scenario 2 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 SAP NetWeaver 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 SAP NetWeaver J2EE engine assigned to the logical system for testing. If the tests are successful the developer releases the changes for transport.
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 (e.g. every evening, every week or every hour) a member of the system administration team uses the CMS web user interface 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 SAP J2EE Engine that acts as a test system.
After deployment and successful test a member of the quality management team approves the new software version for productive usage. Finally the new version can be deployed to productive system.
Overview of the processes in a track of the CMS
Overview of the individual parts of a complete JDI-oriented development scenario and their interactions.
