A Global Rule is a library defined within a configurator. Define functions, subroutines, and types here to make them available in any other rules in that configurator. You can re-use the function many times while only programming the logic once.
Types of Snap blocks which you can insert into a global rule include
Arguments
Arguments are variables passed in to the rule. You can find them by using the Get/Set variable snap blocks. In this rule type, the Get block exposes these arguments:
| Name | Type | Description |
|---|---|---|
| configurator | Configurator | the current running configurator. |
| environment | string | "dev" if you are in the development environment, "test" if you are in the test environment, and "prod" if you are in the production environment. |
| parameters | map | a map of GET or POST parameters passed into the configurator when it was launched. |
Example
Your configurator may use arrays of strings or numbers to track lists of components. You may need to know if the same component is used in two lists. More generally, is there an intersection between two arrays? Here's a function that can answer that question.
Note that the function accepts an array of "any" type, so arrays of numbers, text, or complex objects from types can all be processed by one function. Since the returned array is also of type "any", it is up to the calling code to deal with this ambiguity, such as by assuming the type matches the type passed in.
Contexts for Functions
When writing a function or subroutine in Snap, consider which location for your library would be best.
| Benefit | Safe Function |
Global Rule |
Global Function |
|---|---|---|---|
| Logic available to entire environment |
|
||
| Logic available through the REST API |
|
||
| Logic hidden |
|
||
| Logic available to only this configurator/scene |
|
|
|
| Calculates faster, without network lag |
|
|
|
| Can write directly to UI elements |
|
|
|
| Can read directly from UI elements |
|
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.
Snap rules run in a specific order, and in response to specific events. Learn more about rule execution order.