Im letzten Jahr wurde im Rahmen eines Kundenprojekts das Offline-Planungssystem ins Leben gerufen. Wie der Begriff bereits vermuten lässt, wird ohne Datenbankverbindung auf dem Client geplant. Die Herausforderung besteht darin, dass die Datenbank auf dem Client stets die aktuellen Strukturen und Stammdaten repräsentiert. Nach der abgeschlossenen Planung wiederrum muss der Benutzer in der Lage sein, seine Eingabedaten auf den Server zu übertragen.
Für diesen Zweck wurde auf Basis von Microsoft Analysis Services und mithilfe lokaler Cube-Dateien eine Startapplikation erstellt. Aufgabe dieser Applikation ist die Aktualisierung der folgenden Prozesskomponenten:

• Konfigurationsdatei
• Cube-Datei
• DeltaMaster-Analysesitzung
• SQL-Skript zur Erzeugung und Aktualisierung der Datenbank

Des Weiteren sorgt die Applikation für die Anpassung der Verbindungsinformationen in den Dateien, die Erzeugung und Aktualisierung der lokalen relationalen Datenbank auf Basis von SQL Server Express und die Verarbeitung der lokalen Cube-Datei.

Bevor es aber auf dem Client soweit ist, muss auf dem Server noch einiges passieren.

Manuelle Schritte auf dem Server

Der Administrator erstellt auf dem Server über den DeltaMaster-Menüpunkt „Bearbeiten – OLAP-Datenbank verarbeiten“ (nur über den Registry Key sichtbar) eine leere Cube-Datei, die nur die Struktur der OLAP-Datenbank beinhaltet (template cube file) und für Rückschreiben aktiviert ist. Je nach Infrastruktur der Benutzer können SQL Express Datenbanken oder ACCESS für das Rückschreiben verwendet werden. Diese Datenbanken sind meist die Kopie der Server-Datenbank. Sie enthalten alle Synonyme, Prozeduren und Tabellen für die Synchronisation der Daten zwischen Client und Server. Im Falle der SQL Express Datenbanken wird mittels SQL-Datei die Datenbank auf dem Client erstellt bzw. aktualisiert, sobald die Startapplikation ein neues SQL-Skript erkennt oder der Name des lokalen Datenbankservers bzw. der lokalen Datenbank in der Konfigurationsdatei geändert wird.

Was macht die Startapplikation?

Abbildung 1 verdeutlicht die Arbeitsschritte, die von der Startapplikation ausgeführt werden.

Abb. 1: Funktionsweise der Startapplikation bei Offline-Planung

Nachdem die Applikation „DeltaMasterStart“ auf dem Client gestartet wurde, gleicht sie anhand der Konfigurationsdatei „DeltaMasterStart.config.xml“ Versionsinformationen ab, um herauszufinden, ob es zentrale Änderungen gab (Punkt 1): es wird geprüft, ob neue Versionen der Analysesitzung, der Cube-Datei, des SQL-Skripts zur Erzeugung und Modifikation der lokalen Datenbank verfügbar sind und eine neue Version einer Konfigurationsdatei heruntergeladen werden soll (Punkt 2).

Die Applikation wird üblicherweise im Verzeichnis „C:\Dokumente und Einstellungen\UserName\ DeltaMasterStart“ angelegt. Das Verzeichnis wird beim ersten Programmstart angelegt und die mit der Installation ausgelieferte Version der Konfigurationsdatei in das Arbeitsverzeichnis kopiert.

Die Server-Version der Konfigurationsdatei wird bei vorhandener Netzwerkkonnektivität in ein Unterverzeichnis des Arbeitsverzeichnisses kopiert und dort auf Unterschiede zur lokalen Konfiguration untersucht. Der Verzeichnisname für das Zwischenspeichern der zentralen Konfiguration lautet „C:\Dokumente und Einstellungen\UserName\DeltaMasterStart\temp“

Die Applikation übernimmt die initiale Einrichtung der „Arbeitsumgebung“. Die Konfigurationsdatei benötigt lediglich einen Zielpfad zum Herunterladen der Dateikomponenten. Nachdem, wie in Punkt 2 beschrieben, vom Server der aktuelle Stand der Konfigurationsdatei heruntergeladen wurde, entscheidet die Applikation auf Grund der Versionsinformation (Punkt 3), welche SQL-/DAS- und Cube-Datei heruntergeladen wird, um eine eventuell existierende Version durch die neueste zu ersetzen.

