Configurator Rules are blocks of Snap code you can add to your configurator, giving it considerable logic and flexibility. Think of them as miniature programs which run at just the right moment to perform the right task. These rules are triggered by three types of situations, so your logic can run exactly when it's needed.
-
Events
Changes in the environment, such as when the configurator has completed loading, the user rotated their phone to change the screen size, or a message has been received from a 3D scene alongside the configurator.
-
Rules
Changes in a field's value, such as when the user selects a new value for a number field, or clears a value from a text field so it's empty. Rules store the bulk of your configurator logic.
-
Actions
A click on a button. Your user is explicitly asking for this logic to run.
1. Events: Changes in the Environment
When a change in the configurator environment occurs, only the rule associated with that event will be executed. Environment changes include:
| Event | Logic Applied |
|---|---|
| After an existing configured product is created or a new configurator is loaded in the browser's memory, and before the browser draws the configurator UI on-screen. |
Three blocks of logic run in this order:
The two value rules which frame the loaded rule help information flow up and down any nested configurator relationships. |
| After the user changes a field value. | The rule cycle is run (see next section). |
| After the user interacts with the configurator UI on-screen, not changing a field value. |
One block of logic is run, specific to the type of interaction:
Note that if a "setField" Snap block is included in any of these rules, then a field's value has changed. Therefore, the rule cycle described below is also run. |
| Just after the user submits their configured product for processing by clicking the submit button, and it disappears from the browser: |
(Pricing rules and naming rules are run server-side, not locally. Therefore, they usually complete after the submit rule. If you have Snap code you wish to execute only after the pricing rule completes, consider a general workflow state to contain this code.) |
2. Rules: Changes in a Field's Value
When the value of a field changes, either from a user changing its value in the UI or from a Snap rule changing the value logically, then all rules listed below will be executed in this specific order. This process is called the "rule cycle".
-
Field Rule
- Just the one field rule for the field changed by the user. Other field rules, associated with other fields that were not edited, are not run.
- When a configurator is first loaded, no field is considered "changed" by the user, so Field rules are not part of the loading process.
-
Option Filter selections are recalculated.
- If the current value in any field using this option filter is no longer included in the updated list of selections, then it is replaced with the first available selection in that list.
- Value Rules
- Validation Rules
- Visibility Rules
-
Pricing Rules
- Unlike other configurator rules, pricing rules are asynchronous and non-blocking. The next step in the rule cycle starts immediately, while this rule may still be running.
-
Scene Rules (if a 3D Scene is associated with this configurator). Scene rules are also non-blocking: the configurator is available for the user to edit while the scene updates.
While the order of execution of rules is clearly defined above, you have flexibility within that structure. If you have multiple rules of the same type, you can re-order them by simply dragging them up or down in
the design tree. You can also rename your rules as your application grows, or cut and paste snap blocks from one rule to another. This allows you as a designer to organize your rules in a way that makes
sense, and to change that organization over time as your configurator grows.
Order of operation is not the order of display.
In any configurator, the order of rule types displayed in the design tree is the order in which you added rules to that configurator. That order is for display only. It can vary from one configurator to the next. The
execution order is always the order in the numbered list above.
Some rules not included in rule cycle.
Notice that some rule types do not appear in either of the lists above.
- Both Global Rules and Global Event Rules are libraries that define functions, subroutines, and types which can be referenced by other rules in the configurator.
- A Naming Rule allows a configurator to change the name and description of its configured product based on Snap logic.
Elsewhere in the configurator design tree, you can also add logic for document automation through Output Rules. These are run after the user submits their configuration and are performed on the server.
3. Actions and Buttons: Logic Started by a User
When a user clicks an action or button, the Snap code within it runs. If that code changes the value of a field, then when the code is done the field update automatically triggers the rule cycle described above. Some examples include:
- A button labeled "Exploded View" which, when clicked, animates objects in the scene. Since no field values are edited, the rule cycle does not run.
- A button labeled "Apply Deluxe Package" which, when clicked, sets the values of various fields in the configurator to match a certain configuration. Since one or more fields were edited by this button, the rule cycle is triggered.
Keep your application secure.
Remember the Snap rules you write for your configurator or scene are executed in one of two places: either server-side within the cloud, or client-side within the user's browser. Consider the best location to balance needs for security and speed.
-
Server Side
Server-side code is executed on the server, and the results sent to the client. The Snap code itself is never sent to the user's device for execution. Server-side code is best for any proprietary calculations or patented, sensitive lookups. However, network latency does make this code slower.
Examples: pricing rules, workflow rules, safe functions, global functions. -
Client Side
Most other code is processed within the web browser on the user's device. Local to the user with no network latency, client-side code is fast and responsive. However, it is not as secure: some users could expose the logic or comments within the rule, as they can with any client-side javascript. Local rules are the best place for code which runs often, needs to be fast, and does not contain sensitive calculations or comments.
Examples: configurator rules, scene rules, global rules, etc.
You can easily mix and match your code, placing sensitive functions on the server and other code locally. Learn more about where Snap rules are executed.
Rule execution with nested configurators
When there are nested configurators, the order of execution depends on the situation at hand, and can be quite complex. Epicor CPQ analyzes the Snap rules to determine which rules need to be run depending on what has changed. The following steps gives a simple view of how Epicor CPQ makes these decisions.
Nested Rule Cycle
- Run value rule of configurator whose field has changed (the "parent" configurator).
- If this parent configurator has nested configurators ("children"), and the value rule has changed a field in one of those children, then run a full rule cycle on the nested configurator(s) that were edited.
- If #2 was run, and a value rule in the parent references any fields in the child that were changed, then run the value rule in the parent a second time.
- Run validation rule of the parent.
- Run visibility rule of the parent.
- If the parent of this configurator (the "grandparent" configurator) has a value rule that references a field in this configurator, then run a rule cycle on the grandparent.