Explaining the Paradigms of the SAP Configurator and Introduction to the Syntax

• Declarative dependency type

  Constraints

• Semideclarative dependency types

  Behave like declarative dependency types, but processed procedurally and internally.

  • Preconditions
  • Selection conditions

• Procedual Dependency types

  Procedures

• All dependency types are object- oriented

  Inheritance of dependencies within class hierarchies – Object specific processing of dependencies.

In declarative dependencies, the point in time when the dependency is processed and the sequence in which the dependencies are processed are not relevant to the result. The result of a declarative dependency can be explained logically.

The dependency describes a rule that must always apply. This contrasts with procedural dependencies, where the result depends on the processing sequence and the point in time when the dependency is processed. Some expressions are in themselves non-declarative. For this reason, these expressions cannot be used in declarative object dependencies:

1
NOT SPECIFIED; NOT TYPE_OF; <multiple-value characteristic> NE <value>

You can use these expressions in preconditions and selection conditions. Since preconditions and selection conditions are not processed until the end of the configuration process, you can assume that values have been assigned to all the characteristics that are intended to have values, and that any missing information is deliberately not given.

When the not equals (NE) expression is processed for multiple-value characteristics, theres a difference between constraints and actions. In constraints, not equals can be expressed for multiple-value characteristics, because individual values are processed in constraints. In actions, however, the sum of the selected values is processed. Since it's not clear whether it's deliberate that no value was selected for a multiple-value characteristic or whether a value will be assigned at a later point in time, this expression cannot be processed in actions.

Dependencies, classes, and objects support a declarative and object-oriented solution for a knowledge base. The system determines the processing sequence of the object dependencies and ensures that they are only executed when required.

• Each of the four dependency types has its own syntax rules.

• Preconditions, selection conditions, and procedures are simple dependencies.

• Preconditions and selection conditions are Boolean expressions (with a binary result).

• Constraints are more complex object dependencies with their own syntax. They're structured like a program. They have a much broader functional scope. They're especially useful for defining and evaluating complex, multilevel configurations, but can also be used with single level configurations.

• The syntax of dependencies is not the same as ABAP syntax. (However, ABAP function modules can be called in dependencies as variant functions or BAdIs.)

• Two strings may be separated by any number of blanks.
• Keywords and strings are not case sensitive, except for characteristic values that were originally defined as case sensitive in characteristics maintenance.
• Strings containing hyphens must be enclosed in single quotes and preceded with the keyword SKEY.
• All strings must be entered in their global language independent form.
• An asterisk (*) at the beginning of a line identifies the line as a comment.
• Elements in lists are separated by commas.
• Characteristic values in CHAR format must be enclosed in single quotes.

The following figure explains the syntax: $self, $parent, and $root and their meaning in examples of Object Dependencies

• Constraints are a more flexible method of identifying objects and characteristics.
• All objects and characteristics of the variant classes can be directly and concurrently addressed during the execution of a constraint.
• Objects and characteristics can be addressed by their system-wide, language independent names, or by shorter names that are defined as variables within the constraint to keep the syntax simple.
• New under AVC: The object variables $self, $parent, and $root can also be used in constraints.

Check out possible Operators:

You can use most of arithmetical expressions in object dependencies.

The following figure explains the use of "in" in object dependencies.

The following figure explains the meaning of Specified.

• You use TYPE_OF to define that the condition only applies to one object.

• You can use this condition if the dependency is dependent on its environment, for example. Dependent on being used for a specific BOM header material.

  TYPE_OF($ROOT, (Material)(300)(NR=‘U91’))

• If you use a condition like this, for example, a selection condition for a BOM item, the item is included in the BOM explosion if the $ROOT object (header material) has material number ‘U91‘.

TYPE_OF and NOT TYPE_OF cannot be used in constraints.

The following figure shows you three Character String Operators for object dependencies.

Now let's have a look at two additional figures, which show Syntax elements only available with AVC.

In addition to the statuses that exist for characteristics, classes, and classification, there's also a status for the object dependency.

Local and global object dependencies have a status.

Object dependencies can have the status Released, only if the syntax has no errors. An empty syntax is an error.

For global object dependencies, a manual-only conversion of a status is available.

For local object dependencies, an automatic release is available as well.