Suche (Ereignisaktion)

Prev Next

Siehe auch: Abfragekonfigurator, Such API, Suche (Formulardesigner), Tupel Suche (Formulardesigner)

Ereignisaktion - Kurzfassung

Zweck: Sucht Daten in der Datenbank von Lobster Data Platform / Orchestration und speichert das Ergebnis in einer Variablen.

Tooltip

  • Verwendung: Die analog zum Abfragekonfigurator konfigurierbare "Suche" für die ausgewählte "Entität" überträgt abhängig vom ausgewählten "Modus", den ersten oder mehrere Rückgabewerte aus der Datenbank in die per "Ergebnis speichern als" angegebene Variable. Im Block "Suche anpassen" können Ereignisaktionen konfiguriert werden, die vor dem Ausführen der Suche ausgeführt werden. Dabei gilt die Suche als Bezugsobjekt, sodass ihre Definition "angepasst" werden kann.

  • Parameter:

    • Ergebnis speichern als: Variablenname

    • Entität: der gesuchte Entitätstyp

    • Modus: bestimmt den Rückgabewert

      ↓ Modus / Suche →

      Suche

      Tupel-Suche

      CSV-Suche

      Erstes Ergebnis

      eine Entität

      ein Tupel-Datenobjekt

      erster Tupel als CSV-Zeile

      Suchwert

      (Liste von Ergebnissen)

      Liste von Entitäten

      mehrere Tupel-Datenobjekte

      mehrere CSV-Zeilen

      Suchergebnis

      (wie im Abfragekonfigurator)

      SearchResult

      (Datenobjekt)

      TupleSearchResult

      (Datenobjekt)

      CsvSearchResult

      (Datenobjekt)

    • Suche: spezifische Parameter für Sucharten (Suche, Tupel/CSV-Suche) analog Abfragekonfigurator

  • Output: Ergebnisdaten in der angegebenen Variablen

  • Hinweis: Die Suche berücksichtigt die Zugriffsrechte für den Anmeldekontext der aktuellen Sitzung bzw. abweichende Einstellungen innerhalb einer Ausführen als-Ereignisaktion

Eine Suche (Ereignisaktion) "sucht" über die Such API Daten von Entitäten in der Datenbank von Lobster Data Platform / Orchestration und speichert abhängig vom ausgewählten "Modus", den ersten Treffer (sofern vorhanden) oder eine Datenstruktur mit mehreren Rückgabewerten in einer Variablen.

Hintergrund zur Such-API

Im Unterschied zu einem direkten Zugriff auf die Datenbank, der über die Ereignisaktion SQL-Abfrage ausführen auch realisiert werden kann, berücksichtigt die Such API Zugriffsrechte für einen spezifischen Anmeldekontext, der entweder durch die Sitzung oder - im Kontext einer Ausführen als-Ereignisaktion - abweichend von der aktuellen Sitzung definiert ist. Die Such API unterstützt außerdem die Abfragedefinition per Editor mit grafischen Benutzerschnittstellen für Projektionen, Einschränkungen, Joins, Wertauflöser usw.) was den Umgang mit den intern oft über mehrere Tabellen verteilten Daten effizient ermöglicht, ohne dass dazu SQL-Code erstellt, das interne Datenmodell im Detail verstanden oder Eigenheiten des verwendeten Datenbanksystems berücksichtigt werden müssten. Da die Such API auch in anderen Kontexten verwendet wird (Abfragekonfigurator, Eigene Übersichten, Verhalten, usw.) können außerdem bestehende Konfigurationen "Abfragen" (oder Teile davon) bei Bedarf durch Kopieren und Einfügen ausgetauscht werden.

Konzeptionelle Parallelen zwischen einer Datenbankabfrage (per SELECT in SQL) und der Struktur einer "Suche" spiegeln sich auch im Sprachgebrauch rund um die "Suche".
►ANMERKUNG◄ Gerade vor dem Hintergrund vordergründiger Ähnlichkeiten ist Aufmerksamkeit für Unterscheide angebracht und Skepsis gegenüber ungeprüften Annahmen zu empfehlen!

Funktional sind für die Suche (Ereignisaktion) drei unterschiedliche Suchtypen (Parameter Suche) relevant: Suche, Tupel-Suche und CSV Suche

In Verbindung mit drei Auswahlmöglichkeiten für den Parameter Modus (bzgl. Rückgabewert) ergibt sich die folgende Kombinatorik von Einsatzszenarien für eine Suche (Ereignisaktion):

