Applies to:

SAP BPC 7.5/SAP BW 7.3x

Summary:

This document explains Badi usage in BPC context .BADIs are always faster than Script Logic and can become useful where we have comlex business requirements .

Document covers Introduction of BADI wrt BPC ,creation of BADIs, useful methods during BADI Creation and Testing/Debugging Created BADIs .

Author(s)     :  Amit Kumar Trivedi

Company    :   Infosys Limited

Created on  :  21 August 2013

Author Bio

Amit Kumar Trivedi works as Senior Systems Engineer in Infosys Limited. He has 3.7 years of experience in

SAP BW/ ABAP. He has worked on Various Support and implementation Projects.

Table of Contents

1) Basic Introduction

2) Creating Custom Badi/Script Logic/DM Package

3) Useful Methods in Writing Badi

4) Debugging/Testing Badi.

5) Execution Sequence

1) Basic Introduction

a)     a) BADI vs Script Logic: Make use of Badi wherein you have complex logic to implement. Badi’s are always faster if it is of good design.

BADIs have capability of providing platform to write complex logics using ABAP. It can use capabilities like internal table, methods available to read master  data /transactional data which will be useful to write complex codes and achieve complex business requirements.

It also has its own disadvantages that you will not be able to see the BADIs from BPC Client which creates readability issues .Also you should have knowledge of ABAP to implement it.

Script Logics can be useful when we have limited scope for execution .But these are difficult to implement when we have complex business requirements. Also from execution point of view they do not provide good performance because of multiple parsing for each call due to which multiple READ/WRITE operation takes place.

Note: We should avoid putting all our logic implementation in WriteBack Badi as this is executed every call of Input Schedule .Instead we can make use of Custom Badi to have different logics implemented as there is no limit on Number of Custom Badi in an application, whereas in a single implementation only One WriteBack Badi is written.

b)     b) WriteBack Badi  vs Custom Badi

WriteBack Badi is used when we want to write back the records with certain fashion like disaggregation, distribution etc. For ex: There would be scenarios where the planning is done at higher levels and the data needs to be disaggregated to the child members , in this case we need to have WriteBack Badi to disaggregate data till child members . It’s a Preprocess logic that gets executed first in every call. This is written under Enhancement Spot “UJR_WRITE_BACK”.

Custom Badi is used to execute logic which can be linked with Data Manager Packages. We can achieve a performance boost by using Custom Badi instead of script logics. We can use this in Currency Conversions, Unit of Measure Conversions etc. This is written under Enhancement Spot UJ_CUSTOM_LOGIC.

2)  Creating Custom Badi/Script Logic/DM Package

a)      Creating a Custom Badi

Note: [The Steps shown below doesn’t cover creation of Enhancement Spot. Already enough documents are present for the same to go through]

Step 1: Go to SE 19.Enter the Enhancement Spot name (UJ_CUSTOM_LOGIC for Custom Badi) and click on create Impl. as shown below.

Step 2: A new window will open. Enter the Enhacement Implementation Name and short text and press on Continue .

Step 3: Enter the Badi Implementation , Implementing Class ,BADI Definition and press on continue as shown below .

Step 4: In new window you will get details for the created Enhancement Implementation.

For ex: - Badi definition Name, Interface used for creating Enhancement Spot, Whether Implementation is Active.

Step 5: Go to Filter Val. And provide combination value which will be used in Script logic to call the Custom Badi.

Click on Create Combination .Below option will come as shown below.

After that, click on Change Filter Value; provide Value for Filter and press continue.

Step 6: Writing the Code for implementation .Double Click on Implementing Class as shown below.

Double Click on Method to open the ABAP window to write the actual code .Couple of Dialog Windows will open just press on “Yes” and continue.

Step 7: Blank window will get open. You need to write your Logic in between the Start of Method and End of Method.

Step 8: A simple Custom Badi to Take a RECORD AND Copy it to Another Key.

Step 9: Finally Activate the Badi and Badi is ready to be used in Script logic call.

b)    b)   Creating a Script Logic and linking it with Custom Badi

