HOW TO: BADIs for SPOs with volatile partitions

Version: 1.0

HOW TO: BADIs for SPOs with volatile partitions

Page: 1 / 11

HOW TO: BADIs for SPOs with volatile partitions

Version: 1.0

Document history:
Version

Date

Author

CR

1.0

25-10-2013

Claudio Pinevsky

NA

Comments

Page: 2 / 11

HOW TO: BADIs for SPOs with volatile partitions

Version: 1.0

Table of Contents
1

INTRODUCTION..................................................................................................................... 4
1.1
1.2

Background - The Challenge of Volatile or Complex Logical Partitioning Conditions......................4

Semantically Partitioned Objects (SPOs) and Complex or Volatile Partitioning Conditions.............4

IMPLEMENTATION.................................................................................................................. 5
2.1
Centrally Define SPO PartProvider Implement BAdI RSLPO_BADI_PARTITIONING.................5
2.2
RSLPO_BADI_PARTITIONING: Method GET_T_SPO returns SPOs.........................................5
2.3
RSLPO_BADI_PARTITIONING: Method GET_T_PART - returns Partitions...................................6
2.4
RSLPO_BADI_PARTITIONING: Method GET_T_PART_TEXT - returns description of Partitions.7
2.5
RSLPO_BADI_PARTITIONING: Method GET_T_PART_CRIT - returns Partitioning Criteria
(partition characteristic(s) & values).............................................................................................................. 8

SPO WIZARD MAINTAIN PARTITIONS CALL BADI (2)..........................................................9

4 MASS MAINTENANCE AND ACTIVATION OF SPOS USING BADI VIA TRANSACTION

RSLPO_MASS_ACT...................................................................................................................... 10

Page: 3 / 11

HOW TO: BADIs for SPOs with volatile partitions

Version: 1.0

Background

1.1 The Challenge of Volatile or Complex Logical Partitioning

Conditions
Traditionally logical partitioning modeling is done case by case (tactical logical partitioning). In
other words the definition of logical partitions is done for each InfoCube and each DSO
individually. Nevertheless the partition characteristic and the partition characteristic values assigned
to the PartProviders of different InfoCubes/ DSOs are often identical: e.g. the Sales Order InfoCube
is logical partitioned by year resulting into 3 PartProviders storing data of the last 3 years. The same
partitioning could apply to purchasing order InfoCubes etc.
The logical partitioning for our little example can be modeled in various ways e.g.

Assigning a fix partition characteristic values: assign a fix year for each PartProvider e.g.
PartProvider 1 - for the actual year 2010, PartProvider 2- for 2009, PartProvider 3- for 2008
Modeling a rolling window: define a rule which assigns partition characteristic values (in
the example year) in an automated way to the Partitions
With this simple example we can learn two things (at least):
1. We should not use different logical partitioning implementations for the same requirements of
different InfoProviders as this will decrease maintainability and increase costs. Beside this we will
have a lot of second best implementations like implementation 1. in the example
2. If partitioning conditions are volatile over time we should not assign fix values but a rule based
logical partitioning to remain flexible. The origin of the volatility means that with every new year
the partition condition will change.
If we look to the real world we can learn a third thing:
4. Building a logical partitioned InfoCube or DSO in a continuous roll-out situation not all partition
characteristic values are known at definition time and often even the final number of PartProviders
is not known. That means over time you have to maintain the logical Partitions again and again
assigning new values to PartProviders and/ or creating new PartProviders.
We have this situation designing BWs using the Layered Scalable Architecture (LSA).
We can summarize that individual modeling of Logical Partitioned InfoCubes/ DSOs is the second
best choice especially with large BWs (EDW) as we have numerous InfoProviders following the
same logical partitioning conditions.
1.2 Semantically Partitioned Objects (SPOs) and Complex or Volatile
Partitioning Conditions
The new SPO feature is a big step forward modeling complex partitioning conditions as the new
wizard makes the assignment of partitioning characteristics and partitioning characteristic values to
semantical partitions (PartProvider) transparent and consistent (DTP filters).

Page: 4 / 11

HOW TO: BADIs for SPOs with volatile partitions

Version: 1.0

Nevertheless we still have to manually enter the partition characteristic(s) and partition
characteristic(s) values for each SPO defining the semantical partitions. Thus with the standard SPO
wizard functionality we are confronted with the same challenges mentioned before even though on
a higher more comfortable level:

homogeneous modeling of different SPOs with identical semantical partitioning

