Typical example: Conditional editing of address data

Runtime example:

<core:TupleSearchResult maxResults="100" count="84">
      <columns>
         <name>ADDRESS_LINE_1</name>
         <name>ADDRESS_LINE_2</name>
         <name>ADDRESS_LINE_3</name>
      </columns>
      <result>
         <row>
            <item xsi:type="xsd:string">fixIT Ltd.</item>
            <item xsi:type="xsd:string">Uphill 247</item>
            <item xsi:type="xsd:string">IE-X64GB Array on Byte</item>
         </row>
         <row>
            <item xsi:type="xsd:string">MEGATRUST Inc.</item>
            <item xsi:type="xsd:string">Postbox no. XYZ0815</item>
            <item xsi:type="xsd:string">MT-SCM Smart City</item>
         </row>
      ...
      </result>
   </core:TupleSearchResult>

Configuration:

As an application example for Case projection, the definition for the second address line (ADDRESS_LINE_2) is particularly relevant, as the content is to be formatted depending on a condition.

The Case projection is configured as shown in the screenshot:

• The text ADDRESS_LINE_2 is entered directly as the Name for the output column.

• We set up two branches for the two cases to be distinguished:

  • The first branch (left) is intended for the case where a 'P.O. Box' is specified:

    • The Field restriction in the condition checks whether the 'Postbox' (postboxNumber) property is 'filled' (!=null).

    • In this case, the Concatenated projection below links the property name as a Literal projection (see following note for details) with the value from the 'Mailbox' property via a space (Literal projection) as desired.

  • The second branch (right) regulates the default case (no 'mailbox' specified) via another Concatenated projection.
    

    • No condition is configured, so this branch always takes effect if the condition for the first branch is not fulfilled.

►NOTE◄ Further branches could be added to the case differentiation, e.g. to differentiate between the preparation with and without 'house number' or to include the optional second property for the street (street2). Of course, it is also possible to use another instance of the Case projection within a projection in order to display a hierarchical 'decision tree'.

More complex example: Conditional evaluation for a company and address attribute

A search should check whether the consignee address of a shipment (see Shipments) refers to a Country that is on a 'blacklist' for deliveries.

• The 'blacklist' is given in the context by a blacklist variable, which contains a list of dynamic enumeration values of the Country type.

• The consignee address of the shipment is defined via the 'Company and address attribute' with the (sub)type 'Consignee' (CNE):
  

  • If an explicit 'address' (address) is specified for the CNE attribute, this should be decisive.

  • If no explicit 'address' (address) is specified, the attribute should by convention reference a 'company' (company) instead, whose address (company.address) should then be included in the check.

Configuration:

We limit ourselves here to the Field restriction, which is considered 'passed' if the 'recipient country' is not included in the 'blacklist'.

• A Chained projection is used in the check value (left), which enables us to use a case distinction when 'resolving' the company and address attribute at the address level:
  

  • The Typed attribute projection initially only accesses the complete attribute value:
    

    • The Attribute parameter specifies that the attribute type should be 'Company and address attribute'.

    • The Type parameter specifies the desired (sub)type 'Consignee' (CNE) from the dynamic enumeration Company type for the attribute type 'Company and address attribute'.

    • No entry is made for the Property parameter so that the decision on the decisive property can be made in the next stage of the concatenation.

  • Two branches are configured within the Case projection:

    • The first branch uses Field restriction as a condition to determine whether the address property of the attribute is filled (not $null) and, if this is the case, passes the specified address (address) on to the next level of the concatenation.

    • The second branch does not use a condition. It is used if the address property is not filled and then forwards the company address (company.address) to the next level of the concatenation.

  • The final Property projection refers to the 'Country' property (countryCode) to be evaluated, which should not be found in the list value of the blacklist variable.

• The compare value (right) is provided by the blacklist variable, in the form of a list of Country values not specified here.

►NOTE◄ The Chained projection and the Case projection could be 'avoided' by testing the following logic instead:
(<CNE>.address.countryCode not in blacklist) OR ((<CNE>.address.countryCode == $null) AND (<CNE>.company.address,countryCode not in blacklist))
This logical aggregate can be implemented by linking several instances of the Field restriction. In contrast, the solution approach shown above avoids repeated access to the typed attribute (symbolically referred to as <CNE> in the aggregate) via the Chained projection and the redundant reference to the list variable (blacklist) as a compare value via the Case projection used within.

►NOTE◄ Special cases ('Attribute does not exist', 'No company referenced', 'Company does not reference an address', 'Address does not specify a Country') are not discussed here. We assume that the Field restriction is executed in a context in which these cases are already excluded.

Special case: Evaluating a rule in the condition of a Case projection

In addition to the internal 'ID' (id), a CSV search for Users should output the 'username' (username) property as a readable projection if at least one of the following conditions is met:

• In the execution context, refers to a specific role ('Administrator') as the Role of session.

• The 'Owner' (ownerId) of a listed user account is the Company of session.

If neither of the two conditions applies, the static text ************ should appear instead of the username.

Configuration:

The conditional output for the 'username' (username) property is achieved by a Case projection as follows:

• We assign the internal property name (username) as the Name for the output column to avoid null appearing as the column title.

• The Case projection uses two branches:
  

  • The first branch contains the condition to be evaluated with two instances of the Field restriction in an OR conjunction:

    • The first Field restriction compares the 'Owner' (ownerId) with the value from the id property of the Role of session, which is entered as a constant in the database query.

    • The second Field restriction uses a Role rule, to determine whether the 'Administrator' role applies as the Role of session.
      

      • The Boolean return value of the Role rule is defined as a Literal in a Literal projection via a Rule value resolver, as only projections can be defined on the left-hand side of the Field restriction.

      • A static Boolean value (true) is used as a compare value.

    • The Property projection for the 'User' (username) property returns the name in plain text if one of the OR restrictions applies.

  • Via the second branch of the case differentiation, a Literal projection without an explicit condition returns the static text ************, which is output if the condition in the first branch is not fulfilled.

Runtime example:

In the context of a login without the 'Administrator' role and with a Company of session whose 'ID' (id) is 1902, the search returns the following values, for example:

id,ownerId,username
51,501,************
151,502,************
4201,1902,jdsmith0815
4202,1902,jmmustermann
4203,1902,jmustermann
4204,1902,mjmartinez123
...