Simple use case: Check result as a value assignment for a field

Each time a user account (see Users) is saved (Create/Update), it is checked whether the 'Account number' (accountNumber) field is filled in the user's address.

The result of this check determines the status for the 'Active' (active) Boolean field, so that an account with 'Account number' is automatically 'Active' and one without 'Account number' is or becomes automatically 'Inactive'.

Configuration:

►NOTE◄ The value assignment of the return value from the Rule value resolver solves the given task much more efficiently than an If then else event action with two alternative instances of the Set value event action in the IF and THEN branches could.

More complex use case: Store test results in variables

An association criterion, which is used as a 'logic module', checks an address (see Addresses) at each step and stores the result of each step (as far as this step was executed) in a variable. These variables with the check results can then be evaluated by subsequent association criteria or or in an event handling that refers to the association criteria as a Sub criterion rule in the 'Validating rule' without having to repeat the actual check.

For a clear use case, the 'logic module' should only contain two AND linked checks:

1. The first check determines whether the 'Account number' (accNumber) field in the address to be checked is populated.

2. The second check looks up – whether an 'Account number' is specified – and whether an address book entry exists that refers to this 'Account number'.

Configuration: An association criteria XF_ACCOUNT_EXISTS is configured as described below.

►IMPORTANT◄ This association criteria uses the Check existence value resolver, which implies access to the Lobster Data Platform / Orchestration database. Such database accesses should be triggered as seldom as possible and only in a targeted manner in consideration of performance. For our association criteria, this can be achieved by selecting the Logical component option (see Association criteria of type 'Logical component'). This causes the association criteria to be evaluated only if it is addressed directly and not automatically each time the context is updated.

The following combinatorics results for the course of the tests by this association criteria:

If this association criteria is included as a Sub criterion rule, e.g. in an If then else event action, the following four different scenarios can be distinguished on the basis of the two variables, if required.

Based on this, a check of the addresses for a list of user accounts is executed and the check result per entry is output.

Runtime example:

Configuration:

• In the Resolver for entities of the loop (see For each loop), a Collect values resolver determines the addresses of the associated user accounts starting from a given list of Long values ('User IDs'). The following concatenation of value resolvers is processed for each entry:
  

  • Input object (type safe): To convert the Long values into Users.

  • Object property: Value resolver for accessing the address field in the user account.

  • Default value: Value resolver that enters the false static Boolean value into the list if no address is found.
    ►NOTE◄ A $null value would otherwise simply be omitted by the Collect values resolver.
    
    

• The two Set value event actions are used to ensure that in each iteration of the loop, the accountSpecified and foundInAddressBook variables are reset to 'no value' before the XF_ACCOUNT_EXISTS association criteria is evaluated.
  
  

• The If then else event action checks through the fourfold case distinction 'from left to right' until one of the rules applies. Then the actions are executed below. In the example, a Show alert (Popup) event action with a specific message is executed in each case.

  • The first condition checks the association criteria XF_ACCOUNT_EXISTS as a Sub criterion rule. The accountSpecified and foundInAddressBook variables are assigned via the Rule value value resolver depending on the history.
    

    • The Sub criterion rule applies exactly when both variables contain the value $true. This case can therefore be identified without direct checks for variables.

  • The second condition checks if the foundInAddressBook variable has the value false. This value is assigned exactly when there is an 'Account number' to look up that is not yet in any address book.

  • The third condition checks if the accountSpecified variable has the value false . This value is assigned exactly when an address is present and it does not specify an 'Account number'.

  • The fourth branch of case differentiation does not use any condition. It is only entered if none of the conditions for other branches apply. This is only the case if the Check type for the 'address' type in the Sub criterion rule fails because there is no address to check but the Boolean value false from the Default value resolver in the Resolver for entities (see above).

Special use case: Evaluate a rule in the context of a search

The Regelwer resolver can also be useful if the condition of a search (see Search API) should include the check result of a rule or an association criteria (as a Sub criterion rule).

The following example demonstrates this using a configuration for a row formatting Condition in a datagrid (see Row formatting in datagrids, Datagrid preferences overview).

►NOTE◄ It is not possible to pass the data of the 'row to be evaluated' to which the condition refers as input value to the Rule value resolver. If the right side does not define a projection, a value is resolved only once, namely before the search starts.