SQL-Abfrage ausführen
Siehe auch: Wert aus SQL-Abfrage
Ereignisaktion - Kurzfassung
Zweck: Führt eine native SQL-Abfrage in der Lobster_data-Abfragesyntax aus.
Die Ereignisaktion SQL-Abfrage ausführen übergibt ein einzelnes natives SQL-Statement an eine Datenbank, die für den Lobster Data Platform / Orchestration-Server über einen "Alias" erreichbar sein muss.
Während für lesende Zugriffe alternativ der Wert aus SQL-Abfrage-Wertauflöser eingesetzt werden kann, ermöglicht die Ereignisaktion auch schreibende (bzw. löschende) Zugriffe soweit für die per Alias adressierte Datenbank entsprechende Berechtigungen bestehen.
Der Rückgabewert des SQL-Statements wird in eine Ergebnisvariable geschrieben. Dabei sind abhängig vom Typ des SQL-Statements zwei Fälle zu unterscheiden:
Die von einem SELECT-Statement zurückgegebenen Zeilen werden als Liste von Client-Objekten, deren Felder die Spalten der Abfrage widerspiegeln, in die Ergebnisvariable geschrieben. Abhängig vom Datenbanksystem erscheinen die Spaltennamen dabei entweder einheitlich in Großbuchstaben, einheitlich in Kleinbuchstaben oder unter Berücksichtigung von Groß- und Kleinschreibung. In jedem Fall muss die jeweilige Schreibweise bei Zugriff auf die Datenfelder in Lobster Data Platform / Orchestration (z. B. über einen Objekt-Feld-Wertauflöser) exakt ("case-sensitiv") übereinstimmen.
►HINWEIS◄ Falls eine Abfrage keine Zeilen zurückgibt, enthält die Ergebnisvariable eine leere Liste, die eine Prüfung per Ist leer erfüllt, aber nicht einen Vergleich wie "Ist Gleich 'kein Wert'" (s. erstes Beispiel unten).'Alle anderen SQL-Statements geben die Anzahl der "betroffenen Zeilen" (affected rows) als Ganzzahl in die Ergebnisvariable zurück. Der Wert lautet auch dann 0, wenn das Statement dem Typ nach keine Zeilen betrifft (z. B. DROP TABLE ...).
Das SQL-Statement kann die Werte von Variablen aus dem Kontext der aktuellen Ereignisbehandlung über typsichere Platzhalter entsprechend der Lobster_data Abfragesyntax einbeziehen.
Konfiguration
Im Parameter Ergebnis speichern als kann als statischer Text der Name der Ergebnisvariablen angegeben werden, in die Rückgabewert der Datenbank geschrieben werden soll. Die Angabe ist grundsätzlich optional. Beim Ausführen eines SELECT-Statements ist der Verzicht auf die Ergebnisvariable allerdings begrenzt sinnvoll, sofern es nicht nur darum geht, festzustellen ob es ohne Fehler ausgeführt werden kann.
Der Parameter Alias kann als statischer Text oder als Rückgabewert eines Wertauflösers bestimmt werden. Er muss auf eine Datenbank verweisen, auf die der Lobster Data Platform / Orchestration-Server zugreifen kann.
Der Parameter SQL-Query definiert das auszuführende SQL-Statement in der nativen Syntax der per Alias adressierten Datenbank, ggf. unter Berücksichtigung von typischeren Platzhaltern, an deren Stelle zur Laufzeit der Wert je einer Variablen aus dem Kontext der Ereignisbehandlung eingesetzt wird.
Für die Definition dieser Platzhalter greift die Lobster_data Abfragesyntax mit der Struktur @<index>:<typ>@, also etwa @1:s@ für einen String-Wert oder @2:t@ für einen Timestamp.
Der <index> muss dabei eine positive Ganzzahl sein, die auch als Variablenname innerhalb der Konfiguration verwendet wird. Die verwendeten Werte müssen dabei nicht lückenlos und aufsteigend vergeben werden.
Als <typ> muss ein Kennbuchstabe für einen Datentyp angegeben werden ( "l" long, "s" string, ... komplette Liste s. Lobster_data Abfragesyntax), der zum Verwendungszweck für den Platzhalter passen muss.
Für alle in der SQL Query verwendeten Platzhalter muss explizit ein korrespondierender Variablenname mit einem Wertauflöser konfiguriert werden, dessen Rückgabewert dem Datentyp des Platzhalters entsprechen oder zumindest geeignet konvertierbar sein muss.
Derselbe Variablenname kann von mehreren Platzhaltern referenziert werden, die bei Bedarf sogar unterschiedliche Datentypen spezifizieren können, solange jeder zur Laufzeit auftretende Wert in alle Ziel-Datentypen konvertiert werden kann.
►ANMERKUNG◄ Platzhalter können ausschließlich an Positionen des SQL-Statements verwendet werden, die Werte betreffen und nicht etwa, um Feld- oder Tabellennamen oder Schlüsselwörter der Syntax dynamisch zuzuordnen. Allerdings kann der Wert für den Parameter SQL Query insgesamt dynamisch aufgebaut werden (z. B. per Textverkettung), um entsprechende Flexibilität zu erreichen.
Beispiele
►HINWEIS◄ Die SQL-Statements in den folgenden Beispiele beziehen sich auf eine PostgreSQL-Datenbank.
Abfragen von Daten aus einer bestehenden Tabelle
Die Standardinstallation von Lobster_data stellt über den Alias hub den Zugriff auf Datenbanktabellen bereit. Zu diesen zählt auch die Tabelle dw_log zählt, in der Protokolleinträge auflaufen.
Für das folgende Demonstrationsbeispiel soll die Tabelle dw_log nach Einträgen durchsucht werden, die bei einem Neustart von Lobster_data geschrieben wurden. Mit der folgenden SQL-Abfrage wird nach der Spalte msg (Meldungstext) gefiltert und die Spalte date_at (Anzahl der Millisekunden seit dem 01.01.1970) für alle "Treffer" zurückgegeben:
SELECT date_at FROM dw_log WHERE msg like '%Lobster data%started'ORDER BY date_at DESCDa die Ergebniszeilen absteigend nach dem Zeitstempel (date_at) sortiert werden, repräsentiert der erste Treffer den jüngsten protokollierten Neustart von Lobster_data. Erfüllt kein Protokolleintrag das Prüfkriterium für den Meldungstext (msg) , enthält die Ergebnisliste keine Elemente.
Immer wenn sich ein Benutzer mit der Rolle "Super user limited" am Client anmeldet, soll eine Benachrichtigung mit dem Zeitpunkt des letzten Neustarts erschienen.
Konfiguration:
|
Eine Ereignisbehandlung wird wie rechts abgebildet konfiguriert:
|
|
|
|
|
Alternative Konfiguration mit "bedingter Benachrichtigung" |
|
|
Die rechts aufgezeigten Variante für die Konfiguration führt die Benachrichtigung per Hinweis anzeigen (Popup)-Ereignisaktion nur dann aus, wenn in der Protokolltabelle ein geeigneter Eintrag gefunden wurde. Anderenfalls gibt die Variable records nach dem Ausführen der SQL-Abfrage ausführen-Ereignisaktion eine Listenobjekt ohne Einträge zurück. Der innerhalb der Objekt-Feld-Regel verwendete Vergleichstyp Ist leer wird hier negiert, so dass die im Dann-Block platzierte Hinweis anzeigen (Popup)-Ereignisaktion nur ausgeführt wird, wenn das Protokoll einen "Treffer" liefert. ►ANMERKUNG◄ Auf den in der obigen Konfiguration für die Benachrichtigung eingesetzten Standardwert-Wertauflöser kann innerhalb dieser Fallunterscheidung verzichtet werden, wenn vorausgesetzt werden kann, dass die Spalte date_at in der Datenbanktabelle für jeden Protokolleintrag einen Zeitstempel enthält. |
|
Löschen von Einträgen aus einer bestehenden Tabelle
Als Beispiel für einen "Schreibzugriff" soll hier das Löschen von spezifischen Einträgen aus einer Schnittstellentabelle mit dem Namen who_is_who demonstriert werden, das immer dann ausgelöst werden soll, wenn bestimmten Typen von Allgemeinen Geschäftsobjekten der Arbeitsstatus "Abgeschlossen" zugewiesen wird.
DELETE FROM who_is_who WHERE obj_ref=@1:l@ AND obj_type=@2:s@Die zu löschenden Einträge sollen anhand einer Kombination aus Referenznummer (obj_ref als Long-Wert) und Objekttyp (als String) identifiziert werden, für die hier bereits Platzhalter eingesetzt sind.
Sofern Einträge gelöscht werden, soll der Benutzer über deren Anzahl benachrichtigt werden.
Laufzeitbeispiel:
Einem Allgemeinen Geschäftsobjekt vom Typ "Los/Charge" (LOT) mit der Kennung "1402" als Refernzwert (reference) des Referenzattributs "Beleg-Nr." (RECEIPT_NO) wird der Arbeitsstatus "Abgeschlossen" zugewiesen. Daraufhin werden alle Einträge in der Schnittstellentabelle who_is_who geschlöscht, die dieses Objekt betreffen (DELETE FROM who_is_who WHERE obj_ref=1402 AND obj_type='LOT') und eine Benachrichtigung wie folgende erscheint:
Konfiguration:
|
Eine Ereignisbehandlung wird wie rechts abgebildet konfiguriert:
|
|
|
Die Ereignisaktion SQL-Abfrage ausführen wird wie rechts abgebildet parametriert:
|
|