↓ Modus / Suche →

Suche

Tupel-Suche

CSV Suche

Erstes Ergebnis

eine einzelne Entität

Beispiel: eine Adressbuch-Entität (base:Addressbook)

Wert (value) der Ergebnisvariablen  

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

ein Tupel-Datenobjekt (eine "Zeile" einer Liste)

Beispiel: ID und Name einer Adressbuch-Entität

Wert (value) der Ergebnisvariablen  

 <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>

erster Tupel als CSV-Zeile

Beispiel: ID und Name einer Adressbuch-Entität

 Wert (value) der Ergebnisvariablen

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


►HINWEIS◄ Die erste Zeile der CSV-Ausgabe enthält den oder die Spaltennamen (bzw. die Alias-Namen der Projektionen) aus der Suche.

Suchwert

(Liste von Ergebnissen)

eine Liste von Entitäten

Beispiel: zwei Adressbuch-Entitäten (base:AddressBook)

Wert (value) der Ergebnisvariablen

<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>

mehrere Tupel-Datenobjekte ("Zeilen" einer Liste)

Beispiel: ID und Name zweier Adressbuch-Entitäten (base:AddressBook)

Wert (value) der Ergebnisvariablen

 <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>

mehrere CSV-Zeilen

Beispiel: ID und Name einer Reihe von Adressbuch-Entitäten (base:AddressBook)

Wert (value) der Ergebnisvariablen

<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>

Suchergebnis

(wie Ausgabe im Abfragekonfigurator)

Datenobjekt vom Typ "Suchergebnis"(search:SearchResult)

Beispiel: zwei Adressbuch-Entitäten (base:AddressBook)

Wert (value) der Ergebnisvariablen

<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>

Datenobjekt vom Typ "Ergebnis Tupelsuche"(search:TupleSearchResult)

Beispiel: zwei Adressbuch-Entitäten (base:AddressBook)

 Wert (value) der Ergebnisvariablen

 <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>

Datenobjekt vom Typ "CSV-Suchergebnis"(search:CsvSearchResult)

Beispiel: ID und Name einer Reihe von Adressbuch-Entitäten (base:AddressBook)

Wert (value) der Ergebnisvariablen

<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>

Konfiguration

images/download/attachments/177912084/image-2024-9-18_8-41-43-version-1-modificationdate-1726641702571-api-v2.png

Unabhängig von anderen Parametern muss im Parameter Ergebnis speichern als ein Variablenname angegeben werden, über den nach fehlerfreiem Verlauf der Suche auf den Rückgabewert zugegriffen werden kann.

  • Der Datentyp des Rückgabewerts variiert abhängig von den Einstellungen für Modus und Suche (s. Matrix oben). Im Fall einer Suche ist zusätzlich die Auswahl für die Entität relevant.

Für jede Suche muss der Typ einer Entität ausgewählt werden, die als primäres Ziel der Suche betrachtet wird.

  • Ähnlich wie im FROM-Abschnitt des SELECT-Statements in einer Datenbankabfrage können über die Such API zusätzlich Daten von Entitäten anderer Typen über Joins eingebunden werden.

  • Auch Einschränkungen und - soweit anwendbar - Projektionen können direkt oder über Joins auf Daten "fremder" Entitäten zugreifen und diese in Beziehung zur primären Entität setzen.

Als Modus muss eine der folgenden Optionen für die Übergabe der Suchergebnisse in die Variable ausgewählt werden:

  • Erstes Ergebnis (Standard) begrenzt die Rückgabe auf den ersten "Treffer", sofern es überhaupt einen gibt.

  • Suchwert gibt alle Ergebnisse der Suche als Liste zurück, z. B. eine Liste von Sendungen, falls eine Suche nach dieser Entität ausgeführt wird.

  • Suchergebnis gibt alle Ergebnis der Suche als Suchergebnis-Objekt zurück. Dieses Objekt enthält die Ausgabe von Modus Suchwert im Objekt-Feld result und weitere Informationen zur Suche in anderen Feldern (z. B. count).

Die Auswahl für Suche definiert den Typ der Suche: Suche, Tupel-Suche oder CSV Suche.

Sobald für den Parameter Suche eine Auswahl getroffen ist, erscheinen unterhalb weitere Parameter, mit denen die Suche analog zum im Abfragekonfigurator definiert werden kann.

