Infoproviders (Physical and Virtual)

Data Store Objects

A Data Store object is used to store consolidated and cleansed data

(transaction data or master data) on a document level(atomic level).

Although Datastore Objects can store master data, and and there are

valid reasons for this, they primarily store detailed transaction data.

They can be used to support detailed operational reporting, or can

be part of the warehouse, where they canbe used to hold years of

"potentially needed" data.

One major difference between Datastore Objects and Infocubes is that

DataStore Objects have the option to overwrite records, where infocubes

do not. This is a huge difference.

In contrast to multidimensional Datastores for Infocubes, data in Data

Store objects is stored in flat, transparent database tables. Fact and

dimension tables are not created.

With Datastore objects, we cannot only update keyfigures cumulatively,

as with Infocubes, but also overwrite data fields. This is especially

important for transaction-level documents that change in the source

sytem. Here, document changes not only involve numerical fields, such

as order quantities, but also non-numerical ones such as ship-to parties,

delivery date, and status. Since the OLTP system overwrites these 

records when changes occur, Datastore objects must often be moceled

to overwrite the corresponding fields and update to the current value

in BI.

The Standard Datastore Object consists of thre tables(activation queue,

active data table, and change log). It is completely integrated in the

staging process. In other words, data can be loaded into and out of the

Datastore Objects during the staging process. Using a change log means

that all changes are also written and are available as delta uploads

for connected data targets.

Write Optimized is a new kind of Datastore Object. It is targeted for

the warehouse level of the architectur, and has the advantage of 

quicker loads.

A direct update Datastore object has only the table with active data.

This means it is not as easily integrated in the staging process.

Instead, this Datastore object type is filled using APIs and can be

read via a BAPI.

The following code is delivered for this purpose.

BAPI BAPI_ODSO_READ_DATA_UC

RSDRI_ODSO_INSERT

RSDRI_ODSO_INSERT_RFC

RSDRI_ODSO_MODIFY

RSDRI_ODSO_MODIFY_RFC

RSDRI_ODSO_UPDATE

RSDRI_ODSO_UPDATE_RFC

RSDRI_ODSO_DELETE_RFC

Direct Update DS Object usage in APD:

The APD is a robust tool set for use by the best analysis. It allows

analysts to manipulate and mine data for specific analysis goals.

Direct Update DS Object usage in SEM Business Consolidation(BCS):

During consolidation of two legal entities, accounting entities are 

made to direct update DS Objects to reflect the elimination of

internal transactions.

The number of Datastore Objects that must be implemented depends

on the complexity of the scenario that is to be implemented. Furthermore,

a Datastore object can also form the end of a staging process. In otherwords,

an Infocube does not necessarily have to be updated from the Datastore

object.

Integrating a New Infocube Into an Existing Into an Existing Data Flow:

1. Create a transformation between the original source and the new

    target objects.

2. Create both a full and delta DTP.

3. Manually execute the full DTP.

4. Create a new process chain to execute the delta DTP.

5. Integrate the new chain into your existing nightly process chains.

Infoproviders are all objects that provide information to queries.

Infoproviders are broken down into two grouping. Infoproviders that

store the data persistently(in database tables) and those that do not

store the data in BI, but rather collect the data when the query is

executed. The former grouping of infoproviders are sometimes called

data targets. The ones that do not store data persistently in BI include

Infosets, Virtual Providers, and multiproviders.

Virtual providers are very special. Like all providers, they feed 

information to queries. However, a virtual provider represents a logical

view. Unlike Infocubes, no data is physically stored in BI. The data is

taken from the source systems only after a query has been executed.

There are three types of Virtual Providers, and each type can be 

distinguished by the way in which it retrives data.

Based on DTP For direct access

Based on a BAPI

Based on a function module.

Direct Access, a Definition:

A BI tool set that allows queries to be executed on temporary Virtual

Providers that are tied directly to the source system.

We require up-to-date data from a SAP source system

Only a small quantity of data is transferred(good query design)

Only a small number of users work with queries in the data 

set at any one time.

There are differences between analysis reporting and operational reporting.

For example, a analysis of why accounts receivable is growing 5% a

year would be a BI Report. On the other hand, a list of unpaid invoices

to support dunning the customer for what they owe would be an

OLTP-based report.

This theory of separtation of duties was completely valid when BI Systems

were first developed, but now the line is blurred. It becomes even more

so with the introduction of Real-Time Data Acquisition(RDA). RDA is a new

SAP Netweaver 2004s tool set to support some limited operational

reporting needs inside BI.

With RDA, data is transferred into BI at regular intervals during the

day and is then updated in the Datastore objects, which are directly

available for reporting Background processes(daemons) in the BI System

initiate the Infopackages and data transfer processes assigned to them

(to update the PSA data in Datastore objects).

Real-Time Data Warehousing(RDA)

RDA is a framework for analyzing information from various sources in

real time as soon as the data becomes available in the source system.

Lower time scale than for schedeuled/batch data acquisition

Stream oriented

Almost immediate availability for reporting(less than 1 minute)

RDA is used in tactical decision making.

Using a Webservice Push:

A web service push can write the data directly from the source to the

PSA. The data transfer is not controlled by BI. An infopackage(for full

upload) is required only to specify request-related settings for RDA;it

is never executed, as the data is pushesd into the BI PSA by a web service.

Using the BI Service API: If the source data is based on a source in an

SAP Source system, the BI Service API is used. Many of the steps are

the same as with normal delta extractions, such as the requirement for

an infopackage to initialize delta. 

With RDA, it is these delta loads that are special. If the Datasourceallows for RDA ( a checkbox on RSA2), we can choose to utilize it in 

this way. This involves the creation of a specific RDA Data Transfer Process.

The RDA processes focuses on obtaining data very frequently from your

source system. Due to the limitations discussed above, many times you

only get to decide if the feed to your targets will be normal, periodically

schedulled infopackage, or if it be RDA. 

Infoproviders exist for Plan and Actual data of cost center transaction.

This separate plan vs actual design suports BI Integrated Planning with

one dedicated cube, and to support the loading of actual data from

SAP Source system. Your users now have requirements for plan add actual

comparision reports. We want to investigate a Multiprovider to solve

this need