how to... implement the runlogic keyword in bpc netweaver

SAP BusinessObjects EPM

How-To Guide

How To… Implement the RUNLOGIC

Keyword in SAP Business Objects

Planning & Consolidation, version for

NetWeaver

Applicable Releases:

SAP Business Objects Planning and Consolidation 7.5, version for

NetWeaver, SP04 and higher.

Version 1.1

March 2011

© 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, Outlook, and PowerPoint are

registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel

Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,

OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP,

Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix,

i5/OS, POWER, POWER5, OpenPower and PowerPC are

trademarks or registered trademarks of IBM Corporation.

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.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP

NetWeaver, 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 in several other countries all over the world.

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.

These materials are provided “as is” without a warranty of

any kind, either express or implied, including but not

limited to, the implied warranties of merchantability,

fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including

without limitation direct, special, indirect, or consequential

damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the

information, text, graphics, links or other items contained

within these materials. SAP has no control over the

information that you may access through the use of hot

links contained in these materials and does not endorse

your use of third party web pages nor provide any warranty

whatsoever relating to third party web pages.

SAP NetWeaver “How-to” Guides are intended to simplify

the product implementation. While specific product

features and procedures typically are explained in a

practical business context, it is not implied that those

features and procedures are the only approach in solving a

specific business problem using SAP NetWeaver. Should

you wish to receive additional information, clarification or

support, please refer to SAP Consulting.

Any software coding and/or code lines / strings (“Code”)

included in this documentation are only examples and are

not intended to be used in a productive system

environment. The Code is only intended better explain and

visualize the syntax and phrasing rules of certain coding.

SAP does not warrant the correctness and completeness of

the Code given herein, and SAP shall not be liable for

errors or damages caused by the usage of the Code, except

if such damages were caused by SAP intentionally or

grossly negligent.

Disclaimer

Some components of this product are based on Java™. Any

code change in these components may cause unpredictable

and severe malfunctions and is therefore expressively

prohibited, as is any decompilation of these components.

Any Java™ Source Code delivered with this product is only

to be used by SAP’s Support Services and may not be

modified or altered in any way.

Document History

Document Version Description

1.00 Initial version of this guide

1.10 Fixed ABAP bug, new transport attached

Typographic Conventions

Type Style Description

Example Text Words or characters quoted

from the screen. These

include field names, screen

titles, pushbuttons labels,

menu names, menu paths,

and menu options.

Cross-references to other

documentation

Example text Emphasized words or

phrases in body text, graphic

titles, and table titles

Example text File and directory names and

their paths, messages,

names of variables and

parameters, source text, and

names of installation,

upgrade and database tools.

Example text User entry texts. These are

words or characters that you

enter in the system exactly as

they appear in the

documentation.

<Example

text>

Variable user entry. Angle

brackets indicate that you

replace these words and

characters with appropriate

entries to make entries in the

system.

EXAMPLE TEXT Keys on the keyboard, for

example, F2 or ENTER.

Icons

Icon Description

Caution

Note or Important

Example

Recommendation or Tip

Table of Contents

1. Business Scenario............................................................................................................... 1

1.1 Calling other Scripts and the Push vs Pull Concept ..................................................... 1

1.2 Improving the Performance of Individual Scripts .......................................................... 2

2. Background Information ..................................................................................................... 4

2.1 More Information on the RUNLOGIC Keyword ............................................................ 4

2.2 BPC NetWeaver RUNLOGIC Keyword Algorithm ........................................................ 5

2.2.1 The BAdI “DIMENSION” Parameter ................................................................ 6

2.2.2 The BAdI “CHANGED” Parameter ................................................................... 6

2.2.3 Nesting RUNLOGIC Statements ..................................................................... 6

2.2.4 Locking Issues ................................................................................................. 7

2.2.5 Special Syntax ................................................................................................. 7

2.2.6 Background vs Dialogue Processes ................................................................ 7

2.3 More Information on the BAdI Framework ................................................................... 8

3. Prerequisites ........................................................................................................................ 9

4. Step-by-Step Procedure .................................................................................................... 10

4.1 Import the attached ABAP transport ........................................................................... 10

4.2 Parallel Degree Setup ................................................................................................ 10

4.3 Parallelize on a Single Dimension (MDX Version) ..................................................... 12

4.3.1 Identify Original Script .................................................................................... 12

4.3.2 Run the Original Script in Data Manager ....................................................... 13

4.3.3 Create a New Script for Testing ..................................................................... 13

4.3.4 Create the Calling Script (RUNLOGIC) ......................................................... 13

4.3.5 Run the Calling Script (RUNLOGIC) .............................................................. 14

4.4 Parallelize on a Single Dimension (*WHEN/*REC Version) ....................................... 15

4.4.1 Identify Original Script .................................................................................... 15

4.4.2 Run the Original Script in Data Manager ....................................................... 16




4.5 Parallelize on a Different Dimension (*WHEN/*REC Version) ................................... 17




5. Appendix ............................................................................................................................ 20

How To… Implement the RUNLOGIC Keyword in SAP Business Objects Planning & Consolidation, version for NetWeaver

March 2011 1

1. Business Scenario

SAP Business Objects Planning & Consolidation can be installed on either a Microsoft or a NetWeaver

platform. While both platforms offer many of the same features and functionalities, there are a few key

differences. One of these differences is the support of Script Logic Keywords that have been

delivered with the installation. Currently, the RUNLOGIC Keyword is not delivered with SAP

BusinessObjects Planning and Consolidation, version for Netweaver (hereafter refered to as: BPC

NetWeaver or BPC).

Fortunately, the BPC NetWeaver Script Logic Business AddIn (BadI) provides an enhancement option

that allows you to define your own Script Logic Keywords. Using the BAdI implementation in this

guide as an example, we will show you how to define your own custom version of the RUNLOGIC

Keyword in BPC NetWeaver (For more detailed background information about the RUNLOGIC

Keyword, and the SAP BAdI Framework, see Section 2).

1.1 Calling other Scripts and the Push vs. Pull Concept

Many businesses already have some type of central script which contains references or includes to

other scripts in the same Application – allowing them to define the exact order of scripts which are

executed in a single run. This is a very useful feature for organizing and controlling which scripts are

to be executed at what time. In fact, the RUNLOGIC Keyword allows you to do this same action on a

more global scale, giving you the powerful capability of calling any script logic file which has been

defined in the BPC NetWeaver system.

The screenshot below represents a very simple illustration of how you can use RUNLOGIC to call a

script defined in another Application (or Application Set):

Let’s say you have modeled three different Applications in BPC NetWeaver; Supply, Demand, and

Finance (a simplified sales and operational planning scenario). In the Supply Application, the data is

modeled by Product, Raw Material and Capacity Asset (for ex: production_line_1). In the Demand

Application, the data is modeled by Product and Customer. Both Applications represent valid but

different business views, each affecting the outcome of projected sales and revenue. For the sake of

this example, we can assume the following:

In the Demand Application, a planner plans Demand Volume (how much the business sells).

In the Supply Application, a planner plans Production Volume (how much the business produces).


March 2011 2

During the Production planning process, the planner analyzes both Production Volume and Inventory

of Product in the Supply Application. Inventory can be defined as a calculation in the Supply

Application which is based on Production Volume and Demand Volume:

Ending Inventory = Beginning Inventory + Production Volume – Demand Volume

In order to obtain an accurate calculation of Inventory, the planner will need to know how much

product the business will sell at any point during his/her planning process. It is during this process that

the Production planner would like to pull in the most recent plan of Demand Volume from the Demand

Application in order to review and determine its impact on inventory. Furthermore, the Production

Planner would like to stay in his/her own context while performing this review without any additional

steps.

For the purposes of this example, let’s say you have already defined a script in the Demand

Application which sends the Demand Volume to the Supply Application. You can then configure the

RUNLOGIC Keyword in the Supply Application to call this script, so that the user can get the latest

Demand Volume without having to change his/her context to the Demand Application and pushing

from there. This is a subtle but useful technique in designing BPC Applications which use data from

different areas in order to obtain up to date and holistic views of the entire data model.

1.2 Improving the Performance of Individual Scripts

In addition to providing you with the capability to call script logic files from other Applications and

Application Sets, this custom RUNLOGIC Keyword also gives you the advantage of using a new

parallelization technique that can greatly improve the performance of the script you are calling.

Quite often, businesses have defined their calculations to be executed across similar sets of data. By

changing a few members of certain driver based dimensions like Entity, Time, and so on, the business

could perform a calculation that covers a very large set of data but with very similar semantic

operations. In cases when the data from one set will not affect the data from another set these

operations can run in parallel processes (for example if you are performing the same calculation

across all time periods of a given year). While this might be achieved by scheduling many Data

Manager Packages to run on different regions of data in parallel, this approach can be tedious and

inflexible.

The screenshot below represents a very simple illustration of how you can use RUNLOGIC to break

up the data sets semantically and execute the script on each one in parallel:


March 2011 3

This guide will show you how to use the BPC NetWeaver version of the RUNLOGIC Keyword to

specify different data sets automatically while running these scripts in parallel. Using the approach

described in this guide can greatly improve the performance of individual scripts. While there are no

doubt many different factors that can contribute to performance, initial testing on a simple example

showed an improvement of more than ten times by using just four parallel processes.

Let’s assume the same Demand Volume planning scenario described above, where the Demand

planner is trying to define how much volume of a product the business is trying to sell. Using the

same Demand Application model described above of Customers to Products, we can assume that the

data will be spread across multiple Entities or Business Units. During the planning process, the

Demand planner has already created his/her baseline of Demand Volume as well as the projected

Price for each Product. Now the business needs to calculate a baseline Sales Amount for each

Customer and Product. This sales amount can be defined as a calculation in the Demand Application

which is based on the Projected Price and Demand Volume:

Projected Sales = Demand Volume * Projected Price

Unfortunately, if the number of combinations of Customers by Products by Entities is very high (in the

millions range) such a calculation can take hours to complete (in our internal testing it took more than

five hours to calculate a year’s worth of data across 4 Entities, 50 Customers, and 800 Products).

The solution to this problem can be implemented with the newly created RUNLOGIC Keyword. By

using a driver dimension to semantically break up the data sets (such as Entity or Business Unit) the

RUNLOGIC Keyword can execute the script logic file with multiple data sets, each using its own

dialogue process. The number of dialogue processes used by the new RUNLOGIC Keyword is

determined by a globally defined BPC Web Admin Parameter. Special care should be taken when

setting this number since using too many processes can be detrimental to overall system performance

(see Section 4.1).

In our testing, we used four parallel processes and the script took slightly over twenty minutes to run

on the same data set that was taking over five hours to run – this is a performance increase of several

orders of magnitude! You should be careful when defining the driver/s for parallel execution because

incorrect usage of this feature can lead to negative system impacts. It is highly recommended that

you study the algorithm that this new RUNLOGIC Keyword uses (See Section 2.2).

Be advised that this guide is only intended to provide you with a solution to create the RUNLOGIC

Keyword and is not intended to fix all of your particular performance problems. Individual results will

always vary, and while this guide will show improvement in many different use cases, it may not be the

answer to your exact scenario.


March 2011 4

2. Background Information

The following sections go into more detail and background on some of the areas of knowledge which

are desirable for using this How To Guide.

2.1 More Information on the RUNLOGIC Keyword

BPC provides the powerful option of using a built in Script Logic Engine to perform calculations on

BPC Application data. The Script Logic Engine is a very powerful piece of functionality within BPC.

The Engine is what reads the script written by a BPC Architect/Administrator and transforms it into

Application Logic that is executed on real BPC Application Data. For more detailed documentation of

the supported syntax and Keywords within the BPC NetWeaver Script Logic Framework, please refer

to the SAP Help Site for BPC Business Calculations (See Section 3 – Additional Documentation).

Businesses choose to configure various scripts which can run either at the time of input or via the BPC

Data Manager Interface, depending on the business process and the functionality that is desired.

These scripts can be fashioned to perform many different combinations of calculations and formulas,

based on the Keywords and syntax that you use in the scripts. It is important to note that this guide is

only intended to cover a single Script Logic Keyword RUNLOGIC.

SAP BusinessObjects Planning & Consolidation can be installed on either a Microsoft or a NetWeaver

platform. While both platforms offer many of the same features and functionalities, there are a few key

differences. One of these differences is the support of Script Logic Keywords that have been

delivered with the installation.

On the BPC Microsoft platform, the RUNLOGIC Keyword gives you the ability to keep your business

users logged into their representative Application and run script logic files defined in other

Applications. They can execute these other scripts without changing their context to the other

Application model/view.

As described above, the primary function of the RUNLOGIC Keyword gives you the ability to redirect

the execution of a script logic file. You can configure the RUNLOGIC Keyword to call another script

logic file which has already been set up within BPC. This is useful, for example, if you need to call a

script logic file located in a different Application, or even Application Set – allowing you to perform your

own string of logic calls or even design a “push” vs. “pull” concept within your application architecture

(See Section 1 for a business example).

In addition to changing where the execution of the script actually happens, the BPC Microsoft version

of the RUNLOGIC Keyword also allows you to manipulate the data region passed to that script logic

file. This means you can potentially execute the script on a different data region for which the logic

was originally configured.

With the help of the Script Logic BAdI included in this guide, we can mimic the functionality of the BPC

Microsoft version of RUNLOGIC and also add our own enhancement for breaking up the script into

smaller data sets which can be run in parallel. For a detailed description of the algorithm used in the

custom BAdI version of the RUNLOGIC Keyword, please refer to the next section (See Section 2.2).

The benefits of using this customized approach within BPC NetWeaver center around two key points:

The new Keyword will allow you to execute logic from various applications without logging

onto each one of them individually (i.e. same functionality as Microsoft version)

o This allows you to group and order your business calculations in a simplified and

centralized fashion using various “push” vs. “pull” designs.

The new Keyword can significantly improve the performance of individual scripts

o The script is run on smaller semantic data sets in parallel. This parallelization can

potentially drop the script runtimes down to fractions of the time taken for the

individual script execution.


March 2011 5

The performance improvement mentioned here can greatly improve the overall perceived value of the

BPC implementation when used within DEFAULT logic (remember that DEFAULT logic is executed for

every writeback operation to a BPC Application).

For example: If a calculation defined in DEFAULT logic takes one minute then every save takes

one minute (even if you are only updating one cell for example). Parallelization of the DEFAULT logic

may take this wait time down to several seconds in an optimal scenario. This means the user

experience has been dramatically improved – instead of waiting one minute for every save, the wait

time has been reduced to several seconds, giving the user a more productive and responsive work

session.

We should also mention that this new version of the RUNLOGIC Keyword in BPC NetWeaver can be

used to speed up batch calculations as well. These batch calculations may take a really long time to

run as data volumes and models change. Normally batch calculations are executed during times

when the system activity is much lower. However, if the business users log in from multiple time

zones the batch time window may be much smaller and harder to meet. Improved script runtimes will

allow the business to schedule batch runs efficiently and in smaller time windows which will help to

increase overall business process efficiency.

2.2 BPC NetWeaver RUNLOGIC Keyword Algorithm

This section describes the algorithm used in the Script Logic BAdI delivered with this guide. It is

intended more as a reference for technical readers and may help you to write your own additions and

enhancements to the code.

1. Determine how many parallel processes can be used (based on a new Application Set Web

Admin Parameter)

For example: Web Admin Parameter was configured for two parallel processes.

2. Determine the data sets used for parallel execution.

a. Based on Step 1 there are two processes available – Therefore the RUNLOGIC

algorithm will only generate two data sets at a time (the data sets are based on the

BAdI “Changed” Parameter).

b. This means that the maximum number of data sets that are running in memory at one

time is two.

c. The next data set will only be generated and executed when one of these two

processes becomes available.

For example: The RUNLOGIC BAdI “Changed” Parameter has TIME and ENTITY. In this

example, the RUNLOGIC algorithm finds the first two combinations of TIME and ENTITY

members and will dispatch a process to execute the script for each of those two data sets.

3. Execute the script for each data set.

a. The RUNLOGIC BAdI will execute the called logic based on the first (or next) data set

(from step 2).

b. This process will repeat until there are no more “idle” processes available (out of a

maximum of two, based on Step 1). When there are no more “idle” processes the

RUNLOGIC algorithm will wait until another process becomes available. When

another process becomes available, the RUNLOGIC algorithm will generate the next

data set and execute the called logic for that data set.

NOTE: This process will repeat until there are no more data sets available (where the total

number of data sets is the Cartesian product of the members from the dimensions defined in

the BAdI “Changed” Parameter). Keep in mind that the Cartesian product is based on the set


March 2011 6

of members defined in the BAdI “Dimension” Parameters. If that dimension has not been

defined in the BAdI “Dimension” Parameters then the Cartesian product is based on the

current context which was passed to the BAdI.

Important Notes and guidelines for the BPC NetWeaver version of the RUNLOGIC Keyword:

2.2.1 The BAdI “DIMENSION” Parameter

The BAdI “DIMENSION” Parameter functionality is similar to the BPC Microsoft RUNLOGIC Keyword

in that it will redefine the scope for the called logic. There is, however one key difference: In BPC

NetWeaver, a BAdI is always called wherever it is defined within the script. In BPC Microsoft, the

RUNLOGIC Keyword is always executed at the end of the script.

IMPORTANT NOTE: A BAdI in BPC NetWeaver will commit the data before returning to the script

unless the WRITE Parameter is set to OFF in which case no data is written at all.

In BPC Microsoft, since the RUNLOGIC is always executed at the end of the script, you cannot run

any additional logic afterwards. This is different in BPC NetWeaver, because you can run any logic

you want after the RUNLOGIC BAdI call. So, in BPC NetWeaver, if there is additional logic written

after RUNLOGIC, that logic will run on the newly created BAdI records. The scope for this additional

logic is not defined by the BAdI, but by the scope in the script itself.

IMPORTANT NOTE: Any script defined after (or before) the RUNLOGIC BAdI call will behave as

normal (ie will run on the scope defined in the script itself and not the scope from the BAdI

“Dimension” Parameter).

In BPC NetWeaver, each RUNLOGIC BAdI call defines the scope independently. So if you string

multiple RUNLOGIC BAdI calls together they only scope their own calls (not affecting the other BAdI

calls) – this is different from BPC Microsoft RUNLOGIC where you can redefine each RUNLOGIC call

with scope from a previous RUNLOGIC call.

In BPC NetWeaver, the BAdI “DIMENSION” Parameter will force the scope in the called logic for that

dimension. However, any additional scoping commands (such as XDIM_MEMBERSET) which have

been configured for that dimension in the called logic will then override the BAdI “DIMENSION”

Parameter.

IMPORTANT NOTE: If you want to force the scope of the called logic by using the BAdI

“DIMENSION” Parameter, you must make sure that you do not redefine the scope on that

dimension in the called script.

2.2.2 The BAdI “CHANGED” Parameter

This optional BAdI parameter is only used when running the called script in parallel mode. It is used

to determine the data sets used for parallel execution. For information on how the data sets are

generated, please refer to the RUNLOGIC Keyword algorithm section (See Section 2.2, #2). If you do

not wish to use any form of parallelization then remove this BAdI Parameter completely.

2.2.3 Nesting RUNLOGIC Statements

In BPC Microsoft the RUNLOGIC Keyword cannot be nested. However, in BPC NetWeaver the

RUNLOGIC BAdI can call other scripts which contain RUNLOGIC BAdI calls. These nested

RUNLOGIC BAdI calls will not support more than one BAdI “Changed” Parameter and any attempt to

do so may result in unintentional consequences.

NOTE: The technical reason behind this is that each nested call will be competing for the total

number of defined parallel processes without knowing when the original processes actually finish

– which could result in performance degradation, locking issues, and incorrect data.


March 2011 7

2.2.4 Locking Issues

When dealing with parallelization in the RUNLOGIC BAdI, you must be very careful how you define

the data sets you are sending to the called logic and the data sets you are writing to within the called

logic.

IMPORTANT NOTE: The general rule of thumb is: don’t put dimensions in the BAdI “CHANGED”

parameter if you are collapsing/aggregating on those dimensions in your called logic.

The following example can help explain when a locking scenario might occur:

Calling Logic:CALLING_LOGIC.LGF

START_BAdI RUNLOGIC

QUERY = OFF

WRITE = ON

LOGIC = CALLED_LOGIC.LGF

APPSET = APSHELL

APP = PLANNING

DIMENSION ENTITY = ENTITY_1, ENTITY_2

CHANGED = ENTITY

DEBUG = OFF

END_BAdI

Called Logic:CALLED_LOGIC.LGF

XDIM_ADDMEMBERSET ENTITY = ENTITY_3

//Aggregating/Summarizing data to ENTITY_3 could result in a locking situation:

ENTITY_3 = ENTITY_1 + ENTITY_2

2.2.5 Special Syntax

In BPC Microsoft the RUNLOGIC Keyword uses a special case for dimensions which are not in the

target script data area:

DIMENSION DimName =

In BPC NetWeaver the equivalent of this syntax is the following:

DIMENSION DimName = <NONE>

This syntax is used when you are calling logic in a separate Application which does not contain

DimName. This is similar to the SKIP parameter in the *Destination_App command.

2.2.6 Background vs. Dialogue Processes

In NetWeaver you can choose to kick off a process in the background or in dialogue.

IMPORTANT NOTE: The new RUNLOGIC Keyword delivered in this guide always kicks off the

parallel executions in dialogue mode – specifically so that the controlling RUNLOGIC program

knows when the dialogue process has finished executing.

This is an important distinction for Basis administrators, since dialogue processes behave slightly

different than background processes. Most importantly for the readers of this guide, is that dialogue

processes have a timeout setting and background processes do not. For this reason, the

parallelization technique described in this guide should be tested properly on the system so that each

data set will be able to finish its job within the time that has been allocated for a dialogue process in

your system.


March 2011 8

2.3 More Information on the BAdI Framework

SAP Business Add-Ins (BAdIs) are arguably one of the most important technologies used to adapt

SAP software to specific requirements. As of Release 7.0 of the SAP NetWeaver Application Server

ABAP, BAdIs are part of the Enhancement Framework, where they represent explicit enhancement

options. BAdIs are the basis for Object Plug-Ins that can enhance the functions in ABAP programs

without having to make core software modifications. As such, BAdI calls can be integrated into

customer applications (like BusinessObjects Planning and Consolidation, version for SAP NetWeaver

for example) to allow enhanced customization of standard application functionality.

This guide describes the procedure for implementing a BadI for the BPC NW version of the script logic

Keyword RUNLOGIC. The Step-By-Step section will outline the tasks needed in order to create the

BAdI itself in addition to the configuration required within BPC NW to actually execute the BAdI. The

Appendix section contains the ABAP transport that goes along with this guide’s Business Scenario.

This code is only meant as an example and while it will perform the actions described in this guide it

may not match the exact needs of your own particular Business Scenario – it is only intended to guide

you in the creation of your own BAdI Implementation.

For more detailed documentation of the BAdI Framework, please refer to the SAP Help Site for BAdIs

(see Section 3 – Additional Documentation).


March 2011 9

3. Prerequisites

Required/recommended expertise or prior knowledge

SAP BusinessObjects Planning and Consolidation 7.5, version for SAP NetWeaver

BPC NetWeaver Script Logic

BPC NetWeaver Script Logic BAdI Framework

ABAP programming skills

Access to SAP NetWeaver transaction codes: SE20, SE19, SE37, SE80, SE24, STMS

Relevant SAP Notes:

NA

Additional Documentation:

RKT Online Knowledge Product

http://service.sap.com/rkt On the left hand side, navigate to SAP Ramp-Up Knowledge

Transfer -> SAP BusinessObjects EPM Solutions -> SAP BO PC 7.5, version for SAP

NetWeaver

Other EPM How-To Guides

http://wiki.sdn.sap.com/wiki/display/BPX/Enterprise+Performance+Management+%28EP

M%29+How-to+Guides

SAP Help Library – Business Add Ins (BAdI)

http://help.sap.com/saphelp_nw70/helpdata/en/8f/f2e540f8648431e10000000a1550b0/fr

ameset.htm

SAP Help Library – BPC NetWeaver Business Calculations (Script Logic and Business Rules)

http://help.sap.com/saphelp_bpc75_nw/helpdata/en/94/e0f3a56f174607855bc345a45df8

47/frameset.htm

http://service.sap.com/rkt

http://wiki.sdn.sap.com/wiki/display/BPX/Enterprise+Performance+Management+%28EPM%29+How-to+Guides

http://wiki.sdn.sap.com/wiki/display/BPX/Enterprise+Performance+Management+%28EPM%29+How-to+Guides

http://help.sap.com/saphelp_nw70/helpdata/en/8f/f2e540f8648431e10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/en/8f/f2e540f8648431e10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_bpc75_nw/helpdata/en/94/e0f3a56f174607855bc345a45df847/frameset.htm

http://help.sap.com/saphelp_bpc75_nw/helpdata/en/94/e0f3a56f174607855bc345a45df847/frameset.htm


March 2011 10

4. Step-by-Step Procedure

This How-To guide outlines the procedure for implementing the RUNLOGIC Keyword in BPC 7.5,

NetWeaver. The following steps we describe here show the performance benefits you can acheive by

using the RUNLOGIC Keyword parallelization technique:

1) Import the ABAP transport from Appendix A into a BPC 7.5, Version for NetWeaver System

2) Set the number of Parallel Processes to be used

3) Parallelize on a single Dimension and validate results

4) Parallelize on a different Dimension and validate results

These steps demonstrate the testing of a simple Sales calculation as described in Section 1.2. The

calculation shown in this example simply multiplies Volume by Price and stores the result in Sales. By

modifying the script syntax and trying different parallelization drivers a much better performance can

be gained at run time. As always, performance results will depend on many different factors. The

data given in this guide is just a single example and results for your particular scenario may be

different.

4.1 Import the attached ABAP transport

Make sure you import the transport from Appendix A into a BPC 7.5, Version for NetWeaver system.

Follow the standard procedure for importing an ABAP transport.

NOTE: The ABAP code delivered with this transport belongs to a Package named "ZBPC".

4.2 Parallel Degree Setup ...

1. Start the BPC NetWeaver Admin Client

2. In “Available Interfaces” select “BPC Web”

3. Next, select “Administration”


March 2011 11

4. Next, select “Set AppSet parameters”

5. Adjust the “PARALLELSCRIPT” parameter

NOTE: If this is the first time you are setting this parameter up, scroll down to the bottom of the

list and add a new Parameter named “PARALLELSCRIPT”

6. Set the number of desired Parallel Processes in the box labeled “Value” and click the button

labeled “Update”

NOTE: This number will depend on many different factors related to the system hardware, such

as the available number of CPUs and RAM, in addition to how many other processes will be

running at the same time and how many active users in the system at the time of script

execution.


March 2011 12

7. This configuration will only need to be done once. You can change it later as needed.

4.3 Parallelize on a Single Dimension (MDX Version)

The script used in this example attempts to reflect the business scenario described in Section 1.2. It

multiplies a Volume account by a Price account and stores the result in a Sales account using MDX

based syntax in the BPC NetWeaver Script Logic editor.

4.3.1 Identify Original Script

We assume the business has already defined this calculation, let’s take a look at the example script

named CALC_SALES.LGF (See APPENDIX B for the Script used in this Step)

NOTE: This script assumes that Volumes are populated for some Customer-Product combination

and that the Price is populated for all Products where Customer = NO_CUSTOMER. It will multiply

Volume by Price per Product and places the result on an account named SALES.


March 2011 13

4.3.2 Run the Original Script in Data Manager

On an internal Application Set, this script ran on a combination of 50 Customers and 800 products.

The Application contained ~1.8 million records on a Volume Account and ~38 thousand records on a

Price Account. The data was spread across twelve Periods in a single Year for four separate Entities.

The script generated ~1.8 million records on a Sales Account in approximately 5 hours:

4.3.3 Create a New Script for Testing

Now let’s copy CALC_SALES.LGF to a new script that will be called by RUNLOGIC and split across data sets provided by the RUNLOGIC “CHANGED” Parameter. Let’s assume that we want to run it for each Entity, with all the other dimensions remaining the same as they were in the original script.

Name the new script CAL_SALES_1ENT.LGF (See APPENDIX C for the Script used in this Step):

NOTE: The only thing we changed in this new script is the XDIM specification for ENTITY, using the special key %ENTITY_SET%, i.e. entities provided through the current view. In our case the RUNLOGIC keyword provides these values to the calling script.

4.3.4 Create the Calling Script (RUNLOGIC)

Now we create the calling script PAR_SALES_ENT.LGF (See APPENDIX D for the Script used in this

Step). This script calls RUNLOGIC and specifies the script to be called in addition to the data set

(DIMENSION Parameter) and on what dimension to split the data set (CHANGED Parameter).


March 2011 14

4.3.5 Run the Calling Script (RUNLOGIC)

Execute the calling script (PAR_SALES_ENT.LGF) from a Data Manager Package. You can monitor

the backend server activity by using transaction “SM50”, where you can see 1 background process

(running BAdI) and 4 dialog processes (running one Entity each).

NOTE: In order to make the run times comparable, you must delete all postings from the target

Sales Account first.

Now the log shows that all four Entities ran in ~21 minutes, which is almost 15 times faster than the

single threaded process in Step 4.3.2!!!

You can also see how each Entity was processed in the Formula log:


March 2011 15

4.4 Parallelize on a Single Dimension (*WHEN/*REC

Version)

Let’s rewrite the same Script from Section 4.3 using the *WHEN/*REC/*ENDWHEN syntax since we

already know that the MDX syntax slows things down a bit. The new syntax will still perform the same

calculation of multiplying a Volume account by a Price account and storing the result in a Sales

account.

4.4.1 Identify Original Script

Copy the script we used in Section 4.3.1 and rename it to CALC_SALES_WHEN.LGF (See

APPENDIX E for the Script used in this Step).

NOTE: The only difference from the original script is that we replace the single MDX line with a

*WHEN\*REC\*ENDWHEN syntax.


March 2011 16

4.4.2 Run the Original Script in Data Manager

As expected this script ran a little bit faster than the MDX version but still in the ~4 hour time range.


Now let’s create a new script for testing in the same way we changed the script in Section 4.3.3. Name the new script CAL_SLS_1EN_WHEN.LGF (See APPENDIX F for the Script used in this Step):

NOTE: The only thing we changed in this new script is the XDIM specification for ENTITY, using the special key %ENTITY_SET%, i.e. entities provided through the current view. In our case the RUNLOGIC keyword provides these values to the calling script.


Now we create the calling script PAR_SALES_ENT_WH.LGF (See APPENDIX G for the Script used

in this Step). This script calls RUNLOGIC and specifies the script to be called in addition to the data

set (DIMENSION Parameter) and on what dimension to split the data set (CHANGED Parameter).


March 2011 17


Execute the calling script (PAR_SALES_ENT.LGF) from a Data Manager Package. You can monitor





The log shows that all four Entities ran in ~23 minutes, which is still 10 times faster than the single

threaded process in Step 4.4.2!!!

4.5 Parallelize on a Different Dimension (*WHEN/*REC

Version)

In the previous sections we used the ENTITY Dimension to split the data sets. One can experiment

with different Dimensions and even multiple Dimensions for splitting Data. When running such trials it

makes sense to set the WRITE Parameter to OFF, in which case all the calculations are executed but

the data is not written back to the Application. In this way we can see which data split works more

efficiently and use that configuration for the final RUNLOGIC script.


March 2011 18

In general, parallelization is the most efficient when each piece of data takes approximately the same

time for processing.

IMPORTANT NOTE: The general rule of thumb is: don’t put dimensions in the BAdI “CHANGED”

parameter if you are collapsing/aggregating on those dimensions in your called logic. For more

information, see Section 2.2.4 on Locking Issues.


As described above, if the called script aggregates on one of the dimensions used in the BAdI

“CHANGED” Parameter you can’t use it. For example, if the called script writes all of it’s data to the

first period of the year, then TIME can’t be used in the splitting of data.

Fortunately, this is not the case in our example – so let’s see how the called script changes if we want

to split the data across the TIME Dimension instead of the ENTITY Dimension.

Copy the script from section 4.4.3 to a new script called CAL_SLS_1TIM.LGF (See APPENDIX H for

the Script used in this Step).

NOTE: The only thing we changed in this new script is the XDIM specification for TIME, using the special key %TIME_SET%, i.e. periods provided through the current view. In our case the RUNLOGIC keyword provides these values to the calling script.


Now we create the calling script PAR_SALES_PER.LGF (See APPENDIX I for the Script used in this

Step). This script calls RUNLOGIC and specifies the script to be called in addition to the data set

(DIMENSION Parameter) and on what dimension to split the data set (CHANGED Parameter).


March 2011 19

NOTE: The only thing we changed in this new calling script is the CHANGED Parameter.


Execute the calling script (PAR_SALES_PER.LGF) from a Data Manager Package. You can monitor





The log shows that all four Entities ran in ~13 minutes, which is almost 18 times faster than the single

threaded process in Step 4.4.2!!!


March 2011 20

5. Appendix

Appendix A – ABAP Transport for BPC NetWeaver RUNLOGIC Keyword

This ABAP transport contains the Classes / Function Modules / Enhancement Objects needed for the BPC NetWeaver RUNLOGIC Keyword. NOTE: delivered within an ABAP package named ZBPC

Appendix B – CALC_SALES.LGF

CALC_SALES.LGF from Section 4.3.1

Appendix C – CAL_SALES_1ENT.LGF

CAL_SALES_1ENT.LGF from Section 4.3.3

Appendix D – PAR_SALES_ENT.LGF

PAR_SALES_ENT.LGF from Section 4.3.4

Appendix E – CALC_SALES_WHEN.LGF

CALC_SALES_WHEN.LGF from Section 4.4.1

Appendix F – CAL_SLS_ 1EN_WHEN.LGF

CAL_SLS_1EN_WHEN.LGF from Section 4.4.3


March 2011 21

Appendix G – PAR_SALES_ENT_WH.LGF

PAR_SALES_ENT_WH.LGF from Section 4.4.4

Appendix H – CAL_SLS_1TIM.LGF

CAL_SLS _1TIM.LGF from Section 4.5.1

Appendix I – PAR_SALES_PER.LGF

PAR_SALES_PER.LGF from Section 4.5.2

www.sdn.sap.com/irj/sdn/howtoguides

how to... implement the runlogic keyword in bpc netweaver

Documents