As part of the SAP PRESS title SuccessFactors with SAP ERP HCM I was lucky enough to have an hour-long private session with Mike Rossi about the SuccessFactors Metadata Framework (MDF). Mike was kind enough to give me an overview of some of the details of the MDF, as well as some of the upcoming functionality. In this blog I’m going to provide a high-level overview of the MDF, how it works, and what it means to customers and consultants.
About the MDF
The MDF is a UI-based configuration and extension framework that provides creation, modification, maintenance, and deletion of custom objects (called Metadata Objects) within the SuccessFactors HCM suite. It replaces XML-based configuration and the need to import Master Data via CSV/Excel files. It is also leveraged by the SAP HANA Cloud Platform.
At its core the MDF provides one generic set of the components that are re-used by all objects. This is because each object’s data is Metadata – nothing is hard-coded within the SuccessFactors system. These components include:
- API
- Controller
- User Interface (UI)
- Workflow
- Data Access Object (DAO)
- Database table
- Implementation of Role-Based Permissions (RBP) Security
- Logic Services
- Set of Java services
- Reporting integration
This means that there is no additional processing or memory consumption to use additional custom objects in the system. It also means that there is a common framework for the objects; the Metadata Objects only need their behavior to be configured through the UI and they have consistent behavior and design. And, most importantly, there is upgradability because standard objects and components are not changed. For example, when creating a Metadata Object attributes such as field names, the field data type, and the validation rules for each field are configured. The components such as the API, user interface, and database tables do not require configuration – they automatically work with the user’s custom definitions. All of this means that SuccessFactors can deliver features faster as they do not need to write code and customers can extend their system without the need to write a single line of code.
Customers cannot overwrite standard SuccessFactors objects, but through the MDF they can configure standard objects with their own customers-specific attributes. For example a customer could create attributes of a Job Code object that are specific to their business, but this would not change the SuccessFactors Job Code object – the customer’s changes would be saved separately and would just override those supplied as standard. From a customer perspective they are unable to identify this, but from a technical perspective it helps maintain upgradability of the system.
Although SuccessFactors applications do not use genuine objects in many of the Talent Management applications, this will change once the MDF is rolled out across the SuccessFactors HCM suite. Currently it is available in Employee Central and Succession, Time Off, and the new Job Description Manager application. There are further plans to extend it across the entire SuccessFactors HCM suite. For example, it is planned for SuccessFactors Recruiting to use the MDF from 1311 with more functionality added in the next 2 releases. Since this requires re-architecting of the Database layer and Application layer then this is by no means an easy activity.
Metadata Objects
The structure of each Metadata Object is fixed, although there is a degree of flexibility. Customers have the ability to add up to 200 custom fields for each Metadata Object, in addition to the standard attributes that are required. These required attributes can be seen in the screenshot below.
There are also some attributes that contain system assigned data, including Internal ID, Creator, Creation Date, Last Modifier, and Modified Date.
Metadata Objects can leverage effective dating if required and labels and data can be maintained in multiple languages if any are enabled in the system. They can also have associations (relationships) assigned, just as it is possible with standard objects. And Metadata Objects can have rules triggered at 9 specific points within its transaction flow. These points are called Hooks and allow rules to be executed at point such as during object initialization, when a field is changed, before data is saved, or after data is saved etc. Here is an example of the Position object with rules assigned during the initialization or creation of a position. You can assign more than rule at Hook.
In addition to the standard Metadata Objects there are also other types of Metadata Object, such as Rules, UI components, and Picklists. I will not cover these in this blog, although Rules and Picklists are covered in the blog Rules and Picklists in the SuccessFactors Metadata Framework.
Using the MDF
The MDF is accessible in OneAdmin for system administrators – these are under Company Settings and Employee Files.
Below shows the Employee Files options in OneAdmin. Note that the transactions for Manage Time Off Structures and Manage Time Off Calendars are not available unless the Time Off feature has been switched on.
In the old Admin Tools look for the section called Generic Objects.
OneAdmin provides multiple options for managing different types of Metadata Objects. It also allows you to import or export Metadata Objects. These options are:
- Configure Generic Object Definition: Create, modify, or delete Metadata Objects (e.g. Building object) and Picklists
- Manage Generic Objects: Create and maintain instances of Metadata Objects (e.g. Building number)
- Manage Rule Objects: Create rules and validations
- Manage Position Objects: Perform Position Management that is used within Succession & Development
- Manage Time Off Structures: Create, modify, and delete different Time Off structures (e.g. Work Schedule)
- Manage Time Off Calendars: Create, modify, and delete holiday calendars
- Manage Config UI: User interface designer
- Generic Objects Import/Export: import or export Metadata Object data
The screenshot below shows a new instance of the Country object being created in Manage Generic Objects.
MDF v SAP HCM
The principles and technical aspects of MDF differ from SAP HCM. Within SAP HCM when you create an object type, very little object-specific information is maintained. Rather, the infotypes and allowed relationships for the object type are maintained. New fields for new objects require new infotypes or using standard infotype fields in a different way from which they were designed. For more detail on the process of creating new object types see this blog.
In SuccessFactors – as we have seen – the process for creating an object is based in a single screen and is significantly simplified. Although more data can be maintained, it is structured and easy-to-use each time that you create an object.
What the MDF means for customers and consultants
The MDF means simplification and flexibility for creating new objects. It provides a flexible and consistent framework for customers and consultants to extend the object model of SuccessFactors and add their own unique objects, rules, validations, business logic, and UIs to SuccessFactors. It also means that while the SuccessFactors system is adaptable, it retains its upgradability and protects both the application and the customer from issues caused by enhancing the standard system.
However, it should be noted that management of the system is still required and the MDF is not intended to be available to large audiences. Rather, it should be managed in the same way that the authorizations are managed to restrict access to transactions in SAP in which objects can be created or maintained. It should also be managed as such so that Master Data is created by a central team, as would be the case with SAP. Saying that, the MDF now makes it possible for a business user to be able to enhance the standard SuccessFactors system without relying on a technical consultant or other technical individual to do this.
For consultants, it removes the need to maintain XML and thus reduces the likelihood of introducing errors into the system. In my experience of XML, it can be easy to introduce small errors that render the XML unparseable and are difficult to identify. It also makes extending the system much quicker and provides an object-orientated approach to data design and maintenance.
