Business Rules: Die Auswahl des richtigen Base Objects

Zu den wichtigsten Erweiterungskonzepten in SuccessFactors Employee Central gehören das MDF-Datenmodell sowie Business Rules. Ersteres kann benutzt werden, um gänzlich neue Objekte aber auch Portlets für die Mitarbeiterstammdaten zu erstellen. Business Rules werden durch eine IF-THEN-ELSE Struktur umgesetzt. Wenn also eine Bedingung erfüllt ist, kommt es zu einem bestimmten Systemverhalten. Wichtige Anwendungsbereiche sind das Festlegen von Vorschlagswerten, das Auslösen eines Genehmigungsverfahrens sowie das Anzeigen von Warn- und Fehlermeldungen. 

Beim Erstellen von Business Rules müssen eine ID, ein Titel sowie ein Base Object festgelegt werden. Vielen bereitet die Auswahl des korrekten Base Objects größere Schwierigkeiten. Die entscheidende Frage ist, wodurch die Business Rule ausgelöst werden soll. Wenn beispielsweise beim Anlegen eines neuen Objektes, z.B. einer Position, ein Workflow ausgelöst werden soll, dann ist das Base Object genau dieses Objekt (also „Position“). Der Trigger, also der Auslöser, ist ein onSave Event. Dies bedeutet, dass alle Daten der Position eingegeben werden und beim Betätigen des Speichern-Buttons wird die Business Rule, und damit das Genehmigungsverfahren, ausgelöst.

Oftmals sollen Business Rules im Zusammenhang mit der Änderung der Personalstammdaten aufgerufen werden. Das korrekte Base Object richtet sich hierbei nach dem Portlet, welches bearbeitet wird. 

Job Information vs. Employee Information

Grundsätzlich wird für Änderungen des Job Info Portlets das „Job Information“ Base Object verwendet. Für den Fall, dass die Änderung des Job Info Portlets jedoch während des Einstellungsprozesses erfolgt, wird eine an und für sich korrekte Business Rule nicht aufgerufen. Die Fehlersuche erfolgt oftmals in der Business Rule selbst. Was jedoch das Problem nicht beseitigt. Die Lösung: für Hire/Rehire Prozesse muss das „Employee Information“ Base Object genutzt werden.

Job Information vs. Job Information Model

Grundsätzlich kann in den meisten Fällen problemlos das „Job Information“ Base Object genutzt werden. Soll jedoch geprüft werden, ob der aktuelle und der vorherige Feldwert gleich oder unterschiedlich sind, dann kommt das „Job Information Model“ Base Object zum Zuge. Weitere Anwendungsfälle sind, wenn das sichtbar-Attribut (visibility) oder das Optional/Mussfeld-Attribut (required) unter bestimmten Bedingungen angepasst werden soll. Für manche Mitarbeitergruppen soll bspw. ein Feld angezeigt, für andere ausgeblendet werden.

Wenn nun die Änderung des visibility- oder required-Attributes während eines Hire/Rehire-Prozesses erfolgen soll, ist das hierfür notwendige Base Object „Employee Information Model“. 

Release Update: Setting the Visibility of Fields Using Business Rules

Bisher musste das visibility-Attribut durch das Eintippen eines der Werte „none“, „edit“ oder „view“ gesteuert werden. Dies ist fehleranfällig, nicht zuletzt auch, da auch „true“ und „false“ nicht wirklich falsch klingen (aber nicht zum gewünschten Ergebnis führen). 

Dank der Neuerung steht nun eine Pickliste mit den folgenden Werten zur Verfügung:

• None: Das Feld ist nicht sichtbar.
• Edit: Das Feld ist sichtbar, kann aber auch bearbeitet werden.
• View: Das Feld ist nur sichtbar.

Damit erübrigt sich die Frage wie der korrekte Wert heißt.