This is a follow up to the article Enhanced variant configuration tool
In this blog some developement specific points are shown which ensure that the characteristic configuration is evaluated properly. This are the first thoughts and if you have some improvement ideas, do not hesitate to mention them.
| characteristic | selection criteria | value expression |
|---|---|---|
| TrayType | Length > 200 or Width > 50 or Heigth > 20 | BIG |
| TrayType | Length < 100 and Width < 20 and Heigth < 10 | SMALL |
| TrayType | DEFAULT | MEDIUM |
| ChocolateType | DEFAULT | FirstWord(MaterialCode) |
| ChocolateType | MaterialCode = "chocolate mix" | materialCode |
| WEIGHT | TrayType = 'BIG' | ROUND(Length * Width * Height*2, 2, 'X') + 20 |
| WEIGHT | TrayType = 'SMALL' | ROUND(Length * Width * Height*2, 2, 'X') + 10 |
1. object dependency with variant function
Each characteristic which should be calculated gets a variant function assigned in the object dependencies. This is linked to one function module. To avoid the need for separate function module for each characteristic some "help characteristics" can be very useful.
FUNCTION Z_EvaluateTrayType
(Length = $ROOT.Length,
Width= $ROOT.Width,
Height = $ROOT.Height,
TARGET_CHARACTERISTIC = 'TrayType'
FUNCTION_RESULT = SELF.TrayType)
TARGET_CHARACTERISTIC and FUNCTION_RESULT are two additional characteristics to get the interface between variant function and function module more generic. Well this is a bit tricky and I am still searching for a better solution - do you have one? - but its working.
Target_Characteristic is defined as input variable and Function_result the only output variable which will get the value of function result.
Now you can for example calculate the TrayType, Volume, Weight, Groundfloor with the same function module by setting the TARGET_CHARACTERISTIC to the desired value as they use all the same input characteristics.
2. replacement of characteristics in formulas
To evaluate the selection criteria and the value expression a more or less complex parser is needed. I found in ABAP only the eval_formula, which does fit quite good for arithmetical expressions but not for text expressions, have you got any hints for me?
Finally I settled with REGEX replacement but I am still thinking about switching to a conventional top down or bottom up parser. What do you think?
3. replacement of sub characteristics
Subcharacteristics, like used when calculating the WEIGHT characteristic are done by using recursive function calls.
4. handling of brackets and boolean expressions
Brackets in numerical expressions are coverd quite good through the SAP standard method EVAL_FORMULA. This method provides also some standard functions as rounding to integers, square functions and so on.
The function EVAL_FORMULA can also process boolean expressions, well text comparisions have first be transfered by pure code to a number value (0 or 1)
Numeric functions like Length > 200 or Width > 50 or Heigth > 20 (Length, Width, Height) are characteristics which are replaced with their numerical value can be entirely passed to EVAL_FORMULA.
5. user defined functions
User defined functions like FirstWord(MaterialCode) or for example a oracle like decode function have to be coded in ABAP. To spot formulas in the expressions I used onces more regular expressions.
A bit tricky is the combination of user defined functions with characteristics. I read somewhere about the definition of user defined functions together with EVAL_FORMULA, anybody has good experience with them and want to share it?
6. SAP standard functions
Functions, like substring, round are already available in ABAP. Nevertheless some mapping from the expressions to the ABAP function call has to be done.
All together a lot of coding is necessary. But it should only be necessary once and the big advantage of the solution is that for later configuration changes no further programming effort is needed and thus leads to a efficient and time-consuming configurable system -> i hope so :-)
Any feedback, especially to the questions is welcome.
Andreas