Replication of 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 is 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 if it 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 DataSources in BI. A DataSource can exist either as a DataSource (R3TR RSDS) or a 3.x DataSource (R3TR ISFS). Since a DataSource cannot exist simultaneously in both object types in one source system and because these objects are not differentiated in the system, you have to choose which object you want the metadata to be replicated in when you replicate the DataSource.

Integration

Replicated 3.x DataSources can be emulated in the BI in order to prepare migration of the 3.x DataSources into a DataSource. As long as certain prerequisites are fulfilled, a 3.x DataSource can be restored from a migrated DataSource.

For more Information:

Emulation, Migration, and Restoring DataSources

Prerequisites

You have connected the source system to BI correctly.

Features

Depending on your requirements, you can replicate into the BI system either the entire metadata of an SAP source system (application component hierarchy and DataSources), the DataSource of an application component in a source system, or individual DataSources of a source system.

When you create an SAP source system, an automatic replication of the metadata takes place.

Whenever there is a data request, an automatic replication of the DataSource takes place if the DataSource in the source system has changed.

Replication Process Flow

In the first step, the D versions are replicated.

Here, only 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 the DataSource (R3TR RSDS).

The replication will only be performed if no A or M version of the other object type R3TR ISFS exists for the DataSource.

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

The replication will only be performed if no A or M version of the other object type R3TR RSDS exists for the DataSource.

●      If no BI Content exists in the D version for a DataSource (R3TR OSOD) in BI, the D version cannot be replicated because this version is only 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 relevant metadata. In this way, you avoid generating too many DDIC objects unnecessarily as long as the DataSource is not yet being used – that is, as long as a transformation does not yet exist for the DataSource.

3.x 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 3.x DataSources.

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

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

                            c.      Otherwise, the system asks the user to which object type the DataSource is to be replicated.

Make sure that you replicate the DataSource correctly: For example, if you have modeled the data flow with 3.x objects from BI Content and are thus using update and transfer rules, make sure that you replicate the DataSource to a 3.x DataSource. If you have replicated the DataSource incorrectly, you can no longer use the BI Content data model.

Deleting DataSources 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, during replication,  the system determines 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 no longer available in BI, the system automatically deletes the D version in BI.

If, during replication, the system determines that the A version of a DataSource in the source system is not or no longer available, the BI system asks whether you want to delete the DataSource in BI. If you confirm that you want 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 3.x DataSource, 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 only temporarily not possible to replicate the DataSource, confirming the deletion prompt may cause relevant objects to be deleted.

Automatic Replication During Data Request

You can use a setting in the InfoPackage maintenance under Extras  ® Synchronize Metadata to define that, whenever there is a data request, automatic synchronization of the metadata in BI with the metadata in the source system takes place.  If this indicator is set, the DataSource is automatically replicated from the BI upon each data request – that is, if the DataSource has changed in the source system.

This function ensures that requests are not refused in the source system because of the default time stamp comparison even though the DataSource has not really changed.

With replication, a distinction must be made between DataSource types and the types of changes in the source system.

DataSource (R3TR RSDS)

When a request is created in the InfoPackage, the DataSource is refreshed in BI if the DataSource in the source system has a more recent time stamp than the DataSource in BI. In addition, the DataSource is activated in BI (including transfer structure generation in the source system) if it is older than the DataSource in the source system. However, it is only activated if the object status is “active“ after replication.

This is not the case if changes have been made in the source system to the field property (name, length, type) or if a field has been excluded from the transfer (because, for example, the Hide Field indicator is set in the field list of the DataSource or the field property has been changed in the extraction structure). In these cases, the DataSource is deactivated in BI.

If the DataSource is not active after replication, the system produces an error message. The DataSource must be activated manually.

3.x DataSource (R3TR ISFS)

When a request is created in the InfoPackage, the DataSource replicate is refreshed in BI if the DataSource in the source system has a more recent time stamp than the DataSource replicate in BI. In addition, the transfer structure is activated in BI if it is older than the DataSource in the source system. However, it is only activated if the object status is “active“ after replication.

This is not the case if changes have been made in the source system to the field property (name, length, type) or if a field has been excluded from the transfer (because, for example, the Hide Field indicator is set in the field list of the DataSource or the field property has been changed in the extraction structure). In these cases, the transfer structure is deactivated in BI.

If the transfer structure is not active after replication because, for example, a field property has been changed, no transfer structure exists, or the transfer structure has been deactivated because of changes to the data flow, the system produces an error message; the transfer structure has to be activated manually.

Activities

Replication of the Entire Metadata (Application Component Hierarchy and DataSources) of a Source System

●      Choose Replicate DataSources in the Data Warehousing Workbench in the source system tree through the source system context menu.

or

●      Choose Replicate DataSources in the Data Warehousing Workbench in the DataSource tree through the root node context menu.

Replication of the Application Component Hierarchy of a Source System

Choose Replicate Tree Metadata in the Data Warehousing Workbench in the DataSource tree through the root node context menu.

Replication of the Metadata (DataSources and Possibly Application Components) of an Application Component

Choose Replicate Metadata in the Data Warehousing Workbench in the DataSource tree through an application component context menu.

Replication of a DataSource of a Source System

●      Choose Replicate Metadata in the Data Warehousing Workbench in the DataSource tree through a DataSource context menu.

or

●      In the initial screen of the DataSource repository (transaction RSDS), select the source system and the DataSource and then choose DataSource ®  Replicate DataSource.

Using this function, you can also replicate an individual DataSource that so far did not exist in the BI system. This is not possible in the view for the DataSource tree since a DataSource that has not been replicated so far will not be displayed.

Error Handling

If a DataSource has been replicated into the incorrect object type R3TR RSDS, you can correct the object type by restoring the DataSource in the DataSource repository.

For more information, refer to Restoring 3.x DataSources.