characteristic and values
volatile semantical partitioning by time
To overcome these challenges the SPO supports a rule based central definition of PartProviders and
related DTPs offering the possibility to get all necessary criteria defining PartProviders via a BAdI
implementation (BAdI RSLPO_BADI_PARTITIONING).
2

Implementation

2.1 Centrally Define SPO PartProvider Implement BAdI

RSLPO_BADI_PARTITIONING
You have to create a BAdI implementation of the SPO BAdI RSLPO_BADI_PARTITIONING
using SE18/ SE19.
The interface IF_RSLPO_BADI_PARTITIONING contains five
methods:

Fig. 1: SPO BAdI Methods

The methods GET_T_SPO, GET_T_PART, GET_T_PART_TEXT and GET_T_PART_CRIT
return the parameters to define the SPO PartProviders, the method GET_T_PART_DTP returns the
parameters to define the DTPs filling the SPO PartProviders.
2.2 RSLPO_BADI_PARTITIONING: Method GET_T_SPO returns SPOs
We have to return the (technical) names of the SPOs that shall be managed using the BAdI

Fig.2: SPO BAdI Method GET_T_SPO

Coding for our example:

Page: 5 / 11

HOW TO: BADIs for SPOs with volatile partitions

Version: 1.0

method IF_RSLPO_BADI_PARTITIONING~GET_T_SPO.
DATA:
l_spo TYPE rslponame.
* Return a table with names of supported BAdI SPOs.
*
* TEST SPO
L_SPO = 'C9TECP'.
APPEND L_SPO TO R_T_SPO.
endmethod.

In our example the name SPO C9TECP is returned.

2.3 RSLPO_BADI_PARTITIONING: Method GET_T_PART - returns
Partitions
This method is called for each SPO, which is returned by the first method GET_T_SPO and returns
the Partitions and the display position of the Partition.

Fi
g.3: SPO BAdI Method GET_T_PART
Coding for our example:
method IF_RSLPO_BADI_PARTITIONING~GET_T_PART.
DATA:

l_s_part

TYPE rslpo_badi_s_part.

* Return a table with the partitions of SPO I_SPO.

IF I_SPO = 'C9TECP'.
CONSTANTS: C_YEAR_FROM TYPE N LENGTH 4 VALUE '2006'.
DATA: L_IND TYPE N LENGTH 2 VALUE 1,
L_NUM_PART TYPE N LENGTH 2,
L_YEAR_FROM TYPE N LENGTH 4,
L_CURR_YEAR TYPE N LENGTH 4.
L_YEAR_FROM = C_YEAR_FROM(4).
L_YEAR_TO = SY-DATUM(4).
L_NUM_PART = L_YEAR_TO
- L_YEAR_FROM + 1.

Page: 6 / 11

HOW TO: BADIs for SPOs with volatile partitions

Version: 1.0

WHILE L_IND LE L_NUM_PART.

L_S_PART-POSIT = L_IND.
L_S_PART-IDPART = L_IND.
APPEND L_S_PART TO R_T_PART.
L_IND = L_IND + 1.
ENDWHILE.
ENDIF.
ENDMETHOD.

The method returns for our example SPO C9TESTCP four Partitions.
2.4 RSLPO_BADI_PARTITIONING: Method GET_T_PART_TEXT - returns
description of Partitions
This method is called for each SPO, which is returned by the first method GET_T_SPO (other
assignments only done here will be ignored) and returns the names / description of the Partitions.
The method supports multi-languages.

F
ig.4: SPO BAdI Method GET_T_PART_TEXT
method IF_RSLPO_BADI_PARTITIONING~GET_T_PART_TEXT.
DATA:
l_text_d
l_text_e
l_s_part_text

TYPE string,
TYPE string,
TYPE rslpo_badi_s_part_text.

IF I_SPO = 'C9TECP'.
CONSTANTS: C_YEAR_FROM TYPE N LENGTH 4 VALUE '2006'.
DATA: L_IND TYPE N LENGTH 2 VALUE 1,
L_NUM_PART TYPE N LENGTH 2,
L_YEAR_FROM TYPE N LENGTH 4,
L_YEAR_TO TYPE N LENGTH 4.
L_YEAR_FROM = C_YEAR_FROM(4).
L_YEAR_TO = SY-DATUM(4).
L_NUM_PART = L_YEAR_TO - L_YEAR_FROM + 1.
WHILE L_IND LE L_NUM_PART.

Page: 7 / 11

HOW TO: BADIs for SPOs with volatile partitions

Version: 1.0

