SAP GRC Access Control supports real-time compliance around the clock and prevents security and control violations before they occur. After implementation and deployment of the risk analysis and remediation software, businesses can analyze real-time data, find hidden issues and help ensure the effectiveness of access and authorization controls across the enterprise.


Some considerations regarding alert functionality:


Alerts could be used as soon as a user executes a specific conflict within the system:

  • to check if a user executes an SoD conflict or a critical transaction
  • to check if the reports defined in the mitigating controls were executed on time


Points to consider when using alerts:

  • no detailed authority check, only on transaction level
  • no time-dependend aspects considered (e.g. order goods on day 1 and create goods received on day 2 for a separate order will create an alert as well)


My suggestion is to use the alert functionality wisely.



How to use Alerting within SAP GRC?


Run the program GRAC_ALERT_GENERATION to create alerts. Make sure that the action usage sync job run before (GRAC_ACT_USAGE_SYNC) so that all executed actions are captured from the backend system.


There is the possibility to send email notifications to risk owner to be informed when a SOD violation occurs.


NWBC Report

Alert reports can be displayed or cleared in the frontend. Go to NBCW workcenter "Access Management" and open "Conflicting and Critial Access Alerts" in section "Alerts".


You have the possibility to clear an alert or delete an action.

  • Clear Alert – removes all parts of an alert. User has to execute all sides for the alert to reappear. This tasks requires a comment to be entered.
  • Delete Action – removes 1 action of an alert. User has to execute the deleted action for the alert to reappear.


If you need more information about the possibilities of alerting with SAP GRC do not hesitate to contact me directly by leaving a comment or sending an email.

As of Monday, February 10, 2014, SAP Audit Management is generally available to customers.


SAP Audit Management, powered by SAP HANA, offers an end-to-end solution for managing audits. In the preparation and planning phases of auditing, an auditing department can use SAP Audit Management to collect auditable items in a flexible audit universe repository, prepare audits and assign auditors to them, and build audit plans to manage audit activity over time. During audit execution, the application supports auditors with easy-to-use features for managing working papers and findings. The application also integrates reporting and follow up, with management of audit report review and issuance and tracking of open findings.


The key features of SAP Audit Management include:


  • Full mobile-enablement and easy access from
    multiple devices and platforms: desktops, tablets, and smartphones.
  • Full coverage of the audit roadmap; including
    planning, preparation, execution, report, and follow-up
  • Flexible Audit Universe that serves as a single
    source for audits and monitors audit requests globally
  • Powerful working paper management that allows
    you to create audit documents via drag-and-drop, single-click access to the
    documents, and management review
  • Global monitoring of findings and following up
    on the progress of actions
  • Powerful search function that helps you find the
    target information with one click
  • Clear and intuitive HTML5 user interface design
    that improves the user experience and boosts efficiency
  • Deployable on-premise and in the cloud.


SAP Audit Management, powered by SAP HANA, is one of the solutions of the new SAP offering, SAP Assurance and Compliance Software. SAP Assurance and Compliance Software integrates SAP HANA-based solutions that let you address a broad spectrum of risk and compliance issues in corporate governance.

SAP Fraud Management is released with new and enhanced features as of Monday, February 10, 2014. SAP Fraud Management is generally available since September, 2013.


SAP Fraud Management offers a generic platform for analyzing data for signs of potential fraud. The application signals a suspicious occurrence with an alert. Alerts, in turn, provide the workflow for fraud investigators. SAP Fraud Management also supports investigators in managing and documenting investigations and reporting results. SAP Fraud Management also can be integrated into all kinds of business processes, for real-time online evaluation of claims before payment, disbursals for purchases, and so on.


SAP Fraud Management uses advanced HTML5 user interfaces that have been developed with user input for efficiency and user-friendliness. The lightweight, generic infrastructure that SAP Fraud Management offers makes it possible to extend the application, for example, to address newly discovered
fraud scenarios quickly and easily.


New and enhanced features in SAP Fraud Management include the following:


  • Alert dispatching: Alerts that are not assigned to any investigator can be managed with a new dispatcher work list, accessible by way of the Unassigned Alerts tile in the user interface. Unassigned Alerts offers a special dispatcher workflow, so that a dispatcher can pre-investigate an alert, dispatch it, or close it without investigation. There are new sorting, search, and filtering tools to make it easy to manage alerts produced by SAP Fraud Management.

  • Enhancements to existing features include:
    • Navigation to external targets to view original documents from nodes displayed in the graphical Network Analysis investigation tool
    • Touch and mouse zooming of the Network Analysis graph
    • Enhancements to generic searching
    • Customizable alert and search messages.
  • The existing anti-corruption content , delivered without support or warranty via SCN, remains fully compatible with SAP Fraud Management. Further anti-corruption content will not be released via SCN. Here is a link to the anti-corruption content in SCN.

See also the SAP Fraud Management Release Note.


SAP Fraud Management is mobile enabled and available on desktops, tablets, and smartphones. The solution can be deployed on-premise or in the cloud.


