Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. —Antoine De Saint-Exupéry, Airman's Odyssey   MDF Objects and Business Rules are widely used in Platform, Recruiting, Onboarding, Employee Central and other modules of SuccessFactors. And of course, there is much information about each particular feature of the MDF Objects, and each scenario and function of the Business Rules, which is helpful for the configuration of a standalone Business Rule or solving a certain issue. However, there are not many recommendations about building custom solutions with use of a large number of interconnected Business Rules, and there are no guidelines on how to make a solution with many Business Rules to be more understandable and less like a ‘black box.’ In this article, we will give some basic recommendations on building custom solutions based on many Business Rules for MDF Objects. Also, we will share additional information that will help the Employee Central Consultants use the Business Rules more efficiently.

Scenario ‘Rules for MDF Based Objects’

As you know, the Business Rules of scenario Basic might work unexpectedly for MDF Objects. On the contrary, the Business Rules of scenario ‘Rules for MDF Based Objects’ always work as expected. Scenario ‘Rules for MDF Based Objects’ has many advantages, including the following:

• It shows only the functions that are applicable for the particular Purpose
• It is fully built into the Extension Center ^[1]
• It provides navigation from the Business Rule to the Event(s) where the Rule is executed, as shown in Figure 1.

[caption id="attachment_38375" align="alignnone" width="700"] Figure 1 — Navigation to the Rule’s Event and the Extension Center with use of the Rule Assignment tool[/caption] We recommend that you always use the Business Rules of scenario ‘Rules for MDF Based Objects’ when working with the MDF Objects because the scenario is reliable and user-friendly. However, if you have already assigned the Basic Rule to the MDF Object, then you can change the Rule’s scenario with use of the Change Scenario tool (see Figure 1). For details about the tool, see the guide Implementing Business Rules in SAP SuccessFactors, § 10 Changing a Rule Scenario, p. 71.

Rule ID

When you create an MDF Business Rule, you see the fields as shown in Figure 2. In this article, we will focus on three of them: Rule ID, Rule Name, and Purpose. For details about the other fields, see the guide Implementing the Metadata Framework (MDF), § 11.1.1 Configuring a Business Rule for MDF, p. 136. [caption id="attachment_38377" align="alignnone" width="671"] Figure 2 — Fields of the Business Rule for MDF Based Objects[/caption] The Rule ID field is modifiable only when the Business Rule is not assigned to the Object Definitions. At the same time, Rule ID is the key that is used to import and export the Business Rule and its assignments to the Object Definitions. We recommend using Rule ID as the ‘Biographical Info’ of the Business Rule and storing here the unchangeable facts about the Rule that will help identify, search, import and export the Rule itself and its assignments. Below are some examples of the fixed facts about the Rule:

• Abbreviation of the implementation project
• Code of the Base Object (e.g., JobClassification)
• Purpose (Initialize, Validate, Evaluate, Workflow, Alert and On‑Load) ^[2]
• Code of the Field that holds the idea of the Business Rule (for example, ‘externalCode’ if the Rule performs the auto-numbering, or ‘department’ if the Rule inherits data from the Department to the Position).

Here are some examples of Rule IDs that contain the fixed facts: ACME_Position_Initialize, ACME_Position_externalCode_Evaluate, ACME_Position_Workflow, ACME_Position_department_Evaluate, ACME_Position_jobCode_Evaluate. The Rule ID field is 127 characters long, which is enough for all fixed facts about the Business Rule.

Rule Name

Rule Name can be changed anytime. Rule Name and ID are always visible in the configurational tools, which includes:

• Configure Business Rules, where the Business Rules are created, read, modified and deleted
• Configure Object Definitions, where the Business Rules are assigned to the following Events: On‑Change, Initialize, Validate, Save, Post‑Save and Delete
• Manage Data, where in the ‘Object Configuration’, the Business Rules are assigned to the On‑Load Event for the Standard UI of the MDF Object
• Manage Configuration UI, where the Business Rules are assigned to the On‑Load Event for the Configurable UI of the MDF Object.

Being modifiable and visible on UIs, Rule Name is the ideal place to store the changeable configurational details about the Business Rules, including:

