Working with association criteria
◄ Back to Entering shipment data
Procedures on this page:
Whether a certain configuration object in Lobster Data Platform / Orchestration is applicable or effective in a certain situation depends almost always on access in the login context (role, company/company shares). As we described in the previous step (Entering shipment data), however, many configuration objects must also be assigned Association criteria, which the system evaluates at runtime in order to distinguish 'situationally', whether or which configurations are considered suitable candidates for deployment.
For most of the configuration objects bound to Association criteria (including input forms), usability in a login context does not require read access for the configuration itself. The only decisive factor is whether there is read access for at least one association criterion whose rule applies in the login context. By means of a targeted company authorization for Association criteria, all configurations 'subject to assignment' can be 'made available' to other companies for functional use, or assigned as restrictions.
Association criteria are defined by rules (see Rule types), which are either 'passed' (true/true) or 'failed' (false/false) for the respective data context. The same is valid for the association criterion as a whole, which may or may not 'apply' as a result of logical connexions between several rules.
A check of all association criteria for which there is (at least) read access in a logon context against the background of a concrete data context (especially the reference object/entity type and, if applicable, the logon context) results in a logical 'situational picture' for the system.
If the circumstances require an exclusive selection decision (e.g. 'Which input form appears?'), the best-matching principle comes into play, in which only the applicable association criterion with the highest priority takes effect.
In other cases (e.g. 'Which menu functions appears?'), all candidates are considered according to the all-matching principle, to which at least one applicable association criterion is assigned, whereby the priority is generally irrelevant.
In the last section (Entering shipment data) the association criterion 'Global' was created, whose only condition – a Static rule – is always 'passed' (true):
This association criterion can now be assigned to all configuration objects 'subject to association' that are to be taken into account as a default or in any unspecific situation.
In the context of the input of shipment details, the only form configured up to now is used on the basis of this criterion, provided there is read access for the association criterion in the logon context. This currently applies only to the company 'Smart Logistics AG', which is the owner of the 'Global' association criterion.
Create an alternative input form for shipment details
This rather trivial scenario will now be extended by an alternative input form for shipment details, which will only be used in one specific situation.
The new input form 'External shipment' is to be used if a company belonging to the 'Transport company' group is selected as the 'Shipping freight forwarder' for the respective shipment.
Create a new shipment details input form named 'External Shipment' as a copy of the existing one, and then add an additional Tab panel element as shown below!
|
The additional tab is labelled 'Additional data'. In the Row layout of the tab, two input fields from the 'Text Attribute' category are to be added via drag & drop as shown below:
|
|
We can now temporarily assign the existing association criterion 'Global' to the new input form via Assign in the ribbon.
When creating a new shipment or editing an existing one, the new input form ('External shipment') is always displayed, which is easily recognizable by the third tab in the Tab panel element.
Why is the previously created form ('Standard Shipment') which is assigned the same assignment criterion ('Global') not used?
Since both entry screens qualify as candidates using the same association criterion, there is no difference with regard to the Priority, which is defined in the association criterion. In this case, the system simply reaches for the 'newest' form, since candidates of the same rank are sorted in descending order by their internal IDs.
Instead of this rather 'random' assignment logic, a targeted case differentiation depending on the assigned 'Shipping freight forwarder' is now to be configured.
Create selector form
Since the selection of the shipping freight forwarder should set the course for the entry possibilities of other shipment data, it should be ensured that this choice is made at the beginning of the shipment entry process.
This can be easily achieved by creating another input form for shipment details, which will exclusively select the shipping freight forwarder and which will be 'assigned' with priority, as long as this is not yet defined.
The input forms already created should appear alternatively – depending on the selection made – and only when the selection is finalized.
Create a new (empty) input form for shipment details and assign the name 'Shipping freight forwarder selector' to it.
|
Next, configure the layout as follows:
|
|
With this configuration, the input form is now saved via Publish (in the ribbon) and is indicated as 'ready for use'. Assign the association criterion 'Global'!
How does the configuration within the input form work at runtime?
Any change of the selection in the selection field (that is different from the initial 'empty' state) triggers the 'Select shipping freight forwarder' behaviour.
The Behaviour (5) then executes the Kontext ungültig machen (6) action:
The current context (a shipment that recently contains a selection for the shipping freight forwarder) is not discarded as invalid, as the name of the action might suggest.
The action directs the system to discard the 'situational picture' created when opening the form as invalid, so that it re-evaluates the relevant Association criteria with the changed data.
By this action, the client gives the server the possibility to react to the changes that have not yet been saved and – as in our example – to check whether another input form is applicable for further processing on the basis of the Association criteria.
So now we have to set up Association criteria for the other input forms in such a way that they are accepted after selecting a shipping freight forwarder.
Define association criteria
Association criterion for standard shipments
For the assignment of the 'Standard shipment' input form, a new association criterion must be created, the rule of which includes the selection for the shipping freight forwarder.
|
The new Association criterion is assigned the Name 'Criterion standard shipment'. For the Priority the default value (0) is applied. ►NOTE◄ Since the 'Global' association criterion has been assigned a negative priority (-99999), it is ensured that any applicable criterion with the default value (0) overrides the 'Global' criterion. |
|
The new association criterion shall apply if the 'Shipping freight forwarder' selected for a shipment is the company 'Smart Logistics AG' or one of its corporate structure.
In the Rule tab, suitable Rule types must be logically linked with the Rule editor.
For the described criterion, a Typprüfung (regarding 'Shipment') and a Company attribute rule (to evaluate the selection for the shipping freight forwarder) are combined.
The 'matching' Verknüpfung (AND/OR) is automatically inserted via the editor, depending on the relative position at which an additional rule is inserted.
Since the association criterion is to be exclusively for the business object type 'Shipment', a rule of the Typprüfung (1) is first added by clicking on the 
symbol:
|
|
|
Parameterization of the Company attribute rule (4):
|
|
Finally, the newly created association criterion must be saved and assigned to the 'Shipment details forms' overview of the 'Standard shipment' form. The existing assignment for the 'Global' association criterion must be removed in the process.
Association criterion for 'External shipments'
Now a specific association criterion must also be created for the input form for the shipment details of 'External shipments'.
|
►NOTE◄ This association criterion can be conveniently used as a copy of the previous one, since it is identically structured. As Name (1), 'Criterion external shipment' is assigned. The Typprüfung can be kept unchanged. The selection of Companies (2) within the Company attribute rule, on the other hand, needs to be adjusted: Only the group (company account) 'Transport companies' should be selected. The option Company type 'Shipping freight forwarder' remains unchanged. The option Cascade down remains selected as well. After all, the criterion targets only the group members, i.e. the children to the group 'Transport companies'. ►NOTE◄ The group itself would also be accepted by the criterion as a 'Shipping freight forwarder', but it is not available for selection in the form because the Company type 'Shipping freight forwarder' is not assigned in the group's company account. |
|
Finally, the newly created association criterion must be saved and assigned to the 'Shipment details forms' overview of the 'External shipment' form. The existing assignment for the association criterion 'Global' must be removed in the process.
Verify configuration
Now that the association criteria have been assigned to the relevant input forms, the correct interaction of the association criteria with the forms should be verified.
Create standard shipment
When clicking on 'New' in the shipment overview, the 'Selector form' appears, in which the Shipping freight forwarder must be selected for the shipment before the actual shipment entry is made.
Scrolling through the options in the dropdown of the selection field for the Shipping freight forwarder, it is possible to see that all the companies from the 'Smart Logistics AG' company structure are selectable there, which qualify as the 'Shipping freight forwarder' Company type according to their account.
By contrast, the dropdown menu does not offer any of the companies defined as members of the 'Transport companies' group, which also qualify as 'Shipping freight forwarders'.
Background: Assigning a company as a 'participant' for a business object via a company attribute is tied to an independent authorization that must be granted individually for each business object type. For this authorization, a corresponding company authorization must be issued for the companies of the 'Transport companies' group as already shown (see Creating company authorizations or the chapter Company authorizations in the manual). Within the company structure of 'Smart Logistics AG', authorization is already given because a blanket release to parent companies has been issued for all authorizations (see Creating company authorizations).
The permission set up in the work step Companies as groups as groups for read access to the company accounts of the 'Transport company' group must therefore be extended by the missing permission ('Business objects/Shipments/Use as involved') as shown below:
The header data of this company authorization remains unchanged.
In the Permissions tab, the Use as involved permission must also be selected for the business object.
Now all companies of 'Smart Logistics AG' are allowed to use the members of the group 'Transport companies' as 'Shipping freight forwarder' in their shipments.
►NOTE◄ In the example, the same authorization is used to grant 'Read' (for company accounts) on the one hand and 'Use as involved party' (for shipments) on the other hand. This has the effect that when logging in with a company from the 'Smart Logistics AG' company structure, the companies that can be selected as 'Shipping freight forwarder' are also listed in the company overview. However, the 'Use as involved' would also work without the read access for the company accounts in question. Then only 'Smart Logistics AG' (as owner) could access the 'Transport companies' via the company overview, while the child companies could select the 'Transport companies' as 'Shipping freight forwarder' (for shipments), but could not view them in the company overview.
Back to the 'Test':
If the selector form for creating a new shipment is now called up again, all 'Transport companies' are also available for selection:
If a company from the 'Transport companies' group (e.g. DPD) is selected, the shipment is automatically interpreted as an 'External shipment', since the 'External shipment criterion' association criterion then applies. The action Kontext ungültig machen therefore causes the corresponding input form to appear:
►NOTE◄ At runtime, only the 'Additional data' tab indicates that this is the 'External shipment' input form. For a 'configurator' who knows the layouts of the two available forms, this is a clear differentiator. From the point of view of an end user who wants to enter a shipment, it is only relevant that he should enter 'Shipment details'. Whether different forms are involved, according to which criteria they are assigned and which form is currently displayed, does not necessarily have to be transparent for the end user. However, there is a function that can be used to uniquely identify the displayed input form at runtime:
Hold the Ctrl + Alt keys while clicking anywhere in the display area of the displayed input form!
A message like the following names the 'ID' (here: '10001') and the 'name' (here: 'External shipment') of the template used, as the designs of input forms are also called.
CAUTION
This function is available to every user who is allowed to open a form. This should be taken into account when selecting the name for an input form, which is otherwise only relevant for the configurator!
Conclusion: This was only the beginning of a long story...
The examples of association criteria rules presented in this tutorial are deliberately chosen to be simple and show only a small part of the range of rules described in the Rule types section of the manual. The possibilities to build complex logical connections from these 'building blocks' are almost unlimited. In this respect, this section is also intended to encourage independent experimentation in order to explore the given set of tools with an increasing degree of difficulty.
In general, the following applies in Lobster Data Platform / Orchestration: As soon as the 'Assign' 
button is available in a dialog, corresponding association criteria can be assigned.
► Continue with Weiteres Beispiel für Zuordnungskriterien