Gespeicherte Abfragen
Die Einsatzmöglichkeiten für Gespeicherte Abfragen sind vielfältig:
Einerseits kann man sie in Verbindung mit dem Abfragekonfigurator ganz einfach interaktiv einsetzen, um ad hoc erstellte Abfragen für eine spätere Verwendung (als Entwurf, Referenzlösung, Testfall, Vorlage, Recherche-Werkzeug usw.) abzuspeichern.
Andererseits kann man auf Gespeicherte Abfragen auch per Automatisierung zugreifen, etwa um eine vorbereitete Konfiguration dynamisch - u. a. per Abfrage mit Suchkriterien - auszuwählen, deren Struktur in einem Workflow verarbeitet wird.
►WICHTIG◄ Gespeicherte Abfragen können ausschließlich interaktiv - über die zugehörige Detailansicht, den Abfragekonfigurator - ausgeführt werden. Die Ausführung kann allerdings nicht unmittelbar über Verhalten oder Ereignisaktionen adressiert werden, um automatisiert Suchergebnisse zu gewinnen. Wie Gespeicherte Abfragen trotzdem sinnvoll zur Automastisierung genutzt werden können illustrieren die "Beispiele" unten.
Der Menüpfad "Verwaltung" → "System" → "Datenbank-Tools" → Gespeicherte Abfragen öffnet eine Übersicht für "Abfragen", für die der Abfragekonfigurator als Detailansicht dient.
Rein technisch handelt es sich bei Abfragen um Instanzen des Entitätstyps "EDI > Suche" (de.lobster.scm.edi.SearchTask), der alle Merkmale einer "Abfragekonfiguration" abbildet.
Der Menüpunkt Gespeicherte Abfragen erscheint nur im Menü, wenn die Rolle der Session über die Berechtigung zum "Details anzeigen" (oder eine höherwertige) für den Abfragekonfigurator verfügt.
Das Datengrid der Übersicht listet nur Abfragekonfigurationen auf, für die im Kontext der Sitzung Zugriff besteht, weil die Firma der Session als deren "Besitzer" festgelegt oder über Firmenfreigaben autorisiert ist.
Die Übersicht stellt über das Ribbon die generischen Funktionalitäten für Übersichten und den Umgang mit Entitäten in Übersichten bereit:
Welche Standard-Funktionen (Neu, Löschen, Bearbeiten, Abbrechen, usw.) konkret sichtbar und "aktiv" (=effektiv auswählbar) sind, hängt von den Berechtigungen für die Rolle der Session und ggf. dem Zugriff für ausgewählte Instanzen ab.
Die Daten der ausgewählten Abfrage werden in den Abfragekonfigurator geladen, für den ggf. eine zusätzliche View geöffnet wird, wenn im Ribbon "Bearbeiten" (oder auch "Details anzeigen") ausgewählt oder ein Doppelklick auf einen Eintrag im Datengrid ausgeführt wird.
Für Gespeicherte Abfragen können über die Funktion Liste in der Unterkategorie Änderungsverlauf vorherige Versionen nachvollzogen werden, sofern dieselbe Abfrage mehrfach gespeichert wurde.
Gespeicherte Abfragen können per Meta Exchange zwischen Systemen (z. B. Test-/Produktiv-System) ausgetauscht werden (s. Meta Exchange Erweiterung).
In diesem Zusammenhang sei auf die Möglichkeit hingewiesen, Abfragen mit Tags der Tag-Kategorie "Konfiguration" zu kennzeichnen, für die das Standard-Datengrid die Spalte Tag (Konfiguration) vorsieht.
Beispiele
Die folgenden Anwendungsbeispiele zeigen auf, wie Gespeicherte Abfragen zur Automatisierung genutzt werden können.
Besonderer Anwendungsfall: Bedingung für eine Suche (Ereignisaktion) übernehmen
Im Kontext einer Ereignisbehandlung soll eine Suche (Ereignisaktion) eine Teilmenge aller Gastbenutzer (im Zugriff) als Liste von Entitäten ermitteln, für die anschließend in einer Schleife eine Datenmanipulation ausgeführt werden soll.
Da dieselbe "Teilmenge" - konkret: eine Liste aller Gastbenutzer, deren Konto sich im Feld "Firma" (companyId) auf die Firma der Session bezieht - in unterschiedlichen Kontexten relevant ist, sollen die betreffenden Einschränkungen in einer gespeicherten Abfrage zentral hinterlegt und bei Bedarf gewartet werden. Die "Bedingung" für die dazu verwendete SearchTask-Entität soll zur Laufzeit gelesen und in die auszuführende Suche (Ereignisaktion) in der Ereignisbehandlung übernommen werden.
Konfiguration:
Zunächst muss eine Abfrage konfiguriert und speichert werden, die primär dazu dient die Bedingung zentral zu verwalten.
►HINWEIS◄ Wird diese Abfrage wie nachfolgend beschrieben komplett lauffähig durchkonfiguriert, kann man sie auch für Tests nutzen. Eine vollständige Konfiguration ist allerdings nicht zwingend erforderlich.
►ANMERKUNG◄ Für alle anderen Einstellungen wird der Standardwert beibehalten. Solange diese zur Laufzeit nicht auch explizit in die Suche (Ereignisaktion) übernommen werden, haben sie auf die erzielten Suchergebnisse keinen Einfluss. |
|
Diese Abfrage muss gespeichert werden, idealerweise nachdem man die bestimmungsgemäße Funktion durch das Ausführen von Tests mit geeigneten Daten verifiziert hat.
Anschließend kann der Zugriff auf die Bedingung im Kontext einer Ereignisbehandlung erfolgen.
|
Der Screenshot rechts zeigt denn Lösungsansatz im Überblick:
|
|
|
Der Screenshot rechts zeigt die Details für die erste Suche (Ereignisaktion):
►WICHTIG◄ Der Zweck dieser Abfrage besteht darin, die "Gespeicherte Abfrage" zu finden, deren "Bedingung" für die folgende Suche (Ereignisaktion) übernommen werden soll. Weder das Datenmodell noch die Erfassungsmaske für Gespeicherte Abfragen stellt sicher, dass der beim Speichern verwendete "Name" (name) eindeutig ist. Es können also mehrere Abfragen mit dem gesuchten Namen (hier: GUEST_USERS_FOR_COMPANY) existieren. Sofern für mehrere identisch benannte Abfragen im Ausführungskontext der Suche (Ereignisaktion) Zugriff besteht, wird hier nur der "erste" Treffer (s. Modus) als Rückgabewert berücksichtigt. Solange keine Sortierung verwendet wird, sollte das der Kandidat mit dem höchsten Wert für die ID (id) sein. Das ist in der Regel die zuletzt erstellte Abfrage, die der Bedingung entspricht. Im folgenden verzichten wir auf eine Prüfung, ob überhaupt ein Treffer erzielt wurde. Das ist für die Praxis bedingt empfehlenswert, da ohne weitere Vorkehrungen ggf. die nachfolgende Suche (Ereignisaktion) ohne Einschränkung ausgeführt wird, wenn die Suche rechts zur Laufzeit kein Ergebnis liefert. |
|
|
Der Screenshot rechts zeigt die Details für die zweite Suche (Ereignisaktion):
►HINWEIS◄ Die dafür erforderliche "dynamische" Konfiguration muss per Klick auf den Button "Suche anpassen" (ganz unten in der Suche (Ereignisaktion)) eingeleitet werden:
|
|
|
Im "Suche anpassen"-Block steht als Bezugsobjekt die oberhalb definierte "Suche" - hier: mit Entitätstyp "Suche" (Search) - zur Verfügung, damit dieses vor der Ausführung bearbeitet werden kann. Die Setze Wert-Ereignisaktion überschreibt dessen Feld "Bedingung" (where) mit dem entsprechenden "Sucheinschränkung"-Wert aus der vordefinierten Suche in der Variablen guestSearchTask. Wie der Datenfeldpfad im Objekt-Feld-Wertauflöser (rechts unten) verdeutlicht, muss dazu zunächst das Feld "Suche" (search) und dann dessen Feld "Bedingung" (where) gelesen werden. ►ANMERKUNG◄ Ähnlich könnte man - z. B. im Kontext einer Setze Werte-Ereignisaktion - auch mit weiteren Merkmalen der "Suche"-Entität verfahren. Im Unterschied zur "Bedingung" sind dabei aber ggf. Eigenheiten bzgl. der unterschiedlichen Sucharten zu berücksichtigen. Nicht jedes Merkmal steht in jedem Suchtyp zur Verfügung. Die "Suche" (Search) unterstützt zum Beispiel keine Gruppierung. |
|
▼
▼
Besonderer Anwendungsfall: Suche an eine zu öffnende View übergeben
Die im vorherigen Beispiel verwendete Abfrage für Gastbenutzer soll im Kontext eines Formulars verwendet werden, um beim Klick auf einen Button eine "Gastbenutzerübersicht" als modale View zu öffnen, die in der Abfrage definierte Teilmenge der Gastbenutzer anzeigt.
Konfiguration:
|
Der Screenshot rechts zeigt das Verhalten "lookup" für den Button:
|
|
