BI Data Transfer Using the Data Mart Interface in BW

The data transfer is the same as the data transfer in an SAP system. The system reads the data, taking into account the specified dimension-specific selections, from the fact tables of the delivering BI system.

Delta Process

Using the data mart interface, you can transfer data by full upload as well as by delta requests.

A distinction is made between InfoCubes and DataStore objects.

● The InfoCube that is used as an export DataSource is first initialized, meaning that the current status is transferred into the target BI system. When the next upload is performed, only those requests are transferred that have come in since initialization. Different target systems can also be filled like this.

Only those requests are transferred that have been rolled up successfully in the aggregates. If no aggregates are used, only those requests are transferred that are set to Qualitative OK in the InfoCube administration.

● For DataStore objects, the requests in the change log of the DataStore object are used as the basis for determining the delta. Only the change log requests that have arisen from reactivating the DataStore object data are transferred.

Restriction:

You can only make one selection for each target system for the delta.

You first make a selection using cost center 1 and load deltas for this selection. Later on, you also decide to load a delta for cost center 2 in parallel to thecost center 1 delta. The delta can only be fully requested for both cost centers, meaning that it is then impossible to separately execute deltas for the different selections.

Data Distribution in BW BI

Use

As well as data staging and data processing, the data warehousing capabilities in BI also offer processes for distributing data.

You can distribute data within the BI system or load it for other applications in other systems. In the latter case, the BI system is the source, or hub, of the data transfer.

Features

The data transfer process is available for distributing data both within the BI system and to other systems. For more information, see Data Transfer Process.

The data mart interface is available for distributing data to other BI systems. For more information, see Data Mart Interface.

The open hub service is still available for distributing data to other SAP systems or non-SAP systems, however, we recommend that you use the new open hub destination concept. The open hub destination can now be used as an independent object in the data transfer process. For more information, see Open Hub Destination.

Data Transfer Process in BW BI

Definition

Object that determines how data is transferred between two persistent objects.

Use

You use the data transfer process (DTP) to transfer data within BI from one persistent object to another object, in accordance with certain transformations and filters. In this respect, it replaces the data mart interface and the InfoPackage. As of SAP NetWeaver 7.0, the InfoPackage only loads data to the entry layer of BI (PSA).

The data transfer process makes the transfer processes in the data warehousing layer more transparent. Optimized parallel processing improves the performance of the transfer process (the data transfer process determines the processing mode). You can use the data transfer process to separate delta processes for different targets and you can use filter options between the persistent objects on various levels. For example, you can use filters between a DataStore object and an InfoCube.

Data transfer processes are used for standard data transfer, for real-time data acquisition, and for accessing data directly.

Integration

The following graphic illustrates how the data transfer process is positioned in relation to the objects in the dataflow of BI and the other objects in BI process control:

The InfoPackage controls the transfer of data from the source to the entry layer of BI. The data transfer process controls the distribution of data within BI. The graphic illustrates an example of a data update from the DataSource to an InfoProvider. The data can be updated from an InfoProvider to another InfoProvider using a data transfer process. The data transfer process can also be used to control data distribution from a BI system into any target outside of the BI system. For this purpose, a data transfer process with an open hub destination is used as the target.

Features

You use a process chain to define a data transfer process. Alternatively, you can define a data transfer process for an InfoProvider in an object tree in the Data Warehousing Workbench. We recommend that you use process chains. In this case, the data transfer process is executed when it is triggered by an event in the predecessor process in the process chain. Alternatively, in process chain maintenance, you can execute a data transfer process in the background. A debug mode is also available.

The request is an instance that is generated at the runtime of the data transfer process. The request is processed in the steps that have been defined for the data transfer process (extraction, transformation, filter and so on). The monitor for the data transfer process request shows the header information, request status, and the status and messages for the individual processing steps.

With a data transfer process, you can transfer data either in full extraction mode or in delta mode. In full mode, the entire dataset of the source is transferred to the target; in delta mode, only the data that was posted to the source since the last data transfer is transferred. The data transfer process controls delta handling and therefore allows you to fill several targets with different deltas from one source. With a data transfer process, you do not need to explicitly initialize the delta method as you do when copying data with an InfoPackage.

