Wie im vorangegangen Blogbeitrag Exception Reporting mit DeltaMaster dargestellt, lässt sich durch eine geschickte Kombination von DeltaMaster und Berichtsserver ein Exception Reporting sowohl in multidimensionalen, als auch in relationalen Modellen abbilden. Ist die Konfiguration eines solchen Reportings im multidimensionalen Umfeld weitgehend intuitiv und per toolgesteuerten Dialogen durchzuführen, so erfordert die relationale Umgebung ein wenig mehr Handarbeit. Und genau diese Handarbeit soll im Folgenden um ein paar weitere Schritte ergänzt werden.

Parametrierung des Berichtsserver-Jobs

Um den Bedarfsfall eines solchen Ausnahmeberichts zu modellieren, sind die Bereiche SQL-Aktualisierungs-Befehl und Berichtsgenerator die Einstellungsmittel der Wahl. Ist der gewünschte Job mit der entsprechenden Ausgabe erstellt, so sollte sich der Inhalt des Berichtsgeneratorelements individuell an die Ausnahme anpassen, oder eben nicht. Ganz wörtlich ist hier der Freitext über dem Berichtsgeneratorenbereich zu nehmen: „Neue Berichte generieren für…“, denn genau an dieser Stelle erstellen wir den Ausnahmeindikator. Ist der Bereich mit Elementen gefüllt, werden Berichte erstellt und publiziert. Bei einer leeren Ergebnismenge wird der Job zwar ausgeführt, liefert jedoch kein Ergebnis zurück.

Um die etwas technisch anmutende Syntax von Hierarchie’ElementID‘ (vgl. Abb. 1) automatisiert abbilden zu können, ist der SQL-Aktualisierungs-Befehl vonnöten.

Abb. 1: Berichtsgeneratorelement im Berichtsserver

Auswahl des richtigen Generatorelements

Wie auch in OLAP-Modellen, kann mittels dieses SQL-Aktualisierungs-Befehls direkt auf den relationalen Inhalt von Berichtssevrer-Jobs eingewirkt werden. In diesem speziellen Fall ist dies zunächst die Berichtsservertabelle Iterator. In dieser werden die Elemente des Berichtsgenerators gespeichert. Um nun ein vernünftiges, relationales Exception Reporting aufbauen zu können, benötigen wir eine Ergebnismenge, welche nur unter bestimmten Bedingungen Datensätze zurückliefert. Beispielsweise eine View, welche genau die Niederlassungen zeigt, deren Planeingabe noch nicht vollständig erfolgt ist.

SELECT
       NiederlassungID
FROM
       V_Eingabeprüfung
WHERE
       Anzahl_Planeingaben < 1

Die somit erhaltenen IDs müssten nun möglichst variabel und automatisiert in die Elementauswahl des Berichtsserver-Jobs geschrieben werden. Hierfür empfiehlt sich das Anlegen einer eigenen Pro-zedur in der Berichtsserver-Datenbank. Diese soll die Ergebnismenge der View in das Format der relationalen Elementauswahl bringen und in die Iteratortabelle zurückschreiben. Hierbei sollte auch eine mögliche Konkatenation der Elemente berücksichtigt werden für den Fall, dass mehrere Niederlassungen pro Durchlauf ihre Planeingaben noch nicht vollständig durchgeführt haben.

In mehreren Projekten hat sich folgender Aufbau bewährt:

Hierbei ist wichtig, dass in der @sql- Variablen die IteratorID verwendet wird, welche der zugeordneten Nummer des Berichtsserver-Jobs entspricht.

Aufruf der Prozedur

Um vor jedem Aufruf des Jobs diese Liste der Elemente zu aktualisieren, muss die Prozedur dem Job zugeordnet und im Bereich SQL-Aktualisierungs-Befehl aufgerufen werden.

Abb. 2: SQL-Aktualisierungs-Befehl im Berichtsserver-Job

Je nachdem, welche Elemente nach der Aktualisierung im Bereich des Generatorenelements ausgewählt sind, wird der Ausgabebericht des Jobs entweder an mehrere Niederlassungen, eine Niederlassung oder keine Niederlassung verschickt.