Sequence of events for MDF business rules

Introduction

MDF business rules are executed in the same sequence in which they are assigned to the corresponding event.^[1] However, the sequence of events themselves is fixed and cannot be changed. Likewise, each message is displayed at the moment allotted for it within the sequence of events.

The predefined sequence of events is described in the manual Implementing the Metadata Framework (§ 11.1.3 Order of MDF-Based Rule Execution, page 140), which unfortunately does not show either the full sequence of events or specifics in the message order.

In this article, we will provide the missing details about the sequence of events and messages for MDF rules.

Scenario “Rules for MDF-based Objects”

The above document explains that each scenario for business rules has its own moment within the event, in short, regardless of the actual order within the event, the “Basic” scenario rules are executed before the similar rules of the “MDF-based Object Rules” scenario.^[2]

However, this guide also mentions that the Basic scenario rules should not be used for MDF objects at all, especially for new implementations.

We fully support this recommendation because the MDF-Based Object Rules business rules have many advantages over the rules in the base scenario.

Moreover, if you have already bound the base rule to an MDF object, we recommend that you modify the script using the Edit Script tool (see Figure 1). For more information about this tool, see the manual Implementing Business Rules in SAP SuccessFactors§ 10 Changing a Rule Scenario, p. 71.

Sequence of events

The sequence of events for an MDF object depends on the operation performed on the object: View, Create, Insert New Record, Fix (Edit), and Delete. Figure 2 shows the sequence of events after each operation.

For example, as shown in Figure 2, the “Insert New Record” operation first fires a “On Load” event, followed by a “On Field Change” event with the assignments “Evaluate” and “Verify”, followed by a “Save” event with assignments ‘Workflow’, ‘Evaluate’ and ‘Verify’ followed by a ‘Verify’ event followed by a ‘Confirm Request’ dialog for the workflow followed by a ‘After Save’ event with destinations ‘Validate’ and ‘Alert’ which may be followed by a “On Load” event. See Figure 2 for the “Insert New Record” operation for an explanation.

The On Load event is intended for the View operation, but this event is also raised by all other operations (Create, Insert New Record, Fix, and Delete). The Create, Insert New Record, and Edit operations trigger the On Load event differently, moreover, the same operation triggers this event differently in the Employee Profile and in the Manage Data tool. The Delete operation fires a On Load event for a record that is valid for today, and also differently in the Employee Profile and the Manage Data tool. With all of these differences in mind, the On Load event should be used with care and thoroughly tested.

The On Field Change event can be triggered by a business rule assigned to another On Field Change event. Some may think that this opens up new horizons for automation, but such settings are unnecessarily complicated and, moreover, can lead to circular references, so, as a rule, such settings are best avoided.

_{^one If the data is entered in the Employee Profile, then only one informational message can be generated within the “On Load” event, and only from the “History of Changes” screen. ² This operation can trigger an On Load event either in the Employee Profile or in the Manage Data tool. ³ If the data is entered in the Employee Profile, then only one informational message can be generated within the “On field change” event. ⁴ If data is entered in the Employee Profile, informational messages are not generated from the “History of Changes” screen as part of the “Delete” event. ^five After deleting an entry, the current entry is displayed, and if not, then the earliest future entry, which, in turn, triggers the corresponding On Load event.}

Figure 3 shows what elements the sequence of events consists of.

See the manual for details on the sequence of events. Implementing the Metadata Framework (MDF)§ 11.1.3 Order of MDF-Based Rule Execution, page 140.

Moment for a business rule with the assignment “Workflow” within the “Save” and “Delete” events

In Figure 2, business rules with a Workflow assignment are greyed out because they are independent of the assignment order in the Object Definition and are always executed at their designated time:

• On the Save event, this business rule is executed first;

• On the “Delete” event, this business rule is executed last.

See manual for details Implementing the Metadata Framework (MDF)§ 12.2 Need to Know About Workflows in MDF, page 162.

Sequence of actions “Generate a message”

The “Generate message” action is used to display pop-up messages from rules with the assignments “Check”, “Evaluate” and “On Load”. Messages are displayed at fixed times within a sequence of events, as shown in Figure 2. Within each moment, messages are displayed in the same order in which they were generated by the corresponding business rules.

All messages generated by a single event are grouped by severity (Error, Warning, and Information) and displayed when the corresponding event ends. The dialog box displays only the group of messages with the highest severity:

1. If there is at least one error message, then the dialog only displays error messages;

2. If there is at least one warning and no error messages, then the dialog displays all messages, including informational ones, as a single warning;

3. If there are no error messages or warnings, then the dialog box displays all informational messages.

Warnings and informational messages generated by Save, Review, and After Save events are further grouped by severity and displayed before/after the Confirm Request dialog box for the workflow, as shown in Figure 4.

If we consider the sequence of all pop-up windows generated by these events, then the Confirm Request dialog box is displayed fourth in a row, namely: after the dialog box with warnings for the “Save” and “Validate” events and before the error messages for the “After saving” event “.

Below are some examples of using different types of messages:

• The “After saving” event error message (see number 5 in Figure 4) is the last time you can block saving the record, which is useful for checking settings on a production system.

• Alerts for the “After Save” event should not be used at all, as they are not normally displayed.

• In contrast, informational messages on the “After Save” event are preferred because the other two events (“Save” and “Validate”) can mix informational messages with warnings.

Conclusion

The sequence of events, business rules, and messages is a complex topic that is not fully covered in the reference manuals. The technical details provided in this article will help the reader to better understand MDF business rules and greatly improve decisions based on MDF objects.

Bibliography

1. Latyshenko V. V. Build Custom Solutions Using Business Rules for MDF Objects [Электронный ресурс] // SAPinsider. 2022 URL: https://sapinsider.org/expert-insights/build-custom-solutions-using-business-rules-for-mdf-objects/ (Accessed: 03/23/2022).

2. Implementing Business Rules in SAP SuccessFactors. Document Version: 2H 2021 – 2022-03-18 [Электронный ресурс]. URL: https://help.sap.com/doc/8c6720bf5d0b4715ab10fb1b4f69c4f2/latest/en-US/SF_PLT_Implementing_Business_Rules.pdf (Accessed: 03/23/2022).

3. Implementing the Metadata Framework (MDF). Document Version: 2H 2021 – 2022-03-18 [Электронный ресурс]. URL: https://help.sap.com/doc/067c84408d824c7382637fc264e11310/latest/en-US/SF_IMP_MDF.pdf (Accessed: 03/23/2022).

^{[1] With the exception of MDF rules with the assignment “Document Flow”, which are executed at the time allotted for them.}

^{[2] Except for a business rule that triggers a workflow within the “Save” event, when an MDF rule with a “Workflow” assignment precedes the base rules.}