Versioning and Compatibility 

Prerequisites

A product can have multiple versions. Each product version is a delivery unit visible for customers. The software component versions used in a product version can be called in the System Landscape Directory. In the context of SAP Exchange Infrastructure, the products and software component versions that are of interest are those that are to exchange messages with each other. When development starts they must be imported from the System Landscape Directory into the Integration Builder (see: Importing Software Component Versions).

Versioning

Once a product version has been delivered you access it by creating a new version. You then only make changes in the new software component versions of the product. A user has the option of tracking and controlling changes made to objects for each version of the product. Any changes and deletions made are logged in changes lists visible to the user. When the user activates the changes, they are transported and become visible for other users. The user can also reject changes made to individual objects or for all objects in the change list.

The Integration Builder can contain multiple versions of a software component. This is necessary in order for old and new product versions to be able to communicate. Usually, a new software component version copies all namespaces, including objects from the previous version and possibly new namespaces. If the software component versions need to be reorganized, it is also possible to move namespaces to other software component versions.

Compatibility of Changes

Wherever possible, changes or product enhancements should be compatible with the previous version. In other words, a customer must be able to revert to a new version of a product without any difficulty. Incompatible changes are those that render the program code of the previous version in some way invalid. The following section provides an overview of compatible changes to SAP Exchange Infrastructure objects.

Interface Objects

For two systems to communicate there must be an outbound and an inbound interface. You must ensure that any change to either interface does not mean that the counterpart must be changed as well in order that the systems can communicate with each other. The following options for compatible changes exist:

·        Adding technical and semantically optional attributes or elements to the referenced complex data types. Semantically optional means that a field is not expected by a receiver although it is flagged as optional.

·        Communication partners can of course agree on changes. If a new version of a product depends on changes in another product, then the customer must be informed correspondingly (for example, new product A, version 2.0 requires at least product B, version 3.5).

Generally you check for an object that has had incompatible changes made to it whether it is referenced by other objects and whether you should inform the “owner” of the object about the changes.

Mappings

You must only make compatible changes to a mapping between two application components for technical reasons. Compatible means that the mapping must function for any combination of subsequent versions of both application components. Therefore, the only changes possible to a mapping in different software component versions are corrections. If you need to make incompatible changes, you must create a new mapping.

A mapping between the application components CRM 1.0 and APO 1.0 must also function for the following combinations: CRM 2.0 with APO 2.0, CRM 1.0 with APO 2.0 and CRM 2.0 with APO 1.0 (see: Ensuring the Compatibility of Mappings).

If a mapping comprises multiple mapping programs that are executed one after the other, then they must be compatible for each transitional step.

The mapping programs M1 and M2 are used for the following overall mapping: A (M1) B (M2) C. It is not sufficient when the mapping is only compatible for the mapping from A to C. The mapping from A to B and from B to C must also be compatible.