Compartments

A compartment has the following attributes:

·        Name

·        Caption

·        Description

·        Software Component

Name

The attribute Name specifies the technical name of the compartment. It is unique for the configuration containing the compartment.

Among others, the name of a compartment is used to form folder names and URLs. For this reason, the set of allowed characters for compartment names is restricted.

Caption

This is the displayed name of the compartment.

Description

Optional description of a compartment with additional information on the compartment.

Software Component

Name and vendor of the software component assigned to this compartment.

Information on the sources:

·        DTR and DTR workspace

·        Local archive folder (scenario 2)

A software component can exist in different states (versions, releases). A development configuration defines compartments. A compartment represents a particular state of a software component.

Usually, there is exactly one compartment for every software component that is part of the development configuration. In special cases, a development configuration can contain several states of the same software component. This can be necessary if a using component must be compatible with different states of a used component. In these cases, there can be several compartments for the same software component.

A compartment can make a software component accessible in different ways:

·        As a state that can be activated

·        As a source state that can be changed in the development configuration, but not activated

·        As a source state that cannot be changed in the development configuration

·        As an archive state

SCs as State that can be Activated

The software component is developed in this development configuration. The objects that belong to the software component are stored as changeable versioned resources (“development objects”) in a workspace in the Design Time Repository. This workspace is called the “inactive“ or “changeable” workspace of a compartment.

Changes to components in this compartment must first be checked into the DTR and can then be activated in the assigned build service. Activation in this context means that the build service recompiles the changed components and, if successful, deploys the changes into another workspace of the Repository, into the “active” workspace. In the active workspace, developers cannot make changes directly.

The content of the “inactive“ workspace of a compartment is important only for those developers who develop the components in this compartment.

Developers who only use a component, usually refer to the “active“ state of a component. The active state has been compiled successfully by the build service at least once and, therefore, exists in the form of libraries and deployable archives. Developers can choose whether to use the active sources of a component or its libraries.

The active workspace is assigned exclusively to its compartment. Integrating changes into this workspace results in inconsistencies between the active sources and the libraries the build service provides for these components. It is not possible to let several build services activate into the same active workspace.

SCs as a Source State that can be Changed in the Development Configuration, but not Activated

It may be useful to define a compartment without activation processes and build service. You may use this for component types that are not supported by the build service but still shall be transported and distributed together with other components in a development landscape.

To such a compartment, only one changeable workspace is assigned. Like in compartments that can be activated, changes can be checked into the Repository. Immediately after the check-in, you can release your changes into the development landscape for further transport.

A central build does not happen. For such a compartment, no libraries or archives are available. However, you can always trigger a local build in the SAP NetWeaver Developer Studio.

SCs as a Source State that Cannot be Changed in the Development Configuration

Compartments can contain “static“ states that must not be changed. This may be a state assigned to an old release of a software component, or a “final assembly” state. Because the compartment contains sources, it can be built by a central build at any time.

In these cases, a single workspace is assigned to the compartment, which is flagged as read-only in the Repository.

A not changeable compartment can refer to any workspace, even to a workspace assigned to another compartment or another development configuration. In this case, the content of the workspace may still change.

SCs as an Archive State

An archive state provides only libraries but no sources. It can be changed only the importing archives created at other locations. The development configuration does not have a fixed connection with the source configuration of the archives. You may integrate any state of the software component appropriate for the compartment. In a development landscape, source and target compartment for archives are usually connected by fixed transport paths. This is one of the tasks of the Change Management Service.

The table below gives an example for a development configuration (in simplified representation). The development configuration has three compartments, of which number 3 is a compartment that can be activated, while the other two only contain archives. For the compartment that can be activated, the workspaces are specified (in the form of URLs).

Example: Development-Configuration SC1 6.0 dev

Compartment	SC	Role	Source
1	TC	used	-
2	SC2	used	-
3	SC1	developed	active: http://dtr1.sap.com/ws/ws11 inactive: http://dtr1.sap.com/ws/ws12