Search (Event action)

First result

One single entity

Example: One Address book entity (base:Addressbook)

Value of the result variables

<value id="1312" ... 
name="Consignee"
	 xsi:type="base:AddressBook">
		<types>
			<type>CNE</type>
		</types>
</value>

One tuple data object (one 'row' of a list)

Example: ID and name of an Address book entity.

Value of the result variables

 <value xsi:type="object">
	<property name="name">
	   <value 
xsi:type="xsd:string">Consignee</value>
	</property>
	<property name="id">
	   <value 
xsi:type="xsd:long">1321</value>
	</property>
 </value>

First tuple as CSV row

Example: ID and name of an Address book entity.

Value of the result variables  

<value 
xsi:type="xsd:string">id,name
1321,Consignee
</value>

►NOTE◄ The first row of the CSV output contains the column name(s) (or the alias names of the projections) from the search.

Search value

(List of results)

A list of entities

Example: Two Address book entities (base:AddressBook)

Value of the result variable

<value xsi:type="list">
	<entry id="1312" ... 
name="Consignee"
	 xsi:type="base:AddressBook">
		<types>
			<type>CNE</type>	
		<types>
	</entry>
    <entry id="801" ... 
name="XF_CUSTOMERS"
	 xsi:type="base:AddressBook">
		<types>
			<type>DPA</type>
			<type>CNE</type>
		</types>
	</entry>
</value>

Multiple tuple data objects ('rows' of a list)

Example: ID and name of two Address book entities (base:AddressBook)

Value of the result variables

<value xsi:type="list">
	<entry xsi:type="object">
	   <property name="name">
		  <value 
xsi:type="xsd:string">Consignee</value>
	   </property>
	   <property name="id">
		  <value 
xsi:type="xsd:long">1321</value>
	   </property>
	</entry>
	<entry xsi:type="object">
	   <property name="name">
		  <value 
xsi:type="xsd:string">XF_CUSTOMERS</value>
	   </property>
	   <property name="id">
		  <value 
xsi:type="xsd:long">801</value>
	   </property>
	</entry>
 </value>

Multiple CSV lines

Example: ID and name of a set of Address book entities (base:AddressBook)

Value of the result variables

<value 
xsi:type="xsd:string">id,name
1312,Consignee
1201,TEST
1151,XF_PRINCIPALS
1051,INTL_APTS
851,ZX_SPECIAL_CUSTOMERS
803,VX_CUSTOMERS
802,ZX_CUSTOMERS
801,XF_CUSTOMERS
</value>

Search result

(as in the Search builder)

Data object of 'Search result' type (search:SearchResult)

Example: Two Address book entities (base:AddressBook)

Value of the result variables

<value count="2" 
xsi:type="core:SearchResult">
	<base:AddressBook id="1312" 
... name="Consignee">
		<types>
			<type>CNE</type>
		</types>
	</base:AddressBook>
	<base:AddressBook id="801" ... 
name="XF_CUSTOMERS">
		<types>
			<type>DPA</type>
			<type>CNE</type>
		</types>
	</base:AddressBook>
</value>

Data object of the 'Tuple search result' type(search:TupleSearchResult)

Example: Two Address book entities (base:AddressBook)

Value of the result variables

 <value count="2" 
xsi:type="core:TupleSearchResult">
	<columns>
	   <name xsi:type="xsd:string">id</name>
	   <name 
xsi:type="xsd:string">name</name>
	</columns>
	<result>
	   <row>
		  <item 
xsi:type="xsd:long">1321</item>
		  <item 
xsi:type="xsd:string">Consignee</item>
	   </row>
	   <row>
		  <item 
xsi:type="xsd:long">801</item>
		  <item 
xsi:type="xsd:string">XF_CUSTOMERS</item>
	   </row>
	</result>
 </value>

Data object of the 'CSV search result' type(search:CsvSearchResult)

Example: ID and name of a set of Address book entities (base:AddressBook)

Value of the result variables

<value count="12" 
xsi:type="core:CsvSearchResult">
	<result>id,name
1321,Consignee
1201,TEST
1151,XF_PRINCIPALS
1051,INTL_APTS
851,ZX_SPECIAL_CUSTOMERS
803,VX_CUSTOMERS
802,ZX_CUSTOMERS
801,XF_CUSTOMERS
	</result>
