DB (Eingangsagent Cron)
Einführung: Eine Beschreibung dieser Phase finden Sie im Abschnitt Phase 1 (Einführung).
Die Eingangsdaten werden mittels einer SQL-Abfrage aus einer Datenbank gelesen. Startet der Eingangsagent einen Job, dann übernimmt dieser alle Datensätze, die die SQL-Abfrage liefert, zur Verarbeitung. Das Resultset der Datenbankabfrage wird im CSV-Format als Backup-Datei abgelegt. Siehe auch Dokumentenart Datenbank.
(1) Alias für die Verbindung zur Datenbank. Ein Datenbank-Alias ist eine konfigurierte Verbindung zu einem Datenbanksystem (siehe Konfigurationsdatei ./etc/database.xml und Abschnitt DatabaseService). Zusätzlich stehen alle im Profil definierten Variablen mit Präfix MSG_CALL_ zur Auswahl zur Verfügung. Dadurch ist es möglich, den Alias aus einem triggernden Profil oder mit dem HTTP-Aufruf zu übergeben. Hinweis: Im Interesse einer einfachen Prüfbarkeit sollten die Variablen mit einem Defaultwert definiert werden.
(2) SQL-Abfrage, um die Daten aus der Datenbank zu lesen. Es kann nur ein einzelnes SELECT-Statement angegeben werden. Hinweis: Siehe auch System-Variable VAR_TRIGGER_VALUE. Hinweis: Sie können auch Variablen in der Abfrage verwenden, z. B. select * from @MSG_CALL_var__myTableName@ where company=@1:s@. Hinweis: Siehe auch den Platzhalter für den letzten Lauf. Hinweis: Kommentare können nur mit der Syntax /*Kommentar*/ angegeben werden, sonst entsteht ein Fehler.
(3) Führt die SQL-Anweisung (2) testweise aus. Enthält die SQL-Anweisung für die Namen der Spalten einen *, werden aus der Antwort die tatsächlichen Namen der Spalten ausgelesen und in (2) eingetragen.
(4) Die Spalten der SQL-Anweisung werden als Felder unterhalb eines neuen Knotens in der Quellstruktur angelegt. Vorhandene Mappinganweisungen bleiben dabei erhalten. Die Datentypen und Feldlängen der Spalten werden aus der Datenbankdefinition übernommen.
(5) Siehe (6).
(6) Es besteht die Möglichkeit, in der WHERE-Bedingung der SQL-Abfrage auf variable Werte zuzugreifen. Dazu wird der Variablenname in @-Zeichen gestellt. Beispiel: Parameterwert @MSG_CALL_PARAM1@ (siehe Abschnitt HTTP-Request-Parameter) wird der Parameternummer 1 zugewiesen. In (2) kann dann über WHERE ID = @1:s@ auf die String-Variable zugegriffen werden. Details zu dieser Schreibweise finden Sie im Abschnitt DefaultSQLCron (SQLCron). Da die Auswertung der Variablen vor der Phase 3 (Mapping) stattfindet, sind hier nur Variablen sinnvoll, die von einem aufrufenden Profil oder externem Trigger übergeben werden. Ist eine Variable angegeben, die nicht in diesem Profil deklariert wurde, wird der Platzhalter unverändert übernommen.
(7) Bewirkt ein Löschen aller gelesenen Daten der Tabelle. Wenn Isolation-Level Read Committed eingestellt ist, können von einem anderen Programm gleichzeitig Daten eingestellt werden. Achtung: Diese Checkbox sollte nur mit äußerster Vorsicht verwendet werden. Wenn die Anzahl der gelöschten Zeilen ungleich der Anzahl der gelesenen Zeilen ist, wird kein Job gestartet, sondern eine Fehlermail erzeugt.
Mit einer WHERE-Bedingung kann der Löschvorgang optimiert werden. Dabei wird die WHERE-Bedingung aus (2) mit den gleichen Parametern verwendet. Das ist vor allem dann wichtig, wenn die Datentypen nicht exakt übereinstimmen.
(8) Ist diese Checkbox gesetzt, wird der Inhalt von Blob-Datenfeldern (binäre Daten), vor dem Weiterreichen an das Profil, mit Base64 kodiert. Hinweis: Binärdaten können sonst einen Fehler beim Erstellen des Eingangsbaumes verursachen. Eingelesene Felder können mit der Funktion decode Base64(a, b) wieder entschlüsselt werden.
(9) Ist diese Option gewählt, werden dem Profil auch Daten geliefert, wenn die SQL-Abfrage kein Resultset erzeugt. Die Werte aus dem (dann erscheinenden) Eingabefeld werden dem Profil übergeben. Die Daten müssen im CSV-Format vorliegen (Trennzeichen Komma).