SAP Fraud Management has been integrated into the new SAP offering, SAP Assurance and Compliance Software. SAP Assurance and Compliance Software integrates SAP HANA-based solutions that let you address a broad spectrum of risk and compliance issues in corporate governance.

    The purpose of this post is to demonstrate how to create Template Based Requests and make them available for provisioning in SAP. This document will demonstrate how to customize and associate End User Personalization forms for use with Access Request: Template Based Requests.


    Template Based Requests are an effective way to provision access in SAP environments. Security administrators can create pre-defined templates with specified roles for each back-end environment to simply provision requests for end users. In addition, templates can leverage the Business Role Concept from Business Role Management in GRC 10.0/10.1 to provision bundled composites and singles roles across multiple back-end environments. The following steps outline the process to follow when implementing template based requests:


Step 1: Customize EUP personalization


Access the GRC IMG via t_code SPRO followed by menu path:

Governance, Risk and Compliance> Access Control> User Provisioning> Maintain End User Personalization



Step 2: Create copy of the default EUP personalization form


Within the IMG activity, select the default EUP personalization form.



With the default EUP personalization form selected press F6 or click the “copy as” icon.





Enter a new EUP ID #, EUP Config Name, and Description.




Execute or hit enter and copy all dependent entries in the following pop-up.





Click through the confirmation pop-up and save.





Step 3: Customize the EUP Copy


Select the new EUP personalization form and double click the maintain EUP fields folder.






Select fields to include or exclude in the Template Based Request and save.




List of available options for each field.




Step 4: Create an Access Request: Template Based Request and how to associate EUP Personalization forms.


Navigate to the Access Management Work center in NWBC and select the Template Management under Access Request Administration.




Select create, input name of Template, EUP form, and Request Type.








Select Access Details, and click the add button, choose role.





Choose single, composite, or business role, move role down and select OK.






Role will now appear in the Template, select save.







Access Request: Template Based Request is now available for provisioning.





Access Request: Template Based Request end user view.





Template Based Access Requests can take some time to configure, but the benefits gained simplifying access requests for end users often makes this an easy enhancement to justify for your GRC environment.

In this article, I will provide an overview of the Emergency Access Management reports and which information can be seen. GRC provides six reports specifically for EAM, e.g. the consolidate log report shows firefighting activities which have been executed while using firefighter. The consolidate log report is far the best and used for management review from the firefighter controller (if workflow is in place). The consolidated log report has all the captured information from the backend system in a consolidated view. Following a short overview of the captured information and where it comes from.


Transaction Log

Captures transaction executions from transaction STAD. System, Firefighter, Firefighter ID, Reason Code, Transaction, Date and Owner are read.


System Log

Captures debug and replace information from transaction SM21.


Change Log

Captures change log from change document objects which are stored in table CDPOS and CDHDR.


Security Audit Log

Captures security audit log from transaction SM20.


OS Command Log

Captures changes to OS commands from transaction SM49. For further investigation or to get more information about the activities performed in the backend system these transactions might be helpful.


Other reports are:

Invalid Superuser Report - shows expired, locked and deleted firefighter IDs.

Firefighter Log Summary - shows firefighter ID session details (only available for ID-Based firefighter, see also my blog post about Types of Firefighter).

Reason Code and Activity Report - shows reason and activity details.

SOD Conflict Report for Firefighter IDs - shows SoD conflicts (risk analysis) for firefighting sessions.


Please contribute in this blog post and share your experience and know-how about firefighter reporting.

Purpose and functionality

  1. EAM allow users to take responsibility for task outside of their normal job function.
  2. Allow temporary access for users when assigned with solving problem, giving them provisionally broad, but regulated access.
  3. This temporary access will monitored and reviewed by the application.
  4. EAM provides the ability  to manage and utilize firefighting activities centrally from the access control application
  5. The log files can be distributed to controller and owner via workflow for additional approval

Defining Users

  1. The owner of the ID
  2. The controller
  3. The users who will log on through EAM.

Important Roles and Terms

  1. Firefighter:  a business users requiring emergency access.
  2. Firefighter ID:
  3. A user id with elevated priviledges.
  4. Access T-code  GRAC_SPM
  5. Firefighting: the act of using a firefighter id.
  6. Controller:  review and approves (if necessary) the log file generated by the firefighter.
  7. Owner: a user responsible for the firefighter id and assignment the controller of the firefighter.

Firefighter Application type:

There are two deferent applications that can be used that can be used:

  1. ID based firefighter Application
  2. Role Based firefighter Application.
  • Configure in the IMG using parameter 4000 (Application type)
  • Only once application can be configured at a given time. 

GRC Server package

  1. The main application runs in the GRC server.
  2. It is possible to assignment user for all system using NWBC or portal.
  3. Provisioning of the emergency access can also be done via access request(Workflow)


  1. Firefighter access is done centrally using the GRC system.
  2. Firefighter logon to the GUI back and execute t-code GRAC_SPM
  3. Click on the login.

