Company of session
Value resolver – Abstract
Purpose: This value resolver either returns the company account data from the applicable login context or searches for a specific Company type in its parent company hierarchy.
Server context (e.g. Event handling) |
Client context (e.g. Client workflows) |
|
|
|
|
The Company of session value resolver supports two different evaluations for the applicable login context. This results primarily from the logged-in session (or an authentication via Login API), but may be temporarily changed in the direct or indirect context of a Run as event action.
If the optional Of type parameter is not used, then the value resolver returns the data of the company account to which the applicable logon context applies.
Provided that the login context of the session with regard to the company is unchanged in the execution context of the value resolver, the return value of the value resolver depends on the Force load option:
If the Force load option is not selected (default), the value resolver accesses the data set of the 'logged in' company account, which is kept as a 'snapshot' in the current session. This data set can differ from the server-side data set, since the 'snapshot' is only renewed if changes are made to the company account within the session. Consequently, changes from other sessions that were made after the last change within the session are not reflected in the return value.
If the Force load option is selected, then the value resolver queries the data set of the 'logged in' company account for the return value directly from the server.
If the value resolver is executed in the direct or indirect context of a Run as event action that explicitly specifies a company in the 'As company' parameter, its company account appears as the return value.
The Force load option does not matter in this scenario, because the data of the company explicitly specified in the Run as event action will be retrieved from the server even if it is the company that is actually logged in.
If a Company type is selected for the optional Of type parameter, then the value resolver searches the company hierarchy starting from the company from the applicable login context upwards until a company is found whose account refers to the selected Company type in the 'Company types' field (see Creating and managing company accounts).
The parent company hierarchy is only searched if the company itself does not refer to the searched Company type in the applicable login context.
The company hierarchy, which results from the assignment of 'parent companies' per company account (see Creating and managing company accounts), is searched upwards recursively and step-by-step, if necessary, until a company is found for the first time, for which the searched Company type can be assigned.
If there are several parent companies that match the searched Company type when evaluating a hierarchy level, the company account with the lowest ID (id) is returned.
If the evaluation of a hierarchy level does not yield any results, the search is continued with the 'parent companies' from the recently evaluated company accounts.
If there are no more 'parent companies' to evaluate, the search ends with the result 'no value' (null).
►NOTE◄ The search for the Company type in the company hierarchy is performed without regard to access restrictions for the respective company accounts. The return value also returns company accounts for which there is no read access in the context.
Configuration
The Company of session value resolver ignores the input value. However, it does take into account the applicable login context, which may be directly or indirectly modified by the Run as event action.
The optional Of type parameter enables a static single selection based on the dynamic enumeration Company type. As can be seen in the image, the Auswahlfeld/Combobox element supports a search function. ►IMPORTANT◄ If Dynamic enum filters are applicable for the enumeration in question in the context of a session, they also restrict the selection for the Company type in the course of configuration. However, Dynamic enum filters have no influence on the evaluation of the value resolver at runtime. ►NOTE◄ The Company type search will always (regardless of the Force load option) take into account the server-side data set of the company account if the company actually logged in to a session is applicable as the login context. If 'Company types' or 'Parent companies' of the logged-in company have been changed by other sessions, these may influence the return value rather than the possibly outdated data from the 'snapshot' held in the session. |
|
The Force load option controls whether the company account should be queried from the server when accessing the company actually logged into a session, or whether the possibly outdated 'snapshot' held in the session should be used.
►NOTE◄ The 'Force load' option only affects the return value of the value resolver. The 'snapshot' of the company account for the current session is not refreshed. |
|
Since the resolver does not download any company account data in Client context , the search for matches for an optional choice for Company type in parameter Of Type is also limited to the cloned data object for the actually logged in company, which is already available as part of the session information. Companies in the parent hierarchy of this company will not be evaluated . |
Examples
Example: Line formatting for direct 'Parent companies' in a company overview
In a company overview (see Creating and managing company accounts) the 'Parent companies' of the Company of session should be highlighted by a row formatter (see Row formatting in datagrids).
Runtime example:
|
The screenshot shows a section of a 'Company overview'.
|
Configuration:
In the settings for the list in the 'Company account overview' a Row formatter 'myParents' is added, whose Condition is configured as shown on the right:
►NOTE◄ The option Force load was omitted here. If 'Parent companies' is added or removed from the 'Vortex Inc.' account during the session, this will immediately affect the shading in the list. If a corresponding change is made by access in another session, the colored shading within the session of 'Vortex Inc.' does not reflect the changed data. This remains true even if it is already displayed after refreshing the list (via 'Search'). The shading will not indicate the state stored on the server until the next time the Vortex account is changed within the session or a new login is made. |
|
Example: Presetting a company attribute with a company from the hierarchy
The company hierarchy in Lobster Data Platform / Orchestration is used to map relationships in the internal distribution network of the trading company 'MRVL Ltd.'.
The companies involved are either sales offices (with the Company type 'Consignee'), or distribution centers (DCs), which are classified as 'Location' and/or 'Hub' per Company type.
The following conventions apply in the network:
Each distribution center (DC) that is classified as a 'Location' but not itself as a 'Hub' must specify exactly one 'Hub' as its parent company and obtain its goods exclusively from there.
Each sales office must be clearly subordinate to a distribution center (DC) as the parent company, but can also order goods from other distribution centers.
Requirement for the input form for purchase orders:
When a sales branch creates a new order, the 'Hub' that is directly or indirectly higher in the hierarchy should automatically be preset in the 'Loading party' company attribute.
Runtime example:
The following company overview (see Creating and managing company accounts) is intended to illustrate a section of the company hierarchy.
|
|
The company 'Outlet Nancy' (shaded red) is of the Company type 'Consignee', i.e. a sales branch referring to the 'DC-France @ Lyon' as the parent company.
The 'DC-France @ Lyon' appears shaded in blue in the context of a login with the company 'Outlet Nancy', since the row formatting from the previous example takes effect.
Since the 'DC-France @ Lyon' is only a 'Location' Company type and not a 'Hub', one of the parent companies must be a hub by convention. The 'DC-N @ Genova' (shaded gray) meets this condition.
The following 'Orders overview' for sales branches shades all orders for which the automatically suggested 'Hub' is considered as the 'Loading party' in green:
Configuration:
An event handler that responds to the Triggering event 'New' (Common action event) is configured as shown on the right:
►NOTE◄ It is irrelevant whether 'Outlet Nancy' has access rights to read the company account or to involve 'DC-N @ Genova' in orders. The fact that the 'DC-N @ Genova' does not have the Company type 'Loading party' (DPA) in the company account in the list of 'Company types' does not prevent the assignment as value for the 'Company' (company) field in the relevant 'Company and address attribute' by the event handler. |
|
Runtime example:
In a deviation from the convention that the 'Hub' should be clearly determined by the hierarchy as described above, the 'DC-Central @ Mannheim' is added as a second parent company for the 'Outlet Nancy':
|
|
The company overview now shows the parent companies 'DC-Central @ Mannheim' and 'DC-France @ Lyon' shaded in blue when the 'Outlet Nancy' (shaded in red) is logged in.
The company 'DC-N @ Genova' appears shaded gray because it was selected as the screenshot for clarity.
As the order overview shows, 'DC-Central @ Mannheim' is now the default hub for 'Outlet Nancy', because the Company of session value resolver already finds this company in the superior level of the company hierarchy when searching for the Company type 'Hub', while the 'DC-N @ Genova' would only come into play two levels above 'Outlet Nancy':
After this change, the configured event handling suggests 'DC-Central @ Mannheim' as 'Loading party' for new orders through the 'Outlet Nancy'.