Die Enterprise Data Management Cloud (EDM) ist das Meta-Daten Management der EPM Enterprise Cloud. In Teil 1 habe ich die Erstellung einer Anwendung und das Importieren von Dimensionen darin besprochen. In diesem Beitrag gehe ich in die Tiefe mit der Definition von Node Types, Hierarchiën und Eigenschaften.
In dem dritten und letzten Beitrag zu diesem Thema zeige ich Regeln, Validierungen und vieles Mehr.
Kurzer Rückblick
EDM dient zur Pflege von Dimensionen, Hierarchieen und Attribute (auch Stammdaten Management genannt). Dieses ist selbstverständlich mit vielen Funktionen umgeben und Benutzerfreundlich gestaltet. Meta-Daten Management ist in grösseren Umgebungen mit vielen Änderungen eine Arbeitsintensive, oft mit Fehlern behaftete Tätigkeit. Daher ist ein Werkzeug, welches hierfür speziell entwickelt wurde, eine gute Hilfe.
Ich hatte die Möglicheit, um bei einer Partnerschulung diese Software mir mal näher anzusehen und vorallem auch auszuprobieren. Mit einigem Hintergrundwissen von DRM, aber vorallem EPMA konnte ich mich schnell zurecht finden und habe in diesem Beitrag und in einem Weiteren einen „Mitschnitt“ der Tätigkeiten gemacht.
Es geht weiter mit Nodes, Hierarchiën und Eigenschaften
In dem Desktop sehen sie die Kacheln für die Node Type, Hierarchy Sets, Node Sets und Properties. Diese bilden das Herzstück des EDMC und wir werden diese hiernach erläutern.
Abbildung 1: Desktop eines Admin in Enterprise Data Management
Node Types.
Node Types sind in EPM Dimensionen und umfassen Nodes mit den daran verbundenen Eigenschaften. Zum Beispiel, die Node Type Entity enthält die Entitäten mit ihren Eigenschaften wie Währung und Alias.
In Abbildung 2 sehen sie eine Liste Node Types. Beim Erstellen eines Node Types muss diese einer Anwendung zugeordnet werden. Der sechste Eintrag, die blau unterlegte Entity, wurde in dem vorigen Beitrag angelegt.
Abbildung 2: Node Types
Wir schauen uns einmal den Planning Node Type „Product“ näher an.
Nach dem Öffnen sehen wir wie in Abbildung 3 einige Reiter mit den Definitionen dieser Dimension. So gibt es einen Präfix und es ist ersichtlich wer Anpassungen gemacht hat.
Abbildung 3: Node Type Product
In dem Reiter Properties sehen wir die Liste der Eigenschaften, die mit der Dimension und dem Planungstyp verbunden sind. Dieses sind generische Eigenschaften, die dieser Dimension zugeordnet wurden. In diesem Fenster können diese als Pflichtangabe eingestellt werden oder nicht.
Abbildung 4: Node Type Properties
Wir gehen noch ein Level tiefer und sehen uns in Abbildung 5 die Eigenschaften von PLN.Alias: Default an. Die Eigenschaften haben eine Basis-Definition von einer maximalen Länge von 80 Zeichen (nicht in der Abbildung) und bestimmte Zeichen sind verboten wie Anführungszeichen oder Tab.
Die Beschränkungen gelten überall, wo das PLN.Alias: Default eingesetzt wird. Somit kann es einmal definiert werden und überall wiederverwendet werden.
Abbildung 5: Eigenschaften von PLN.Alias: Default
Hierarchy Sets
Bei dem Anlegen der Verbindung mit der Planning Cloud, und dem Verbinden der Entity, wurde auch ein Eintrag in den Hierarchy Sets gemacht.
Abbildung 6: Hierarchy Sets.
Und die verschiedenen Reiter, um diese Dimension weiter zu definieren. Hier können Validierungen gesetzt werden, dass bestimmte Parent-Child Kombinationen nicht erlaubt sind. So kann man definieren, dass es keine Shared Member in der Entity Dimension geben kann.
Abbildung 6: Keine Restriktionen in den Membern von Entity.
Node Set
In einem Node Set kann eine Gruppe von Node Types und/oder Top Nodes verwaltet werden. Es ist ein gespeicherter Filter, damit nicht immer wieder eine Selektion auf die Arbeitswiese gemacht werden muss.
Wir sehen bei der Definition von Entity, wurde auch ein Node Set angelegt.
Abbildung 7: Node Sets.
Properties
Die Properties sind die Eigenschaften von Dimensionen, Elemente und anderen Objekten. Diese können hier Zentral definiert und dann in gleichartige Objekte wiederverwendet werden. Die Properties sind eine der wichtigsten Bausteine in Dimensionsmanagement und kommen vordefiniert mit ECMCS.
In Abbildung 5 wurden bereits die Eigenschaften von PLN.Alias: Default dargestellt und gezeigt wie diese eingesetzt werden können. In Abbildung 8 sind weitere gezeigt. Das PLN steht für Planning und das OEP in Klammern für das Oracle Enterprise Planning.
Abbildung 8: Die Properties oder Eigenschaften.
Abbildung 9: Die Eigenschaften für PLN.Account Type
In den Eigenschaften sehen wir als Erlaubte Werte dann die bekannten Expense, Revenue, Asset, Liability, Equity und Saved Assumptions. Hiermit können wir Regeln erstellen, dass einer dieser erlaubten Werte zu einem Element der Account Dimension gesetzt sein muss. Andere Werte führen zu einem Fehler.
Abbildung 10: Werte Tabelle in den Properties.
Damit sind wir am Ende des zweiten Teils gekommen.
Ihr Philip Hulsebosch. 
