Free SAP Business Warehouse (BW) Books, Faqs, Material

Functions in the SAP Source System in BI

2009-02-12T10:47:00.000+05:30

Use

The BI Service API (SAPI) is a technology package in the SAP source system that enables the close integration of data transfer from SAP source systems into a BI system.

The SAPI allows you to

● make SAP application extractors available as a basis for data transfer into BI

● carry out generic data extraction

● use intelligent delta processes

● access data in the source system directly from BI (VirtualProvider support)

With transaction SBIW, the SAPI provides an implementation guide in the SAP source system that includes the activities necessary for data extraction and data transfer from an SAP source system into BI.

Irrespective of the type of SAP source system, Customizing for extractors comprises activities that belong to the scope of SAPI:

● general settings for data transfer from a source system into BI

● the option of installing BI Content delivered by SAP

● the option of maintaining generic DataSources

● the option of postprocessing the application component hierarchy and DataSources on a source system level

In addition to the activities that are part of the scope of SAPI, Customizing for extractors for OLTP and further SAP source systems may contain source-system specific settings for application-specific DataSources.

Features

General Settings

General settings include the following activities:

● Maintaining control parameters for data transfer

● Restricting authorizations for extraction

● Monitoring the delta queue

Installing BI Content Delivered by SAP

DataSources delivered with the BI Content by SAP and those delivered by partners appear in a delivery version (D version). If you want to use a partner or BI Content DataSource to transfer data from a source system into BI, you need to transfer this DataSource from the D into the active (A) version.

In the source system, the DataSources are assigned to specific application components. If you want to display the DataSources in BI in the DataSource tree of the Data Warehousing Workbench according to this application component hierarchy, you need to transfer them from the D version into the A version in the source system.

Transferring data from an OLTP system or other SAP source systems

Note: You need to make settings for some BI Content DataSources before you can transfer data into BI. These settings are listed in transaction SBIW in the Settings for Application-Specific DataSources section. You can only find this section in those SAP source systems for which it is relevant.

The following activities are associated with installing BI Content:

● Transferring application component hierarchies

● Installing Business Content DataSources

Generic DataSources

Regardless of the specific application, you can use generic data extraction to extract data from any transparent tables, database views or SAP Query functional areas. You do not need to program in ABAP. You can also use function modules for generic data extraction.

In this way, you can use your own DataSources for transaction data, master data attributes or texts. The data for such DataSources is read generically and then transferred into BI.

Generic DataSources allow you to extract data which cannot be supplied to BI either with the DataSources delivered with BI Content or with customer-defined DataSources of the application.

For more information, see Maintaining Generic DataSources.

Postprocessing DataSources

You can adapt existing DataSources to suit your requirements as well as edit the application component hierarchy for the DataSources.

For more information, see Editing DataSources and Application Component Hierarchies .

Maintaining Control Parameters for Data Transfer in BI

2009-02-12T10:46:00.000+05:30

Procedure

Maintain entries for the following fields:

...

1. Source system

Enter the logical system for your source client and assign a control parameter to it.

For information about source clients, see the source system under Tools ® Administration ® Management ® Client Management ® Client Maintenance.

2. Maximum size of the data package

When you transfer data into BI, the individual data records are sent to BI in packages of variable size. You use this parameter to control the typical size of a data package of this type.

If you do not maintain an entry, the data is transferred with the default setting of 10,000 kBytes per data package. However, the required memory depends not only on the data package size setting, but also on the width of the transfer structure, the required memory of the affected extractor, and, for large data packages, the number of data records in the package.

3. Maximum number of rows in a data package

For large data packages, the required memory mainly depends on the number of data records that are transferred with the package. You use this parameter to control the maximum number of data records that you want the data package to contain.

By default, the system transfers a maximum of 100,000 records per data package.

The maximum main memory required per data package is approximately 2 X ’Max. Rows’ X 1000 bytes.

4. Frequency

By specifying a frequency you determine the number of data IDocs after which an info IDoc is to be sent. In other words, how many data IDocs are described by a single info IDoc.

The frequency is set to 1 by default. This means that an info IDoc follows after each data IDoc. You should choose a frequency between 5 and 10, but not greater than 20.

The larger the package size of a data IDoc, the lower you should set the frequency. As a result, you get information about the data load status during the data upload at relatively short intervals.

In the BI monitor, you can see from each info IDoc whether the load process was successful. If this is the case for all data IDocs described in an info IDoc, the traffic light in the monitor is green. Info IDocs contain information about whether the data IDocs were correctly uploaded.

5. Maximum number of parallel processes for the data transfer

An entry in this field is only required as of Release 3.1I.

Enter a value greater than 0. The maximum number of parallel processes is set to 2 by default. The optimal choice of the parameter depends on the configuration of the application server that you are using for the data transfer.

6. Target system of a batch job

Enter the name of the application server on which you want to process the extraction job.

To get the name of the application server, choose Tools ® Administration ® Monitor ® System Monitoring ® Server. The Host column displays the name of the application server.

7. Maximum number of data packages in a delta request

You use this parameter to set the maximum number of data packages in a delta request or in the repeat of a delta request (repair).

Only use this parameter if you are expecting delta requests with a very large volume of data. In this case, you allow more than 1000 data packages to be generated in a request, while retaining an appropriate data package size.

As before, there are no limits for initials values or the value 0. A limit is only applied if you have a value that is greater than 0. However, for consistency reasons this number is not always strictly adhered to. Depending on the extent to which the data in the qRFC queue is compressed, the actual limit can deviate by up to 100 from the specified value.

Restricting Authorizations for Extraction in BI

2009-02-12T10:44:00.001+05:30

UseYou use this function to exclude DataSources from the extraction. Data that is stored in these DataSources is not transferred into BI.

Use this function to exclude DataSources from the extraction for individual BI systems. If you want to exclude a DataSource from the extraction for all connected BI systems, in the post-processing of DataSources, choose editing DataSources and application component hierarchies and delete the DataSource.

Procedure

...

1. Choose New Entries.

2. Choose the DataSource that you want to exclude from the extraction.

3. Choose the BI system into which you no longer want data from this DataSource to be extracted.

4. In the Extr. Off field, specify that the DataSource is to be excluded from the extraction.

5. Save your entries and specify a transport request.

Delta Queue Check in BI

2009-02-12T10:43:00.001+05:30

Use

The delta queue is a data store in the source system into which data records are written automatically. The data records are written to the delta queue either using an update process in the source system (for example with FI documents) or are extracted using a function module when data is requested from BI (for example, LIS extraction prior to BW 2.0).

With a delta request, the data records are transferred into BI from the scheduler.

The data is stored in compressed form in the delta queue. It can be requested from several BI systems. The delta queue is also repeat enabled; it stores the data from the last extraction process. The repeat mode of the delta queue is specific to the target system.

If the extraction structure of a DataSource is changed after data is written into the delta queue but before the queue data is read (for example, when you upgrade), you can tell which structure in the delta queue the data was written to from the data itself. The queue monitor contains fields that were not filled before but are now filled and/or fields that were filled before but are no longer filled.

You use this function to check the delta queue.

Features

The status symbol shows whether an update into a delta queue is activated for a particular DataSource. The delta queue is active if the status symbol is green; it is filled with data records when there is an update process or data request from BI. The delta method has to be initialized successfully in the scheduler in BI before a delta update can take place.

You can carry out the following activities:

● Display data records

● Display the current status of the delta-relevant field

● Refresh

● Delete the queue

● Delete queue data

Activities

Displaying Data Records

...

1. To check the amount and type of data in the delta queue, select the delta queue and choose Display Data Records.

2. A dialog box appears in which you can specify how you want to display the data records.

a. You can select the data packages that contain the data records you want to see.

b. You can display specific data records in the data package.

c. You can simulate the extraction parameters to select how you want to display the data records.

3. To display the data records, choose Execute.

Displaying Current Status of Delta-Relevant Field

For DataSources that support generic deltas, you can display the current value of the delta-relevant field in the delta queue. In the Status column, choose Detail. The value displayed includes the largest value for the last extraction with reference to the delta-relevant field. It is the lower limit for the next extraction.

Refreshing

If you select refresh,

● newly activated delta queues are displayed

● new data records that have been written to the delta queue are displayed

● data records that have been deleted by the time the system reads the data records are not displayed

Deleting Queue Data

To delete the data in a delta queue for a DataSource, select the delta queue and in the context menu, choose Delete Data.

If you delete data from the delta queue, you do not have to reinitialize the delta method to write the DataSource data records into the delta queue.

Note that data is also deleted that has not yet been read from the delta queue. As a result, any existing delta update is invalidated. Only use this function when you are sure that you want to delete all queue data.

Deleting Queues

You can delete the entire queue by choosing Queue ® Delete Queue. You need to reinitialize the delta method before you can write data records for the related DataSource into the delta queue.

Installing Application Component Hierarchies in BI

2009-02-12T10:42:00.000+05:30

You use this function to install and activate application component hierarchies delivered by SAP or by partners.

After the DataSources are replicated in BI, this application component hierarchy is displayed with the transferred DataSources in the source system view of the Data Warehousing Workbench – Modeling. In BI, choose the DataSource overview from the context menu (right-mouse click) for the source system.

If you activate the BI Content application component hierarchy, the active customer version is overwritten when you install the BI Content version.

For information about changing the installed application component hierarchy, see Editing DataSources and Application Component Hierarchies.

Installing BI Content DataSources in BI

2009-02-12T10:41:00.000+05:30

Use

You use this function to transfer and activate DataSources delivered with BI Content and, where applicable, partner DataSources delivered in their own namespaces. After installing BI Content DataSources you can extract data from all the active DataSources that you have replicated in BI and transfer this data to all connected BI systems.

Activities

The Install DataSources from BI Content screen displays the DataSources in an overview tree. This tree is structured in accordance with the application components assigned to you.

...

1. In the application component hierarchy, select the nodes for which you want to install DataSources in the active version. To do this, position the cursor on the node and choose Highlight Subtree.

The DataSources and subtrees below the node are selected.

2. Choose Select Delta.

DataSources where the system found differences between the active and the delivered version (due to changes to the extractor, for example) are highlighted in yellow.

3. To analyze the differences between active and delivered versions of a particular DataSource, select the DataSource and choose Version Comparison. The application log contains further information about the version comparison.

4. To transfer a DataSource from the delivery version to the active version, select it in the overview tree by choosing Highlight Subtree and choose Transfer DataSources.

If an error occurs, the error log appears.

Regardless of whether data has been successfully transferred into the active version, you can call the log by choosing Display Log.

With a metadata upload (when you replicate DataSources in BI), the active version of the DataSource is made known to BI.

When you activate BI Content DataSources, the system overwrites the active customer version with the SAP version.

You can only search for DataSources or other nodes in expanded nodes.

For information about changing the installed DataSources, see Editing DataSources and Application Components.

Maintaining Generic DataSources in BI

2009-02-12T10:39:00.001+05:30

Use

Regardless of the application, you can create and maintain generic DataSources for transaction data, master data attributes or texts from any transparent table, database view or SAP Query InfoSet, or using a function module. This allows you to extract data generically.

Procedure

Creating Generic DataSources

...
1. Select the DataSource type and specify a technical name.

2. Choose Create.

The screen for creating a generic DataSource appears.

3. Choose the application component to which you want to assign the DataSource.

4. Enter the descriptive texts. You can choose any text.

5. Select the datasets from which you want to fill the generic DataSource.

a. Choose Extraction from View if you want to extract data from a transparent table or a database view. Enter the name of the table or the database view.

After you generate the DataSource, you have a DataSource with an extraction structure that corresponds to the database view or transparent table.

For more information about creating and maintaining database views and tables, see the ABAP Dictionary Documentation.

b. Choose Extraction from Query if you want to use a SAP Query InfoSet as the data source. Select the required InfoSet from the InfoSet catalog.

Notes on Extraction Using SAP Query

After you generate the DataSource, you have a DataSource with an extraction structure that corresponds to the InfoSet.

