Show TOC

Background documentationConcepts Locate this document in the navigation structure

 

The Composite Designer perspective facilitates the development of composite applications in all technological layers. It introduces products as main development entities for composite applications. The product used in the Composite Designer perspective is closely related to the SAP NetWeaver Development Infrastructure (NWDI) and the System Landscape Directory (SLD). Therefore, you need to be familiar with basic details that originate from these two areas. In the following topic, you can find a brief summary of the necessary basic knowledge that allows you to work with the Composite Designer perspective.

When you develop your composite application in the SAP NetWeaver Developer Studio, there are different ways of starting the development. The common activity between any of them is that you have to keep up to the SAP component model principles. Your main entry point for reviewing and developing composite applications is the Composite Designer perspective.

Local Development

If you prefer to stay away from landscapes' setup and/or development in a track using the NWDI, you still have the option of developing your product as a standalone application. You can use your local file system, or you can perform team development with a third party versioning system. You start with creating a local development configuration file, and with minimum effort, you can set up the entire environment for your development.

You directly create a development configuration from scratch, and manually create the software components (SCs) that you want, using only the SAP NetWeaver Developer Studio. You do not need SLD or NWDI at all. If your product is a composite application, you have a huge number of capabilities for easier development inside the Developer Studio.

You go into the Developer Studio and start working on your composite application. Note that you can always move your development from the local development configuration to development integrated with the development infrastructure.

More information:

Migrating from Local Development to NWDI.

Local Development as a Start to Component Based Development.

Development Using Optional Development Infrastructure

Development Integrated with the SAP’s Development Infrastructure

If local development does not meet your requirements, you can decide to move your development to a central development system landscape. If this is your case, note that you need an administrator to set up your development environment:

  1. In the System Landscape Directory (SLD) to create SLD product(s) and software component(s) that correspond to SCs of the composite application you are developing in the Developer Studio. In the SLD you define the product version and associate the product with the software component (SC) versions that belong to it.

  2. A track needs to be set up in the AS ABAP TMS system or in the AS Java system. Once you have your track created, you need to include the SCs that the product comprises of in the development track.

  3. Use the New Product wizard of the Composite Designer to finalize the product configuration. This step has to be performed only once.

    Subsequently, all developers have to use the Import Product wizard to synchronize the product´s content to their local system.

All this setup is required to enable the logical connectivity between the product defined in the SLD, to the development track, then to the development configuration file, and down to the Product Description SC that the developers are working on. That is, you need to follow the steps described in the documentation of the NWDI.

More information:

Defining Products in a Single Development Configuration.

Components Development with the NWDI.

The picture below illustrates the use of Product Description SC.

This graphic is explained in the accompanying text.

Product Description Software Components (SCs)

Note that in your development configuration you define the different products that this development configuration may contain, by associating them to an SC (Product Description SC).

These Product Description SCs are created automatically by the Composite Designer when you create a new product in a local development environment without the involvement of SLD. However, it is necessary to manually create the Product Description SC in SLD if you are working in an NWDI-based landscape.

When working with a development configuration that is connected to a development track, this Product Description SC has a special association with the product defined by the administrator in the SLD called Association. The association contains a product definition that allows the NWDI to handle the product meta information for the development infrastructure. The Product Description SC is also the container to define the scope of the product in terms of SCs and development components (DCs). In any case, you need such an SC to be able to display your product as a composite application inside the Composite Designer perspective of the Developer Studio.

That means that in the Composite Designer perspective, a single product consists of at least two SCs: one Product Description SC, which contains no code but just metadata, and one (or more) content SCs, which contain the actual DCs and code of the product. This approach allows the alignment of relations: source code – development component – software component – composite application – product.

Multiple Products Support in a Single Development Configuration

You can use the development configuration as a container for developing several different composite applications, and the Product Description SC as a denotation, used to recognize each combination of SCs as different products (that is, a different composite application). For example, to meet the different customer requirements you can organize the available functionality in your development configuration into different products (for example to reuse generic functionality in different products). To do that, you need to assemble arbitrary combinations of the SCs that constitute your application and mark these combinations as different products that can be delivered out of the same track. You can develop composite applications that comprise of more than one SC. To figure out how to define the SC structure of your product, refer to the corresponding NWDI documentation.

Composite Designer

The Composite Designer recognizes products as main development units. From the Composite Designer point of view, one product bundles up one or multiple SCs into a single unit.

The figure below illustrates the Composite Designer concepts and deliverables.

This graphic is explained in the accompanying text.

With its graphical toolset, the Composite Designer perspective of the SAP NetWeaver Developer Studio is a major entry point for modeling and developing composite applications. You can easily create new composite applications or simply import already existing products inside this perspective. Then, you can quickly and intuitively perform different analytical tasks. For example, you can explore and troubleshoot the development object relations or simply review the existing development objects details.

The main use cases of the Composite Designer perspective are:

  • Composite application architecture overview.

    The perspective allows a unified graphical view and transparency of the composites' layer structure. You can also visualize the development objects that are located inside the different layers, as well as the corresponding relations between these development objects. Composite Designer provides its views across all technologies in the Developer Studio. Composite Designer also hides the complexity of the different relations from one technology to another one (for example the Web Dynpro model).

  • Composite application central management

    Using the Composite Designer perspective, you assemble the elements of your composite and pack them in the way they are delivered to customers. Usually the composites are delivered as software component archives (SCAs). These archives consist of the composite's development components. For more information, see Component Model.

More information:

Development Infrastructure (DI)

System Landscape Directory

Development Infrastructure

SAP's Component Model