The data transfer process supports you in handling data records with errors. When you define the data transfer process, you can determine how the system responds to errors. At runtime, the incorrect data records are sorted and written to an error stack (request-based database table). A special error DTP further updates the data records from the error stack into the target. It is easier to restart failed load processes if the data is written to a temporary storage after each processing step. It also allows you to find records that have errors. In the monitor for the data transfer process request or in the temporary storage for the processing step (if filled), you can display the data records in the error stack. In data transfer process maintenance, you determine the processing steps after which you want to store data temporarily.

Creating Data Transfer Processes in BW BI

Use

You use the data transfer process (DTP) to transfer data from source objects to target objects within BI. You can also use the data transfer process to access InfoProvider data directly.

Prerequisites

You have used transformations to define the data flow between the source and target object.

Procedure

Creating Data Transfer Processes Using Process Chains

You are in the plan view of the process chain that you want to use for the data transfer process.

The process type Data Transfer Process is available in the Loading Process and Postprocessing process category.

...

1. Use drag and drop or double-click to include the process in the process chain.

2. To create a data transfer process as a new process variant, enter a technical name and choose Create.

The dialog box for creating a data transfer process appears.

3. Select

Creating Data Transfer Processes for Real-Time Data Acquisition in BW BI

Use

You use the data transfer process (DTP) for real-time data acquisition to transfer data to the DataStore object from the PSA. In the DataStore object, the data is available for use in reporting.

Prerequisites

You have used transformations to define the data flow between the DataSource and the DataStore object.

The selections for the data transfer process do not overlap with selections in other data transfer processes.

Procedure

The starting point when creating a data transfer process is the DataStore object into which you want to transfer data. In the Data Warehousing Workbench, an object tree is displayed and you select the DataStore object.

...

1. In the context menu, choose Create Data Transfer Process.

The dialog box for creating a data transfer process appears.

2. Select DTP for Real-Time Data Acquisition as the DTP Type.

3. As the source object, select the DataSource from which you want to transfer data to the DataStore object.

The input help for the source object shows the selection of DataSources that already exist in the data flow for the DataStore object. An additional List pushbutton is available. This allows you to select a DataSource from the complete list of BI DataSources.

4. Choose Continue.

The data transfer process maintenance screen appears.

The header data for the data transfer process shows the description, ID, version, and status of the data transfer process, along with the delta status.

5. On the Extraction tab page, specify the parameters:

a. Delta is chosen as the extraction mode for real-time data acquisition.

b. If necessary, determine filter criteria for the delta transfer. To do this, choose Filter.

This means that you can use multiple data transfer processes with disjunctive selection conditions to efficiently transfer small sets of data from a source into one or more targets, instead of transferring large volumes of data. You can specify individual selections, multiple selections, intervals, selections based on variables, or routines. To change the list of InfoObjects that can be selected, choose Change Selection.

The icon next to pushbutton Filter indicates that predefined selections exist for the data transfer process. The quick info text for this icon displays the selections as a character string.

c. Semantic grouping is not used for real-time data acquisition. The data is read from the source in packages.

6. On the Update tab page, specify the parameters:

Make the settings for error handling. You define:

○ How you want to update valid records when errors occur.

○ How many errors can occur before the load process terminates.

Note that this setting only has an impact while repairing a DTP request (repair) and during the conversion of the DTP to standard DTP (for example, to correct an error during extraction).

For real-time data acquisition, specify in the InfoPackage the maximum number of failed attempts that is permitted when the daemon is accessing data before the data transfer terminates with an error.

For more information about error handling settings, see Handling Data Records with Errors.

7. On the Execute tab page, determine the parameters:

On this tab page, the process flow of the program for the data transfer process is displayed in a tree structure.

a. Specify the status that you want the system to adopt for the request if warnings are to be displayed in the log.

b. Specify how you want the system to define the overall status of the request.

8. Check, save, and activate the data transfer process.

9. With Assign Daemon you go to the monitor for real-time data acquisition if there is already an InfoPackage for RDA for the DataSource that is the source for this DTP.

If there is not yet an InfoPackage for RDA for the DataSource that is the source for this DTP, the system informs you that you must first create an InfoPackage for RDA before you can assign the DTP.

Alternatively you can go to the monitor for real-time data acquisition from the context menu entry Assign RDA Daemon of the data transfer process if you are in the Data Warehousing Workbench.

