Show TOC Start of Content Area

Background documentation Development in a Team  Locate the document in its SAP Library structure

 

The development task is usually made up of several development components (DCs) that have defined inter-dependencies and are assigned to a software component. Here, the development tasks are distributed among several developers or developer teams (multi-user development). All the projects are based on the component model and use the existing SAP development infrastructure.

Source management and versioning is performed by the DTR. Support for a central build task is available in accordance with the development scenarios.

Note

For an overview of all services, refer to SAP NetWeaver Development Infrastructure.

 

Process Flow

The development process can be split up into the following main steps:

1. Selecting the Development Configuration and Importing into the Developer Studio

So that you can use the SAP Java development infrastructure in the first place, you must first configure your local development environment accordingly. For more information, you may refer to Importing Development Configurations. The development configuration supplies your local development environment with all the necessary information for addressing infrastructure services and systems (DTR workspaces, landscape directory). In addition, a configuration contains a set of software components to which a set of DCs is assigned each.

Irrespective of whether you wish to create a new DC or edit an existing one, you must have the option of logging on to the DTR server. However, you must have the necessary authorization.

(A development configuration is, to a certain extent, comparable with an SAP development system in the ABAP development environment. Here, too, the developer must first log on to the system before being able to create his or her own development objects within a predefined package hierarchy, or before editing them or checking their status.

2. Creating a Development Component of the Web Dynpro Type

In order to implement a Web Dynpro application using the Java development infrastructure, you first require a corresponding project in the Developer Studio. The special feature of this now is that such a project is identified using exactly one development component.

In the first step, you will have an initial project framework for a Web Dynpro project generated with the help of a wizard. In this way, you receive a well-defined container for all the development objects and resources of your application.

3. Synchronizing the Archives or DCs to Be Used

It is possible that the new DC will require further DCs, which you will have to synchronize from the DTR.

4. Creating Application-Specific Objects and Implementing the Application

Starting from the generated standard DC project, you will generally create one or several Web Dynpro components and there define the visual parts of the application together with the navigation or implement the required business logic for back-end access. Furthermore, you create a Web Dynpro application to define an entry point for the Web Dynpro components that can be called externally.

5. Defining Public Parts

For each DC whose functions you make available for other DCs also, you will need to define one or several public parts. The public parts can then be referenced by other DCs.

5*. Declaring Usage Dependency

Conversely, should you use the functions of another DC in your DC, you must declare a usage dependency for the used DC. 

6. Building Sources Locally

Before your DC is built centrally, you should first locally execute a build for all the project changes. As a result, no compiling errors should be issued.

7. Deploying and Testing the Application in a Local Environment

To start a Web Dynpro application in your local environment, you must first create the respective archive and deploy it on the J2EE server.

8. Checking the Activity into the DTR

To update all (changed) project sources in the DTR server, you now only need to check in the assigned open activities.

9. Activating the Changes

Activation is only possible if the CBS can be used for the underlying development configuration (depending on the development scenario). Activation means that the relevant DCs are centrally built by the CBS.

10. Releasing the Activities

When you release the activities, the CMS (Change Management System) transports the changes to another system (for example, a consolidation system). This step requires that the CBS and the CMS can be used for the underlying development configuration.

 

 

 

End of Content Area