Step1 :  Go to BPC Admin Client and go for “Create New Logic” .Enter a Technical Name and click on Ok to continue .

Step2:  Write below code and click on “Validate and Save”. Script Logic is created.

.

c)     c) Creating a Data Manager Package and linking it with Script Logic.

Step1: Go to BPC Excel client and then to Planning and Consolidation tab as shown below.

Step 2: Follow the standard procedure to create a DM Package. Already enough documents are available in SDN for the same. One Sample DM Package linking with Script Logic is shown below.

3) Useful Methods in Writing Badi

a)     a) Reading the Dimension Member Data. : - Reading a GEOGRAPHY Dimension Member data.

DATA: lv_appset_id TYPE uj_appset_id VALUE 'ABC',        “ APPSET ID
      lo_geography TYPE REF TO if_uja_dim_data,          " Object Reference

      ls_hier_info TYPE uja_s_hier,
      lt_hier_name TYPE uja_t_hier_name,

      ls_attr_list TYPE uja_s_attr,

      lt_attr_name_geo TYPE uja_t_attr_name ,

      lr_data TYPE REF TO data.

FIELD-SYMBOLS:

      <lt_geo_mbr> TYPE HASHED TABLE,        " All entity members

"Object Creation

lo_geography = cl_uja_admin_mgr=>create_dim_ref( i_appset_id = lv_appset_id
                                                 i_dim_name = 'GEOGRAPHY' ).

“Choosing Attributes of Dimension to be read.

If we want to read only two Attributes “Country” and “Area” & Hierarchy from GEOGRAPHY Dimension, then take out those attributes and put them in table lt_attr_name_geo and lt_hire_name.

ls_hier_info-hier_name =

APPEND ls_hier_info-hier_name TO lt_hier_name.

ls_attr_list-attribute_name =

APPEND ls_attr_list-attribute_name TO lt_attr_name_geo.

ls_attr_list-attribute_name = 'AREA'.

APPEND ls_attr_list-attribute_name TO lt_attr_name_geo.

* Retrieving the Dimension member for Geography .
CALL METHOD lo_geography->read_mbr_data
    EXPORTING
       if_ret_hashtab = abap_true
       it_attr_list   = lt_attr_name_geo          " columns:attributes name list
       it_hier_list   = lt_hier_name              " columns:hieracies name list
    IMPORTING
       er_data        = lr_data.
    ASSIGN lr_data->* TO <lt_geo_mbr>.

<lt_geo_mbr> will have the data read from the Dimension GEOGRAPHY from BPC and can be used in Badi as per your requirement.

b)     b)  Reading the Dimension Names of an Application.

Below is the technique of referring to the cube dimensions indirectly through application name so that you we are immune to cube changes due to full optimize.

DATA: lo_appl TYPE REF TO cl_uja_application,

      lv_appset_id TYPE uj_appset_id VALUE 'ABC',
      lv_application_id TYPE uj_appl_id VALUE 'APPLICATION',

      lt_appl_dim TYPE uja_t_appl_dim,

      lt_dim_name TYPE ujq_t_dim,

      ls_appl_dim LIKE LINE OF lt_appl_dim,

ls_dim_name LIKE LINE OF lt_dim_name,

* Retrieving the  Dimension Name
      CREATE OBJECT lo_appl
        EXPORTING
          i_appset_id      = lv_appset_id
          i_application_id = lv_application_id.

      REFRESH lt_appl_dim.
      lo_appl->get_appl_dim(
                EXPORTING
                    i_appl_id   = lv_application_id
                IMPORTING
                    et_appl_dim = lt_appl_dim ).

      REFRESH lt_dim_name.
* Retrieving the Dimension name Of The SMP Application.
      LOOP AT lt_appl_dim INTO ls_appl_dim.
        ls_dim_name = ls_appl_dim-dimension.
        APPEND ls_dim_name TO lt_dim_name.
        CLEAR ls_dim_name.
      ENDLOOP.

Further lt_dim_name can be used to read the transactional data from cube. Please see next points how to read transactional data from cube.

c)    c)   Reading the Transactional Data from the cube.