Außerdem wird ein Backup der DAS- und Cube-Dateien aus dem Arbeitsverzeichnis, sowie der vorhandenen Konfigurationsdatei erstellt.

Zusätzlich kümmert sich die Startapplikation um die Datensynchronisation zwischen dem Server und dem Client. Sie passt die Verbindungszeichenfolge der relationalen Datenquelle in der Cube-Datei an, wenn

• ein neues SQL-Skript heruntergeladen wird (Punkt 4),
• eine neue Cube-Datei heruntergeladen wird (Punkt 7),
• sich der lokale Datenbankserver oder Datenbankname ändert oder
• der zentrale Datenbankserver oder Datenbankname ändert.

Dazu modifiziert sie die Verbindungseigenschaften der Analysesitzung, also den Pfad zur lokalen Cube-Datei und die Verbindungszeichenfolge für den relationalen Zugriff auf die lokale SQL Express-Instanz, wenn

• eine neue Analysesitzung heruntergeladen wird (Punkt 8),
• eine neue Cube-Datei heruntergeladen wird (der Name könnte sich geändert haben) oder
• der lokale Datenbankserver bzw. Datenbankname sich ändert.

Nachdem das SQL-Skript heruntergeladen wurde, wird es ausgeführt und die lokale Datenbank mit den Strukturänderungen aus dem zentralen Server aktualisiert (Punkt 5). Diese Erneuerungen in Form von Strukturen oder Aggregationen sind gleichzeitig in der lokalen Cube-Datei eingeflossen, so dass eine problemlose Kommunikation zwischen lokaler Datenbank und der lokalen Cube-Datei stattfinden kann (Punkt 6).

Zuletzt startet sie DeltaMaster und die Sitzung für die Dateneingabe der Planung (Punkt 9). Die Sitzung ist mit der Cube-Datei verbunden (Punkt 10). Die Benutzer erfassen über vorbereitete Planberichte ihre Werte. Die Daten werden in die Rückschreibetabelle auf der lokalen relationalen Datenbank geschrieben (Punkt 11).

Datensynchronisation

Hat der Benutzer die Dateneingabe beendet, kann er jederzeit (Netzwerkkonnektivität vorausgesetzt) seine Daten zum Server übertragen (DataSync). Weil dieser Prozess manuell angestoßen werden muss, um die Daten von der Rückschreibetabelle der lokalen Datenbank in die Faktentabelle der Server-Datenbank zu übertragen, kommt die DeltaMaster CustomApp zum Einsatz. Dieses Plugin bietet generell die Möglichkeit die Menüstruktur von DeltaMaster dynamisch zu erweitern. Dabei sind Aufrufe eines externen Programms oder einer gespeicherten Prozedur möglich. Als zusätzlicher Menüpunkt von DeltaMaster wird dann die gespeicherte Prozedur
„P_SYNC_ProcessCompleteSync“ ausgeführt.

Besonderheiten

• Lizenzierung

Es kommt eine Custom-Version von DeltaMaster zum Einsatz. Hierbei nutzen wir eine spezielle Version, die das Lizenzierungsmodell unterstützt. Da die Lizenzierung der vielen Offline-User mit Named-Lizenzen zu aufwendig wäre, liegt die Lizenz in der DAS-Datei.

• ExpressDataSync

Aufgrund von Netzwerk-Latenzen oder niedrigen Bandbreiten (GSM Netz) kann eine Datensynchronisierung über Linked Server TDS (Tabular Data Stream) Protokoll sehr lange dauern. TDS verfügt über keine Komprimierung was dazu führt, dass selbst NULL Zellen mit der Größe des Datentyps übertragen werden (z. B. char(30) ergeben 30 Bytes Transfer). Je größer die Datenmenge ist, desto stärker fallen die Latenzen ins Gewicht, die bei der Bestätigung der Datenblöcke auftreten.

• Wie funktioniert es?

Das ExpressDataSyncCLR ist ein SQLCLR also eine Strored Procedure, die in .NET geschrieben ist. Es ruft die gewählte Tabelle auf, komprimiert diese und schickt die Daten als Binärvariable über das Netzwerk. Die beste Komprimierungsrate wird bei NULL, char, nchar, varchar und nvarchar erreicht. Es kann das Übertragungsvolumen im Schnitt bis zu 70% reduzieren.