Transfer Structure 
Definition
The transfer structure (active object: ISTS / delivery object: SHTR) is a source system-dependant object. It does not carry the source system directly, but uses a transfer structure prefix that is coded in its key.
You can find additional information about this BW
object under 
Transfer
Structure.
Structure
Key Fields of a Transfer Structure (ISTS / SHTR)
|
Version |
Key Fields |
|
A (active) / M (modified) / T (Transport) - ISTS |
DataSource with coded connection, object version |
|
D (Delivery / Content) - SHTR |
DataSource, source system release |
As a transfer structure (A/ M version) carries a transfer structure prefix in its key, its name is replaced with the name of the transfer rule for which it is valid, before delivery. This is the ‘virtual key’. As a result, a transfer structure in the D version also has the release in its key.
More detailed information on this conversion is given in the example below.
As the target tables in the customer system do not carry the source system in a key, the shadow tables of the transfer structure are not physically multiplied, as those in the transfer rule are.
With a transfer structure, this ‘multiplication’, (the replacement of the release status by the respective source system), takes place while the objects are being collected for content activation. The object collector then operates with ‘virtual’ transfer structure names that have no physical correspondent.
The system finds the transfer structure prefix, and with it the new name for the transfer structure, by identifying the source system. When the system reads the transfer structure suitable for this source system from the Content, it takes the transfer structure with the nearest lower release to the release for the source system.
Example
The following example aims to show what you need to be aware of when delivering transfer structures within partner Content.
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 transfer structure does not have the source system (field LOGSYS) in its key, but the name of the DataSource. This is the expanded transfer structure prefix name. The table RSBASIDOC shows to which source system with which release status a transfer structure prefix is assigned.
Table RSBASIDOC
|
SLOGSYS |
SAPREL |
TSPREFIX |
|
Q1 |
3.1 |
QA |
|
Q2 |
4.5 |
QB |
|
Q3 |
4.5 |
QC |
The customer’s target system is connected to the following source systems:
· Source system X1, release 3.1, transfer structure prefix XA
· Source system X2, release 4.0, transfer structure prefix XB
The left-hand side of the following graphic shows the code conversion from the A version to the D version in the Content development system. Note that only the first column (TRANSTRU) is a key field. The system writes the name of the DataSource (OLTPSOURCE) to the field TRANSTRU in the D version and accesses the release status of the source system (SAPREL) from the transfer structure prefix. As a result the name of the transfer structure is replaced in the D version with the name of the transfer rule for which the transfer structure is valid. As Q2 and Q3 have the same release status, the D version only contains two data records.
Avoid using the same DataSources with the same names, in different source systems that have the same release status. See the notes in the section Transfer Rule and DataSourceon this.
The D version is delivered 1:1. The code conversion on the right-hand side corresponds, in principle, to that of the transfer rule. Here, however, it actually shows the features described above (‘virtual’ transfer structure name).
See also:
Transport and Delivery of Source System-Dependent Objects