Transferring BW Test and Demo Scenarios with SDATA
Using the tool SDATA - for transferring BW scenario data (transaction RSDATA) - you can transfer BW objects, including data (transaction data and master data), from a source to a target. This is intended for test and demo purposes. The intention of SDATA is to reduce the effort required to set up BW objects and BW data for test and demo scenarios in new environments (initially installed BW systems).
The basic installation is usually sufficient to evaluate the productivity and quality of an SAP BW system version. During the software lifecycle of a BW system, specific business scenarios are needed for test purposes for tasks such as verifying release upgrades or support packages. These business scenario models are often similar to productive models, which are based on a well-defined quantity of BW objects, including the object data. In the following sections of documentation, these models are referred to as "BW test and demo scenarios" or simply "BW scenarios".
Usually once BW scenarios have been created, they are copied in a new environment (target systems for evaluations) using a system copy, or they are manually distributed using the transport connection transport of requests and data provisioning (staging). However, the following documentation describes which system activities are required to distribute BW test and demo scenarios (including their objects and data), which already exist in a system, as target systems in not copied systems by using SDATA.
Possible application areas of SDAA include:
- Setting up test scenarios for support package tests and upgrade tests
- Providing business scenarios for customer validations or proof of concept projects
- Support of upgrade evaluations, preparations and proof of concepts (for example, SAP BW on SAP HANA trial version in the Cloud).
The transfer of BW test and demo scenarios using SDATA is supported by a two-step method:
- The objects and data are exported from a (source) system into a local or global file system.
- The objects and data are imported by the saved SDATA files into the target system.
Prerequisites
- Note the information in the following Notes:
- Authorization object S_RS_SDATA is required for working with SDATA.
- We recommend the following general GUI setting:
Modify Local Layout 
Options Security Security Settings Status: Deactivated
Supported Objects and Data
SDATA supports the following BW objects:
|
Object Category |
Supported Objects |
|---|---|
|
BW Object Main Types |
|
|
Report-Specific Types |
|
|
BW Trace Tool Types |
|
|
Basis Object Types |
|
SDATA can handle the following data types:
- InfoCube data
- Active data of DataStore object (classic) by copying the data content of the A table (see chapter Restrictions for more details)
- Data from a DataStore object (advanced): The request data can be transferred by writing the data via request handling.
- Attribute data and text data of characteristics
- Hierarchy version data for display hierarchies
Limitations
Unfortunately SDATA cannot handle every possible scenario constellation, because SDATA does not support every InfoProvider type and does not support all BW object settings.
General limitations
- SDATA does not currently offer any version concept, except for InfoObjects (metadata) and RSTT traces. If a BW object exists in the source system and in the target system, SDATA cannot identify whether the object versions are identical or inconsistent. The same issue occurs with existing BW data instances such as InfoCube requests or InfoObject attributes.
- In cases where BW objects (start objects) relate to subobjects that are not supported by SDATA, most of the master objects are not set up correctly. Example: a query based on a VirtualProvider with DTP access. Since SDATA cannot transfer DTP objects, the query execution at the end will only be successful if the DTP already exists in the target system.
SDATA helps you to transfer a scenario by helping you with the list of tasks required before or after the transfer.
Object-related limitations
- The data of DataStore objects (classic) can only be used to execute queries. Since SDATA copies the data of the active table directly into the target DSO, the load request status is not consistent. Therefore no data staging activity is possible on the DSO data (for example, using the data transfer process to load data into another data target). In addition, it is currently not possible to create SIDs for all included characteristic values.
- Specific InfoProvider types cannot be transferred: InfoSet, HybridProvider.
- ABAP implementations are not supported. Examples: user exit variables, master data read classes and data access implementations for VirtualProviders. In all these cases, the BW object itself is transferred correctly, but the associated implementation is not transferred.