In this blog series I would like to share how to realize central definition and maintenance of partitioning patterns. The standard Semantically Partitioned Object (SPO) functionality of SAP NetWeaver BW 7.3 is enhanced by implementing Business Add-in (BAdI) RSLPO_BADI_PARTITIONING and few control tables. It facilitates an automated (re)partitioning, either individually or collectively, and enables partitions, criteria, texts and Data Transfer Processes (DTPs) to be generated automatically and consistently.
The blog series consists of the following blogs in addition to this blog:
- Pattern-based Partitioning using the SPO BAdI – Part 1: Introduction;
- Pattern-based Partitioning using the SPO BAdI – Part 2: BAdI Managed Maintenance;
- Pattern-based Partitioning using the SPO BAdI – Part 4: Use Cases.
I developed a working version of the BAdI implementation which I would like to share via two documents. Implementing Pattern-based Partitioning using the SPO BAdI – Part 1: Control Tables contains all technical details of creating the control tables and the related ABAP data dictionary objects. Implementing Pattern-based Partitioning using the SPO BAdI – Part 2: BAdI Implementation explains all technical details of implementing BAdI RSLPO_BADI_PARTITIONING and the necessary ABAP Object Oriented programming in the implementing class.
Authorized Partitioning Patterns
SAP BW Layered, Scalable Architecture (LSA – SAP’s best practice in Enterprise Data Warehousing) propagates a central definition of modeling patterns. In the context of logical partitioning, it would make sense to introduce authorized partitioning patterns to enable a central definition and maintenance of partitioning patterns. This leads to a uniform and consistent modeling throughout the entire LSA Enterprise Data Warehouse. It also offers an increased transparency of partitioning with criteria, texts and DTPs implemented by different people in the various project teams.
We can define and maintain these partition patterns in central tables. It will reduce the risk of input errors, multiple ways-of-working, different interpretations, duplicate and possibly inconsistent values, etc. The SPOs can reuse the partition patterns and the BAdI will take care of the generation of partitions by combining the partition patterns. The texts and DTPs are also in scope of the automatic generation procedure.
In the paragraph How to Use the Control Tables you will learn more which control tables are implemented and the way they are intended to be used.
Maximum Number of Partitions
Let’s have a look at the maximum number of partitions. A maximum of 1,295 partitions can be created. The maximum of 99 partitions was increased in SAP NetWeaver BW 7.3 SP4. Please refer also to the release notes and SAP Note 1590179.
The Partition ID field has data type Character (CHAR) and is 2 positions long. Before this support package, only digits were allowed where partition ID ‘00’ was reserved for the master partition. This resulted in a maximum of 99 partitions.
Currently, also the 26 uppercase letters are allowed. This yields a lot more combinations: 36 x 36 = 1,296. However, partition ID ‘00’ is still reserved for the master partition, so the maximum becomes 1,295 partitions.
Although it is technically possible to create up to 1,295 partitions, it’s wise to consider a few things:
- What is the estimated data volume per year and how many years of history are required;
- What is the underlying database;
- Is In-Memory technology used (i.e. BW Accelerator or HANA);
- What are the Information Lifecycle Management requirements (data archiving and near-line storage).
One should avoid creating too small partitions. Each partition should hold a reasonable volume of data. How much is dependent on the underlying database. Databases such as Oracle and IBM DB2 are designed to handle huge volumes of data, e.g. because of table partitioning or clustering technology. IBM DB2 even offers Database Partitioning Feature (DPF), a technology to assign tablespaces to multiple database partitions which can be spread across multiple database nodes.
Also using In-Memory technology should be taken into consideration. Such technologies offer out-of-the-box partitioning features, both hardware-based and software-based.
Last but not least, Information Lifecycle Management plays a role in determining the optimal configuration of logical partitions. It might be convenient to use partitioning in conjunction with data archiving and near-line storage.
The maximum number of partitions of the Pattern-based Partitioning solution is intentionally limited to 99 partitions. This will be sufficient under normal circumstances. However, it is technically possible to increase the number of partitions.
How to Use the Control Tables
The BAdI automated scenario should be implemented using control tables. You can find below an introduction on how to use the control tables. There are in total 5 control tables required:
- YSPOINFOPROV – SPO BAdI Managed InfoProvider;
- YSPOPATTERN – SPO Authorized Partition Pattern;
- YSPOPATTERNT – SPO Authorized Partition Pattern Text;
- YSPOCRITERIA – SPO Pattern Partition Criteria;
- YSPODTP – SPO BAdI Managed DTP.
The first control table YSPOINFOPROV contains the BAdI managed SPO InfoProviders. Here you can store the SPO InfoProviders that have to be managed by the BAdI.
Figure 1: Control Table BAdI Managed SPOInfoProvider
As you can see you can define up to 2 partitioning patterns. This concept is explained in the paragraph Authorized Partitioning Patterns.
The next two tables, YSPOPATTERN and YSPOPATTERNT, are necessary for the maintenance of partitioning patterns.
Figure 2: Control Table Partitioning Patterns
The text table is integrated with the main table and both can be maintained at the same time. Please take into account that the texts are only maintained in the logon language.
The next table YSPOCRITERIA makes it possible to maintain the partitioning criteria.
Figure 3: Control Table Partitioning Criteria
The partitioning group is required to group together multiple single values belonging to the same partition. Furthermore it’s not possible to combine single values and intervals within the same group simultaneously. By the way, this is a standard design limitation of SPO.
The last table YSPODTP contains all DTP settings for the SPO InfoProvider.
Figure 4: Control Table DTPs
Here you can specify which data sources have to be used to extract data and the required DTP Template. It’s is possible to specify more than one data source object for every SPO InfoProvider.
In this blog you learned more about authorized partitioning patterns, the maximum number of partitions and how to use the control tables. The solution provides a way to define and maintain the partitioning patterns (including the partitioning criteria) centrally. For every new SPO InfoProvider you assign one or two partitioning patterns. The BAdI is able to combine the partitioning patterns and will generate all configuration automatically and consistently.
In the last blog Pattern-based Partitioning using the SPO BAdI – Part 4: Use Cases I will highlight some use cases of pattern-based partitioning based on LSA data flow templates.