Objekte und Regeln für das SuccessFactors Metadata Framework erstellen

Möchten Sie Ihre SuccessFactors-Software erweitern? Dieser Beitrag stellt Best Practices für die Nutzung des SuccessFactors Metadata Frameworks vor.

Das SuccessFactors Metadata Framework (MDF) ermöglicht es Kunden, Objekte, Screens und Geschäftsregeln im SuccessFactors System zu erstellen und zu pflegen. Mit diesen lassen sich die SuccessFactors Funktionalitäten auf einfache Art und Weise erweitern. Davon profitiert in erster Linie die Human-Ressources-Komponente Employee Central, teilweise ist aber auch Compensation und Succession.

Das SuccessFactors Metadata Framework ist einfach zu bedienen und reduziert signifikant die Komplexität und den Aufwand, der nötig ist, um die Employee Central Funktionalitäten zu erweitern. Dies bedeutet aber auch, dass spezielle Praktiken benötigt werden, die sich von jenen unterscheiden, die SAP-Kunden normalerweise für Aktivitäten wie Design und Schulung verwenden, wenn sie diese Funktionen nutzen.

In diesem Artikel stellen wir einige Best Practices vor, die erforderlich sind, wenn MDF verwendet wird und wir geben wichtige Tipps, um Ihnen bei der Verwaltung und dem Support des Prozesses zu helfen.

Governance

Einer der ersten Aspekte jeglicher Entwicklung oder Erweiterung eines Frameworks ist die Berücksichtigung der Governance. Der Schutz eines Systems vor Chaos und Schäden, verursacht durch falsche oder unangemessene Konfiguration, ist von größter Bedeutung – egal ob es sich um Software as a Service (SaaS) oder eine andere Anwendung handelt. 

Da das Erzeugen von Objekten (hier: „Generic Objects“ oder „generische Objekte”), Screens und Regeln im MDF deutlich einfacher und weniger komplex ist als das Erzeugen von Objekten, Infotypen und Screens in SAP, ist eine noch größere Rücksichtname auf die Governance erforderlich.

Aufgrund der reduzierten Komplexität können Kunden generische Objekte ganz leicht selbst erstellen, ohne einen Systemintegrator einzuschalten, der diese Arbeit sonst ausführt. Es ist wichtig, dass die Kunden – und ebenso die Systemintegratoren – sorgfältig über Folgendes nachdenken:

  • Namenskonventionen;
  • Business Cases und Benutzung;
  • Design und Architektur;
  • Dokumentation.

Nutzung und Design

Obwohl generische Objekte für SuccessFactors nicht spezifisch sind, lohnt es sich, sich daran zu erinnern, wie zentral Nutzung und Design für die Festlegung von Business Cases sind und wie wichtig es ist, klare Anforderungen zu definieren. Beispielsweise müssen folgende Fragen geklärt werden:

  • Muss das Objekt effektiv datiert sein?
  • Braucht es Regeln?
  • Welche Datentypen werden für jedes Feld benötigt?
  • Wie wird es mit anderen Objekten verknüpft?
  • Was soll das Layout der Benutzeroberfläche aussehen?

Das Festlegen der Anforderungen zusammen mit einem Consultant, der sich mit MDF auskennt, macht ein architektonisch effizientes Design möglich. Zum Beispiel können in einigen Fällen mehrere effektiv datierte generische Objekte benötigt werden, um eine bestimmte Anforderung zu realisieren. Darüber hinaus kann das Ändern eines generischen Objekts vor und nach einer effektiven Datierung Komplikationen mit dem Objekt und seinen Feldern erzeugen.

Dokumentation

Natürlich müssen alle Systemkonfigurationen auch dokumentiert werden. Beispielsweise muss für generische Objekte sichergestellt sein, dass Design und Abhängigkeiten eines Objekts gut dokumentiert sind – vor allem, wenn es ins Produktivsystem gelegt und dort getestet wird. Die folgenden Punkte sollten gut dokumentiert werden:

  • der Zweck des generischen Objects;
  • die Änderungen an Standardfeldern wie Datentypen oder die Quelle für die gültigen Werte (zum Beispiel eine Auswahlliste oder ein Foundation-Objekt);
  • benutzerdefinierte Felder, die hinzugefügt werden, zusammen mit Details des neuen Feldes (zum Beispiel Datentypen, gültige Werte, Regeln, etc.);
  • Objekte für die MDF-Auswahlliste, die erstellt wurden;
  • Verknüpfungen zwischen dem generischen Objekt und anderen Objekten;
  • Regeln, die erstellt wurden und deren Zuordnung (zum Beispiel bei der Initialisierung [onInit] oder beim Speichern eines Portlets oder Objekts);
  • Berechtigungseinstellungen;
  • ertstellte UI-Konfigurationen und zugehörige Details (zum Beispiel Objektname, Felder, die angezeigt werden sollen, Layout, etc.).

Schulung

Egal, ob vor der Erstellung eines generischen Objekts oder beim fortlaufenden Prozess: Eine kontinuierliche Schulung ist unumgänglich. Das MDF wird mit jedem vierteljährlichen Release verbessert, und obwohl dies keinen nachteiligen Effekt auf bestehende Objekte hat, können neue Features und Funktionen helfen, ein vorhandenes Generic Object oder einen Prozess zu verbessern. Auf diese Weise wird das Objekt effizienter und Prozesse werden weiter automatisiert.

Kunden sollten bei jeder Employee Central Implementierung durch ihre Systemintegratoren in MDF geschult werden. SAP selbst bietet auf dem SAP Service Marketplace eine Dokumentation zu MDF und der Rules Engine an – ebenso wie zu Advances, Alternative Cost Distribution, Deductions, Global Benefits, Income Tax Declarations, Position Management and Time Off (die alle MDF-basiert sind).

Regeln

Die Rules Engine ist ein sehr leistungsfähiger Teil des MDF und gibt Nutzern viele Möglichkeiten, ihre eigene Business-Logik auf das System anzuwenden. 

Ein grundlegendes Verständnis für die verschiedenen mathematischen und datumsspezifischen Operatoren, die für die Regeln zur Verfügung stehen, kann bei der Einrichtung von Warnungen, Benachrichtigungen, numerischen Berechnungen und Time Off Regeln sehr nützlich sein. Die verschiedenen modellbasierten Objekte können effektiv genutzt werden, um Feldattribute zu ändern, wie die Sichtbarkeit eines Feldes oder ob ein Feld erforderlich ist.

Es ist auch wichtig, die Triggerpunkte für Regeln zu verstehen. Diese bestimmen, wie und wann eine Regel ausgelöst wird und wie Regeln allgemein funktionieren. Wenn zum Beispiel eine Regel verwendet wird, um für ein generisches Objekt externen Code automatisch zu erzeugen, falls das externe Code-Feld Attribut „Required“ auf „Yes" gesetzt wird und ein OnChange-Event auf Feldebene oder ein onSave Event auf Objektebene nutzt, so wird es die Fortsetzung der Verarbeitung nicht zulassen, wenn die Objektdaten gespeichert werden.

Oft muss eine Regel für das generische Object erstellt werden, um ein onInit Event auszulösen und den externen Code mit einem Wert (zum Beispiel „Automatic") zu belegen. In diesem Fall muss die Regel, die den externen Code generiert, eine If-Bedingung benutzen, die auf dem vorgegebenen Wert des externen Codefeldes basiert.

Folgen Sie SearchEnterpriseSoftware.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im Dezember 2014 aktualisiert

Erfahren Sie mehr über Cloud Computing

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close