Enterprise Data Management Cloud Teil 3.

Die Enterprise Data Management Cloud (EDM) ist das Meta-Daten Management der EPM Enterprise Cloud. In Teil 1 habe ich die Erstellung einer EDM Anwendung und das Importieren von Dimensionen darin besprochen. In dem zweiten Beitrag habe ich die Definition von Node Types, Hierarchien und Eigenschaften besprochen.

In diesem dritten und letzten Beitrag zu diesem Thema zeige ich wie man in Eigenschaften eingreifen kann, wie Regeln und Validierungen erstellt werden und einiges 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.

Eigenschaften ausschliessen und per rule definieren

Wir hatten gesehen das wir Elemente Eigenschaften zuweisen können.

In einem Beispiel möchte ich zeigen, wie bestimmte Eigenschaften blockiert werden können. Die Speichereigenschaft „Dynamic Calc and Store“ hat ja im Normalfall in Planning Datenbanken nicht so viel Sinn. Deshalb möchte ich diese Option nicht erlauben.

Weil sie Standard mit eingebunden wird, gehe ich in diesem Beispiel hin und entferne diese Eigenschaft.

Unter „Properties“ sehen wir einen kleinen Ausschnitt der Eigenschaften. Die Planning Eigenschaften haben wir ein PLN prefix gegeben. Ich wähle Data Storage aus.

Abbildung 1: Die PLN.Data Storage wird ausgewählt.

Links sehen wir wo diese Eigenschaft Data Storage überall so verwendet wird. Ich wähle meine Anwendung MyPBCS aus und klicke auf den Edit Knopf.

Abbildung 2: Die MyPBCS Anwendung wird gewählt.

Ich selektiere in den „Allowed Values“ den Eintrag „Dynamic Calc and Store“ und entferne diesen.

Abbildung 3: Entfernen einer Standardeinstellung.

Daraufhin bekomme ich eine Warnung angezeigt.

Abbildung 4: Eine letzte Warnung.

Ich habe keine Dynamic Calc and Store in meiner heutigen Outline, also gibt es dort keine Probleme. Neue werden aber auch nicht zugelassen.

Standardwert definieren: Speichern auf Level0, ansonsten Dynamisch Berechnen.

Als nächstes möchte ich eine Regel erstellen, dass der Standardwert definiert wird, wenn ein neues Element erstellt wird. Dieser Standardwert sollte so eingestellt werden, das, wenn ein Element ein neues Level0 element ist, dieser auf „Store“ eingestellt ist. Ansonsten muss „Dynamic Calc“ gesetzt werden.

In den Properties wähle ich die Data Storage Eigenschaft aus. Unter „Default Parameters“ wähle ich „Derived“ aus und kann dann den Editor starten.

Abbildung 5: Einen Parameter automatisch setzen (Derived).

In dem Editor beginne ich mit einem Kommentar.

Abbildung 6: Setzen von einem Kommentar, was hier definiert wird.

Es besteht eine reichhaltige Palette an Objekten und Operators mit dem ich die Logik schreiben kann.

Abbildung 7: Optionen zur Auswahl.

Und so sieht dann die Rule aus:

Abbildung 8: Aufbau der Regel.

Dort wo das CoreStats.Bottom Node steht, gibt es die Auswahl aller Eigenschaften zum Planning.

In den Eigenschaften der Elemente, kann man dann sehen, ob diese aus der Standard Eigenschaft (Derived) oder gesetzte Eigenschaft (Defined) herkommen.

Abbildung 9: Links ist die Eigenschaft per Rule gesetzt auf er rechten Seite definiert.

Validierungen

Wir wollen nicht manuell sondern die Anwendung checken lassen, dass unsere Anpassungen im Einklang sind mit den Regeln die wir gesetzt haben. Hierzu gibt es Validierungen. Ich erstelle eine neue Validierung um zu kontrollieren ob alle ID’s in der Dimension Accounts, die hinzugefügt oder umbenannt werden, ein Präfix A_ bekommen/haben. Wenn nicht, dann gibt es eine Fehlerbotschaft.

Unter Node Types selektieren wir die Dimension Accounts.

Abbildung 10: Unter Node Types finden wir Validierungen.

Danach kann unter „Validations“ eine Validierungsregel erstellt werden.

