uj custom logic

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

© 2010 SAP AG 1

BPC 7.X for NetWeaver:

Performance Improvements for

BADI UJ_CUSTOM_LOGIC Using

Buffer Objects

Applies to:

BW 7.X, BPC 7.X for NetWeaver

Summary

To implement efficient customer based planning algorithms buffering techniques are necessary, especially if the memory requirements are high and the algorithm is executed in packages. Implementing customer defined planning algorithm can be done in BPC 7.X for NetWeaver by implementing BADI UJ_CUSTOM_LOGIC. Unfortunately the BADI does not provide an initialization routine or finalization routines, which allows filling internal buffers in the beginning of the algorithm and clean them at the end. This paper shows a work around for this issue and shows how efficient algorithms can be implemented by using a special buffer object. The buffer object has an initialization routine to fill the buffers and a finalize routine to clear the buffers again. Furthermore it provides methods to access the buffered data. This paper outlines the concept and shows how the concept can be used.

Author: Matthias Nutt

Company: SAP (Switzerland) AG

Created on: 08 June 2010

Author Bio

Matthias Nutt works for SAP (Switzerland) AG. He is a professional consultant since 2002 and works in the area of BW in close co-operation with the development and support team. His work spans a variety of roles including project manager, technical project manager, consulting, development, primary support and development support.

BPC 7.X for NetWeaver: Performance Improvements for BADI UJ_CUSTOM_LOGIC Using Buffer Objects


© 2010 SAP AG 2

Table of Contents

Introduction ......................................................................................................................................................... 3

Simulating and Initialization/Finalization Routine ............................................................................................... 3

Implementing class ZCL_BPC_INIT_EXEC_FINISH ......................................................................................... 5

Interfaces ........................................................................................................................................................ 5

Methods .......................................................................................................................................................... 5 Method if_uj_custom_logic~execute ............................................................................................................................ 6

Method _get_identifier ................................................................................................................................................. 8

Method _execute ......................................................................................................................................................... 8

Implementing Class ZCL_BPC_INIT_EXEC_FINISH_SGLTN ........................................................................ 10

Public types ................................................................................................................................................... 11

Attributes ....................................................................................................................................................... 11

Methods ........................................................................................................................................................ 12 Method get_instance .................................................................................................................................................. 12

Method initialize ......................................................................................................................................................... 13

Method get_entity_data ............................................................................................................................................. 15

Miscellaneous ................................................................................................................................................... 16

Copyright........................................................................................................................................................... 17



© 2010 SAP AG 3

Introduction

Runtime efficient implementations needs some kind of buffers for data which is used several times but should only be once read from the data base for performance reasons. Usually these data is read from the data base in an initialization phase and stored in internal buffers for faster access. If the data is not needed anymore e.g. at the end of the algorithm, the buffers can be deleted again or can be kept for the next run of the algorithm. Deletion of buffered data typically happens in a finalization phase. Unfortunately in BPC the BADI UJ_CUSTOM_LOGIC does not provide an initialization method or a finalization method. Furthermore if

the script logic statement *XDIM_MAXMEMBERS is used, the system reads the list of dimension members and splits the dimension members into several packages. Each package is processed separately, which means that the BADI is called once for each package. Inside the BADI you can refer to the current package by reading the data provided in table IT_CV. This allows writing algorithms which work only on the current package of data. At this point is it important to know that the BADI is instantiated again for each package of data. This will clear non-static attributes of the BADI implementation. Thus non-static attributes cannot serve as buffers for UJ_CUSTOM_LOGIC BADI. A work around would be using static attributes to buffer data. Nevertheless it is still hard to determine the first call to the BADI or the last call to the BADI implementation to re-initialize or delete the buffered data. The following shows a work around by using a special buffer object. Technically the special buffer object can be seen as an implementation of the singleton programming concept. Please note that this paper does not discuss the singleton concept in detail. For further information please refer to a book on advanced programming concepts.

Simulating and Initialization/Finalization Routine

As stated above the BADI UJ_CUSTOM_LOGIC does not provide an initialization or finalization method. To effectively buffer data these methods can be very useful to control the buffer. In general an algorithm can be divided in three phases.

