Personalisierte E-Mails mit dem Berichtsserver versenden

Liebe Datenanalysten,

„liebe Datenanalysten“ – so begrüßen wir Sie in diesem Rundschreiben nunmehr zum 85. Mal. Eine Anrede für eine ganze Leserschar: Das ist angemessen und treffend, wenn die Mitteilung tatsächlich an eine ganze Schar von Lesern gerichtet ist und nicht persönlich an Einzelne. Und, zugegeben, eine Personalisierung der DeltaMaster clicks! zöge auch einigen technischen Aufwand nach sich. Wenn Sie Ihre Controllingergebnisse mitteilen, haben Sie es oft mit beiden Empfängerkreisen zu tun: Manches geht identisch an eine größere Anzahl von Empfängern, manches wird für jeden einzelnen erstellt, zum Beispiel, um nur über das spezifische Vertriebsgebiet zu berichten oder die Kostenstelle oder die „Business Unit“, für die der Empfänger verantwortlich ist. Mit DeltaMaster stehen Ihnen leistungsfähige Mechanismen zur Verfügung, die wiederkehrenden Aufgaben im Berichtswesen zu automatisieren. Der Berichtsserver beispielsweise hat sich bestens bewährt, um dutzende, hunderte, tausende von Empfängern mit Informationen über ihren Verantwortungsbereich zu informieren. Jeden einzelnen. Ohne großen Aufwand. Und dabei muss nicht einmal die persönliche Anrede auf der Strecke bleiben. Vorschläge für solche Lösungen finden Sie, liebe Datenanalysten, auf den folgenden Seiten.

Herzliche Grüße
Ihr Team von Bissantz & Company

Besonders bei Aufgaben, die sich mit wenig Variation wiederholen, lohnt es sich zu prüfen, ob sie sich automatisieren lassen. Eine solche Aufgabe ist das Standardreporting: Regelmäßig müssen die gleichen Berichte aktualisiert und den gleichen Empfängern zugestellt werden. Viele DeltaMaster-Anwender erledigen das mit dem Berichtsserver, einer Zusatzkomponente für DeltaMaster, die Routinetätigkeiten im Reporting automatisiert.

Trotz der Routine, trotz der Automation muss es dabei nicht unpersönlich zugehen. Wir wollen im Folgenden einige Ansätze vorstellen, wie Sie mit dem Berichtsserver Ihre Empfänger persönlich erreichen und ansprechen. Insbesondere geht es uns darum, wie personalisierte Berichte per E-Mail verteilt werden – und wie Sie die sachlichen Geschäftszahlen mit Höflichkeit und Verbindlichkeit übermitteln, wie es zum Glück noch immer gute Sitte ist.

Als Beispiel dient uns erneut unser Referenzmodell „Chair“. Darin findet sich eine Dimension für die Kunden. Wir nehmen an, dass jede Vertriebsregion einem Regionalleiter untersteht; den wollen wir per E-Mail regelmäßig informieren, zum Beispiel über seine wichtigsten Kunden im letzten Monat. Dazu haben wir die folgenden Fragen zu klären:

• Wo speichern wir persönliche Angaben über die Empfänger, zum Beispiel die Namen unserer Regionalleiter, die Anreden und E-Mail-Adressen?

• Wie verwenden wir diese Angaben in DeltaMaster und im Berichtsserver?

• Wie verwenden wir die persönlichen Angaben in den E-Mails, die der Berichtsserver verteilt?

Dabei erweist sich ein Konzept von multidimensionalen Datenbanken als sehr nützlich: die sogenannten Elementeigenschaften (Attribute, Member Properties). Aber der Reihe nach.

Gewusst wer

Damit der Berichtsserver seine Ergebnisse auf die Empfänger zuschneiden kann, sind ein paar Angaben über den Empfänger erforderlich. Oft genügen schon wenige Attribute, insbesondere diese vier: der Name des Berichtsempfängers, die Anrede, die E-Mail-Adresse und eventuell ein Ablageverzeichnis, in dem erzeugte Berichtsdateien gespeichert werden. Mit diesen Informationen ist der Berichtsserver in der Lage, Berichte für einzelne Empfänger zu erzeugen, zu versenden, abzulegen – und den Empfänger in einer E-Mail persönlich anzusprechen.

Woher nimmt der Berichtsserver diese Informationen über den Berichtsempfänger? Bei integrierten Lösungen, wie wir sie im Business Intelligence anstreben, empfiehlt es sich, sie als Elementeigenschaften in das zugrunde liegende Datenmodell aufzunehmen. Damit sind sie an einer Stelle zentral zu pflegen und können sehr flexibel in DeltaMaster-Anwendungen verwendet werden.

Elementeigenschaften im Datenmodell

