The selection dialogue lists all available categories of value resolvers on the left.

By default, the overarching (pseudo) category ‘all’ is selected so that all available value resolvers are displayed in the selection list (on the right), including a reference to their parent category (in the ‘bottom line’).

The first entry in the selection list is focussed in the image: A user-defined value resolver with the name ‘myResolver’, which belongs to the ‘Custom blocks’ category.

At the top left (in the menu bar above the lists) there is an input field for a search criterion that only searches the entries in the selection list (i.e. the Resolvers in the selected category).

The ‘all’ category is always preset when opening the selection dialogue so that entering a search criterion without selecting a specific category always takes all available Resolvers into account. More experienced users skip the category selection and simply enter a proven string to quickly reach the selection for a specific resolver.

Various ribbon buttons appear to the right of the search field depending on the circumstances. In the screenshot, for example, the ‘Paste’ ribbon button appears because the Lobster Data Platform / Orchestration clipboard contains content suitable for pasting. This must be a value resolver.

The screenshot on the right shows a selection list that is restricted by the selection of a category (‘Content builder’) in the menu bar. Here, the name of the category is not shown in the bottom line, as it matches the preselection for all ‘matches’.

As long as a category only contains a manageable number of value resolvers, the selection of the ‘right’ choice for a particular task is quite easy based on the short list for the category.

As can be seen from the numbers behind the name of the category in the menu bar, there are also categories (e.g. ‘Value resolvers (38)’ or ‘String processing (14)’) to which so many value resolvers are assigned that the restricted selection list is also long.

The system for assigning value resolvers to categories is a single-level hierarchy, i.e. each value resolver is assigned to exactly one category. This means that ‘finding’ the right value resolver by selecting a category only works if the user makes the right choice from the categories offered. Not all categories offered are named in such a way that a specific profile can be derived from the name. In addition, the range of tasks for custom value resolvers in the ‘Custom subroutines’ category, for example, is unspecific by definition.

Whether a user prefers the selection from a self-selected category over a ‘global’ search via the 'all’ category depends on many factors – such as individual knowledge, experience and preferences – as well as on the specific task: Whether the aim is to ‘find’ a known value resolver in order to select it as efficiently as possible, or to search for a ‘suitable’ candidate that might not even exist, or how it is named, and where it should be categorised.

In the screenshot on the right, the character string ‘relative’ was entered in the search field while the category ‘all’ was selected (default when opening).

The selection list in the screenshot shows exactly two matches for the search string entered, in whose name the text ‘relative’ was ‘found’ in a coherent but case-insensitive manner.

However, it is not a criterion for the search that the characters entered were used as a continuous substring in the name, as the next example demonstrates.

In the screenshot on the right, the ‘rangetime’ string has been entered in the search field. The ‘all’ category has been retained.

With this string, the selection list only shows one hit that contains the characters entered (r-a-n-g-e-t-i-m-e) in the order in which they were entered:

'Relative date range with time'

The underscoring indicates the matches by character.

It remains to be seen whether it is worth remembering the unhelpful keyword ‘rangetime’ for the precise selection of the Relative date with time resolver. In any case, the input speeds up the selection process, which can be finalised by pressing the Enter key.

Within the selection list, a small icon appears on the far right of the line for each match, which can be used to obtain ‘Help’ for the value resolver in various ways:

1. For most configuration elements (not just Resolvers), a Quick Help window can be called up, which appears automatically when the mouse cursor is moved over the icon (see screenshot on the right). The ‘Quick Help’ window disappears again automatically when the mouse cursor leaves the area of the icon.
   
   

2. Clicking on the icon for an entry in the selection list shows the corresponding manual entry (if available). If necessary, a new documentation view is opened. Priority is given to an already open documentation view to display the page.
   
   

3. The ‘Help’ ribbon button at the top right of the selection dialogue can be used to open the manual entry for an already selected resolver after clicking on its menu icon to open the selection dialogue.

The placeholder for a value configuration shown at the beginning is represented graphically as the outline of a stadium (geometric figure). This shape is intended to symbolise the value that a specific value configuration returns. In the screenshot on the right, this relates to the left-hand side (placeholder) within a Set value event action.

In contrast, the right-hand side of the Set value configuration shows a trapezoid with a blue border, which represents a specific value resolver (here: Random long value). The symbol is intended to represent the value resolver as a funnel into which an input value is tipped ‘from above’ in order to obtain a specific return value ‘below’.

The screenshot on the right shows a Set value event action that defines the assignment of a random long Long value (Random long value resolver on the right) as the value of a variable (Variable value resolver on the left).

• The configuration interface for both value resolvers is ‘expanded’ to the maximum here so that available parameters and setting options (where available) can be recognised. Three parameters of different types can be seen on the left, whereas none can be seen on the right because the Random long value resolver does not offer any parameters.
  
  

• The arrows from above indicate that the reference object could be used as an input value on the left and right in the context of the Set value event. However, there are value resolvers that ignore the input value or do not forward it to value configurations for their parameters.

The screenshot on the right shows the same Set value event action, but after clicking on the minus sign at the top right in the blue framed area for both value configurations.

The configuration interface with the parameters is therefore no longer visible and the funnel symbol with the blue border now only shows the name of the value resolver (in grey at the top) and specific detailed information (left: name of the variable, right: type of return value).

The screenshot on the right again shows the same Set value event action, but after clicking on the minus sign at the top right of the grey rectangle for both value configurations.

The blue-framed funnel symbol for the value resolver has now disappeared completely and only the stadium symbol, which indicates the area for a value configuration (with or without a configured value resolver), can be seen.