1. Initialization: Initialization activities like reading the necessary data and some additional data from the database. Storing some of this data in local buffers to speed up processing in phase 2 (e.g. reading some attributes of a dimension: the attributes do not change during the runtime of the algorithm and can be stored in a internal buffer for faster read access)

2. Execution: Execution of the algorithm which implements the planning requirements.

3. Finalization: Cleaning up activities like clearing the buffers, setting internal status flags, etc.

To simulate this behavior in BADI UJ_COSTUM_LOGIC an additional parameter “MODE” for the BADI is introduced. The parameter controls the phase. Without parameter mode the script logic looks like this:

*START_BADI Z_BPC_INIT_EXEC_FINISH WRITE = ON QUERY = ON *END_BADI

As can be seen the BADI is called only once. There no explicit initialization or finalization phase. In the next example below a single line is added. The statement “*XDIM_MAXMEMBERS” defines that the data is processed in packages. The BADI is called several times by the BPC framework depending on the amount of members for dimension P_ACCT. For each package the whole planning function is called again. If data (e.g. attributes of members) is read from the database in the BADI implementation, this is done for each single package and impacts the runtime of the BADI.

// processing data in packages because otherwise the memory requirements are too high

*XDIM_MAXMEMBERS P_ACCT = 1 *START_BADI Z_BPC_INIT_EXEC_FINISH WRITE = ON QUERY = ON *END_BADI



© 2010 SAP AG 4

To prevent reading the same data from the database over and over again, a way needs to be provided to read the data only once, buffer it and release the buffer in the end. The work around presented here achieves this behavior by calling the BADI three times. An additional parameter is introduced. The parameter MODE controls the phase (initialization, execution, and finalization). For each phase the BADI is called separately. This is demonstrated in the script below.

The script logic contains the following statements now:

// initialize – fill the buffer

*START_BADI Z_BPC_INIT_EXEC_FINISH WRITE = OFF QUERY = OFF MODE = INIT *END_BADI

// processing data in packages because otherwise the memory requirements are too high

*XDIM_MAXMEMBERS P_ACCT = 1 *START_BADI Z_BPC_INIT_EXEC_FINISH WRITE = ON QUERY = ON MODE = EXEC *END_BADI // finalize – clean the buffer *START_BADI Z_BPC_INIT_EXEC_FINISH WRITE = OFF QUERY = OFF MODE = FINISH *END_BADI

It is important to set the parameter WRITE and QUERY to OFF when the parameter MODE is equal to INIT or FINISH. In these two phases no transactional data should be read or written. This ensures that the BPC framework calls the BADI with minimal overhead. In mode EXEC the parameters WRITE and QUERY can be set to ON or OFF depending on the needs of the algorithm.

To implement the desired behavior two classes are used. The first one implements the BADI UJ_CUSTOM_LOGIC and has the name ZCL_BPC_INIT_EXEC_FINISH. This is the real BADI implementation. It implements the planning functionality in mode EXEC. For the other modes the class works as dispatcher and calls depending on the mode a method of class ZCL_BPC_INIT_EXEC_FINISH_SGLTN, which implements the buffer object. Basically the buffer object is a normal class. The only special thing is that this class represents a singleton. Instead of calling the constructor directly method GET_INSTANCE must be used to retrieve an instance of this class. This allows controlling the creation of instances and here it means that there is only one instance of it in a session. Furthermore the lifetime of this object and the attribute values can be controlled by the programmer. As there is only one instance in the session memory which is not deleted during the different calls to the BADI, non-static attributes of this class can be used as buffers.



© 2010 SAP AG 5

Implementing class ZCL_BPC_INIT_EXEC_FINISH

Class ZCL_BPC_INIT_EXEC_FINISH is a simple implementation of the BADI UJ_CUSTOM_LOGIC. The remainder of this chapter shows how the class is implemented. For educational reason we discuss this class first, but if you are going to implement it class ZCL_BPC_INIT_EXEC_FINISH_SGLTN needs to be implemented first.

Interfaces

