This article provides a FAQ to outline the benefits and advantages of enabling the RBP Refresh Framework
SAP SuccessFactors HCM Suite
The refresh framework can automatically adjust between buffer mode and real-time refresh mode, based on the actual refresh work load.
Enabling the framework will ensure better and more stable performance for the Role Based Permissions Refresh framework for your company.
1. What’s the advantage to enabling the Refresh Framework?
The refresh framework can automatically adjust between buffer mode and real-time refresh mode, based on the actual refresh work load. When the workload is light, the framework will enable on demand or real-time mode. This is the refresh mode that may be most familiar as you may currently use it for each refresh request. For example, an API call to change one user will cause a refresh on all user groups.
When the workload is heavy, on demand is disabled and buffer mode is enabled. That means requests within five minutes will buffer and reschedule tasks based on the buffer refresh request. With buffer mode enabled, you’ll notice very little delay and will save database resources by removing duplicate requests. Instead of refreshing the same set of groups and roles with each new request, the refresh framework will remove the duplicates and only process the delta 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 due to the fact that 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.
The high frequency is caused when many changes occur in a short period of time, that then trigger frequent refresh jobs. This will impact and generate a high CPU usage for the datacenter.
3. What Is the current RBP refresh setup? Explain how it works?
The current Real-time on-demand is triggered by the system, at the end of each user update action
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 previous 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 and how do I prevent this problem?
The best practices from SAP is to use Refresh Framework to handle the high volume of update actions. The Refresh Framework will automatically switch between 2 modes.
- On demand mode: When updating volume is low, each update action will still trigger its own refresh jobs no different from current behavior.
- Buffer mode: When updating volume is high, the framework will buffer the refresh request for 5 minutes, as the refresh requests are always based on the same set of groups and roles, by buffering the request we can avoid those duplicated refresh actions within 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.
- If there is high frequency the refresh will switch to buffer mode which will generate a delay on dynamic group changes and permission granting changes.
- The new user will not appear in the admin user or their manager’s processing target users for 5 minutes if the related module is using RBP to control permissions.
- In addition, the new user will not be able to login for at least 10 minutes.
- Lastly, for user update cases, the granted permission changes for the updated user will have a 10 minutes delay.
6. Are there any risks to turning on the refresh framework?
There are no risks to using the refresh framework. There may be up to 10 minute delay but the refresh framework will save database CPU and other resources.
7. Why hasn’t this refresh framework already been enabled?
For now, turning on the refresh framework requires approval according to the SDO policy. Eventually, the refresh framework will be generally available.
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
Product Support see Internal Memo for addittional details on enablement of the framework
RBP, Role Based Permissions, Refresh Network FAQ, Performance, Issues, Refresh Permissions , RBP Refresh Framework , enable RBP Refresh Framework . rbp refresh framework , New Refresh Framework, RBP, RBP Changes, Permissions, Realtime refresh, Refresh Framework , KBA , LOD-SF-PLT , Foundational Capabilities & Tools , LOD-SF-PLT-RBP , Role Based Permissions , How To