images/s/-95e2zf/9012/8yg2g7/_/images/icons/emoticons/warning.svg ACHTUNG images/s/-95e2zf/9012/8yg2g7/_/images/icons/emoticons/warning.svg Grundsätzlich kann der Typ einer bereits konfigurierten Suche nachträglich geändert werden. Allerdings gehen bei einem Wechsel zum Typ Suche Konfiguration für Projektionen und Gruppierung verloren, da die Suche diese nicht unterstützt.

Über das im Bild rechts oben eingeblendete Kontextmenü für den Parameter Suche kann die komplette Konfiguration über die Lobster Data Platform / Orchestration-Zwischenablage kopiert oder ausgeschnitten und in einem beliebigen Kontext, der sich auf die Such API bezieht, wieder eingefügt werden. Die Option Einfügen erscheint nur, wenn die Zwischenablage bereits eine Suchdefinition enthält.

Diese spezielle Zwischenablage ermöglicht nicht nur den Austausch von Suchdefinitionen, z. B. für Tests mit dem Abfragekonfigurator. Sie kann auch verwendet werden, um beim Editieren einen bestimmten Änderungsstand "einzufrieren", damit dieser bei Bedarf später wiederhergestellt werden kann.

Außerdem können natürlich auch einzelne Komponenten wie Projektionen, Joins oder Einschränkungen ausgeschnitten, kopiert und eingefügt werden, sofern Quell- und Zielkontext kompatibel sind.

images/download/attachments/177912084/image2021-4-22_18-12-40-version-1-modificationdate-1726641676949-api-v2.png

Beispiel

Bei der Anlage von Sendungen soll über ein Verknüpfte-Entitätsattribut (vom Typ "Sendung zu Bestellposition") im Kopf der Sendung ein eindeutiger Bezug zu genau einer Position einer Bestellung identifiziert werden können, auf die sich diese Sendung bezieht.

Das Löschen von Bestellungen soll unzulässig sein, solange Sendungen existieren, die sich auf Positionen der zu löschenden Bestellung beziehen. Beim Versuch eine solche Bestellung zu löschen soll eine Meldung wie die folgende ausgegeben und das "Löschen" unterbunden werden:

images/download/attachments/177912084/image2021-4-26_18-35-34-version-1-modificationdate-1726641676958-api-v2.png

Konfiguration:

Eine Ereignisbehandlung wird wie rechts abgebildet konfiguriert:

  • Das Auslösende Ereignis "Löschen" (s. Allgemein (Ereignisse)) reagiert auf das Löschen einer beliebigen Entität.

  • Die Prüfende Regel prüft daher per Typprüfung, ob eine Entität des Typs "Bestellung" gelöscht werden soll.

  • Die Aktionen bei bestandener Regel werden also genau ausgeführt, wenn eine Bestellung gelöscht werden soll:

    • Die Suche (Ereignisaktion) ermittelt, ob es Sendungen gibt, die sich auf eine oder oder mehrere der Positionen der Bestellung beziehen. Als Rückgabewert der Suche (Ereignisaktion) dient eine Variable linkedShipments (s. Details ganz unten), der eine Liste aller gefundenen Sendungen zugewiesen werden soll.

    • Der Rückgabewert wird durch die folgende Ereignisaktion vom Typ Ausführen mit weiter verarbeitet. Deren Objekt Resolver bezieht sich per Variable-Wertauflöser auf die Variable linkedShipments.

    • Im Aktionsblock der Ausführen mit-Ereignisaktion wird zunächst per Objekt-Feld-Regel geprüft, ob die Suche (Ereignisaktion) überhaupt Sendungen "gefunden" hat.

      images/download/attachments/177912084/image2021-4-26_18-54-15-version-1-modificationdate-1726641676964-api-v2.png  



    • Ist dies der Fall, dann wird eine Abbrechen ausgelöst, in deren Meldung die IDs der betreffenden Sendungen aufgelistet werden. Dazu werden Wertauflöser der Typen Textverkettung und Sammle Werte verschachtelt, wie im Screenshot unten ersichtlich. Die äußere Textverkettung definiert den gesamten Meldungstext und die Textverkettung im Parameter Wert zum Sammeln für Sammle Werte den für jede "gesammelte" Sendungs-ID wiederholten Text.

      ►ANMERKUNG◄ Anstelle des Objekt-Feld-Wertauflösers für das Feld "ID" könnten auch andere Felder der Sendung eingebunden werden, etwa ein Referenzattribut mit einer Auftragsnummer.

