Semantically Partitioned Object sap bw 7.3

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

Model DTP‟s via BAdi ................................................................................................................................................ 19

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

Use SPO‟s/part providers in multiproviders .................................................................................................. 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. Each of the underlying data providers (of the SPO) behaves like a “regular” DSO or InfoCube, 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 - <SPO001>00

Part-provider - <SPO001>01, <SPO001>02, <SPO001>03….

Inbound Infosource - <SPO001>_I

Outbound Infosource - <SPO001>_O



© 2011 SAP AG 5

Modeling

1. SPO‟s can be created via the DSO or InfoCube creation screen in RSA1. 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. By using a template, the metadata of the template object is copied to the master provider‟s 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



© 2011 SAP AG 9

11. At any point if there is a need to change the partitioning InfoObjects, it can be done by clicking the “change InfoObjects” button

12. The next step is to activate the SPO



© 2011 SAP AG 10

13. Upon activation, a log is presented which contains detailed information about the activation details of all dependent objects, at various stages of activation

14. The structure of the SPO in rsa1 after the activation



© 2011 SAP AG 11

Including SPO in Data Flow

1. After the metadata of the SPO is created, the next step is to include the SPO in a dataflow. The SPO can be the target of a BW transformation from any source, including another SPO. The transformation to an SPO can either be created from the SPO maintenance screen, or from the context menu of the SPO in rsa1. For this example, we will use the SPO maintenance screen to create the transformation. Click on create transformation under further options

2. The transformation creation screen pops up, provide source details, make changes to the transformation and activate

3. All rules and routines to be applied to the part providers of the SPO should be provided to this master transformation. Changes are not allowed to the tunneling transformations

4. Upon activation of the transformation, DTP‟s can be created. The SPO maintenance screen has special DTP maintenance options for the SPO objects. DTP settings can be saved as DTP templates which can then be applied to any DTP in the SPO maintenance screen at a later point of time. The DTP templates can be organized in folders.

5. To create a DTP filter, goto „create data transfer process‟ in SPO maintenance, click on create template



© 2011 SAP AG 12

6. Here, you can choose most DTP options you would normally require. If you set the filter as user defined, then the user has to specify filter criteria in the DTP filter tab after the DTP is activated

Note: The partitioning criteria specified while defining partitions will be added to the DTP filter by default (can be changed by user). This filter will be enforced while loading data to part providers irrespective of its existence in the DTP filter.



© 2011 SAP AG 13

7. Once the templates are saved, click on the datasources for which the DTP‟s are to be assigned, select the DTP template to be applied, and click on assign. Once the DTP‟s are assigned, click on generate to activate the DTP‟s. You can execute the DTP‟s (multiple) via this screen

Note: make sure the datasource type of the template corresponds to the datasource selected. Any runtime errors like already existing DTP is caught during activation.

8. You can create process chains to execute these DTP‟s and the SPO maintenance offers tools to automate this process. Goto create process chain, either drag and drop the DTP‟s or select and click on add.



© 2011 SAP AG 14

9. Properties like „add create/delete indices‟, rollup, sequence and path of the variants can be specified. For a data store object, the activation properties can be specified. Additionally, you can create a new chain. Once the properties are specified, you can save and generate the process chain. Upon generation, the process chain start variant maintenance screen appears, where you can specify the scheduling criteria. On exiting this screen, the process chain is activ

10. Structure of SPO with dataflow in RSA1



© 2011 SAP AG 15

Tables

Important tables

RSLPO – SPO directory

RSLPOCOMP – Contains the components of the SPO. Here is the table entries just created

RSLPOPART – contains part providers of the SPO

RSLPOPARTRANGE – contains partition criteria for the different partitions

List of all relevant tables

Table Purpose

RSLPO Logical Partitioning: Directory of LPOs

RSLPO_DFG_DTPFOL Table for Managing Folders for DTP Templates

RSLPO_DFG_DTPGEN Table of Generated DTPs

RSLPO_DFG_DTPTPL Table of DTP Templates

RSLPO_DFG_GENTGT Pseudo Table for Lock Requests at Target TLOGO

RSLPO_LOCKS Persistent Locks

RSLPO_PC_THREAD Process Chain Generation - Threads

RSLPOCOMP Logical Partitioning: Components of a LPO

RSLPOCOMPTEXT Logical Partitioning: Texts for Components of LPO

RSLPODBPART Semantic Partitioning: Criteria for DB Partitioning

RSLPOPARAM LPO Parameter

RSLPOPART Logical Partitioning: Partitions of a LPO

RSLPOPARTRANGE Logical Partitioning: Partitioning Criteria

RSLPOSCHED Logical Partitioning: Scheduling Options for BTC Jobs

RSLPOT Logical Partitioning: Texts for LPOs



© 2011 SAP AG 16

Enhanced Modeling

Model partitions via BAdi

SAP provides an option of specifying complex partitioning criteria via BAdi RSLPO_BADI_PARTITIONING. The BAdi contains interface IF_RSLPO_BADI_PARTITIONING which provides five methods which have to be implemented with the logic for partitions and DTP:

GET_T_SPO Supplies table with semantically partitioned objects

GET_T_PART Supplies table with partitions

GET_T_PART_TEXT Supplies table with names for partitions

GET_T_PART_CRIT Supplies table with partitioning criteria

GET_T_PART_DTP Supplies table with data transfer processes

How it works

Partitioning characteristics can be obtained from a BAdi

Once the partitioning characteristic has been selected, the partitioning criteria can be selected via BAdi as follows:



© 2011 SAP AG 17

BAdi Implementation

To achieve the following, create an interface and code the methods of the interface as follows

IF_RSLPO_BADI_PARTITIONING~GET_T_SPO