For more information about maintaining the InfoSet, see the System Administration documentation.

c. Choose Extraction Using FM if you want to extract data using a function module. Enter the function module and extraction structure.

The data must be transferred by the function module in an interface table E_T_DATA.

Interface Description and Extraction Process

For information about the function library, see the ABAP Workbench: Tools documentation.

d. With texts you also have the option of extracting from fixed values for domains.

6. Maintain the settings for delta transfer, as required.

7. Choose Save.

When performing extraction, note SAP Query: Assigning to a User Group.

Note when extracting from a transparent table or view:

If the extraction structure contains a key figure field that references a unit of measure or a currency unit field, this unit field has to be included in the same extraction structure as the key figure field.

A screen appears on which you can edit the fields of the extraction structure.

8. Edit the DataSource:

○ Selection

When you schedule a data request in the BI scheduler, you can enter the selection criteria for the data transfer. For example, you can determine that data requests are only to apply to data from the previous month.

If you set the Selection indicator for a field within the extraction structure, the data for this field is transferred in correspondence with the selection criteria in the scheduler.

○ Hide field

You set this indicator to exclude an extraction structure field from the data transfer. The field is no longer available in BI when you set the transfer rules or generate the transfer structure.

○ Inversion

Reverse postings are possible for customer-defined key figures. Therefore inversion is only active for certain transaction data DataSources. These include DataSources that have a field that is marked as an inversion field, for example, the update mode field in DataSource 0FI_AP_3. If this field has a value, the data records are interpreted as reverse records in BI.

If you want to carry out a reverse posting for a customer-defined field (key figure), set the Inversion indicator. The value of the key figure is transferred to BI in inverted form (multiplied by –1).

○ Field only known in exit

You can enhance data by extending the extraction structure for a DataSource by adding fields in append structures.

The Field Only Known in Exit indicator is set for the fields of an append structure; by default these fields are not passed to the extractor from the field list and selection table.

Deselect the Field Only Known in Exit indicator to enable the Service API to pass on the append structure field to the extractor together with the fields of the delivered extract structures in the field list and in the selection table.

9. Choose DataSource ® Generate.

The DataSource is saved in the source system.

Maintaining Generic DataSources

● Change DataSource

To change a generic DataSource, in the initial screen of DataSource maintenance, enter the name of the DataSource and choose Change.

You can change the assignment of a DataSource to an application component or change the texts of a DataSource. Double-click on the name of the table, view, InfoSet or extraction structure to get to the appropriate maintenance screen. Here you make the changes to add new fields. You can also completely swap transparent tables and database views, though this is not possible with InfoSets. Return to DataSource maintenance and choose Create. The screen for editing a DataSource appears. To save the DataSource in the SAP source system, choose DataSource ® Generate.

If you want to test extraction in the source system independently of a BI system, choose DataSource ® Test Extraction.

● Delta DataSource

On the Change Generic DataSource screen, you can delete any DataSources that are no longer relevant. If you are extracting data from an InfoSet, delete the corresponding query. If you want to delete a DataSource, make sure it is not connected to a BI system.

For more information about extraction using SAP Query, see Extraction Using SAP Query.

Delta Transfer to BI in BI

2009-02-12T10:35:00.002+05:30

The following update modes are available in BI:

● Full update

A full update requests all data that meets the selection criteria you set in the scheduler.

● Delta update

A delta update only requests data that has appeared in the source system since the last load.

● Initializing the delta process

You need to initialize a delta process before you can execute it. The initialization selections are copied to load the delta records.

With large volumes of data, you can only ensure a performance-optimized extraction from the source system if you use a delta process.

In the maintenance of the generic DataSource, you can set up a delta for master data attributes and texts. You can also set up a generic delta using a (delta-relevant) field with a monotonically increasing value.

Setting Up an ALE Delta for Master Data Attributes or Texts

Master data attributes or texts for which you want to use a delta transfer have to fulfill two prerequisites:

1. Data must be extracted generically using a transparent table or database view.

2. A change document object must be available that can update the complete key of the table (or view) used for data extraction in combination with one of the tables on which the change document object is based.

The required control entries are delivered for the most important master data attributes and texts. By including a maintenance interface for control entries in the maintenance of generic DataSources or InfoSources, you can use the delta transfer for other master data attributes or texts.

To generate the control entry for master data attributes or texts that is required for BI, proceed as follows:

1. For an attribute or text DataSource, choose DataSource ® ALE Delta.

2. Enter the table and the change document object that you want to use as a basis for the delta transfer.

An input help for the Table Name field searches all possible tables for a suitable key.

3. Confirm your entries.

If you have entered a usable combination of table and change document object, the extraction structure fields are listed in the table below. The status in the first column shows whether changing the master data in this field causes the system to transfer the delta record.

4. Save the settings to generate the required control entry.

Delta transfer is now possible for master data and texts.

After the DataSource has been generated, you can see this on the DataSource: Edit Customer Version screen; the Delta Update field is selected.

You need two separate entries if you want to transfer delta records for texts and master data attributes.

Generic Delta

If a field exists in the extraction structure of a DataSource and the field contains values that increase monotonically over time, you can define delta capability for this DataSource. If a delta-relevant field of this type exists in the extraction structure (a timestamp, for example), the system determines the data volume transferred in the delta mode by comparing the maximum value transferred with the last load with the amount of data that has since entered the system. Only the new data is transferred.

To get the delta, generic delta management translates the update mode into a selection criterion. The selections of the request are enhanced with an interval for the delta-relevant field. The lower limit of the interval is taken from the previous extraction. The upper limit is taken from the current value, for example, the timestamp at the time of extraction. You use security intervals to ensure that all data is taken into account during extraction (see below). After the data request is transferred to the extractor and the data is extracted, the extractor informs generic delta management that the pointer can be set to the upper limit of the previously determined interval.

The delta for generic DataSources cannot be used with a BI system release prior to 3.0. In older SAP BW releases, the system does not replicate DataSources for master data and texts that were delta-enabled using the delta for generic DataSources.

Determining Generic Delta for a DataSource

1. Choose Generic Delta.

2. In the dialog box that appears, specify the delta-determining field and the type of this field.

3. a. Enter a security interval.

The purpose of a security interval is to make the system extract records with the next extraction that appear during the extraction process but which have not yet been extracted (because, for example, they have not been saved).

You can add a security interval to the upper limit or lower limit of the interval.

You should only specify a security interval for the lower limit if the delta process produces a new status for the changed records (when the status is overwritten in BI). In this case, duplicate data records that may arise with a security interval of this type have no affect in BI.

b.Choose the delta type for the data that you want to extract.

You use the delta type to determine how the extracted data is interpreted in BI and the data targets to which it can be updated.

With the Additive Delta delta type, the record to be loaded for cumulative key figures only returns the change to the respective key figure. The extracted data is added into BI. DataSources with this delta type can write data to DataStore objects and InfoCubes.

With the New Status for Changed Records delta type, each record to be loaded returns the new status for all key figures and characteristics. The values in BI are overwritten. DataSources with this delta type can write data to DataStore objects and master data tables.

c. Specify whether the DataSource supports real-time data acquisition.

4. Save your entries.

Delta transfer is now possible for this DataSource.

After the DataSource has been generated, you can see this on the DataSource: Edit Customer Version screen; the Delta Update field is selected.

In systems as of Basis Release 4.0B, you can display the current value of the delta-relevant field in the delta queue.

Example of Determining Selection Intervals with Generic Delta

Security interval upper limit

The delta-relevant field is a timestamp.

The timestamp that was read last is 12:00:00. Delta extraction begins at 12:30:00. The security interval for the upper limit is 120 seconds. The selection interval for the delta request is: 12:00:00 to 12:28:00. When the extraction is finished, the pointer is set to 12:28:00.

Security interval lower limit

The delta-relevant field is a timestamp. After images are transferred. In BI the record is overwritten with the post-change status, for example, for master data. Any duplicate data records do not affect BI.

The last read timestamp is 12:28:00. Delta extraction begins at 13:00. The security interval for the lower limit is 180 seconds. The selection interval for the delta request is: 12:25:00 to 13:00:00. When the extraction is finished, the pointer is set to 13:00:00.

Function Module: Interface Description and Procedure in BI

2009-02-12T10:34:00.001+05:30

A description of the interface for a function module that is used for generic data extraction:

Importing Parameter

I_DSOURCE type SRSC_S_IF_SIMPLE-DSOURCE DataSource

I_INITFLAG type SRSC_S_IF_SIMPLE-INITFLAG Initialization call

I_MAXSIZE type SRSC_S_IF_SIMPLE-MAXSIZE package size

I_REQUNR type SRSC_S_IF_SIMPLE-REQUNR request number

Tables

I_T_SELECT type SRSC_S_IF_SIMPLE-T_SELECT

I_T_FIELDS type SRSC_S_IF_SIMPLE-T_SELECT

E_T_DATA

Exceptions

NO_MORE_DATA

ERROR_PASSED_TO_MESS_HANDLER

Details on Individual Parameters

· I_INITFLAG

This parameter is set to ‘X’ when the function module is called up for the first time, then to ‘ ‘.

· I_MAXSIZE

This parameter contains the number of lines expected within a read call.

Extraction Process

...

The function module is called up again and again during an extraction process:

1. Initialization call:

Only the request parameters are transferred to the module here. The module is as yet unable to transfer data.

2. First read call:

The extractor returns the data typified with the extract structure in an interface table. The number of rows the system expected is determined in the request parameter (I_MAXSIZE).

3. Second read call:

The extractor returns the data enclosed within the first data package in a separate package with I_MAXSIZE rows.

4. The system calls up the function module again and again until the module returns the exception NO_MORE_DATA. Data cannot be transferred in the call in which this exception is called up.

Example

An example of a function module that meets these demands is RSAX_BIW_GET_DATA_SIMPLE. A simple way of creating a syntactically correct module is to copy it into its own function group and then to cope the rows of the top-include of function group RSAX (LRSAXTOP) into the top-include of its own function group. Afterwards, the copied function module must be adjusted to the individual requests.

Testing Extraction in BI

2009-02-12T10:33:00.002+05:30

Use

You can use this function to test extraction from DataSources that were created using the maintenance for the generic DataSource. After the test extraction, you can display the extracted data and the associated logs.

Procedure

...

1. Choose DataSource ® Test Extraction.

A screen appears in which you can set parameters and selections for the test extraction.

2. Enter a request no. for the test extraction via a function module.

3. Enter how many data records are to be read with each extractor call.

4. The extractor is called up by the Service API until no more data is available. In the Display Extr. Calls field, you can specify the maximum number of times the extractor is to be called. This enables you to restrict the no. of data packages when testing the extraction. With a real extraction, the system transfers data packages until is no longer able to find any more data.

5. Depending on the definition of the DataSource, you can test the extraction in various update modes.

For DataSources that support the delta method, you can also test deltas and repeats as well as the full update.

The modes delta and repeat are only available for testing when the extractor supports a mode in which the system reads the data but does not modify the delta management status tables.

· To avoid errors in BW, the timestamp or pointer that was set in delta management must not be changed during testing.

· Before you are able to test the extraction in a delta mode in the source system, you need to have carried out an initialization of the delta method or a simulation of such an initialization for this DataSource.

You can test the transfer of an opening balance for non-cumulative values.

6. Specify selections for the test extraction.

Only those extract structures fields you have selected in DataSource maintenance can be selected.

To enter several selections for a field, insert new rows for this field into the selection table.

7. Choose whether you want to execute the test extraction in debug mode or by tracing an authorization trace.

If you test the extraction in the debug mode, a breakpoint is set just before the extractor initialization call.

For information on the debugger, see ABAP Workbench: Tools.

If you set an authorization trace, you can call it after the test by choosing Display Trace.

8. Start the extraction.

Result

If the extraction was successful, a message appears that specifies the number of extracted records. The buttons Display List, Display Log and Display Trace (optional) appear on the screen. You can use Display List to display the data packages. By double-clicking on the number of records for a data package, you get to a display of the data records. Choose Display Log to display the application log.