images/download/attachments/177912084/image2021-4-26_18-38-12-version-1-modificationdate-1726641676961-api-v2.png


images/download/attachments/177912084/image2021-4-26_18-55-32-version-1-modificationdate-1726641676966-api-v2.png

Die einleitende Suche (Ereignisaktion) wird wie folgt konfiguriert:

  • Der Parameter Ergebnis speichern als gibt hier den Variablennamen linkedShipments für den Rückgabewert der Suche an.

  • Die Auswahl für die Entität verweist auf den Entitätstyp "Sendung".

  • Als Modus für den Rückgabewert wird "Suchwert" ausgewählt, damit eine Liste von Sendungen in die Variable linkedShipments geschrieben wird.

  • Die Suche soll als "Suche" ausgeführt werden, so dass gefundene Sendungen im Rückgabewert als komplette Entität erscheinen. Solange - wie im Beispiel - nur das Feld "ID" für die Meldung benötigt wird, wäre eine "Tupel-Suche", die nur dieses Feld zurückgibt zwar effizienter. Mit einer "Suche" besteht dafür maximale Flexibilität bei der Ausgestaltung der Meldung, da alle Daten der gefundenen Sendung im Rückgabewert zur Verfügung stehen.

  • Die Bedingung der Suche prüft eine Typisiertes-Attribut-Projektion, ob der Wert des Felds "ID der verknüpften Entität" aus dem Verknüpfte-Entitätsattribut vom Typ "Ship To Ord Line Item" (linke Seite) in einer Liste der IDs aller Bestellpositionen enthalten ist, die per Sammle Werte-Wertauflöser (rechte Seite) ausgehend vom Objekt-Feld lineItems der zu löschenden Bestellung ermittelt wird.

images/download/attachments/177912084/image2021-4-27_5-58-42-version-1-modificationdate-1726641676973-api-v2.png

Aktionsblock "Suche anpassen"

images/download/attachments/177912084/image-2024-3-1_14-53-39-version-1-modificationdate-1726641676921-api-v2.png

Im Block "Suche anpassen" können Ereignisaktionen konfiguriert werden, die vor dem Ausführen der Suche ausgeführt werden. Dabei gilt die Suche als Bezugsobjekt, sodass ihre Definition "angepasst" werden kann.

Typisches Anwendungsbeispiel: Paging

Eine typische Verwendung zum Anpassen der Suche ist das Manipulieren der Parameter "Erstes Ergebnis" und "Maximale Ergebnisse", um über die Suche (Ereignisaktion) ein Paging für umfangreiche Datenmengen zu realisieren.

Für die folgende Konfiguration gehen wir davon aus, dass zwei Variablen firstResult und maxResults im Ausführungskontext für die Suche (Ereignisaktion) mit Long-Werten gefüllt sind, um das "Blättern" in einer umfangreichen Anzahl von Treffern zu ermöglichen.

Konfiguration:

Die rechts abgebildete Setze Werte-Ereignisaktion wurde dem "Suche anpassen"-Bock über das Kontextmenü für das images/s/-95e2zf/9012/8yg2g7/_/images/icons/emoticons/add.svg -Symbol (siehe oben) hinzugefügt. Sie definiert zwei Zuweisungen:

  • Die erste Zuweisung weist dem Feld "Erstes Ergebnis" (firstResult) der auszuführenden "Suche" den Wert der Variablen firstResult zu.

  • Die zweite Zuweisung weist dem Feld "Maximale Ergebnisse" (maxResults) der auszuführenden "Suche" den Wert der Variablen maxResults zu.

►HINWEIS◄ Da kein Zielobjekt definiert ist, beziehen sich die Objekt-Feld-Wertauflöser für die Zielwerte (links im Bild) auf die konfigurierte "Suche", die das Bezugsobjekt im "Suche anpassen"-Block gilt.

Der Entitätstyp dieses Bezugsobjekts hängt davon ab, welche der Sucharten im Parameter "Suche" (s. oben) ausgewählt ist. Die Beschriftung im Kopf des "Suche anpassen"-Blocks variiert entsprechend ("Suche anpassen", "Tupel-Suche anpassen" oder "CSV-Suche anpassen").


images/download/attachments/177912084/image-2024-3-1_15-4-35-version-1-modificationdate-1726641676919-api-v2.png

Besonderes Anwendungsbeispiel: "Nachrüsten" einer Bedingung