L_S_PART_TEXT-IDPART = L_IND.
L_S_PART_TEXT-LANGU = 'E'.
L_S_PART_TEXT-TXTLG = L_YEAR_TO.
APPEND L_S_PART_TEXT TO R_T_PART_TEXT.
L_IND = L_IND + 1.
L_YEAR_TO = L_YEAR_TO - 1.
ENDWHILE.
ENDIF.
ENDMETHOD.

2.5 RSLPO_BADI_PARTITIONING: Method GET_T_PART_CRIT - returns

Partitioning Criteria (partition characteristic(s) & values)
This method is called for each SPO, which is returned by the first method GET_T_SPO and returns
the partitioncriteria(s) and the assigned values for partitions returned by the method GET_T_PART
(other assignments onlydone here will be ignored):

Fig.5: SPO BAdI Method GET_T_PART_CRIT

Coding for our example:
method IF_RSLPO_BADI_PARTITIONING~GET_T_PART_CRIT.
DATA:
l_s_part_crit TYPE rslpo_badi_s_part_crit.
* Return a table with the partitioning criteria.
IF I_SPO = 'C9TECP'.
CONSTANTS: C_YEAR_FROM TYPE N LENGTH 4 VALUE '2006'.
DATA: L_IND TYPE N LENGTH 2 VALUE 1,
L_NUM_PART TYPE N LENGTH 2,
L_YEAR_FROM TYPE N LENGTH 4,
L_YEAR_TO TYPE N LENGTH 4.
L_YEAR_FROM = C_YEAR_FROM(4).
L_YEAR_TO = SY-DATUM(4).
L_NUM_PART = L_YEAR_TO - L_YEAR_FROM + 1.
WHILE L_IND LE L_NUM_PART.
L_S_PART_CRIT-POSIT = L_IND.
L_S_PART_CRIT-IDPART = L_IND.
L_S_PART_CRIT-IOBJNM = '0FISCYEAR'.

Page: 8 / 11

HOW TO: BADIs for SPOs with volatile partitions

Version: 1.0

L_S_PART_CRIT-OPT
= 'EQ'.
L_S_PART_CRIT-LOW = L_YEAR_TO.
APPEND L_S_PART_CRIT TO R_T_PART_CRIT.
L_S_PART_CRIT-IOBJNM = '0FISCVARNT'.
L_S_PART_CRIT-OPT
= 'EQ'.
L_S_PART_CRIT-LOW = 'K4'.
APPEND L_S_PART_CRIT TO R_T_PART_CRIT.
L_IND = L_IND + 1.
L_YEAR_TO = L_YEAR_TO - 1.
ENDWHILE.
ENDIF.
ENDMETHOD.

The so far described methods return all information necessary defining the PartProviders of an SPO.
3

SPO Wizard Maintain Partitions Call BAdI (2)

Entering the Partition maintenance screen you do not need to enter any partitions or partition
characteristic values. These are entered via the BAdI: Build Version From BAdI Implementation:

Fig. 6: Example- Maintain SPO Partitions using BAdI implementation screen

The result looks as follows:

Page: 9 / 11

HOW TO: BADIs for SPOs with volatile partitions

Version: 1.0

Fi
g.7: Example- SPO Partitions after getting data using BAdI screen
We observe that all SPO PartProviders are defined like given in the mapping table above: names,
partition characteristic, partition characteristic values and even the sequence like the partitions are
shown.
4

Mass Maintenance and Activation of SPOs Using BAdI via Transaction

RSLPO_MASS_ACT

The Transaction RSLPO_MASS_ACT allows maintaining all BAdI managed SPOs (returned by
method GET_T_SPO) centrally.
RSLPO_MASS_ACT compares the BAdI (methods GET_T_PART, GET_T_PART_TEXT,
GET_T_PART_CRIT) returned SPO definition with the active version of these SPOs and lists
whether there are differences:

Fig.8: Example RSLPO_MASS_ACT screen

In detail the status highlights New Partitions, Deleted Partitions and Changed Partitions.
You can now select any set of BAdI managed SPOs and apply the new BAdI settings in a mass
change and activation run.

Page: 10 / 11

HOW TO: BADIs for SPOs with volatile partitions

Version: 1.0

RSLPO_MASS_ACT allows reducing the SPO interactive modeling to an absolute minimum for
all SPOs managed via BAdI in case of

adding new PartProviders

adding new partition criteria values to existing an PartProvider

removing partition criteria values if no data for this values exist any longer in the
PartProvider (planned)

dropping/ deleting PartProviders

automated generation of DTPs (planned) not just the DTP assignment like with the SPO
Wizard

RSLPO_MASS_ACT functionality therefore perfectly addresses the volatile logical partitioning

challenges mentioned above applying changes consistently throughout BW.

Page: 11 / 11