The story so far...
Welcome to this snapshot on how constraints in LO-VC and the AVC are similar, but also very different.
If you are planning to migrate to the AVC from LOVC, you can in many cases transform your existing constraints to the AVC without any syntax changes. Read this blog post to get an overview of the transformation process.
As long as you are using standard VC in the constraints then the same syntax will be compatible in the AVC. So the transformation tools will copy the syntax into the AVC process version. Sometimes you may need to adjust the variant table if it is used in the constraint.
The transformation in the AVC will look the same.
Syntax LO-VC Processing Mode: Classic | Syntax AVC Processing Mode: AVC |
|---|---|
 |  |
However the processing of the syntax is different.
A word about resources...
Before we move on the the 4 main differences, take a moment to consider the best sources of information for Variant Configuration.
The configuration-workgroup.com is an incredible group to join for free. It has forums, conferences, SAP sandbox systems and information resources.
The VC Books from SAP Press with the latest edition focused on the AVC.
Configurable Opinions on YouTube is a channel I cohost with Steve Schneider. We talk about all sorts of topics about and around SAP Variant Configuration.
Our VC Essentials Training that is online and self-paced. The point of difference is that it teaches you how to apply a Constraint-Based approach to building your models. Although it was developed in LO-VC, the same design principles apply to the AVC. Try the preview for FREE.
Check out our other blog posts, and the Radiant Think YouTube channel.
What are the main differences...
So if we use the transformation tools that SAP provides we have seen that the constraint looks the same, however it is processed differently.
Restrictable Characteristics
In LO-VC we had to set the Restrictable flag in the characteristic so we could restrict values using constraints. This was often a pain point when it was not set and had been used, making it difficult to reset to Restrictable.
In the AVC, regardless of the setting on the characteristic, the characteristics are treated as Restrictable. This is a positive change considering SAP promote the AVC as a constraint-based engine.
Inferences
Although the INFERENCES section is copied it is ignored by the AVC engine. What does this mean? Well for the AVC it infers all characteristics. In LO-VC we had control to infer the paint colour (RT_PAINT_COLOUR) based on the frame material (RT_FRAME_MAT), so in one direction.
In the AVC it will infer in all directions. So even if we have the inferences section in the AVC constraint, it is completely ignored.
In LO-VC to have the same behavior as the AVC we would set up the INFERENCE as follows.
INFERENCES:
X.RT_PAINT_COLOUR, X.RT_FRAME_MAT
You may consider doing this if you want to be closer to the behaviour in the AVC.
Syntax LO-VCProcessing Mode: Classic | Syntax AVCProcessing Mode: AVC |
|---|---|
|  |
Mandatory and Optional Sections
Although all the sections of the constraint
- OBJECTS
- CONDITION
- RESTRICTIONS
- INFERENCES
can be present in both LO-VC and the AVC there is a difference in those that are mandatory or optional.
Section | LO-VC | AVC |
|---|---|---|
OBJECTS: | Mandatory | Optional |
CONDITION: | Optional | Optional |
RESTRICTIONS: | Mandatory | Mandatory |
INFERENCES: | Optional* | Not Applicable |
Optional* - In most cases in LO-VC we have an INFERENCES section but if we use a FALSE statement in the RESTRICTIONS section the INFERENCE is not needed.
The interesting one is where you may not need an OBJECTS: section in the AVC. For clarity I think you should always have an OBJECTS section and in the next difference we will show how this can be used.
$self, $parent and $root
As you probably know in LO-VC, procedures, preconditions and selection conditions use $self, $parent and $root to target the characteristics that we want. In constraints we used IS_A for classes and IS_OBJECT for materials.
In the AVC there is now the ability to use $self, $parent and $root in Constraints. This will offer good AVC practices that could make a transition from poor practices in LO-VC easier as the logic is not reliant on a class or material, and only on the characteristics.
Based on our example the constraint in the AVC can be written in these ways
AVC | Syntax Examples |
Option 1 No OBJECTS section |  |
Option 2 With OBJECTS section |  |
What this all means...
The way you may approach your VC models in the AVC may change. This will depend on a few scenarios
Where is the AVC? - on premise, private cloud, public cloud
Are you transforming from LOVC? - all models, some models
Are you wanting to implement good practice approaches?
Do you understand the models you have?
This is not a full list by any means, but raises so points that you need to consider.
I have seen many poorly designed VC models in LO-VC and it would be a backward step in my view to take them into the AVC as they are. These would be models that use preconditions and long procedures as the main red flag. Transitioning to good practices within LO-VC has its challenges, mainly due to the Restrictable flag not being set on characteristics and moving from preconditions to constraints. If you are not planning to go to the AVC there are still pathways to good practices.
However if there is a plan to migrate to the AVC there is an ideal situation to leave poor practices in the past and take in good practices into the future. The Transformation Tools can help with this process.
You need to be aware that each company is different and a transition path for one, can be different for another. We have worked with companies to understand their products and product families for the VC perspective, to make the best use of the class design, constraint design, BOM and routing design to take advantage of what LO-VC has to offer as well as for the AVC.
Conclusion
Make sure that your VC team is educated of good practice approaches. Once they understand these and apply the principles correctly the usually see the huge advantage that good practice approaches offer. So go back and check out the links provided as your starting point.
If you have any questions then raise a comment or email me phil@radiantthink.com
Comentários