Class ZCL_BPC_INIT_EXEC_FINISH is the BADI implementation and because of this it has the interfaces IF_BADI_INTERFACE and IF_UJ_CUSTOM_LOGIC as demonstrated in the screenshot below.

Methods

The class implements the following methods: Method IF_UJ_CUSTOM_LOGIC~EXECUTE, method _GET_IDENTIFIER and method _EXECUTE. The details are discussed below in the screenshot.



© 2010 SAP AG 6

Method if_uj_custom_logic~execute

Parameters

Discussion

The code for this method is shown below. Here we outline the implementation principle. At first the current mode is retrieved from the parameters. In the next step the system reads a unique identifier for this BADI Implementation. Once this is done, the instance of the buffer object is determined. The following case statement shows the dispatching character of the IF_UJ_CUSTOM_LOGIC~EXECUTE method. Depending on the mode, the initialization or the finalization method of the buffer object is called. The buffer object can fill the buffers. Some methods for accessing the buffered data need to be added to the buffer object. The execution method is implemented in the BADI implementation directly as shown in method _EXECUTE.

Code

method if_uj_custom_logic~execute.

data: ls_param_mode type ujk_s_script_logic_hashentry.

data: lr_sgltn_buffer type ref to zcl_bpc_init_exec_finish_sgltn.

data: l_identifier type char10.

data: l_log type string.

data: lr_error type ref to cx_uj_custom_logic.

data: ls_SCX_T100KEY type SCX_T100KEY.

DATA: l_dummy TYPE CHAR100.

** testing: UJKT: Application: APPSHELL AppSet: Planning User: BPCADMIN

** Script:

***** // initialize the buffer

***** *start_badi Z_BPC_INIT_EXEC_FINISH

***** write = OFF

***** query = OFF

***** MODE = INIT

***** *end_badi

*****

***** // "real" call to the badi algorithm

***** // simulating huge amount of data and therefore

***** // restricting the number of members for one dimension

***** *XDIM_MAXMEMBERS P_ACCT = 1


***** write = OFF

***** query = ON

***** MODE = EXEC



© 2010 SAP AG 7

***** *end_badi

*****

***** // delete the buffer


***** write = OFF

***** query = OFF

***** MODE = FINISH

***** *end_badi

read table it_param into ls_param_mode

with table key hashkey = 'MODE'.

if sy-subrc <> 0.

* error: parameter MODE is missing

message e026(ujv_exception) with

'Error: Parameter MODE not found.' into l_log.

cl_ujk_logger=>log( i_object = l_log ).

raise EXCEPTION type cx_uj_custom_logic.

endif.

me->_get_identifier( importing e_identifier = l_identifier ).

zcl_bpc_init_exec_finish_sgltn=>get_instance(

exporting i_identifier = l_identifier

importing e_instance = lr_sgltn_buffer ).

if not lr_sgltn_buffer is bound.

message e026(UJV_EXCEPTION) with

'Error: could not get singleton buffer' into l_log.


raise exception type cx_uj_custom_logic.

endif.

translate ls_param_mode-hashvalue to upper case.

case ls_param_mode-hashvalue.

when 'INIT'.

lr_sgltn_buffer->initialize(

exporting i_appset_id = i_appset_id

i_appl_id = i_appl_id

it_param = it_param

it_cv = it_cv

importing et_message = et_message

changing ct_data = ct_data ).

when 'EXEC'.