Eine CSV Suche im Kontext einer Suche (Ereignisaktion) sieht per Standard keine "Bedingung" vor. Im Block "Suche anpassen" soll allerdings ausgehend von zwei Textwerten aus Variablen (propertyName und beginsWith)eine Einfache Feld-Einschränkung als "Bedingung" generiert werden.

Dafür soll folgende Konvention gelten:

  • Die Variable propertyName benennt einen validen "Datenfeldpfad" für die gesuchte Entität, z. B. name für das "Name"-Feld.

  • Die Variable beginsWith definiert eine Zeichenfolge, die ohne Beachtung der Groß-/Kleinschreibung am Beginn des Werts im betreffenden Datenfeld (propertyName) erwartet wird, etwa TEST.

Konfiguration:

Der Screenshot rechts zeigt die Konfiguration für Ereignisaktionen im "Suche anpassen"-Block einer Suche (Ereignisaktion), die eine "CSV-Suche" ausführen soll:

  • Innerhalb der Setze Werte-Ereignisaktion wird als Zielobjekt per Erzeuge Instanz eine Einfache Feld-Einschränkung erzeugt und über den verketteten Wert als Variable speichern-Wertauflöser in die Variable filter gespeichert.

  • Es folgen drei Wertzuweisungen an Felder der neu angelegten Einfache Feld-Einschränkung-Instanz:

    • Dem Feld "Projektion" (projection) wird der Wert zugwiesen, den die Variable propertyName bereitstellt.

    • Dem Feld "Vergleichstyp" (compareType) wird der Schlüsselwert ilike als statischer Text zugewiesen. Das ist der Vergleichsoperator für Groß-/Klein-indifferente Textmuster.

    • Dem Feld "Zeichenfolge" (stringValue) wird der Wert der Variable beginsWith verkettet mit dem statischen Textwert % (Wildcard für eine beliebige Anzahl an Zeichen) zugewiesen. Diese Verknüpfung erzwingt eine Übereinstimmung "Am Anfang" des Werts aus dem per propertyName adressierten Feld.

      ►ANMERKUNG◄ Wir berücksichtigen hier nicht den Sonderfall, dass der Wert aus der Variable beginsWith Zeichen enthält, die im Kontext der Datenbank "maskiert" werden müssten (z. B. Wildcard-Zeichen wie % oder _).

  • Nachdem die Einfache Feld-Einschränkung erzeugt und parametrisiert ist, wird sie in der folgenden Setze Wert-Ereignisaktion als Ganzes dem Feld "Bedingung" (where) der Suche zugewiesen. Diesen Zugriff ermöglich die Variable filter, die eine Referenz auf das erzeugte SimplePropertySearch-Objekt enthält (s. Wert als Variable speichern oben).

►HINWEIS◄ Falls die Konfiguration für die "Bedingung" der CSV-Suche doch eine oder mehrere (statische) Einschränkungen vorsehen sollte, überschreibt unsere Zuweisung diese komplett. Soll die erzeugte Einschränkung zusätzlich zu bestehenden Einschränkungen berücksichtigt werden, muss eine Such-Verknüpfung angepasst oder erzeugt werden, um je nach Bedarf entweder eine UND- oder eine ODER-Beziehung herzustellen.

images/download/attachments/177912084/image-2024-3-1_15-43-2-version-1-modificationdate-1726641676912-api-v2.png

Besonderes Anwendungsbeispiel: Generieren eines "Suche"-Objekts

Über die Öffne View (Aktion) kann eine Übersicht für eine Entitätstyp mit einer "Suche" (bzw. "CSV-Suche" oder "Tupel-Suche")-Objekt anstelle von "Formulardaten" geöffnet werden. Dann wirkt die "Bedingung" aus der Suche wie eine "Einschränkung" für Eigene Übersichten. Falls es sich bei der geöffneten View um eine Eigene Übersicht handelt, wird die "Bedingung" aus der Suche mit der ggf. konfigurierten Einschränkung der Übersicht UND-verknüpft.

Da das Erstellen einer Bedingung per Automatisierung schnell aufwändig und unübersichtlich werden kann, wenn es um mehr als eine Einfache Feld-Einschränkung (s. oben) geht, kann eine Suche (Ereignisaktion) "missbraucht" werden, um das benötigte "Suche"-Objekt für Öffne View (Aktion) zu erzeugen.

Konfiguration:

Der Screenshot rechts zeigt die Konfiguration für eine Suche (für die Entität Firmen/Mandanten) innerhalb einer Suche (Ereignisaktion), die eigentlich nur dazu dient, im Kontext einer Ereignisbehandlung ein Search-Objekt zu erzeugen, das anschließend einer Öffne View (Aktion) als Filterbedingung für die zu öffnende View genutzt werden soll.

►ANMERKUNG◄ Da die Ausführung der Suche nicht verhindert werden kann wir sie hier so konfiguriert, dass sie möglichst wenig Daten erzeugt. Als Modus ist deshalb "Erstes Ergebnis" ausgewählt, sodass in die Variable dummy als Rückgabewert nur ein oder kein Firmenkonto gespeichert wird.

  • Der wertgebende Bestandteil dieser Suche ist die mehr oder weniger komplexe Bedingung. Konkrete Details zu deren Inhalt sind nicht von Belang. Hinter der im Bild erkennbaren UND-Verknüpfung kann sich ein umfangreiches und mehrfach verschachteltes logisches Aggregat verstecken.

  • Im Suche anpassen-Block weist eine Setze Wert-Ereignisaktion die dort als Bezugsobjekt vorliegende "Suche" einer Variablen mySearch zu, auf die im Unterschied zur vom System verwalteten entity-Variablen auch nach dem Ausführen der Suche von außerhalb des "Suche anpassen"-Blocks nachfolgenden Ereignisaktionen zugegriffen werden kann.

►WICHTIG◄ In der nachfolgenden Öffne View (Aktion)-Ereignisaktion wird auf das Search-Objekt als Ganzes zugegriffen. Dabei wird die im where-Feld definierte Bedingung nicht direkt als Einschränkung für die geöffnete Übersicht übernommen. Vielmehr wird aus der Definition der Suche insgesamt eine Sub-Suche-Einschränkung erstellt, die mit einer ggf. bestehenden "Einschränkung" für die zu öffnende View (s. Eigene Übersichten) UND-verknüpft wird. Diese Vorgehensweise mag unnötig kompliziert erscheinen, stellt aber u. a. sicher, dass die Bedingung in der übergebenen Suche auch Einschränkungen verwenden kann, die Felder aus Joins adressieren. Auch die einschränkende Wirkung von INNER Joins kann nur indirekt - per "Umweg" über die Sub-Suche-Einschränkung - auf die Zu öffnende View übertragen werden.

images/download/attachments/177912084/image-2024-3-1_17-6-16-version-1-modificationdate-1726641676903-api-v2.png

Die rechts abgebildete Öffne View (Aktion)-Ereignisaktion öffnet eine Standard-"Firmenübersicht", für die die "Bedingung" aus dem Search-Objekt in der Variablen mySearch als "Einschränkung" gilt, wenn im Parameter Formulardaten der Wert dieser Variablen als Search-Objekt aufgelöst wird.

►WICHTIG◄ Falls in der Suche (Ereignisaktion) in der Variablen mySearch anstelle der Suche eine Tupel-Suche oder CSV Suche definiert wäre, würde die adressierte Firmenübersicht geöffnet aber nicht auf Grundlage der Suche eingeschränkt.

Es ist wichtig zu verstehen warum: Öffne View (Aktion) versucht nur dann aus dem Parameter Formulardaten eine Restriktion für die Zu öffnende View abzuleiten, wenn sein Wert dem Typ "Suche" (Search) oder "Sucheinschränkung" (ISearchRestriction) entspricht. Ein TupleSearch-Objekt würde diesen Test nicht bestehen. Die dann anwendbare Standardbehandlung für Formulardaten (s. Öffne View (Aktion) ergibt keine Auswahl (mangels ID-Feld auch keine unbeabsichtigte) einer Entität im Kontext der geöffneten Übersicht.

images/download/attachments/177912084/image-2024-3-1_17-12-16-version-1-modificationdate-1726641676901-api-v2.png

►HINWEIS◄ Für alle relevanten Sucharten (Suche, Tupel-Suche und CSV Suche) besteht die Möglichkeit im Parameter Formulardaten auf das where-Feld innerhalb der Suche zuzugreifen. Dann wird versucht, die dort definierte Bedingung direkt (und falls nötig UND-verknüpft) als Einschränkung für die Zu öffnende View zu berücksichtigen. Dies gelingt allerdings nur, sofern innerhalb der Sucheinschränkung nicht auf Joins zugegriffen wird, die nicht über eine Verkettete Projektion komplett in die "Bedingung" integriert sind.