Hotspot Inheritance Algorithm
As mentioned in the previous chapter, the Hotspot number inheritance at Runtime is performed under certain conditions only. This chapter presents different scenarios allowing to better understand how the inheritance algorithm works in Smart CPQ.
As a reminder, there is no Hotspot number inheritance done at Design.
Initial Product Structure
SPARE PARTS INITIAL STRUCTURE
In this chapter, we consider a Standard Item SI_A with the following Parts structure:
CONVENTIONS
In the following chapters:
- If no Hotspot number (HS) is set on a given element, it means that none is affected.
- Hotspots in red color are the ones manually changed, thus triggering the inheritance behavior for each use case.
- Hotspots in green color are the one affected by the initial manual change.
- Hotspots in black color are not affected by the manual change
The blue arrows represent ‘sparePart’ links. The red arrows represent ‘replacement’ links
Use cases on the initial structure
SCENARIO 1: SIMPLE INHERITANCE OF UNIQUE HOTSPOT
Description
In that use case, we affect the Hotspot 10 to the SI_A1 on the first level at Design.
Result
In that scenario, we observe that SI_A1 on the second level and SI_A1 on the third level automatically inherit from the Hotspot 10 at Runtime:
SCENARIO 2: OVERRIDE INHERITED HOTSPOT
Description
In that use case, we consider having run the Scenario 1. SI_A1 is associated with Hotspot 10 on all 3
levels.
From there, we manually assign at Design the Hotspot 20 to SI_A1 on the third level.
Result
The assignation has no impact on the Hotspot associated to SI_A1 on level 1 and 2 (Hotspot 10)
SCENARIO 3: OVERRIDE UNIQUE HOTSPOT
Description
In that use case, we consider having run the Scenario 1. SI_A1 is associated with Hotspot 10 on all 3 levels.
From there, we manually assign at Design the Hotspot 20 to SI_A1 on the first level.
Result
The Hotspot 20, manually changed for SI_A1 at the first level, is inherited at Runtime at the second and third levels for SI_A1, thus replacing the previous inherited value.
SCENARIO 4: DELETE UNIQUE HOTSPOT
Description
In that use case, we consider having run the Scenario 1. SI_A1 is associated with Hotspot 10 on all 3 levels.
From there, we manually delete at Design the Hotspot 10 associated with SI_A1 on the first level.
Result
The deletion of the Hotspot previously assigned on the first level for SI_A1 is inherited at Runtime, in the sense that no Hotspot is associated anymore with SI_A1 on levels 2 and 3.
SCENARIO 5: DELETE ONE HOTSPOT AMONG MULTIPLE IN A SUB-LEVEL
Description
In that use case, we consider having run the Scenario 1 and 2:
- SI_A1 is associated with Hotspot 10 on level 1.
- SI_A1 is associated with Hotspot 10 on level 2 (inherited from level 1)
- SI_A1 is associated with Hotspot 20 on level 3 (manually changed after the inheritance)
From there, we manually delete at Design the Hotspot 20 associated with SI_A1 on the third level.
Result
The deletion of the Hotspot associated with SI_A1 on the level 3 makes this SI eligible to inheritance. SI_A1 on level 3 thus inherits from Hotspot 10 manually associated with SI_A1 on the first level.
SCENARIO 6: DELETE ONE HOTSPOT AMONG MULTIPLE AT TOP LEVEL
Description
In that use case, we consider having run the Scenario 1 and 2:
- SI_A1 is associated with Hotspot 10 on level 1.
- SI_A1 is associated with Hotspot 10 on level 2 (inherited from level 1)
- SI_A1 is associated with Hotspot 20 on level 3 (manually changed after the inheritance)
From there, we manually delete at Design the Hotspot 10 associated with SI_A1 on the first level.
Result
The deletion of the Hotspot associated with SI_A1 on the level 1 makes this SI eligible to inheritance. SI_A1 on level 1 thus inherits from Hotspot 20 manually associated with SI_A1 on the third level.
SI_A1 on level 2 does not inherit from the first level anymore and is thus eligible to inheritance. SI_A1 on level 2 thus inherits from Hotspot 20 manually associated with SI_A1 on the third level.
Multi directional Inheritance
In the following chapters, we enrich the structure of SI_A described in chapter 3.1 by adding sub-elements and by introducing a deeper level. The goal of this new structure is to describe the Hotspot number inheritance by highlighting the horizontal and vertical assignation of Hotspot numbers.
SCENARIO 7: SIMPLE INHERITANCE FROM A DEEPER LEVEL
Description
In that use case, we affect the Hotspot 10 to the SI_A1 on the second level at Design.
Result
In that scenario, we observe that SI_A1, at all horizontal and vertical levels, inherits from the Hotspot number 10.
SCENARIO 8: HORIZONTAL VS. VERTICAL INHERITANCE
Description
In that use case, we affect the Hotspot 10 to the SI_A1 on the fourth level at Design.
Result
In that scenario, we observe that SI_A1, at all horizontal and vertical levels, inherits from the Hotspot number 10.
Introducing replacement links
In the following chapters, we enrich the structure of SI_A described in chapter 3.1 by adding sub-elements and by introducing replacement links in addition to spare parts links.
SCENARIO 9: INHERITANCE THROUGH A REPLACEMENT LINK
Description
In that use case, SI_B5 here is replaced by SI_A1:
For that scenario, we affect the Hotspot 10 to the SI_B5 at Design.
Result
In that scenario, we observe that SI_A1 replacing SI_B5 inherits from the Hotspot 10 of SI_B5. No other SI_A1 at other levels inherits from that Hotspot number at Runtime.
One item (SI_A1) replacing another one (SI_B5) can only inherit from the Hotspot of the replaced item, if any.
SCENARIO 10: SIMPLE INHERITANCE OF UNIQUE HOTSPOT WITH REPLACEMENT BY A SINGLE ELEMENT
Description
In that use case, SI_B5 here is replaced by SI_A1:
For that scenario, we proceed as in the Scenario 1 but on this new structure: we affect the Hotspot
10 to the SI_A1 on the first level at Design.
Result
In that scenario, we observe that SI_A1, on level 2 and 3 with ‘spare parts’ links, automatically inherit from the Hotspot 10 at Runtime. The SI_A1 replacing SI_B5 however does not inherit any Hotspot.
This confirm that one item (SI_A1) replacing another one (SI_B5) can only inherit from the Hotspot of the replaced item, if any. However, it cannot inherit from Hotspot numbers at other levels of the spare parts structure (in the sense of items associated with ‘spareParts’ links).
SCENARIO 11: SIMPLE INHERITANCE OF UNIQUE HOTSPOT WITH REPLACEMENT BY A SUBTREE
Description
In that use case, SI_B5 here is replaced by SI_A1 and SI_B6 is replaced by SI_A2 and a subtree with SI_A1:
For that scenario, we proceed as in the Scenario 1 but on this new structure: we affect the Hotspot 10 to the SI_A1 on the first level at Design. Then we manually assign the Hotspot 30 to the SI_A2 on the first level at Design.
Result
In that scenario, we observe that SI_A1, on level 2 and 3 with ‘spare parts’ links, automatically inherit from the Hotspot 10 at Runtime. The SI_A1 replacing SI_B5 however does not inherit any Hotspot.
The SI_A2 replacing SI_B6 on the second level does not inherit from the Hotspot 30 at Runtime. However, the SI_A1 in the subtree of SI_A2 replacing SI_B6 inherits from Hotspot 10 at Runtime.
This confirm that one item (SI_A1) replacing another one (SI_B5) can only inherit from the hotspot of the replaced item, if any. However, it cannot inherit from Hotspot numbers at other levels of the spare parts structure (in the sense of items associated with ‘spareParts’ links). We observe the exact same mechanism for A2 replacing SI_B6.
This scenario however highlights the fact that an item in the spare parts structure (in the sense of items associated with ‘spareParts’ links) inherits from Hotspot numbers at other levels of this hierarchy, whenever they are not linked to another item with a ‘replacement’ link.