Skip to Content

Majority of BPC projects pay big attention to performance issues. This is especially true when companies want to plan on detailed level. Some scripts in such cases can run for hours.

Parallel execution of the script with sub regions could be away to improve performance. There are multiple ways of making run scripts in parallel, but the most obvious way is to split the original data set into multiple data sets manually. This becomes very cumbersome when data sets change from one run to another.

Lets’ assume you have to run some script for multiple Entities and calculation on each Entity is done independently form all the other Entities. It would be natural to split the whole Data Set by Entities and execute that script for each Entity separately. This could bring not only benefits of concurrent execution, but of a smaller data set  for each task as well.

We decided to automate that task by implementing a BADI that splits the data set and starts next run as soon as previous execution is finished. We found that this approach can speed up execution 10 to 20 times with just 4 parallel processes comparing to the original script.

Using that tool is very easy. You just have to call the BADI providing the script name and name of the dimension on which split is made. Sometimes you also have to adjust your original script if it has “hardcoded” members of the dimension that is used for split. If for example, the mentioned above script has a statement

*XDIM_MEMBERSET ENTITY = A1000, A1001, A1002, A1003

it should be replaced with


BADI RUNLOGIC is very similar to BPC MS script RUNLOGIC, but here we’ll discuss mostly differences between those two. The main difference is that MS version doesn’t have parallelization option.

If for instance, name of the original script is CALULATE_SALES.LGF than to run it in parallel for each Entity you have to create a script like:





In the illustration above Entity Dimension was chosen just as an example. Data set split can be done on any Dimension. If you what splitting data set on Time dimension you can change that script to something like







BADI will be attached to the How To … Guide as a transport. So, the only preparation one should make is to import that transport and set up number of parallel processes you want to run. 


I’m finished next version of that BADI which will make it functionality closer to the original MS RUNLOGIC, i.e. it will inherit context from the calling script. This will require less parameters in the call. This is downward compatible.


Another version of RUNLOGIC is available now. It allows grouping by Dimension property and by Hierarchy node. This provides for much better flexibility of grouping data in slices of comparable sizes. If one doesn’t have a Dimension that provides equal splits of data one can create a Property (or a Hierarchy) and populate them to form equal splits.


This is especially useful when you have a Dimension that provides slices too small to be efficient because of the overhead. We tested it on this kind of data and by adding a Property we were able to achieve run time reduction of 3 times.


How To Guide is finally published!!!. You can find it at

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Anjali Sharma
    Its very nice to have this kind of tool to improve the performance of logic. Thanks for posting this blog.
    But in this case do we need to execute the logic for all the entities or can we make a selection of a group of entities/ filter the entities based on a property etc ? Does this BADI comes out of the box?
    1. Gersh Voldman Post author
      No, this BADI can run on any set of Entities (or any other Dimensions). Whatever user selects in the main script, i.e. based on Properties, hierarchies, other dimension, etc.

      Yes, BADI transport will be attached to the How To Guide and users will have to just import it into the system and set number of parallel processes to run. This will be described in the HTG.

  2. Ravi Thothadri
    There ia a HOw to on Badi itself for script logic. Can you pl send the link for the same. I kept requested Scott but neevr got that one.

    Ravi T

    1. Gersh Voldman Post author

      There are multiple HTG on BPC BADI and I’m not sure which one you referring to. HTG “HOW TO PASS PARAMETERS TO CUSTOM LOGIC BADI USING START_BADI” could be usefull. It’s loacted at  You can take a look at where all BPC HTG are located and may be you’ll find something that you are looking for.

  3. Elia Corazza
    please send transports at

    We have about 50 allocations (it’s a cost-accounting model) written with script logic.
    They takes about 1 hour altogether and we would like to reduce the total excecution time in order to built a better simulation environment.
    I’ll feedback to you the results.
    Thank you.

  4. Lider Bw Bps Bcs
    Could you send an example of the ABAP code? marcio.costa at vpar.

    We are facing performance problems with a sequence of Script Logics that run in 30min for a group of 30 Entities, but 10min for a single Entity.

    I will feedback with the results.

    Best Regards,

  5. Gersh Voldman Post author
    Even newer version just passed testing. It allows greater flexibility with parallelizing on hierarchy nodes. Also runs faster when DEBUG = OFF is set.
          1. Manishkumar Jain
            Hi Gersh,

            We have implemented the BADI but nothing seems to work. I have liked the idea of running the script that sits in another application. In our case, we are transferring our data from IOMATCHING to CONSOLIDATION by using DESTINATION_APP keyword. As a part of data transfer that we want to automatically trigger default logic in the target CONSOLIDATION application.

            Another issue we have is – ACCOUNT dimension is different in both application. We use ACCOUNT_IC in ICAMTCHING application and ACCOUNT in CONSOLIDATION application?

            Can this BADI support above scenario? Can you please send me the latest transport file?

            Appreciate your help. Thanks a lot


            1. Gersh Voldman Post author

              Hi Manish,<br/><br/>Yes, RUNLOGIC should support such scenario. You  don’t need a newer version for this – newer version supports additional parallelisation scenarios.<br/><br/>If I understood your problem correctly you should have something like<br/>START_BADI RUNLOGIC<br/>QUERY = OFF<br/>WRITE = ON<br/>APP = CONSOLIDATION<br/>LOGIC = DEFAULT.LGF<br/>ACCOUNT_IC = <NONE><br/>ACCOUNT = scope of that Dim in CONSOLIDATION<br/>END_BADI<br/><br/>If this doesn’t work can you send UJKT log to<br/><br/>Regards,<br/>Gersh

        Hi Gersh,

        I made the change and retested, but I still think there’s an issue with the initial loop I mentioned since it never gets to delete the dimensions not found in the target application from lt_cur_view (line 266 – delete table lt_cur_view …). 

        Since lt_cur_view contains an invalid dimension (in this case) it fails when the method check_member_exist is called to validate against the target application dimensions (line 350 – CALL METHOD CL_UJK_MODEL=>CHECK_MEMBER_EXIST).

        I really appreciate you publishing this code as it helps overcome 2 big BPC NW issues (pushing concept and script performance) – it’s not often one gets something for free these days!



Leave a Reply