Extraction Using SAP Query in BI

2009-02-12T10:33:00.001+05:30

SAP Query is a comprehensive tool for defining reports. It uses many different forms of reporting. It allows users to define and execute their own evaluations of data in the SAP system without requiring ABAP programming know-how.

To define the structure of evaluations, you enter texts in SAP Query and select fields and options. InfoSets and functional groups allow you to easily select the relevant fields.

An InfoSet is a special view of a set of data (logical database, table join, table, sequential file). It serves as the data source for SAP Query. An InfoSet determines which tables or fields of these tables are referenced in an evaluation. InfoSets are usually based on logical databases.

The maintenance of InfoSets is one component of SAP Query. When an InfoSet is created, a data source is selected in an application system. Since a data source can have a large number of fields, fields can be combined into logical units; the functional groups. Functional groups are groups of several fields that form a logical unit within an InfoSet. Any fields that you want to use in an extraction structure have to be assigned to a functional group. In generic data extraction using an InfoSet, all the fields of all functional groups for this InfoSet are available.

The relevance of SAP Query to BI lies in the definition of the extraction structure by selecting fields of a logical database, a table join or other datasets in an InfoSet. This allows you to use generic data extraction for master or transaction data from any InfoSet. A query is generated for an InfoSet. The query gets the data and transfers it to the generic extractor.

InfoSets represent an additional, easily manageable data source for generic data extraction. They allow you to use logical databases from all SAP applications, table joins, and further datasets as data sources for BI. For more information about SAP Query, and InfoSets in particular, see the SAP Query documentation -> System Administration.

In the following section, the terms SAP Query and InfoSet are used independently of the source system release. Depending on the source system release, SAP Query is the same as an ABAP Query or ABAP/4 query. The InfoSet is also called a functional area in some source system releases.

Notes on Extraction Using SAP Query in BI

2009-02-12T10:32:00.000+05:30

Client Dependency

InfoSets are only available if you have created them globally, independent of a client. You set this global area in the initial screen of InfoSet maintenance under Environment ® Work Areas.

Size Limits When Extracting Data Using SAP Query InfoSets

If you are using an InfoSet to extract data, the system first collects all data in the main memory. The data is transferred to the BI system in packages using the Service API interface. The size of the main memory is therefore important with this type of extraction. It is suitable for limited datasets only.

As of SAP Web Application Server 6.10, you can extract mass data using certain InfoSets (tables or table joins).

See also:

Extraction Using SAP Query

Editing DataSources and Application Component Hierarchies in BI

2009-02-12T10:27:00.002+05:30

Use

To adapt existing DataSources to your requirements, you can edit them in this step before transporting them from a test system into a productive system.

In this step you can also postprocess the application component hierarchy.

Procedure

DataSource

Transporting DataSources

Select the DataSources that you want to transport from the test system into the productive system and choose Transport. Specify a development class and a transport request so that the DataSources can be transported.

Maintaining DataSources

To maintain a DataSource, select it and choose Maintain DataSource. The following editing options are available:

● Selection

If you set the Selection indicator for a field within the extraction structure, the data for this field is transferred in correspondence with the selection criteria in the scheduler.

● Hide field

You set this indicator to exclude an extraction structure field from the data transfer. The field is no longer available in BI when you set the transfer rules or generate the transfer structure.

● Inversion

Set the Inversion indicator if you want to carry out a reverse posting for a customer-defined field (key figure). The value of the key figure is transferred to BI in inverted form (multiplied by –1).

● Field only known in exit

You can enhance data by extending the extraction structure for a DataSource by adding fields in append structures.

The Field Only Known in Exit indicator is set for the fields of an append structure; by default these fields are not passed to the extractor from the field list and selection table.

Field Only Known in Exit indicator to enable the BI Service API to pass on the append structure field to the extractor together with the fields of the delivered extract structures in the field list and in the selection table.

Enhancing the extraction structure

If you want to transfer additional information for an existing DataSource from a source system into BI, you first need to enhance the DataSource extraction structure by adding fields. To do this, create an append structure for the extraction structure (see Adding Append Structures)...

1. Choose Enhance Extr. Str., to access field maintenance for the append structure. The name of the append structure is taken from the extraction structure name in the customer namespace.

2. Enter the fields you want to add in the field list, together with their subordinate data elements. You can use all the functions that are available for maintaining fields of tables and structures.

3. Save and activate your append.

4. Go back to the DataSource display and make sure that the Hide Field indicator is not selected for the newly added fields.

Function enhancement

To fill the append structure fields with data, you need to create a customer-specific function module. For information about enhancing the SAP standard with customer-specific function modules, see Enhancing the SAP Standard in SAP Library.

The SAP enhancement RSAP0001 is available for enhancing BI DataSources. This enhancement contains the following enhancement components:

Transaction data	exit_saplrsap_001
Attributes, texts	exit_saplrsap_002
Hierarchies	exit_saplrsap_004

For more information, see Enhancing DataSources.

As of Release 6.0, the Business Add-In (BAdI) RSU5_SAPI_BADI is available. You can display the BAdI documentation in the BAdI definition or BAdI implementation.

Application Component Hierarchy

● To create a same-level or lower-level node for a particular node, place the cursor over this node and choose Object ® Create Node. You can also create lower-level nodes by choosing Object ® Create Children.

● To rename, expand, or compress a node, place your cursor over the node and click on the appropriate button.

● To move a node or subtree, select the node you want to move (by positioning the cursor over it and choosing Select Subtree), position the cursor on the node onto which the selected node is to be positioned. Choose Reassign.

● If you select a node with the cursor and choose Set Segment, this node is displayed with its subnodes. You can go to the higher-level nodes for this subtree using the appropriate links in the row above the subtree.

● If you select a node with the cursor and choose Position, the node is displayed in the first row of the view.

● All DataSources for which a valid (assigned) application component could not be found are placed under the node NODESNOTCONNECTED. The node and its subnodes are only built at transaction runtime and are refreshed when the display is saved.

NODESNOTCONNECTED is not persistently saved to the database and is therefore not transferred in a particular state to other systems when you transport the application component hierarchy.

Note: Hierarchy nodes created under NODESNOTCONNECTED are lost when you save. After you save, the system only displays those nodes under NODESNOTCONNECTED that were moved to this node with DataSources.

A DataSource is positioned under an application component X. You transfer a new application component hierarchy from BI Content that does not contain application component X. In this application component, the DataSource is automatically placed under the node NODESNOTCONNECTED.

Note: Changes to the application component hierarchy only apply until BI Content is installed again.

SAP Query: Assignment to a User Group in BI

2009-02-12T10:26:00.000+05:30

If you want to extract your data from an InfoSet, the InfoSet must be assigned to a user group before the DataSource can be generated. This is necessary as the extraction is processed from an InfoSet using a query that comprises all fields of the InfoSet. In turn, this query can only be generated when the InfoSet is assigned to a user group.

Releases up to 3.1I

In releases up to 3.1I, a screen appears in which you have to specify a user group as well as a query name. The user group must be specified using the value help. In other words, it must already have been created. You can get more information about creating user groups in the SAP Query documentation, in the section System Management ® Functions for Managing User Groups.

A separate query is required for an InfoSet each time it is used in a DataSource. For this reason, enter a query name that was previously not in the system.

The query is generated after you confirm your entries.

Releases from 4.0A

In releases as of 4.0A, the InfoSet for the extract structure of the new DataSource is automatically assigned to the pre-finished system user group. A query is automatically generated by the system.

Free Download Warehouse Management(WM) Tutorial Pdf Books

2009-02-12T10:25:00.000+05:30

Decentralized Warehouse Management (LE-IDW)
SAP Open Information Warehouse
Warehouse Management Guide

Free Download Book Decentralized Warehouse Management LE-IDW

2009-02-12T10:24:00.001+05:30

Decentralized Warehouse Management (LE-IDW)

Free Download Book SAP Open Information Warehouse

2009-02-12T10:23:00.000+05:30

SAP Open Information Warehouse

Free Download Book Warehouse Management Guide

2009-02-12T10:22:00.000+05:30

Warehouse Management Guide

BI DataStore Objects

2009-02-08T12:34:00.001+05:30

Definition

A DataStore object serves as a storage location for consolidated and cleansed transaction data or master data on a document (atomic) level.

This data can be evaluated using a BEx query.

A DataStore object contains key fields (for example, document number/item) and data fields that can also contain character fields (for example, order status, customer) as key figures. The data from a DataStore object can be updated with a delta update into InfoCubes and/or other DataStore objects or master data tables (attributes or texts) in the same system or across different systems.

Unlike multidimensional data storage using InfoCubes, the data in DataStore objects is stored in transparent, flat database tables. The system does not create fact tables or dimension tables.

Use

The cumulative update of key figures is supported for DataStore objects, just as it is with InfoCubes, but with DataStore objects it is also possible to overwrite data fields. This is particularly important with document-related structures. If documents are changed in the source system, these changes include both numeric fields, such as the order quantity, and non-numeric fields, such as the ship-to party, status and delivery date. To reproduce these changes in the DataStore objects in the BI system, you have to overwrite the relevant fields in the DataStore objects and set them to the current value. Furthermore, you can use an overwrite and the existing change log to render a source delta enabled. This means that the delta that is further updated to the InfoCubes, for example, is calculated from two successive after-images.

There are different types of DataStore object:

...

● Standard (see Standard DataStore Objectss)

● For direct update (see DataStore Objects for Direct Updates)

● Write-optimized (see Write-Optimized DataStore Objectss)

Differences between DataStore object types:

Type	Structure	Data Supply	SID Generation	Are BEx Queries Possible?
Standard	Consists of three tables: activation queue, table of active data, change log	From data transfer process	Yes	Yes
For direct update	Consists of the table of active data only	From APIs	No	Yes
Write-optimized	Consists of the table of active data only	From data transfer process	No	Yes

Integration

Integration with the Data Warehousing Workbench - Modeling

Metadata

DataStore objects are fully integrated with BI metadata. They are transported just like InfoCubes and are installed from BI Content (for more information, see Installing Business Content). DataStore objects are grouped with InfoCubes in the InfoProvider view of the Data Warehousing Workbench - Modeling, and are displayed in a tree. They also appear in the data flow display.

Update

Transformation rules define the rules that are used to write data to a DataStore object. They are very similar to the transformation rules for InfoCubes. The main difference is the behavior of data fields in the update. When you update requests into a DataStore object, you have an overwrite option as well as an addition option.

Scheduling and Monitoring

The processes for scheduling the data transfer process for updating data into InfoCubes and DataStore objects are identical.

It is also possible to schedule the activation of DataStore object data and the update from the DataStore object into the related InfoCubes or DataStore objects.

The individual steps, including processing the DataStore object, are logged in the monitor.

There is a separate detailed monitor for executed request operations (such as activation or rollback).

Loadable DataSources

In full-update mode, each transaction data DataSource contained in a DataStore object can be updated. In delta-update mode, only those DataSources that are flagged as delta-enabled DataStores can be updated.

BW Scenario for SAP DataStore Objects

2009-02-08T12:33:00.000+05:30

The diagram below shows how DataStore objects are used in this example of updating order and delivery information, and the status tracking of orders, meaning which orders are open, which are partially-delivered, and so on.

There are three main steps to the entire data process:

...

Loading the data into the BI system and storing it in the PSA

The data requested by the BI system is stored initially in the PSA. A PSA is created for each DataSource and each source system. The PSA is the storage location for incoming data in the BI system. Requested data is saved, unchanged, to the source system.

1. Processing and storing the data in DataSource objects

In the second step, the DataSource objects are used on two different levels.

a. On level one, the data from multiple source systems is stored in DataSource objects. Transformation rules permit you to store the consolidated and cleaned up data in the technical format of the BI system. On level one, the data is stored on the document level (for example, orders and deliveries) and constitutes the consolidated database for further processing in the BI system. Data analysis is therefore not usually performed on the DataSource objects at this level.

