SAP Knowledge Base Article - Public

2766870 - Role Based Permissions (RBP) Refresh Framework FAQ - SuccessFactors

Symptom

This KB article provides a FAQ to outline the benefits and advantages of enabling the RBP Refresh Framework

Environment

SAP SuccessFactors HXM Suite

Cause

Benefits

The Refresh Framework improves the stability of group refresh and the performance in some heavy workload scenarios, by automatically switching between the buffer mode and the on-demand (real-time) mode based on the detected refresh workload

Resolution

1. What are the advantages to enabling the Refresh Framework?

The Refresh Framework improves the stability of group refresh, and the performance in some heavy workload scenarios.

The refresh framework can automatically switch between buffer mode and on-demand mode based on the detected refresh workload:

  • When light workload is detected, the framework switches to on-demand mode (previously called real-time mode. For example, when an API request changes a user, a refresh on all user groups is triggered.)
  • When a heavy workload is detected, the buffer mode is enabled. That means all requests within the next five minutes are buffered and scheduled in one refresh task. Instead of refreshing the same set of groups and roles with each change, the buffer mode reduces duplicate efforts and only processes the delta changes. It turns the once demanding task of frequently refreshing groups into a much lighter and stable task. It’s also capable of handling some of the heavy workloads cases without having to turn on the timely refresh which requires one hour waiting time. With the buffer mode, you’ll notice very little delay and will save database resources by removing duplicate requests.

2. What generated High Number of RBP Job executions?

Changes to your users information will cause dynamic groups to refresh and RBP granted roles to refresh. This is because dynamic groups are defined based on user information. The types of user information changes can be:

  • API calls to update or insert users
  • Changes from user management
  • Employee Central changes to modify EC related definition or EC employee field values.

When many changes occur in a short period of time, frequent on-demand refresh jobs are triggered. This results in a high CPU usage in the data center.

We highly recommend that you reduce duplicate requests to avoid frequent RBP refresh jobs, which can cause longer waiting time.

3. What Is the current RBP refresh setup? Explain how it works?

In the current RBP setup, on-demand refresh is triggered by the system after each user information change.

For example, updates made to the user management page for a single user will cause two refresh jobs. The first job is to update the dynamic group members, based on the latest user details. The second job is to update granted permissions, based on the result of the first job.

If the update made to the user moves the user from department A to department B, the first job recalculates the group memberships.

For example, if there is one group defined as “All Users in Department A”, this group must update its memberships to remove the updated user from this group.

After the system updates the group, the permission roles which are defined based on this group, gets updated as well.

For example, if one role uses the previously updated group as the access group, then that means that “All users from department A” will be granted to this role. When the updated user is removed from the group, the user should also get removed from the role as well.  So a second job handles this refresh.

4. What is the solution to high CPU usage?

The best practices from SAP is to use the Refresh Framework to handle the high volume of update actions.  The Refresh Framework will automatically switch between the two modes.

  1. On demand mode:  When the update volume is low, each update action still triggers its own refresh jobs, which is no different from the current behavior.
  2. Buffer mode: When the update volume is high, the framework buffers the refresh request for 5 minutes. Because the refresh requests are always based on the same set of groups and roles, by buffering the request we can avoid duplicate refresh actions within the 5 minutes.

5. Is there any negative impact?

  • If there are no updates there is no impact the refresh will work as always in real-time.

Negative impact.png

6. Are there any risks to turning on the refresh framework?

There are no risks in using the refresh framework. In some cases, you might experience slightly longer refreshing time when the buffer mode is on. However, the refresh framework can significantly improve the overall stability and performance of the system.

7. What is the plan to roll out the refresh framework?

As of November 2019, we have already turned on the refresh framework 2.0 for the all Datacenter.

Only customers running RBP Rules job will not be effected by the change.

8. Can I use my system while you enable the refresh framework?

Yes, you can use your system as you normally would.

If you would like to set up "New RBP Refresh Framework" for your company please open an incident with Product Support under component LOD-SF-PLT-RBP 

Note: For Partners never turn off refresh framework in provisioning without engineering team review. All instances should be running with either RBP refresh framework or refresh RBP rules Job , otherwise the CPU spike caused by this job would easily occur.

See Also

Product Support see Internal Memo for additional details on enablement of the framework

Keywords

SF, success factors, Performance, Issues, Refresh Permissions ,  enable RBP Refresh Framework, New Refresh Framework, RBP Changes, Realtime refresh , KBA , LOD-SF-PLT , Platform Foundational Capabilities , LOD-SF-PLT-RBP , Role Based Permissions , How To

Product

SAP SuccessFactors HXM Suite all versions