In list

"DEF"

["ABC","DEF","GHI"]

true

List in Compare value contains the Check value (direct)

4600

["3591","04600","39052"]

true

The second list entry in the Compare value is converted to the integer 4600 defined as the Check value.

32

["32.1608", "32.0"]

true

The second list entry in the Compare value is converted to the integer 32 defined as the Check value.

32

[31.999, 32.1608]

true

The second list entry in the Compare value is converted to the integer 32 defined as the Check value.

["EDME"]

["LOWS", "EDME", "EDMQ"]

true

The third list entry in the Compare value is converted to the list defined as the Check value (with one entry).

["EDME"]

"EDME"

true

The Compare value (String) is converted to the Check value defined list (with one entry).

["EDML", "EDMV", "EDMY"]

["EDMV", "EDMY"]

true

None of the list entries in the Compare value matches the list provided as the Check value.

["LEPA", "EDDM"]

[["EDDM", "LOWI"], ["LEPA", "EDDM"]]

true

The second list entry in the Compare value matches the list defined as the Check value with two entries.

"[LEPA, EDDM]"

[["EDDM", "LOWI"], ["LEPA", "EDDM"]]

true

The second list entry in the Compare value returns the string defined as the Check value as a String image.

"[EDDM,LOWI]"

[["EDDM", "LOWI"], ["LEPA", "EDDM"]]

false

None of the list entries in the Compare value returns exactly the String defined as the Check value as a string image.

Specifically, to match the first entry, the space after the comma is missing.

Comparison of 'client objects':

{"name":"robinson"}

[{"name":"friday"}, {"name":"robinson"}]

in server context:

true

in Client Workflow:

false/true

In a server-side execution context (within Event handling, Association criteria, etc.) data objects are basically compared by content, i.e. by their specific property values.

In a Client Workflow, a 'Client object' is only recognized as 'equal' if it is the same 'Client object'. A comparison of the contents does not take place.

We create the two 'Client objects' from the list in the compare value (above) in advance and assign them to two variables (named robinson and friday).

true

Since in this example the list entries refer by reference to the 'Client objects' created in advance, the In list comparison is also considered to have passed in the Client Workflow.

For the Client Workflow, the comparison appears like this:

• (Object-A) In list (Object-B, Object-A)

in server context:

true

in Client Workflow:

false

The server compares content and recognizes the match.

For the Client Workflow, the comparison appears like this:

• (Object-A) In list (Object-B, Object-C)

Whether or not the content of Object-A is the same as Object-C is simply not examined.

false

In this variant, the 'Client object' in the Check value is converted to a String by an Object to JSON. It is wrong to expect that the 'Client objects' listed in the Compare value will be automatically converted to JSON Strings for the In list comparison. In fact, a String image of each 'Client object' from the Compare value is used for comparison, but it does not reflect the JSON format.

The following variant, on the other hand, leads to the goal.

true

With this variant, the content comparison of 'Client objects' can be enforced independently of the execution context (client/server) by comparing their JSON format image as a string instead of the objects involved.

The list of 'client objects' in the Compare value is converted by the concatenated Collect values resolver into a list of String values that map the listed objects into JSON notation.

The Value to collect is defined via the Object to JSON value resolver, ensuring that the notation in detail matches the JSON string generated as the Check value if a content-matching 'Client object' is listed in the Compare value.

The In list compare type is purposefully not used here so that the check of the list provides the same results regardless of the execution context (server/client):

• The list of 'Client objects' provided as a Compare value in an In list comparison is configured on the right as the input value for a Rule list resolver, which provides the Check value for an Is empty comparison negated by the not (Matcher) within the outer Entity property rule.

• The inner Entity property rule (in the Rule list resolver) compares the entity variable (here: list entry from the input value) as the Check value with the 'Client object' as the Compare value, which would have served as the Check value in the corresponding In list comparison, in an Equals comparison with the Deep compare option switched on.

This may sound complicated, but it is really quite simple: The rule is passed if the list from the input value contains a 'Client object' as an entry that matches the content of the object searched for. This is because it is then considered to be the Check value for the outer Entity property rule, which satisfies the not (Is empty) condition.

As soon as the In list compare type is selected for an instance of the Entity property rule, the default value configuration for the Compare value (a Create list value resolver without entries) shown on the right appears – if applicable, instead of an existing value configuration for the Compare value (right).

In the automatically added Create list resolver, value configurations for list entries can be assigned by clicking on the symbol.

Clicking on the symbol removes an existing entry for a value configuration.

However, instead of the default value configuration, any other value configuration can be used that provides one or more suitable Compare values at runtime.

The association criteria uses the AND conjunction of two rules as shown on the right:

• The initial Check type ensures that there is a user as the reference object. Only then is the second rule checked.

• The Entity property rule performs an In list comparison between the language selection for the user account in the input value and the statically defined positive list:

  • The 'Locale' (locale) property of the given user is used as the Check value (left), which is read by the Object property value resolver.

  • After selecting the In list comparison type (below), the Create list value resolver is automatically suggested for the Compare value (right). In this, the static positive list can simply be created by assigning a value from the dynamic enumeration Locale to each entry. The selection allows one instance of the Any enumeration value resolver at a time.

The association criteria uses the AND conjunction of two rules as shown on the right:

• The initial Check type ensures that the reference object is an entity of any type. Only then is the second rule checked.

• The Entity property rule performs a comparison with the In list compare type:

  • The Check value (left) is provided by the 'Owner' (ownerId) property of the entity present as the reference object via an Object property value resolver.

  • As a Compare value (right), the 'Companies' (companies) list property from the user account that is considered user of session is used via an object property value resolver.

    ►NOTE◄ In the course of the value resolver chain, the Input object (type safe) resolver is first used to explicitly refer to the specific 'User' entity type, while the User of session could also be a 'Guest user' account (see Guest users).

If the User of session is a guest user, the first three value resolvers in the chain, which are identical to the above configuration, will return 'No value' ($null).

On this basis, the specific treatment for Guest users can be controlled by the Default value resolver attached to the chain.

As the image on the right shows, the value resolver chain in its Default value parameter is structured in the same way as before:

• For the return value from the User of session value resolver this time the 'Guest user' type is assigned by selection in the concatenated Input object (type safe) value resolver.

• In the concatenated Object property value resolver, the specific property 'Company' (companyId) can then be selected for the guest user.

►NOTE◄ The return value type for the chain is still the Long[] data type, whereas the Default value within the Default value resolver refers to the data type long. However, this does not affect the behavior at runtime: The In list matcher will always compare a single compare value directly with the check value.

Accessing the 'Company' property via the Object property value resolver can alternatively be done in the context of a Collect values resolver. Since the guest user account passed as input value is not a list, again only a single value ('Company') is read. However, this is returned as the only entry in a list, so during configuration the Long[] type of return value appears consistently.

This additional processing step in the value resolver chain creates transparency in the configuration, even if nothing changes in the effective logic at runtime.

►NOTE◄ Indirect case discrimination via Default value resolvers within a common value resolver chain solves the problem and results in a relatively compact configuration. For the benefit of more transparency and 'readability' in the configuration, an explicit case distinction could be configured within a With rule instead, which recognizes the User of session as either a 'User' or 'Guest user' based on a Check type and then makes a specific comparison with the entity's 'Owner' ID. Then the In list comparison type must be used only for Users, while for Guest users an Equals comparison is sufficient.