Emergency Access Architecture


  1. Once component called plug-in that is installed in remote system.
  2. Emergency Access Management access the plug-in  using RFC.


  1. Create users and roles as needed
  2. Execute program GRAC_ROLEREP_USER_SYNC

Centralized firefighter overview and prerequisites

Centralized firefighter overview

  1. EAM provides a centralized console through which firefighter can logon to deferent system for firefighting.
  2. In id based scenarios, firefighter do not have to logon to individual client system to do firefighting.

Centralized firefighter prerequisites

  1. Application type is 1 for id based firefighting
  2. Set parameter group 6 super users management
  3. Set parameter id 4000
  4. Firefighter user must exists in the central access control system and the role SAP_GRAC_SPM_FIREFIGHTER

Centralized Logon Pad

       ● Access Control provides centralized logon pad for accessing the firefighter IDs in all connected back end systems

The centralized logon pad allows:


  1. Displaying all firefighter IDs assigned to the user
  2. Logging on to all connected back end systems
  3. Sending messages to other firefighters who are using a specific firefighter ID
  4. Unlocking a firefighter session not closed properly


While a Firefighter Session is running


  1. The status of the firefighter ID will display in red
  2. The firefighter can take the following actions:

    ● Click Additional Activity to enter more information

    ● If the firefighter ID is in use by another firefighter, choose Message to send notification to the other firefighter


● Choose Unlock to unlock the firefighter ID if it is locked


EAM Configuration

Parameter setting

4000-Application type

4001-Default Firefighter Validity Period (Days)

4002-Send Email Immediately

4003-Retrieve Change Log

4004-Retrieve System log

4005-Retrieve Audit log

4006-Retrieve OS Command log

4007-Send Log Report Execution Notification Immediately

4008-Send FirefightId Login Notification

4009-Log Report Execution Notification

4010-Firefighter ID role name

Monitoring Emergency Access


Firefighter Report types and purpose

Using firefighter reports

  1. Resulting change log is stored in CDHDR and CDPOS tables
  2. Log data is retrieved from the client system and stored in GRC for report generation



In  GRC10 – ARM  Access Request approver have the choice to do Risk analysis at “Action Level”, “Permission Level”, “Critical Action”, “Critical Permission” and “Critical Role/Profile”.  But In 5.3, Approver didn't have choice to decide while using from CUP.


When approver open access request in AC10 under Risk Violation tab Permission Level is always selected .Selection is fine as this is configured this way (Parameter in SPRO 1023 -Default Report Type for Risk Analysis).  But the approver also has an option to deselect "Permission Level".


If you want to ensure that approver always keep "Permission Level" as an option, in other words option should be grayed out with permanent tick mark. This is to make sure that CUP enforce "Permission Level" check, otherwise if approver deselect then they can always skip the risk analysis by clicking different report types. Also possibility at times all the approver doesn't understand the meaning of each option.  Both accidental / intentional ways skipping Risk Analysis is possible.


As you can see Permission level is always selected but editable. Approver can deselect and submit the request with no violation. This way unmitigated risks can be submitted.


We have achieved this by deploying SAP NOTE 1796838 - UAM Risk analysis at permission level set to non editable and following below steps.



1. Go to transaction se80.

Select Package as ‘GRAC_ACCESS_REQUEST’.

Click on Web Dynpro -> Web Dynpro Application



2  .Drill down to application ‘GRAC_OIF_REQUEST_APPROVAL’. Right click on it and click Test.


3. Now, the following screen will appear.



Go to the URL of the above screen and add the following string to it.

Go to Transaction  SE16 and Enter table name as GRACREQ, enter any request number in REQ_ID field.

Click execute button and copy the value of field REQ_ID


Below is String to add in URL-


&SAP-CONFIG-MODE=X&OBJECT_ID=ACCREQ/<REQ_ID  checked from above step>


Below is example for string to add in above screen dump URL..




Observe that the dump will now get removed and an access request will be opened.

4. Go to the Risk Violation Tab and right click on the Type check boxes and choose ‘Settings for Current Configuration’



5. Now, the following pop up window will appear.



In this, you can go to each of the type of result options and click on ‘read only access’ check box.



6 For example, If you click on Permission Level and set Read-Only Access as ‘Yes’, permission level will appear as non editable on approval screens for all requests.


Click on ‘Save and Close’.

Please see that the Permission level check box is now disabled.




Hope this will help you if you meet such a kind of requirement. and prevent from submit unmitigated Risk.



Dilip Jaiswal.

GRC - IDM Consultant.


In this Customizing activity, you can configure the LaunchPad settings for Governance, Risk, and Compliance (GRC) application menu items. The GRC application uses one repository and seven LaunchPads, one for each work center, as listed below:


    Operation = GRC AC PC RM IA Repository

  Work Centers 

  • My Home
    Role = GRCHOME
    Instance = GRC_SUITE_HOME
    Operation = GRC Suite Home Workset
  • Master Data
    Role = GRCMASDAT
    Operation = GRC Suite Master Data IA
  • Rule Setup
    Operation = GRC Suite Rule Setup Workset
  • Assessment
    Operation = GRC Suite Assessment Workset
  • Access Management
    Operation = GRC Suite Access Management Workset
  • Reports and Analytics
    Instance = GRC_SUITE_REPORTS
    Operation = GRC Suite Reports Workset
  • Application Administration
    Operation = GRC Suite App Administration


