Predicate and Propositional logic was the only subject in university that I failed (if only partial points were awarded for partial proofs!). Yet, I find myself applying this form of mathematics all the time in work as part of troubleshooting and problem solving. I must admit also, I can barely do the proofs anymore (goes to show what happens when you stop practising). However, the parts of this maths discipline is around reasoning and logical deductions - the type of mathematics we all use daily without realising. Yep – problem solving! By understanding logic and the concepts, it has helped me to troubleshoot and simply requirements. And in some cases, it has help me provide solutions to questions asked in this space.


So what has this really go to do with GRC? A tad random for me to be writing about something with no direct connection to GRC. Then again, the thought for this blog came to me after assisting a few recent questions relating to MSMP and BRF+ Decision tables. Members of this community were not asking how to resolve an error (that is, they knew how to configure workflow) but more around their design of their workflow and decision table entries (they didn't know what values to specify for the steps). Logically, it became evident that logic was missing.


I won’t attempt to provide a lesson in this mathematics (I couldn't imagine anyone willing to learn from a self-proclaimed failure). However, I thought I might share a slither of my thought process and approach to designing the decision table rules in hope it can help you to determine yours.


I have used this recent question from GRC space as an example of breaking it down - GRC 10.0 BRM : Issue with Decision Table. My workings this blog are not 100% the same as to the answer I gave as I have separated the steps out. However, the answer I provided would also have covered the requirement.



Step 1 – Gather and Record your Requirements


This step does not require changes to your system. Hold back on configuring your system until your think your requirements through. Therefore, you’re working with pen and paper and figuring out your design.


Requirements gathering in its simplest form involves obtaining business statements of what is needed. In this step, avoid the use of technical jargon and write your requirements out in simple English (or whatever your native language is).


You can ask yourself questions such as:

  • Do I have different workflow scenarios depending on the request?
  • What sort of scenarios are they?
  • Will these scenarios require different approval steps?
  • Who are my different approvers (agents)?


In this example, the requirements were already provided (off to a good start to designing the table)


If I select Composite Role it has to go Approver 1 irrespective of any criticality of the role whereas for Single Role if the role criticality is HIGH it has to go to Approver 2 and If the role criticality is MEDIUM and LOW it has to go Approver 3.



Step 2 – Identity your Inputs attributes

By the time you get to step 2 you should have written down all of the scenarios that you can think off for your requirements. The next stage is to go through and find the condition values (attributes) that you can use to configure your rules.


My approach on this one is to go through your statements with a highlighter and colour the attributes that you can see exist for the request type. Depending on how visual you and are how complex your requirement, you might want to use different colours to group the attributes.


For later use (in step 3) you can also highlight the output paths. In this case, these output paths are the identified Approver groups (return results).


1 bus req highlight.png


Once you have gone through and found your condition values, you can then group them together as to identify the attributes:

  • Role Type (e.g. Composite Role, Single Role)
  • Criticality Level (e.g. High, Medium, Low, Any) – in BRF+ it will display as “Crit. Lvl”


At the end of this analysis, you now know that you have two input attributes to use. You can now build the structure of your decision table (you know the inputs from this analysis and you have the outputs due to the rule type – initiator).


2 decision table structure.png


Step 3 – Sequence and Simplify your conditions

As entry to this step, you know you the attributes to enter as the column headings. In this stage, you need to return the original business requirements and rewrite them as a pseudo-logic format based on your inputs and outputs.


3 rule break down.png

Now an example of where Logic comes in (allows you to build a logically equivalent rule) and shows an example between how I wrote suggested the solution versus how it was built is Rule 1.


4 rule example for logic.png

A Logical equivalent of this rule would be replacing the criticality is asterisk with the use of an OR operator and listing out ALL POSSIBLE VALUES for Criticality level


5 rule example for logic equiv.png

The risk of switching to the OR operator is if new Criticality Levels are built, then you have not factored them into this scenario. You then have to update the decision table. For this reason, when you requirement does not require the use of the attribute, I would specify the asterisks. However, the two rules above will return the same result (so long as there are only those 3 criticality levels).


You could approach this sequencing and simplification by drawing a decision tree. If you have completed business process flows, you may not even need to go through this process as the steps are already defined for you. Example of the decision tree, provides a visual flow of your rules which may help you validate them later when you test the rules. It is also a useful approach to use when you are analysing gaps in your requirements.


6 decision tree.png


When breaking this one down, as it was a simply scenario, I realised immediately that 3 lines were needed for the different scenarios. However, where it becomes more complex, you might need to work through a decision flow and refine it until you can see all of the scenarios.


Step 4 – Add your catch-all

Depending on how thorough your rules are, you may have no rules left to capture. This step is important to analyse the business rules that you have devised to make sure you did not miss any possible combinations. If you miss a scenario then your end user will receive an “on submission” of the workflow error.


In this step, you need to look at your business rules and compare to your IMG configuration to determine if there are any possible inputs not yet catered for. In some cases you may be able to simplify your rules by changing the OPERATOR. In other scenarios, you may need to add additional rules (another line item).


As an example, ROLE TYPE is a potential gap. The original requirements only considered two roles types – Single and Composite. However, there are other roles types to choose from (profile, derived, composite, etc). It is hard to know if this is an oversight as part of it comes back to IMG configuration for choosing which role types are in scope. For the purposes of this blog, let’s assume that all role types are required.

The second potential is PRIORITY. If you only list the explicit values – LOW, MEDIUM and HIGH – you risk missing any other configured values. You also risk future IMG configuration requiring creation of a new criticality but the BRF+ decision table is forgotten. For example, there might be a value call CRITICAL.


There are a few ways to add the catch-all


Option 1 Rewrite your rules to cater for them

In the case of the first attempt – you can go through your rules and incorporate it. The risk of this path is that you implicitly include it in an Approver Path instead of going back to your business requirements and confirming them. This option really depends on how well you captures you business requirements in the first place.


For example, in rule 2 and 3 change it to Role Type <> Composite instead of Role Type = Single. For rule 3, change the criticality to not equal high. You have now removed the gap for Role Type and Criticality.


7 catch all rewrite.png


Your risk is whether you have interpreted the requirement correctly in simplifying. For example, what if Non-Composite Roles that have Criticality level of Critical need to go to a different approver (approver4)? This rule will not provide that option. Therefore, your simplification becomes invalid.



Option 2 Add entries to the bottom for each scenario

For each gap, you need to define the requirement and capture it. For example, you have determined that there are only two role types (Single and Composite) but there is another Criticality level – Critical – and you want to route to Approver2.


8 catch all add entries.png


If you have a decision flow diagram, then you would need to update it to reflect the new rule. For each scenario, you would add a new rule to your table.



Option 3 Edit your Existing Rules to Expand

An alternative to Option 2 could involve editing the existing rules to include the missed scenarios. This would depend on the missing gap. Using the same requirement Options 2 (criticality of critical for single roles should go to Approver2) would result in editing rule 2.


9 catch all edit entry.png


Option 4 Wildcard catch all at the very end

If your decision table properties has been configured to only return a single result (which is the first rule evaluated) then you can add a wildcard catch all to the very end. This rule will only be evaluated if all other rules have failed. In this case, would configure an Approver_X (unknown) and consider routing it in MSMP to an Administrator to investigate.


10 catch up wildcard.png


Step 5 – Build and Test your decision table

Finally, you’re at the stage where you have translated your business requirements into business rules. Time to hope into BRF+ and create the decision table. Once you have completed, activate the decision table, functional and application. Finally, you can simulate your rules to verify that you receive the expected result based on your inputs (your decision tree might even help you with your test scenarios).


11 decision table complete.png

Note: configuration screen shot taken from the original thread referenced at the top




Hope this helps you think through your rules and apply a little logic. If you happen to be interested in logic as a topic (and succeed where I failed), this site is useful and includes a Teach Yourself Logic Guide.


What is your approach to breaking down BRF+ rules? Do you take a similar approach or do something different altogether? I would love to hear your thoughts in the comments below.




Surely 2014 was the year of simplicity with SAP's emphasis on simplification, simplicity, "Run simpler," or any of the variations on that theme trumpeted loudly and clearly at every SAP event and opportunity. This new emphasis seemed to be well received by customers, and why not? Who *wouldn't* want their SAP landscape to be simpler and easier to support and sustain? Security is no exception: doing more with less, squeezing a lean team harder to support more projects, more systems, and more users is just the given these days. Assuming that we start with at least a minimum number of well trained and competent SAP security staff, what does it take to simplify security to make it sustainable and bring about sustainable compliance? Here are some suggestions for your consideration.


Consistent security design

In my experience, there is not a "one size fits all" of security design except to say that sustainable results are more likely to be achieved with a consistent design. Are your security roles built using the derived role functionality, the enabler role model, or a haphazard mix of both? Is the design task-based, job-role based, or not clearly one or the other? If Business Role Management (BRM) is in use, is the model easy for the business users to understand? Is it your organization's practice that security roles have standalone integrity, or do some unknown number of them not fully functional unless some other functional role is assigned, which is not documented but "everyone in the plants knows that?" Are end user roles restricted from assignment to the SAP support team, or are exceptions frequent? Whatever approach the organization takes, taking it consistently and documenting it thoroughly will make your security much more sustainable in the long run, reducing the confusion among the people requesting access and the demands on the security resources to maintain and explain it.

Security design aligned with the business model

Whatever the basis of your security role designs, aligning the designs with the business is imperative for simplification. Otherwise, the requesters and role approvers will find themselves in an endless cycle of submitting requests to the security team for adding and removing roles from the users, and adding/ removing access from roles,  in frustrating attempts to get the access levels just right. But what if the jobs are not defined in a consistent manner? Then there is really very little the security team can do until the HR function works with the business to review the job  and task descriptions to improve the consistency.

Organizational standards

In my experience and observation, it is often the case that the organization's management wishes to have users' access restricted organizationally, often for compliance reasons. Whether the division is geographically based, product/service line based, data sensitivity based, or some other reason, sustainable security and compliance is much easier to achieve when the rules are documented, applied consistently, and enforced via automation. There is not much point in stating that users with access to one business unit should not have access to data of another business unit, when one functional area has a different idea from another of what organizational values represent each business unit, and end users are frequently granted roles from more than one functional area.


Furthermore, when the rules must be enforced manually, and approved exceptions are kept in a spreadsheet or file drawer instead of in a GRC toolset, compliance is anything but sustainable.

Governance model

So how does an organization that is lacking in any of these areas bring about the changes that are needed for sustainable security and compliance? In my experience, governance is the key. Role designs should not only be required to meet a documented standard, they should also be subject to periodic governance review. If role designs are any which way that the role owner and/or his/her business lead wish, if organizational standards are only a suggestion instead of a policy, if exceptions are numerous and monitored manually,  the security team will find themselves in an endless cycle of role and user modifications, which can take so much time and effort that value-added proactive initiatives, such as automating the user access review or some of that manual monitoring, are forever on the back burner. Without a governance model that has teeth, the security team may find themselves the scapegoats for the breaches and non compliance that are almost inevitable.


I hope that some of these suggestions spark improvement ideas that help bring about simpler and more sustainable security and compliance in your SAP landscape. Are any such initiatives already in the works for 2015 at your organization or among your clients? I welcome your comments and observations. What did I miss that you have found to be key to sustainable security and compliance?



I am currently working on GRC 10.1 SP05. I could see lot of customers also working on same SP or upgraded to same SP. There are lot of issues in GRC 10.1 SP05 which we came across. I am just updating the issues with relevant SAP notes here just to make it easy for the guys who come across the issues just like mine. Also I am requesting others to contribute by adding in the details which we might had missed out.


There are still lot of issues which we are working on and will update this blog regularly based on our issues and fixes.


NOTE: There can be few SAP notes which SAP might have released specific to us, but if the issue is relevant in your system you can request the same from SAP

101 Blog.png


Access Request Module (ARQ)

Issue 1

Work Inbox – Simplified Not Working

When launching the Work Inbox - Simplified from IE8, it generate the following error messages and it will only display the "Work Inbox" header but the rest of the body are blank.

The following are the error messages:

1. Error


2. ExceptionTypeError: Access is denied.

Replicate the Scenario using below steps

  1. From GRC, execute Tcode NWBC. It will launch IE8 to display Business Client for HTML.
  2. From the Work Inbox section click on Work Inbox - Simplified link. It will launch another IE8 browser for Work Inbox.


Related SAP Note for fix

UI5 libraries which were used for Simplified Access Request have recommendations for IE9 and above, hence it don’t work properly in IE8, so customers using this functionality should upgrade to IE9 and above.

1974672 - Keyword Search in simplified access request/ Approver in Box not opening

Issue 2

We are getting the error "Text 265 Not Found" every time we click the "View Provisioning Logs".

In ST22, it shows some ABAP dump. I have attached the ABAP dump for your analysis.


Steps for Reconstruction 

NWBC->My Home->My Profile->Request Status-> Select a Request -> click on View Provisioning Logs

Related fix

You have missed some Text elements in your system due to which this error is being thrown. For the resolution of this issue, kindly follow the steps mentioned below:

a. Go to Transaction SE24.

b. Enter CL_GRAC_UIBB_ACCESS_REQ_ASSIST and click on display.

c. Click on Goto and select Text elements.

d. Click on edit icon (Ctrl+F1).

e. Enter '265' in Sym and 'Request Key' in Text field.

f. Save and Activate.


Issue 3

This is more of a query. We are trying to configure the system that it automatically perform the risk analysis while submitting an access request. We have configure this and this with config parameter 1071. We found that this functionality is running risk analysis only for one type of risks (Action level, Permission, Critical Action or Critical Permission) based on config parameter 1023, which means it shows incomplete risk analysis results. We want to configure it to run risk analysis for all type of risks.

Related Solution

In that case, you can either remove 1023 parameter from Configuration Parameter list (as mentioned in SAP Note 1733984).


You can maintain multiple values under 1023 parameter (as mentioned in SAP Note 1776542).

This would resolve the issue.

Issue 4

The ABAP program GRAC_REPOSITORY_OBJECT_SYNC didn’t sync the data properly of an EP Connector (X PORTAL). It only properly sync the roles but it didn’t sync the users properly.

It work for other EP Connector (Y PORTAL). They belong to the same connector group (PORTAL_GRP).

The X_PORTAL is a SAP NW 7.4 Portal while Y PORTAL is an SAP NW 7.0 Portal.

We have configured our EP Connector using the instruction in SAP Note 1977781 - GRC 10.1 Enterprise Portal Configuration

We have also applied the instruction in SAP Note 1647157 - How to Setup Access to the SPML Service on AS Java

Replicate the Scenario using below steps

Tcode SE38


Select Profile, Role, User and Role Search check box.

Connector: <Portal Connector>

Run it in foreground.

Related fix

1889792 - UAM: Portal sync results in time out/ Portal Object not getting synched

2008685 - Portal sync in GRC 10.0 is not working

1940769 - Timeout problem in GRAC_REP_OBJ_SYNC

Issue 5

We are always getting ABAP dump every time we run the program GRAC_REPOSITORY_OBJECT_SYNC.

We are consistently getting the error 'SQL error "SQL code: 3135" occurred while accessing table "GRACRLCONN"

Related fix

Jobs are terminated because of the huge Database space Usage and that’s why it is giving dump. So we advised you to schedule a job by selecting option which is really required. If the requirement is related to user only then you should select only user option rest you can uncheck. In this way, you can execute parallel jobs as much as you can. But if you really want to schedule a batch job with all the options then you should schedule one at a time. This is not the application issue it’s all because database usage.

This is a known limitation of any database that can't handle big SQL statements and you can experiment the same issue when you select the data for a particular table in standard ABAP transaction SE11/SE16.

Ex:  Table USR02 and you can put high volume of users into the selection criteria and you will see the same issue.

You may also check Note - 1847034 - Runtime error for very large OpenSQL statements, for additional details.

Issue 6

Currently the GRC system allows all kinds of file types to be attached in the GRC system (Eg. on the BRM and ARQ screens). These file types includes .html or .exe which could contain malicious scripts. If the system is able to prevent certain file types from being uploaded, then the risk is minimized.

Please refer to SAP note 1232736 for the same functionality in SAP GRC Access Control 5.3.

Since it was there in 5.3 our customer is expecting the same in latest version as well

Related fix

Please implement note 2058231 (manual and automatic corrections) in your system. After implementing this note you will have to implement a BADI as shown in the document attached to the note. Then you can maintain configuration parameter 2401 in IMG for the allowed types of files.

Issue 7

We have enabled mitigation control assignment workflow based on the client’s requirement. Workflow is configured to have first level of approver by supervisor who will perform risk analysis and mitigate the risk at this stage.

Based on the GRC 10.1 behavior we have noted below shortfalls:

  1. On request level, access request approver in this case supervisor does not get confirmation on the mitigation control approval submission. There is a submit button and after clicking that the request does not show the mitigation control workflow number.
  2. Mitigation Control assignment number does not match with the access request number and hence the mitigation control approver have no idea about which access request is this approval for. This is major short fall for client which are expected to have high volume of mitigation control assignments.


Related SAP Suggestion

Request number of Control Assignment workflow is generated separately and it would be considered as a separate workflow. Normal Access Request workflow has different request number and flow and control assignment workflow has different request number and flow. These cannot be merged.

However, as far as the linkage is concerned, you can submit this idea on SAP Idea Place and let our Product Management team consider based upon the feedback/voting from the globe or if possible.

Issue 8

We have configured stage level approval and rejection level to "Request" which mean the approver on the stage allowed to approve the whole request or reject whole request. In the above configuration we should not be shown approve and reject button at line item level near user access tab. We have observed that approve and Reject button are still visible and they are non-functional.

Related SAP Fix

2057413 - UAM: Approve/Reject button at Line Item Level not working according to stage level setting

Fix for visibility of reject button under other options after fixing the issue of APPROVE/REJECT buttons at Line Item Level

2066115 - UAM: Reject option not displayed while request approval

Issue 9

For Screens like Model User, Existing Assignment and My Profile there was not feature to filter the records in the upper table

Related SAP Fix

1984995 - Missing Filter for Model User, Existing Assignment and My Profile

Issue 10

We want to achieve that user can only select role from his business process in access request.

The business process field is getting populated from LDAP. We have configured the role selection that business process field is mandatory and non-editable in role selection screen. This works fine that user can only select role from his business process.

We noticed that user cannot edit the auto populated business process field but he can add another business process field on role selection screen and the role search works as 'OR' between both of the business process. This means user can select the roles from both business processes. This system behavior defeats the purpose of having a field as mandatory and Non-Editable in role search. This is a product bug.

Related SAP Fix

2068938   UAM: Duplicate actions shown in the ACTION OVS in access request role search and role search restriction not working in access request

Issue 11

There is no authorization control available to control user as such that they can administer their own jobs. The users should not be allowed to view, delete the result of background job scheduled by other users.

We have run the trace for the back ground jobs and found it doesn't check any authorization object so we can control. This is very basic behavior which should be implemented.

No authorization control for the user to view and adminster his own’s job

The role only has object GRAC_BGJOB with 70. The users will need to adminster their own job and not others job.

Based on the trace enabled only GRAC_BGJOB

User able to delete and administer all jobs in GRC system

Related SAP Fix

Need to put this in GRC Ideas place

Issue 12

We are facing an issue while searching for users from LDAP. If we type a user ID and press ENTER then User details are populated correctly from LDAP. However if we click on button to search user from pop-up screen then system doesn't shows any search result from LDAP.

This was working fine before we implemented a SAP Note 1982896. This functionality is broken by this note.

Related SAP Fix

Kindly implement the note 2025895 after implementing the note 1982896 to resolve the issue

1982896 - UAM: Fuzzy Search is not working on User ID and copy request is not copying line items.

2025895 - UAM: Users not searched from HR/LDAP connectors if Realtime search parameter 2050 is YES

Issue 13

We are facing issue while downloading the default role template to upload default roles. Once we click on default role template button there is no action from system.

Related SAP Fix

2044932 - FPM Search GUIBB: dump or empty screen

2018804 - UAM: Dump in default roles while clicking the Import from file button

2067320 - Default role file import does not support connector group with space

Issue 14

We noticed that in unlock account users are able to add role via existing account option. This should be not allowed. We have given only existing "Unlock Account" action to the unlock request type. This is a bug in system functionality.

Related SAP Fix

2101596 - UAM: In Existing assignment, systems are selectable though request doesn't have any system action.

2048988 - System are selectable in existing assignments for Assign ob


After applying the above notes everything was working fine and then we found out that Business roles are being added from existing assignments when creating unlock account request. Waiting for update from SAP for this issue

Issue 15

We have mapped the business role as default role in our configuration with other single and composite roles. If a user submit the request and this request fulfills the default role criteria, however only single and composite roles are auto populated in request. The configured business roles are not populated in request.

We have already implemented SAP Note “2030797 - Default role is not getting populated in Access Request in case of Business Role”

Related SAP Fix

2077121 - UAM: Business Role as default role is not working for Request level

Issue 16

We are using this GRC End User Login services for all new users to request access to the SAP system. The new users have an LDAP account. We are using SiteMinder to authenticate the user to its LDAP before calling the SAP Webdynpro application. We have enabled the parameter SAP SSO parameter login/accept_sso2_ticket=1 to accept an SSO ticket.

We are having problem on the GRC End User Logon services (Webdynpro application grac_uibb_end_user_login) to authenticate from SiteMinder. The Webdynpro application doesn’t recognize that the user have already been authenticated by SiteMinder. It still show the screen asking for UserId and password.

Is there a configuration that we need to do for the Webdynpro application to authenticate to it?

Related SAP Suggestion

SiteMinder validation is not supported in GRC End user login. Kindly refer the note 1575897 and create an enhancement request in the Idea Place

1575897 - Logging Enhancement Request - Business Objects Access Control

Issue 17

While raising the access request the user selects business role and its validity date for business role is not set automatically. Valid to date is cleared in case of Business Roles. Business Roles doesn’t have validity date.

Related SAP Fix

2095046 - UAM: Business Role Valid to date is blank

Issue 18

We noticed that the drop downs on access request page are not sorted based on description. For Example while selecting the roles the dropdown for Functional Area, Business Process, and Company. These drop downs are not sorted based on the description. These are sorted based on ID which is not visible to the user in drop down. This causes a confusion to the user as they need to browse through the whole list which may go up to 100 line items.

Related SAP Fix

2061817 - UAM: Access Request field values are not sorted with short description

Issue 19

We have configured our LDAP server as a user data source. Our LDAP server has 2 fields (Mail, Mid Mail) which stores the Email ID. System is able to pull the mail information correctly if it is available in any of these fields.

The issue happens when we try to search for users by using Email ID. The search with email ID doesn't work. It simply doesn't return the result.

Related SAP Fix

2102827 - Search LDAP User Using ID and Email Address

Issue 21

We have created an ABAP Webdynpro iView for the GRC application grac_oif_request_approval. This is to ensure that the link will use SSO automatically when clicked inside an email. Everything is working fine except when the user start clicking any link inside the ABAP Webdynpro application. All of the sudden, the link being generated is using a Portal NavigationTarget instead of the usual link generated when launch from SAP ABAP ICM. Because it generated a different link, it doesn't call the correct ABAP service to display the content.

May we know how to force the Portal to use the link generated will follow the link when it is being launch from SAP ABAP ICM.

Related SAP Fix

Waiting for SAP to help with this issue

Issue 22

Every time the user is creating an access request to lock a user in Portal, the following message are generated in the access request log:
Could not update user Attribute "lockreason" on namespace "" of principal "UACC.R3.DATASOURCE.S8".
Object class name does not exist in IDM.
By the way, our Portal UME is using a Backend SAP ABAP.

Related SAP Fix

Waiting for SAP to help with this issue

Issue 23

The default role upload is not working if we include business roles as part of default role. It checks for the system of the role however the system is not applicable in case of business role. This is causing the issue.

We compared the behavior by leaving the system field blank and found that in back-end it stores as "ALL SYSTEM", however if set the business role manually(Without upload) it stores as "BUSINESS_ROLE". Could you check this functionality and provide a fix for us.

Related SAP Fix

2084889 - Default role file import is not working for business role

Issue 24

We noticed that if an Approver (A) delegate his rights to another approver (B). The approver (B) gets the request in their work inbox however they don't get the notification. This cause that delegated approver (B) will not be aware of any new access request routed for his approval.

Related SAP Fix

1589130 - GRC AC 10.0 - MSMP Notification Override BADi - Enabling

1734548 - Delegated Approver is not receiving the Email

2028411 - Workflow delegation BADI not executed during delegation in Access Controls


Business Role Management (BRM)

Issue 1

When risk analysis is performed at the Critical permission level for certain roles with inactive Authorization objects through BRM, the risk is flagged by the system. However, this behavior is not consistent for all roles. In some cases, the roles with the same inactive authorization objects are not flagged.

Related SAP Fix

2036645 - Role Risk Analysis shows inactive authorization objects

Issue 2

We found that Role Search while creating an access request is not correct. The search result is impacted by parameter max no. of result row. It seems system is considering the parameter

"Max no. of result row" to look into the list of role.

For example:

If this parameter is set to 100 then system look for roles only in first 100 roles and shows only 3 roles as result.

If we set this parameter to 50 then system look only in first 50 roles and returns only 2 roles.

Related SAP Fix

2059283 - Role Search is not accurate

Issue 3

Unable to search Business role based on action maintained in single role on role search screen when business role having composite role and that composite role having single role.

Related SAP Fix

2093026 - Unable to search Business role based on action maintained in single role on role search screen

Issue 4

We are facing an issue while importing Composite roles in BRM. System does not import any of composite roles in BRM. We are trying to import the roles from back-end and selecting the role parameters during import process. With the same steps we managed to import all the single roles however not able to import any of the composite role. We have already run authority sync and repository sync job. We have also imported all the single roles associated with composite role.

Related SAP Fix

2027477 - Composite role import is not working

Issue 5

The issue is that when role owner is approving the role changes then he should be aware what all mitigation controls are applied to the role. This can only be possible if include mitigated risk is by default checked while system auto trigger the risk analysis before generating the role.

Risks were not displayed in the Analyze Risks - Role Generation Phase even though risks were displayed in Risk Analysis Phase

Our methodology is as follow:

Define --> Maintain Authorization --> Risk Analysis --> Generate --> Maintain test case --> Approval --> Complete

Related SAP Fix

2075894 - BRM: Risks are not displayed in the Role Generation Phase

Issue 6

We are facing issue in role certification. When user click on the link from role certification. The user is able to view the define tab of role in display mode however if he try to navigate to maintain authorization or risk analysis process step. System gives a dump "Assert Condition violated"

The role owner is not able to see the list of approvers and company mapped with the role. This information is required to certify the role. This information should be available to the role owner in display mode.

Related SAP Fix

2061588 - Assertion failed dump with no edit authorization in role methodology

Issue 7

We found that role prerequisites are not available in Role Parameter import template. These are also a role parameter same like functional area, Company, Business Process. Please rectify the problem and provide a fix to us. We need to upload prerequisite for 6000+ roles. This parameter should be part of Role Import Template.

Related SAP Fix

SAP has provided a Z program and related step by step document. Anyone has the same requirement let us know, I can share the program details here

Issue 8

We found that Role Owner search under "Define Role" Methodology step is working correctly. There are 2 fields (Owner & User ID) to search. If we put user ID (S80*) in user ID field it gives no result. However if we put user ID (S80*) in Owner field we get the search result. If we put user name (MADHU) in Owner field then there is no result and if we put user name in User ID then we can get the result.

The search is not working correctly as per the parameter provided. If we provide Owner it looks in User ID and if we provide User ID it looks into role owner name.

Related SAP Fix

2092209 - Text for user name in approver search help during role definition is ambiguous


Access Risk Analysis (ARA)

Issue 1

We are trying to transport the ruleset from SPRO but it gives error.

Related SAP Fix

1968082 - Not able to create transport for SoD Rules after upgrading to NW 740 SP04

Emergency Access Management (EAM)

Issue 1

We have noticed that some Notification variable for Firefighter log review doesn't get filled in the notification template. Following are the parameters which are nor working.




Related SAP Fix

1983997 - LINK_WORKITEM variable not filled for FF Log Review Report Workflow

Issue 2

We noticed that the FF Log Review report doesn't have any option to relate the logs with the Original Access Request. We want to see this mapping in log review request so that reviewers will be able to match the request justification raised by firefighter and match the activities performed by him.

As we understand this is not available in standard product but this is very critical requirement for Log Review. Could you please let us know any possible workaround to achieve this requirement.


Related SAP Fix

Waiting for SAP update


Issue 3

We are running the GRAC_SPM_LOG_SYNC_UPDATE as a background job in our GRC system to extract GRC SPM log from our ECC Production system. We noticed that we need to increase the parameter rdisp/max_wprun_time considerably high (around 43200 secs) in the ECC system, otherwise the background job will fail in GRC. Our policy is that that the rdisp/max_wprun_time should only be set to 3600 secs (1 hour). This is to ensure that the work process are not block which will lead to system standstill.


If we reset the rdisp/max_wprun_time to 3600 secs, the GRAC_SPM_LOG_SYNC_UPDATE job will fail and the SPM logs that is not sync will also grow, which will make the job runtime even longer.


Is there a way to optimize the GRAC_SPM_LOG_SYNC_UPDATE job performance so that it will fit in the rdisp/max_wprun_time of 3600 secs? Can it have the same behaviour as BW extraction job which is not affected by the parameter rdisp/max_wprun_time even though it runs longer than 3600 secs?


Related SAP Fix

Please check this Notes. It describes the ways of optimizing the performance of EAM sync job.

1617529 - Best Practices For Improving Performance of EAM Log Sync job

1741151 - GRC 10.0 Indexing on CDHDR table in case of time out issue due to huge data

2047097 - Communication failure with remote system (SAP Query)

Reports and Analytics

Issue 1

The access rule library auto pop out once the group rule level is changed.

Please follow flowing steps for reproduction and refer to the attached screenshot.

1. Click on the “Reports and Analytics”

2. Click on Dashboard report “Access Rule Library”

3. Click on the pie chart with high violations and close the window

4. Now change the group level to “Critical Permission”

5. The window is auto populated without users actions

This behavior is an irritant and need to be resolved as this is bug.

Related SAP Fix

2061888 - In Access Rule library report, popup gets open without user action

Issue 2

The report "User to Role relationship" is not working as expected. If there is a role which doesn't have a profile then this report doesn't pick the role in output.

The expected output for this report is to include all the roles which are assigned to the user irrespective of profile of the role as this report is to show the relation between role and user instead of user and profile.

Related SAP Fix

2093024 - User to Role Relationship report not showing roles that does not have any profile generated

2107567 - User to role relationship shows empty profile even for generated roles

Issue 3

Change log report does not show results when the search criteria is in lower case. The report does not have option to save the file in excel.

Reports and Analytics -> Audit Reports -> Change Log Report

Related SAP Fix

2061392 - Role name is case sensitive while executing the change log report

Issue 4

As a part of the UAT phase following issue was noticed in the GRC 10.1 with SP Level 5. The role library dashboard does not have export option in the drill down list.

Related SAP Fix

2062839 - Export option not visible in the drill down of role library report

Issue 5

We noticed that that some reports are giving results in foreground mode however if we schedule the same job in background then it doesn't give any result.

List of Reports which are failing.

1. Role Relationship with User Group (No Output)


Related SAP Fix

2073736 - Role Relationship with user/user group is not working in background option

Issue 6

We have seen incorrect data being populated in the SAP standard dashboard report “Access Requests”. The numbers shown in access request pie chart and shown in request by types for similar period and similar filter criteria are not shown correctly.

Related SAP Fix

2064801 - UAM: Incorrect values displayed in access request report and drill down doesn't display data in provisioning report

Issue 7

We noticed that that some reports are giving results in foreground mode however if we schedule the same job in background then it doesn't give any result.

List of Reports which are failing.

Approver Delegation (Dump)

Related SAP Fix

2083663 - UAM: Approver Delegation report is generating short dump when it is run in background

Issue 8

We noticed that user group filter for the report (List Expired and Expiring roles) is not working. The User group is a very good criteria to list out the appropriate report to consume by user administrator.

Related SAP Fix

2066074 - List Expired and Expiring Roles for Users Report not working

*** Anyone interested to collaborate with the details which can add more value to this blog post, please let me know ***

The Public Company Accounting Oversight Board, established by Congress as part of the Sarbanes-Oxley Act, has responsibility to oversee audits by public companies. Since 2012, the PCAOB has been particularly active, and in September of 2014 the PCAOB announced significant changes to auditing standards have been released and take effect for companies with a fiscal year starting December 15th, 2014 or afterwards - less than two weeks from the time of this writing.


In addition to changes and proposed changes to accounting standards, the PCAOB has been actively releasing staff guidance in the form of practice alerts, directing additional validation of source reporting assumptions, ensuring that system-generated reports are complete and accurate, and verifying top-down risk assessments are conducted (one auditor acquaintance of mine recently termed the current PCAOB validation process “brutal”).

So What Does this Mean for Me?

Practically speaking, SAP customers publicly traded in the U.S. have been seeing and will continue to see increased scrutiny from their external auditors. So what does this mean for SAP customers with U.S. Sarbanes-Oxley obligations? And in particular, what does this mean for SAP customers with SAP Access Control/GRC in place to monitor separation of duties and automate security design and role assignment?


Canned Access Control/GRC reports and rule sets are relatively easy to verify assumptions around completeness and accuracy. That said, the SAP-delivered  rule set is not one size fits all – some high risks for certain industries will be medium risks for others, and vice-versa. For those of you who like to spend this time of year planning strategy for the coming year, I recommend considering the following questions when planning your FY 2015 audit report improvements to stay ahead of trends in SOX reporting requirements:


  • Have we conducted a top-down risk assessment with high, medium and low SOD risks in our AC/GRC rule set(s) in scope, and have the results been verified and signed off on by senior management? And are we able to trace rule set changes to findings in this risk assessment?
  • Mitigating controls are, by design, limited to being effective for one year. Still, many SAP customers will re-apply them for another year without giving a whole lot of thought to the underlying assumptions. Did your risk assessment ensure that the residual risk after mitigating controls is in effect is acceptable? And is there traceability of these management signoffs to your mitigating controls?
  • Are my technical controls for my GRC landscape adequately defined and documented? Have we spent time adequately negative testing GRC roles (for example, can mitigating controls owners approve firefighter requests?)
  • Have my risk owners been adequately defined by senior management and adequately documented?
  • Have my BPOs been adequately defined by senior management?


Final Thoughts

The PCAOB practice and standards changes have had and will continue to have an impact; the full extent of that impact has yet to be determined. That said, early compliance will have significantly less organizational impact than mid-year remediation.  It never hurts to plan ahead!


Related Reading


In MSMP, Access Controls 10.0 and 10.1 provides extremely flexible and powerful tool to configure workflows. In this document we will see how to create BRF+ (NOT line item by line item) MSMP agent rule by taking example of real business case in context of Access Request.



In GRC 10/10.1 SAP has provided different ways for determining agents for a stage in access request. This scenario is more to determine the Role Owner for a role using Custom BRF+ application based on Functional Area field.

Functional area is a table.  It is possible to maintain multiple functional areas in roles, so it is not possible to directly use functional area as attribute for roles in BRF+ decision table. Hence, this blog has been created which will be helpful for the consultants who have the requirement to use Functional Area as an attribute in determining the agent for roles. The below mentioned BRF+ agent rule is developed assuming each role will have a unique functional area


Ref SAP Note: 1890452 - Functional area attribute for role is not picked up by BRF+ rule

Ref Discussion on SCN:


Steps to build the BRF Rule:


Creating BRF+ Rule for determining Agent based on Functional Area

You have to generate the BRF Rule via Transaction SPRO in GRC system. Follow the below steps in your GRC system.

Run the transaction SPRO, Go to IMG => Governance, Risk and Compliance =>Access Control =>Workflow for Access Control  => Define Workflow related MSMP rules.


Directly execute Tcode GRFNMW_DEV_RULES

  • Fill generation criteria (Process ID, Rule type, etc.)
  • Specify Generation options
  • Generate rule shell (Execute button)


Click Execute or Press F8. This now generates a successful message for BRFPlus Rule with name and ID. You can run BRF+ Tcode and can check the newly created BRF+ application there.

Now you can see the created BRF+ application as shown below.

Functions Signature Update

In BRF+ function, change the mode to “Event Mode” and activate the function as shown below

  • Since Function mode has been changed to “Event mode,” the result data object has changed automatically, so it has to be reset manually
  • In “Signature” tab of BRF Function, change the result data object to GRFN_MW_T_AGENT_ID


Create Ruleset in BRF+ Application

Create Ruleset in your BRF+ application by clicking on “Create Ruleset” button under “ASSIGNED RULESETS” tab of function. Ruleset is a combination of business rules that can only be assigned to a function in the BRFPlus framework.


Enter any name for the Ruleset and click on “Create and Navigate to object” as shown below

Ruleset will be created and you will be shown a success message as shown below

Create Rule within Ruleset - Create Expression of Type “Loop”

  1. Click on “Insert Rule” button to create new rule
  2. From within rule, click on “Add” -> “Process Expression” -> “Create” to create a new expression
  3. Create expression of type “Loop” and provide suitable name and description




Loop gets created as shown below. Processing Mode and Loop Mode maintain as mentioned below.

Create Rules within Loop Expression

First Rule





Create expression of type “Table Operation” and provide suitable name and description. In this Table Operation, we will fetch the Functional area value from Functional area table and return the result in to Functional Area field which is part of structure GRAC_S_API_ROLE_FUNC_AREA





Second Rule

Create an expression of type DECISION TABLE as shown below and create a rule change agent ID in agent ID structure after processing each entry in Decision table.












Third Rule

Third rule is used to assign value to context as shown below. This rule will be included in your loop for inserting the values into Agent ID table after processing each LineItem.



When an employee joins the company he requires SAP Access. The general process I the manager or supervisor of the employees sends an email to the SAP Security with the required roles and the user is provisioned in the required backend systems. This process does works but everything is manual and there is no clear audit trail. There is also no guarantee that the roles were properly assigned.




This is where the SAP GRC 10.0 User Provisioning tool can help. The key engine which drives this process of the approval workflow is called MSMP - Multi Step Multi Process. This will automate the process. Let us understand the MSMP from high level so beginner can understand the configuration


Step 1 ( Process Global Settings) - Execute MSMP Configuration from the SPRO menu to come to MSMP main screen. Here you need to note the process ID which is SAP_GRAC_ACCESS_REQUEST and it is liked to GRAC_AR_INITIATOR. Only one initiator can be linked to the process id.



Step 2:  (Maintain rules) - In this step we are going to look at the result value of the GRAC_AR_INITIATOR which drives the path of the work flow. Here the GRAC_DEFAULT_RESULT is the result value. This value will be used to find out how the request is going to flow when you create a request


MSMP_2_Maintain Rules.jpg


Step 6 (Maintain Route Mapping) – In this step we look for the GRAC_DEFAULT_RESULT and see which path it is mapped to GRAC_DEFAULT_PATH


MSMP_3_Routing Path.jpg


Step 5 Maintain Path – In this setting we look for the GRAC_DEFAULT_PATH and identify the Stage in the Path. This shows that there are two stages which are manager and Security. Now we need to understand how the approvers are assigned to the stages. The approvers assigned to the stage are ZGRC_MANAGER and ZGRC_SECURITY






Step 3 Maintain Agents – In this step we are looking are defining the agents and linking them to the PFCG role. The users assigned to this role will be the approvers of the request coming to this stage




Now when you create a request the following high lighted request which are mapped to Process id SAP_GRAC_ACCESS_REQUEST will follow these two steps and get provisionined into the system


Hope this help. Give your feed back and comments

GRC 10.x being based on ABAP, we know that a lot of configuration can be built in the development GRC box and then moved along through the GRC landscape.


Lets take a typical landscape comprising of three GRC systems; development, quality and production. Usually, the quality and production boxes are closed for changes on them. During GRC AC implementation's realization phases, all configuration of GRC AC is done on the GRC development box and all changes are then moved to quality and production.


Following are the basic requirements for the configuration of access control:


1. RFC connections to backend systems done by basis.

2. These RFCs to be used then into configuration settings; like: user defaults, PSS, BRF plus rules, etc.


Considering that a lot of configuration is attached to RFC names there needs to be a way to be able to efficiently manage the changes through the landscape.


For example in user defaults, we tag the defaults to an RFC name and a default ID is assigned to this record automatically. Which is then in-turn used in the BRF plus user default rule.


Now lets consider the following options for change management, each has its pros-cons. I would really like to get feedback and better understand which one is better considered across implementations. Or if there is much better alternative to balance efficiency and trace-ability.




Here we have the RFC named as per regular conventions <SID>CLNT<Client#>; example - ECDCLNT100. So, here we have the following connections:


2014-10-23 17_08_55-Presentation1.jpg

Each RFC from the GRC box to its ECC counterpart is named per its SID and client number.

Now in development GRC we build the user default configuration with ECDCLNT100 and tag different defaults to it. Everything works fine.


Then post-unit testing we move the configurations to Quality GRC box. Here in the Quality box, the config entry comes through the transport and is maintained as ECDCLNT100. Which is not present in the GRC quality! also the quality ECC is on a different RFC.


Thus, the user defaults does not work in Quality box. To fix it, the quality box is to be opened by basis and the entry fixed manually directly in the QA box. Now think of the effort of manual fix multiplied by the number of clients + exposure and risk of opening the clients for every little change related to RFC names.


The only seeming benefit here is that you get to use the regular RFCs and they are of standard naming convention that can/might be helpful for basis team members to track the RFCs by name.




Here we have GRC specific RFCs with same names across the landscape. The would ofcourse connect to the respective ECC client but their names would be same.


2014-10-23 17_09_14-Presentation1.jpg

ECC_GRC is the RFC for connecting GRC box to ECC box. This ECC_GRC sitting on GRC Development connects to ECC development, ECC_GRC sitting on GRC Quality connects to ECC quality and so on. The exact target entity can always be mentioned in the description of the RFC.


Now coming back to the user default configuration, in this option we tag the defaults to "ECC_GRC" in development system. And transport it to Quality box. And it works! No manual changes needed.


The only catch here is that the set of RFCs to backend systems needs to be created by basis on GRC development, quality and production boxes, which is a one time activity.




I have personally liked the option 2, since it brings down the change and maintenance efforts to minimum and eliminates client opening risks for small regular changes.


As a closure to this blog I request experts to share experiences and design of change management of configuration across the GRC landscape. If there are other options to use, if these options can be bettered?




More and more organizations are adopting Enterprise Risk Management (ERM) frameworks to respond to regulatory pressures.  And with good reason.


In their 2014 Report on the Current State of Enterprise Risk Management researchers Mark Beasley, Bruce Branson, and Bonnie Hancock found that nearly two-thirds of organizations surveyed admitted they were caught off guard by an operational surprise “somewhat” to “extensively” in the preceding five years. And in a 2014 survey of nearly 300 insurance organizations by Wolters Kluwer Financial, two-thirds of the respondents rated "maintaining compliance with changing regulations" as one of their most pressing regulatory and risk management concerns.


It's the battle we're all in - the need to mitigate risk and maintain profitable growth in the face of regulatory changes. Maybe you're facing a steady stream of new rules. For example, the US Securities and Exchange Commission issued 20 final rules in 2013 alone.  Or perhaps you're preparing for a larger change, such as complying with the Solvency II insurance regulation directives in the EU, or the Affordable Care Act in the US.


Amongst the myriad challenges facing an organization (assessing risk culture, integrating technology systems, aligning and integrating risk management into strategic planning), there lies "the human element".  In the end, the success or failure of a risk management framework, like any business transformation, comes down to people.


If you have new processes to adopt, you need a workforce that can adapt - - a workforce that makes informed decisions, has the right information in the right format at the right time, and then absorbs and acts upon urgent information.


SAP's solutions for access control, process control, and fraud management provide an excellent framework for successful risk management.  And SAP has recently introduced SAP Communication Center by Ancile (SCC) as one way to address the human element.  When used in combination with SAP's risk management solutions, SCC enables you to align your workforce and your ecosystem in a single compliance-driven framework.


SAP Communication Center provides urgent information to employees via mini-lessons that focus on one or two key concepts.  Each message you deliver to your team with SCC includes critical information along with a quick knowledge check to ensure the recipient understands the information. 


For example, consider banks who want to comply with the latest global regulatory standard Basel III.  To meet this standard, banks must comply with specific monitoring and public disclosure standards. On the ecosystem side, the real-time, high-speed reporting and risk management is available from SAP's Liquidity Risk Management (LRM) Architecture.   But, in addition to the LRM application framework, you'll also need a workforce that's ready to implement the Basel III disclosure requirements. 

By creating a simple mini-lesson using SAP Communication Center, a risk manager can quickly share just enough information to the right people to ensure that they know what to do.  Each team member receives the message in their desktop or mobile browser, or via the SCC iPhone app.




SAP Communication Center also includes reports that give the risk manager much-needed visibility into how well their team is absorbing the information.





Given the pace and complexity of regulatory changes and the need for an effective enterprise-wide approach to risk oversight, learning snacks may be exactly what workers and business leaders need in order to adapt.  Beasley, Branson, and Hancock found that most organizations haven't provided training and guidance on risk management in the past two years for senior executives or key business unit leaders.


How do you deal with the human element in your ERM approach?  Do your workers know what the organization expects of them regarding risk activities? What support and incentives do you provide to enable and encourage the desired behaviors needed for effective risk management?


I encourage you to share your experiences, views, and insights by replying to my blog post here on SCN.


Risks are the core objects that identify the potential access issues which your enterprise may encounter. The elements that make up a risk are its attributes. Risk management uses the attribute descriptions to generate rules. Risk management is the set of processes through which management identifies, analyzes, and, where necessary, responds appropriately by mitigation or remediation to risks that might adversely affect realization of the organization's business objectives. The response to risks typically depends on their perceived gravity, and involves controlling, avoiding, accepting or transferring them to a third party. Whereas organizations routinely manage a wide range of risks (e.g. technological risks, commercial/financial risks, information security risks etc.), external legal and regulatory compliance risks are arguably the key issue in GRC.


Critical Permission Risk:

Defining a critical permission risk ensures that risk analysis identifies any employee who has been assigned a potentially risky permission. You can use this feature if the permission has been enabled but has no actions. This risk can have only one function.


SAP delivered SoD doesn't contain any Critical Risk ID specific to Critical actions or Critical permissions. So, if you run the access risk violation reports either at user or role level and if you select any option among Action level, Permission level, Critical action level et al. but Critical Permission level, you would see the risk reports as expected out of the selected rule sets. But once you select only Critical Permission level, you wouldn't see any violations. Reason being is that SAP standard SoD doesn’t contain any critical risk ID either at action or permission levels.


So, in order to customize the rule set and to create Critical risk at permission level, first we need to create a Function ID which would contain the permission (authorization object) and no action (transaction code) in it.


// Verion of GRC used: GRC AC 10.1 and SP 06 //


Go to create Functions as per the path defined below and don't add any action in this function.



Now, we will go to Permission tab to enter the required permission to be treated as Critical Permission.




Now, this Function ID (CF01) has to be added to a new Risk ID (CR02), map this risk ID with the Rule set and assign the risk owner as below:




Then generate this newly created Risk ID; either via NWBC or via SPRO (IMG -->GRC --> Access control --> Access risk analysis --> SoD rules --> Generate SoD rules; and mention the lately created Risk ID and execute).





We would see the risk violations at critical permission as below:



Your inputs/suggestions are always welcome


Courtesy & Regards,

Ameet kumar & Fernando Bassuino


With the availability of defining Business roles within GRC AC 10.0, provisioning initial access to users across multiple landscapes with a single combined role is possible.


However, there have been questions raised by many in regards to how you update/synchronise actual technical role assignments embedded within the Business Role assigned to users via GRC.


For example;  If a new R/3 role has been added to the Business role definition, how do you update the assignment to the 55 users already assigned to the Business role? It is impractical to raise a new change request via Access Request Management for all the assigned users for the same role again, as it would create unnecessary requests (and maybe agitate the approvers involved).


Thankfully, within GRC 10.0/1, it is possible to synchronise the technical role assignments via the Role Maintenance screen in NWBC, but it requires a few tweaks within the GRC system.


Part 1 Enable the hidden Methodology step “Provisioning”


Note - These steps needs to be done on both 10.0 and 10.1, as the SAP BC-set delivered Default Methodology is missing the required Step definition.


1. Go to SPRO and open the following node menu: Governance, Risk and Compliance > Access Control > Role Management > Define Methodology Processes and Steps


2. Click “Define Steps” and then “New Entries” – By default, the BC set delivered methodology steps is missing “Provisioning” from the defined list.


3. Select the action “Provisioning” and enter is as “Active” and enter the Phase text details “Provisioning”


4. Save any transport prompt

5. Under “Define Methodology”, select the methodology to update and then click “Methodology Process Step”


6. Ensure the final step “Provisioning” is added to the methodology



7. The new methodology step should be visible now within the “Role Maintenance” functionality of BRM (on NWBC side)




The button will be enabled when:

     • The Business role has already been provisioned at least once
      • The Business role has changed and technical roles have been added or removed

The button will be disabled when:
      • The Business role has not been provisioned via request yet
      • The Business role has already been provisioned at least once, but there are no users currently assigned (the Business role has been later removed from     the users)



Part 2 Updating Cluster class


A runtime error has been  observed within GRC AC 10.0 (not 10.1, as it seems the cluster class has been delivered correctly) when clicking the “Update Assignment” button. The error appears as follows: Parameter has invalid value: Parameter SYST_DATE/SYST_TIME has invalid value 00000000/000000.


The cause of the issue is that the correct configuration is missing in the view cluster: GRFNVC_PLUSG for the provisioning background job.

To fix this, implement the steps provided in SAP note 1837416 (described below)


1. Go to transaction code SE54


2. Click on the button “Edit view Cluster”, followed by “Test”


3. Enter the Table/view “GRFNVC_PLUSG” and click "Test"


4. Select the Node “Plan Activity for Access Management”  under the  Dialogue structure


5. Select Plan Usage GRAC_BRLP and double click on it.

6. Enter the correct ABAP class as "CL_GRAC_ERM_BROLE_BG". (This value may have been set up/delivered incorrectly before, hence the error).


NOTE: If the entry “GRAC_BRLP” does not exist, you can create it as per SAP note 1837416

    1. Click on New Entries
    2. Enter the following fields and save:

     Plan Usage: GRAC_BRLP

     Activity Name: Access Control Business Role Provisioning Background Job

     App-component: GRC-AC.

     ABAP class: CL_GRAC_ERM_BROLE_BG (note SAP note 1837416 mentions CL_GRAC_BROLE_BG, but this does not work)


With this fix, you should now be able to successfully maintain and provision Business role updates to all users via the Role Maintenance screen.

SAP Notes in relation to this topic



Business Role Methodology contains multiple steps including “Provisioning” and under “Provisioning” steps there is “Update Assignment” button. When customer clicks on “Update Assignment” button, notification is triggering to all the end users whom this business role is assigned and notifying the access changing. But there is no way to control this notification.

The SAP note provides  correction instructions that introduces a new configuration parameter ID to control if emails are sent out to users during the "provisioning update" scenario (param ID 3029 - Send Notification to End User on Update Assignment)




It seems there is a program issue in 10.1 whereby the updates are not working correctly when a new derived role is added or a existing role is removed from the business role definition. Seems to state the note is part of SP08 for 10.1. No clear indication of if this behavior is reported or fixed for 10.0.




I presume that the fact there is no "Mass assignment" feature available for Business Roles from BRM means that there is no "Mass Update Assignment" feature available at all either (i.e. running a "Provision update assignment" job for many business roles in a single attempt. SAP suggest utilising the "Multiple User Request" option to control mass assignments of business roles.


SAP TechEd && dcode image.pngWhat I like best about SAP TechEd && d-code is the variety of learning experiences available to attendees. SAP Security and GRC professionals might be surprised to learn that there is a good variety of sessions for us if you look for them.


My location: definitely Las Vegas. Not that I am a huge fan of Vegas excess, but the ASUG customer-driven content makes that the right choice for me, besides the travel time and expense being much less.


My plan: I like to fill my personal agenda with as much security and GRC Access Control content as possible, then fill in the blanks with samplings of other topics. I also plan to attend Demo Jam and do lots of networking. My agenda is still a work in progress, but here are some highlights:


ITM113 Overview of Security Features, Functions, and Services in SAP Products. You can't go wrong with a session presented by Gerlinde Zibulski , who leads the Security Product Management team at SAP. This session covers both security *and* GRC Access Control, making it a winner for me.


SEC104 Security Notes, System Recommendations, and Business Process Change Analyzer. Speaker Frank Buchholz has been presenting an excellent web cast series for ASUG on topics related to security patching, so I know he is expert on this topic, and I look forward to learning about BPCA.


SEC260 Security Control Center by SAP Active Global Support. This session is related to SEC104. We have not yet used the Configuration Validation application at my current organization, so I hope to be able to give it a test drive in this hands-on session.


SEC834 Road Map Q&A SAP Product Security, Strategy, Features, and Functions. This road map and Q&A session is a follow up to ITM113, and Gerlinde can be counted on to answer questions with frankness and expertise, so don't miss this session for the real scoop on security, GRC Access Control and more.


SEC200 Security in Different SAP HANA Scenarios. I attended speaker Mark Hourani 's  overview presentation on SAP HANA Security at the ASUG Annual Conference, and I look forward to this more technical dive into it.


SEC107 SAP Access Control On Going Management and Lessons Learned. The speaker, my SAP Mentor colleague Greg Capps has been working on GRC 10 Access Control since his organization was in ramp-up, so he already has years of lessons learned to share. This ASUG education session is a don't miss whether you have already implemented GRC Access Control or are still thinking about it.


SEC201 Implementing LDAP within SAP Access Control. Greg is also presenting this session, which will give you some ideas for improving your GRC Access Control user experience. We have already implemented LDAP with Access control, but Greg's real-world tips for making our users' experience even better will be worth hearing.


SEC203 SAP HANA Security - How Newell Rubbermaid Simplified Security Administration. Speaker Gautam Patel is Newell Rubbermaid's SAP Lead Technical Architect, and his lessons learned and leading practices are sure to be informative.


Advice to first-timers: Plan a personal agenda, but don't worry if it has scheduling conflicts. In fact, that can be a good thing: if a session you are attending is not what you expected, you can slip out quietly and head over to your alternate session. If a session is offered twice, put both of them into your agenda. Be sure to visit the Community Clubhouse and the evening events; even if you are not a developer, Demo Jam is great fun. If attending in Las Vegas, be sure to include some ASUG content in your agenda for real world case studies and lessons learned. Try to eat healthy foods and stay hydrated; it is easy to get run down with the hectic schedule and late nights, and you don't want to be so exhausted by Thursday that you miss the Huey Lewis and the News concert. You might spot some people in SAP Mentors shirts, leading networking sessions, assisting in hands-on workshops, and just chatting in the Community Clubhouse; don't be shy, come up and join the conversation. Most of us are SAP customers or partners, dealing with the same challenges at work as you are. We don't necessarily have all the answers but we look forward to meeting you and sharing your TechEd && d-code experience.

SAP recently conducted a survey on transforming internal audit management at the Institute of Internal Auditors International Conference 2014 held at London. The purpose of this survey was to explore the current status, business impact and potential future of technology in transforming internal audit. Around 150 respondents provided their inputs to this survey providing some key insights:

  • 81% consider Integration with Risk and Control management systems and/or the underlying ERM as the key capability needed in the future
  • Only 15% use integrated audit management solutions with analytical capabilities and only 14% say that current audit management/analysis tools meet all/most needs
  • 54% believe that Technology will fundamentally change how audit services are performed and how the value of those services is measured


Here is the link to a blog post as well as an infographic depicting the key findings.

If you attended Alan Jackson's performance at the 2013 ASUG/ SAPPHIRE Now Celebration Night, or if you are a fan of his, you might be familiar with his hit ballad "I'd love you all over again."

Now that we have gone live with our Governance, Risk and Compliance (GRC) 10 system, I thought I might look back over several years of such projects to ask myself, if I had it to do all over, which choices would I love all over again.


Pilot or big bang?

One choice, to do an Access Control pilot, was the option selected by one of my previous GRC 10 projects. It allowed us to get the system configured, build the Business Roles, and do a pilot of the custom request workflows, in a few short months. The downside to that choice is that everyone else stayed on the 5.3 system, so both systems had to be maintained, and presumably audited, until all the business units were brought onboard the 10.0. It was a trade-off, but they were willing to make that choice.


On the other hand, my recent project took the "big bang" approach, bringing all the systems connected to our 5.3 GRC over and going live with everyone at once. The upside was that we were able to shut down our 5.3 system soon after the go-live, reducing the dual maintenance period. The downside was that testing identified many issues, particularly with provisioning to the SAP Portal, many corrections were implemented, one connection never did work and had to be taken out of scope, and it all took much longer than planned. Now, just a few weeks after go-live, we are already living on borrowed time: the APO system was upgraded to a NetWeaver release requiring a plug-in higher than our SP level. Everything is working for now, but sooner or later, another connected system upgrade will force us to upgrade, too.


Business roles or technical roles?


The GRC 10 project I was on back in early 2012 included implementation of Business Role Management (BRM), and I blogged about that here. BRM was, unfortunately, still pretty buggy back then. I think it was a good choice given their technical role design and their access request process, but waiting for a later support pack might have made it easier.


In that client's process, anyone could submit an access request; in contrast, the process at my current organization has access requests submitted by key users  trained on SAP security reporting and other tools. In theory, these folks are knowledgeable enough of the business processes at their location for the users they support, and with the tools and training, can make informed role choices. While Business Roles would probably add value to our process, we chose to continue with requesting technical roles for now, with some role mapping to ease the process, and consider implementing BRM later.


Another option is to do a security re-write- concurrently, before, or after the GRC project? If you decide to do it concurrently, be sure you have enough resources for the multiple work streams. My first GRC 10 project went that path; in my view, having a small army of experienced internal and external resources was one of the good decisions, along with ensuring good executive support.


If your rule set is in good shape, maybe you want to do your security rewrite ahead of the migration to GRC 10, either with a pilot or big bang. If you lean towards a pilot, be certain that your pilot group is onboard with the project approach; trust me, you don't want to be in the position of having the business unit for the pilot getting cold feet midway through the project, leaving you in a tough spot.


between a rock and a hard place3.jpg


Change management decisions


How much of a change is GRC 10? It all depends. If you are implementing Access Request Management, does your current access request process have a lot of manual hand-offs and detours to be automated in the new process? It may delight your users, but they still have to be trained on the new user interface and get used to the automation. On the other hand, if you are just going live with Access Risk Analysis, you probably have a smaller user community to train.


The big project I mentioned above included a team of experienced change management consultants, and I think that was a smart choice for such a huge undertaking. My much smaller recent project had excellent internal support for communications and our web page, but we were pretty much on our own for developing and delivering training. We offered live training, step-by-step video recordings, and Quick Reference Cards that were jointly produced. All were well received; however, by business decision the training was not mandatory, so you can probably guess the outcome: the users who took the training are doing pretty well and are happy with the new system, especially the new request templates and more efficient workflows, and those who opted out of training.... Enough said.


Now we are working on resolving non-showstopper issues, problems identified during testing that were not urgent enough to risk breaking something else with a possibly buggy correction before go-live. It never really ends, does it?

And what about you? If you are already live on GRC 10, what would you do all over again and what might you do differently? I invite you to share your perspectives.

In the last 9 months, more than 250 consultants from partners attended the Fraud Management Partner Workshops to receive training on how to develop rules for SAP Fraud Management. Since then, many partners have decided to develop content for SAP Fraud Management for such industries as utilities, insurance or banking.


For SAP and its customers, this is a perfect match as it complements SAP’s offering with specific domain expertise and helps customers to implement faster and with lower effort, based on predefined content.


With the SAP HANA market place, SAP now provides a simple way for partners to list and sell content for SAP Fraud Management. The SAP HANA market place is the one-stop location to learn, try out, and buy SAP HANA applications. After a certification, partners can load any kind of collaterals and can then launch their content via the SAP HANA marketplace.


For more details, please see contact Narayan Sundareswaran or see the materials on the SAP Fraud Management wiki page.

Sign Up Now To Summer Training - Partner Workshop on SAP Fraud Management

August 26-28th, 2014 SAP Campus – Walldorf, Germany



With the continuing momentum around SAP Fraud Management, we will be offering partners the opportunity to attend another Partner workshop on SAP Fraud
in AugustIt will take place from Tuesday, August 26 to Thursday, August 28, 2014 at the SAP Campus in Walldorf. This workshop is free of charge and for selected partners and SAP employees, however, you will need to cover your own travel costs.


Objective of the workshopThis workshop offers deep-dive training into SAP Fraud Management and would enable attendees to be able to take customer data and build customer-specific rules with the solution. 


  • Day 1: Business Overview for Fraud Investigators & Deep Dive Detection
  • Day 2: Programming of Detection Rules & Overview of Predictive Capabilities
  • Day 3: Self-Guided Programming
  • Optional: Day 4: (Self-Guided Programming)



Note: There may also be an option for attendees to continue their programming on the SAP Fraud Management development system after
the workshop until the end of the training week.  Subject to availability.



Workshop Pre-requisite & Commitment


In order to maximize the value for you please be prepared to:


    • Bring a data model and data sample from either a customer or industry, plus a set of rules that can be implemented in the development system during the training.
    • Send a mixture of both technical and functional people (HANA and solid SQL knowledge, together with forensic or fraud knowledge).


What should I do now?

Please let us know that you will be attending as soon as possible as space is limited. To reserve your place click REGISTER to confirm your registration (first come first serve).


For each attendee, please include:


      • Name
      • Job Title
      • Full Company Address
      • E-mail Address
      • Contact Phone Number




We look forward to seeing you in Walldorf.



Gerhard Hafner   Genaro Pena
Chief Product OwnerVP Sales, EMEA
HANA Based Applications




Filter Blog

By author:
By date:
By tag: