Show TOC

Software ComponentsLocate this document in the navigation structure

Definition

Software components (SCs) combine development components (DCs) into larger units for delivery and deployment.

  • Every top-level DC must be assigned to exactly one SC.

  • Child DCs always belong to the same SC as their parent DC.

  • The assignment of DCs to SCs is not static and may change over time.

  • SCs cannot be nested into each other.

  • SCs do not directly control the visibility of their assigned DCs. They can indirectly control them through dependencies defined between the SCs themselves.

  • SCs do not adhere to the black box principle.

  • SCs do not define public parts: all assigned DCs are automatically defined as public.

  • SCs can depend on each other and use each other, similarly to DCs.

  • Since SCs do not have development objects of their own, they define dependencies exclusively for the components assigned to them.

  • A DC can use another DC from a different SC only if its own SC defines an appropriate dependency.

  • DCs can restrict their use from certain SCs using access control lists (ACLs).

  • SCs can be used to implement software layers.

SCs have globally unique names, which are structured according to the rules for DC names. Names of SCs consist of a vendor ID and only one segment, such as sap.com/crm . See Naming .

Caution

You must define the name when you create the software component; this name cannot be changed later.

Structure

SCs combine DCs into groups that are developed, used, delivered and maintained together.

  • Every DC can belong to only one SC in a single release version. In the different release versions, you can change the SC to which a DC belongs.

  • Always select used SCs from related release levels.

    The use dependency between SCs is determined in the System Landscape Directory (SLD). Transitive usage does not happen in such a way that these dependencies have to be defined because the SCs are used in the archive state.

Number of Software Components

The size of an SC - that is, the number of DCs it contains - is not limited. The size does not even influence the speed of the build process because the DCs are the units for the build process.

Note

One exception is the assembly process in which the entire SC is built.

In the following cases, you need more than one SC:

  • The installation is carried out on different platforms.

    Example

    The Java EE part of your application is to be installed on the SAP NetWeaver and another part as a standalone client application.

  • There are different delivery and maintenance cycles.

    Example

    You should not mix the Portal Business packages you develop with applications since the portal content is updated more frequently than the functions of the application.

  • You use layered development.

    Example

    A framework component should be developed and tested before the dependent part of the software.

  • There are technical reasons.

    • You want to deliver some product parts together with the source files (to allow modifications) and others as archives only.

    • You want to define different build variants for different groups of DCs.

Versioning

From the point of view of time, an SC exists in well-defined states or versions . A state of an SC encloses a certain state of each of its assigned DCs. The state of a DC is determined by its sources, attributes and dependencies at a given point in time. Every time a change in the source code is released, a new state of an SC is created.

For delivery, deployment and maintenance, certain states of an SC can be recorded as a release . The person responsible for the SC makes this decision: if it should be stored in the SAP NetWeaver Developer Studio or in the development infrastructure. The state of the SC then corresponds to the state of your DCs. DCs do not have a state of their own. Implicitly, they always adopt the respective state of their software component.

Dependencies

SCs may depend on each other. If a dependency between two SCs exists, then the DCs of the using SC themselves may declare dependencies (of any kind) to DCs of the used SC.

Example

In a layered software system, in which an application layer (represented by an SC) uses the services of a technology layer (represented by another SC), a dependency is defined from the application layer to the technology layer. However, this does not allow the DCs of the technology layer to access DCs of the application layer.

A dependency between two SCs is created without referring to actual states or versions of these DCs. A development configuration determines which actual states of these DCs may or must be used together. A development configuration establishes relations between actual states of SCs. The relations between SCs determine which DCs are allowed to use one another and which not. Therefore, the configuration implicitly determines which actual states of DCs can be used together. This is an important consequence for the interaction of DCs: a DC cannot determine by itself that it wants to interact only with a particular version of another DC.

Example

A development configuration determines that the SC ABC uses another SC Technology . A DC A from ABC then declares a dependency to a DC B from Technology . The DCs of the used SCs are made available. This step determines the version to be used.