Show TOC

Replication of DataSourcesLocate this document in the navigation structure

The metadata of SAP source systems is independent of BW metadata. There is no implicit assignment of objects using identical 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 BW so that data can be read more quickly. The assignment of source system objects to BW objects takes place exclusively and centrally in BW.

In the SAP source system, the DataSource is the BW-relevant metaobject that makes source data available in a flat structure for data transfer into BW. A DataSource can be in the source system in the SAP delivery version (D version: Object type R3TR OSOD) and the active version (A version: Object type R3TR OSOA). There are two types of DataSources in BW. A DataSource can either be 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.

Besides the DataSources, the application component hierarchy where the DataSources of a source system are grouped belongs to the metadata that can be replicated to BW.

You can define the scope as required by replicating metadata to the BW system. You can:

  • Replicate the entire metadata of a SAP source system (application component hierarchy and DataSources).
  • Replicate the DataSources of an application component of a source system.
  • Replicate individual DataSources of a source system.
Prerequisites

You have connected the source system to BW correctly.

Execute Replication

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 Entire Metadata (Application Component Hierarchy and DataSources) of a Source System

You have the following options:

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

If you replicate all the metadata of a source system, the switches of the business functions available in the switch framework of the source system are also replicated. The switches control the visibility of query parts in Business Content queries. For more information, see Replicating Switches.

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

You have the following options:

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

    or

  • On the initial screen of the DataSource repository (transaction RSDS), select the source system and the DataSource and then choose Start of the navigation path DataSource Next navigation step Replicate DataSource End of the navigation path.

    Using this function, you can also replicate an individual DataSource that did not previously exist in the BW system.

Make Replication Settings

If you execute the replication at the level of the source system or an application component, you can use a dialog box to make different settings to influence the replication process. These allow you to define which DataSources are replicated, thus speeding up the replication process.

  • Under Replication Scope, you can define if DataSources are to be executed in active and/or delivery version during the replication.
  • Under Allow creation of BW DataSources you can define whether DataSources that are not known yet in the BW system should be created there and, which object type they should be created in (R3TR RSDS or R3TR ISFS).
    Note Note that the selectio of the object type is only taken into consideration if no other reasons specify the object type (for example, the existence of BI Content for one of the two object types).
  • Under Deletion of DataSources you can define whether DataSources that do not exist any more in the source system should be created in the BW system.
  • Under Reactivation of Changed (Active) DataSources, you can define when and how DataSources that had already been activated prior to replication should be reactivated.

On the next dialog box, all DataSources are displayed with a flag that are intended for the replication according to the settings that were previously made. You can define here which DataSouces are actually to be replicated. If, for example, only one or a couple of DataSources are to be created, then those can be selected here.

Replication Process Flow

In the first step, the D versions are replicated provided you have selected it for replication in the dialog box.

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

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

    Note

    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 BW shadow content, the relevant metadata is replicated in the DataSource (R3TR ISFS).

    Note

    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 BW Content exists in the D version for a DataSource (R3TR OSOD) in BW, the D version cannot be replicated because this version is only used in BW for BW Content activation.

In the second step, the A versions are replicated.

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

3.x DataSources (R3TR ISFS) are saved in BW 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 BW in the A or D version, the DataSource is replicated to the existing object.

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

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

      • Hierarchy DataSources are replicated to 3.x DataSources.

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

    2. If there is a D version in BW for a mapping object (R3TR ISMP), the system replicates to the 3.x DataSource (R3TR ISFS).

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

      Caution

      Make sure you replicate the DataSource correctly: For example, if you have modeled the data flow with 3.x objects from BI Content and used update and transfer rules, ensure that you replicate the DataSource to a 3.x DataSource. If you replicate the DataSource incorrectly, you can no longer use the BW 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 the system determines upon replication that the D version of a DataSource in the source system or the associated BW Content (shadow objects of DataSource R3TR SHDS or shadow objects of mapping R3TR SHMP) is not (or is no longer) available in BW, the system automatically deletes the D version in BW.

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 BW system asks whether you want to delete the DataSource in BW. 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.

Caution

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.

Automatic Replication During Data Request

You can use a setting in the InfoPackage maintenance under Start of the navigation path Extras Next navigation step Synchronize Metadata End of the navigation path to define that, whenever there is a data request, automatic synchronization of the metadata in BW with the metadata in the source system takes place. If this indicator is set, the DataSource is automatically replicated from BW 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 changed substantially.

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

  • DataSource (R3TR RSDS)

    If a request is created in the InfoPackage, the DataSource in BW is updated if the DataSource in the source system has a later time stamp than the DataSource in BW. The DataSource in BW is also activated (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 BW.

    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)

    If a request is created in the InfoPackage, the DataSource replica in BW is updated if the DataSource in the source system has a later time stamp than the DataSource replica in BW. The transfer strcuture in BW is also activated 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 BW.

    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.

Using 3.x Emulated Replicated DataSources

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

More information: Emulation, Migration, and Restoring DataSources

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.

More information: Manually Restoring 3.x DataSources