Result

The data transfer process is assigned to the DataSource.

If the DataSource is already assigned to a daemon, the data transfer process appears in the monitor for real-time data acquisition under this daemon and the DataSource. It is now available for data processing by the daemon.

If the DataSource has not yet been assigned to a daemon, the data transfer process appears in the monitor for real-time data acquisition under the DataSource in the area Unassigned Objects. The data transfer process, the corresponding DataSource, the InfoPackage and possibly further associated data transfer processes are assigned to the specified daemon in the context menu of the data transfer process with Assign Daemon..

Creating Data Transfer Processes for Direct Access in BW BI

Use

You use a data transfer process for direct access to access the data in an InfoProvider directly.

Prerequisites

You have used transformations to define the data flow between the source and target object.

Procedure

The starting point when creating a data transfer process is the target into which you want to transfer data. In the Data Warehousing Workbench, an object tree is displayed and you have highlighted the target object, a VirtualProvider.

...

1. In the context menu, choose Create Data Transfer Process.

The dialog box for creating a data transfer process appears.

DTP for Direct Access is displayed as the type of the data transfer process.

2. Select the type of source object.

Supported object types are DataSources, InfoCubes, DataStore objects and InfoObjects (texts and attributes, if they are released as InfoProviders).

3. Select the object from which you want to transfer data into the target.

When you select the source object, input help is available. Input help shows you the selection of objects that already exist in the data flow for target object. If only one object exists in the data flow, this is selected by default.

An additional List pushbutton is available. This allows you to select a source object from the complete list of objects that exist for this object type.

4. Choose Continue.

The data transfer process maintenance screen appears.

The header data for the data transfer process shows the description, ID, version, and status of the data transfer process, along with the delta status.

On the Extraction tab page, the system displays information about the adapter, the format of the data and additional source-specific settings.

On the Update tab page, the system displays information about the target.

On the Execute tab page, the system displays the processing mode for direct access and the process flow of the program for the data transfer process.

You do not need to make any settings in the data transfer process.

5. Check the data transfer process, save and activate it.

Choose Goto ® Overview of DTP to display information about the source and target objects, the transformations, and the last changes to the data transfer process.

Result

You can use the data transfer process to access data directly.

Handling of Data Records with Errors in BW BI

Use

On the Update tab page in the data transfer process (DTP), the error handling settings allow you to control how the system responds if errors occur in the data records when data is transferred from a DTP source to a DTP target.

These settings were previously made in the InfoPackage. When using data transfer processes, InfoPackages only write to the PSA. Therefore, error handling settings are no longer made in the InfoPackage but in the data transfer process.

Features

Settings for Error Handling

For a data transfer process (DTP), you can specify how you want the system to respond when data records contain errors. If you activate error handling, the records with errors are written to a request-based database table (PSA table). This is the error stack. You can use a special data transfer process, the error DTP, to update the records to the target.

Temporary storage is available after each processing step of the DTP request. This allows you to determine the processing step in which the error occurred.

Checks for Incorrect Data Records

The following table provides an overview of where checks for incorrect data records can be run:

Where Is Check Run?	Examples of Incorrect Data Records
In the transformation	Field contains invalid characters or lowercase characters Error during conversion Error during currency translation A routine returns a return code <> 0 Characteristic value is not found for master data Error reading master data Customer-specific formula results in error
When data is updated to the master data table or text table	Invalid characters in keys or navigation attributes If no SID exists for the value of the navigation attribute If no language field is defined for texts Invalid "from" and "to" dates Duplicate data records with relation to keys Overlapping and invalid time intervals
When data is updated to the InfoCube	If no SID exists for the characteristic value
When checking referential integrity of an InfoObject against master data tables or DataStore objects	If no SID exists for the characteristic value

"Repairing" with Error DTP

You create an error DTP for an active data transfer process on the Update tab page. You run it directly in the background or include it in a process chain so that you can schedule it regularly in the context of your process chain. The error DTP uses the full update mode to extract data from the error stack (in this case, the source of the DTP) and transfer it to the target that you have already defined in the data transfer process.

Activities

...

1. On the Extraction tab page under Semantic Groups, define the key fields for the error stack.