Abbildung 11: Auch die Namensgebung von Validierungen sollte Deutlichkeit schaffen.

Als nächstes kommt die Regel.

Abbildung 12: Wir bauen eine Expression auf.

Und hier ist die Logik die unter Expression eingetragen ist.

Abbildung 13: Ein A_ sollte gesetzt sein in der ID.

Sobald ich eine neue Anfrage in der Dimension Accounts erstelle, dann wird die Regel sichtbar. Wenn dann in dem Namen (die ID) mit ein „A_“ begonnen wird, dann verschwindet die Mitteilung unten.

Abbildung 14: Noch steht dort kein A_ und deshalb kommt die Nachricht.

Also bevor ich die Anpassung oder Erstellung abspeichere, kommt die Mitteilung schon. Damit kann ich direkt eine Korrektur vornehmen.

Zwei Dimensions Strukturen vergleichen

Eine der wichtigsten Dinge ist der Vergleich von Dimensionsstrukturen, denn man will wissen, welche Anpassungen gab es, oder sind bestimmte Strukturen gleich.

Ich zeige hier ein sehr einfaches Beispiel, wo die Storage Eigenschaft anders steht. Ab einem bestimmten Punkt in der Hierarchie vergleiche ich beide Strukturen. Es geht hier um eine Struktur in Financial Consolidation und Planning.

Abbildung 15: Ab diesem Punkt abwärts einen Vergleich machen.

Abbildung 16: Eine Abweichung auf C_102 gefunden (links), Doppelklick und die Eigenschaften werden angezeigt.

Anlegen von einem neuen Account

In dem folgenden Schritt wird ein Account angelegt und bereitgestellt für eine Genehmigung.

Abbildung 17: Auswahl der MyPBCS Anwendung in der View.

Abbildung 18: New Request oben rechts selektieren.

Dieser Anfrage solle ein sprechender Name mitgegeben werden. In diesem Fall wähle ich „Add MyPBCS Technical Account”. Ich füge ein Kind unter dem ACC_0001 hinzu.

Abbildung 19: Die Anfrage.

Gebe diesen Namen und alle weiteren Eigenschaften.

Abbildung 20: Das Kind sollte ACC_0018 heissen.

Abbildung 21: und diese Eigenschaften haben. Danach auf den Submit Knopf drücken.

Abbildung 22: Wir kommen zum Ausgangsbildschirm zurück.

Abbildung 23: Unter Requests, und dann Filtern auf MyPBCS, sehen wir die Anfrage.

Abbildung 24: Eine Zustimmung (Approval) der Anpassung war nicht nötig ich war als Admin angemeldet.

Ein Workflow Schema für Zustimmungen kann aufgebaut werden. Dieses kann Granular auf Eigenschaften und Anwendungen gemacht werden.

Export of Dimension data

In den nächsten Schritten werde ich die Meta Daten der Account Dimension direkt in die PBCS Anwendung exportieren. Dort werde ich einen Job erstellen (weil ich noch keinen habe) und diese neue Account Struktur importieren.

Abbildung 25: Unter Application die MyPBCS auswählen und dann Export wählen.

Abbildung 26: Export aus EDMCS direkt in die PBCS Anwendung.

Abbildung 27: Aus PBCS kurz herunterladen um zu sehen…

Abbildung 28: …ob das Account da ist. Ja, alles gut.

Abbildung 29: In PBCS > Overview > Dimensions zum Importieren der Meta Daten.

Abbildung 30: In der Inbox steht die CSV Datei.

Abbildung 31: Einen Job erstellen um die Datei zu importieren.

Abbildung 32: Importieren der Accout Metadaten in PBCS.

Abbildung 33: Im Jobviewer sehen wir das der Import und der Refresh gelaufen sind.

Abbildung 34: Wir sehen den neuen Account in PBCS.

Damit sind wir am Ende der Vorstellung von Data Management Cloud angekommen. Ich hoffe, ich konnte ihnen einen guten ersten Einblick in dieses Produkt geben. Ich habe nur oberflächlich die Funktionalität und Benutzerfreundlichkeit zeigen können. Selbst bin ich begeistert von dem Produkt und glaube, das es so einige „handgestrickte“ Anwendung ersetzen kann mit einem viel besseren Konzept und Prozess.

Ihr Philip Hulsebosch.