b. On level two, transfer rules subsequently combine the data from several DataStore objects into a single DataStore object in accordance with business-related criteria. The data is very detailed, for example, information such as the delivery quantity, the delivery delay in days, and the order status, are calculated and stored per order item. Level 2 is used specifically for operative analysis issues, for example, which orders are still open from the last week. Unlike multidimensional analysis, where very large quantities of data are selected, here data is displayed and analyzed selectively.

2. Storing data in the InfoCube

In the final step, the data is aggregated from the DataStore object on level two into an InfoCube, meaning in this scenario, that the InfoCube does not contain the order number, but saves the data, for example, on the levels of customer, product, and month. Multidimensional analysis is also performed on this data using a BEx query. You can still display the detailed document data from the DataStore object whenever you need to. Use the report/report interface from a BEx query. In this way, you are able to analyze the aggregated data from the InfoCube, and target the specific level of detail you want to access in the data.

SAP Standard BI DataStore Object

2009-02-08T12:32:00.002+05:30

Use

The standard DataStore object is filled with data during the extraction and load process in the BI system.

Structure

A standard DataStore object is represented on the database by three transparent tables:

Activation queue: Serves to save DataStore object data records that are to be updated, but that have not yet been activated. The data is deleted after the records have been activated.

Active data: A table containing the active data (A table).

Change log: Contains the change history for the delta update from the DataStore object into other data targets, such as DataStore objects or InfoCubes.

The tables of active data are built according to the DataStore object definition. This means that key fields and data fields are specified when the DataStore object is defined. The activation queue and the change log are almost identical in structure: the activation queue has an SID as its key, the package ID and the record number; the change log has the request ID as its key, the package ID, and the record number.

This graphic shows how the various tables of the DataStore object work together during the data load.

Data can be loaded performantly from several source systems simultaneously because a queuing mechanism enables a parallel INSERT. The key allows records to be labeled consistently in the activation queue.

The data arrives in the change log from the activation queue and is written to the table for active data upon activation. During activation, the requests are sorted according to their logical keys. This ensures that the data is updated to the table for active data in the correct request sequence.

See also: Example of Activating and Updating Data.

DataStore Objects for Direct Update

2009-02-08T12:32:00.001+05:30

Definition

The DataStore object for direct update differs from the standard DataStore object in terms of how the data is processed. In a standard DataStore object, data is stored in different versions (active, delta, modified), whereas a DataStore object for direct update contains data in a single version. Therefore, data is stored in precisely the same form in which it was written to the DataStore object for direct update by the application. In the BI system, you can use a DataStore object for direct update as a data target for an analysis process. For more information, see Analysis Process Designer.

The DataStore object for direct update is also required by diverse applications, such as SAP Strategic Enterprise Management (SEM) for example, as well as other external applications.

Use

DataStore objects for direct update ensure that the data is available quickly. The data from this kind of DataStore object is accessed transactionally. The data is written to the DataStore object (possibly by several users at the same time) and reread as soon as possible.

It is not a replacement for the standard DataStore object. It is an additional function that can be used in special application contexts.

Structure

The DataStore object for direct update consists of a table for active data only. It retrieves its data from external systems via fill or delete APIs. See DataStore Data and External Applications.

The load process is not supported by the BI system. The advantage to the way it is structured is that it is easy to access data. Data is made available for analysis and reporting immediately after it is loaded.

Creating DataStore Objects for Direct Update

When you create a DataStore object, you can change the DataStore object type under Settings in the context menu. The default setting is Standard. You can only switch between DataStore object types standard and direct update if data does not yet exist in the DataStore object.

Integration

Since you cannot use staging and fill DataStore objects for direct update with BI data (DataSources do not provide the data), DataStore objects are not displayed in the scheduler or in the monitor. However, you can update the data in DataStore objects for direct update to additional InfoProviders.

If you switch a standard DataStore object that already has update rules to direct update, the update rules are set to inactive and can no longer be processed.

Since no change log is generated, you cannot perform a delta update to the InfoProviders at the end of this process.

The DataStore object for direct update is available as an InfoProvider in the BEx Query Designer and can be used for analysis purposes.

SAP Write-Optimized BI DataStore Objects

2009-02-08T12:31:00.000+05:30

Definition

DataStore object that only consists of one table of active data. Data is loaded using the data transfer process.

Use

Data that is loaded into write-optimized DataStore objects is available immediately for further processing.

You use write-optimized DataStore objects in the following scenarios:

● You use a write-optimized DataStore object as a temporary storage area for large sets of data if you are executing complex transformations for this data before it is written to the DataStore object. Subsequently, the data can be updated to further (smaller) InfoProviders. You only have to create the complex transformations once for all data.

● You use write-optimized DataStore objects as the EDW layer for saving data. Business rules are only applied when the data is updated to additional InfoProviders.

The system does not generate SIDs for write-optimized DataStore objects and you do not need to activate them. This means that you can save and further process data quickly. Reporting is possible on the basis of these DataStore objects. However, we recommend that you use them as a consolidation layer, and update the data to additional InfoProviders, standard DataStore objects, or InfoCubes.

Structure

Since the write-optimized DataStore object only consists of the table of active data, you do not have to activate the data, as is necessary with the standard DataStore object. This means that you can process data more quickly.

The loaded data is not aggregated; the history of the data is retained. If two data records with the same logical key are extracted from the source, both records are saved in the DataStore object. The record mode responsible for aggregation remains, however, so that the aggregation of data can take place later in standard DataStore objects.

The system generates a unique technical key for the write-optimized DataStore object. The standard key fields are not necessary with this type of DataStore object. If standard key fields exist anyway, they are called semantic keys so that they can be distinguished from the technical keys. The technical key consists of the Request GUID field (0REQUEST), the Data Package field (0DATAPAKID) and the Data Record Number field (0RECORD). Only new data records are loaded to this key.

You can specify that you do not want to run a check to ensure that the data is unique. If you do not check the uniqueness of the data, the DataStore object table may contain several records with the same key. If you do not set this indicator, and you do check the uniqueness of the data, the system generates a unique index in the semantic key of the InfoObject. This index has the technical name "KEY". Since write-optimized DataStore objects do not have a change log, the system does not create delta (in the sense of a before image and an after image). When you update data into the connected InfoProviders, the system only updates the requests that have not yet been posted.

Use in BEx Queries

For performance reasons, SID values are not created for the characteristics that are loaded. The data is still available for BEx queries. However, in comparison to standard DataStore objects, you can expect slightly worse performance because the SID values have to be created during reporting.

If you want to use write-optimized DataStore objects in BEx queries, we recommend that they have a semantic key and that you run a check to ensure that the data is unique. In this case, the write-optimized DataStore object behaves like a standard DataStore object. If the DataStore object does not have these properties, unexpected results may be produced when the data is aggregated in the query.

SAP Creating BI DataStore Objects

2009-02-08T12:30:00.002+05:30

Procedure

...

1. Select the InfoArea that you want to assign the DataStore object to, or create a new InfoArea. Choose Modeling ® Info Providers ® Create InfoArea.

2. In the context menu of the InfoArea, choose Create DataStore Object.

3. Specify a name and a description for the DataStore object, and choose Create.

If you want to create a copy of an existing DataStore object, specify the DataStore object that you want to use as a template.

You get to the DataStore object maintenance screen.

4. Copying InfoObjects:

On the left side of the screen, there are various templates to choose from. These allow you to get a better overview in relation to a particular task. For performance reasons, the default setting is an empty template. You use the pushbuttons to select different objects as templates.

On the right side of the screen you define the DataStore object. Using the drag and drop function, assign the InfoObjects in the key fields and in the data fields. You can select several InfoObjects at once. The system assigns navigation attributes automatically. These navigation attributes can be switched on to analyze data in BEx.

Or:

You are also able to insert InfoObjects without selecting a template in the left half of the screen. This is useful if you know exactly which InfoObjects you want to include in the DataStore object. To do this, choose Insert InfoObjects in the context menu for the node for key fields or data fields. In the dialog box that appears, you can enter and transfer up to 10 ten InfoObjects directly and or you can select them using input help. You can use drag and drop to reassign them.

There has to be at least one key field and one data field.

Additional restrictions:

- You can create a maximum of 16 key fields (if you have more key fields, you can combine fields using a routine for a key field (concatenate)).

- You can create a maximum of 749 fields

- You can use 1962 bytes (minus 44 bytes for the change log)

- You cannot include key figures as key fields

5. In the context menu of the Data Fields folder you can Insert New Hierarchy Nodes. In this way you can sort the data fields in a hierarchy. You then get a better overview of large quantities of data fields in query definition.

6. Using Settings you can make various settings and define the properties of the DataStore object. See also DataStore Object Settingss.

7. Under Indexes, call the context menu to create secondary indexes. This improves the load and query performance of the DataStore object. Primary indexes are created automatically by the system.

If the values in the index fields uniquely identify each record in the table, select Unique Index from the dialog box. Note that errors can occur during activation if the values are not unique.

The description of the indexes is specified by the system. To create a folder for the indexes, choose Continue from the dialog box. Now you can transfer the required key fields into the index folder using drag and drop.

You can create a maximum of 16 secondary indexes. These are also transported automatically.

For more information see Indexes.

8. Use Check to make sure that the DataStore object is consistent.

9. Save the DataStore object, and activate it. When you activate the DataStore object, the system generates an export DataSource. You use this to update the DataStore object data to further InfoProviders.

DataStore Object Settings

2009-02-08T12:30:00.001+05:30

Use

When creating and changing a DataStore object, you can make the following settings:

DataStore Object Type

Select the DataStore object type. You can choose between standard, direct update and write-optimized, where standard is the default value and direct update is only intended for special cases. You can switch the type as long as there is still no data in the DataStore object.

More information: Standard DataStore Objects, DataStore Objects for Direct Update, and Write-Optimized DataStore Objects

Check Table for InfoObjects

Here, the system displays the name of the InfoObject for which the DataStore object can also be the check table. You can specify this when creating an InfoObject. More information: Tab Page: Master Data/Texts in the InfoObject maintenance

Type-Specific Settings

The following settings are only available for certain DataStore object types:

For Write-Optimized DataStore Objects

Do Not Check Uniqueness of Data

This indicator is only relevant for write-optimized DataStore objects. With these objects, the technical key of the active tables always consists of the fields Request, Data Package, and Data Record. The InfoObjects that appear in the maintenance dialog in the Semantic Key folder form the semantic key of the write-optimized DataStore object.

If you set this indicator, no unique index is generated with the technical name "KEY" for the InfoObjects in the semantic key, and there can be multiple records with the same key in the active table of the DataStore object.

For Standard DataStore Objects:

Generating SID Values

With the Generation of SID Values indicator, you specify whether SIDs are created for the new characteristic values in the DataStore object when the data is activated. If you do not set the indicator, no SIDs are created and activation is completed faster.

Loading Unique Data Records

If you are only loading unique data records (data records with nonrecurring key combinations) into the DataStore object, the loading performance improves if you set the indicator Unique Data Records in the DataStore object maintenance.

The records are then updated more quickly because the system no longer needs to check whether the record already exists. You have to be sure that no duplicate records are loaded because this terminates the process.

If you set this indicator, the system automatically sets the indicator for creating SID values.

This DataStore object property is only supported if SID values are created during activation (see the Creating SID Values indicator). Otherwise, we recommend using a write-optimized DataStore object.

Automatic Further Processing

If you still use a 3.x InfoPackage to load data, you can activate several automatisms to further process the data in the DataStore object. If you use the data transfer process and process chains that SAP recommends you use, you cannot however use these automatisms.

We recommend that you always use process chains.

More information: Including DataStore Objects in Process Chains

Settings for automatic further processing:

● Automatically Setting Quality Status to OK

Using this indicator, you can specify that the system automatically sets the quality status of the data to OK after the data has been loaded into the DataStore object. Activate this function. You should only deselect this indicator if you want to check the data after it has been loaded.

● Activating the DataStore Object Data Automatically