This setting is only relevant if you are transferring data to DataStore objects with data fields that are overwritten. If errors occur, all subsequent data records with the same key are written to the error stack along with the incorrect data record; they are not updated to the target. This guarantees the serialization of the data records, and consistent data processing. The serialization of the data records and thus the explicit definition of key fields for the error stack is not relevant for targets that are not updated by overwriting.

The default value and possible entries for the key fields of the error stack for DataStore objects that overwrite are shown below:

Default Value/Possible Entries	Which Fields of the Source?
Default value for the key fields of the error stack (fields selected by the system)	All fields of the source that are uniquely assigned to a key field of the target. That is, all the fields of the source that are directly assigned to a key field of the DataStore object in the transformation.
Fields that can also be selected as key fields for the error stack

Error Stack in BW BI

Definition

A request-based table (PSA table) into which erroneous data records from a data transfer process are written. The error stack is based on the data source, that is, records from the source are written to the error stack.

Use

At runtime, erroneous data records are written to an error stack if the error handling for the data transfer process is activated. You use the error stack to update the data to the target destination once the error is resolved.

Integration

In the monitor for the data transfer process, you can navigate to the PSA maintenance by choosing Error Stack in the toolbar, and display and edit erroneous records in the error stack.

With an error DTP, you can update the data records to the target manually or by means of a process chain. Once the data records have been successfully updated, they are deleted from the error stack. If there are any erroneous data records, they are written to the error stack again in a new error DTP request.

When a DTP request is deleted, the corresponding data records are also deleted from the error stack.

Examples for Using the Error Stack in BW BI

Consistent Error Handling for Aggregation

Number of Records in Source is Greater than Number of Records in Target

During the transformation, the data records for request 109882 are aggregated to one data record. If, for example, there is no SID for the characteristic value order number 1000, the record is interpreted as erroneous. It is not updated to the target. Those data records that form the aggregated data record are written to the error stack.

Number of Records in Source is Less than Number of Records in Target

During the transformation, the data record for request 109882 is duplicated to multiple data records. If, for example, there is no SID for the characteristic value calendar day 07-03-2005, the record is interpreted as erroneous. The duplicated records are not updated to the target. The data record that formed the duplicate records is written to the error stack. In the error stack, the record is listed as containing an error every time it duplicates data records with errors.

Consistent Error Handling with Respect to Order in Which Data Records are Written to Error Stack

Update to DataStore Object: 1 Request

The Order Number field is the key for the error stack. During the transformation, data record 02 of request 109882 is marked as containing errors. In addition to the erroneous data record, all subsequent data records for the request that contain the same key are written to the error stack. In this example, this is data record 03. This ensures that when error records are updated with the error DTP, the records are serialized correctly and newer data is not inadvertently overwritten by older data. Data record 01 has the same key as the incorrect data record 02 (order number 1000), but is correct and it occurred before the incorrect data record. Data record 01 is therefore copied into the target of the DTP. The order of the data records is not changed.

Updating to DataStore Object: Multiple Requests – Error in First Request

The Order Number field is the key for the error stack. During the transformation, data record 02 of request 109882 is marked as containing errors. In addition to the erroneous data record, all subsequent data records, including the following requests that have the same key, are written to the error stack. In this example, data record 01 for request 109883 is written to the error stack in addition to data record 02 for request 109882.

Updating to DataStore Object: Multiple Requests – Error in Subsequent Request

The Order Number field is the key for the error stack. During the transformation, data record 01 of request 109883 is identified as containing errors. It is written to the error stack. Any data records from the previous request that have the same key were updated successfully to the target.

Temporary Storage in BW BI

Definition

Table that contains the data records processed with the request in a specific data transfer process (DTP) processing step. The table contains correct records as well as erroneous records with a status display.

Use

The temporary storage is used at runtime to allow processes to be restarted without a significant impact on performance and consistency when errors occur. It also allows you to find records with errors. Unlike on the source level, this is only possible if, under Level of Detail, you have set Trace of Erroneous Records or Trace of Transformation by Records.

Integration

You make the settings for the temporary storage in the maintenance routine for a DTP from the menu Goto. For more information, see Handling Data Records with Errors.

You can display the temporary storage for each of the processing steps using the monitor for the data transfer process request by choosing the pushbutton in the Data column. The records with errors can be identified by the symbol. For more information, see Monitor.

