Introducing CompositeProviders

Now that all master data and transactional data have been loaded, we want to report on it. Transactional data is stored in a Data Mart DataStore Object (cost center actual postings) and in a Standard DataStore Object (cost center plan line items).

In the report, actual and plan data should be combined. We will define a CompositeProvider to virtually combine the data from the Data Mart DataStore Object and the Standard DataStore Object.

The picture above shows Staging DataStore Objects presenting the Open ODS Layer. Staging DataStore Objects are often based on fields and can serve as Corporate Memory in SAP BW/4HANA.

The EDW (Enterprise Data Warehouse) Layer consists of Standard DataStore Objects and Data Mart DataStore Objects.

A Standard DataStore Object is used to store consolidated and cleansed data (transactional data or master data) on a document level (atomic level). Data Mart DataStore Objects are designed to store summarized and aggregated data for long periods of time. Normally, the Standard DataStore Object should be sufficient and your goal in designing a warehouse is only to use this type of object. If you are dealing with big amounts of data or many complex calculations, and the reporting on a Standard DataStore Object becomes slow, a Data Mart DataStore Object could be used.

In many situations, it is necessary to incorporate additional layers in the staging process. SAP BW/4HANA enables you to integrate one or more DataStore Objects (advanced) into the data flow.

The virtualization layer is positioned on top of layers presenting physical data storage. In a state-of-the-art data warehouse, there is always a virtualization layer as the interface for reporting. In SAP BW/4HANA, the virtualization layer is built from CompositeProviders. Although CompositeProviders might appear to be complex in their design, during Query run-time they are trimmed of all unnecessary elements so reporting performance is maintained.

A CompositeProvider is a type of InfoProvider that combines data from a number of InfoProviders and makes it available for analysis purposes. The CompositeProvider itself does not contain any data. Its data comes entirely from the InfoProviders on which it is based. These InfoProviders are connected to one another by a union and/or join operation.

A CompositeProvider can consist of different combinations of the following InfoProviders:

• InfoObjects

• DataStore Objects (advanced)

• CompositeProviders

• Open ODS Views

CompositeProviders are used for the following reasons:

• As an interface for Queries.

• As a virtual data mart layer. Changes to DataStore Objects (advanced) will not change your reporting if the CompositeProviders remain unchanged.

• Semantic partitioning of data marts can be divided into several smaller units which are integrated by the UNION-capabilities of CompositeProviders. This process brings much more flexibility to your data model and enables parallel processing for loading and reporting processes, resulting in performance gains.

CompositeProviders are optimized for SAP HANA. They run their SQL operations on SAP HANA rather than on the ABAP application side – the SQL union or join operation has been pushed down to SAP HANA.

As an example of a homogeneous CompositeProvider, you have one InfoProvider with the actual data for a logically related business area and one equivalent InfoProvider with the plan data. To compare the actual data with the planned data in one Query, you combine the two InfoProviders into one CompositeProvider.

Homogeneous CompositeProviders consist of InfoProviders that are technically the same. An example of this is an InfoProvider with exactly the same Characteristics and similar Key Figures. In this case, the InfoProvider with the plan data contains Key Figure planned costs and the InfoProvider with the actual data contains Key Figure actual costs.

As an example of a heterogeneous CompositeProvider, you can model a sales scenario that is made up of the sub-processes order, delivery and payment. Each of these sub-processes has its own (private) InfoObjects (delivery location and invoice number, for example) as well as a number of cross-process objects (such as customer or order number). You are advised to model each sub-process in its own InfoProvider and then combine these InfoProviders into a CompositeProvider.

This option usually simplifies the modeling process and can improve system performance when loading and reading data. There is one DataStore Object (advanced) for order, delivery and payment respectively. You can execute individual Queries for the individual InfoProvider, or obtain an overview of the entire process by creating a Query based on the CompositeProvider.

You can configure the assignments for the fields on the right of the screen. On the left, you see the participating InfoProviders. To the right of these, the CompositeProvider's fields are displayed. In the graphical display, you can add the fields to the CompositeProvider. This is achieved by either using drag and drop, or by choosing Create Assignments in the Context menu and creating the assignments. If you add an InfoProvider by dragging and dropping it, the fields and dimensions (groups) of the InfoProvider are applied and any required dimensions that do not already exist are created.

In a CompositeProvider, JOIN operation can also be used.

Besides combining SAP BW/4HANA InfoProviders in a CompositeProvider, it's also possible to set up mixed modeling scenarios by integrating SAP HANA Calculation Views.