SAP BPC Common Mistakes in Logic Script

Logic Script is a powerful proprietary language used in SAP BPC for logic execution. While it is widely used in almost every BPC implementation, especially for the Planning Models, there aren’t many resources teaching you on best practices or how to write it correctly.

The official SAP BPC420 BPC Administration course is covering only marginally how the Logic Script code should be written. Therefore the majority of the consultants are learning by doing without tutor guidance. The so-called “Trial and error” method. Check my page to get a proper SAP BPC Logic Script Course.

Unfortunately, there are cases where because of poorly written Logic Script, consultants are rewriting the code in BADI. This doesn’t mean that I am against BADIs. However, replacing Logic Script with BADIs adds additional burden to the development team and any on-going changes/maintenance after that.

Usually, the best way to optimise particular Logic Script code is by using UJKT Transaction in SAP NW. There, you can see exactly what the code is doing and what are the effects of any change you make.

Based on the mistakes I have done in the past, SAP SCN examples and reading an old code, I will try to summarise the most common mistakes I have found so far. It is a good time to disclose, that I am not referring to logic errors where the results are wrong, but cases where the code is running slower then what it can be.

I. Using members in *IS statements when they are explicitly defined in the scope (*XDIM)

There is no need to limit members in *IS statement when they have already been limited in the preceding *XDIM statement. Leave Asterix (*) so the system does fewer checks and remove unnecessary nested *WHEN / *ENDWHEN if you have such.

Example:

Optimised version:

II. Using %DIM_SET% variables when dimensions are defined by a Data Manager Package

Having a *XDIM with %DIM_SET% is not required, but it will not harm in most cases. The scope will be whatever you sent from the DM Package. However, in case you have %DIM_SET% and this dimension is not in the selection options in the DM Package, then the operation will fail. If the %DIM_SET% is not defined, the package will not fail, but it will get all members.

Example:

DM Package Selection:

• CATEGORY = Budget
• ACCOUNT = PL010

III. Using *COMMIT statement after *WHEN/*ENDWHEN (NW Version)

In BPC NW version, *COMMIT statement is not required after *WHEN/*ENDWHEN statement in cases you want to store the data into the DB. It is resetting the scope to the initial one (DM Package or Input Form Save Data Scope).

Example:

I don’t have benchmarks to compare both cases if we use *COMMIT or not. In cases where you want to continue performing calculations on the same scope, I assume it will be slower to redefine it again.

IV. Using JavaScript engine for calculation instead of ABAP Engine

By Default, the systems are JavaScript engine enabled. I assume this is related to backwards compatibility with the old code. However, if you are creating a new Model, it is highly advisable to enable K2_CALC_ENGNINE (ABAP engine) parameter on a Model level. The ABAP engine was introduced in 2012 and has been improved a lot since then. Most if not all of the functions are working fine as at BPC 10.1 SP10.

V. Using excessive rescoping (*XDIM)  in Default Logic

Usually, we need to limit the calculations running in Default as much as possible. This means we should perform logic calculations only to these intersections of data that are part of the current Save Data Scope. Imagine the data in Default is Waterfall where we need to calculate only these areas the users send.

Potentially, you may find some extraordinary cases where *XDIM rescoping produce better results, but you should use UJKT to test it. Overly, we should refrain from using XDIM rescoping in Default.

Let’s have an example where we enter labour hours based on which labour costs and sales are calculated. For the costs, we will have cost rate, and for the Sales – Mark Up.

Example with *XDIM rescoping:

While the example below works perfectly in DM Package run script, it is not suitable for Default. The reason is that even if we enter Overhead Costs on other accounts, we will always recalculate Costs and Sales.

Optimised Option 1:

First, we will check whether the current scope is LHOUR (Labour Hours) and produce LCOST (Labour Costs). After that, we will use the committed to the database LCOST and multiply it by the markup to produce Sales. In this case, if we enter data on another account, these statements will not run.

Further Optimisation of Option 1 – Option 2:

SAP is recommending limiting the number of *WHEN/*ENDWHEN as much as you can. So, instead of having two separate statements, because we were waiting for the labour costs, we can have a second row in the first statement replicating the LCOST and applying the markup.

VI. Use fewer *WHEN/*ENDWHEN

There are cases where we can define a few block of small scope (*XDIM) with more *WHEN/*ENDWHEN operations or we can have one big block with a wider scope. SAP is recommending the wider scope option with fewer *WHEN/*ENDWHEN.

Example:

Optimised:

The idea behind is that at the end of every *ENDWHEN the result is transferred from the internal memory/table to the database. The fewer inserts/updates to the database, even with a wider scope, the better.

Summary

There are probably many more common mistakes, but these are the one I can mention off the top of my head. Please feel free to comment and recommend any changes to the way I write my Logic Scripts or suggest other common mistakes. It will be beneficial for me and everyone else. Enjoy and have fun with Logic Scripting :).