Nicht in allen Anwendungen ist der beschriebene Anwendungsfall von Anfang an vorgesehen, sodass die benötigten Elementeigenschaften im Modell vielleicht noch nicht vorhanden sind. Sie zu ergänzen, macht keine große Mühe, wenn das Datenmodell mit dem DeltaMaster Modeler oder dem DeltaMaster TableWizard/CubeWizard erzeugt wurde.

Im DeltaMaster Modeler legt man in den „Level Attributes“ die gewünschten Eigenschaften an, in den „Level Attributes Source Columns“ trägt man ein, in welcher Tabelle und welcher Spalte des relationalen Modells die Eigenschaftswerte zu finden sind.

Im DeltaMaster TableWizard ist das noch einfacher, weil die Anpassung direkt aus der Datenansicht heraus vorgenommen werden kann. Abgebildet ist eine vereinfachte Version des „Chair“-Modells. Es unterscheidet nicht zwischen Fakt- und Dimensionstabelle, die persönlichen Daten sind in der „flachen“ Tabelle enthalten. Über das Kontextmenü lassen sich so Elementeigenschaften anlegen. Mit den kaskadierenden Menüs bestimmt man, zu welcher Dimension und Dimensionsebene die Eigenschaft gehören soll. Dieses vereinfachte Modell verwenden wir im Folgenden.

Diese Einrichtung ist nur einmal vorzunehmen. Danach lassen sich die empfängerspezifischen Merkmale so verwalten, wie man es auch mit anderen Stammdaten tun würde.

Elementeigenschaften in DeltaMaster

Als Ergebnis einer solchen Modellierung stehen die Eigenschaften in der Analysesitzung von DeltaMaster zur Verfügung. Im Dimensionsbrowser werden sie als Alias angeboten.

Auf der Registerkarte Eigenschaften sind die Eigenschaften mitsamt ihren Werten nebeneinander einzusehen, sodass man sich schnell einen Überblick verschaffen kann.

In den Berichten, Cockpits und Analysen von DeltaMaster lassen sich die Eigenschaftswerte auf vielfältige Weise nutzen, zum Beispiel als zusätzliche Spalten in Tabellen mit weiteren Angaben zu den Produkten, Kunden, Niederlassungen usw., über die berichtet wird. Darauf soll es uns hier aber nicht ankommen – uns interessiert, wie wir die Elementeigenschaften zur Personalisierung im Berichtsserver nutzen können.

Berichtsgenerator

Im Berichtsserver werden Aufgabenpakete als sogenannte Jobs erfasst. Sie können von Hand oder automatisch gestartet werden, zum Beispiel zeitgesteuert. Für Wiederholungen innerhalb eines Jobs ist der Berichtsgenerator zuständig, ein Feld links unten im Anwendungsfenster des Berichtsservers. Seine Aufgabe ist es, neue Berichte für jedes der ausgewählten Elemente zu generieren – in unserem Beispiel also für die Regionalleiter in den beiden Regionen Nord und Süd. Die Elemente, für die jeweils Berichte erzeugt werden sollen, wählt man mit dem bekannten Dimensionsbrowser aus; alternativ könnte man auch einen MDX-Ausdruck eingeben. Bei der Ausführung des Jobs berechnet der Berichtsserver die Analysesitzung, die als Vorlage dient, sukzessive für jedes Element dieser Menge. Das bedeutet, grob gesprochen: Die Berichtsquelle (die Analysesitzung, auf der der Job basiert) wird geöffnet, für jeden Bericht darin wird die Sicht intern auf das aktuelle Element gestellt und der Bericht damit berechnet. Das Ergebnis dieser Berechnungen schreibt der Berichtsserver in eine eigene Datei. Diese Schritte führt er nacheinander für alle angegebenen Elemente aus und erzeugt so eine Reihe von „Zieldokumenten“, für jeden Empfänger eines.

Für unser Thema ist das Berichtsgenerator-Feld Adresse besonders von Bedeutung. In dieser Auswahlliste sind alle Elementeigenschaften der Quelldimension/Hierarchie aufgeführt. Damit teilen wir dem Berichtsserver mit, in welcher Elementeigenschaft die Adresse für den Berichtsversand zu finden ist; im Beispiel „Regionalleiter_Mail“ auf der Ebene „Region“.

Bei der Bezeichnung „Adresse“ denkt man schnell und zu Recht an eine E-Mail-Adresse, wie auch in unserem Beispiel. Man könnte damit aber auch andere Texte transportieren, die dazu dienen, die zu erzeugenden Berichte voneinander zu unterscheiden oder zu verteilen, zum Beispiel ein Namenskürzel, das an den Dateinamen anzuhängen ist, oder ein Benutzerverzeichnis auf einem Fileserver.

Variablen des Berichtsgenerators