Note  If SAP provides updates to the content, then such changes update the standard SAP delivered repository and LaunchPads; the changes do not directly update any customized versions.  To view the changes to the SAP delivered versions and to update your customized version go to Extra->Show SAP Version.


You have created the new menu item using the Customizing activity Maintain Authorizations for Application Links.


To create new menu items, do the following:

1. Choose a component for the menu items.

2. Choose New Application.

3. In the field Link Text , enter the menu item name.

4. Select Application Categoryand choose WDA Webdynpro ABAP.

5. In the field Namespace, enter the required SAP namespace.

6. Enter the applications. (This can possibly result in the need for development of the new applications.)

7. Enter the System Alias based on the component of the menu item. You can use the following aliases:


    • SAP-GRC for items applicable to both Process Control and Risk Management, and for all (Access Control, Process Control, Risk Management)
    • SAP-GRC-AC for Access Control only
    • SAP-GRC-PC for Process Control only
    • SAP-GRC-RM for Risk Management only

8. Enter the required Application Parameters.

9. In the field Add Information, enter MENUITEMID=<The MENUITEMID,as maintained using the Customizing activity Maintain Authorizations for Application Links.

10. Save your entries.

To link the menu items to a particular LaunchPad, do the following:

1. Double-click the LaunchPad you want to link, for example Master Data.

2. Navigate to the folder to locate the new menu item.

3. Choose Link to a Repository Application.

4. Choose the repository GRC AC PC RM IA Repository, and drag the menu items to the folder.

5. Save your entries.

To create new menu folders, do the following:

1. Double-click the LaunchPad of the work centers in which you want to locate the menu folders.

2. Choose the New Folder pushbutton.

3. Enter the folder name and folder description.

4. Change the icon of the folder. (This step is optional)


In this Customizing activity, you maintain menu authorization of all Governance, Risk, and Compliance (GRC) applications. The autorizations are then used in SAP NetWeaver Portal (portal) or in the NetWever Business Client (NWBC).

Menu items represent individual navigation links. The text is used for reference and to provide an indication about the purpose of the application. Each menu item must belong to at least one or more of the application components listed below:

  • FN, which is the common component used for all GRC
  • Process Control (PC)
  • Risk Management (RM)
  • Access Control (AC)

The application displays the group items and menu items in accordance with the authorizations granted by the user role.  For example, if the user role is not authorized to view any objects and entities in a group, the application will also not display the related menu item.

Note: If you are upgrading from Process Control 3.0, you can use the delivered BC Set for this Customizing activity. For more information, see the SAP GRC Process Control  10.0 Upgrade Guide.


You have maintained each menu item ID in Web Dynpro  and in Launchpad Customizing.


To customize the authorizations, perform the following steps:

   1. Choose the New Entries pushbutton and enter a menu item ID. This is the referenced text for the application item.

   2. Choose the required Authorization Mode from the following:

   3. Choose the Entity Evaluation. You can specify if the item can be enabled by providing authorization only for one entity or object, or if it is necessary to provide authorization for all entities and objects. If no entity or object is defined for the item, then the item is always displayed.

   4. Choose the Authorization Class.

   5. Choose the Logical Operation to provide  an additional authorization check.

You can use an exit class for the ABAP code-based authorization check for a menu item. To do this, follow the requirements listed below:


  • Use the interface IF_GRFN_MENU_ITEM_AUTH.
  • The interface contains the method IS_AUTHORIZED. The method has the following  parameters:

Importing Parameters

    • IO_SESSION type, referring to class CL_GRFN_API_SESSION

  Exporting Parameters 



  The results from the exit class can be combined with the entity-level and if required with PFCG authorization by specifying the type of operation (NO, AND, OR). You can make the required selection and save your data.

   6. If you want the authorization to be evaluated by all regulations, then select the Regulation Relevence checkbox.   That is if one of the regulations is authorized, the menu item is shown.

   7. Choose Used in Application Components.

   8. Choose the New Entries pushbuttonand select the menu items that you created.

   9. Select one of the application components used in the application. In field Application Component, select whether you want to customize the entire GRC, or select the required components from the following: PC, RM, and AC.

  10. If the authorization for the application is evaluated by Entity-Level Authorization or Entity-Level and PFCG Authorization, then do the following:

a) Choose Authorized Entities.

b) Choose the New Entries pushbutton and select one of the menu items you created.

c) Select an entity from the dropdown list to be used with the selected menu item.

d) Save your entry.

Proceed in the same manner with all other menu items.

Eskom Configuration: Not used

SPRO Location




This organizational activity describes how you can activate or modify the delivered Business Configuration (BC) sets.

SAP provides a set of recommended BC sets as a baseline. For example, there exists a BC set for the frequency timeframes, where you define and maintain the time period of your system