DATA:   lv_appset_id TYPE uj_appset_id VALUE 'ABC',
        lv_application_id1 TYPE uj_appl_id VALUE 'APPLICATION',
        lt_dim_name TYPE ujq_t_dim,

        it_sel TYPE uj0_t_sel,

                   wa_sel TYPE uj0_s_sel,

“Selection table to filter the Result Set from the Cube Read. Data for Geography INDIA will be read from the cube.

CLEAR : it_sel.
        wa_sel-dimension = 'GEOGRAPHY'.
        wa_sel-attribute = 'ID'.
        wa_sel-sign      = 'I'.
        wa_sel-option    = 'EQ'.
        wa_sel-low       = ‘INDIA’.
        wa_sel-high      = ''.
        APPEND wa_sel TO it_sel.
        CLEAR wa_sel.
** Call SQE to read transaction data
        TRY.
            CALL FUNCTION 'UJQ_RUN_RSDRI_QUERY'
              EXPORTING
                i_appset_id       = lv_appset_id  “ Appset Id
                i_appl_id         = lv_application_id1   “ Application
                it_dim_name       = lt_dim_name “ Dimensions
                it_sel            = it_sel “ Selection Table
                if_check_security = abap_true “ to enable Security Check
              IMPORTING
                et_data           = it_rate_data. “ Output
          CATCH cx_ujq_exception.
        ENDTRY.

Other Important Parameters available in Function Module.

a)      Package Size: - You can define your own Package Size and then the output will have same number of records in each data package.

b)      Security Check: - Default value for this is “ABAP_TRUE”. If this value is set Cube read checks for the security.

c)      Database Aggregate: - Default value for this is “ABAP_TRUE”. If this value is set to true, cube read makes use of Database Aggregates.

d)      d)  Reading the Child members of a Hierarchy.

DATA: lo_geography TYPE REF TO if_uja_dim_data,

*To get the children if any
      CALL METHOD lo_geography->get_children_mbr
        EXPORTING
          i_parent_mbr     = ‘ASIA’" Parent
          i_level          = -99 " -99 = All children in any level; -1 = direct child
          if_only_base_mbr = abap_true " Only base member
        IMPORTING
          et_member        = lt_geography_mbr.

lt_geography_mbr   will have  all the Child Members for Geography ASIA .

4) Debugging/Testing Badi

Debugging is the best way of understanding ABAP code .There is a small difference in debugging process for Data Manager Packages and for Input Schedule.

1)      Debugging Badi for Data Manager Package Run/Offline Run :-

Ø  Go to SE24, Enter Class name: - CL_UJD_START_PACKAGE.

Click on Display.

Ø  Double click on Method “RUN_PACKAGE”. You will be taken to ABAP Editor.

Ø  Go to Method Call RUN_PACKAGE_P and apply External Breakpoint at this line.

Ø  Go to your Badi and apply External Breakpoint at the line from where you want to start the Debugging .Debugging Pointer will directly come at that line.

Ø  After that you can run the Data Manager Package giving your selections .

Ø  You will be redirected to the below screen .Double click on LF_SYNCHRONOUES and change the value of it to ‘X and press enter’. Initially it will be blank .After that press F7 to navigate into the Badi Screen .

Ø  Once you click on F7 you will be directed to your Custom Badi , where you can follow normal  way of doing the debugging .

     To Execute Single Step: - Press F5

     To Execute: - Press F6

     To Return: - F7

     To Continue: - Press F8.

2)      Debugging Badi for Input Schedule/Online Run: - The only difference in Input Schedule Badi debugging is that you don’t need to put Break Point in class rather you can directly put Breakpoint in Custom Badi and you will be  taken into custom Badi Debugging screen.

5) Execution Sequence

Below is the sequence of execution of different objects in SAP BPC.

WB->CR->DL->WB->CR->CB1->WB->CR->CB2… and so on .

Notation Used

WB  -> WriteBack Badi

CR    -> Cube Read based on scoping

DL    -> Default Logic

CB1  -> Custom Badi 1

CB2  -> Custom Badi 2