Liebe Datenanalysten,

in vielen Fachgebieten lässt sich die Effizienz erheblich steigern, indem man sich auf Änderungen konzentriert. So beschleunigt es etwa den Ladeprozess im Data Warehouse, wenn man nur geänderte und neue Datensätze aufnimmt („Delta Load“); Videofilme komprimiert man digital, indem man nicht alle Einzelbilder vollständig speichert, sondern nur einige Referenzbilder, zu denen man kleinere Differenzbilder berechnet; Gesetzesänderungen diskutieren Juristen und Politiker zügiger, wenn alte und neue Fassung gegenübergestellt und geänderte Passagen markiert sind; und generell ist es im Redaktionsprozess von Fachartikeln, Berichten und vielen anderen schriftlichen Ausarbeitungen gang und gäbe, Änderungen anzustreichen oder durch das Textverarbeitungsprogramm nachverfolgen zu lassen. Auch DeltaMaster verfügt über so eine Änderungslogik: Mit dem Berichtsserver lassen sich Berichte automatisch aktualisieren und verteilen – und Änderungen hervorheben. Das macht dem Leser einiges leichter, dem Redakteur nichts schwieriger. Manchmal ist es so einfach, die Effizienz zu steigern.

Herzliche Grüße
Ihr Team von Bissantz & Company

Für viele operative Anwendungen benötigt man Listen und Auswertungen, die laufend ergänzt und aktualisiert werden. Wenn beispielsweise der Vertrieb zur Hausmesse einlädt und Kunden und Interessenten anspricht, möchte der Vertriebsleiter täglich über den Anmeldestand informiert werden. Die Anmeldeliste wird von Tag zu Tag länger. Damit der Vertriebsleiter sie nicht jedes Mal von Anfang bis Ende durchgehen muss, sollen die jeweils neu hinzugekommenen Anmeldungen hervorgehoben (und die Erfolge des tüchtigen Vertriebsinnendiensts dokumentiert) werden.

Ein Beispiel für einen solchen Bericht zeigt die nebenstehende Abbildung: eine Pivottabelle aus DeltaMaster, als HTML-Mail per Berichtsserver versandt und in Microsoft Outlook geöffnet. Der Bericht leistet zweierlei: Zum einen gibt er den aktuellen Stand vollständig wieder, zum anderen lässt er erkennen, was sich geändert hat – und das ist wichtig, denn die Änderungen benötigen oft mehr Aufmerksamkeit als das, was gleich geblieben ist (und schon vorher Aufmerksamkeit bekommen hat). Solche Anwendungen lassen sich mit dem DeltaMaster Berichtsserver schnell einrichten, wie wir im Folgenden zeigen. Als Beispiel bleiben wir bei den Anmeldungen, die beschriebenen Arbeitsweisen sind jedoch allgemein gültig und eignen sich für viele weitere Einsatzgebiete, wie etwa Kundendienstanfragen (Supportfälle), Fertigungsaufträge oder Einträge aus einem CRM-System. Außerdem ist das Hervorheben von Änderungen auch in Berichten möglich, die nicht „wachsen“ – bei denen die Zeilen und Spalten unverändert bleiben, nur Werte sich ändern.

Exception Reporting – Änderungen als Ausnahmen

Der Schlüssel zur Erkennung von Änderungen ist die Ausnahmeberichterstattung, das sogenannte Exception Reporting. Mit dieser Option lässt sich das Verhalten des Berichtsservers beeinflussen: Für jeden Bericht kann eine Bedingung festgelegt werden, die der Berichtsserver bei der Jobverarbeitung auswertet. Nur wenn die Bedingung erfüllt ist, wird der Bericht in die Ausgabe des Jobs aufgenommen. Sollten alle Berichte einer Berichtsquelle (Analysesitzung oder Anwendung) durch Bedingungen aussortiert sein, so beendet der Berichtsserver seine Arbeit, ohne etwas auszugeben; er generiert dann keine Dateien und versendet keine E-Mails. Anders ausgedrückt: Dateien werden nur dann generiert, E-Mails nur dann versendet, wenn für mindestens einen Bericht die festgelegte Bedingung erfüllt ist (oder mindestens ein Bericht nicht an eine Bedingung geknüpft ist). Dadurch lässt sich der Berichtsserver nutzen, um ereignisgesteuert Benachrichtigungen zu versenden. Ausführlich beschrieben ist der Mechanismus in den DeltaMaster clicks! 11/2008.

