!--a11y-->
Scenario 2: Development with
ComponentsThis
scenario is based on
scenario 1, but in
this case the customer has decided to also use the SAP
component
model.
This
scenario supports the development of all
types of development
components in the SAP NetWeaver Developer Studio.

We recommend this scenario only for demo scenarios, in which you want to test the development with the component model. SAP does not offer a spezial migration step in scenarios 2+ and 3. A migration into these scenarios at a later time must be done manually.
The installation uses the SAP NetWeaver platform.
· The work in the development team is synchronized by the shared storage of the source files in the Design Time Repository.
· At the beginning of the development phase, a development configuration is created centrally and shared with all developers.
· The development itself is divided into components, according to the SAP component model.
· The command line tool supports the creation of a central build process.
Like in scenario 1 every developer has a SAP NetWeaver Developer Studio and a SAP J2EE engine installed locally and uses the DTR as the central source code management system. However, by using components, developers now are able to break up their code systematically into smaller reusable pieces that are easier to handle and maintain. Components may use each other in a well-defined way, encapsulating and protecting their implementation and leveraging their functionality as a set of public interfaces. Developers in this scenario create development components instead of plain Eclipse projects.
In addition, the SAP NetWeaver Developer Studio automatically configures, for example, access to the DTR by importing a development configuration.
A
special components
build
is available in the SAP NetWeaver
Developer Studio that builds components based on their type and technology. In
the build process, the system searches for unresolved relations and checks
whether the
public parts of
the component are used correctly.
In addition to the tasks of scenario 2, an administrator is now also responsible for creating and distributing the development configurations. Configurations can easily be created with a web-based self-service.
Component builds can easily be integrated with a script-based, automated central make environment. For that a command line tool is provided that allows replicating the sources of a component to a file server and then running a component build on them. At the moment the command line tool requires a SAP NetWeaver Developer Studio installation on the make server in order to have access to the build plugins.
Optionally, the administration can demand from the developers that they use a name service to guarantee the unique naming of certain critical resources such as components and database tables. The name service can be assigned upon creation of a new development configuration. The SAP NetWeaver Developer Studio then will automatically contact the name service whenever such a critical resource is created. It is highly recommended to use this feature because it prevents problems that will arise from duplicate names. The name service is part of the System Landscape Directory (SLD).
You have installed the following elements:
...
· SAP NetWeaver J2EE Engine with JDI.
From the JDI, the DTR and the configuration self-service are used.
· SAP NetWeaver Developer Studio on every developer PC.
· (Optional) System Landscape Directory (SLD).
· (Optional) SAP NetWeaver Developer Studio for the central make.
· (Optional) Install SAP NetWeaver J2EE engine for central test server.
...
· Configure the DTR service.
¡
Configure the
user management
system.
¡
Create
users and
authorizations.
¡
Create
workspaces.
· (Optional) Configure the name service.
· Use the web-based self-service to create a development configuration (on the server, on which the JDI is installed).
· Distribute the configuration file to the developers.
·
Import the
configuration into the SAP NetWeaver Developer Studio
instances.