Der Berichtsserver als Zusatzkomponente von DeltaMaster übernimmt die Aktualisierung, Veränderung, Vervielfältigung und das Verteilen von Analysesitzungen, Berichtsmappen oder Berichten in den unterschiedlichsten Formaten – automatisiert. Wenn beispielsweise die Vertriebsleiter regelmäßig über die Kundenzahlen ihrer Region informiert werden möchten, wird ein entsprechender Bericht einmalig in einer Analysesitzung erstellt und ein Berichtsserver-Job angelegt, der an jedem Monatsersten die Zahlen aktualisiert, über die einzelnen Vertriebsleiter iteriert und den frischen Bericht per E-Mail versendet.
Beim Exception Reporting soll ein derartiger Bericht nur dann erzeugt werden, wenn sich eine Ausnahmesituation ergibt. Der regelmäßige Berichtsversand wird dann unregelmäßig. Beispielsweise, wenn es Kunden in einer Vertriebsregion gibt, die am Monatsende noch keine Bürostuhlbestellung aufgegeben haben, oder wenn es Mitarbeiter gibt, die kurz vor Ende der Planungsrunde noch nicht alle Planzahlen erfasst haben. Wie Exception Reporting in multidimensionalen und relationalen Modellen eingerichtet wird, zeigt dieser Blogbeitrag.
Berichte unregelmäßig versenden
Damit ein Bericht nur unregelmäßig, also in Ausnahmefällen, versendet wird, sind sowohl in OLAP- als auch in relationalen Modellen zwei Dinge Voraussetzung:
- Es muss festgelegt werden, von welcher Bedingung ein Berichtsversand abhängig ist. Im obigen Beispiel sind „Kunden ohne Absatz“ bzw. „Mitarbeiter mit unterschrittener Anzahl Planeingaben“.
- Die Bedingung muss regelmäßig in einem zeitgesteuerten Berichtsserver-Job überprüft werden.
Vorgehensweise in OLAP-Modellen
Bedingungen festlegen
Abb. 1 zeigt einen Bericht aus unserer Demoanwendung Chair: Diese Kunden des Vertriebsleiters Hohlmeier haben im Mai 2012 keinen Absatz gemacht. Die Bedingung ist in Abb. 2 definiert: gefiltert wird nach den Kunden, deren Analysewert Absatz gleich 0 ist.
Abb. 1: Kunden von Vertriebsleiter Hohlmeier ohne Absatz im Mai 2012
Abb. 2: Filter nach Analysewert Absatz mit Bedingung Absatz = 0
Sobald Kunde Grossmann Absatz macht, wird dieser größer 0 und der Kunde verschwindet aus der Liste. Machen alle Kunden Absatz, enthält der Bericht 0 Zeilen.
Berichtsserver-Job einrichten
Im Berichtsserver legt man einen Job an, der den Vertriebsleitern eine Auflistung ihrer Kunden per
E-Mail schicken soll.
Als Berichtsformat wählt man z. B. html und als Verteilungsart mail; als Empfänger adressieren wir per @IDA die Adresse des aktuellen Geneneratorelements (E-Mail-Adressen sind in der Chair-Demo im Attribut „E-Mail“ in der Vertriebsdimension hinterlegt). Das Berichtsupdate bestimmen wir dynamisch per MDX, sodass der Bericht immer die Werte des aktuellen Monats zeigt (strtomember(“[Periode].[Periode].[Monat].&[“+format(now(), “yyyyMM”)+”]”)). Als Berichtsordner wählen wir den Ordner aus, in dem unser Bericht mit der Bedingung gespeichert ist. Beim Berichtsgenerator wählen wir die einzelnen Vertriebsleiter aus.
Exception Reporting aktivieren
Der Vertriebsleiter, der keinen Kunden ohne Absatz hat, soll den Bericht nicht erhalten. Dazu haben wir in der Bedingung in Abschnitt 2.1 bereits sichergestellt, dass der Bericht dann keine Zeilen enthält. In den Berichtseigenschaften definiert man zusätzlich, dass der Bericht in das Ergebnis eines Berichtsserver-Jobs nur aufgenommen werden soll, wenn er mehr als 0 Zeilen enthält (vgl. Abb. 3).
Der Berichtsserver-Job iteriert also, wie in Abschnitt 2.2 beschrieben, über alle Vertriebsleiter (Berichtsgeneartor), lässt aber über die Exception-Reporting-Eigenschaft diejenigen aus, deren Bericht 0 Kunden (Zeilen) aufweist.
Alternativ kann auch eine beliebige MDX-Bedingung ausgewertet werden, z. B. wenn Flexreports oder Kombicockpits zum Einsatz kommen; der Bericht wird dann in das Ergebnis des Berichtsserver-Jobs aufgenommen, wenn der Ausdruck zu „true“ ausgewertet werden kann.
Abb. 3: Einstellungen zum Exception Reporting in den Berichtseigenschaften
Vorgehensweise in relationalen Modellen
Auch hier ist die Basis wieder ein Bericht. Beispielhaft sollen alle Planer, die ihre Daten noch nicht oder noch nicht vollständig eingegeben haben, per E-Mail vom Berichtsserver informiert werden. Die Datensätze der Planeingabe werden gezählt und sind im relationalen Beispielmodell in der Kennzahl „Anzahl_Planeingaben“ modelliert. Der Schwellwert liegt bei 30.
Bedingungen einrichten
Ähnlich wie beim OLAP-Modell wird auch hier der Bericht aufgebaut, der diejenigen Planer als Elementliste zeigt, deren Eingaben noch nicht oder noch nicht vollständig sind. Die Anzahl der Zeilen ist damit abhängig vom Analysewert Anzahl_Planeingaben, der im Bericht aber nicht angezeigt werden soll.
Abb. 4: Liste der Planer mit unvollständigen Planeingaben
In der Achsendefinition von relationalen Dateneingabeanwendungen ist es möglich, eine SQL-Abfrage für eine Elementliste abzusetzen (vgl. Abb. 5). Außerdem kann die Synchronisation mit der Sicht statisch gesetzt werden: die Anzahl der Zeilen ist dann unabhängig von der Sichteinstellung der Planerdimension. Zur besseren Lesbarkeit folgt das SQL-Statement für diesen Beispielfall. Dabei enthält die Tabelle T_D_Anzahl_Planeingaben die Bewegungsdaten, die Tabelle T_DIM_06_01_Planer die Strukturdaten für die Planerdimension.
Abb. 5: SQL-Abfrage für Elementliste in Achsendefinition
Berichtsserver-Job einrichten
Im Berichtsserver legt man einen Job an, der den Planern nur dann einen Bericht mit ihren aktuellen Eingaben schickt, wenn diese unvollständig sind.
Als Berichtsformat wählt man z. B. html und als Verteilungsart mail; als Empfänger adressieren wir per @IDA die Adresse des aktuellen Geneneratorelements (E-Mail-Adressen sind in der relationalen Demo im Attribut „E-Mail“ in der Planerdimension hinterlegt).
Das Berichtsupdate kann in relationalen Modellen nicht per MDX erfolgen. Eine automatische Aktualisierung, z. B. auf den aktuellen Monat, ist dennoch möglich, muss aber im Berichtsserver-Job in einer Prozedur gekapselt werden. Diese Prozedur, deren Aufruf im Berichtsserver-Job unter „SQL-Aktualisierungsbefehl“ eingegeben wird, muss im vorliegenden Beispiel die Tabelle [dbo].JobPeriod von der Berichtsserver-Datenbank modifizieren. Dies muss zur Laufzeit des Jobs passieren.
Der Auszug der Tabelle zeigt das vom Berichtsserver benötigte Format für das Berichtsupdate-Element.
Abb. 6: Auszug aus Tabelle JobPeriod der Berichtsserver-Datenbank
Die erste Zeile zeigt den Berichtsupdate-Befehl aus Abschnitt 2.2. Die zweite Zeile zeigt den Berichtsupdate-Befehl des relationalen Modells (Spalte UpdatePeriod) im Format [LevelID]‘[ElementID]‘. Im Beispiel sehen wir also, dass der Bericht für die Periodendimension (DimensionID 2) im zweiten Level auf das Element ‚201401‘ (entspricht Januar 2014) aktualisieren soll.
Der Berichtsgenerator muss, ähnlich wie das Berichtsupdate, ebenfalls eine Tabelle in der Berichtsserver-Datenbank aktualisieren, nämlich die Tabelle [dbo].[Iterator].
Der Auszug der Tabelle zeigt das vom Berichtsserver benötigte Format für das Berichtgenerator-Element.
Die erste Zeile zeigt die ausgewählten Elemente des OLAP-Modells. Die zweite Zeile zeigt die für das relationale Modell ausgewählten Elemente (Spalte MemberExpr) im Format [LevelID]‘[ElementID]‘, wobei mehrere Elemente komma-separiert werden. Die Adresse des Berichtsempfängers findet sich in der Spalte DistributionAdresse im Format [LevelID]|[ElementID].
Exception Reporting aktivieren
In der Analysesitzung bzw. im Bericht selbst ist in relationalen Modellen keine Einstellung für Exception Reporting möglich. Die Tatsache, dass der Berichtsserver-Job nur ausgeführt wird, wenn der Bericht mehr als 0 Zeilen enthält, wird durch den Berichtsgenerator sichergestellt: soll der Bericht für niemanden erzeugt werden (haben also alle Planer Ihre Eingaben vollständig getätigt), bleibt die Spalte MemberExpr der Tabelle [dbo].[Iterator] leer und der Bericht wird für niemanden erzeugt.