Handling Duplicate Data Records in BW BI

Use

DataSources for texts or attributes can transfer data records with the same key into BI in one request. Whether the DataSource transfers multiple data records with the same key in one request is a property of the DataSource. There may be cases in which you want to transfer multiple data records with the same key (referred to as duplicate data records below) to BI more than once within a request; this is not always an error. BI provides functions to handle duplicate data records so that you can accommodate this.

Features

In a dataflow that is modeled using a transformation, you can work with duplicate data records for time-dependent and time-independent attributes and texts.

If you are updating attributes or texts from a DataSource to an InfoObject using a data transfer process (DTP), you can specify the number of data records with the same record key within a request that the system can process. In DTP maintenance on the Update tab page, you set the Handle Duplicate Record Keys indicator to specify the number of data records.

This indicator is not set by default.

If you set the indicator, duplicate data records (multiple records with identical key values) are handled as follows:

● Time-independent data:

If data records have the same key, the last data record in the data package is interpreted as being valid and is updated to the target.

● Time-Dependent Data

If data records have the same key, the system calculates new time intervals for the data record values. The system calculates new time intervals on the basis of the intersecting time intervals and the sequence of the data records.

Data record 1 is valid from 01.01.2006 to 31.12.2006

Data record 2 has the same key but is valid from 01.07.2006 to 31.12.2007

The system corrects the time interval for data record 1 to 01.01.2006 to 30.06.2006. As of 01.07.2006, the next data record in the data package (data record 2) is valid.

If you set the indicator for time-dependent data, note the following:

You cannot include the data source field that contains the DATETO information in the semantic key of the DTP. This may cause duplicate data records to be sorted incorrectly and time intervals to be incorrectly calculated.

The semantic key specifies the structure of the data packages that are read from the source.

Example

You have two data records with the same key within one data package.

In the following graphic, DATETO is not an element of the key:

In the data package, the data records are in sequence DS2, DS1. In this case, the time interval for data record 1 is corrected:

Data record 1 is valid from 1.1.2002 to 31.12.2006.

Data record 2 is valid from 1.1.2000 to 31.12.2001.

In the following graphic, DATETO is an element of the key:

If DATETO is an element of the key, the records are sorted by DATETO. In this case, the data record with the earliest date is put before the data record with the most recent date. In the data package, the data records are in sequence DS2, DS1. In this case, the time interval for data record 2 is corrected:

Data record 2 is valid from 1.1.2000 to 31.12.2000.

Data record 1 is valid from 1.1.2001 to 31.12.2006.

If you do not set this indicator, data records that have the same key are written to the error stack of the DTP.

Note

You can specify how duplicate data records within a request are handled, independently of whether the setting that allows DataSources to deliver potentially duplicate data records has been made. This is useful if the setting was not made to the DataSource, but the system knows from other sources that duplicate data records are transferred (for example, when flat files are loaded).

Monitor in BW BI

Use

A request is generated to execute your data transfer process (DTP). The monitor for data transfer processes allows you to keep track of the request in the various processing steps.

Integration

The request status and request messages from the data transfer processes and the InfoPackage loading processes are integrated into the monitor for loading processes, which you can call in the Administration functional area of the Data Warehousing Workbench by choosing Monitors ® Load Data.

You can also call the monitor using data transfer process maintenance, using the process monitor on a DTP in the log view of the process chain maintenance, or using the Call Monitor function for a target object in an object tree in the Data Warehousing Workbench.

If you call the monitor for a data transfer process with the indicator Get All New Data in Source Request by Request using the log view of a process chain run, a list of the DTP requests that all source requests retrieved within the process chain run is displayed.

Note that DTPs that were created prior to SAP NetWeaver 7.0 SPS12 behave in a different manner: If you set the indicator, the first request of the source is retrieved with only one DTP request. In this case the process monitor displays only this one DTP request.

More information: Creating Data Transfer Processes

Features

The monitor for a data transfer process request displays detailed information about the processing of the request, in addition to the header information.

At the first level of the detail tree, the system displays the status of the requests at various points during the process, for example, at generation, when processing the steps during the DTP program, and when setting the technical and complete status of the request. The status display for the processing is then divided further according to the steps of the data transfer process and displays the status and messages for each of the processing steps and data packages in the processing steps.

