Show TOC

Development Using Optional Development InfrastructureLocate this document in the navigation structure


Component Based Development with Optional Infrastructure

The following documentation describes the recommended way to organize the development processes that you should follow to be able to integrate external tools into your development process, or if you plan later on to integrate to and work with the full SAP NetWeaver Development Infrastructure (NWDI) support. At the same time, the two perspectives that are provided with the SAP NetWeaver Developer Studio for working with NWDI (the Design Time Repository and the Development Infrastructure perspectives) can be also used in your system and in this way ease your work process.

Why is all this important?

This development scenario is applicable if you have already bought or prefer to work with a certain third party development infrastructure tool. For example, you can have a versioning system that you want to use instead of sticking to the one proposed by SAP's Design Time Repository (DTR) server, or if your development is based on the local file system and you do not want to use versioning system at all. Organizing your development in the process that is described in the following topics allows you to benefit from the best practices we have for efficiently organizing the development components. If you follow these recommendations, you should be able to plug your development into other SAP systems (and the full-blown NWDI) later on without much effort or problems.

The Developer Studio provides a command line tool, which provides some of the functionality of a full-blown NWDI system.

This development scenario provides the following benefits:

  • Faster development start. The development can start immediately without having to set up an infrastructure first.

  • Small development teams may actually not need the complete Software Change Management environment as it is provided with NWDI.

The constraints are:

  • Since today there is no commonly accepted standard for development life cycle management systems, it is not possible to leverage the same level of integration and convenience to developers as with NWDI. Compared with the NWDI landscape, this development scenario has certain limitations. For example, it is impossible to anticipate the concrete set of development life cycle tools and processes at customer site, and to provide a tight integration with all of them (and in all possible combinations).

  • You have to integrate the SAP NetWeaver technology with your own development tools and processes.

    In this section, you will find a description of the specifics of this type of development, plus recommendations how to organise the entire development infrastructure to ease your development processes. In addition this might be helpful if you later on decide to switch back to DTR.


The configuration comprises in setting up the development and production landscape. For the development itself the Developer Studio is used, which means that certain configurations to the perspectives and the underlying infrastructure must be performed.

Development Steps

The development starts with normal development projects wrapped in DCs. Then you build the DCs, and if the build is successful you group them into DC archives. The DC archives are packed in the software component (SC) and out of the SCs you have, you generate an SCA file that you can distribute to your customers:

Production Life-Cycle


For the development itself, you use the Developer Studio. Since the Developer Studio is based on the Eclipse open-source development platform, you can add additional plug-ins and in this way integrate third party technologies. You choose the processes and the tools you use to cope with sharing of source and libraries within a development team, change management and versioning, central build, transport, testing, deployment and so on.

This figure provides information on the big picture of this scenario:

  1. Defining the development environment - development configurations.

    If you are going to provide software to SAP's customers, they might expect objects that are tailored to meet the requirements of their SAP NetWeaver runtime systems and make use of the different SAP's project types. Many of these need the component model and development configurations. You can create development configurations locally yourself without the central systems. This enables you to use the Developer Studio in combination with your existing development infrastructure tools and processes whilst building applications with SAP NetWeaver.

    You can use a development configuration on a single PC to create component based applications for SAP NetWeaver. More probably, however, you will work in a team. All you need to do is distribute the development configuration to your team and to use the file system to exchange data.

  2. Sharing development objects in the file system.

    Working together requires at least a file share for team members. The next step is to put the development sources and artifacts under version control using any tool you like, for example CVS, or see SAP's approach to file versioning the DTR (with versioning mechanisms that allow modification scenarios), which can be used independently of the NWDI.

  3. Setting up a central build process.

    Anything you produce in the Developer Studio (including the development components), you can build in there. However, if you are working in a team producing components that depend on each other, you will need to have a complete selection of all objects - source files and artifacts - available for building the complete application. For this purpose, SAP delivers a command line tool to deal with the build centrally in the file system - the DC command line tool.

  4. Shipping the software - creating software components.

    Once all components of an application have been created and tested, you need a format to deliver and install the application - exactly the one we started with when we created a development configuration. We produce one or more SC archives or SCA-files. These are the units of delivery, installation, and upgrade. The tool to produce these units is again the DC command line tool.

  5. Organizing the next steps - maintenance and enhancement of applications.

    SCA files can also be reused in the next development configuration. You can either use SCA files to create the next version of the software whilst continuing with development, or set up a development configuration for maintenance purposes, or you can even use the new SC as a basic layer for other functions created on top of it - in this case it will become a required SC in the new configuration.

In the following sections, you will find more information that is relevant to the use of the external development infrastructure. Since we cannot assume exactly what you will decide to use as the development infrastructure, we are offering as much information and as many recommendations here as we can about how to set up your system. This information is only an overview of what SAP provides and it is up to you to manage the integration of the external development infrastructure successfully and without errors.