Transfer Structure in Data Flow 3.x  

DefinitionThe transfer structure is the structure in which the data is transported from the source system into BI.

It is a selection of DataSource fields from a source system.

UseThe transfer structure provides BI with all the source system information available for a business process.

An InfoSource 3.x in BI needs at least a DataSource 3.x for data extraction. In an SAP source system, DataSource data that logically belongs together is staged in a flat structure, the extraction structure. In the source system, you are able to filter and enhance the extraction structure in order to determine the DataSource fields.

In the transfer structure maintenance in BI, you determine which fields of the DataSource 3.x are to be transferred to BI. When you activate the transfer rules in BI, a transfer structure identical to the one in BI is created in the source system from the DataSource fields.

This data is transferred 1:1 from the transfer structure of the source system into the BI transfer structure, and is then transferred into the BI communication structure using the transfer rules.

A transfer structure always refers to a DataSource from a source system and to an InfoSource in BI.

If you choose Create Transfer Rules  from the DataSource or the InfoSource in an object tree of the Data Warehousing Workbench, the transfer structure maintenance appears.

 

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.

StructureKey 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.

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).

Transfer Rule and DataSource 

DefinitionTransfer 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.

StructureKey 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.

ExampleThe 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). 

 

Transport and Delivery of Source System-Dependant Objects 

Use

To facilitate understanding of this topic, this section contains information on transports in general. 

It is not objects themselves that are transported into a BW system but the meta information that is required to generate an object in the target system. Source system-dependant objects are notably dependant on circumstances in the target system. They can be distributed, even physically, to a BW system and a source system.  As a result,

particular requirements often exist in relation to source system-dependant objects, such as the following:

         An object that was created in the original system for a source system A, should be created in the target system for another source system B 

         As the definition of a connection to a source system always depends on both sides, the source system and the BW system, an object that was created in both the source and target systems for one and the same source system physically has two different connections to this system. 

Therefore, with source system-dependant objects, a logic runs that defines the name of, and connection to the source system for which the import and activation of the content is to be executed. 

Delivery (content-specific)

As with the delivery of SAP Business Content, the name of the source system is normally also of little relevance with the delivery of customer Content. This is because the customer has other source systems connected as the Content development system.  Therefore the source systems of source system-dependant objects are made anonymous before delivery and replaced by their release status.  This means source system-dependant objects need to be delivered with their own tables. These carry the release instead of the source system in their key. These tables are called shadow tables.

Transport (general)

The key (name) of the source system-dependant objects in the target system differs from the key for the object in the original system. This means the meta information cannot be imported in the same version as it exists in the original system (A or M version). In the event, there could be other objects in the target system that have the same key as the object in the original system. Therefore source system-dependant objects are imported in their own version, the T (transport) version.

After-import methods act on the T version and generate the modified and active version from this. 

Features

The following table offers an overview of the different types of source system-dependant objects:

Source system-dependant objects

Type of Object Example

Source system-dependant object, carries the source system directly in its key

Transfer rule

DataSource

BBS receiver for the InfoCube

BBS receiver for the query

Source system-dependant object, carries the source system in its key in coded form

Transfer Structure

Source system-dependant object, carries aGUID (Globally Unique Identifier) in its key

InfoPackage

Source system-independent object, refers to a source system-dependent object

Process chain

Process chain variants (PSA processes)

In the first three cases the keys change. In this way, a distinction can be made between their D and A tables.

Process Chain and Process Variant 

Definition

Process Chain (active object: RSPC / delivery object: DSPC) and process variant (active object: RSPV / delivery object: DSPV) are non- source-system dependent objects that can, however, reference to source-system dependent objects.  

You can find additional information about such BW objects under  Process Chain and Process.

Structure

Process chains and process variants are normal transport objects. The key belonging to these objects is the same in the target and original system. However, process chains and process variants can reference to source-system dependent objects.

A process chain that references to source-system dependent objects that have a GUID in the key, has the GUID in data field VARIANT (see graphic).

During Content activation, these fields are encoded in the same way as for the corresponding source-system dependent object. Accordingly, the A and D versions of the process chains and process variants differ.

The following graphic shows the individual conversion steps for the example above. GUID1 references to the InfoPackage. When copying to the D version, GUID1 is encoded to GUID2. As in the example in InfoPackage, GUID2 is copied to GIUD3 and GUID4 for the different customer source systems.

Example

The following example will show what you need to bear in mind when activating process chains when using Customer Content.

When activating a process chain in the customer system, all source systems are considered that you have selected as the default. For example, if you selected an R/3 system with release state 4.0B and one with release state 4.5B in the dialog Select Source Systems as Default, the Object Collector then collects an InfoPackage for each source system. If you activate the process chain with the same setting, both InfoPackages are then transferred to the process chain:

We recommend that you only activate process chains for one source system. Otherwise, the subsequent process steps are either executed more than once (when dealing with a periodic process chain), or they are executed too early (after the first InfoPackage is processed).

1. Scenario: Customer System with a Source System

Select the source system before activating the Content.

2. Scenario: Customer System with Several Source Systems

The customer has additional manual work. After the event, you need to redraw the lines of connection in process chain maintenance.

Variant 1...

       1.      Before installing the Content, select the required source systems .

       2.      Collect the InfoPackage and activate it with the selected source systems.

       3.      Before installing the Content, choose one of the source systems.

       4.      Collect the process chain and activate it with the selected source system.

       5.      Call up the process chain maintenance. Add the InfoPackage process type “Load Data” to the process chain for the source system that you did not select before activating the process chain. Add the process type “AND(Last)” and draw the necessary lines of connection to include the new InfoPackages.

The following graphic shows how an InfoPackage is subsequently added for the source system with release state 4.0B:

Variant 2...

       1.      Before installing the Content, select the required source systems .

       2.      Collect the process chain and activate it with the selected source systems.

       3.      Call up the process chain maintenance. Remove the line of connections from the “data load” process. Add process type “AND (Last)” and draw the requisite lines of connection to include all InfoPackages.

Content Development System

Avoid changing the source system release after delivery of Customer Content. This can lead to failure even in a customer system with only one source system. With a new delivery, the D version is used in the customer system. However, upon activation , the older active version remains where it was due to the divergent source system.

InfoPackage 

Definition

An InfoPackage (active object: ISIP/delivery object :SHIP) is a source-system dependent object that has the GUID as key. There is one object for each source system.

You can find additional information about this BW object under  Maintaining an InfoPackage.

StructureKey Fields of an InfoPackage (ISIP/SHIP)

Version Key Fields Data Fields

A (active) / M (modified) / T (Transport) - ISIP

GUID Source System

D (Delivery /. Content) - SHIP GUID Source system release

As the source system does not exist in the key, but is contained within the data part, the InfoPackage objects is also delivered as a shadow table.

Example

The following example aims to show what you need to be aware of when delivering InfoPackages within partner Content.

The Content development system is connected to source system Q1. There is exactly one InfoPackage with GUID1 for this source system.

In the customer system, this InfoPackage is to be activated for several source systems with the same release status:

        Source system X1, Release 4.0

        Source system X2, Release 4.0

Accordingly, the InfoPackage is copied into the A version twice. The logic behind this is the same as for transfer rules (see Transfer Rules and DataSource). Conversion is carried out byRSSM_SHIP_PSEUDO_DVERSION_WIR. The copies contains GUID3 and GUID4.

When SAP delivers again, you need to know from which InfoPackage GUID3 and GUID4 are derived. This information is stored in table RSSHIPDVERS:

Table RSSHIPDVERS

LOGDPID_SH LOGSYS LOGDPID

GUID3 X1 GUID2

GUID4 X2 GUID2

Extract Structure 

Definition

In the extract structure, data from a DataSource is staged in the source system. The extract structure contains the amount of fields that are offered by an extractor in the source system for the data loading process.

You can edit and enhance DataSource extract structures in the source system. To do this, in the BW Administrator Workbench choose Goto  Modeling  Source Systems  Your Source System  Context Menu (right mouse click)  Customizing Extractors  Subsequent Processing of DataSources.

Compounding Info Object

In Compounding a Field or another Object is attached to an Info Object. A Compounding Characteristic is when object's definition is incomplete without the definition of the another Characteristic Info Object.

For the better understanding the Info Object - Location (0PP_LOCAT) has to be assigned with  a Compound Info Object - Plant (0PLANT).

Here Plant(0PLANT) is the Superior Info Object of the Location(0PP_LOCAT)

The Info Object 0Plant has to be Installed/Created/ Activated first, later followed by Location(0PP_LOCAT)

While creating the Info Object itself we need to assign the Superior Object like below at Compounding Tab Page of Info Object.

Compounding Info Object Acts as a compounding Primary Key at the Master Data Table.

When a compounded Info object is included in an Info cube, all corresponding info objects are added to the Info cube. 

If Location(0PP_LOCAT) is to be included in the Info Cube , Plant (0Plant) is automatically added to the Info Cube. 

When a Compounded Info object is included in the DSO , all corresponding Objects are added to the DSO Key fields/Data Fields.

If Location(0PP_LOCAT) is to be included in the DSO , Plant (0Plant) is automatically added to the DSO. 

The below video explains: 

If an info object is defined as an attribute, it cannot be included as compounding object.

The total length of the compounding info objects cannot exceed 60 characters.

An Info Object which is defined as an Attribute only setting can not be included in Compounding object.

The Compounding Info Objects at BEx Report out put will be 0PLANT/0PP_LOCAT.