Bei der Ausführung des Jobs nimmt sich der Berichtsserver der Reihe nach jedes ausgewählte Element einzeln vor. Auf das Element, das gerade an der Reihe ist, kann man in der Jobdefinition mit Variablen Bezug nehmen. Das ist zum Beispiel für die E-Mail-Adresse wichtig: Sie ist ja im Datenmodell gespeichert und muss im Berichtsserver in das Feld Adresse in der Jobdefinition übernommen werden. Das leisten die Variablen.

Für die in diesen clicks! vorgestellten Zwecke sind vor allem diese Variablen relevant:

Diese Platzhalter müssen Sie nicht auswendig kennen; sie werden in einem „Tooltipp“ angezeigt, wenn Sie mit der Maus zum Beispiel auf das Feld Adresse zeigen.

Die Variablen machen die Empfängerdaten aus dem Datenmodell im Berichtsserver-Job zugänglich. Wenn der Berichtsgenerator das erste Element behandelt, in unserem Beispiel „Nord“, dann ist „@IMN“ mit dem Namen dieses Elements belegt, also mit „Nord“.

Die Variable „@IDA“ ist mit dem Wert der Elementeigenschaft belegt, die im Feld Adresse des Berichtsgenerators ausgewählt wurde, in unserem Beispiel also mit dem Wert der Eigenschaft „Regionalleiter_Mail“; für das Element „Nord“ ist das „nils.neumann@example.com“.

Zusätzliche Empfänger, die die E-Mail als Kopie oder als Blindkopie erhalten sollen, geben Sie mit dem vorangestellten Zusatz „CC:“ bzw. „BCC:“ und durch Kommas getrennt in das Feld Adresse ein, zum Beispiel „@IDA, CC:vertriebsleitung@example.com, BCC:reporting@example.com“.

Auf diese Weise lässt sich die Versandadresse dynamisch und empfängerabhängig aus dem Datenmodell übernehmen.

Auch der Name des Generatorelements wird häufig benötigt, vor allem dann, wenn der Berichtsserver keine E-Mails direkt versenden, sondern zum Beispiel PDF- oder Word-Dateien in Serie exportieren und in einem bestimmten Verzeichnis ablegen soll. In diesem Fall bietet es sich an, mithilfe der Variablen „@IMN“ den Dateinamen anzupassen; andernfalls würden sich die Exportdateien gegenseitig überschreiben bzw. bekämen Namen, die sich nur in einer automatisch hochgezählten Nummer unterscheiden, die an den Namen angehängt wird. In unserem Beispiel würde die Adresse „C:DeltaMaster ExportVertriebsberichte @IMN.doc“ zu den beiden Namen „Vertriebsberichte Nord.doc“ und „Vertriebsberichte Süd.doc“ aufgelöst.

Die Variablen werden nicht nur im Feld Adresse unterstützt, sondern auch in den Feldern E-Mail-Betreff, E-Mail-Text und E-Mail-Anhang. Falls wir also im Subject der E-Mail kenntlich machen wollen, wen oder was die beiliegenden Berichte betreffen, könnten wir als E-Mail-Betreff „Vertriebsberichte @IMN“ angeben und erhielten die beiden Betreffzeilen „Vertriebsberichte Nord“ und „Vertriebsberichte Süd“.

Zugriff auf alle Elementeigenschaften

Auch für die anderen Elementeigenschaften gibt es eine Variable, wie in der Tabelle oben schon angedeutet: „@Pxxyy“. Darin steht „xx“ für die Id der Dimension, aus der wir Elementeigenschaften abfragen möchten, und „yy“ für die Id der gewünschten Eigenschaften. Die benötigten Ids findet man am besten im Modell-Browser (Menü Modell). Die Anrede beispielsweise hatten wir oben als eine Elementeigenschaft namens „Regionalleiter_Anrede“ modelliert. Dafür ist im Modell-Browser die Id als „0-0-2-1“ angegeben. Dies ist so zu interpretieren, von links nach rechts gelesen: Wir betrachten die Dimension mit der Id 0 („Kunden/0“), darin die Hierarchie mit der Id 0 („Kunden/0-0“), darin die Ebene mit der Id 2 („Region/0-0-2“) und darin wiederum die Elementeigenschaft mit der Id 1 („Regionalleiter_Anrede/0-0-2-1“).

Die Ziffernpaare werden direkt hintereinander geschrieben, ohne Komma oder Ähnliches; bei einstelligen Ids, wie hier, ergänzen Sie vorne eine Null. Um die Anrede herauszugreifen, lautet die Berichtsserver-Variable also: „@P0001“. Das erste Ziffernpaar gibt die Id der Dimension an („00“ steht für „Kunden“, wie oben gezeigt), das zweite die Elementeigenschaft („01“ für „Regionalleiter_Anrede“).