At the processing step level, you can also branch into the temporary storage display for this particular processing step if you have defined in DTP maintenance that the temporary storage is to be filled after this processing step. You can jump to the PSA maintenance for the error stack if data has been written to the error stack and has not been updated yet.

If the DTP is used in a process chain, you can jump to the log view of the process chain run in which the DTP request was processed from within the monitor by choosing Process Chain. You can also jump in the case of deleted requests.

From the monitor, you can branch to the where-used list for the request. This allows you to display independent target requests and delete requests consistently. More information: Where-Used List for Requests.

You can also branch to the administration for the source and the target (DataSource or InfoProvider), as well as to the job and process overviews.

With Debugging you can Simulate and Debug DTP Requests.

Where-Used List for Requests in BW BI

Use

The where-used list supports you in finding dependent requests in further targets. The where-used list therefore allows you to delete across several persistence layers.

Integration

You can call the where-used list for DTP requests in InfoCubes and DataStore objects if the request has already been loaded into other data targets. You can also call the where-used list for requests in the PSA tables of the DataSource (R3TR RSDS).

Features

The where-used list displays the source request and all related target requests in a hierarchy. You can delete requests directly from the where-used list display.

Simulating and Debugging DTP Requests in BW BI

Use

Simulating the data update and debugging a data transfer process request (DTP request) help you to analyze an incorrect DTP request.

In this way you can also simulate a transformation prior to the actual data transfer if you would like to check whether it provides the desired results.

Procedure

Simple Simulation and Debugging

...

1. If you want to execute a standard DTP in debug mode, choose Serially in the Dialog Process (for Debugging) as the processing mode on the Execute tab page in the DTP maintenance.

2. In the overview for program execution, define breakpoints for debugging by choosing Change Breakpoints.

3. Choose This graphic is explained in the accompanying text

Data Mart Interface in BW BI

Purpose

The data mart interface makes it possible to update data from one InfoProvider to another.

You have the following options:

● Data exchange of multiple BI Systems: the data-delivering system is referred to as the Source B; the data-receiving system as the Target BI. The individual BI systems arranged in this way are called data marts. The InfoProviders of the source BI are used as sources of data here.

● Data exchange between BI systems and other SAP systems

More information: Data Mart Interface Between Several Systems

Data marts can be used in different ways:

● They save a subset of the data of a Data Warehouse in another database, possibly even in a different location.

● They are smaller units of a Data Warehouse.

● They are stored as intentionally redundant segments of the (logical, global) overall system (Data Warehouse).

Features

A BI system defines itself as the source system for another BI system by:

● Providing metadata

● Providing transaction data and master data

An export DataSource is needed to transfer data from a source BI into a target BI. Export DataSources for InfoCubes and DataStore objects contain all the characteristics and key figures of the InfoProvider. Export DataSources for master data contain the metadata for all attributes, texts, and hierarchies for an InfoObject.

Data Mart Interface Between Several Systems in BW BI

Use

The data mart interface can be used between two BI Systems or between another SAP system and a BI System:

· to enable large amounts of data to be processed

· to increase the respective speeds of data transfer, logging and analysis.

· to achieve improved concision and maintenance of the individual Data Warehouses.

· to enable data separation relating to the task area, on the one hand, and to be able to perform analyses of the state of the entire dataset on the other.

· to make it possible to have fewer complexities when constructing and implementing a Data Warehouse.

· to construct hub and spoke scenarios in which a BI System stands in the middle and the data from distributed systems runs together and is standardized.

Integration

Data marts are found both in the maintenance and in the definition, the same as in the SAP source system. Here too, you can group together data from one or more source systems in a BI System, or continue to work in several BI Systems.

Features

These functions can produce different architectures in a Data Warehouse landscape.

Replicating Architecture:

If you select this architecture, the data for a BI server is available as source data and can be updated in further target BI Systems.

Aggregating Architecture:

With aggregating architecture, data is grouped together from two or more BI servers, and is then available for further processing.

Using the Data Mart Interface in BW BI

Purpose

If you want to define an existing BI system as a source system, access the functions of the data mart.

Process Flow

1. In the Source BI