</value>

An event handler is configured as shown on the right:

• The Triggering events 'Delete' (see Common action event) reacts to the deletion of any entity.

  ---

• The Validating rule therefore determines by Check type whether an entity of the 'Order' type is to be deleted.

• So the Actions on passed rule will be executed exactly when an order is to be deleted:

  • The Search (Event action) determines whether there are shipments that refer to one or more of the items of the order. The return value of the Search (Event action) is a variable linkedShipments (see details below), to which a list of all shipments found is to be assigned.

  • The return value is processed further by the following event action of the Execute with type. Its Object resolver refers to the variable linkedShipments via the Variable value resolver.

  • In the action block of the Execute with event action, an Entity property rule is first used to check whether the Search (Event action) has 'found' any items at all.

       

  • If this is the case, then an Abort is triggered, with the Message listing the IDs of the relevant shipments. For this purpose, value resolvers of the Concat strings types and Collect values are nested, as shown in the screenshot below. The outer Concat strings defines the entire message text and the Concat strings in the Collect values for the Value to collect parameter defines the text repeated for each 'collected' shipment ID.

    ►NOTE◄ Instead of the Object property value resolver for the 'ID' property, other properties of the shipment could also be included, for example a reference attribute with an order number.

• The Save result as parameter here specifies the variable name linkedShipments for the return value of the search.

• The selection for Entity refers to the 'Shipment' entity type.

• 'Search value' is selected as the Mode for the return value so that a list of shipments is written to the linkedShipments variable.

• The Search should be executed as a 'Search', so that shipments found appear in the return value as a complete entity. For example, as long as only the 'ID' property is needed for the message, a 'tuple search' that returns only this property would be more efficient. With a 'Search' there is maximum flexibility in the design of the message, since all data of the found shipment is available in the return value.

• The Where condition of the search checks a Typed attribute projection whether the value of the 'ID of linked entity' property from the linked entity attribute of the Type 'Shipment to Order Line Item' (left side) is contained in a list of IDs of all order items, which is determined via Collect values resolver (right side) starting from the Object property lineItems of the order to be deleted.

The screenshot on the right shows the configuration for a Search (for the Companies/Clients Entity) within a Search (Event action), which actually only serves to create a Search object in the context of event handling, which is then to be used by an Open view (Action) as a filter condition for the view to be opened.

►NOTE◄ As execution of the Search cannot be prevented, it is configured here so that it generates as little data as possible. The Mode 'First result value' is therefore selected so that only one or no company account is saved in the dummy variable as the return value.

• The value-giving component of this search is the more or less complex Where condition. Specific details about its content are not relevant. The AND operation shown in the image can conceal an extensive and multi-nested logical aggregate.

• In the Customize Search block, a Set value event action assigns the 'Search' available there as a reference object to a mySearch variable, which, unlike the entity variable managed by the system, can also be accessed after the search has been executed by subsequent Event actions outside the 'Customize Search' block.

►IMPORTANT◄ In the subsequent Open view (Action) event action, the Search object is accessed as a whole. The Where condition defined in the where property is not directly adopted as a restriction for the opened overview. Instead, a Sub search restriction is created from the definition of the Search as a whole, which is AND-linked with any existing 'restriction' for the view to be opened (see Custom overviews). This procedure may seem unnecessarily complicated, but it ensures, among other things, that the Where condition in the transferred Search can also use Restrictions that address fields from Joins. The restrictive effect of INNER Joins can also only be transferred indirectly – with a 'detour' via the Sub search restriction – to the View name.

The Open view (Action) event action shown on the right opens a standard 'Company account overview' for which the 'Where' condition from the Search object in the mySearch variable applies as a 'restriction' if the value of this variable is resolved as a Search object in the Form data parameter.

►IMPORTANT◄ In case a Tuple search or CSV search is defined in the Search (Event action) in the mySearch variable instead of the Search, the addressed company overview would be opened but not restricted based on the search.

It is important to understand why: Open view (Action) only attempts to derive a restriction for the View name to be opened from the Form data parameter if its value corresponds to the 'Search' (Search) or 'Search restriction' (ISearchRestriction) type. A TupleSearch object would not pass this test. The applicable default handling for Form data (see Open view (Action) does not result in a selection (or an unintended selection due to the lack of an ID property) of an entity in the context of the opened overview.