This is the first part of a series that shows how you can write more powerful Script Logic for the BPC Netweaver version. We are about to embark on a quest through the thicket of BPC Script Logic so lean back and enjoy the ride. If you are completely uninitiated with Script Logic, I recommend reading BPC Script Logic for Dummies by James Lim and the help documentation first.
Background
It is well documented that the BPC Netweaver version features a limited set of Script Logic commands. Some keywords available in the Microsoft version such as FLD are not supported. As a result it has become common to use ABAP not only because of performance bottlenecks but also to work around these limitations. Sometimes ABAP has been applied even when Script Logic might have been a better choice for the task.
When Script Logic is used it is often written in a static fashion including a lot of hard-coded values. This kind of code is simple to create and easy to read. However, it also tends to be high-maintenance when things change (as they always do).
Incomplete and sometimes contradicting documentation seems to be a contributing factor to these trends. This series of articles is my attempt to help developers and business users to see the many possibilities Script Logic offers. There is much more than meets the eye at first blush. Before going to technical details let’s lay out the business case.
Business example
In our business example we want to read salary account values, calculate associated payroll charges and save the calculated values on separate accounts. In our example, the applicable percentage depends on the source AUDITID. Target ACCOUNT varies depending on the source ACCOUNT.
Source values to be read are stored with AUDITID dimension members PAYR01/PAYR02 and ACCOUNT dimension members PL5110,PL5111 / PL6110,PL6111. Calculation results should be saved using AUDITID member CALCRES and ACCOUNT members PL5119/PL6119. The table below summarizes our posting logic.
Source AUDITID | Source ACCOUNT | Percentage | Target AUDITID | Target ACCOUNT |
PAYR01 | PL5110 | 0.25 | CALCRES | PL5119 |
PAYR01 | PL5111 | 0.25 | CALCRES | PL5119 |
PAYR01 | PL6110 | 0.25 | CALCRES | PL6119 |
PAYR01 | PL6111 | 0.25 | CALCRES | PL6119 |
PAYR02 | PL5110 | 0.31 | CALCRES | PL5119 |
PAYR02 | PL5111 | 0.31 | CALCRES | PL5119 |
PAYR02 | PL6110 | 0.31 | CALCRES | PL6119 |
PAYR02 | PL6111 | 0.31 | CALCRES | PL6119 |
Let’s have a look at a simple script suitable for our business case. Later on, we will learn how it can be improved with minimum effort.
Simple Script
Script Logic is still often used in projects because it is easy to learn and it can be maintained by business users instead of IT specialists. Below you can find a simple Script Logic that meets our business case requirements. The keyword FACTOR is used in this example but you can easily enhance the script by using EXPRESSION instead.
*XDIM_MEMBERSET AUDITID = PAYR01, PAYR02
*XDIM_MEMBERSET ACCOUNT = PL5110, PL5111, PL6110, PL6111
*WHEN AUDITID
*IS PAYR01
*WHEN ACCOUNT
*IS PL5110, PL5111
*REC(FACTOR = 0.25, ACCOUNT = PL5119, AUDITID = CALCRES)
*IS PL6110, PL6111
*REC(FACTOR = 0.25, ACCOUNT = PL6119, AUDITID = CALCRES)
*ENDWHEN
*IS PAYR02
*WHEN ACCOUNT
*IS PL5110, PL5111
*REC(FACTOR = 0.31, ACCOUNT = PL5119, AUDITID = CALCRES)
*IS PL6110, PL6111
*REC(FACTOR = 0.31, ACCOUNT = PL6119, AUDITID = CALCRES)
*ENDWHEN
*ENDWHEN
Some remarks
There is nothing inherently wrong writing script this way especially when only a few static operations are needed. However, adding new members and more complicated conditions might require numerous nested WHEN statements. As time passes and the system evolves, a statically written script tends to become longer and longer. Lack of forethought during the design phase can make the system difficult to maintain and even prone to errors.
In the second part of this series, I will show step by step how easy it is to improve this sample script.
