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 Datasource
allows 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.