Download my Performance Tuning Checklist for VirtualProviders
Published on 15.10.2015
In this post, I show you the different types of VirtualProviders, but implementing them in a right way can be tricky. I have collected a checklist that I use when I have to implement a VirtualProvider. The checklist contains my most important settings and proposals to consider when creating and modeling a VirtualProvider, I use them during my projects. I can share this checklist with you for FREE, just click on the button below.
Overview
In this blog post I will describe the different VirtualProviders that SAP BW offers as well as their specifics and implementation considerations. I will also introduce the features of HybridProviders, which are clearly one of the exciting new features of BW 7.3.
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.
- 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.
- 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.
- 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.
HybridProvider, complex model in a simple object
With BW 7.3 SAP introduced a new InfoProvider called HybridProvider. It is somehow similar to a MultiProvider, because it does not store the data itself, but combines the data from underlying InfoProviders. The HybridProvider is designed to suit two modeling cases and therefore could be one of the following combinations:
- Standard DSO with RDA and a standard InfoCube
- Virtual InfoCube and a standard InfoCube.
HybridProviders are very useful for business scenarios where you need real-time or near real-time fast access to information. I have to say that the modeling principle behind HybridProviders has been used in previous versions of BW as well. However, with BW 7.3 instead of doing the whole model by hand the system creates part of the necessary objects automatically. For example, in the case of HybridProvider based on a standard DSO with RDA SAP BW automatically generates the standard infocube, the transformation and the DTP between the DSO and the Infocube. The system also automatically creates a process chain for the generated DTP. Moreover, it takes away part of the administration work as it ensures consistency between the DSO and the standard Infocube.
Particularly interesting in the context of our blog topic is the scenario, when a HybridProvider is based on a VirtualProvider. In that case the virtual Infocube and the standard InfoCube are assigned to a DataSource that supports direct access. When a user runs a query on top of the HybridProvider, BW will try to get the data from the standard InfoCube. However, if the data does not exist in the standard InfoCube, the system will try to extract the data through the virtual provider.
Summary
So, as you have seen, VirtualProviders could be very useful and can cover complex scenarios. The two things that you have to always care about are - to model your dataflow wisely and to ensure top performance of your VirtualProvider by proper data selections. BW will take care of the rest.