Search junction
The Search junction is a type of restriction that is used to logically link Boolean return values from other Restrictions.
The Search junction is required when configuring Einschränkunge in Lobster Data Platform / Orchestration in the following cases:
|
Use case |
Logic |
Example |
|
AND junction |
The AND junction returns true if all linked Restrictions return true. Alternative Definition: The AND junction returns false if at least one of the linked Restrictions returns false. In the graphical editor (see right), the Restrictions are arranged one above the other within an AND junction. The arrangement demonstrates that the Rule passed result is only achieved if all Restrictions are completed from top to bottom (i.e. with the partial result 'Rule passed'). Failure to pass a single one of the linked Restrictions causes a branch to the right to the overall result Rule failed. |
|
|
OR junction |
The OR junction returns true if at least one of the linked Restrictions returns true. Alternative Definition: The OR junction returns false if all linked Restrictions return false. In the graphical editor (see right), the Restrictions appear next to each other within an OR junction. The arrangement demonstrates that the result Rule failed is only achieved if all Restrictions are completed from left to right (i.e. with the partial result 'Rule failed'). Passing a single one of the linked Restrictions results in the overall result Rule passed. |
This Search junction is considered passed for entities whose active property contains the value true AND whose ownerId contains the value 1066. |
|
Negation |
The return value of a restriction can be 'negated' – i.e. 'logically reversed'. The 'negation' therefore returns true instead of false and vice versa. ►IMPORTANT◄ Technically, Lobster Data Platform / Orchestration only provides for the negation of Restrictions for the Search junction restriction type. All other types of Restrictions can only be negated indirectly by using them within a negated Search junction. In the graphical editor, the negation is indicated by the symbol ( ! ) at the bottom of the Search junction. In addition, the text character '!' also appears as a prefix in front of the link type in the title bar of the Search junction (in the image on the right: '!AND') |
This Search junction is considered passed for entities for which the ownerId projection does NOT return the value 1066 - i.e. either no value ($null)) or a different value. |
This 
Configuration
The editor for Restrictions is based on the Rule editor in terms of appearance and function when it comes to creating logical aggregates.
The rules (see Rules and values) in the Rule editor correspond to the Restrictions. The Search junction corresponds to the Junction (RuleJunction) for rules.
A Search junction (SearchJunction) is created automatically if this is required to add a restriction or a negation to an existing configuration.
Technically, a Search junction (or the SearchJunction entity type) has the following properties:
|
Property |
Data type |
Usage |
|
Required expressions |
Object[] |
The 'Required expressions' property is used to list the Restrictions that are the subject of the Search junction. This list can contain any number of instances of any restriction type, including further instances of the Search junction. |
|
Junction type |
Junction type |
The static enumeration 'Junction type' (JunctionType) provides exactly two options:
|
|
not |
Boolean |
If the Boolean value true is assigned to the 'not' (not) indicator, the return value from the link is 'negated'. |
The technical structure of the Search junction is only relevant if a Search junction is created, changed or 'read' using automation or if the interactive function 'Edit as XML' is used to manipulate a Search junction.
In contrast, the following table shows typical interactive configuration operations for the Search junction using very simple examples. These operations can be used to create logical aggregates of any complexity by nesting.
|
Starting situation |
→ |
→ |
← |
|
To define a restriction, the various editors always use a parameter for a value configuration, the name of which can vary depending on the context (e.g. 'Where' condition or 'Restriction'). In the Search builder, for example, this affects the value for the Where condition within the configured search:
►NOTE◄ A specific configuration for the added Simple property restriction is deliberately omitted here. For the following alternative steps (see |
A click on one of the OR diamonds, which appears on the mouse cursor approach to the right or left of each restriction, opens a context menu for selecting the type of restriction to be added or by pasting a copied or cut restriction from the clipboard. |
|
The context menu options 'Cut' or 'Remove' delete existing restrictions from a configuration. If a Search junction that is not negated (see c) then only contains exactly one restriction, the surrounding Search junction automatically disappears from the configuration because it is no longer required. |
|
→ |
→ |
||
|
A click on one of the AND diamonds, which appears on mouse cursor approach to the right or left of each restriction, opens a context menu for selecting the type of restriction to be added or by pasting a copied or cut restriction from the clipboard. |
|
||
|
→ |
→ |
← |
|
|
|
By selecting the not option in Step c, a negated Search junction (with AND type) containing the original restriction was automatically created at the position of the original restriction. This only happens if the original restriction is not a Search junction. |
The Search junction created as the carrier of the negation to be applied does not automatically disappear again when the 'not' menu function is used again:
The only way to return to the original state is to select 'Cut' for the Simple property restriction in order to be able to insert it again after removing the Search junction. |
a Setting up an OR junction
a - Result
a+b: Reversal
↓ No restriction applied
↓ Click on the menu icon to open the context menu 
↓ An instance of the selected restriction type is added as a value by selection:
►IMPORTANT◄ Each instance of the Search junction in turn represents a restriction that can be linked or negated with other Restrictions in a parent Search junction.
The Search builder also provides a tree view for configuring the 'Where' condition, in which some of the operations described here can also be carried out.
►NOTE◄ However, the 'not' option for negation is not available via the tree view, but only in the editor. However, for an instance of the Search junction selected in the tree, the negation can be changed to via the Edit as XML function.
Example
A search for Company accounts should list company accounts, ...
.... to which the Company type 'Bill-to party' (INV) is assigned in the 'Company type' (types) property ...
... OR for which no parent company is specified in the 'Parent companies' (parentCompanies) property ...
... AND for which the User of session is not registered as the 'creator' (creatorId).
Configuration:
The Where condition of the search can be set up with the configuration operations described above as shown below.
The tree view in the Search builder illustrates the hierarchical structure of this Where condition:
|
At the top level of the 'Where' condition there is an instance of the Search junction of the 'AND' type, which links two 'Required expressions':
|
|