Before a BI system can request data from another BI system, it must have information about the structure of the data to be requested. To do this, you have to upload the metadata from the source BI into the target BI.

You generate an export DataSource for the respective InfoProvider in the source BI. This export DataSource includes an extraction structure, which contains all the characteristics and key figures of the InfoProvider.

For InfoCubes/DataStore objects, see: Generating Data Target Export DataSources

For InfoObjects, see: Generating Master Data Export DataSources

2. In the Target BI

...

1. If required, define the source system. This is only necessary if the source system has not yet been created in the target BI.

2. Create the InfoProvider into which the data is to be loaded.

3. Replicate the metadata of your export DataSource from your source BI into your target BI. Using the source system tree, you can replicate all the metadata of a source system, or only replicate the metadata of your DataSource.

More information: Metadata Upload for SAP Systems

4. Activate the DataSource.

5. Create an InfoPackage at your DataSource using the context menu. Your source BI system is specified as the source by default.

More information: Creating InfoPackages

6. Using the context menu for your DataSource, create a data transfer process with the InfoProvider into which the data is to be loaded as the target. A default transformation is created at the same time.

More information: Creating Data Transfer Processes

The complete data flow is displayed in the InfoProvider tree under your InfoProvider.

7. Schedule the InfoPackage and the data transfer process. We recommend that you always use process chains for loading processes.

More information: Creating Process Chains

Result

You have loaded data from one BI system into another BI system.

Generating Export DataSources for InfoProviders in BW

Use

The export DataSource is needed to transfer data from a source BI system into a target BI system. You can use the selected InfoProvider as a DataSource for another BI system.

Prerequisites

The source BI system must be created and actively saved in the target BI system as the BI source system.

More information: Creating SAP Source Systems

Procedure

...

1. In the Data Warehousing Workbench in the BI source system, choose Modeling and select the InfoProvider tree.

2. Generate the export DataSource using the context menu of your InfoProvider. To do this, choose Additional Functions ® Generate Export DataSource.

The technical name of the export DataSource is made up of the number 8 together with the name of the InfoProvider.

Technical name of an InfoCube: COPA

Technical name of the export DataSource: 8COPA

Generating Master Data Export DataSources in BW BI

Use

The export DataSource is needed to transfer data from a source BI system into a target BI system.

You can generate an export DataSource for master data, and thus for individual InfoObjects. By doing this, all the metadata is created that is required to extract master data (all attributes, texts, and hierarchies) from an InfoObject.

Prerequisites

The source BI system must have been created and actively saved in the target BI system as a BI source system.

More information: Creating SAP Source Systems

Procedure

...

1. Select the InfoObject tree in the Data Warehousing Workbench in the source BI system.

2. Generate the export DataSource from the context menu of your InfoObject. To do this, choose Additional Functions ® Generate Export DataSource.

The technical name of the export DataSource is

8******M for attributes (M stands for master data)

8******T for texts

8******H for hierarchies.

(The asterisks (*) stand for the source InfoObject).

When you create an InfoObject or a master data InfoSource in the source BI system, you must therefore make sure that the length of the technical name of each object is no longer than 28 characters.

Data Transfer Using the Data Mart Interface in BW BI

The data transfer is the same as the data transfer in an SAP system. The system reads the data, taking into account the specified dimension-specific selections, from the fact tables of the delivering BI system.

Delta Process

Using the data mart interface, you can transfer data by full upload as well as by delta requests.

A distinction is made between InfoCubes and DataStore objects.

● The InfoCube that is used as an export DataSource is first initialized, meaning that the current status is transferred into the target BI system. When the next upload is performed, only those requests are transferred that have come in since initialization. Different target systems can also be filled like this.

Only those requests are transferred that have been rolled up successfully in the aggregates. If no aggregates are used, only those requests are transferred that are set to Qualitative OK in the InfoCube administration.

● For DataStore objects, the requests in the change log of the DataStore object are used as the basis for determining the delta. Only the change log requests that have arisen from reactivating the DataStore object data are transferred.

Restriction:

You can only make one selection for each target system for the delta.

You first make a selection using cost center 1 and load deltas for this selection. Later on, you also decide to load a delta for cost center 2 in parallel to thecost center 1 delta. The delta can only be fully requested for both cost centers, meaning that it is then impossible to separately execute deltas for the different selections.