Composite Providers With BW on HANA for Efficient Data Modelling

8/11/2019 Composite Providers With BW on HANA for Efficient Data Modelling

1/5

Composite Providers with BW on HANA for Efficient data modelling

By this time most of you would have come across the term composite providers w.r.to BW systems

on HANA. This paper takes a deeper look at this new type of Info provider and also looks at how

modelling scenarios that previously were time consuming could be made easily, in lesser time and

also make use of the Calculation engine of HANA to its best. This paper does not focus on the steps

to be followed for creating a composite provider.

Composite Provider:

A Composite Provider is an Info Provider, which combines data from several analytic indexes or from

other Info Providers (by Join or Union), and makes this data available for reporting and analysis.

UNION and JOIN operations are executed in HANA and not the application server. BEx Queries can be

created on Composite Providers as on any other BW Info Provider. This is done in transaction

RSLIMOBW.

The main advantage of Composite providers is that: BW Info Providers can be combined using theJOIN operation allowing us to create new scenarios not possible or very expensive with standard

techniques (Multiprovider, InfoSet).

When we hear the word Union, what strikes our mind immediately is a Multi provider. SAP Still

suggests the usage of Multiprovider in case your requirement is just to use Unions. This is because

the OLAP engine is well suited for this operation.

Composite providers however can be used on top of Multiproviders to execute Join operations with

Multiprovider as one of the data providers. This gives us additional flexibility and even one additional

level of modelling thus allowing us to create new scenarios that were not possible before.

For information on how to create Composite providers using RSLIMOBW refer tohelp.sap.com.

Having seen the definition and some of the benefits of Composite providers its time that we jump

into some real modelling scenario to see its real benefit.

Modeling Scenario:

Most or almost all of us would have come across this typical scenario of building cubes in our

projects. A cube is created as a final destination for source data. This cube is loaded from several

DSOs containing transaction data and during the loading there are several lookups written inorder to

fetch master data attributes from other DSOs and load them in the cube.

Regular Modeling Scenario - An example :

Let us take an example of a simple cube. Let us assume that the cube is used for tracking sales

information based on customer data and also based on the product sold. So for the report to have

slice and dice capabilities we would need to have all the attributes of Customer as well as Product to

be a part of the cube. This is not required in case the attributes are not required historically. Where

we can use them as Navigational attributes. For example, to track sales of a city (an attribute of

customer) for a month, and to see its trend in the past, it would make sense to have city as a part of

the cube and lookup and populate city every month from customer master, when data is loaded tothe cube. This prevents a customer from being left out if his City was changed historically.
http://help.sap.com/http://help.sap.com/http://help.sap.com/http://help.sap.com/


2/5

Similarly, we also have product attributes like Product Category, Product Group etc.

A typical data model for the scenario described above would look like the following:

This scenario depicted above is just an example considering one source DSO, In real-time, the

number of DSOs loading to a cube is usually more than one and also the number of lookups

performed can be more than what is depicted here.

In this typical way, we not only store the same information of the DSOs in an aggregated

form in the cube, but also add additional attributes added to the transaction data and stored

again in the cubes.

An addition of new characteristic to the cube which requires lookup from one of these DSOs

would be a herculean task, as the new characteristic has to be added to the cube and all the

impacted transformations, DTPs would have to be transported again with precision. The

characteristic would then have to be added to the Multiprovider to be made available in the

reports. And on top of this a reload of history is required in case an attribute is required

historically.

Sales Transaction Information

Product Master DSO

Key: Product number, Calmonth

Customer Master DSO

Key: Customer number, Calmonth

Lookup on master data DSOLookup on master data DSO


3/5

Although SAP has provided a new rule type in the transformation called the Read DSO data

in the transformation, this would only help us in avoiding the ABAP part of the lookup but

not in reducing the effort taken for changes and the expense.

Modeling Scenario using Composite Provider:

With the new Composite provider it is possible to realize the dream of storing the same data

only once at least for this scenario. The following case shows how we can model the same

scenario using a composite provider and thus make use of the calculation capabilities of

HANA DB.

In transaction RSLIMOBW, we create a Composite provider that uses the 3 Data store

objects, Sales Transaction, Customer Master and Product Master as shown below.

How this works:

The Sales transaction DSO is taken in the Composite Provider with Binding Type

Union. By default there should be at least one Info provider of type Union in the

Composite provider.

The fields of Sales Transaction DSO are dragged into the Central Composite Provider.

The Customer Master and the Product Master DSO are added to the Composite

provider with the binding type Join.

Master data fields required in the composite provider are dragged and dropped into

the composite provider. (These are the fields for which lookups were written in the

original scenario).

The fields Customer number and Calmonth are used as Join fields and a join

condition is drawn between the Sales DSO and the Customer Master.

Similarly Product number and Calmonth are joined from the Product DSO with the

composite provider.


4/5

In this way, the composite provider will contain all the records present in the Sales

transaction DSO with the corresponding attributes filled based on the Calendar

Month.

The Joins and Unions are executed at the query execution time. UNION and JOIN

operations are executed in HANA DB.

Note that SID generation option should be checked in the DSO for it to be available

as a data provider for Composite provider.

Advantages:

Development time & Cost:

Using this approach, a lot of time taken to developlookups and maintain complex data

models is saved.

Addition of a new attribute (changes) to cubes, which required changing a lot of objects

in the earlier scenario is very simple now. The only place where the attribute need to beadded is in the source DSO (Master DSO) and in the composite provider Maintenance).

Loading time:

The time taken for loading huge amounts of data through several layers (staging and

further) in BW is reduced as the Composite providers can be modelled using the DSOs in

the EDW layer itself.

The time taken for performing lookups to derive attributes is also saved during loading.

DB Size:

A lot of DB -spaceis saved since we only store information once and use it at different

places instead of executing a lookup and storing them every time in the cube.

Flexibility:

Further to what is shown above and as in the case with most of the real time systems,

not just one DSO loads to a cube. In that case, a Multiprovider is created on top of these

DSOs can also be used in the Composite provider to deliver the desired results.

Conclusion: With the new Composite provider with SAP BW on HANA there are numerous

capabilities that can be explored to save time and cost for your company. In each case it is good to

evaluate these possibilities and make a wise decision.


5/5

Composite Providers With BW on HANA for Efficient Data Modelling

Documents

Transcript of Composite Providers With BW on HANA for Efficient Data Modelling