Beschreibung

In der Praxis tritt häufig das Problem auf, dass Daten aus verschiedenen Tabellen einer Datenbank ausgelesen werden sollen. Um diese Daten einfach einzulesen, gibt es eine Klasse, die dies einfach ermöglicht. Die Klasse DefaultSQLCron liest aus einer Konfigurationsdatei die auszuführenden SQL-Anweisungen und Abhängigkeiten zwischen den Tabellen aus.

Die auszuführenden SQL-Anweisungen müssen aufsteigend mit einem Namen select.<n> versehen werden. Die Nummern müssen lückenlos vergeben werden, die Nummerierung beginnt mit 0. Zwischen den SQL-Anweisungen werden Abhängigkeiten festgelegt. Diese Festlegungen werden in der Form dependencies.<n>=<s>:<m> getroffen, wobei s für den Index der SQL-Anweisung und m für den Index der Spalte innerhalb der Ergebnismenge und n für den Index der Abhängigkeit steht. Die Abhängigkeit dependencies.1= 0:2 legt fest, dass die SQL-Anweisung select.1 von der zweiten Spalte aus dem Ergebnis von select.0 abhängt. Hier können auch mehrere Spalten angegeben werden, also z. B. dependencies.1= 0:2,0:3.

Wichtiger Hinweis: Da es gerade das erste mal nicht ganz einfach ist die Konfigurationsdatei manuell zu erstellen, kann dies mit dem SQL-Konfigurations-Assistenten gemacht werden.

Hinweis: Die Quellstruktur für die Eingangsdatei kann im Menü der Quellstruktur erzeugt werden.

Parameterbeschreibung

In den WHERE-Bedingungen der select.<n> werden Platzhalter eingesetzt, um die Abhängigkeiten festzulegen. Der Platzhalter @1:i@ wird durch die erste Spalte aus den zugehörigen Abhängigkeiten (dependencies) ersetzt, der Platzhalter @2:i@ durch die zweite Spalte. Das i im Platzhalter steht für den Datentyp, hier Integer. Siehe folgende Tabelle. Es können auch Werte von Variablen verwendet werden. Dabei kann es sich nur um Variablen von vorangegangenen Profilen, oder Parameterwerte von HTTP-Triggern handeln, zudem müssen die Variablen im Profil definiert sein. Wird in der Properties-Datei z. B. MSG_CALL_MYVAR=100 definiert, dann füllt der Werte der Variable den Platzhalter @100:i@. Wichtiger Hinweis: Die Platzhalter-Nummer für Variablen darf nicht kleiner 100 sein.

Hinweis: Es ist auch möglich den Zeitpunkt des letzten erfolgreichen Profilstarts, mittels eines Platzhalters in einer WHERE-Bedingung zu verwenden. Hierzu gibt es drei Möglichkeiten.

• @0:t@ gibt den Zeitpunkt des letzten Profillaufs als Timestamp wieder.

• @0:d@ gibt den Zeitpunkt des letzten Profillaufs als Date wieder.

• @0:s#<template>@ gibt den Zeitpunkt als formatierten String wieder. Beispiel: @0:s#yyyyMMdd@ gibt 20150310 für den 10.3.2015 zurück. Wichtiger Hinweis: @0:s#<template>@ wird nur einmal aufgelöst. Eine weiteres Vorkommen von @0:s#<template>@ mit einem abweichenden Template hat keinen Effekt! Stattdessen wird bei weiteren Vorkommen der gecachte Wert des ersten Vorkommens verwendet.

Beispiel

Wichtiger Hinweis: Nehmen wir an wir hätten eine String-Variable MSG_CALL_MYVAR mit Inhalt 'USA','UK'. Verwenden Sie nun in der unten gezeigten Konfigurationsdatei die Definition MSG_CALL_MYVAR=100, dann würde die SQL-Abfrage SELECT id, name FROM supplier WHERE country IN (@100:s@) nicht funktionieren. Der Grund ist, dass dies nicht aufgelöst wird in SELECT id, name FROM supplier WHERE country IN ('USA','UK'), sondern in SELECT id, name FROM supplier WHERE country IN (''USA','UK''), da der Platzhalter ja einen String repräsentiert. Gelöst werden können solche Abfragen leider nur über die Dependencies, wie unten gezeigt. Der SQL-Konfigurations-Assistent wird Sie dabei unterstützen.

Drei Tabellen (order, item, item_text) sollen ausgelesen werden. Die Tabellen sind jeweils durch 1:n Beziehungen verknüpft. Zu einem Auftrag (order) kann es beliebig viele Positionen (item) geben. Zu einer Position kann es beliebig viele Positionstexte (item_text) geben.

Die Tabelle order:

Die Tabelle item:

Die Tabelle item_text:

Das erste SQL-Statement select.0 wird ausgeführt und dabei die Variable @0:d@ durch das Datum des letzten Profildurchlaufs ersetzt. Nachfolgend das Ergebnis der Datenbank:

Mit der ersten Zeile

des Ergebnis von select.0 werden die dependencies.1 erstellt:

Mit den dependencies.1 wird select.1 ausgeführt:

Aus diesem Ergebnis werden die dependencies.2 erstellt:

Mit den dependencies.2 wird select.2 ausgeführt:

Dann werden die Ergebniszeilen zusammengefasst zum ersten Teilergebnis:

Analog dazu wird mit der zweiten Zeile

des Ergebnis aus select.0 verfahren.

Die dependencies.1 werden erstellt:

Dann liefert select.1:

Die dependencies.2 ergeben:

select.2 für die erste Zeile von dependencies.2 liefert kein Ergebnis. select.2 für die zweite Zeile von dependencies.2 liefert:

Auch diese Ergebniszeilen werden zu einem weiteren Teilergebnis zusammengefasst:

Aus den Teilergebnissen wird das Gesamtergebnis erstellt und an das Profil übergeben:

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

• Aufbau einer Properties-Datei

• DefaultFileSQLCron

• CrossSQLCron

• MultipleSqlCron