What is the procedural logic for an autocomplete rule?
Hello, my name is Steve. In this video, I’ll explain the procedural logic for an autocomplete rule.
An autocomplete rule proceeds logically, step-by-step, through a set of instructions. First, the rule fetches the declared variables. These could include a field value from the current business object; a value for UI context, such as the code for the current action type; or a row of values from a related business object. The rule then continues through one or more blocks of conditional logic. This is where the rule evaluates the criteria and other required references according to the requirements of the rule. Depending on the logic in the condition block, a validation rule determines whether an error or warning message will be triggered. For a defaulting rule it determines whether a field value will be defaulted.
Autocomplete rules use variables to hold criteria values and required references to be used in the logic of the rule. These values are from the fields inside the current, or in a related, business object. Variables are needed so that you can:
-
Access and store the values of fields on a related object.
-
Transform the value of a field on the current, or related, object so that it's in a form you can use in the rule's logic.
-
Get information about the UI state, such as the role of the logged in user, or if a given field has been modified. To get these values you use a function.
Variables are defined at the beginning of the autocomplete rule.
Variables that derive their values from a function are usually included in a subsequent IF block of conditional logic. Because these variables have values that are fetched from the data model, they can be used to determine if the rule should be triggered in the current action. In this example, the variable PeriodType uses a function to get the period type of the worker’s work relationship, for example, E for an Employee. The second variable, LegInfo, uses a function to let you access a related business object, person legislative information. This allows the rule to fetch related legislative information, such as Country Code.
You can use variables as conditions in the subsequent IF block. In this example, you want this rule to continue processing if the Country Code is United States, and if the current flow is Hire an Employee. If either of these conditions are not met, then the procedural logic ends.
A condition block is used to conditionally default or validate. It inserts a generic set of If… Then… Else statements into the rule in a block format. You can use this to conditionally proceed only if a field or an entire object is NOT NULL. You can change or add to any part of the condition block. The generic statements include a condition and several variables. You can edit these, or you can remove them after adding additional conditions and statements to meet the needs of your requirement.
These are some common options you have for editing the condition block:
-
In many cases you may not need or want the Else block. It is easy to remove using the rule editor.
-
You can add additional conditions. This will include the same conjunction, either AND or OR, as already used with previous conditions.
-
You can cluster a set of conditions inside a block with the same conjunction inside the cluster. For complex logic you can have additional groups of conditions, each with it’s own conjunction within each group and between the groups.
-
You can change the conjunctions between conditions, and between condition groups.
-
When you have more than one condition you can delete any of them. But you can’t delete a condition if it’s the only one in the block.
This concludes the explanation of the procedural logic for an autocomplete rule.
Thanks for watching.