Die extrem hohe Vernetzung aller Bestandteile von DeltaMaster ist im Grunde ein großer Vorteil von DeltaMaster und OLAP-Datenbanken. Alle Beziehungen sind vordefiniert und der User kann sich sofort mit seinen Daten befassen, ohne vorher solche Beziehungen erst noch mühevoll definieren zu müssen.
Die Ebenen einer Hierarchie hängen voneinander ab. Attribute bilden Beziehungen in einer Dimension. Faktendaten sind mit bestimmten Attributen verbunden. MDX-Berechnungen benötigen die entsprechenden Measures der Faktentabellen. In einer DAS-Datei setzt sich diese hohe Vernetzung weiter fort: es sind neuen Analysewerte definiert und neue Dimensionselemente, die wiederum davon abhängig sind, dass die darunterliegenden Bestandteile alle genauso vorliegen, wie es zur Zeit der Definition der Fall war. Ein Bericht in einer DAS-Datei ist da nur das letzte Puzzlestück, die obere, sichtbare Sicht auf diese wohlgeformte aber eben auch recht komplexe Welt von Abhängigkeiten. Einen Bericht da herauszulösen und in eine andere Welt zu implementieren, würde erfordern, dass alle erforderlichen Bestandteile in der neuen Welt genauso vorhanden sind, wie in der alten.
Trotz all dieser Schwierigkeiten bietet DeltaMaster ein Standard-Verfahren an, um Berichte von einer DAS-Datei in eine andere zu transferieren: die Seite ‚Import‘ im Modell-Browser. Da es ein automatisiertes Standard-Verfahren ist, muss man sich dabei an einige Regeln gewöhnen. Z.B. werden alle Bestandteile der DAS-Datei, von denen der zu überführende Bericht abhängig ist, ebenfalls mit kopiert. So wird sichergestellt, dass der Bericht in seiner neuen Umgebung auch funktioniert. Es wird sogar bei vorhandenen Elementen (z.B. einem benutzerdefinierten Analysewert, der in beiden DAS-Dateien unter gleichem Namen vorhanden ist), die Definition überschrieben. Das ist zwar gut für den importierten Bericht, kann aber in vorhandenen Berichten falsch sein, wenn das entsprechende Element (z.B. Analysewert) in der Ziel-DAS eine ganz andere Bedeutung hat.
Da solche Situationen durchaus häufig auftreten, gibt es zumindest für Flex-Reports eine alternative Variante des Berichtstransfers. Diese soll hier kurz vorgestellt werden.
Durch Einfügen des Registry-Schlüssels ‚EnableFlxImExport‘ kann man die Möglichkeit aktivieren, Flex-Reports als XML-Datei zu exportieren bzw. importieren.
Nach Erstellen des Schlüssels und Neustart des Deltamasters erscheinen die neuen Einträge im ‚Ändern‘-Menü: ‚Flexreport-Definition importieren‘ und, wenn ein Flex-Report gerade angezeigt wird, auch ‚Flexreport-Definition exportieren‘
Der erste Schritt ist also das Exportieren der Berichtsdefinition in eine XML-Datei. Das ist absolut selbsterklärend und am Ende hat man eine XML-Datei, in der alle Einstellungen des Flex-Reports gespeichert sind.
Das hier beschriebene Verfahren wurde verwendet, um Flex-Reports zu transferieren, in der hauptsächlich mit Referenzen auf Pivot-Tabellen gearbeitet wurde. Diese zugrundeliegenden Pivot-Tabellen wurden ‚von Hand‘ nochmals in der Ziel-DAS angelegt. Und damit natürlich auch alle benötigten Analysewerte und weitere notwendigen Elemente (z.B. benutzerdefinierte Dimensionselemente). Das Anlegen von Pivot-Tabellen oder Analysewerten kostet auch etwas Zeit, leider gibt es aber z.Z. keine Möglichkeit diese auch auf ähnliche Art und Weise zu importieren. Außerdem kann man so auf die vorhandenen Elemente in der neuen Umgebung achten und gegebenenfalls Elemente umbenennen. Außerdem ist das Anlegen von Pivot-Tabellen wesentlich schneller als das Anlegen eines komplexen, komplett durchformatierten Flex-Reports. Beim Flex-Report müsste jede Zelle entsprechend neu formatiert werden, was viel Zeit kosten kann.
Für das Anlegen der Pivot-Tabellen ist es notwendig, genau zu wissen, welche Pivot-Tabellen dem Flex-Report zugrunde liegen. Auch diese Information ist in DeltaMaster auf der Import-Seite des Modell-Browsers abrufbar. Dies kostet jedoch recht viel Zeit und die entsprechende Baum-View kann bei großen DAS-Dateien mit hunderten von Elementen schnell unübersichtlich werden. Deshalb hier noch ein alternativer Tipp: Diese Informationen kann man sich auch aus der exportierten XML-Datei holen.
Um eine XML-Datei auszuwerten, gibt es die verschiedensten Wege. Als SQL-Experten wählen wir natürlich den Weg über eine Tabelle mit einer Spalte des Typs XML. Es wird also eine neue Tabelle angelegt und die XML-Datei importiert, was recht einfach und schnell funktioniert:
Transact-SQL bietet eine Handvoll von Techniken für XML. Einige werden im folgenden SQL-Statement genutzt, um die referenzierten Pivot-Tabellen zu finden:
Um kurz auf dieses SQL-Statement einzugehen, hier noch ein Stück einer entsprechenden XML-Datei:
Die Flex-Report-XML benutzen einen eigenen Namespace, der in der SQL-Abfrage gesondert angegeben werden muss. Ansonsten ist das XML sehr einfach aufgebaut, es enthält unter dem ‚PropertiesFreeReport‘-Tag für jede Zelle des Berichts einen ‚CellDef‘-Tag. Die XML-Spalte XML_txt bekommt das Alias xmldoc. XML ist in SQL ein komplexer Datentyp, der auch eigene Funktionen beinhaltet. So eine Funktion (.nodes) wird mit CROSS APPLY aufgerufen und gibt die Menge aller CellDef-Knoten des XMLs zurück.
In einem CellDef-Knoten sind alle relevanten Informationen zur Zelle aufgelistet. Z.B. bedeutet 0, dass es sich um eine Zelle vom Typ Leer handelt. 39 ist eine Zelle mit Referenz. Die CellDef-Knoten sind natürlich selbst auch wieder vom Typ XML und haben die entsprechenden Funktionen. Im Select-Teil wird nun eine andere XML-Funktion verwendet: .query(). Dieser Funktion kann man eine Art abgespecktes X-Path-Statement mitgeben, um auf bestimmte Elemente des Knotens zugreifen zu können. Im Beispiel wird im X-Path-Statement einfach auf ein untergeordnetes Tag verwiesen (Index0). Das Tag Index0 gibt die ID des referenzierten Cockpits der Zelle an. Diese IDs gibt das SQL-Statement (…cellnodes.CELL.query(‘Index0′)…) zurück.
Der Rest ist ein wenig Arbeit, aber schnell erklärt: nach dem Erstellen der Cockpits, auf die im Flex referenziert wird, müssen dann in der XML-Datei die IDs der neuen Cockpits an die Stelle der entsprechenden Cockpit-IDs der alten DAS-Datei. Das funktioniert bestens mit ‚Suchen und Ersetzen‘ im Texteditor.
