This is a followup to my previous blog post about "Old VC Models" Often what I see in VC Models that are difficult to manage is the extensive use of preconditions, particularly when applied to characteristic values. The purpose of preconditions is to hide or display a characteristic value (or characteristic) based on something else is true.
Where did the chaos begin?
In SAP Help there is an example. You can check it in the link. The logic required in the model is that 21 gears are only available when the Bike Model is Racing.
Using the precondition solution requires this logic
MODEL EQ ‘Racing’ assigned to the value 21.
Very simple to do, but imagine more complex relationships, or situations where you share that characteristic in other classes, class types, models etc and then you can create a complex nightmare.
In fact, you may end up with multiple characteristics for GEARS because you cannot separate the logic.
It just gets ugly really fast.
The reason preconditions have been used widely in my view is that the VC Modeller knew no better. SAP does not really prescribe good approaches in VC and so when people refer to SAP Help, the first dependency they find is Preconditions - and thus the chaos timebomb is unleashed. At first, it may look like a good solution, but add 3 - 10 years of changes and it becomes a monster in many cases.
What should we have done instead?
The good practice solution is to use Constraint logic and it can be used with and without variant tables. In some models I have seen, they do not use constraints at all. This tells me the VC Modeller has not been fortunate enough to be taught the power of constraints or considered them too difficult.
The truth is that if you learn constraints early, they are not difficult. There is a certain structure that they require, but once understood you cannot imagine not using them for filtering values.
The advantage of constraints is that you can organise and group logic in the configuration profile. It is centrally visible at the main trunk of the VC Model, and not blowing in the wind on a leaf that exists deep in the model on a characteristic value.
When we use constraints with variant tables it means we separate the data from the code. So when changes are required we change the data in the table. With preconditions you need to look at the leaves on the tree and alter the code. I know what I prefer to do.
How do we transition off preconditions?
The main technical roadblock to moving from preconditions to constraints in LO-VC (The AVC is different) is that the characteristic to be filtered must be restrictable. You will likely find that this field is greyed out and not changeable.
This is because the characteristic is being used in dependencies. To make the tick box accessible you need to lock all the relevant dependencies.
Once done you set the tick and then unlock the dependencies again.
If there are not many to deal with, then the task is manageable. However sometimes there are so many to lock, it is nearly impossible to do manually one by one.
On some projects, I use a custom program to set the tickbox. This means you do not need to lock all the dependencies.
However once set, then you will find that anything to do with this characteristic may no longer work. The second step is to recompile the dependencies. The great thing is that SAP provides a standard program to do this. RCU_COMPILE_DEPENDENCY
The selection screen looks like this.
You run it for procedures etc first and then for constraints. It can take a little time and a report is provided at the end. I often run it for every dependency to make sure I do not miss any.
Summary
I am not saying it is simple to migrate off preconditions. I wanted to provide an overview and some ideas that may be useful. As with anything VC - test, test and retest again. You may have situations where these approaches do not work and so I am providing general information only
In our VC Essentials Training Course, we focus on good practices. We only teach one use case for preconditions and tell you why. The first dependency we write in the course is a constraint and put you on the right path from the start.
Contact me if you have any questions.