Mit dem Abfragekonfigurator können unterschiedliche Typen von Abfragen bzw. "Suchen" konfiguriert und unter Berücksichtigung der Zugriffsrechte des aktuellen Benutzerkontexts auf die Lobster Data Platform / Orchestration-Datenbank ausgeführt werden.

Auch wenn der Abfragekonfigurator damit grundsätzlich zur Ausführung konkreter Recherchen in der Lobster Data Platform / Orchestration-Datenbank verwendet werden kann, besteht die wesentlich wichtigere Aufgabe darin, Abfrage-Definitionen zu entwerfen, die unmittelbar getestet und anschließend in einem anderen Kontext (z. B. Lobster_pro: SearchTask (_data-Funktion), SearchCronTask, Dashboards) implementiert werden sollen, wo ein selektiver Zugriff auf Daten bzw. Datenobjekte stattfinden soll. Der Abfragekonfigurator ist dabei als reine "Werkbank" für diesen Design-Prozess konzipiert und bietet keinerlei Funktionalitäten zum Speichern von "Suchen". Im Idealfall kann die XML-Definition einer erstellten Abfrage über die Zwischenablage direkt in den Zielkontext übertragen werden. Die "Einschränkungen" für Eigene Übersichten können umgekehrt in den Abfragekonfigurator übernommen werden.

Der logische Aufbau solcher "Suchen" ähnelt dem Aufbau von SQL-SELECT-Statements.

• Jede Suche bezieht sich auf eine bestimmte Entität, also einen bestimmten Datenobjekttyp aus aus der Datenbank von Lobster Data Platform / Orchestration (quasi der FROM-Teil eines SELECT-Statements).

• Joins zu anderen Entitäten können den Dateninhalt der Suche erweitern (wie im FROM-Teil eines SELECT-Statements).

• Die Struktur der Ergebnisse wird durch Projektionen (wie im SELECT-Teil einer SQL-Abfrage) bestimmt, wenn die Suche nicht auf komplette Datenobjekte der gewählten Entität abzielt.

• Bedingungen können das Suchergebnis qualitativ abgrenzen (WHERE-Teil eines SELECT-Statements), der Parameter Maximale Ergebnisse (TOP/LIMIT/... in SQL-Statements) quantitativ.

• Gruppierungen können in Verbindung mit Aggregationsfunktionen in Projektionen verwendet werden, um Teilergebnisse zu aggregieren (GROUP-BY in SELECT-Statements).

►HINWEIS◄ Mit Blick auf die Laufzeit beim Ausführen einer Suche sollte in Bedingungen, Sortierungen, Gruppierungen und Joins auf nicht-indizierte Felder möglichst verzichtet werden. Als Hilfestellung für die Gestaltung performanter Abfragen werden indizierte Felder im Kontext der Abfragedefinition immer durch ein angehängtes Sternchen gekennzeichnet. Das Sternchen kann wie im folgenden Beispiel als Suchkriterium eingegeben werden, sodass das Dropdown nur die indizierten Felder der gewählten Entität anzeigt:

Grundsätzlich sind drei Typen von "Suchen" zu unterschieden:

<base:Role id="501" [...] active="true">
    <roleName>Super user limited</roleName>
    <parentRole>1</parentRole>
    <flatPermissionNames>~</flatPermissionNames>
</base:Role>

Anhand eines Beispiels soll hier die grundsätzliche Funktionalität des Abfragekonfigurators erläutert werden.

Für Datenbankabfragen werden Suchobjekte verwendet, die im XML-Format zwischen dem Client- und dem Server übertragen werden. Bei der Verwendung beim Import über den _data, fungiert der _data quasi als Client, der die Suchobjekte auch im XML-Format liefert.

Das XML-Format der Suche im Beispiel ( Das XML ist eigentlich größer, aber nicht relevante Teile wurden der Übersichtlichkeit halber durch ... ersetzt):

Über (1) muss angegeben werden, welche Suchart verwendet werden soll, siehe auch Sucharten. Die Sucharten unterscheiden sich grundsätzlich nur darin, wie die Daten der Suche zurückgeliefert werden, z.B. Objekte, oder CSV oder Tuple-Objekte.

Eine Suchanfrage (SearchTask) erfordert immer die Angabe der Entität (2). Die Entität (im XML ist das dann der XML-Name als entity im Root-Knoten) entspricht dem FROM-Ausdruck in SQL, also welches Datenobjekt gesucht werden soll.

Auf der linken Seite wird die Suche in einem Baum dargestellt (3). Auf der rechten Seite (4) kann der links im Baum ausgewählte Teilbereich konfiguriert werden. Hier wurde die Bedingung (eine Feldeinschränkung) ausgewählt.

Die Bedingung (4) entspricht dem WHERE-Ausdruck in SQL. Hier werden über Projektionen (5) (siehe auch Projektionen) und Einschränkungen (4) (siehe auch Einschränkungen) die WHERE-Bedingungen konfiguriert.

Im Beispiel wird eine Feld Einschränkung (4) definiert, welche eine Feldprojektion (5) des Feldes cne.value.address.name1 mit like (6) auf den Wert (7) Mustermann überprüfen soll.