To activate BC sets:

1. To see the activities that have a BC set, choose Existing BC Sets.
The system displays the BC sets on the right hand side of each activity.

2. Place the cursor on a BC set and choose Additional Information ->BC Sets ->Display BC Sets for Activity. The Business Configuration Sets: Display screen appears.

3. To highlight the individual BC set, choose Goto ->Activation Transaction.
The Business Configuration Sets: Activation screen appears.

Note: You must activate each BC Set separately.

4. Choose Activate BC Set or press F7.
The BC Set is activated.


Eskom Configuration:  The above does not work.


Note: BC Sets activate the default contents on the Configuration Tables

  These BC sets can be activated via transaction code SCPR20



Select each of the BC Set ID as per the table below:




In this Customizing activity, you establish the settings for transporting the organizational objects created during the set-up of your organizational structure.

This setting suppresses the SAPGUI error and warning messages received from the HR Organization objects as a result of the changes performed, for example, by changing the name of a control in the Process Control application. Examples of objects include risks, controls, processes, and so on. If you do not configure this setting, then there is a possibility system dump appears on the user interface.

Note: You must specify the transport settings for the objects in the organizational plan created for Organizational Management. This is esential because the tool used for the organizational structure set-up in Risk Management (RM) and Process Control (PC) is the same as that for setting up the organizational plan in the clien system.

Standard settings

In the standard system, the automatic transport connection is active. As a result, the Value Abbreviation field is empty for the abbreviation CORR.


To deactivate the automatic transport connection, enter the value X for the abbreviation CORR. You must do this if  you want to maintain the settings for the organizational structure in the user interface.

Eskom Configuration: This option not used, default.



In this Customizing activity, you activate the applications that can be used in your client system.

In the default delivery system, there are three application components that can be activated:

  • GRC-PC for Process Control
  • GRC-RM for Risk Management
  • GRM-AC for Access Control


To activate an application component, proceed as follows:

  1. 1. Choose New Entries.




  2. Select an application component from the dropdown list.

  3. In the column Active, select the checkbox if you want to activate the application. If you are using both Process Control and Risk Management, you must set the indicator for both components.

  4. Save the entries.

The purpose of Emergency Access Management is to allow users to take responsibility for tasks outside their normal job function. This component allows temporary access for users when assigned with solving a problem, giving them provisionally broad, but regulated access which is monitored and recorded in the application.

SAP GRC 10.0 provides two different types of firefighting which can be used either centralized or decentralized. Following a short description of both types which can be configured in IMG using parameter 4000 (Application Type). Only one type can be configured at a given time.


ID-Based Firefighting

With ID-Based Firefighter each Firefighter ID has its own user master record with roles assigned directly to the Firefighter ID. The End-user (Firefighter) executes a transaction code and checks out an ID. It is possible for multiple users to check-out each Firefighter ID (which is authorized to the end-user) but only one user can have a Firefighter ID checked out at any time. A reason code and the expected activity must be documented prior to gaining Firefighter access. Relevant changes in SAP are captured in the change history under the Firefighter ID. It is important to highlight that everything is documented with the Firefighter ID and not the user’s normal user ID.


Role-Based Firefighting

Each role which is defined as Firefighter Role can be assigned directly to a user. This can be done through Access Request Management (ARM) if in place or directly in SU01. To use the Firefighter a user doesn’t have to check out a separate ID. Transactions and change histories are logged with the user’s own ID, which is an advantage in relation with the ID-based Firefighter. The end-user is not aware when he is utilizing emergency / firefighter access as he does not have to check out an ID and uses his own ID all the time.


Concept of ID-Based Firefighting



Concept of Role-Based Firefighting



Steps to set up ID-Based Firefighting

  1. Create Firefighter ID
    • Create a user account in transaction SU01 with user type S (Service) to be used as a firefighter. This can also be done in Access Request Management if in place.
    • Assign the Firefighter ID role which is defined in configuration parameter 4010 (Firefighter ID role name) to recognize the service user as a Firefighter ID.
    • Assign necessary roles for firefighter access.
  2. Define Firefighter Owner
    • Assign an Owner to the Firefighter ID
  3. Assign Firefighter Controller
    • Assign a Controller to the Firefighter ID. Controllers are responsible for reviewing the log report and can receive email notifications or workflows of Firefighter ID use.
    • Firefighter ID Controllers can also be Firefighter ID Owners.
  4. Assign Firefighter
    • Assign a user (must have an existing user ID) to the Firefighter ID.
    • The user can access the Firefighter IDs (can be more than one) within the validity dates.


Steps to set up Role-Based Firefighting

  1. Define Firefighter Role
    • Enable a specific role for Firefighting directly in the Business Role Management.
  2. Define Firefighter Role Owner
    • Assign an Owner to the Firefighter Role.
  3. Create Firefighter Role Controller
    • Assign a Controller to the Firefighter Role. Controllers are responsible for reviewing the log report and can receive email notifications or workflows of Firefighter ID use.
    • Firefighter Role Controllers can also be Firefighter Role Owners.
  4. Assign Firefighter
    • Assign a user (must have an existing user ID) to the Firefighter Role.
    • The user can access the Firefighter Roles (can be more than one) within the validity dates.


