Modeling Without Persistent Data Storage
In this model, data is not stored persistently in the BW system but is read directly for reporting and analysis purposes.
Process
Simple Model with VirtualProvider
The data is read straight from the source system using a VirtualProvider.
Analysis and reporting using a VirtualProvider is a suitable alternative if:
you need up-to-date availability of data from the source system
you only want to access small data sets sporadically, and replicating the data into BW would be too time-consuming in comparison
only a few users execute queries simultaneously in the requested dataset.
As long as a suitable extractor is available, a query based on a VirtualProvider can replace drill through to an SAP source system using the report-report interface. In both cases, you obtain real-time data. However, a drill through uses an SAP query to present the data, whereas a VirtualProvider uses a BEx query.
Restrictions:
The source system must always be available.
Data analysis based on VirtualProviders represents additional system load on the source system. Performance is reduced further the more users are working with BEx queries based on VirtualProviders and the higher the level of aggregation for the queries.
VirtualProviders do not support navigation attributes.
You can also use VirtualProviders with a prototyping process with the generic extractor. You can also access non-SAP systems quickly and easily using DB Connect.
Since VirtualProviders do not require persistent data storage in the BW system, changes to the structures (extract structure, transfer structure, transfer rules) in the whole staging process of the prototype phase can be performed quickly.
Data Mart Scenario with VirtualProviders
First, data is stored in a BW system (BW 1) in DataStore objects or InfoCubes. The data is read for analysis purposes from an additional BW system (BW 2) using a VirtualProvider.
When you create a system landscape with several BW Systems, you have two alternatives for distributing the transaction data: You can replicate the data beforehand, or only read it once it is requested from the source system. With the second option, you use VirtualProviders. The restrictions that apply when you use VirtualProviders with an SAP system do not have the same significance when you join two BI systems. You can significantly reduce the performance load on the source system (BW 1) when using InfoCubes by implementing suitable aggregates or BW accelerator indexes. Limitations regarding system availability and navigation attributes still apply.
When you use a data mart scenario, it is not usually useful to replicate data at document level in all the connected BW systems. Since users only sporadically access the data in the connected BW systems in detail, this is a case that is well suited to the use of VirtualProviders.