Liebe Datenanalysten,
wer mehr als einen Adressaten informieren oder anschreiben möchte, kommt fast zwangsläufig mit dem Konzept von Variablen in Berührung – auch wenn die nur in der Datenverarbeitung so heißen und sonst eher Platzhalter genannt oder einfach ausgelassen werden. So beginnen Entwürfe und Vorlagen oft mit „Sehr geehrter Herr …“, mit Auslassungspunkten. Diese sind natürlich als Variable gemeint, denn im Ergebnis soll hier ja gerade nichts ausgelassen, sondern etwas ganz Individuelles eingesetzt werden. Wer seine Adressaten automatisch anschreiben und informieren möchte, tut das besonders effizient mit dem Publisher bzw. Berichtsserver von DeltaMaster. Wenn man so will, ist jeder Job im Publisher ein Entwurf, eine Vorlage für die Korrespondenz, in der genau festgelegt ist, wie welche Berichte aktualisiert, angepasst und verteilt werden sollen. Zur individuellen Anpassung steht eine Reihe von Variablen zur Verfügung. Welche das sind und was man darüber wissen sollte, erläutern wir in diesen clicks!, vollständig und ohne Auslassung.
Herzliche Grüße
Ihr Team von Bissantz & Company
Mit dem DeltaMaster Publisher bzw. Berichtsserver lassen sich Berichte individuell für unterschiedliche Empfänger anpassen. Diese Individualisierung hat mindestens zwei Facetten: Zum einen müssen die Berichte in sich individualisiert sein, inhaltlich – sie sollen genau die Daten zeigen, die dem Empfänger zugedacht sind und für die er verantwortlich ist. Zum anderen muss die Ausgabe individualisiert sein, technisch – es soll für jeden Empfänger eine eigene E-Mail versendet oder eine eigene Datei gespeichert werden. Jeder Empfänger hat natürlich eine eigene E-Mail-Adresse, jede Datei benötigt einen eigenen, eindeutigen Dateinamen bzw. Speicherort, damit sie nicht überschrieben wird, wenn der Publisher das nächste Element verarbeitet.
Den ersten Aspekt, wie man Berichte inhaltlich individualisiert, haben wir in der letzten clicks!-Ausgabe beschrieben: Das geht über die Sicht, die Filtereinstellungen der Berichte. Diese kann der Publisher automatisch anpassen, mit dem Berichtsgenerator sogar wiederholt, in einer Schleife für mehrere Elemente (Iteration). Wie man die Ausgabe technisch individualisiert, beschreiben wir im Folgenden. Im Grunde ist es ganz einfach: Das geht mit Variablen!
Individualisierung durch Variablen
Die automatische Anpassung durch den Publisher ist in der Jobdefinition geregelt, in den Fenstern Berichtsupdate, Berichtsordner, Berichtsgenerator und Berichtsempfänger.
Auf alles, was in diesen vier Abschnitten festgelegt ist, kann man mit Variablen zugreifen und mit diesen die Ausgabe individualisieren:
- auf den Namen und die Eigenschaften von Elementen aus dem Berichtsupdate,
- auf die Namen von Berichtsordnern,
- auf die Namen und Eigenschaften der Elemente, die durch den Berichtsgenerator sukzessive abgearbeitet (iteriert) werden, und
- auf die Adressen von Berichtsempfängern, die den Berichtsgenerator-Elementen zugeordnet sein können. Auf die Adressen gehen wir weiter unten ausführlich ein.
Diese vier Abschnitte sind gewissermaßen die Quellen für die Variablen: Hier ist spezifiziert, wie sie ihre Werte bekommen. Verwendet werden die Variablen in den Feldern der Jobdefinition, allen voran im Feld Adresse, um variable Dateinamen und Verzeichnisse im Dateisystem sowie E-Mail-Adressen zu beschreiben. Auch in den Feldern Exportvorlage, E-Mail-Betreff, E-Mail-Text, E-Mail-Anhang und Benachrichtigung (weiter rechts in der Jobdefinition, hier nicht abgebildet) arbeitet man oft mit Variablen.
Bei der Jobausführung ersetzt der Publisher die Variablen durch konkrete Ausprägungen, zum Beispiel durch den im Berichtsupdate eingestellten Monat, durch den Namen von Niederlassungs- oder Kostenstellenleitern aus dem Berichtsgenerator oder durch die ihnen zugeordneten E-Mail-Adressen. Aus einer Adressangabe wie „C:Chair AG@IMN.doc“ wird so beispielsweise „C:Chair AGSüd.doc“.
Berichtsserver-Variablen, Teil 1
Die folgenden Variablen stehen zur Verfügung, um die veränderlichen Bestandteile aus den vier Fenstern in den Feldern der Jobdefinition zu referenzieren.
| @Dxx | Name des Berichtsupdate-Elements in der Dimension mit der Id xx. Der Variablenname steht für „Dimension“. |
| @Pxxyy | Elementeigenschaftswert des Berichtsupdate- oder Berichtsgenerator-Elements in der Dimension mit der Id xx und der Elementeigenschaft mit der Id yy. Der Variablenname steht für „Property“. |
| @Fxx | Name des Berichtsordners mit der Id xx. Der Variablenname steht für „Folder“. |
| @IMN | Name des aktuellen Berichtsgenerator-Elements. Der Variablenname steht für „Iterator Member Name“. |
| @IDA | Adresse, die dem aktuellen Element aus dem Berichtsgenerator zugeordnet ist, entweder gemäß der als Adresse ausgewählten Elementeigenschaft im Fenster Berichtsgenerator oder der Adressliste im Fenster Berichtsempfänger. Der Variablenname steht für „Iterator Distribution Address“. |
Die Ids sind numerische Angaben und in der DeltaMaster-Sitzung leicht zu ermitteln. Dazu zeigen Sie im Bearbeitungsmodus von DeltaMaster 6 bei gedrückter Alt-Taste mit der Maus auf das entsprechende Objekt: auf eine Dimension in der Filterleiste bzw. auf einen Ordner in der Berichtsliste.
Die Id einer Elementeigenschaft (das „yy“ in „@Pxxyy“) ermitteln Sie beim Modellieren mithilfe des Dimensionsbrowsers: Auf der Registerkarte Ebenen öffnen Sie die Auswahlliste in der Spalte Alias und zählen die Position der gewünschten Eigenschaft ab. Die oberste Eigenschaft, „(keines)“, hat die Id ?1 und ist im Publisher nicht verwendbar; dann geht es mit 0, 1, 2 weiter. Für DeltaMaster 5 gelten diese Hinweise analog; der Filterleiste entspricht das Fenster Sicht, die Id einer Elementeigenschaft kann zusätzlich im Modell-Browser (Menü Modell im Modus Miner) auf der Registerkarte Modell abgelesen werden.
Alle Ids müssen zweistellig angegeben werden, gegebenenfalls mit führender Null, zum Beispiel „@D01“ für die Dimension mit der Id 1.
Sollte eine Variable nicht aufgelöst werden können, weist der Publisher im Monitor (DeltaMaster 5: Ablaufprotokoll) darauf hin und greift stattdessen auf den Variablennamen zurück. Dadurch sind Fehler schnell zu erkennen: Wenn beispielsweise eine Datei namens „@IMN.doc“ generiert wird, ist das ein Zeichen, dass kein Berichtsgenerator definiert wurde.
Beim Exporttyp „file“ gibt die Adresse den Dateinamen und den Pfad der Datei an. Beide können mit Variablen angegeben werden, auch der Pfad, zum Beispiel „C:Chair@IMNVertrieb.doc“. Falls das Verzeichnis noch nicht existiert, legt es der Publisher automatisch an.
Weitere Variablen sind am Ende dieser clicks! aufgeführt.
Adressen von Berichtsempfängern: die Variable „@IDA“
Wir halten fest: Was der Publisher jeweils in Bearbeitung hat, kann über Variablen referenziert und weiterverwendet werden. Speziell für den Berichtsversand per E-Mail (Verteilungsart „mail“) benötigt man aber nicht nur eine Variable, die zum Beispiel den Namen der aktuellen Vertriebsregion enthält, sondern eine zweite – nämlich die E-Mail-Adresse des Empfängers, dem das erzeugte Dokument gesendet werden soll. Dafür gibt es die Variable „@IDA“. Sie liefert die Adresse zurück, die dem aktuell verarbeiteten Berichtsgenerator-Element, „@IMN“, zugeordnet ist.
Elemente und Adressen können auf zweierlei Weise zugeordnet sein: Entweder werden die Adressen
- im Analysemodell mitgeführt, in Form von Elementeigenschaften, oderlicks
- direkt im Publisher gepflegt, im Fenster Berichtsempfänger. Durch diesen Mechanismus ist die automatische Berichtserzeugung und ?verteilung mit jeder Anwendung möglich, unabhängig vom Datenmodell und ohne dieses anpassen zu müssen.
Übrigens, auch wenn hier und im Folgenden von E-Mail-Adressen die Rede ist: Die Technik eignet sich ebenso für andere Arten von Textbestandteilen, die Sie empfängerabhängig in Datei- oder Verzeichnisnamen, den E-Mail-Betreff usw. einfügen möchten.
Adressen aus dem Analysemodell verwenden
Elementeigenschaften (Member Properties) sind Zusatzinformationen zu Dimensionselementen. Sie lassen sich auf vielfältige Weise nutzen, wie in den DeltaMaster clicks! 11/2015 ausgeführt, zum Beispiel, um Stammdatenmerkmale aus dem ERP-System, Aliasse oder Bezeichnungen in mehreren Sprachen im Analysemodell verfügbar zu machen. Auch E-Mail-Adressen können als Elementeigenschaft gespeichert werden, zum Beispiel für Außendienstmitarbeiter, Niederlassungsleiter, Kostenstellenverantwortliche, Produktmanager oder Geschäftsbereichsleiter, vorausgesetzt, diese sind als eigenständige Dimensionselemente modelliert.
Im Berichtsgenerator können Sie für jeden Eintrag (für jede Dimension) auswählen, welche Elementeigenschaft als Adresse verwendet werden soll.
Adressen im Publisher pflegen
Alternativ ordnen Sie den Elementen des ausgewählten Berichtsgenerators die gewünschten Adressen im Fenster Berichtsempfänger zu. In der Liste steht links der Name eines Elements, rechts geben Sie die Adresse ein, die für dieses Element verwendet werden soll.
Mit den Befehlen oben rechts im Fenster bearbeiten Sie die Liste.
| Neuer Empfänger | Legt einen neuen, leeren Eintrag in der Liste an. Geben Sie den Namen des Elements und die Adresse ein. Der Befehl ist vor allem dann nützlich, wenn Sie eine Adresse für ein Element hinterlegen wollen, das noch nicht oder nicht immer im Berichtsgenerator enthalten ist, zum Beispiel, weil es von einer in MDX formulierten Bedingung abhängt. Um eine leere Liste erstmalig einzurichten oder eine bestehende zu erweitern, ist es einfacher, wenn Sie sich die Liste erzeugen lassen. |
| Löschen | Löscht die ausgewählte Zeile (ohne Rückfrage). |
| Liste erzeugen | Erstellt oder aktualisiert die Empfängerliste, basierend auf der aktuellen Spezifikation im Berichtsgenerator. Für jedes Element, das nicht bereits im Fenster Berichtsempfänger referenziert ist, wird ein neuer Eintrag angelegt. Ist ein Element bereits referenziert, so bleibt der Eintrag unverändert erhalten (Adresse, User Id und Passwort werden nicht geändert). Elemente in der Empfängerliste, die in der aktuellen Elementauswahl nicht mehr vorkommen, werden entfernt. |
| Die erste Einrichtung der Liste ist also schnell erledigt: Mit nur einem Klick lassen Sie den Publisher die Liste erzeugen – schon steht das Verzeichnis und Sie können zu den automatisch vorgegebenen Namen die zugehörigen Adressen eingeben. | 
|
Optional lassen sich für die einzelnen Elemente spezifische Benutzernamen (User Id) und Passwörter hinterlegen. Damit kann sich der Publisher mit den Berechtigungen des jeweiligen Benutzers an der Datenbank anmelden und hat so dieselbe Sicht auf die Datenbank wie der Benutzer selbst. Benutzername und Passwort werden unverschlüsselt in der Publisher-Datenbank gespeichert.
Das Fenster Berichtsempfänger ist nur freigeschaltet, wenn bereits ein Berichtsgenerator ausgewählt ist. Sobald mindestens ein Name eingetragen ist, arbeitet der Publisher nach der Liste und erwartet, dass für jedes Berichtsgenerator-Element ein Eintrag vorhanden ist. Fehlt ein Eintrag, so überspringt der Publisher dieses Element, generiert keine Ausgabe und vermerkt dies im Monitor bzw. Ablaufprotokoll. Ist ein Eintrag vorhanden, aber die Adresse leer, wird ersatzweise der Wert aus der im Berichtsgenerator zugewiesenen Elementeigenschaft herangezogen; fehlt diese, setzt der Publisher den Variablennamen „@IDA“ ein.
Beispiele
Um die Funktionsweise der Variablen zu verdeutlichen, haben wir zwei Jobs angelegt, die Berichte aus derselben Analysesitzung (Berichtsquelle) erstellen bzw. verteilen. Der erste Job soll Word-Dokumente exportieren und lokal speichern, der zweite soll die Berichte als HTML-Mail versenden.
Für beide Jobs gelten diese Verarbeitungsvorschriften:
- Als Berichtsupdate soll in der Zeitdimension (mit der Id 2) „Aug 2015“ ausgewählt werden,
- nur der Berichtsordner „Vertrieb“ (mit der Id 10) soll berücksichtigt werden und
- der Berichtsgenerator soll über die Elemente „Nord“, „Süd“, „Ost“ und „West“ iterieren.
Für den ersten Job lautet die Adresse „C:Chair AG@F10 @IMN, @D02.doc“, das Fenster Berichtsempfänger bleibt leer.
Führt man den Job aus, erzeugt er vier individuelle Dokumente mit sprechenden Dateinamen. Ebenso sind die Filter in den enthaltenen Berichten gesetzt.
Für den zweiten Job lautet die Adresse schlicht „@IDA“. Im Fenster Berichtsempfänger ist eine Liste wie die auf Seite 5 angelegt: Dem Element „Süd“ ist die Adresse „vertrieb-sued@example.com“ zugeordnet, dem Element „Nord“ die Adresse „vertrieb-nord@example.com“ usw. Die Kennzeichnung, um welche Auswertungen, welche Region und welche Periode es geht, wird der Nachricht im E-Mail-Betreff mitgegeben: „@F10 @IMN, @D02“.
Führt man den Job aus, versendet er vier E-Mails an vier verschiedene E-Mail-Adressen, mit individueller Betreffzeile und individuellem Berichtsinhalt.
Besonders wertvoll werden solche Nachrichten, wenn man die Betreffzeile nicht nur zum Ankünden von Information nutzt, sondern zum Verkünden – indem man schon dort die wichtigste(n) Kennzahl(en) aus dem wichtigsten Bericht zitiert. Dies ermöglicht die Variable „@Report“, wie im nächsten Abschnitt angedeutet und in der dort genannten Quelle ausgeführt.
Ein weiteres Beispiel, nämlich: wie Sie die Ausgabe mit Elementeigenschaften („@Pxxyy“) anpassen, bis hin zur persönlichen Anrede, finden Sie in den DeltaMaster clicks! 11/2011 („Personalisierte E-Mails mit dem Berichtsserver versenden“).
Berichtsserver-Variablen, Teil 2
Neben den oben vorgestellten Variablen, die sich auf Bestandteile der Jobdefinition beziehen, gibt es weitere, mit denen Sie die Ausgabe des Publishers anpassen können. Der Vollständigkeit halber führen wir sie hier mit auf.
Variablen für Berichtsinhalt (Zellwerte, Änderungen gegenüber vorheriger Berechnung)
Die folgenden vier Variablen beziehen sich auf den Berichtsinhalt. Sie werden vor allem dazu genutzt, die Betreffzeile und den Text von automatisch generierten E-Mails anzupassen (Felder E-Mail-Betreff und E-Mail-Text in der Jobdefinition).
| @Reportx!RyCz | Wert der Zelle in Zeile y (engl. row), Spalte z (engl. column) im Bericht x |
| @Reportx#R | Anzahl der Zeilen im Bericht x („R“ wie engl. „rows“, Zeilen) |
| @Reportx#+R | Anzahl der Zeilen im Bericht x, die im Vergleich zum vorherigen Job-Durchlauf dazugekommen sind |
| @Reportx#-R | Anzahl der Zeilen im Bericht x, die im Vergleich zum vorherigen Job-Durchlauf entfallen sind |
Die Berichts-Id x ermitteln Sie wie die von Dimensionen und Berichtsordnern: indem Sie im Bearbeitungsmodus bei gedrückter Alt-Taste mit der Maus auf den Bericht in der Berichtsliste zeigen.
Ausführliche Hinweise liefern die DeltaMaster clicks! 06/2013 („Bessere Betreffzeilen für E-Mails durch Werte aus den Berichten“) und 06/2015 („Änderungen in automatisch aktualisierten Berichten hervorheben“).
Variablen für Exportvorlagen
Die Ersetzung von Variablen kann der Publisher nicht nur in seinen eigenen Einstellungen ausführen, sondern auch in den Vorlagen für den Export nach Microsoft Office und ins PDF-Format (Dateien „DeltaMaster.dot/.pdf/.pot/.potx/.xlt“ oder entsprechende eigene Vorlagendateien). Die folgenden Variablen lassen sich in Exportvorlagen platzieren und werden in den Ausgabedokumenten ersetzt.
| @shortdate | Datum des Exports im Kurzformat gemäß Windows-Einstellungen, zum Beispiel „14.07.2016“. |
| @shorttime | Uhrzeit des Exports im Kurzformat gemäß Windows-Einstellungen, zum Beispiel „13:59“. |
| @longdate | Datum des Exports im Langformat gemäß Windows-Einstellungen, zum Beispiel „Donnerstag, 14. Juli 2016“ |
| @longtime | Uhrzeit des Exports im Langformat gemäß Windows-Einstellungen, zum Beispiel „13:59:12“ |
| @database | Name der Datenbank, auf der die Berichtsquelle (Anwendung/Analysesitzung) basiert |
| @cube | Name des OLAP-Würfels, auf dem die Berichtsquelle basiert |
So lässt sich beispielsweise auf dem Deckblatt eines Word-Dokuments das Erstellungsdatum einfügen. Diese Variablen werden auch in der Adresse, im E-Mail-Betreff usw. erkannt und ersetzt. Die Uhrzeit eignet sich jedoch nicht als Adresse für die Verteilungsart „file“, da sie üblicherweise mit einem Doppelpunkt angegeben wird und dieser in Dateinamen nicht zulässig ist.
Variablen für Sprachen
In der Jobdefinition können eine oder mehrere (Oberflächen-)Sprachen und Alias Sets eingestellt werden, in die die Berichtsquelle umgesetzt werden soll, vgl. DeltaMaster deltas! 5.5.4, Punkt 9. Auch dies ist eine Iteration, die man mit Variablen referenzieren kann.
| @aliasset | aktuelles Alias-Set aus der Iteration über die Elemente im Feld Alias Set der Jobdefinition |
| @language | aktuelle Sprache aus der Iteration über die Elemente im Feld Sprache der Jobdefinition |
Die Variablen sind insbesondere für die Adresse von Bedeutung, wenn ein Job Dokumente in mehreren Sprachen ausgeben soll, sowie für die Exportvorlage, wenn diese Exporte auf sprachabhängigen Vorlagen basieren sollen.
Variablen für CSV-Export
Beim Export im Format CSV (Comma-Separated Values) wird jede exportierte Tabelle in eine eigene Datei geschrieben. Das erleichtert die Datenübernahme in andere Systeme – und ist ein Unterschied zu den übrigen Exportformaten, bei denen alle Berichte in nur eine Datei geschrieben werden. Daher muss die Adresse beim CSV-Export auch einzelne Berichte differenzieren können. Das leisten die folgenden Variablen.
| @rid | Id des gerade verarbeiten Berichts. Der Variablenname steht für „Report Id“. |
| @rn | Name des gerade verarbeiten Berichts. Der Variablenname steht für „Report Name“. |
Der CSV-Export ist ausführlich in den DeltaMaster deltas! 5.4.9, Punkt 9, erläutert.