Bedingungen

Einrichten lässt sich das Exception Reporting ab der Stufe Pivotizer in den Berichtseigenschaften (Kontextmenü der Berichte in der Berichtsmappe) auf der Registerkarte Exception Reporting. Hier können Sie festlegen, dass der Berichtsserver den Bericht nur dann in das Ergebnis eines Berichtsserver-Jobs aufnehmen soll, wenn eine Bedingung erfüllt ist.

Die Bedingung kann auf dreierlei Weise formuliert werden:

• Über die Anzahl der Zeilen im Bericht. Der wichtigste Anwendungsfall dafür ist, leere Berichte auszusondern: Ein Bericht soll nur berücksichtigt werden, wenn er „mehr als 0 Zeilen“ hat. Diese Variante wird zum Beispiel für Detaillisten zu Abweichungen genutzt: Wenn es keine Abweichungen gibt, soll der gesamte Bericht nicht erzeugt werden. Auch zum individuellen Konfektionieren von Berichtsmappen macht man sich diese Option zunutze: Berichte, die nach Empfänger gefiltert werden, lassen sich zurückhalten, wenn sie durch das Filtern leer werden; der Empfänger bekommt dann nicht einen leeren Bericht, sondern sieht den Bericht erst gar nicht. Die Option ist für Pivottabellen und überwiegend tabellarische Berichtstypen gedacht, zum Beispiel SQL-Durchgriff, Rangfolge oder PowerSearch.
• Mithilfe eines MDX-Ausdrucks. Nur wenn die MDX-Bedingung „true“ zurückliefert, wird der Bericht in das Ergebnis des Berichtsserver-Jobs aufgenommen. MDX ermöglicht es, Kriterien einzubeziehen, die sich nicht in der Länge des Berichts niederschlagen, womöglich dem Bericht nicht einmal zu entnehmen sind. Die MDX-Bedingung kann für alle Berichtstypen verwendet werden. Bei einigen ist sie die einzige Option, bei jenen nämlich, für die sich keine allgemein sinnvolle Zeilenanzahl bestimmen lässt, zum Beispiel Kombinationscockpits.
• Als Vergleich, ob in dem vom Berichtsserver berechneten Ergebnis Änderungen gegenüber dem letzten Durchlauf enthalten sind. Diese Option ist ebenfalls für alle Berichtstypen verfügbar. Bei Pivottabellen und Berichten aus dem SQL-Durchgriff können auf Wunsch die geänderten Tabellenzellen hervorgehoben werden, je nach Ausgabeformat.

Für unsere Aufgabenstellung ist die dritte Option die richtige: Der Berichtsserver soll überprüfen, ob sich die Anmeldeliste geändert hat, und gegebenenfalls die Änderungen hervorheben. Dazu genügt es, die Option in den Berichtseigenschaften zu aktivieren; im Berichtsserver ist keine Anpassung erforderlich.

Aktualisierung der Berichtsquelle

Wie erkennt nun der Berichtsserver, ob sich etwas geändert hat? Er berechnet den Bericht mit „frischen“ Daten neu und vergleicht das Ergebnis dieser Berechnung mit dem Ergebnis, das in der Analysesitzung (DAS-Datei) gespeichert ist. Stimmen die Ergebnisse überein, so hat sich offensichtlich nichts geändert und der Bericht wird nicht in die Ausgabe des Jobs aufgenommen. Falls insgesamt keine Berichte in die Ausgabe des Jobs aufzunehmen sind, erzeugt der Berichtsserver keine Ausgabe, wie oben erläutert. Es kann also die Benachrichtigung auch einmal ausbleiben: wenn es nichts Neues zu berichten gibt.