method IF_RSLPO_BADI_PARTITIONING~GET_T_SPO.

*provide the tech names of the SPO's for which partitioning

*has to be created or DTP has to be generated

DATA:

l_spo TYPE rslponame.

l_spo = 'RSPO4'.

APPEND l_spo TO r_t_spo.

l_spo = 'RSPO10'.


l_spo = 'RSPO11'.


l_spo = 'RSPO12'.


l_spo = 'RSPO26'.


l_spo = 'RSPO27'.


endmethod.

IF_RSLPO_BADI_PARTITIONING~GET_T_PART

method IF_RSLPO_BADI_PARTITIONING~GET_T_PART.

DATA:

l_s_part TYPE rslpo_BAdi_s_part.

CASE i_spo.

WHEN 'RSPO10'.

l_s_part-idpart = '01'.

l_s_part-posit = 1.

APPEND l_s_part TO r_t_part.


l_s_part-posit = 2.


WHEN 'RSPO4'.


l_s_part-posit = 1.



l_s_part-posit = 2.


WHEN 'RSPO11'.


l_s_part-posit = 1.




© 2011 SAP AG 18


l_s_part-posit = 2.


endcase.

endmethod.

IF_RSLPO_BADI_PARTITIONING~GET_T_PART_TEXT

method IF_RSLPO_BADI_PARTITIONING~GET_T_PART_TEXT.

DATA:

l_s_part_text TYPE rslpo_BAdi_s_part_text.

CASE i_spo.

WHEN 'RSPO10'.

l_s_part_text-idpart = '01'.

l_s_part_text-langu = 'E'.

l_s_part_text-txtlg = 'UN'.

APPEND l_s_part_text TO r_t_part_text.

l_s_part_text-idpart = '02'.

l_s_part_text-langu = 'E'.

l_s_part_text-txtlg = 'DUES'.

APPEND l_s_part_text TO r_t_part_text.

endcase.

endmethod.

IF_RSLPO_BADI_PARTITIONING~GET_T_PART_CRIT

method IF_RSLPO_BADI_PARTITIONING~GET_T_PART_CRIT.

DATA:

l_s_part_crit TYPE rslpo_BAdi_s_part_crit.

CASE i_spo.

WHEN 'RSPO10'.

l_s_part_crit-idpart = '01'.

l_s_part_crit-iobjnm = '0EC_MESTATU'.

l_s_part_crit-posit = 1.

l_s_part_crit-opt = 'EQ'.

l_s_part_crit-low = 'M2'.

* l_s_part_crit-HIGH = '20'.

APPEND l_s_part_crit TO r_t_part_crit.

l_s_part_crit-idpart = '02'.

l_s_part_crit-iobjnm = '0EC_MESTATU'.

l_s_part_crit-posit = 1.

l_s_part_crit-opt = 'EQ'.

l_s_part_crit-low = 'M4'.

* l_s_part_crit-HIGH = '20'.

APPEND l_s_part_crit TO r_t_part_crit.

endcase.

endmethod.



© 2011 SAP AG 19

Model DTP‟s via BAdi

DTP‟s can be assigned via BAdi in the SPO DTP maintenance screen

Implement the interface IF_RSLPO_BADI_PARTITIONING~GET_T_PART_DTP

method IF_RSLPO_BADI_PARTITIONING~GET_T_PART_DTP.

data l_s_part_dtp type rslpo_BAdi_s_part_dtp.

case I_spo.

when 'RSPO10'.

l_s_part_dtp-idpart = '01'.

l_s_part_dtp-dtptemplate = 'source = DS'.

l_s_part_dtp-OBJNM = 'ZRDK_DS1'.

l_s_part_dtp-tlogo = 'RSDS'.

l_s_part_dtp-logsys = 'BIYCLNT000'.

APPEND l_s_part_dtp to r_t_part_dtp.

l_s_part_dtp-idpart = '02'.

l_s_part_dtp-dtptemplate = 'source = DS'.

l_s_part_dtp-OBJNM = 'ZRDK_DS1'.

l_s_part_dtp-tlogo = 'RSDS'.

l_s_part_dtp-logsys = 'BIYCLNT000'.

APPEND l_s_part_dtp to r_t_part_dtp.

endcase.

endmethod.



© 2011 SAP AG 20

Additional options

Use SPO’s/part providers in multiproviders

SPO objects can be included in multiproviders. Also, the part providers of an SPO can be used in a multiprovider independently of an SPO

Archiving

Data from the part providers of an SPO can be archived using the BW archiving process. An archiving object can be created via the context menu of the SPO. Once activated, archiving can be performed by clicking the archiving button on the SPO maintenance, which leads to the standard archiving request screen



© 2011 SAP AG 21

The create archiving request screen has additional options pertaining to SPO, where the administrator can choose to archive data from all partitions or from single partitions

SPO Mass Activation

Transaction RSLPO_MASS_ACT provides a UI where multiple SPO‟s can be activated at once. The UI provides information about changed partitions, new partitions and deleted partitions. Activating from this UI also takes in the changes provided by the BAdi. There is a version comparison which shows differences between active and the modified versions



© 2011 SAP AG 22

Related Content

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/21334Reference 2

https://weblogs.sdn.sap.com/pub/wlg/24825

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/24829

For more information, please visit the EDW homepage.



https://weblogs.sdn.sap.com/pub/wlg/24825


https://www.sdn.sap.com/irj/sdn/businessone



© 2011 SAP AG 23

Copyright

© Copyright 2011 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Oracle Corporation.

JavaScript is a registered trademark of Oracle Corporation, used under license for technology invented and implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Documents

Semantically Partitioned Object sap bw 7.3