Using Tools in Variant Configuration

You can use the transaction VC_TABLE_INFO to display and evaluate the storage of the configuration of any type (for example, sales order).

The next figure gives you an overview of the database tables in the area of Variant Configuration.

There's one entry in IBIN for each configuration. The validity period (see version management) is important here, so that the field IN_RECNO is used instead of the object or the instance as the primary key.

IBINVALUES contains the key of this valuation for each valuation of the configuration (primary key IN_RECNO). The key is given by the field SYMBOL_ID. This means that the database table IBINVALUES doesn't explicitly contain the valuations.

For each symbol ID, IBSYMBOL contains information about which characteristic was valuated and in which class type. The entries in IBINVALUES result in the valuation of the configuration.

The following steps result for variant tables and functions in Customizing for Variant Configuration:

• Maintain Status for Variant Tables

• Maintain Group for Variant Tables

• Maintain Status for Variant Functions

• Maintain Group for Variant Functions

In authorization management, there are authorization objects for:

• Maintenance of Variant Tables (Structure, Contents)

• Linking to DB Tables

• Maintenance of variant functions

Only table content maintenance is connected to engineering change management.

These best practices show you how to implement models with good performance.

You can improve the performance of your configuration models considerably if you keep a few things in mind. There are several ways to implement the requirements of your configuration model. In addition to the maintainability of the model, it's essential to keep an eye on the performance since not every formulation of the same issue is easy to calculate for the configuration engine. In the following, we outline a few typical reasons for reduced performance in AVC and their possible bypass.

Usually, a constraint-based approach can be recommended for modeling in AVC, but for some purposes, you need to work with procedures.

Models with constraints promise good maintainability (because no complicated sequence effects must be considered) and good performance. In particular, the use of variant tables in constraints is often beneficial. However, even in AVC, not everything can be expressed using constraints. Among the cases that make procedures necessary, these are the most important:

• NOT SPECIFIED is not possible in constraints:

  In an IF condition, you want to use the syntax NOT SPECIFIED to query whether a given characteristic hasn't yet been assigned a value. This keyword is only possible in procedures, which have precisely defined execution times. Constraints, on the contrary, can be triggered at any time. Therefore, you can never be sure whether the characteristic is assigned a value when the constraint is executed again. That’s the reason why using NOT SPECIFIED in constraints leads to a syntax error.

• Setting dynamic default values isn't possible in constraints:

  The value assignments and restrictions from constraints have an indefinite lifetime during validation. However, a default value from a procedure is dynamic and can be overwritten at any time by a procedure or a constraint.

Procedures allow you to use dynamic default values and to work with overwrites. Concerning performance, attention is required.

The AVC configuration engine is based on a high-performance constraint solver with some proprietary extensions. Constraint solvers are efficient in calculating the value assignments and restrictions that result from a set of constraints. This efficiency is also based on the assumption that a restriction or value assignment by a constraint remains valid indefinitely: The solver always calculates forward but never backward. In other words, the set of possible values becomes smaller, not larger.

With procedures, however, it's possible to overwrite the value assignment of another procedure at any time during validation. In the same way, default values can be overwritten at any time by a procedure or constraint. Hence, not all values remain valid during the validation by the configuration engine. In these cases, a new constraint model must be built internally in AVC that no longer contains the values to be replaced. The constraints of the current instance are validated again, which can considerably increase the effort per instance and overwrite.

This results in the following recommendations:

• Don't use overwriting procedures at all if possible. In practice, this can often be easily achieved. If overwrites can’t be avoided, try not to address the affected characteristics in constraints also.