• Actions to be done with the Rule (e.g., ‘to be deleted’, ‘to be replaced’, ‘to be checked’, ‘to becorrected’, ‘being corrected’)
• The Event(s) on which the Rule is executed:
  • The Validate-Purposed Rules can be executed within the On‑Change, Save, Post-Save and Delete Events
  • The Evaluate-Purposed Rules can be executed within the On‑Change and Save Events
  • The Workflow-Purposed Rules can be executed on the Save and Delete Events
• The order in which the Rule is executed on the Event(s), which is important to know if the output of the first-executed Rule is used as the input for the next Rules
• The previous Rule ID if there was a change in the naming convention
• The changeable IF conditions, the fields to be changed, etc.

Ideally, Rule Name should store all key facts about the changeable configuration of the Business Rule and help understand it even before you open it. Also, it is a good practice to duplicate the Rule ID in the Rule Name (and thus to show that there were no changes in the naming convention). In Figure 3, there are some examples of Rule Names and explanation of the key facts. The Rule Name field is 128 characters long, which is enough for all key facts about the Business Rule. [caption id="attachment_38378" align="alignnone" width="640"] Figure 3 — Examples of Rule Names that contain the key facts of the changeable configuration[/caption]

The Order of the Evaluate-Purposed Business Rules Within One Event

Within an Event, the Business Rules are executed in the same order in which they are assigned to the Event. The only exception here are the Workflow-Purposed Business Rules, which have fixed positions within the Save and Delete Events. The order of Business Rules becomes important only if some Rules consume output of the antecedent Rules, which is technically possible for Rules of Initialize, On‑Load and Evaluate Purposes. Though technically possible, the supplier-consumer chains of the OnLoad- and Initialize-Purposed Rules should be avoided because such configuration is overcomplicated. On the contrary, the Evaluate-Purposed Rules are frequently arraigned into the consumer-supplier chains, which is applicable only to the On‑Change and Save Events. Figure 4 shows an example of the Event with six Evaluate-Purposed Business Rules that are grouped into three relative positions. The Rules of each relative position have either a common supplier Rule or a common consumer Rule. The Rules within one relative position do not influence each other and can be executed in any order. If you build a supplier-consumer chain of Rules, we recommend storing the order (i.e., the relative position) in the Rule Name field. As shown in Figure 4, it is a good practice to use step 10 or more for the numeration of the relative positions, which might be useful in case you need to insert an additional relative position in between. [caption id="attachment_38379" align="alignnone" width="424"] Figure 4 — An example of Event when six Business Rules are grouped into three relative positions[/caption]

Position of the Workflow-Purposed Business Rules Within the Save and Delete Events

As we have already mentioned, the Workflow-Purposed Rules do not respect the order of the assignment in the Object Definitions and have fixed positions within the Events:

• On the Save Event, the Workflow-Purposed Rule is always executed the first
• On the Delete Event, the Workflow-Purposed Rule is always executed the last.

For more details, see the guide Implementing the Metadata Framework (MDF), § 12.2 Need to Know About Workflows in MDF, p. 162.

The Sequence of the Raise Message Actions

The Raise Message action is used to display Messages and is available for Validate, Evaluate and On‑Load Purposes. There are fixed ‘Message Points’ within the sequence of Events (see the next section of the article below). Within each Point, the Messages are displayed in the same order in which they were raised by the Business Rule(s). Messages of each Event are grouped by Severity (Error, Warning and Info) and displayed after the Event. The dialog box shows only the group of Messages with the highest Severity:

• If there is at least one Error Message, then the dialog box shows only the Error Message(s)
• If there is at least one Warning Message and no Error Messages, then the dialog box shows all Messages as a Warning
• If there are neither Error nor Warning Messages, then the dialog box shows all Info Messages.

The Warning and Info Messages of Save, Validate and Post-Save Events are additionally grouped by Severity and displayed before/after the Workflow Confirmation Pop-Up, as shown in Figure 5. The Workflow Confirmation Pop-Up itself is displayed in the fourth position, after the dialog box with the Save and Validation Warnings and before the Post-Save Error Messages. The Post-Save Error Message is the last moment to stop the system from saving the record, which can be used for validation of configuration in the production instance. The Warning Messages of the Post-Save Event should not be used at all because, normally, they are not displayed. The Info Messages of the Post-Save Event, on the contrary, are preferable because on other Events (i.e., Save and Validate) the Info Messages could be mixed with the Warning Messages (if the latter are raised the last). [caption id="attachment_38381" align="alignnone" width="657"] Figure 5 — The sequence of Messages of Save, Validation and Post Save Events grouped by Severity[/caption]

The Sequence of Events

The sequence of Events of the MDF Object depends on the operation with the Object: View, Create, Insert, Correct (Edit) and Delete. Figure 6 shows the sequence of Events after each operation. For example, as shown in Figure 6, the Insert operation results in the On‑Load Event that is followed by the On‑Change Event with Evaluation and Validation Purposes that is followed by the Save Event with Workflow, Evaluation and Validation Purposes that is followed by the Validate Event that is followed by the Workflow Confirmation Pop-Up that is followed by the Post‑Save Event with Validation and Alert Purposes that might be followed by the On‑Load Event. The On‑Load Event is intended to be used with operation View; however, the Event is also triggered by all other operations (Create, Insert, Correct and Delete). Operations Create, Insert and Correct trigger the On‑Load Event differently, moreover, one and the same operation triggers the Event differently in People Profile and Manage Data. Operation Delete triggers the On-Load Event for the record that is valid for today, and also differently in People Profile and Manage Data. Taking into account all the differences, the On‑Load Event should be used cautiously. The On‑Change Event can be triggered by the Business Rule that is assigned to another On‑Change Event; however, such configuration should be avoided because it is overcomplicated and might result in the circular reference. [caption id="attachment_38382" align="alignnone" width="640"] Figure 6 — The sequence of Events for MDF Business Rules after operations View, Create, Insert, Correct and Delete with MDF Objects 1 In People Profile, only one Info Message can be raised within the On Load Event, and only from the Change History windows 2 The operation might trigger the On Load Event either in People Profile or in Manage Data 3 In People Profile, within the On Change Event, the Info Message can be raised only once 4 In People Profile, within the Delete Event, the Info Messages cannot be raised from the Change History windows 5 Upon deletion, the as-of-today record is displayed or, if none, the earliest future record is displayed, which triggers the respective On Load Event[/caption] For more details about the sequence of Events, see the guide Implementing the Metadata Framework (MDF), § 11.1.3 Order of MDF-Based Rule Execution, p. 140.

The Body of Business Rules

Below we add some general recommendations on how to write the Business Rules:

• The Business Rules should be as simple as possible
• The complex IF statements should be simplified
• The AND operator with a large number of entries should be avoided (e.g., more than 20 entries)
• The more probable conditions should be the first
• The recurring calculations should be replaced with the variables
• The Business Rule should not substitute the associations and field criteria.

Conclusion

Building custom solutions with use of Business Rules requires a thoughtful naming convention, understanding of the Rules’ Events and use of reliable techniques in order to make the new solution less complex, more understandable, more stable and friendly for both the support and the end users. From this article, the reader should have learned:

• The key benefits of using the MDF Business Rules
• The sequence of MDF Business Rules and Messages
• How to build the consumer-supplier chains of Evaluate-Purposed Business Rules.

Reference list

1. Implementing Business Rules in SAP SuccessFactors. Document Version: 2H 2021 – 2022-01-21. Available at https://help.sap.com/doc/8c6720bf5d0b4715ab10fb1b4f69c4f2/2111/en-US/SF_PLT_Implementing_Business_Rules.pdf (Accesses: 26 January 2022).
2. Implementing the Metadata Framework (MDF). Document Version: 2H 2021 – 2022-01-21. Available at https://help.sap.com/doc/067c84408d824c7382637fc264e11310/2111/en-US/SF_IMP_MDF.pdf (Accessed: 26 January 2022).

^[1] Extension Center combines both Configure Business Rules, Configure Object Definitions and Manage Configuration UI. We recommend using if you are new to SuccessFactors Metadata Framework. ^[2] If required, you can change the Purpose of the MDF Business Rule with use of the Change Scenario tool.