Using this indicator, you can specify that data that has the quality status OK is transferred from the activation queue into the table of active data, and that the change log is updated. Activation is carried out by a new job that is started after data has been loaded into a DataStore object. If the activation process terminates, there can be no automatic update.

● Updating Data from DataStore Objects Automatically

Using this indicator, you can specify that the DataStore object data is automatically updated. Once the data has been activated, it is updated to the connected InfoProviders. The first update is automatically an initial update. If the activation process terminates, there can be no automatic update. The update is carried out by a new job that is started once activation is complete.

Only switch on automatic activation and automatic update if you are sure that these processes do not overlap.

For further settings, see Performance Optimization for DataStore Objects.

SAP BW Multidimensional Clustering Data Store Objects

2009-02-08T12:29:00.002+05:30

Use

Multidimensional clustering (MDC) allows you to save the sorted data records in the active table of a DataStore object. Data records with the same key field values are saved in the same extents (related database storage unit). This prevents data records with the same key values from being spread over a large memory area and thereby reduces the number of extents to be read upon accessing tables. Multidimensional clustering greatly improves active table queries.

Prerequisites

Currently, the function is only supported by the database platform IBM DB2 Universal Database for UNIX and Windows.

Features

Multidimensional clustering organizes the data records of the active table of a DataStore object according to one or more fields of your choice. The selected fields are also indicated as MDC dimensions. Only data records with the same values in the MDC dimensions are saved in an extent. In the context of MDC, an extent is called a block.

The system creates block indexes from within the database for the selected fields. Block indexes link to extents instead of data record numbers and are therefore much smaller than row-based secondary indexes. They save memory space and can be searched through more quickly. This particularly improves performance of table queries that are restricted to these fields.

You can select the key fields of an active table of a DataStore object as an MDC dimension.

Multidimensional clustering was introduced in Release SAP NetWeaver 2004s and can be set up separately for each DataStore object.

For procedures, see Definition of Clustering.

Data Store Objects Definition of Clustering

2009-02-08T12:29:00.001+05:30

Prerequisites

You can only change clustering if the DataStore object does not contain any data. You can change the clustering of DataStore objects that are already filled using the Reclustering function.

For more information, see Reclustering.

Features

In the DataStore maintenance, select Extras ® DB Performance ® Clustering.

You can select MDC dimensions for the DataStore object on the Multidimensional Clustering screen.

Select one or more InfoObjects as MDC dimensions and assign them consecutive sequence numbers, beginning with 1. The sequence number shows whether a field has been selected as an MDC dimension and determines the order of the MDC dimensions in the combined block index.

In addition to block indexes for the different MDC dimensions within the database, the system creates the combined block index. The combined block index contains the fields of all the MDC dimensions. The order of the MDC dimensions can slightly affect the performance of table queries that are restricted to all MDC dimensions and those that are used to access the combined block index.

When selecting, proceed as follows:

· Select InfoObjects that you use to restrict your queries. For example, you can use a time characteristic as an MDC dimension to restrict your queries.

· Select InfoObjects with a low cardinality. For example, the time characteristic 0CALMONTH instead of 0CALDAY.

You cannot select more than three InfoObjects.

· Assign sequence numbers using the following criteria:

¡ Sort the InfoObjects according to how often they occur in queries (assign the lowest sequence number to the InfoObject that occurs most often in queries).

¡ Sort the InfoObjects according to selectivity (assign the lowest sequence number to the InfoObject with the most different data records).

Note: At least one block is created for each value combination in the MDC dimension. This memory area is reserved independently of the number of data records that have the same value combination in the MDC dimension. If there is not a sufficient number of data records with the same value combinations to completely fill a block, the free memory remains unused. This is so that data records with a different value combination in the MDC dimension cannot be written to the block.

If for each combination that exists in the DataStore object, only a few data records exist in the selected MDC dimension, most blocks have unused free memory. This means that the active tables use an unnecessarily large amount of memory space. Performance of table queries also deteriorates, as many pages with not much information must be read.

Example

The size of a block depends on the PAGESIZE and the EXTENTSIZE of the tablespace. The standard PAGESIZE of the DataStore tablespace with the assigned data class DODS is 16K. Up to Release SAP BW 3.5, the default EXTENTSIZE value was 16. As of Release SAP NetWeaver 2004s the new default EXTENTSIZE value is 2.

With an EXTENTSIZE of 2 and a PAGESIZE of 16K the memory area is calculated as 2 x 16K = 32K, this is reserved for each block.

The width of a data record depends on the width and number of key fields and data fields in the DataStore object.

If, for example, a DataStore object has 10 key fields, each with 10 bytes, and 30 data fields with an average of 9 bytes each, a data record needs 10 x 10 bytes + 30 x 9 bytes = 370 bytes. In a 32K block, 32768 bytes/370 bytes could write 88 data records. At least 80 data records should exist for each value combination in the MDC dimensions. This allows optimal use of the memory space in the active table.

DataStore Data and External Applications

2009-02-08T12:28:00.000+05:30

Use

Various functions allow you to read data from DataStore objects from external applications or to fill DataStore objects from external applications.

Features

The BAPI, BAPI_ODSO_READ_DATA_UC, for reading data, enables you to make DataStore data available to external systems. This BAPI can be used for all DataStore object types.

BAPI BAPI_ODSO_READ_DATA was used fort his purpose in the previous release. It is now obsolete.

The following APIs are available for direct update of DataStore objects (see DataStore Object for Direct Update):

RSDRI_ODSO_INSERT: Inserts new data (with keys not yet in the system).

RSDRI_ODSO_INSERT_RFC: see above, can be called up remotely

RSDRI_ODSO_MODIFY: inserts data having new keys; for data with keys already in the system, the data is changed.

RSDRI_ODSO_MODIFY_RFC: see above, can be called up remotely

RSDRI_ODSO_UPDATE: changes data with keys in the system

RSDRI_ODSO_UPDATE_RFC: see above, can be called up remotely

RSDRI_ODSO_DELETE_RFC: deletes data

Also take a look at the extensive documentation for this function module in the BW system.

These APIs allow you to fill DataStore objects with data from external applications, for example, from Web applications.

You can also download from the DataStore object. You can display the DataStore table data from the DataStore object administration, and also download the data using the data browser so that you can use or display it in other applications. For more information see DataStore Object Content.

Data Store Objects Interview Questions and Answers

2009-02-08T12:27:00.002+05:30

What are the benefits of loading requests in parallel?

Several requests can be updated more quickly in the DataStore object.

Can the processes for loading and activating requests be started independently of one another?

Yes. You can create a process chain that starts the activation process once the loading process is complete. More information: Including DataStore Objects in Process Chains

Is there a maximum number of records that can be activated simultaneously?

No.

Can I change the loading method that is used to load the data into the DataStore object from a full update to a delta update?

No. Once a full update has been used to load data into the DataStore object, you are no longer able to change the loading method for this particular combination of DataSource and source system. One exception to this is updating a DataStore object to another (not yet filled) DataStore object if InfoProviders already exist that have been supplied with deltas from the DataStore object. You can run a full upload, which is handled like an initial, into the empty DataStore object and then load deltas on top of that.

Why is it that, after multiple data loads, the change log is larger than the table of active data?

The change log grows in proportion to the table of active data, because before and after-images of each new request are stored there. More information: Example for Activating and Updating Data and the description of the delta process.

Can I delete date from the change log once the data has been activated?

If a delta initialization is available for updates to connected InfoProviders, requests have to be updated before the corresponding data can be deleted from the change log. In the DataStore object administration, you can then call the Delete Change Log Data function. You can schedule this process to run periodically.

However, you cannot immediately delete the data that you just activated, because the most recent deletion selection that you can specify is Older Than 1 Day.

Are locks set when I delete data from the DataStore object to prevent data being written simultaneously?

More information: Functional Constraints of Processes

When is it useful to delete data from the DataStore object?

There are three options available for deleting data from the DataStore object: by request, selectively, and from the change log. To determine the best option, read the detailed description of deleting data from DataStore objects.

When do I use the DataStore object for direct update?

You use this type of DataStore object to load data quickly without using the extraction and load processes in the BI system. More information: DataStore Objects for Direct Update

InfoObjects As InfoProvider SAP BW

2009-02-08T12:27:00.001+05:30

Definition

You can indicate an InfoObject of type characteristic as an InfoProvider if it has attributes and/or texts. The data is then loaded into the master data tables using the transformation rules.

You can only designate a characteristic as an InfoProvider if it contains texts or attributes. It is not possible to use transformation rules to load hierarchies.

Use

You can define transformation rules for the characteristic and use them to load attributes and texts.

You can also define queries for the characteristic (more exactly: for the master data of a characteristic) and then report using the master data.

In InfoObject maintenance, you can also select two-level navigation attributes (the navigation attributes for the navigation attributes of the characteristic) for this characteristic in the Attribute tab page. These are then available like normal characteristics in the query definition.

Integration

If you want to turn a characteristic into an InfoProvider, you have to assign an InfoArea to the characteristic. The characteristic is subsequently displayed in the InfoProvider tree in the Data Warehousing Workbench.

SAP DataSource in the SAP Source System in BW BI

2009-02-05T11:02:00.002+05:30

Definition

Data that logically belongs together is stored in the source system in the form of DataSources.

A DataSource consists of a quantity of fields that are offered for data transfer into BI. The DataSource is technically based on the fields of the extraction structure. By defining a DataSource, these fields can be enhanced as well as hidden (or filtered) for the data transfer.

Additionally, the DataSource describes the properties of the associated extractor with regard to data transfer to BI. Upon replication, the BI-relevant properties of the DataSource are made known in BI.

Integration

DataSources are used for extracting data from an SAP source system and for transferring data into BI. DataSources make the source system data available to BI on request in the form of the (if necessary, filtered and enhanced) extraction structure. In the DataSource maintenance in BI, you determine which fields from the DataSource are actually transferred. Data is transferred in the input layer of BI, the Persistent Staging Area (PSA). In the transformation, you determine what the assignment of fields from the DataSource to InfoObjects from BI should look like. Data transfer processes facilitate the further distribution of the data from the PSA to other targets. The rules that you set in the transformation apply here.

SAP Extraction Structure in BW BI

2009-02-05T11:02:00.001+05:30

Definition

In the extraction structure, data from a DataSource is staged in the source system. It contains the amount of fields that are offered by an extractor in the source system for the data loading process.

You can edit DataSource extraction structures in the source system. In particular, you can determine the DataSource fields in which you hide extraction structure fields from the transfer. This means filtering the extraction structure and/or enhancing the DataSource for fields, meaning completing the extraction structure. In transaction SBIW in the source system, choose Business Information Warehouse ® Subsequent Processing of DataSources.

SAP Installing the Business Content DataSource in the Active Version in BW BI

2009-02-05T11:01:00.000+05:30

Use

The DataSources delivered by SAP with the BI Content and any DataSources delivered by partners or customers in their own namespace are available in the delivery version (D version) in the SAP source system. If you want to transfer data from an SAP source system to a BI system using a DataSource, you must first copy the data from the D version to the active version (A version) and make it known in the BI system.

You have two options:

● You can copy the DataSource in the SAP source system to the active version and then replicate it.

● You can copy the DataSource remotely from within the BI system to the active version. In this case the replication takes place automatically.

Prerequisites

● The remote activation is subject to an authorization check. Authorization object S_RO_BCTRA is checked. System administration must have assigned you the role SAP_RO_BCTRA in order for you to be able to activate the DataSources (more information: Changing Standard Roles). This authorization applies to all the DataSources in a source system.

● For remote activation, the D versions of the DataSources must exist in the BI system. They are replicated when you connect a source system and when you replicate to the BI system for an application component or a source system.

Procedure

In the SAP Source System

...

1. To transfer and activate a DataSource delivered by SAP with Business Content, in transaction SBIW in the source system choose Business Information Warehouse à Business Content DataSources or Activating SAP Business Content àTransfer Business Content DataSources.

The following figure displays the DataSources in an overview according to the application component.