me->_execute(



it_param = it_param

it_cv = it_cv

i_sngltn_buffer = lr_sgltn_buffer



when 'FINISH'.

lr_sgltn_buffer->finalize(



it_param = it_param

it_cv = it_cv



© 2010 SAP AG 8



when others.

* wrong paramter value

message e026(ujv_exception) with

'Error: Parameter MODE has unknown value: '

ls_param_mode-hashvalue into l_log.


raise exception type cx_uj_custom_logic.

endcase.

endmethod.

Method _get_identifier

Parameters

Discussion

The important thing here is that this method returns a unique identifier. The identifier is used to identify the correct buffer object for this BADI implementation. Please make sure that you change it to a unique value. The concept in this paper allows to instantiate different buffer object. Each buffer object can be retrieved by the identifier.

Code

method _GET_IDENTIFIER.

e_identifier = 'MY_ID_01'.

endmethod.

Method _execute

Parameters



© 2010 SAP AG 9

Discussion

This method contains the code for the planning function. The buffer object which holds the buffered data is handed over in variable I_SNGLTN_BUFFER and can be used to access the buffered data. The sample algorithm below shows, how the buffered can be read and used. The simple sample algorithm below identifies the entities and if the attribute ELIM has the value Y does some calculation. As we do not want to change the data in this simple example the calculation is a simple multiplication with the value 1. The important point here is showing, how the buffered data can be used in the planning function.

Code

method _EXECUTE.

data: lr_line type ref to data.

data: lr_entity type ref to data.

field-symbols: <lfs_data> type any.

field-symbols: <lfs_result> type any.

field-symbols: <lf_sd> type any.

field-symbols: <lfs_line> type any.

field-symbols: <lf_elim> type any.

field-symbols: <lf_entity> type any.

field-symbols: <lt_entity> type hashed table.

* read the buffered data from the singleton

i_sngltn_buffer->get_entity_data( importing e_data = lr_entity ).

* assign pr_entity->* to <lt_entity>.

assign lr_entity->* to <lt_entity>.

if sy-subrc <> 0. assert 1 = 2. endif.

create data lr_line like line of <lt_entity>.

assign lr_line->* to <lfs_line>.

loop at ct_data assigning <lfs_data>.

assign component 'ENTITY' of structure <lfs_data> to <lf_entity>.


assign component 'SIGNEDDATA' of structure <lfs_data> to <lf_sd>.


<lfs_line> = <lf_entity>.

read table <lt_entity> assigning <lfs_result>

from <lfs_line>.

if sy-subrc <> 0.

* error: entity not found

continue.

endif.

* check if field ELIM = Y

assign component 'ELIM' of structure <lfs_result> to <lf_elim>.


if <lf_elim> <> 'Y'.

* do something ... here we just keep the value, because we do not

* want to modify the APPSHELL data

<lf_sd> = <lf_sd> * 1.



© 2010 SAP AG 10

endif.

endloop.

endmethod.

Implementing Class ZCL_BPC_INIT_EXEC_FINISH_SGLTN

This class implements the buffer object. It contains a static table which keeps track if an object has already been created for the given identifier. An identifier is always referring to one instance of this class. Please note that the identifier must be the same for all BADI implementation to implement a real singleton concept. For our purpose it is sufficient that the object stays the same during the runtime of the algorithm. Using different identifier allows to retrieve different buffer objects; one object for each identifier. In this case class ZCL_BPC_INIT_EXEC_FINISH_SGLTN does not longer represents a singleton, but nevertheless it returns buffer objects, which can be used for our purposes. This way it is possible to define special buffer objects and respect different life-times, if necessary.

Please make sure to set the instantiation to “private” as shown in the screenshot below.



© 2010 SAP AG 11

Public types

For the little example provided here two local types are necessary. The first type defines a structure which contains the name of the identifier and an object reference to the instantiated buffer object. The second type defines of a hashed table type for the first type. Details can be found below.

types:

begin of ty_instances,

identifier type char10,

instance type ref to ZCL_BPC_INIT_EXEC_FINISH_SGLTN,

end of ty_instances .

types:

tt_instances type hashed table of ty_instances with UNIQUE KEY identifier .

Attributes

The class has the static attribute PT_INSTANCES which keeps track of the instantiated buffer objects. The other attribute PR_ENTITY is used as simple example implementation of a buffer. Here it used to buffer the entity attribute. PR_ENTITY demonstrates how buffers can be used for performance tuning. Instead of reading the data each time the BADI is called, it read just once and stored in the singleton. As long as the singleton lives in the memory, the buffer is filled and does not need to read again from the database.



© 2010 SAP AG 12

Methods

This class implements four methods. Method GET_INSTANCE to get an object reference to this class. Instead of calling the constructor directly method GET_INSTANCE needs to be used to get the reference to the buffer object. This is demonstrated in method EXECUTE of class ZCL_BPC_INIT_EXEC_FINISH. Method INITIALIZE is used to implement the necessary things in the initialization phase. In this example a dimension is read from the database and buffered in the static attribute PR_ENTITY. Method GET_ENTITY_DATA returns the buffered data and gives access to the buffer. Finally method FINALIZE is used to clean up things, if necessary. In this example the buffered data is released and the buffer object is cleared for educational purposes. The screenshot below shows the method definitions in detail.

Method get_instance

Parameters

Discussion

The concept of a buffer objects needs a controlled way how objects are created and it needs to make sure that only one instance of an object is instantiated for the same identifier. The following code implements this scheme. During the execution it checks, if an object is instantiated already for the given identifier. If yes, the reference to this object is returned. Otherwise a new object is created and the reference to the new object is stored in table pt_instances for further reference.



© 2010 SAP AG 13

Code

method get_instance.

data: ls_instances type ty_instances.

data: lr_object type ref to zcl_bpc_init_exec_finish_sgltn.

read table pt_instances into ls_instances

with table key identifier = i_identifier.

if sy-subrc = 0.

e_instance = ls_instances-instance.

else.

create object lr_object.

ls_instances-identifier = i_identifier.

ls_instances-instance = lr_object.

insert ls_instances into table pt_instances.

e_instance = ls_instances-instance.

endif.

endmethod.

Method initialize

Parameter

Discussion

This is a sample implementation how the buffer can be initialized. Here some data is read from the database and stored in an attribute. In this example the attributes and master data for dimension ENTITY are buffered.

Code

method initialize.

data: lr_uja_dim type ref to cl_uja_dim.

data: ls_attr type uj_attr_name.

data: lt_attr_list type uja_t_attr_name.

data: lt_hier_list type uja_t_hier_name.

* here you can buffer some data and store it e.g. in attributes

* here we buffer the dimension ENTITY

create object lr_uja_dim

exporting

i_appset_id = i_appset_id



© 2010 SAP AG 14

i_dimension = 'ENTITY'.

* Get only base members and return a hash table for faster read access later

on

call method lr_uja_dim->read_mbr_data

exporting

it_attr_list = lt_attr_list

it_hier_list = lt_hier_list

if_only_base = abap_true

if_ret_hashtab = abap_true

importing

er_data = pr_entity.

endmethod.

Method finalize

Parameters

Discussion

The finalize method cleans up the buffered data. Furthermore is deletes the current instance from the static table pt_instances. That means that the next call to the initialize method instantiates and returns a new object. Of course it is not necessary to clear the entry in table pt_instances. Depending on your requirements it may be better not to delete it and keep the buffered object instead.

Code

method finalize.

field-symbols: <lt_entity> type hashed table.

* delete the buffer if necessary - for educational reasons we do this here

assign pr_entity->* to <lt_entity>.

free <lt_entity>.

* delete the singleton if necessary -

for educational reasons we do this here

delete pt_instances where instance = me.

endmethod.



© 2010 SAP AG 15

Method get_entity_data

The buffered data is needed in method _execute in class ZCL_BPC_INIT_EXEC_FINISH. Therefore a way to access the buffered data needs to be established. This method provides access to the buffered data.

Parameters

Discussion

This method provides access to the buffered data. In this simple implementation it just returns a reference to the buffered table.

Code

method GET_ENTITY_DATA.

e_data = pr_entity.

endmethod.



© 2010 SAP AG 16

Miscellaneous

This paper describes a way to implement efficient buffering technique by introducing buffer objects. Instead of using buffer objects is possible to use function groups and dedicated functions to achieve a similar behavior. In this case global variables of a function group can be used as buffers. Furthermore some functions are necessary to initialize the global variables, return the buffered data and delete the buffered data. Using function groups can be sufficient in some cases.

Please note that the SAP support organization cannot handle questions about the approach presented in this paper. Please ask your questions in SDN.

Testing the concept presented in this paper can be done in transaction UJKT. Please take a look at the screenshot below. It shows which input is necessary.



© 2010 SAP AG 17

Copyright

© Copyright 2010 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 Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., 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.

uj custom logic

Documents

special buffer

faster read

type defines

table ptinstances

message e026

business objects

method execute

type ref