Please share your thoughts of both firefighting concepts and participate in upcoming discussions.

Best regards,


Access Control: - Create Access Request Using Web Service in GRC10

In this blog I would like to share my experience how Web service can be tested and create Access Request from GRC system when you are integrating with IDM system.


Suppose you have integrated GRC10 with IDM 7.2 and wanted to submit access request from IDM to GRC. Being a GRC consultant you can test Web Service used to create Access Request from GRC side. It helps to check Web Service is working and you are able to submit request and its following MSMP workflow created in GRC10 by you. Once this is tested from GRC side it’s easier to use same inputs from IDM side and submit Access Request to GRC.



Web Service used to create access request from GRC is GRAC_USER_ACCES_WS (User Access Request Service) .


Follow below steps to execute Web Service.


Execute Tcode SE80 and double click on Repository Information System


Expand Enterprise Services under Repository Information System and double click on Service Definitions .


In Application Component enter GRC-AC and Execute.

Now you will be able to see all Web Service used for IDM- GRC Integration

Here double click on highlight Web Service GRAC_USER_ACCES_WS (User Access Request Service ) .


And execute GRAC_USER_ACCES_WS (User Access Request Service) from below screen


Below pop up will come. Select Generate Request Template and execute.5.png

Below output will come. From here click on XML editor and provide required details in XML tags. And execute. This will create access request in response if you have provided all the details correct. If details are not correct then you will receive Error in response .


In above Web Service there are 5 Sections as below.


  1. CustomFieldsVal
  2. Parameter
  3. RequestHeaderData
  4. User Info
  5. Requested Line Item


Mandatory fields and User information are determined based on End user Personalization (EUP) in SPRO.  ReqInitSystem in Request Header data is mandatory filed and you need to provide IDM connector information in this.



Fill details in Header data , Line Item and User Info based on your configuration


Header DATA-


<Reqtype>String 12</Reqtype>
<Priority>String 13</Priority>
<ReqDueDate>String 14</ReqDueDate>
<ReqInitSystem>String 15</ReqInitSystem>
<Requestorid>String 16</Requestorid>
<Email>String 17</Email>
<RequestReason>String 18</RequestReason>
<Funcarea>String 19</Funcarea>
<Bproc>String 20</Bproc>


Line Item Details-


<ItemName>String 21</ItemName>
<Connector>String 22</Connector>
<ProvItemType>String 23</ProvItemType>
<ProvType>String 24</ProvType>
<AssignmentType>String 25</AssignmentType>
<ProvStatus>String 26</ProvStatus>
<ValidFrom>String 27</ValidFrom>
<ValidTo>String 28</ValidTo>
<FfOwner>String 29</FfOwner>
<Comments>String 30</Comments>
<ProvAction>String 31</ProvAction>
<RoleType>String 32</RoleType>




User Info


<Userid>String 49</Userid>
<Title>String 50</Title>
<Fname>String 51</Fname>
<Lname>String 52</Lname>
<SncName>String 53</SncName>
<UnsecSnc>String 54</UnsecSnc>
<Accno>String 55</Accno>
<UserGroup>String 56</UserGroup>
<ValidFrom>String 57</ValidFrom>
<ValidTo>String 58</ValidTo>
<Empposition>String 59</Empposition>
<Empjob>String 60</Empjob>
<Personnelno>String 61</Personnelno>
<Personnelarea>String 62</Personnelarea>
<CommMethod>String 63</CommMethod>
<Fax>String 64</Fax>
<Email>String 65</Email>
<Telnumber>String 66</Telnumber>
<Department>String 67</Department>
<Company>String 68</Company>
<Location>String 69</Location>
<Costcenter>String 70</Costcenter>
<Printer>String 71</Printer>
<Orgunit>String 72</Orgunit>
<Emptype>String 73</Emptype>
<Manager>String 74</Manager>
<ManagerEmail>String 75</ManagerEmail>
<ManagerFirstname>String 76</ManagerFirstname>
<ManagerLastname>String 77</ManagerLastname>
<StartMenu>String 78</StartMenu>
<LogonLang>String 79</LogonLang>
<DecNotation>String 80</DecNotation>
<DateFormat>String 81</DateFormat>
<Alias>String 82</Alias>
<UserType>String 83</UserType>




Kind Of Error / SUCCESS message you can get in response.




<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>



  <MsgStatement>Invalid request initiation system</MsgStatement>


  <RequestId />

  <RequestNo />




<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>

  <   MsgNo>4</MsgNo>


  <MsgStatement>Invalid request type</MsgStatement>


  <RequestId />

  <RequestNo />





<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>



  <MsgStatement>Invalid priority type</MsgStatement>


  <RequestId />

  <RequestNo />






<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>



  <MsgStatement>Invalid Provision Action in line no 1</MsgStatement>


  <RequestId />

  <RequestNo />