Sofern für mindestens einen Bericht die Änderungserkennung aktiviert ist, wird die Analysesitzung, die als Berichtsquelle ausgewählt ist, bei jedem Durchlauf des Jobs neu berechnet und in dieselbe DAS-Datei zurückgeschrieben. Das ist ein wichtiger Unterschied zum sonstigen Verhalten des Berichtsservers: Normalerweise wird die Berichtsquelle vom Berichtsserver nicht verändert. Wenn es jedoch auf Änderungen ankommt, aktualisiert der Berichtsserver bei jedem Durchlauf die Berichtsquelle. Deshalb darf die DAS-Datei nicht schreibgeschützt sein. Anwendungen im Repository sowie DM2GO-Dateien werden derzeit nicht unterstützt, die Behandlung von Änderungen ist nur für DAS-Dateien vorgesehen.

Formatierung

Werden Änderungen erkannt und sollen diese hervorgehoben werden, so färbt DeltaMaster den Hintergrund der betreffenden Zellen gelb, sofern die Ausgabeformate dies unterstützen. In den Formaten von Microsoft Office (Word, Excel, PowerPoint), bei PDF-Dokumenten sowie bei HTML-Dateien und ?Mails ist die Formatierung möglich. Bei Berichten aus dem SQL-Durchgriff können Sie den Berichtsinhalt als Text ausgeben (anstatt den Bericht als Bild in das HTML-Dokument einzubetten). In diesem Fall können Sie mithilfe von CSS Einfluss auf die Formatierung nehmen (siehe DeltaMaster deltas! 5.6.1, Punkt 1b).

See & Go

Wenn die Liste per E-Mail verschickt wird, kann man dem Empfänger einen besonderen Dienst erweisen und die wichtigsten Zahlen schon in der Betreffzeile (im Subject) angeben, nämlich: wie viele Einträge (im Beispiel: Anmeldungen) es jetzt insgesamt sind, wie viele im Vergleich zur letzten Auflage des Berichts hinzugekommen und wie viele entfernt worden sind.

Auf diese Weise zu berichten, ist besonders effizient: Kaum einen Informationskanal verfolgt man so intensiv wie den elektronischen Posteingang und die Betreffzeile ist das erste, was der Empfänger von einer E-Mail wahrnimmt. Trotzdem wird dieser Kanal meist immer noch schlecht genutzt. Allzu oft enthält das Subject lediglich die Ankündigung einer Information („Anmeldungen zur Hausmesse“) anstatt tatsächlich eine Information („Hausmesse: 41 Anmeldungen, 5 neu, 0 weg“). In den DeltaMaster clicks! 06/2013 zeigen wir, wie Sie zu besseren Betreffzeilen kommen, indem Sie mit Variablen automatisch Werte aus Berichten herausgreifen und in die Betreffzeile übernehmen.

Für Änderungen in Berichten stehen drei spezielle Variablen zur Verfügung:

Darin steht „X“ für die Id des Berichts, dessen Länge oder Längenänderung angegeben werden soll. Die Id entnehmen Sie den Berichtseigenschaften oder dem Tooltip, der erscheint, wenn Sie in der Berichtsmappe mit gedrückter Alt-Taste auf einen Bericht zeigen. Voraussetzung ist, dass der Bericht auf einer Pivottabelle oder dem SQL-Durchgriff basiert.

Die Variablen können Sie im E-Mail-Betreff, im E-Mail-Text sowie im E-Mail-Anhang verwenden. Beim Versand der Nachricht werden sie durch die entsprechenden Werte ersetzt.