The aim of a value configuration is always to provide exactly one return value. This can also be a ‘list’ of values or a complex data object with several values in data fields. However, these complex data structures are also returned as one value (object), just like a simple numerical value or text. However, each value configuration can contain more than one value resolver if these are combined to form a value resolver chain. Within the chain, which appears in the configuration interface as a ‘stack’ of value resolvers, each value resolver has exactly one input value (possibly from its predecessor in the chain) and exactly one return value, which either serves as the input value for its successor in the chain or represents the return value of the entire chain.

The screenshot on the right illustrates this using the example of a Set value event action in the value configuration for the value to be assigned (right):

• At the beginning of the chain is a Random long value resolver, which should only generate a random integer and does not process an input value.

• The first chained Calculate value resolver determines a random integer from the set {1,2,3,4,5,6} from the random long value, which can be addressed in the calculation as a input variable , which represents a ‘cubed value’.

• The second chained Calculate value resolver adds the ‘diced value’ to the value of another variable (total), which is also the target of the assignment here (left).

The screenshot on the right shows the configuration for the Set value resolver after clicking on the minus sign at the top right in the value configuration for the value to be assigned (right).

• The value resolver chain can no longer be seen as a sequence of funnel symbols.

• The labelling concatenates the data types of the respective return values using the ‘>’ character, which indicates the presence of a chain.

The selection dialogue described above, which must be called up to add a value resolver in an existing value configuration for an insertion point selected by the user, enables value resolvers to be chained.

As shown in the screenshot on the right, each value resolver has an insertion point at the top and bottom of the funnel icon to allow a predecessor or successor to be added. All available insertion points within a value configuration are marked with a icon as soon as the mouse cursor is in the area of the value configuration. The icons are generally grey, but change to green when the mouse cursor is hovered over them. Clicking on an icon then opens the selection dialogue for adding a value resolver at the relevant insertion point, e.g. by selecting it from the list.

When concatenating a single value resolver with a second one, a Chained resolver is automatically created, which acts as an invisible interface between the value configuration and the value resolver chain. If only a single value resolver remains after removing the other resolvers from the chain (menu icon → selection dialogue → ribbon button ‘Remove value’ or ‘Cut’), and automatically disappears again from the value configuration.

If Resolvers have parameters of a certain type, it should be possible to assign a value to these parameters in the context of the configuration.

The value resolver for static text shown on the right (see Text) provides an input field for text, the value of which can only be changed in the configuration context. At runtime, the configured text value ‘static’ (unchangeable) is returned.

In contrast, the Variable value resolver shown on the right provides two alternative ways of providing the Variable name text parameter:

• The image on the left shows the default view for the configuration interface, with a Text field for the Variable name parameter, which provides for the direct input of text (as in the Text) as the default method.
  
  

• Clicking on the small grey arrow symbol at the bottom left of the Text field makes the Text field disappear and instead displays the value configuration visible in the image on the right. The default Text resolver configuration can be edited or replaced by any other value resolver in order to assign the variable name dynamically (changeable at runtime).

If the value of a parameter (here: Variable name) allows the parameter value to be defined as the return value of another value resolver, the two value resolvers can be considered to be nested or cascaded, whereby the inner value resolver must provide its return value so that the outer resolver can determine its return value.

In the example on the right, the Variable name is determined in the outer Variable value resolver using a two-stage value resolver chain:

• The Role of session value resolver provides the ‘role’ (see Roles) applicable to the execution context as a complex data object.

• The chained Object property value resolver reads the text value from the ‘role name’ (roleName) field of this role, which is assigned to the outer parameter Variable name as the return value of the value configuration.

With this configuration, the Variable value resolver enables read/write access to a variable that is dynamically ‘named’ depending on the role applicable in the context (e.g. ‘Super user limited’).

If the value configuration for the Variable name parameter is changed so that only the static Text resolver offered by default defines the parameter value (see first screenshot on the right), then the next time the entire configuration is opened or after the configuration interface for the Variable value resolver is expanded/collapsed, the direct input originally offered appears again with the small grey arrow symbol at the bottom.

While the choice between direct input vs. value configuration is only offered selectively and almost exclusively for text parameters, the concept of nesting value resolvers is used in a variety of ways – in general, a placeholder for a value configuration is displayed for a parameter by default. Occasionally, a specific value resolver is also pre-assigned.

The Conditional value resolver shown in the screenshot on the right offers the option of case differentiation, in which the return value for each case can be determined by a freely definable value configuration.

In the example on the right, an Entity property rule with the Is empty compare type was inserted as a rule for case differentiation. This rule contains a value configuration for the check value, which is pre-assigned with an Object property value resolver by default. However, this is only a suggestion. The Object property resolver can easily be replaced by any other type.

The example configuration for the Conditional value shown on the right checks the Entity property rule to see whether the Trim value resolver (check value) returns a string or is empty based on the input value for the Conditional value.

• If the Is empty comparison is deemed to have been passed, the text 'INVALID' is assigned via a Text resolver.
  
  

• If the Is empty comparison fails, the 'trimmed' string image of the input value should result in a non-empty string. In the second branch of case differentiation, the input value is passed to a value resolver chain as an input value without checking another condition, which links an Upper case value resolver with a Trim resolver in order to determine a processed return value.

►IMPORTANT◄ The arrows in the configuration interface could give the impression that the check value ‘trimmed’ in the Entity property rule is forwarded to the second branch of the case differentiation as an input value if it is not empty. This is not the case!

Instead, in the context of case differentiation, the arrows only symbolise the order in which the branches are logically processed and not the passing on of any value. Both for a further check (not shown in the example) and for a value configuration in each branch, only the input value that was passed to the Conditional value from outside is relevant.