Damit können wir nun auch die Anrede in die generierten E-Mail-Nachrichten übernehmen. Die resultierende E-Mail ist auf Seite 2 abgebildet.

E-Mails ohne Anhang

Manchmal möchte man die vom Berichtsserver erzeugten Exporte nicht als Anhang per E-Mail versenden, sondern lediglich automatisiert darauf hinweisen, dass neue Berichte bereitliegen. Das erlaubt eine kleine Modifikation des Felds E-Mail-Anhang in der Jobdefinition: Wenn vor dem Dateinamen ein Pfad angegeben ist und hinter dem Dateinamen zwei Sternchen („**“), schreibt der Berichtsserver die exportierten Dokumente in den angegebenen Pfad und versendet die E-Mail ohne Attachment. Der E-Mail-Text sollte einen Hinweis enthalten, wie man auf die aktualisierten Berichte zugreifen kann, also wo sie gespeichert sind.

Auch für den Pfad kann man auf empfängerspezifische Angaben zurückgreifen – zum Beispiel auf ein Benutzerverzeichnis, das ebenfalls als Elementeigenschaft abgebildet wurde. In unserem Beispiel haben wir dafür das Attribut „Regionalleiter_Ablage“ angelegt und Werte wie „fileserverAblageVertrieb Nord“ eingetragen. Aus der Abbildung weiter oben geht die Id für diese Eigenschaft hervor: 0; unsere Berichtsservervariable lautet also „@P0000“.

Damit setzen wir den Namen für den E-Mail-Anhang zusammen und fügen die beiden Sternchen an.

Die gleiche Bezeichnung, nur ohne die Sternchen, setzen wir in den E-Mail-Text ein. Damit Microsoft Outlook und andere E-Mail-Clients den Verweis auf das Dokument als Hyperlink darstellen, auch wenn er Leerzeichen enthält oder länger ist als eine Zeile, empfiehlt es sich, Pfad und Dateinamen in spitze Klammern zu setzen („<…>“).

Mit diesen Einstellungen erzeugt der Berichtsserver die gewünschte Exportdatei, versendet sie aber nicht, sondern informiert den Adressaten, dass und wo sie bereitsteht.

Voraussetzung für diese Art der Berichtsverteilung ist, dass der Berichtsserver-Job unter einem Benutzer ausgeführt wird, der Schreibrechte auf die angegebenen Verzeichnisse hat.

Berichte im HTML-Format

Die bisher beschriebenen Verfahren gelten für Berichtsformate, die als Anlage einer E-Mail verschickt werden, zum Beispiel DeltaMaster-Analysesitzungen, PDF-Dateien, Excel-Tabellen oder PowerPoint-Präsentationen. Ebenfalls beliebt für den Berichtsversand sind HTML-Mails.

Bei den HTML-Mails sind die Berichte direkt in die E-Mail eingebettet und werden nicht als Anlage beigefügt. Aus diesem Grund bleibt das Feld E-Mail-Text zunächst wirkungslos, wenn als Berichtsformat „html“ ausgewählt ist – den Inhalt der E-Mail zusammenzustellen, das erledigt der HTML-Export, nicht die Versandkomponente des Berichtsservers. Dennoch ist eine Personalisierung möglich – indem Sie für den vom Berichtsserver generierten E-Mail-Text eine Variable in die Exportvorlage einfügen.

Dazu dient die HTML-Export-Variable „##reportservermailbody##“. Sie wird beim Export ersetzt durch den E-Mail-Text aus dem Berichtsserver. HTML-Tags in diesem Text werden derzeit nicht unterstützt. Zur Formatierung des Texts können Sie auf Stylesheets (CSS) zurückgreifen, wie auch bei den anderen Bestandteilen der Exportvorlage.

Mehr Dynamik

Der Berichtsserver ist ein äußerst leistungsfähiges und flexibles Werkzeug für die datengetriebene Automation. Er bietet vielfältige Möglichkeiten, die aktuelle Datenlage in automatisierten Prozessen zu berücksichtigen. Beispielsweise könnte man mit Variabeln auf ausgewählte Kennzahlen in den zu verteilenden Berichten zugreifen und diese schon im Betreff einer E-Mail angeben. Oder man nutzt den Berichtsserver, um Änderungen in Berichten zu erkennen und hervorzuheben, zum Beispiel neue Kunden in einer Umsatzauswertung, die bei der letzten Berechnung noch nicht vorhanden waren. Auf diese Themen werden wir in kommenden clicks!-Ausgaben eingehen. Schon vorgestellt hatten wir die Ausnahmeberichterstattung (Exception Reporting); sie war das Thema der DeltaMaster clicks! 11/2008.