2. Select the nodes in the application component hierarchy for which you want to transfer DataSources into the active version. Do so by positioning the cursor on the node and choosing Highlight Subtree.

The DataSources lying under the subtree and other subtrees are selected.

3. To check for differences between the active and delivery versions of the DataSources, choose Select Delta.

DataSources for which differences were found in the check (for example, due to changes to the extractor) are highlighted in yellow.

4. To analyze the differences between active and delivered versions of a particular DataSource, select the DataSource and choose Version Comparison. The application log contains further information regarding the version comparison.

5. To transfer a DataSource from the delivery version into the active version, select it in the overview tree using the button Highlight Subtree and choose Transfer DataSources.

If an error occurs, the error log appears.

Regardless of whether data has been successfully transferred into the active version, you can call the log by choosing Display Log.

6. To provide the active version of the DataSource in the connected BI systems and to enable data extraction and transfer, replicate the DataSource(s) with a metadata upload to the BI system.

You can then activate the objects for this source system that depend on the source system in the BI system.

When you activate BI Content DataSources, the system overwrites the active customer version with the SAP version.

You can only search for DataSources or other nodes in expanded nodes.

For information about changing the installed DataSources, see Editing DataSources and Application Components.

Remotely From Within the BI System

DataSources are activated remotely under the given circumstances when BI Content is activated. Information about the general procedure for installing content: Installing BI Content.

In BI, the system collects the DataSources for those objects that are one level (at most) before the selected object. This is sufficient to provide transaction and master data.

For example, if this object is an InfoCube, the following DataSources are collected:

■ DataSources from which the corresponding InfoSource supplies transaction data to the InfoCube (see above graphic)

■ DataSources that contain the original master data of the InfoObjects contained in the InfoCube (characteristics of the InfoProvider as well as their display and navigation attributes). No DataSources are collected for the attributes of these InfoObjects.

When the objects are collected, the system checks the authorizations remotely. If you do not have authorization to activate the DataSource, the system produces a warning.

If you install BI Content in the BI system in the active version, the results of the authorization check are taken from the main store.

If you do not have the necessary authorization, the system produces a warning for the DataSource. Errors are shown for the corresponding source-system-dependent objects (transformations, transfer rules, transfer structure, InfoPackage, process chain, process variant). In this case, you have the option of manually installing the required DataSources in the source system from the BI Content (see above), replicating them in the BI system, and then transferring the corresponding source-system-dependent objects from the BI Content.

If you have the required authorization, the active versions of the DataSources are installed in the source system and replicated in the BI system. The source-system-dependent objects are activated in the BI system.

BI Service API with Release SAP NetWeaver 7.0 (Plug-In Basis 2005.1) in the source system and BI are prerequisite to remote activation. If this prerequisite is not fulfilled, you have to activate DataSources in the source system and replicate them in BI afterwards.

SAP Editing the DataSource in the Source System in BW BI

2009-02-05T11:00:00.000+05:30

Use

You can edit DataSources in the source system, using transaction SBIW.

For more information on maintaining DataSources, choose Subsequent Processing of DataSources ® Edit DataSource in transaction SBIW.

SAP Replication of DataSources in BW BI

2009-02-05T10:59:00.000+05:30

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.

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.

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

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

SAP Editing DataSources from SAP Source Systems in BI in BW BI

2009-02-05T10:57:00.001+05:30

Use

A DataSource is defined in the SAP source system along with its properties and field list. In DataSource maintenance in BI, you determine which fields of the DataSource are to be transferred to BI. In addition, you can change the properties for extracting data from the DataSource and properties for the DataSource fields.

Prerequisites

You have replicated the DataSource in BI.

Procedure

You are in an object tree in the Data Warehousing Workbench....

1. Select the required DataSource and choose Change.

2. Go to the General tab page.

Select PSA in the CHAR format if you do not want to generate the PSA for the DataSource in a typed structure but with character-type fields of type CHAR exclusively.

Use this option if conversion during loading causes problems, for example, because there is no appropriate conversion routine, or if the source cannot guarantee that data is loaded with the correct data type.

In this case, after you have activated the DataSource you can load data into the PSA and correct it there.

3. Go to the Extraction tab page.

a. Under Adapter, you determine how the data is to be accessed. The options depend on whether the DataSource supports direct access and real-time data acquisition.

b. If you select Number Format Direct Entry, you can specify the character for the thousand separator and the decimal point character that are to be used for the DataSource fields. If a User Master Record has been specified, the system applies the settings of the user who is used when the conversion exit is executed. This is usually the BI background user (see also: User Management).

4. Go to the Fields tab page.

a. Under Transfer, specify the decision-relevant DataSource fields that you want to be available for extraction and transferred to BI.

b. If required, change the setting for the Format of the field.

c. If you choose an External Format, ensure that the output length of the field (external length) is correct. Change the entries, as required.

d. If required, specify a conversion routine that converts data from an external format into an internal format.

e. Under Currency/Unit, change the entries for the referenced currency and unit fields as required.

5. Check, save and activate your DataSource.

Result

When you activate the DataSource, BI generates a PSA table and a transfer program.

You can now create an InfoPackage. You define the selections for the data request in the InfoPackage. The data can be loaded into the entry layer of the BI system, the PSA. Alternatively, you can access the data directly if the DataSource supports direct access and you have defined a VirtualProvider in the data flow.

SAP Using Emulated 3.x DataSources in BW BI

2009-02-05T10:56:00.000+05:30

Use

You can display an emulated 3.x DataSource in DataSource maintenance in BI. Changes are not possible in this display. In addition, you can use emulation to create the (new) data flow for a 3.x DataSource with transformations, without having to migrate the existing data flow that is based on the 3.x DataSource.

We recommend that you use emulation before migrating the DataSource in order to model and test the functionality of the data flow with transformations, without changing or deleting the objects of the existing data flow. Note that use of the emulated Data Source in a data flow with transformations has an effect on the evaluation of the settings in the InfoPackage. We therefore recommend that you only use the emulation in a development or test system.

Constraints

An emulated 3.x DataSource does not support real-time data acquisition, using the data transfer process to access data directly, or loading data directly (without using the PSA).

Prerequisites

If you want to use transformations in the modeling of the data flow for the 3.x DataSource, the transfer rules and therefore the transfer structure must be activated for the 3.x DataSource. The PSA table to which the data is written is created when the transfer structure is activated.

Procedure

To display the emulated 3.x DataSource in DataSource maintenance, highlight the 3.x DataSource in the DataSource tree and choose Display from the context menu.

To create a data flow using transformations, highlight the 3.x DataSource in the DataSource tree and choose Create Transformation from the context menu. You also use the transformation to set the target of the data transferred from the PSA.

To permit a data transfer to the PSA and further updating of the data from the PSA to the InfoProvider, select the DataSource 3.x in the DataSource tree and choose Create InfoPackage or Create Data Transfer Process in the context menu. We recommend that you use the processes for data transfer to prepare for the migration of a data flow and not in the production system.

Result

If you defined and tested the data flow with transformations using the emulation, you can migrate the DataSource 3.x after a successful test.

SAP Data Reconciliation in BW BI

2009-02-05T10:53:00.003+05:30

Purpose

An important aspect in ensuring the quality of data in BI is the consistency of the data. As a data warehouse, BI integrates and transforms data and stores it so that it is made available for analysis and interpretation. The consistency of the data between the various process steps has to be ensured. Data reconciliation for DataSources allows you to ensure the consistency of data that has been loaded into BI and is available and used productively there. You use the scenarios that are described below to validate the loaded data. Data reconciliation is based on a comparison of the data loaded into BI and the application data in the source system. You can access the data in the source system directly to perform this comparison.

The term productive DataSource is used for DataSources that are used for data transfer in the productive operation of BI. The term data reconciliation DataSource is used for DataSources that are used as a reference for accessing the application data in the source directly and therefore allow you to draw comparisons to the source data.

You can use the process for transaction data. Limitations apply when you use the process for master data because, in this case, you cannot total key figures, for example.

Model

The following figure shows the data model for reconciling application data and loaded data in the data flow with transformation. The data model can also be based on 3.x objects (data flow with transfer rules).

The productive DataSource uses data transfer to deliver the data that is to be validated to BI. The transformation connects the DataSource fields with the InfoObject of a DataStore object that has been created for data reconciliation, by means of a direct assignment. The data reconciliation DataSource allows a VirtualProvider direct access to the application data. In a MultiProvider, the data from the DataStore object is combined with the data that has been read directly. In a query that is defined on the basis of a MultiProvider, the loaded data can be compared with the application data in the source system.

In order to automate data reconciliation, we recommend that you define exceptions in the query that proactively signal that differences exist between the productive data in BI and the reconciliation data in the source. You can use information broadcasting to distribute the results of data reconciliation by e-mail, for example.

Modeling Aspects

Data reconciliation for DataSources allows you to check the integrity of the loaded data by, for example, comparing the totals of a key figure in the DataStore object with the corresponding totals that the VirtualProvider accesses directly in the source system.

In addition, you can use the extractor or extractor error interpretation to identify potential errors in the data processing. This function is available if the data reconciliation DataSource uses a different extraction module to the productive DataSource.

We recommend that you keep the volume of data transferred as small as possible because the data reconciliation DataSource accesses the data in the source system directly. This is best performed using a data reconciliation DataSource delivered by BI Content or a generic DataSource using function modules because this allows you to implement an aggregation logic. For mass data, you generally need to aggregate the data or make appropriate selections during extraction.

The data reconciliation DataSource has to provide selection fields that allow the same set of data to be extracted as the productive DataSource.

Selecting the DataSource for Data Reconciliation

Different DataSources can take on the function of a data reconciliation DataSource. The DataSources that can be used in your data reconciliation scenario are explained below.

BI Content DataSources for Data Reconciliation and Recommendations from BI Content for Data Reconciliation

Use the following process to validate your data:

● If a data reconciliation DataSource is specified for a productive DataSource in the BI Content documentation.

You can see that a DataSource of this type is delivered with BI Content if the documentation in the Technical Data table contains an appropriate entry in row Checkable.

● If the DataSource documentation contains instructions on building a data reconciliation scenario.

Special DataSources for data reconciliation can be delivered in systems that have PI Basis Release 2005.1 or higher or 4.6C source systems PI 2004.1 SP10.

If the BI Content documentation does not include a reference to a delivered data reconciliation scenario, the decision as to which data reconciliation DataSource you use depends on the properties of the data that is to be compared.

Generic DataSource for Database View or InfoSet

Use this process:

● If BI Content does not deliver a data reconciliation DataSource and the documentation for the productive BI Content DataSource does not include instructions on building a data reconciliation scenario.

● If the data that the productive DataSource supplies is made available in a database table or can be extracted using an InfoSet.

● If you can use selections to significantly limit the volume of data that is to be extracted and transferred.

This process is particularly appropriate for calculated key figures.

If you have created a suitable database view or InfoSet, create a corresponding generic DataSource in the source system in transaction SBIW Generic DataSources ® Maintain Generic DataSource.

Generic DataSource for Function Module

Use this process:

● If the data is not available in a database table or cannot be extracted using an InfoSet.

● If you can supply equivalent data for data reconciliation, despite the complex extraction logic of the productive DataSource.

You can reproduce a complex extraction logic using a generic DataSource that extracts data using a customer-defined function module. This allows you to stage data that is equivalent to the productive DataSource, without using the same extraction module as the productive DataSource. In addition, you can use aggregation to reduce the volume of data that is to be transferred.

Note that the extraction logic of the data reconciliation DataSource is prone to errors if the extraction logic of the productive DataSource is complex. Errors in the extraction logic of the data reconciliation DataSource lead to errors in the data reconciliation. We recommend that only experienced developers use this scenario.

Productive DataSource with Direct Access

Use this process:

● If none of the processes described above are possible.

● If the productive DataSource allows direct access.

Since the runtime largely depends on the volume of data that has to be read by the database and transferred, the prerequisite for using this process is that you have set meaningful selections in order to keep the volume of data that is to be transferred small.