5. When you provide al the required detail correct. SUCCESS response will be received.


<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>



  <MsgStatement>Request created successfully</MsgStatement>







6. One strange issue I have seen. If you are creating access request with user missing with GRAC_SYS auth object then you can get “Connector not configured Error”



Same type of error message you can get in IDM- VDS logs when Access Request is submitted via IDM.


Hope this will help you to understand Access Request creation using Web Service and test Web Service.



Dilip Jaiswal

Purpose of the Document:

In GRC 10.0 SAP has introduced the Centralized Emergency Access Management process unlike its older version GRC 5.3 which got mixed reviews from GRC users.

Initially a user has submitted his idea in SAP IDEA PLACE asking SAP to provide De-centralized logon in GRC 10.0 in the same way they have been using in GRC 5.3 and this has been supported by lot of GRC consultants.

Finally SAP has enabled De-centralized firefighting feature in GRC 10.0 from GRC SP10. Depending on the client's needs, the option "log on centrally" (current version 10 behavior) or "log on locally" (5.3 behavior) can be configured in GRC 10 and GRC 10.1

Also system has the ability where both centralized and de-centralized approach can be configured but user can either login centrally or locally as there can be only one firefighter session at a time.

De-centralized EAM configuration – SP13 – ID based Firefighting

Step 1: Creating Connector and Assigning Integration Scenarios

Creating Connector:

  • Create new connector using SM59 Tcode or going through below mentioned path.

SPRO -> IMG -> GRC -> Common Component Settings -> Integration Framework -> Create Connectors


  • Create ABAP connector with the options as shown below.

  • Under Logon & Security maintain the details as shown below. User RFC_USER is a system user and is available in ECD system with S_RFC access.

  • Once you have maintained all these values. Save the connector and then click on Connection Test. If it is successful, you will get below screen.

Maintain Connectors and Connection Types

  • Now click on Maintain connectors and Connection Types going to below path as this is required for assigning the connection type to our connector which is created in the above step.


  • You will get the below screen where you can see different types of connection types available in the GRC system.


  • Maintain the entries for your connector as mentioned below. Source connector is not required. Change the setting “Max No. of BG...“parameters to “3“ (i.e. this connector will use a maximum of 3 background jobs for synch jobs)

  • Now our connector needs to be assigned connector group. This is similar to logical system in GRC 5.3 where we group similar systems under one logical system. You can create your own connector group or else, when you activate BC sets for SOD rules automatically connector groups gets created in the system which were used in the SOD rules. Then you can assign your connector to the connector group as shown below.


  • Once you have these connector groups, then assign the connector group to group type as shown below.



  • Next step is to assign connectors to connector group as shown below.

Maintain Connection Settings

  • Connectors must be assigned to the all integration scenarios (AM, ROLMG, SUPMG, AUTH, PROV) available as it is a good practice according to SAP (under Common Component Settings -> Integration Framework -> Maintain Connector Settings). In the same way mentioned below repeat for ROLMG, SUPMG and PROV scenarios.

Maintain Connector Settings


  • Now go to below mentioned path for maintaining connectors with application types and enabling PSS.




Maintain Mapping for actions and Connector Groups

  • For POC purpose we are connecting GRC 10 system to ECC system and hence only one Connector group is there in active status.

  • From the same screen we can define default connector to be used for different actions as shown below.



For example if you are creating LDAP connector then the mapping between AC and LDAP fields are maintained in assign group field mapping. Once all the above mentioned steps are performed, then the next step would be to schedule the synchronization jobs in the order advised by SAP.


Step 2: Creating FF Users, FF Owners, FF Controllers in GRC 10


  • FF Users executes Tcode /n/GRCPI/GRIA_EAM from Plug-in system and login with firefighter Id’s assigned to them. So users no need to exist in GRC system any more.


  • Following role must be assigned to the Firefighter user.

SAP_GRAC_SUPER_USER_MGMT_USER for the centralization as well as Decentralization.

  • FF Id’s will be created in plug-in system and assign the role SAP_GRAC_SPM_FFID or its “Y” or “Z” equivalent to make it recognizable as FF Id.


  • FF Owner, FF Controller, Reason Codes are created and maintained in GRC system.

       NWBC -> Setup -> SuperUser Assignment and NWBC -> Setup -> SuperUser Maintenance

  •     FF Controller should also exist in the plug-in system with valid Email ID as FF login notifications will be sent to controller’s Mail Id maintained in plug-in system.


  •    FF log notifications are sent to FF controller’s mailed maintained in GRC system. Hence FF controller should exist in both GRC and Plug-in systems.


Step 3: Synchronization Jobs in GRC 10

In GRC 10 synchronization jobs can be run from SPRO->IMG, navigating to Governance, Risk & Compliance>Access Control>Synchronization Jobs

Authorization Synch
Synchronizes PFCG Authorization data

Repository Object Synch
Synchronizes Profiles, Roles, and Users master data

Action Usage Synch
Synchronizes action usage data

Role Usage Synch
Synchronize role usage data

Firefighter Log Synch

