Software Component Versions 

Definition

A software component version is a shipment unit for repository objects. A software component version can be used in different product versions.

You can access SAP software components (and products) from the software catalog of the System Landscape Directory (see: Software Catalog).

It is also possible to structure software component versions using other software component versions.

Use

To use software component versions you must first import them into the Integration Builder from the System Landscape Directory (see: Importing Software Component Versions). A software component version is only relevant for the Integration Repository and not for the Integration Directory because the contents of the latter is not shipped but configured at the customer site.

Structure

When you have imported a software component version, the Key tab page displays attributes from the System Landscape Directory. You can use the following XI-specific attributes on the Definition tab page:

·        Interface Import

Here you can define whether the import of RFCs and IDocs is permitted for the software component version. If it is, then you must specify an SAP system from which these interfaces are to be imported. You can only specify one such SAP system for each software component version.

See: Connection with Adapters and Imported Interfaces

·        Namespaces

Using namespaces you can further subdivide the software component version into semantic units. These are required to create objects in the repository (in other words, Business Scenarios, message interfaces, and mappings).

See: Namespaces, Design Time

·        Object Properties

Use these two attributes to define the properties for all objects of the software component version:

                             a.      Objects Are Original Objects:

The objects of the software component version are the original objects in the repository belonging to the Integration Builder, and should only be modified in this repository. There can only be one original object, in other words, you must not set this attribute for multiple software component versions of other repositories simultaneously.

                             b.      Objects Are Modifiable:

This attribute enables you to change objects in the software component version when set. Use this attribute to lock all objects against changes, if required.

Also see: Versioning in Transports

The latter two attributes are typically used as follows:

Attribute Set	Use
(a) and (b) set	The objects in this repository are the originals and can be modified there. Use this setting for the repository in which the cross-system process is being developed.
(a) and (b) not set	The objects in this repository are not the originals and cannot therefore be modified here. Use this setting for repositories where the originals from a different repository have been imported. Also see: Exporting and Importing Integration Objects.
Only (a) set	The original objects are temporarily locked against modifications, for example to ‘freeze’ the development status.
Only (b) set	Normally you do not change objects in a repository where the objects are the not the originals. However, use this attribute for temporary changes, for example when you do not want to wait for the next import before making an emergency correction. These changes are lost when the next import takes place (due to the conflict resolution function).

Integration

The navigation tree in the Integration Builder then provides you with an overview of all software component versions that use integration objects within cross-system applications. To ensure that objects that belong together within a software component version are shipped together, the Integration Builder restricts the references that are possible between objects in the Integration Repository (also see: Object References).