Einstellungen

(1) DB Alias: Alias für die Verbindung zur Datenbank (auswählbar über Icon rechts). Ein Datenbank-Alias ist eine konfigurierte Verbindung zu einem Datenbanksystem. Siehe Abschnitt Datenbanken/Connectoren (Verwaltung). 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 Timeout: Timeout für (6).

(3) Tables/Procedures/Views: Zeigt alle Tabellen und Prozeduren für den ausgewählten Alias (1) an.

(4) SQL Wizard: Ein einfacher Wizard, mit dem das SELECT-Statement (6) erzeugt werden kann.

(5) SQL Parameter anzeigen: Um (7) anzuzeigen.

(6) SQL: SQL-Abfrage, um die Daten aus der Datenbank zu lesen. Es kann nur ein einzelnes SELECT-Statement angegeben werden. Kommentare können nur mit der Syntax /*Kommentar*/ angegeben werden, sonst entsteht ein Fehler. Über das Kontextmenü können Abfragen gespeichert werden und gespeicherte Abfragen ausgewählt werden. Zur Verwaltung der Abfragen gibt es einen weiteren Dialog. Sie können in der Abfrage Variablen (Syntax @MSG_CALL_MYVAR@), System-Konstanten (Syntax %MYCONST%), Parameter (siehe (7) für Syntax) und Platzhalter für den Zeitstempel des letzten Laufs des Profils verwenden. Zudem sind permanente Profil-Werte erlaubt (Syntax %perm:KEYNAME%).

Bei der Verwendung von Variablen ist zu beachten, dass hier nur MSG_CALL_-Variablen Sinn machen, weil nur diese in Phase 1 initialisiert sind. Zudem müssen diese Variablen im Profil auch angelegt sein. Ein praktisches Anwendungsbeispiel wäre die Verwendung von HTTP-Request-Parametern in der SQL-Abfrage, also z. B. @MSG_CALL_PARAM1@. Eine weitere Möglichkeit ist die Übergabe von Werten von vorgelagerten Profilen in Profil-Ketten. Beispiele:

SELECT * FROM @MSG_CALL_MYTABLE@

SELECT * FROM %MY_TABLE_CONST%

SELECT * FROM orders WHERE order_no=@MSG_CALL_PARAM1@

SELECT * FROM products WHERE id=@1:s@

SELECT * FROM city WHERE zip=%perm:zip%

Die Platzhalter für den Zeitstempel des letzten Laufs des Profils sind @0:t@ (kompletter Zeitstempel), @0:d@ (nur das Datum) und @0:s#<template>@ (formatierter String des Zeitstempels). Der Zeitstempel wird mit jedem Lauf des Profils aktualisiert, aber nur, wenn der Platzhalter in der Abfrage verwendet wird. Der Zeitstempel wird dann auch aktualisiert, wenn der Cronjob lief, aber kein Job generiert wurde. Nur, wenn es zu einem Fehler in Phase 1 kam, wird der Zeitstempel nicht verändert. Beispiele:

SELECT * FROM orders WHERE act_time > @0:t@

SELECT * FROM orders WHERE act_time > @0:d@

SELECT * FROM orders WHERE act_time > @0:s#yyyyMMdd@

(7) Fenster rechts (SQL-Parameter): Wird nur angezeigt, wenn (5) gesetzt ist. Hier können Sie (über das Kontextmenü) Parameter definieren, die im WHERE-Teil der Abfrage benutzt werden können.

Die Werte dieser Parameter können Festwerte sein, Variablen (Syntax @MYVAR@), System-Konstanten (Syntax %MYCONST%) und permanente Profil-Werte (Syntax %perm:KEYNAME%). Siehe Auswahlmenü in GUI.

Die Platzhalter für diese Parameter haben die Syntax @<Parameternummer>:<Datentyp>@, also z. B. @1:s@. Erlaubte Datentypen:

Zudem stehen ein paar spezielle Platzhalter für den letzten Lauf des Profils zur Verfügung.

Bei der Verwendung von Variablen als Parameterwert ist zu beachten, dass hier nur MSG_CALL_-Variablen Sinn machen, weil nur diese in Phase 1 initialisiert sind. Zudem müssen diese Variablen im Profil auch angelegt sein. Ein praktisches Anwendungsbeispiel wäre die Verwendung von HTTP-Request-Parametern in der SQL-Abfrage, also z. B. @MSG_CALL_PARAM1@. Eine weitere Möglichkeit ist die Übergabe von Werten von vorgelagerten Profilen in Profil-Ketten.

Beispiel:

Param-Nr: "1".

Wert: "@MSG_CALL_PARAM1@".

(8) Timeout: Timeout für (9) und (10).

(9) SQL testen: Führt die SQL-Anweisung (6) 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 (6) eingetragen.

(10) Struktur erzeugen: 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.

(11) Daten löschen: 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 (6) mit den gleichen Parametern verwendet. Das ist vor allem dann wichtig, wenn die Datentypen nicht exakt übereinstimmen.

(12) Blob Felder sind Base64 kodiert: 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, [c]) wieder entschlüsselt werden.

(13) Ersatzwerte bei leerem Ergebnis verwenden: 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).

Leerzeichen im Abfrage-Ergebnis (MSSQL/Informix)

Bei MSSQL- und Informix-Datenbanken werden die Ergebniswerte von SQL-Aufrufen per Default um voranstehende und nachfolgende Leerzeichen bereinigt (trimmed). Mit dem Parameter skipTrimResultValues kann in der Konfigurationsdatei des Datenbank-Aliases dieses Verhalten geändert werden.

Siehe auch

• Business Connector (Eingangsagent Cron)