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.