• Default values should be set last.

  Sometimes, configuration models are based on the following approach: First, each characteristic is supplied with a default value. These default values are overwritten if other values can be derived from the user requirements.

  In AVC, we recommend the following approach instead: First, as many values as possible are derived from the user requirements using constraints and procedures. Only then are the remaining characteristics (the ones that haven't yet been valuated) supplied with defaults.

  In this context, let's also mention again that dynamic defaults in AVC are recalculated with each validation. Unlike in LO-VC, dynamic defaults aren't transferred from one validation to the next. This makes most usages of $DEL_DEFAULT syntax superfluous in AVC.

Procedures that don't result in overwrites or deletion of default values aren't critical for performance in AVC.

Using variant tables appropriately, you can improve your model's performance.

As already mentioned, constraint-based modeling using variant tables is often recommended. For this reason, AVC has a highly efficient implementation to calculate restrictions and valuations using these tables. However, each time a characteristic is bound to the table and the characteristic value changes, the respective table constraint is executed. This results in excellent user guidance for this modeling approach.

On the other hand, this behavior may not always be necessary. Sometimes a table lookup is only relevant when specific characteristics have already been valuated. In this case, it can make sense to add a condition to the constraint:

1234

CONDITION:
SPECIFIED CHARACTERISTIC1 AND
SPECIFIED CHARACTERISTIC2 AND …

This technique can be critical for performance in two cases: Either for large variant tables, which occur more frequently when variant tables are linked to database tables, or if characteristics with many discrete values (say 10,000) are used with large variant tables (say 10,000 lines). This latter issue is related to the number of individual values. An interval from 1 to10,000 as a characteristic domain wouldn't be critical, whereas having values 1, 2, 3, ... would be critical.

Procedures aren't critical in this regard because they only access variant tables via keys.

Usually, characteristics in constraints are addressed by naming their classes. Assume a material that has both mechanical and electrical properties that are however related to each other. The constraint usually starts as follows:

1234

OBJECTS:
M IS_A (300)MECH_CLASS,
E IS_A (300)ELEC_CLASS.

The properties are then related in the RESTRICTIONS part.

Let's further assume that it's a multilevel configuration model, and that the mechanical and electrical properties should also be known at the lower level. Then the corresponding classes are often also assigned to the child instances. However, this can lead to problems. The constraint is only assigned to the root instance via the constraint net. However, the OBJECTS part causes the constraint to bind to all instances in the model where the mentioned classes can be found.

Let’s consider the following simple RESTRICTIONS part:

1234

RESTRICTIONS:
M.MECH_PROP1 = ‘SOME_OTHER_VAL’
IF E.ELEC_PROP2 = ‘SOME_OTHER_VAL’.

This constraint is now not only executed on every instance on which the two classes mentioned can be found. It also connects all corresponding instances. This means that for every pair of instances with class M or E, this pair is connected to each other. Assume seven or eight affected instances: this can lead to several thousand constraint executions. Moreover, these cross-relations can, of course, be completely undesirable semantically.

This problem can be addressed in several ways. First, in the OBJECTS part, you can restrict the constraint to specific materials as follows:

123456

OBJECTS:
MAT IS_OBJECT (material)(300)(NR=‘M4711’).
RESTRICTIONS:
MAT.MECH_PROP1 = ‘SOME_OTHER_VAL’
IF MAT.ELEC_PROP2 = ‘SOME_OTHER_VAL’.

Next, in AVC, it's also possible to address instances in constraints using $SELF, $PARENT, and $ROOT. The scope of the constraint is then controlled by the assignment of the constraint net to an instance. In this case, the OBJECTS part can also be omitted.

If we assign a constraint with the following source code to the ROOT instance, we've restricted the scope of the constraint to this instance:

1234

RESTRICTIONS:
$SELF.MECH_PROP1 = ‘SOME_VAL’
IF $SELF.ELEC_PROP2 = ‘SOME_OTHER_VAL’.

In the same way, this syntax can also be used for multilevel characteristic addressing. A constraint that's assigned to a child instance can be built up as follows:

1234

RESTRICTIONS:
$SELF.MECH_PROP1 = ‘SOME_VAL’
IF $ROOT.ELEC_PROP2 = ‘SOME_OTHER_VAL’

In this case, exactly two instances are connected without the need to use an ambiguous classification. In general, particular attention should be paid to the scope of the constraints when modeling.