Mit dem Release der Version 212 des DeltaMaster Modeler im Herbst 2013 kam ein neues Feature hinzu, das angetreten ist, die immerwährende Kluft zwischen DeltaMaster Modeler und dem SQL Server Business Intelligence Development Studio (BIDS) bzw. den SQL-Server Data Tools (SSDT) zu schließen. Bis dahin war es immer ein Problem, wenn man den Modellierungspfad des Modelers verlassen musste, um im BIDS/SSDT etwas zu implementieren, das über die Modeler-Funktionalität nicht modellierbar gewesen wäre. Mit jedem Deploy wurde diese Anpassung überschrieben und musste mühsam von Hand wieder nachgezogen werden. Aber seit dem Release der Version 212 gehört dies der Vergangenheit an: Anpassungen, die über das BIDS/SSDT vorgenommen wurden, können jetzt per XMLA-Script hinterlegt und vom Modeler nach einem Deploy in das Datenmodell eingefügt werden.
XMLA – was ist das?
XMLA steht als Abkürzung für „XML for Analysis“ – ein speziell entwickeltes XML-Protokoll, das auf den universellen Datenzugriff für mehrdimensionale Datenquellen ausgerichtet ist. Jegliche Kommunikation zwischen Clientanwendungen und Analysis Services läuft auf der Protokollebene über XMLA. Somit ist klar, dass auch das Erstellen und Ändern von Objekten über BIDS bzw. SSDT am Ende immer in einem XMLA-Script mündet. Hier ein weiterführender Link zu dem Thema:
http://msdn.microsoft.com/de-de/library/ms187152.aspx.
Wie kommt man an ein XMLA-Script?
Die einfachste Möglichkeit, um ein XMLA-Script aus einem bestehenden SSAS-Datenmodell abzuleiten, ist der Rechtsklick auf ein Objekt (Datenbank, Dimension, Cube, etc.) und die Auswahl „Skript für als…“ im Kontextmenü. Danach öffnet sich ein Untermenü, in dem CREATE, ALTER oder DELETE zur Auswahl stehen – mit jeweils den Auswahlmöglichkeiten „Neues Abfrage-Editor-Fenster“, „Datei…“ oder „Zwischenablage“. Da ein Script erstellt werden soll, das eine Änderung am Datenmodell bewirken soll, empfiehlt es sich, das Script mit ALTER in einem neuen Abfrage-Editor-Fenster erstellen zu lassen.
Abbildung 1: Menüführung im Management-Studio
… und voilà – schon hat man ein XMLA-Script erstellt, mit dem man ein ganzes Datenmodell oder auch nur Teile davon erstellen kann.
Überarbeitung des XMLA-Scripts
Je nach Umfang des Datenmodells kann das XMLA-Script recht umfangreich werden, hier nun einige Tipps, wie man diese Menge an Information auf ein überschaubares Maß reduzieren kann:
- Das Script nach Möglichkeit immer auf dem Server erstellen lassen, auf dem es nach dem Cube-Deploy auch ausgeführt werden soll. Je nach Serverkonfiguration kann es vorkommen, dass unterschiedliche Namensräume angegeben werden.
- Ganz zu Anfang stehen die Header-Informationen, diese dürfen nicht verändert werden. Zum Beispiel die Definition der Namensräume, das <Object>-Tag mit Angaben zur OLAP-Datenbank und zum Objekt, auf dem der Alter-Befehl ausgeführt werden soll.
- Eine sinnvolle Ergänzung innerhalb des <Alter>-Tags: Das Attribut AllowCreate=“true“. Dieses Attribut ist standardmäßig nicht im <Alter>-Tag enthalten!
Mit diesem Tag wird ein Objekt angelegt, falls es noch nicht im Datenmodell vorhanden ist. Ansonsten würde der Versuch einen Alter-Befehl auf ein nicht vorhandenes Objekt auszuführen einen Fehler verursachen. - Tag-Bereiche können entfernt werden, wenn keine Informationen zu der gewünschten Anpassung enthalten sind. Ein Beispiel:
Wenn das XMLA-Script eines Cubes erstellt wurde, um die manuell eingestellten Partitionsdefinitionen nach einem Cube-Deploy wieder herzustellen, können aus dem Script die nicht relevanten Bereiche (wie z.B. alles zwischen <Dimensions>… und …</Dimensions>) entfernt werden. Diese werden ja bereits über den Modeler aufgebaut und müssen für die gewünschte Anpassung des Datenmodells nicht verändert werden. Wichtig ist nur, dass die Teile erhalten bleiben, die von der Änderung betroffen sind und natürlich auch alle Tags, die diese Bereiche einschließen. Mit anderen Worten: Wenn in einem Bereich zwischen einem öffnenden und einem schließenden Tag keine relevante Information steht, kann der gesamte Bereich (inkl. des öffnenden und schließenden Tags) aus dem Script entfernt werden. - XMLA ist Case-Sensitiv – also immer auf Groß-/Kleinschreibung achten. Die Fehlermeldungen, die aus einer falschen Schreibweise resultieren, sind manchmal ziemlich unspezifisch.
Ausführung im Modeler
Im Repository des DeltaMaster Modeler gibt es eine Tabelle, in der XMLA-Scripte hinterlegt werden können: T_Model_XMLA_Script. Diese Tabelle hat vier Spalten:
- ApplicationID: Wenn das Script nur für eine bestimmte Application hinterlegt werden soll, muss hier die ID dieser Application eingetragen werden – ansonsten eine 0. Damit gilt das XMLA-Script für alle Applications.
- XMLA_Script_Name: Der Name des Scripts. Dieser Name wird im Modeler-LOG angezeigt, wenn das Script ausgeführt wird.
- XMLA_Script: Das gesamte XMLA-Script.
- IsActive: Flag zur Steuerung, ob das XMLA ausgeführt werden soll oder nicht (1 oder 0)
Am besten verwendet man zum Einfügen des XMLA-Scripts das folgende Insert-Statement:
INSERT INTO [dbo].[T_Model_XMLA_Script](
[ApplicationID],
[XMLA_Script_Name],
[XMLA_Script],
[IsActive]
)
VALUES(
0, -- 0: für alle Applications; <> 0: Gilt nur für Application mit dieser ID
N'This script name will be displayed in Modeler.exe', -- Name für dieses Script
N'
HIER DAS XMLA-Script einfügen!!!
',
1 -- IsActive: 0 oder 1
)
GO
Wenn alles steht, muss nur noch die XMLA-Verarbeitung im Modeler aktiviert werden. Dazu gibt es in der Modeler-DAS den Parameter „Enable XMLA run-after-scripts“. Den Parameterwert muss man auf 1 stellen, damit die Einträge aus der Tabelle T_Model_XMLA_Script nach dem Cube-Deploy ausgeführt werden.
Abbildung 2: Einstellungen im DeltaMaster Modeler
