Constraint networks (CU21) handle the most complex configuration scenarios: cross-object validation, multi-class relationships, and consistency enforcement across different BOM levels.
Procedures handle single-object logic. Constraints handle relationships between objects.
Source: SAP Help: Constraints
Constraint Structure
A constraint has four sections:
| Section | Purpose |
|---|---|
| OBJECTS | Declare all classes and objects involved |
| CONDITION | Prerequisite for processing the constraint |
| RESTRICTIONS | Check and set value relationships |
| INFERENCES | Define which values to infer automatically |
Example: Hard Disk Compatibility
A constraint that describes the relationship between a casing model and the compatible hard disk size:
OBJECTS:
CASE IS_A(300) CASE_CLASS,
HD IS_A(300) HD_CLASS
CONDITION:
CASE.MODEL = 'Tower' OR CASE.MODEL = 'Mini'
RESTRICTIONS:
HD.SIZE = '16GB' IF CASE.MODEL = 'Tower',
HD.SIZE = '8GB' IF CASE.MODEL = 'Mini'
INFERENCES:
HD.SIZE
Key Differences from Procedures
| Aspect | Procedure | Constraint |
|---|---|---|
| Object reference | $SELF, $PARENT, $ROOT | Declared objects by class |
| Scope | Single object | Multiple objects/classes |
| Trigger | Every config change | When all declared objects exist |
| Syntax | Value assignments | Declarative restrictions |
| Pricing | ✅ Supported | ❌ Not in LO-VC (AVC supports) |
Dependency Nets
Constraints are grouped into dependency nets via CU21. The net is assigned to the configuration profile.
Why use nets:
- Centralizes all cross-object logic in one place
- Easier to audit than preconditions scattered across values
- Nets can be enabled/disabled as a group
When to Use Constraints Over Preconditions
Preconditions are attached to individual characteristic values. Finding all of them means checking every value of every characteristic. Constraints live in one place: the config profile dependency net.
Use constraints when:
- Two different classes interact (e.g., casing and motherboard from different classes)
- You need to enforce consistency across BOM levels
- The logic involves multiple objects with the same relationship pattern
Use preconditions when:
- Simple single-value hiding
- One-off constraints that don't warrant a constraint object
Advanced Patterns
Pattern 1: Value inheritance via constraints (for non-restrictable chars): Some characteristics have the "Restrictable" flag unchecked, preventing inheritance. A constraint can force the inheritance:
OBJECTS:
PARENT IS_A(300) PARENT_CLASS,
CHILD IS_A(300) CHILD_CLASS
CONDITION:
SUBPART_OF (CHILD, PARENT)
RESTRICTIONS:
CHILD.DESIGN_CODE = PARENT.DESIGN_CODE,
CHILD.CTRL_SYSTEM = PARENT.CTRL_SYSTEM
Pattern 2: Class hierarchy constraints: Use IS-A with hierarchy level numbers to handle class hierarchies:
OBJECTS:
SPB IS_A(300) SPB_CLASS,
POWER IS_A(300) POWER_CLASS
CONDITION:
SUBPART_OF (POWER, SPB)
Performance
Constraints have more overhead than procedures but only execute when needed, when all objects in the OBJECTS section exist in the configuration. For simple single-object logic, use procedures. For cross-object validation, use constraints.
Common Mistakes
- Using constraints for simple default values: overkill. Use procedures with
?= - Too many objects in one constraint: keep the OBJECTS section focused on 2-4 objects
- Missing CONDITION: without a condition, the constraint processes every time (expensive if it involves multiple objects
- Forgetting to assign the net to the profile: creating constraints in CU21 but not assigning the dependency net to CU41
Sources: SAP Help: Constraints | CU21 transaction documentation