Highlighted
Absent Member.
Absent Member.
3414 views

Implementing Virtual Infocube Based on Direct Access in SAP BI 7.0

SAP Business Warehouse (abridge SAP BW) is SAP's Enterprise DataWarehouse product. It can transform and consolidate business information from virtually any source system.

Why SAP Business Warehouse?

Because SAP Business Warehouse is unlike any other data warehousing application on the market. SAP BW runs on traditional RDBMS databases – or on the SAP HANA in-memory database for lightning-fast performance. Consume and integrate SAP and non-SAP data, and access thousands of prebuilt data models to reduce development time.

  • Simplify your data warehouse architecture and free up more time for line-of-business requirements
  • Integrate SAP and non-SAP applications into one environment – for a single version of the truth
  • Confidently scale your enterprise data warehouse from gigabytes to petabytes
  • Deploy SAP BW on-premise, in the cloud, or in a hybrid environment

The data in SAP BW is managed with the help of a centralized tool known as SAP BI Administration Workbench. The BI platform provides infrastructure and functions which include −

  • OLAP Processor
  • Metadata Repository,
  • Process designer and other functions.

The Business Explorer (BEx) is a reporting and analysis tool that supports query, analysis and reporting functions in BI. Using BEx, you can analyze historical and current data to different degree of analysis.

SAP BW is known as an open, standard tool which allows you to extract the data from different systems and then send it to the BI system. It also evaluates the data with different reporting tools and you can distribute this to other systems.

BENEFITS

VirtualProviders are exciting, because they usually come up on the modeling board as part of complex business reporting scenarios. The main role of such an InfoProvider is to give the needed information without any time lag and without storing the data physically on the BW server. So, VirtualProviders are just like structures with no persistent storage, which can answer certain reporting questions on demand. Besides that, virtual providers are often used for reconciliation purposes of the data loaded in SAP BW with a normal staging data flow and the source system.

MODELING CONSIDERATIONS

All these features sound really nice, but there are a couple of important factors to be considered before jumping in the implementation. VirtualProviders are only suitable for cases when:

  • The need of precisely up-to-date information is very strong
  • A small amount of data is accessed from the source
  • The information will be requested only by a few users simultaneously

If any of these three rules is broken, then you should consider implementing your solution in another way. For example, a traditional data flow model with more frequent loading times or a more advanced model relying on real-time data acquisition (RDA).

TYPES OF VIRTUALPROVIDERS

After performing the very initial analysis whether a virtual provider is the right choice for the model, you have to choose the type of the VirtualProvider. In SAP BW you have the following choices.

  1. VirtualProvider based on Data Transfer Process (DTP)

    This is certainly the easiest and the most transparent way to build this type of InfoProvider. It could be based on a DataSource for direct access or on another InfoProvider in BW. Technically, when a user executes a query or navigates inside the query, a request is sent through the virtual provider to its source and the needed data is returned back. To have that model perform well the most important part is to be able to restrict the data, so that you do not request unnecessary data from the source system. For the more complex cases this selection is done with the help of the inverse routine in the transformation.

  2. VirtualProvider based on BAPIs

    This type is used for cases, when you need to report on information coming from a Non-SAP system and the information is stored not in a relational, but in a hierarchical database. A typical example would be an external system for market data. When the VirtualProvider is used in reporting, the BAPI is called to collect the data and after that pass it to the BW OLAP engine.

  3. VirtualProvider based on function module

    This is the most complex, but also the most flexible approach for building a VirtualProvider. It allows you not only to select the needed data from the source, but freely make complex data calculations or changes before pushing it to the OLAP engine. The effort to implement a VirtualProvider based on a function module is bigger than the one with the other two types, but the options that the developer is allowed to use are limited only by the ABAP knowledge and confidence that he/she has.

Here is the www.scribd.com/document/118135536/How-to-Implement-a-VirtualProvider-with-Function-Module

5 Steps to Real-Time Data Analysis with Virtual InfoProviders

As transactional data comes into an SAP system, you typically need to stage it via extraction, transformation, and loading (ETL) into SAP NetWeaver BW for reporting purposes. When the transactional data is created in the transparent tables, SAP NetWeaver BW extracts analytics data for management and operational reporting. A time lag exists between the time data is posted to SAP ERP tables and when the data is available in SAP NetWeaver BW for reporting and analysis.

We show you how to use a virtual InfoProvider to read the data in real time from underlying SAP ERP tables and present the data in Xcelsius for reporting. The time lag is significantly reduced because data loading is completely eliminated, thereby making the posted data instantaneously available for reporting.

The advantages of using this approach are:

  • No need to run lengthy data extraction programs or complex ETL processes
  • Data is available for analysis immediately as it is entered into the system
  • Ability to make real-time decisions based on critical business data

However, note that Xcelsius can only handle about 500 rows of data and still maintain responsive performance (1,000 rows max). For some scenarios this may be a critical limitation. In this situation, many reports require large data sets to be pre-aggregated.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.