semantic

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com

2011 SAP AG 1

All you need to Know about

Semantically Partitioned Object in

BW 7.30

Applies to:

BW 7.30. For more information, please visit the EDW homepage.

Summary

This paper provides a detailed description of the Semantically Partitioned Object (SPO), released as part of BW 7.30.

Author: Rakesh Dilip Kalyankar

Company: SAP Global Delivery

Created on: 14 November 2011

Author Bio

Rakesh is a BW/HANA consultant working with SAP Global Delivery and has extensive BW implementation experience. Prior to SAP Global Delivery, Rakesh was part of the BW R&D team in SAP Labs since 2006; he has worked on the SDLC of latest BW releases like BW 7.30, 7.31 and was responsible for quality of many components of the the EDW.
https://www.sdn.sap.com/irj/sdn/businessone

All you need to Know about Semantically Partitioned Object in BW 7.30


2011 SAP AG 2

Table of Contents

Background and Introduction .............................................................................................................................. 3

Metadata Model .................................................................................................................................................. 3

Components of an SPO .................................................................................................................................. 3

Details ............................................................................................................................................................. 4

Naming Conventions ....................................................................................................................................... 4

Modeling ............................................................................................................................................................. 5

Including SPO in Data Flow .......................................................................................................................... 11

Tables . ....................................................................................................................................................... 15

Important tables ............................................................................................................................................ 15

List of all relevant tables................................................................................................................................ 15

Enhanced Modeling .......................................................................................................................................... 16

Model partitions via BAdi............................................................................................................................... 16 How it works ............................................................................................................................................................... 16

BAdi Implementation .................................................................................................................................................. 17

................................................................................................................................................ 19

Additional options ............................................................................................................................................. 20

.................................................................................................. 20

Archiving ....................................................................................................................................................... 20

SPO Mass Activation .................................................................................................................................... 21

Related Content ................................................................................................................................................ 22

Copyright........................................................................................................................................................... 23



2011 SAP AG 3

Background and Introduction

Enterprise wide data warehouses are increasingly used as the underlying infrastructure for business intelligence (BI) solutions. As a result, data warehouse frameworks being utilized must be configured to handle high data throughput. With conventional data warehousing scenarios, well defined time windows are used to extract data from source systems and to store it in flat tables (e.g. DataStore objects, etc.) or in multi-dimensional data targets (e.g., InfoCubes, etc.). The following factors can influence the amount of time required to make data available for reporting:

(i) time for propagating data to data targets (data loading time); and

(ii) Time needed for administrative tasks (e.g. dropping and re-creating indexes, activation of data in DataStore objects, rebuilding of aggregate data, etc.). The challenge, in particular for mass data, is to complete the steps within the defined time window.

(iii) Another aspect that can affect data availability is the degree of data coupling. In some implementations, data generated by differing source systems must be processed in a sequential manner (as opposed to parallel processing)

To counter these and other issues with the current architecture, SAP has implemented the concept of a semantically partitioned Object with the BW 7.30 version. The Semantically partitioning object enables an (enterprise) data warehouse to handle mass data. Semantical partitioning improves the performance for the staging processes and reduces the time needed to make data available for reporting. Instead of using one data target that stores a huge amount of data semantical partitioning involves the creation of multiple structurally identical data targets (metadata objects).

Metadata Model

Components of an SPO

1. Master Provider

2. Part Providers

3. Inbound Infosources

4. Outbound Infosources

5. Tunneling transformations



2011 SAP AG 4

Details

1. An SPO is based on either a DSO or an InfoCube

2. Each SPO is made of multiple data providers of the same type with identical structure

3. with its own metadata tables, data tables, data flows and sources/targets, and are independent of each other

4. Each SPO will have a so called Master provider, which acts as a template based on which the underlying providers, called part providers are built

5. While defining metadata for the SPO, the definition is being made implicitly to the master provider, which is then used as a template to create the part providers

6. The part providers are read only, changes to them can be made only via the master provider

7. The consistency of the data model is automatically controlled by the system

8. The part providers are created based inputs provided for partitioning criteria

9. Partitioning criteria define the number of part providers to be created, and the data which is allowed to be loaded to the part providers

10. Definition of the partition criteria contains 2 parts

a. Define the infoobject(s) for criteria - usually derived based on business logic, based on how you want to partition your data, e.g. based on cost centre, business partner, region

b. Data for partition criteria defines how data should be partitioned and loaded between part providers. This is done via an internal logic

11. Inbound infosources

12. During activation of the SPO, along with the Master provider and part provider, there are a few other objects created automatically

a. Inbound and outbound infosources There read-only infosources have identical to the master provider and act as the entry and exit points of data. i.e. when a transformation is created from a source to an SPO, the transformation is implicitly created from the source and the inbound infosource of the SPO. The outbound infosource functions similarly and comes into picture during data extraction from SPO. Only one inbound and outbound infosource can exist per SPO

b. Tunneling transformations These are read-only transformations which are automatically created between the inbound infosources and the part providers. This transformation cannot be changed, any changes should ne made to the main transformation between source and SPO (inbound infosource). Outbound

Naming Conventions

SPO Name SPO001

Master Provider - 00

Part-provider -

Inbound Infosource - _I

Outbound Infosource - _O



2011 SAP AG 5

Modeling

1. . You can choose a template or add objects manually in the next step. Notice that with the 7.30 release, SPO can be used as a template for creating another object.

2. Once you have clicked on create, you are taken to the maintenance mode. There are 3 options for defining the metadata of an SPO

a. Maintain Object

b. Maintain Partitions

c. Start Activation

3. metadata. Changes can be made at this time if required



2011 SAP AG 6

4. Click on maintain partitions to define the partition criteria. First step is to choose the infoObject(s) on which the partition criteria is to be defined. This is based on the business logic.

5. The next step is to maintain the partition criteria for the selected infoObjects. You can add partitions and delete partitions



2011 SAP AG 7

6. If you want to specify multiple values for characteristics where the value range wont be helpful, you can also add multiple selections for each InfoObject in a partition

7. There is an option to add multiple partitions, either based on time or a fixed number of partitions.

8. The time-based partitioning option allows you to specify number of partitions based on available time characteristics



2011 SAP AG 8

9. Once the time characteristic is chosen, mention the time period, and the number of time units per partition. Based on this, the number of partitions to be created is calculated

10. A fixed number of partitions can also be specified

semantic

Documents