During data reconciliation, the data loaded into BI by means of delta transfer is compared with the data in the source system that the extractor accesses directly. Because the same extractor is used for loading and direct access, this process does not allow you to identify potential systematic errors in the logic of the extractor. Errors in processing the delta requests can be identified.

Prerequisites for Performing Data Reconciliation

You have to be able to use suitable selections (time intervals, for example) or pre-aggregation to restrict the scope of the data that you are going to compare so that it can be accessed directly by the VirtualProvider.

In addition, you have to ensure that the selection conditions for the productive DataSource and the data reconciliation DataSource filter the same data range.

Process Flow...

1. Create the object model for data reconciliation according to the requirements of your scenario.

2. Load data from the productive DataSource into the DataStore object using suitable selection conditions.

3. Make sure that there is no unloaded data in the delta queue or in the application for the productive DataSource when the check is performed. The application for validating the data is either stopped or the data that is to be reconciled is limited by means of selections (for example, by creating and using time stamps for the data records).

4. Check the data in the query.

5. If you find inconsistencies, proceed as follows:

6. Check whether all the data was loaded from the source system. Load the data that has not yet been loaded into BI, if applicable, and perform reconciliation again.

If the loaded data is not complete, start a repair request.

If the loaded data is complete but not correct, reinitialize the delta or contact SAP.

Example

Information about application-specific scenarios for performing a data reconciliation is available in the How-To-Guide How to… Reconcile Data Between SAP Source Systems and SAP NetWeaver BI in SDN at http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/7a5ee147-0501-0010-0a9d-f7abcba36b14.

SAP Delta Process in BW BI

2009-02-05T10:52:00.001+05:30

Definition

The delta process is a feature of the extractor and specifies how data is to be transferred. As a DataSource attribute, it specifies how the DataSource data is passed on to the data target. From this you can derive, for example, for which data a DataSource is suited, and how the update and serialization are to be carried out.

Use

The type of delta process affects the update into a data target. When you update data in an ODS object, you need to serialize it so that you can also overwrite it. According to the delta process, the system decides whether it is necessary to serialize by request or by data packet.

Structure

There are various delta processes for SAP source systems:

...

1. Forming deltas with after, before and reverse images that are updated directly in the delta queue; an after image shows the status after the change, a before image the status before the change with a negative sign and the reverse image also shows the negative sign next to the record while indicating it for deletion. This serializes the delta packets. The delta process controls whether adding or overwriting is permitted. In this case, adding and overwriting are permitted. This process supports an update in an ODS object as well as in an InfoCube. (technical name of the delta process in the system): ABR)

2. The extractor delivers additive deltas that are serialized by request. This serialization is necessary since the extractor within a request delivers each key once, and otherwise changes in the non-key fields are not copied over correctly. It only supports the addition of fields. It supports an update in an ODS object as well as in an InfoCube. This delta process is used by LIS DataSources. (technical name of the delta process in the system): ADD)

3. Forming deltas with after image, which are updated directly in the delta queue. This serializes data by packet since the same key can be copied more than once within a request. It does not support the direct update of data in an InfoCube. An ODS object must always be in operation when you update data in an InfoCube. For numeric key figures, for example, this process only supports overwriting and not adding, otherwise incorrect results would come about. It is used in FI-AP/AR for transferring line items, while the variation of the process, where the extractor can also send records with the deletion flag, is used in this capacity in BBP. (technical name of the delta process in the system): AIM/AIMD)

Integration

The field 0RECORDMODE determines whether the records are added to or overwritten. It determines how a record is updated in the delta process: A blank character signifies an after image, ‘X’ a before image, ‘D’ deletes the record and ‘R’ means a reverse image.

When you are loading flat files you have to select a suitable delta process from the transfer structure maintenance, this ensures that you use the correct type of update. You can find additional information under InfoSources with Flexible Updating of Flat Files.

SAP Using a Data Warehouse BI

2009-01-16T11:13:00.001+05:30

The reporting, analysis, and interpretation of business data is of central importance to a company in guaranteeing its competitive edge, optimizing processes, and enabling it to react quickly and in line with the market.

Company data is usually spread across several applications that are used for entering data. Analyzing this data is not only difficult because it is spread across several systems but because the data is saved in a form that is optimized for processing, not analysis. Data analysis represents additional system load which affects operative data processing. Furthermore, the data has come from heterogeneous applications and is therefore only available in heterogeneous formats which must first be standardized. The applications also only save historic data to a limited extent. This historic data can be important in analysis.

Therefore separate systems are required for storing data and supporting data analysis requirements. This type of system is called a data warehouse.

A data warehouse serves to integrate data from heterogeneous sources, transform, consolidate, clean up and store this data, and stage it efficiently for analysis and interpretation purposes.

SAP Architecture of a Data Warehouse BI

2009-01-16T11:12:00.002+05:30

There are many different definitions of a data warehouse. However, they all favor a layer-based architecture.

Data warehousing has developed into an advanced and complex technology. For some time it was assumed that it was sufficient to store data in a star schema optimized for reporting. However this does not adequately meet the needs for consistency and flexibility in the long run. Therefore data warehouses are now structured using a layer architecture. The different layers contain data in differing levels of granularity. We differentiate between the following layers:

● Persistent staging area

● Data warehouse

● Architected data marts

● Operational data store

Persistent Staging Area

After it is extracted from source systems, data is transferred to the entry layer of the data warehouse, the persistent staging area (PSA). In this layer, data is stored in the same form as in the source system. The way in which data is transferred from here to the next layer incorporates quality-assuring measures and the transformations and clean up required for a uniform, integrated view of the data.

Data warehouse

The result of the first transformations and clean up is saved in the next layer, the data warehouse. This data warehouse layer offers integrated, granular, historic, stable data that has not yet been modified for a concrete usage and can therefore be seen as neutral. It acts as the basis for building consistent reporting structures and allows you to react to new requirements with flexibility.

Architected Data Marts

The data warehouse layer provides the most multidimensional analysis structures. These are also called architected data marts. This layer satisfies data analysis requirements. Data marts are not necessarily to be equated with the terms summarized or aggregated; here too you find highly granular structures but they are focused on data analysis requirements alone, unlike the granular data in the data warehouse layer which is application neutral so as to ensure reusability.

The term “architected“ refers to data marts that are not isolated applications but are based on a universally consistent data model. This means that master data can be reused in the form of Shared or Conformed Dimensions.

Operational Data Store

As well as strategic data analysis, a data warehouse also supports operative data analysis by means of the operational data store. Data can be updated to an operational data store on a continual basis or at short intervals and be read for operative analysis. You can also forward the data from the operational data store layer to the data warehouse layer at set times. This means that the data is stored in different levels of granularity: while the operational data store layer contains all the changes to the data, only the days-end status, for example, is stored in the data warehouse layer.

The layer architecture of the data warehouse is largely conceptual. In reality the boundaries between these layers are often fluid; individual data memory can play a role in two different layers. The technical implementation is always specific to the organization.

SAP Enterprise Data Warehouse EDW BI

2009-01-16T11:12:00.001+05:30

The type of information that a data warehouse should deliver is largely determined by individual business needs. In practice this often results in a number of isolated applications which are referred to as

SAP Enterprise Data Warehouse EDW BI

2009-01-16T11:11:00.002+05:30

SAP Building and Running a Data Warehouse BI

2009-01-16T11:11:00.001+05:30

The structure and running of a data warehouse in general, and an enterprise data warehouse in particular, is highly complex and cannot be tackled without the support of adequate tools. Business Intelligence in SAP NetWeaver offers an integrated solution that represents the entire data warehouse process from extraction, to the data warehouse architecture, to analysis and reporting.

Data Warehousing as an Element of Business Intelligence in SAP NetWeaver Provides:

● Data staging:

○ Extraction, transformation, loading (ETL) of data: All data sources can be accessed by means of extraction in the background (via JDBC, file, XMLA, ODBO, ..). Extractors are delivered for SAP applications or can be generated. The standard applications of other providers can be accessed by integrating the ETL tools of non-SAP providers.

○ Real-time data warehousing: Event-near availability of data in the operational data store can be realized using real-time data acquisition technology.

○ Remote data access: Data can be accessed without being saved in the BI system using VirtualProviders (see below).

● Modeling a layer architecture: InfoCubes support the modeling of star schemas (with one large fact table in the center and several surrounding dimension tables) in the architected data mart layer. VirtualProviders allow you to access source data directly. InfoCubes can be combined in virtual star schemas (MultiProvider) using Shared or Conformed Dimensions (master data tables).

The persistent staging area, data warehouse layer and operational data store are built from flat stores, the DataStore objects.

InfoObjects (characteristics and key figures) form the basis of the InfoCube or DataStore object description. You ensure vertical consistency by using the same InfoObjects in the various layers and thus avoid the interface problems that can arise if you use heterogeneous tools to build the layers.

● Transformation: Transformation rules serve to clean up and consolidate data.

● Modeling the data flow: Data transfer processes serve to transfer the data to the different stores. You use process chains to schedule the data processing and observe it using a monitor.

● Staging data for analysis: You can define queries based on any InfoProvider using the Business Explorer. BEx queries form the basis of the applications that are available to users in the portal or based on Microsoft Excel.

SAP Data Warehousing: Step by Step BI

2009-01-16T11:10:00.000+05:30

Purpose

To build a data warehouse, you have to execute certain process steps.

Process Flow

1. Data modeling

○ Creating InfoObjects: Characteristics

○ Creating InfoObjects: Key Figures

○ Creating DataStore objects

○ And/or creating InfoCubes

○ And/or creating InfoSets

○ And/or creating MultiProviders

○ Or creating VirtualProviders

2. Metadata and Document Management

○ Installing BI Content

○ Creating documents

3. Setting up the source system:

○ Creating SAP source systems

○ And/or creating external systems

○ And/or creating file systems

4. Defining extraction:

○ For SAP source systems: Maintaining DataSources

○ Or for a SOAP-based transfer of data: Creating XML DataSources

○ Or for transferring data with UD Connect: Creating a DataSource for UD Connect

○ Or for transferring data with DB Connect: Creating a DataSource for DB Connect

○ Or for files: Creating DataSources for File Source Systems

○ Or for transferring data from non-SAP systems

○ Creating InfoPackages

5. Defining transformations:

○ Creating transformations

6. Defining data distribution:

○ Using the data mart interface

○ Creating open hub destinations

7. Defining the data flow:

○ Creating data transfer processes

○ Creating process chains

8. Scheduling and monitoring:

○ Checking process chain runs

○ Monitor for extraction processes and data transfer processes

SAP Data Warehousing Workbench BI

2009-01-16T11:09:00.002+05:30

Purpose

The Data Warehousing Workbench (DWB) is the central tool for performing tasks in the data warehousing process. It provides data modeling functions as well as functions for controlling, monitoring, and maintaining all the processes in SAP NetWeaver BI that are related to the procurement, retention, and processing of data.

Structure of the Data Warehousing Workbench

The following figure shows the structure of the Data Warehousing Workbench:

Navigation Pane Showing Functional Areas of Data Warehousing Workbench

When you call the Data Warehousing Workbench, a navigation pane appears on the left-hand side of the screen. You open the individual functional areas of the Data Warehousing Workbench by choosing the pushbuttons in the navigation pane. The applications that are available in these areas are displayed in the navigation pane; in the modeling functional area, you see the possible views of the object trees.

Object Trees or Applications in the Individual Functional Areas

If object trees or applications are assigned to a functional area in the navigation pane, you call them by clicking them once in the right-hand side of the screen.

Application Toolbar

In all functional areas, the Data Warehousing Workbench toolbar contains a pushbutton for showing or hiding the navigation pane. It also contains pushbuttons that are relevant in the context of the individual functional areas and applications.

Menu Bar

The functions that you can call from the menu bar of the Data Warehousing Workbench depend on the functional areas.

Status Bar

The system displays information, warnings, and error messages in the status bar.

Features

Functional Areas of the Data Warehousing Workbench

