In order to understand propagation paths, let’s have a look at the following generic example:

In this figure, you can see different sets of form properties that will form “propagation paths”.

The following figure will put these potential propagation paths in perspective:

As you can see, this figure has 3 propagation paths:

• First path: fp11 to fp12 to fp13 to form_2
• Second path: fp21 to fp22 to fp23 and fp21 to fp31 to fp33
• Third path: fp32 to fp31

These propagation paths indicate the path followed by the CPQ Engine when a domain is filtered or when a value is set. This can happen in multiple circumstances:

• The user gives the answer to a question.
  • By doing this, the user will execute a setValue which will in return filter the domain of the associated form property.
• The event logic forces a value for a form property.
  • By doing this, the event logic substitutes itself to the end-user and executes a setValue which again will filter the domain of the associated form property.
• The CPQ Engine is already executing a propagation path, and during this cycle the domain of a variable is filtered.
• A new BRC is loaded by the CPQ Engine or by the event logic.
  • By doing this, the CPQ Engine will check the execution conditions of this new BRC and possibly trigger a propagation path.

Let’s walk through this using an example. For the first propagation path, let’s suppose that the involved BRC are defined as follows. Notice that we have made abstraction of the flags “mustExist” and “mustBeAnswered” for simplicity’s sake.

When the user triggers answers value A for form property aFp11, the propagation path executes. The first thing that happens is the execution of brcListFp12, in order to filter the domain of Fp12. The domain of Fp12 is filtered and only one value is left; this value will be automatically “answered” by the CPQ Engine itself:

As the domain of Fp12 has changed, brcCstForm_1 is executed, in order to filter the domain for the form property Fp13. The result is the following:

Finally, the brcExForm_2 is re-evaluated, because the domain of Fp13 has been reduced to 2 instead of originally 4 values:

By now, it should be clear that a user action (in this case: answering a form property) can trigger a propagation path that executes multiple BRC.

The following lessons can be learned from this propagation path:

• Each time the user executes an action (setting a value, resetting a value, copying-pasting, etc.), a propagation path is triggered in which multiple BRC can be executed. The precise number of BRC depends on the model.
• Each time the user executes an action, a variable number of objects (amongst which: form properties) can be impacted by the propagation path.
  • These objects can undergo a certain number of changes: automatically setting a value, filtering the domain, becoming optional, etc.

It should also be clear that the more dependencies a model has, the longer the propagation path can be.

The length of the propagation path is a direct consequence of the design of the model and particularly the connectivity of the model. Indeed, the “connectivity” of the model represents how much the different attributes of a configuration (CP, FO and FP states, values and attributes) are dependant of each other via relations expressed as BRCs.

The more the objects are inter-connected, the longer the propagation path could be.

Warning:

So for very large models, take care of the way you define your Business Rules & Constraints and thus establish the topology of your problem.

Keep as much as possible independent sub-parts in the BRC network of your model and define unique entry point in these sub-parts.

In the previous section, we have focused on only one propagation path. However in some circumstances, propagation paths will automatically trigger subsequent propagation paths. Let’s have a look at our first example again:

In this example, the first propagation paths automatically stops at form_2, because the existence of the form_2 is still undetermined. However, if we add the answer “C” to brcListFp11, the overall picture changes. The propagation path can now look as follows:

In this case, the propagation path has determined that form_2 exists; this will have as an effect that all the form properties in form_2 suddenly exist and the second propagation path will execute.

As said before, the propagation paths are normally triggered by a user action, like “answering a question” or “resetting a question” or “copying-pasting an instance”.

However, the event logic module also enables the execution of propagation paths, because it typically automates user interaction.

For safety reasons, the event logic intervenes after the total propagation process. To illustrate this, let’s take the previous example again:

Using the Event Logic step in the Designer, the modeler can define that the answer “Z” is not acceptable, and therefore has to be reset (after issuing a message). This can be achieved using a “reset” action triggered on the “onComplete” event on form property fp11.

In this case, when the user answers “Z” to the first form property, both the first propagation path as well as the second propagation path will execute:

When the propagation path is finished, all events will be executed in order. In this case, the “reset” action will be executed and will again trigger the first and the second path.