Replicating DataSources 

Use

In the SAP source system, the DataSource is the BI-relevant metaobject that makes source data available in a flat structure for data transfer into BI. In the source system, a DataSource can have the SAP delivery version (D version: Object type R3TR OSOD) or the active version (A version: Object type R3TR OSOA).

The metadata from the SAP source systems are not dependent on the BI metadata. There is no implicit assignment of objects with the same names.  In the source system, information is only retained that is required for data extraction. Replication allows you to make the relevant metadata known in BI so that data can be read more quickly. The assignment of source system objects to BI objects takes place exclusively and centrally in BI.

There are two types of DataSource in BI. A DataSource can either be a DataSource (R3TR RSDS) or a DataSource 3.x (R3TR ISFS). Since a specific DataSource cannot exist in a specific source system at the same time in both objects in the system, and because these objects are not differentiated between in the system, when replication is performed, you have to choose which object you want the metadata to be replicated in.

Integration

Replicated DataSources 3.x can be used as emulated DataSources in BI for the purposes of migration. As long as certain prerequisites are fulfilled, a DataSource 3.x can be restored from a DataSource.

See also:

Emulation, Migration and Restoring DataSources

Prerequisites

You have connected the source system to BI correctly.

Features

Metadata from a SAP source system is read in the source system using the Replicate Metadata function in the DataSource tree of the Data Warehousing Workbench and is replicated to BI or created there. When you create a SAP source system, an automatic metadata upload is carried out.

In the DataSource tree, you can request the metadata for a DataSource, the metadata for an application component, or all the metadata for a source system: The Replicate Tree Metadata function replicates the application component hierarchy of the SAP source system to BI.

Replication Process Flow

In the first step, the D versions are replicated.

The DataSource header tables of BI Content DataSources are saved in BI as the D version. Replicating the header tables is a prerequisite for collecting and activating BI Content.

●     If SHDS is available for the D-TLOGO object in the BI shadow content, the relevant metadata is replicated in DataSource (R3TR RSDS).

●     If SHMP (mapping for DataSource 3.x) is available for the D-TLOGO object in the BI shadow content, the relevant metadata is replicated in DataSource (R3TR ISFS).

●     If no BI Content is available in the D version in BI for a DataSource (R3TR OSOD), the D version cannot be replicated because this version is only being used in BI for BI Content activation.

In the second step, the A versions are replicated.

DataSources (R3TR RSDS) are saved in the M version in BI with all the relevant metadata. This means that, as long as the DataSource is not yet being used, that is, as long as a transformation does not yet exist for the DataSource, you can avoid generating too many DDIC objects needlessly.

DataSources (R3TR ISFS) are saved in BI in the A version with all the relevant metadata.

●     As a basic principle, the object type of the A version follows the object type of the D version. If the DataSource already exists in BI in the A or D version, the DataSource is replicated to the existing object.

●     If the DataSource does not yet exist in BI, the system performs replication according to the following logic:

...

                            a.      If the DataSource is a hierarchy or export DataSource, this determines the object type for the replication:

■      Hierarchy DataSources are replicated to DataSources 3.x.

■      Export DataSources (8*) are replicated to DataSources 3.x.

                            b.      If there is a D version in BI for a mapping object (R3TR ISMP), the system performs replication to DataSource 3.x (R3TR ISFS).

                            c.      In other cases, the system asks the user which object type the DataSource is to be replicated to.

Deleting During Replication

DataSources are only deleted during replication if you perform replication for an entire source system or for a particular DataSource. When you replicate DataSources for a particular application component, the system does not delete any DataSources because they may have been assigned to another application component in the meantime.

If the system determines upon replication that the D version of a DataSource in the source system or the associated BI Content (shadow objects of DataSource R3TR SHDS or shadow objects of mapping R3TR SHMP) is not (or is no longer) available in BI, the system automatically deletes the D version in BI.

If the system determines upon replication that the A version of a DataSource in the source system is not (or is no longer) available, the BI system asks whether you want to delete the DataSource in BI. If you confirm that the system is to delete the DataSource, the system also deletes all dependent objects; the PSA, InfoPackage, transformation, data transfer process (where applicable) and, in the case of DataSource 3.x, the mapping and transfer structure, if these exist.

Before confirming that you want to delete the DataSource and related objects, ensure that you are no longer using the objects that will be deleted. If it is only temporarily not possible to replicate the DataSource, confirming the deletion prompt may cause relevant objects to be deleted.