Functional Area	Documentation
Modeling	Modeling
Administration	Administration guide: Enterprise Data Warehousing
Transport Connection	Transporting BI Objects and Copying BI Content
Documents	Documents
BI Content	Transporting BI Objects and Copying BI Content
Translation	Translating Text for BI Objects
BI Metadata Repository	Metadata Repository

SAP Data Warehousing Workbench - Modeling BI

2009-01-16T11:09:00.001+05:30

Purpose

In the Modeling functional area of the Data Warehousing Workbench, you can display BI objects and the corresponding dataflow in a structured way in object trees. You can create new objects, call applications and functions for objects and define the dataflow for the objects.

Structure of Data Warehousing Workbench: Modeling

The following graphic illustrates the structure of the Data Warehousing Workbench: Modeling:

The Modeling functional area consists of various screen areas. As well as the menu, title and status bars, the modeling screen contains the following four screen areas:

· Modeling pushbutton bar

· Navigation pane in the left-hand area of the screen

· View of selected object tree in right-hand area of screen and, with open applications, the middle area of the screen

· Open application in the right-hand area of the screen

Basic Navigation Options

From the navigation pane, you can click on an entry in the object tree list to open the view of this object tree.

In the object tree, you can expand the nodes to navigate in the objects. You can jump to the corresponding application, usually the object maintenance display, by double clicking on the object name in the tree. The application is called in the right-hand area of the screen.

The modeling pushbutton bar contains the following pushbuttons and provides the following navigation options:

· Previous object: Jumps to the application that was called before the present application.

The navigation pane and tree display do not change, since these are displayed independently of the forwards/backwards navigation in the applications.

Similarly, the open application is still displayed if you call another tree.

· Next object: Jumps to the application that was called after the present application.

The navigation pane and tree display do not change, since these are displayed independently of the forwards/backwards navigation in the applications.

Similarly, the open application is still displayed if you call another tree.

· Show/hide navigator: Hides the navigation pane and tree display if both are currently displayed.

Shows the navigation pane if the tree display is shown.

Shows the tree display if the navigation pane is shown.

This function is only possible if an application has been called.

· Tree display full screen/half screen: Hides or shows the tree display.

This is only possible if an application has been called.

You can remove the navigation pane and object tree from the display by choosing (hide navigation pane or hide tree).

You can display information on additional navigation functions in the navigation pane and information on the structure and functions of the object tree in the legends () for the object trees.

SAP Data Flow in the Data Warehouse BI

2009-01-16T11:07:00.000+05:30

The data flow in the Data Warehouse describes which objects are needed at design time and which objects are needed at runtime to transfer data from a source to BI and cleanse, consolidate and integrate the data so that it can be used for analysis, reporting and possibly for planning. The individual requirements of your company processes are supported by numerous ways to design the data flow. You can use any data sources that transfer the data to BI or access the source data directly, apply simple or complex cleansing and consolidating methods, and define data repositories that correspond to the requirements of your layer architecture.

With SAP NetWeaver 7.0, the concepts and technologies for certain elements in the data flow were changed. The most important components of the new data flow are explained below, whereby mention is also made of the changes in comparison to the past data flow. To distinguish them from the new objects, the objects previously used are appended with 3.x.

Data Flow in SAP NetWeaver 7.0

The following graphic shows the data flow in the Data Warehouse:

In BI, the metadata description of the source data is modeled with DataSources. A DataSource is a set of fields that are used to extract data of a business unit from a source system and transfer it to the entry layer of the BI system or provide it for direct access.

There is a new object concept available for DataSources in BI. In BI, the DataSource is edited or created independently of 3.x objects on a unified user interface. When the DataSource is activated, the system creates a PSA table in the Persistent Staging Area (PSA), the entry layer of BI. In this way the DataSource represents a persistent object within the data flow.

Before data can be processed in BI, it has to be loaded into the PSA using an InfoPackage. In the InfoPackage, you specify the selection parameters for transferring data into the PSA. In the new data flow, InfoPackages are only used to load data into the PSA.

Using the transformation, data is copied from a source format to a target format in BI. The transformation process thus allows you to consolidate, cleanse, and integrate data. In the data flow, the transformation replaces the update and transfer rules, including transfer structure maintenance. In the transformation, the fields of a DataSource are also assigned to the InfoObjects of the BI system.

InfoObjects are the smallest units of BI. You map the information in a structured form that is required for constructing InfoProviders.

InfoProviders are persistent data repositories that are used in the layer architecture of the Data Warehouse or in views on data. They can provide the data for analysis, reporting and planning.

Using an InfoSource, which is optional in the new data flow, you can connect multiple sequential transformations. You therefore only require an InfoSource for complex transformations (multistep procedures).

You use the data transfer process (DTP) to transfer the data within BI from one persistent object to another object, in accordance with certain transformations and filters. Possible sources for the data transfer include DataSources and InfoProviders; possible targets include InfoProviders and open hub destinations. To distribute data within BI and in downstream systems, the DTP replaces the InfoPackage, the Data Mart Interface (export DataSources) and the InfoSpoke.

You can also distribute data to other systems using an open hub destination.

In BI, process chains are used to schedule the processes associated with the data flow, including InfoPackages and data transfer processes.

Uses and Advantages of the Data Flow with SAP NetWeaver 7.0

Use of the new DataSource permits real-time data acquisition as well as direct access to source systems of type File and DB Connect.

The data transfer process (DTP) makes the transfer processes in the data warehousing layers more transparent. The performance of the transfer processes increases when you optimize parallelization. With the DTP, delta processes can be separated for different targets and filtering options can be used for the persistent objects on different levels. Error handling can also be defined for DataStore objects with the DTP. The ability to sort out incorrect records in an error stack and to write the data to a buffer after the processing steps of the DTP simplifies error handling. When you use a DTP, you can also directly access each DataSource in the SAP source system that supports the corresponding mode in the metadata (also master data and text DataSources).

The use of transformations simplifies the maintenance of rules for cleansing and consolidating data. Instead of two rules (transfer rules and update rules), as in the past, only the transformation rules are still needed. You edit the transformation rule on an intuitive graphic user interface. InfoSources are no longer mandatory; they are optional and are only required for certain functions. Transformations also provide additional functions such as quantity conversion and the option to create an end routine or expert routine.

Constraints

Hierarchy DataSources, DataSources with the transfer method IDoc as well as DataSources for BAPI source systems cannot be created in the new data flow. They also cannot be migrated. However, DataSources 3.x can be displayed with the interfaces of the new DataSource concept and be used in the new data flow to a limited extent. More information: Using Emulated 3.x DataSources.

Migration

More information about how to migrate an existing data flow with 3.x objects can be found under Migrating Existing Data Flows.

Data load in SAP BW Data Uploading

2009-01-12T11:46:00.001+05:30

What is the strategy to load for example 500,000 entries in BW (material master, transactional data)?

How to separate this entries in small packages and transfer it to BW in automatic?

Is there some strategy for that?

Is there some configuration for that?

See OSS note 411464 (example concerning Info Structures from purchasing documents) to create smaller jobs in order to integrate a large amount of data.

For example, if you wish to split your 500,000 entries in five intervals:

- Create 5 variants in RMCENEAU for each interval
- Create 5 jobs (SM36) that execute RMCENEAU for each variant
- Schedule your jobs
- You can then see the result in RSA3

Loading Data From a Data Target

Can you please guide me for carrying out his activity with some important steps?

I am having few request with the without data mart status. How can I use only them & create a export datasource?

Can you please tell me how my data mechanism will work after the loading?

Follow these steps:

1. Select Source data target( in u r case X) , in the context menu click on Create Export Datasources.
DataSource ( InfoSource) with name 8(name of datatarget) will be generated.

2. In Modelling menu click on Source Systems, Select the logical Source System of your BW server, in the context menu click on Replicate DataSource.

3. In the DataModelling click on Infosources and search for infosource 8(name of datatarget). If not found in the search refresh it. Still not find then from DataModelling click on Infosources, in right side window again select Infosources, in the context menu click on insert Lost Nodes.
Now search you will definately found.

4. No goto Receiving DataTargets ( in your case Y1,Y2,Y3) create update rules.
In the next screen select Infocube radio button and enter name of Source Datatarget (in u r case X). click Next screen Button ( Shift F7), here select Addition radio button, then select Source keyfield radio button and map the keyfields form Source cube to target cube.

5. In the DataModelling click on Infosources select infoSource which u replicated earlier and create infopackage to load data..

Difference in number of data records

2009-01-12T11:45:00.000+05:30

I have uploaded data from R/3 to BW (Controlling Datasources).

The problem is that when i use the extractor checker (rsa3) in R/3 for a
specific datasource (0CO_OM_OPA_1) it shows me that there are 1600 records.

When i load this datasource in BW it shows me that there are 400.000
records. I'm uploading data to "PSA only".

Any ideas why this is happening ?

Thanks

-----Reply Message-----
Subject: RE: Difference in number of data records

Check the 'data recs/call' and 'number of extract calls' parameters in
RSA3. Most likely the actual extract is only making one call with a larger
data rec/call number. The extraction process will collect data records
with the same key so less data has to be transferred to the BW. When you
run RSA3 you are probably getting similar records (that would normally
collect) in different data packets thereby creating more records. Try
running RSA3 with a much higher (2000) recs/call for several calls.

BI Data Transfer Using the Data Mart Interface in BW

2009-01-12T11:29:00.000+05:30

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.

BI Data Extraction from SAP Source Systems in BW

2009-01-12T11:28:00.000+05:30

Purpose

Extractors are part of the data retrieval mechanisms in the SAP source system. An extractor can fill the extraction structure of a DataSource with the data from SAP source system datasets.

Replication makes the DataSource and its relevant properties known in BI.

For the data transfer to the input layer of BI, the Persistent Staging Area (PSA), define the load process with an InfoPackage in the scheduler. The data load process is triggered by a request IDoc to the source system when the InfoPackage is executed. We recommend that you use process chains for execution.

Process Flow

There are application-specific extractors, each of which is hard-coded for the DataSource that was delivered with BI Content, and which fill the extraction structure of this DataSource.

In addition, there are generic extractors with which you can extract more data from the SAP source system and transfer it into BI. Only when you call up the generic extractor by naming the DataSource does it know which data is to be extracted, and from which tables it should read it from and in which structure. This is how it fills different extraction structures and DataSources.

You can run generic data extraction in the SAP source system application areas such as LIS, CO-PA, FI-SL and HR. This is how LIS, for example, uses a generic extractor to read info structures. DataSources are generated on the basis of these (individually) defined info structures. We speak of customer-defined DataSources with generic data extraction from applications.

Regardless of application, you can generically extract master data attributes or texts, or transaction data from all transparent tables, database views or SAP query functional areas or using the function module. You can generate user-specific DataSources here. In this case, we speak of generic DataSources.

The DataSource data for these types are read generically and transferred into BI. This is how generic extractors allow the extraction of data that cannot be made available within the framework of BI Content.

PlugIn for SAP Systems

BI-specific source system functions, extractors and DataSources are delivered for specific SAP systems by plug-ins.

Communication between the SAP source system and BI is only possible if the appropriate plug-in is installed in the source system.

Data Distribution in BW BI

2009-01-09T16:09:00.002+05:30

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

2009-01-09T16:08:00.004+05:30

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

2009-01-09T16:08:00.003+05:30

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

2009-01-09T16:07:00.004+05:30

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

2009-01-09T16:07:00.003+05:30

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

2009-01-09T16:06:00.004+05:30

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

2009-01-09T16:06:00.003+05:30

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

2009-01-09T16:05:00.004+05:30

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

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

2009-01-09T16:05:00.003+05:30

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

2009-01-09T16:04:00.004+05:30

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

2009-01-09T16:04:00.003+05:30

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

2009-01-09T16:03:00.001+05:30

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

2009-01-09T16:02:00.002+05:30

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

2009-01-09T16:01:00.004+05:30

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

2009-01-09T16:01:00.003+05:30

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

2009-01-09T15:59:00.004+05:30

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

2009-01-09T15:59:00.003+05:30

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