Within a Set value event action, the Variable value resolver is used to identify the target for the assignment:

• The Key is defined by direct input as static text (rightAngle).
  
  

• The Class specification is omitted. This means that the data type is stored that is returned by the value resolver chain on the right side of the assignment (here: 'Big Decimal'/java.math.BigDecimal).

Result: (XML image of the variables as entry in the storage map)

<entry>
<key xsi:type="xsd:string">rightAngle</key>
<value xsi:type="xsd:decimal">0.785398163397448309615</value>
</entry>

Within the previous configuration, the Class 'Double' (java.lang.Double) is now selected for write access via the Variable value resolver (on the left side), which stores the calculation result in the variable less precisely.

Result: (XML image of the variables as entry in the storage map)

<entry>
<key xsi:type="xsd:string">rightAngle</key>
<value xsi:type="xsd:double">0.7853981633974483</value>
</entry>

In a Client workflow (in the context of a form), a Show alert (Popup) event action can be configured as shown on the right to achieve the desired result:

• In the Title, the String value (CN) stored in the origin variable is accessed directly (per Key origin and without selection for the Class) via the Variable value resolver.
  
  

• In the Message, the Variable value resolver with the Key origin is again used to access the variable. However, 'Country' (Country) is selected as the Class here. At runtime, a type conversion of the text value in the origin variable to a value from the dynamic enumeration Country will be performed. If no Country is found with an internal 'Name' that matches the text value, 'no value' ($null) is returned..

►IMPORTANT◄ The return value for the Message is a dynamic enumeration value (DynamicEnumValue) if the type conversion is successful, which must be converted back to a String value in the context of the Message parameter for display in the notification. The string conversion for the Country value only takes the applicable localization into account in the client context (here: Client workflow). In the server context (e.g. in Event handling), on the other hand, the 'Name' is output as a string. Then the Title and Message in the example display CN.

Since a Search (Event action) can only be executed as an event action and not as a value resolver, the name of a variable into which the result of the search is saved at runtime must be specified during configuration via the Save result as parameter.

• In our example, Addresses are searched for, so this entity type must be selected in the Entity parameter.
  
  

• The 'Search value' Mode specifies that a list of all 'found' entities of the selected type should be returned.
  
  

• In addition, the 'Search' option must be selected in the Search parameter so that complete entities are listed in the result and not just tuples with selected projections from their data.

• Where checks exactly one condition, namely whether the value for the 'Country' (countryCode) field of the address is contained in a positive list with the statically defined enumeration values 'Belgium' (BE), 'Netherlands' (NL) and 'Luxembourg' (LU).

►NOTE◄ The Search (Event action) lists only addresses for the 'addresses' entity that can be accessed via Address book entries in the given execution context.

The following For each loop event action iterates over all 'found' addresses. A Variable value resolver is therefore used as the Resolver for entries and configured as follows:

• The Key is the name of the addrBNL variable, which was arbitrarily specified in the Save result as parameter of the Search (Event action) (see above).
  
  

• The 'Address' entity type is selected as Class, like the Entity parameter in the Search (Event action) (see above).
  
  

• The Is collection of option is checked because the 'Search value' Mode for the Search (Event action) (see above) returns a list of entities of the searched type.

Accordingly, the expected data type (at the bottom of the value resolver 'Address[]' is shown and the type 'Address' for the action block of the loop.

►NOTE◄ The selection for Class could technically also be omitted, since all entries passed into the addrBNL list variable with the Mode 'Search value' must be of the 'Address' entity type. If no entries are found, the variable contains an empty list, so no iterations of the loop are executed. The selection for Class here is mainly for declaring the variable content so that it can be transparently traced in the configuration of the loop and the contained Execute with event action and the 'right' elements (e.g. value resolvers) are offered as 'suitable' for the context.

The configuration for an association criteria shown on the right checks the criteria described above in the context of an Entity property rule:

• On the left side, the registered company is determined by the Company of session value resolver and its ID (id) is used for an In list comparison by a concatenated Object property value resolver.

• On the right side, a list is compiled with the IDs of the two company accounts that, according to the requirement above, should be considered 'acceptable' candidates in the sense of the criterion:
  
  

  • The first candidate is the 'owner' of the logged-in user account returned by the User of session value resolver.
    
    

    • The concatenated Object property value resolver accesses its 'owner' (ownerId) field, whose value contains the ID (id) of the relevant company account relevant for the comparison.

    • The concatenated Store value as variable value resolver stores this ID in the variable myOwnerId, since the company account in question must be accessed to determine its owner as the second candidate.
      
      

  • The second candidate is the 'owner' of the company that owns the User of session. To determine this, the company account in question must be evaluated:
    

    • The Variable value resolver reads the ID stored in the myOwnerId variable and – since this is a numeric value and the Class 'Company account' (CompanyAccount) is selected – looks up the respective company account as return value.

    • The concatenated Object property value resolver then accesses the 'owner' (ownerId) field as above to provide the 'ID' (id) of the relevant company account as a comparison value.

►NOTE◄ Instead of using the myOnwerId variable, the second candidate could also start the value resolver chain at the User of session and look up the owning company via the ownerId field as an input value for an Input object (type safe) value resolver to then get its ownerId.