Transfer Rule and DataSource 

Definition

Transfer rules (active object: ISMP/ delivery object: SHMP) and DataSources (active object: ISFS/ delivery object: SHFS) are source system-dependent objects that carry the source system directly in their keys.

You can find additional information on these BW objects under Processing Transfer Rules and DataSource. 

Structure

Key fields of a transfer rule (ISMP/ SHMP)

Version	Key Fields
A (active) / M (modified) / T (Transport) - ISMP	DataSource, source system, object version
D (Delivery / Content) - SHMP	DataSource, source system release

The T version is used for a normal transport. The source system codes are converted by the RSLOGSYSMAP table.  

Features transporting Content objects: Transfer rules (SHMP) are the only Content objects, as far as the InfoSource is concerned, that have an after-import method.  This after-import method ‘multiplies’ the release-dependent shadow table (not the source system-dependent shadow table) and so finds the best Content release for each source system. In this way, Content is generated for each source system. The system executes the same logic when a new source system is connected. The appropriate Content for this system is likewise generated from the shadow table. 

This multiplication is carried out by the function module RSAOS_PSEUDO_DVERSION_UPD.

Subsequently, the Content version of an object caries the source system in its key. When the Content is activated, the objects for this source system can be activated.

Key fields of a DataSource (ISFS/ SHFS)

Version	Key Fields
A (active) / M (modified) / T (Transport) - ISFS	DataSource, source system, object version
D (Delivery / Content) - SHFS	DataSource

As a DataSource (SHFS) in the BW is only delivered for file or BAPI systems, the release for these objects, unlike transfer rules, always remain initial. Therefore the source system release does not exist as its own field in the key. 

You can find additional information on the delivery of DataSources in the OLTP system under Delivery and Use Customer Content in the Source System.

Example

The following example aims to show what you need to pay attention to, as far as transfer rules are concerned, regarding customer Content and the delivery of source system-dependent objects having the source system in their keys. 

The Content development system is connected to the following source systems:

·        Source system Q1, Release 3.1

·        Source system Q2, Release 4.5

·        Source system Q3, Release 4.5

The target system of the customer is connected to the following source systems:

·        Source system X1, Release 3.1

·        Source system X1, Release 4.0

The left-hand side of the following graphic shows the code conversion from the A version to the shadow version in the Content development system. As a result of this code conversion, the source system is replaced by its release. As Q2 and Q3 have the same release status, the shadow version only contains two data records.

The shadow table is generated automatically when this is activated. 

Avoid using the same DataSource with the same names, in different source systems that have the same release status.  In this case only one delivery object is generated in the shadow table. This is compiled from the information in the different source systems. If this leads to a conflict, the most recently activated object has priority. This is also true for the Transfer Structure.

We recommend that you always set up a customer content development system for each customer release.

The shadow version is delivered 1:1. The right-hand side of the graphic shows the processes in the customer system. The D version is generated from the shadow version in the first after-import step.  The system searches for the appropriate release in the content for source system X1 and finds 3.1. As there is no release 4.0 in the Content, the system takes the next release back, which is 3.1.  By activating the Content the D version is copied into the A version.

As a customer, code upwards compatibility (additive). 

 

See also:

 

Transport and Delivery of Source-System Dependent Objects