Synchronizes the firefighter logs from plug-in system to GRC system


Firefighter Workflow Synch

Initiates FF log report review workflow based up on your workflow settings which sends the FF log report to FF controller for review.


EAM Master Data Synch

This is the new job introduced as part of De-centralized firefighting. Synchronizes the EAM data from GRC box to Plug-in system. Once you have created all required users execute this job to synchronize the data from GRC to plug-in system.

These reports can also be maintained as scheduled background jobs.



Step 4: Configuration Parameters

SAP has introduced a new configuration parameter 4015 which has to be maintained as “YES” in order to enable De-centralized firefighting as shown below.

Configuration Parameters – GRC system

Configuration Parameters – Plug-in system


In GRC System:



In Plug-In system:



Step 5: Assigning FF Ids to Users

Unable to find FF Id’s in NWBC.

  1. Please check whether configuration parameters are maintained as mentioned in step 3.
  2. Please check whether all synchronization jobs are executed as mentioned in step 2.
  3. Please check whether the user who is searching for FF ID’s in NWBC has required access.
  4. Please check the below mentioned configuration also.


Assign Owner, and Controller:

Without assigning an owner and a controller, you might not be able to assign the FF ID to a Firefighter. From NWBC –> Setup –> Super User Assignment, assign Owner, and NWBC –> Setup –> Super user Maintenance, assign Controller.

Now you can assign the Firefighter Id to Firefighters either directly or through GRC access request.

   5. In plug-in system you will find all the FF roles required for user, controller etc. You need to create Y or Z copy of them and should assign them to the users.



Step 6: FF ID is assigned to the FF User

  • FF user has been assigned with the FF Id.


  • Now FF Users executes the Tcode /n/GRCPI/GRIA_EAM in plug-in system and can see the FF Id assigned to his User ID. When FF users tries to login with the FF Id assigned user will get the below error.


  • We already has RFC connector SECCLNT100 created in GRC system to connect from GRC to SEC and vice-versa. This error was resolved after creating RFC connection locally by the same name SECCLNT100 as system is expecting a local RFC connection with the same name.


  • Once this issue is fixed, users are able to login as Firefighters from plug-in systems and complete their tasks.


Step 7: Fire fighter Login and Log notifications

Configurations required for the Login Notification:

  1. In the GRC Box, maintain configuration parameters as mentioned above in Step 4.
  2. Make sure that 'EAM master sync job' is complete.
  3. Into the Plug-in system, maintain configuration parameters as mentioned above in Step 4.
  4. In the Plug-in system, FFID controller must exist with a valid email Id, as email notification is sent from the Plug-in system.
  5. Login notification mail will be sent from Firefighter User SU01 Mail Id itself in de-centralized model. Make sure that email Id of the firefighter User is also maintained properly.
  6. FF User time zone and system time zone should be the same in plug-in system.


Login Notification sent from Plug-in system:

Configurations required for the Log report Notification

Unlike Login notification, Log Report notification is sent from the GRC Box. Almost, all of the steps are same as in case of centralization.

  1. Make sure that the configuration parameter 4002 is maintained into the GRC BOX.
    1. If the 4007 is set to 'Yes' then schedule only job 'GRAC_SPM_LOG_SYNC_UPDATE'. This job will send the Log Report notification as well.
    2. If the 4007 is set to 'NO' then schedule job GRAC_SPM_LOG_SYNC_UPDATE for synchronization. It will not send the Log Report Notification. For the Log Report, another job is required to be scheduled which is 'GRAC_SPM_WORKFLOW_SYNC'.
  2. Controller of the FFID is configured with the valid Email Id.
  3. In the NWBC -> Access Management -> Controller -> make sure that 'Notification By' column is selected to 'Email'.
  4. Make sure that 'EAM master sync job' is complete.
  5. There is no setting which is required to be maintained into Plug-in system in this case.


Log Notification sent from GRC system




Firefighter Login Issues - Plug-in system

Login as firefighter using Tcode /n/GRCPI/GRIA_EAM

User will enter the reason code and activity details and click OK.

User will be presented with a login screen.



User should be assigned to the below roles and make sure user also has access to S_USER_GRP object with Activity 03,05


EAM for Webdynpro and Web based applications

Firefighter functionality is primarily designed for use with ABAP systems. Lot of us had a requirement to implement EAM for webdynpro or web based applications, but there are lot of limitations for using EAM for webdynpro and web based applications.

To understand about EAM functionality with Webdynpro applications,  please check out the below blog post.

Emergency Access Management (EAM) for Webdynpro applications or Web-based applications - GRC 10.0


Wrong Firefighter ID Status - De-centralized EAM:

When firefighter tries to logon to the system via transaction /n/GRAC_SPM, error comes:


"<Firefighter ID> is logged on using <some other firefighter id> firefighter id."

Please check below SAP notes to resolve the issue.


1895204 - Error message: <Firefighter ID> is logged on using <some other firefighter id> firefighter ID


1702370 - Wrong Firefighter Id Status


Filter Blog

By author:
By date:
By tag: