The Entity property rule shown on the right can be used in the Validating rule of an event handler or in an If then else event action to conditionally perform the critical operation:

• The value configuration for the Check value (left) uses the User prompt value resolver, whose return value is converted to a sequence of uppercase letters by the concatenated Upper case resolver.
  
  

• In the value configuration for the Compare value, the Secret Code is statically stored as the chatGptMeIfYouCan string (see Static values). The concatenated Upper case value resolver below ensures that the Compare value in the comparison is also compared only as a sequence of uppercase letters.

►NOTE◄ Typing a string like CHATGPTMEIFYOUCAN without errors is much easier for people if the sequence is broken up by alternating between lowercase and uppercase letters.

The Entity property rule shown on the right offsets the input variables, checks the condition ('Load weight in target range'), and stores the charge weight in a weight variable for further use:

• The Check value (left) defines the static default value for the integer portion of the load weight in tons.
  
  

• The Compare value (right) includes the calculation in a Calculate value resolver. The weight of the liquid (number of cubic meters x weight of a cubic meter) is converted back to tons (t).
  
  

  • The primary calculated 'Unit number' is assigned to the weight variable by the concatenated Store value as variable resolver.
    
    

  • The concatenated Object property value resolver then accesses the 'Value' (value) of the unit number, which defines the Compare value in BigDecimal format (decimal number).

►IMPORTANT◄ The Equals comparison type converts the Compare value data type (on the right) to the Check value type (on the left). In the configuration on the right, the Long data type that is relevant for the comparison appears in the hexagonal symbol for the Matchers. When converting decimals to integers, no rounding is done. The decimals are simply truncated.

The association criteria shown on the right defines a two-stage check within an AND conjunction (see Junction):

• First, a Check type ensures that there is an 'entity' as a reference object in the context.
  
  

• The following Entity property rule below is only evaluated in the context of an 'Entity'. It compares the 'Company types' (types) list field of the owning company and the Company of session using the Equals comparison type.
  
  

  • The Check value (left) is determined using a value resolution chain (see Chained resolver). Starting from the 'owner' (ownerId) field of the reference object, the relevant company account is first taken as the Input object (type safe). The concatenated Object property value resolver returns the list of the 'Company types' (see Company type) assigned there (see Company type), which is then sorted by the Sort list value resolver.
    
    

  • As a Compare value (right), the 'Company types' (types) list field is processed in the same way, based on the Company of session.

►NOTE◄ The Sort list value resolver must use a sort criteria acting in the same sense in the Check value and in the Compare value in both cases. Only then is it guaranteed that the compared company type lists are evaluated as matching even if they contain the same entries in a different order.

Runtime example: (Rule is considered passed)

• 'Company types' of the owner-company:
  

  • 'Bill-to party' (INV), 'Consignee' (CNE)

• 'Company types' of Company of session:
  

  • 'Consignee' (CNE), 'Bill-to party' (INV)

■ Prague,
Czech Republic

CZ

360

{
    "class": "set",
    "data": [
        {
            "area": "360",
            "country": {
                "class": "de.lobster.scm.denum.DynamicEnumDto",
                "enumName": "de.lobster.scm.localization.Country",
                "name": "CZ"
            }
        },
        {
            "area": "930",
            "country": {
                "class": "de.lobster.scm.denum.DynamicEnumDto",
                "enumName": "de.lobster.scm.localization.Country",
                "name": "DE"
            }
        },
        {
            "area": "844",
            "country": {
                "class": "de.lobster.scm.denum.DynamicEnumDto",
                "enumName": "de.lobster.scm.localization.Country",
                "name": "DE"
            },
            "zone": "CTR"
        },
        {
            "area": "950",
            "country": {
                "class": "de.lobster.scm.denum.DynamicEnumDto",
                "enumName": "de.lobster.scm.localization.Country",
                "name": "AT"
            }
        },
        {
            "area": "137",
            "country": {
                "class": "de.lobster.scm.denum.DynamicEnumDto",
                "enumName": "de.lobster.scm.localization.Country",
                "name": "SI"
            }
        }
    ]
}

▼ Regensburg,
Germany

DE

930

▼ Burghausen,
Germany,
Zone 'CTR'

DE

844

CTR

▼ Rennstein,
Austria

AT

950

■ Logatec,
Slovenia

SI

137

The value resolver chain shown on the right examines the list of client objects representing waypoints provided in per tour variable:

• The concatenated Rule list resolver defines the check condition per Entity property rule:
  
  

  • The Check value (left) is taken from a candidateWpt variable. This contains a 'Client object' that was created in advance and filled with the destination data to be checked.
    
    

  • The list entry of the tour to be evaluated should be used as the Compare value (right), i.e. the data object that represents an already present waypoint in the tour. This is returned by an Object property value resolver without specifying a field.

►IMPORTANT◄ For the Equals comparison type (below) the Deep compare option has been set here, since the question is not whether the 'client object' in the candidateWpt variable has already been added to the tour list. Rather, the goal is to determine whether the tour list contains a waypoint that matches the 'candidate' in the candidateWpt variable in all fields (see runtime example below).

►NOTE◄ If the check is limited to whether the tour list contains at least one waypoint 'client object' matching the 'candidate', the In list comparison type could in principle also be used in a simple Entity property rule (without the Rule list resolver). However, this approach only works in the server context, because 'client objects' are always compared by object content on the server side. Therefore, the Deep compare option in the above configuration can be omitted if it is guaranteed that the configuration will only be used in the server context and will never be copied to a Client workflow. In a Client workflow, the In list comparison type (like the Equals matcher with the Deep compare option turned off) only accepts truly identical objects as matches, which would not be appropriate for this example.

FROSTRANS KG
DE-84419 Schwindegg

{
	"area": "844",
	"country": {
		"class": "de.lobster.scm.denum.DynamicEnumDto",
		"enumName": "de.lobster.scm.localization.Country",
		"name": "DE"
	}
}

Candidate is considered a new waypoint, although the third waypoint ('Burghausen') refers to the same country (DE) and the same area (844).

The candidate lacks the 'Zone' (zone) feature.

FROSTRANS KG
DE-84419 Schwindegg 
via 
Combi Terminal Rail (CTR)

{
	"area": "844",
	"country": {
		"class": "de.lobster.scm.denum.DynamicEnumDto",
		"enumName": "de.lobster.scm.localization.Country",
		"name": "DE"
	},
	"zone": "CTR"
}

The reference to the 'Combi Terminal Rail' (see destination address) is systematically reflected in the zone field of the waypoint.

This now also recognizes that the destination is covered by the third waypoint of the tour.

not passed

passed

As a Check value and as a Compare value, one instance each of the Create instance value resolver returns a 'new' entity of the 'User' type (see Users). Although they do not differ in content immediately after creation, they are considered to be non-matching for Equals as long as the Deep compare option is turned off. If the option is enabled, however, they will pass the comparison of object contents.

not passed

passed

As a Check value and as a Compare value, one instance each of the Role of session value resolver returns an individual 'clone' of the role used in the session (see Roles). Although these two clones do not differ in content, they are considered non-matching for Equals as long as the Deep compare option is disabled. However, they pass the comparison performed with the option enabled.

passed

passed

The entity variable provided by the system is specified as the Check value, which refers to the current reference object in the context. The concatenated Store value as variable value resolver assigns a reference to this reference object to a second variable entity2 as value.

The value configuration for the Compare value refers to the entity2 variable. Since this variable contains a reference to the reference object and not a 'clone' as in the previous example, the Check value and the Compare value are considered to match regardless of the Deep compare option.

in server context:
passed

in Client workflow:
not passed

in server context:
passed

in Client workflow:
passed
but only by chance
(see notes right)

For the Check value and Compare value, the Role of session is first accessed. Since this value resolver returns two 'clones' of the actual role (see above), we access the 'ID' (id) field of the respective clone via concatenation, thereby using the Input object (type safe) value resolver to include the role in question in the current context without cloning it. In case of a server-side execution (e.g. in Event handling) the Equals comparison is therefore considered as passed.

►NOTE◄ The Input object (type safe) value resolver only really returns the data of the role referenced by ID in the server context. In a Client workflow, it instead returns a data object for which only the class and id fields are filled. In the specific use case, the compared data objects are considered identical only because their IDs match.

in server context:
not passed
(because of the 'clone' left)

in Client workflow:
not passed
(because of the 'clone' left)

in server context:
not passed
(Details see right)

in Client workflow:
not passed
(Details see right)

In the Check value, the Role of session value resolver provides a 'clone' of the role used in the session.

As in the previous example, the same role is added as an 'input object' as a Compare value via the ID found in the Role of session.

The Equals check fails in this configuration in all cases for different reasons:

• Without the content comparison, the original and 'clone' are considered different for server and client.

• The content comparison encounters specific differences on the server and client side:

  • The return value of the Role of session does not contain any data about the permissions of a role. The state provided on the server side as 'input object' contains this data.

  • On the client side, the Input object (type safe) value resolver returns only the ID field of a role.