Applies to:

SAP GRC Process Control 10.1.

Summary

This document covers “How to customize Workflow name for ‘Manual Test of Effectiveness’ in GRC Process Control 10.1”?

Author: Amit Saini

Created on: April 21st, 2015

Problem Statement: Business users perform ‘Manual Test of Effectiveness’ for manual controls. In turn, multiple issues are being created for same control. For example, business users create 5-6 issues for a single control.

When users go to inbox to manage the issues, they are not able to differentiate the issues from Workflow Task text. Since GRC PC inbox does not have “Issue name“as the personalized field.

The workflow task name ‘Remediate Issue: Manual Test’ is identical for all the Workflow Tasks. It is confusing to end users, as the user need to open each task separately and identify the corresponding issue, which he needs to Remediate.  Suppose user needs to work on priority on 1 issue out of 6 issues created. So, the workflow name could be added to the workflow task and users could work on the task, according to their priority. They could differentiate the workflow tasks, if the issue name is merged with Workflow task text.

In the below screenshot, there are multiple workflow tasks, with same text :

  
Customization of the Workflow Task : Follow the below steps to personalize the text of Workflow Item.

1) Identifying  the task name for ‘Remediate issue: Manual Test’.

This can be identified by using transaction ‘SPRO’ and following the path

Governance, Risk and Compliance-> General Settings->Workflow-> Workflow Task Names-> Maintain Custom Task Names.

The technical name could be found by selecting the Inbox Task at position 53 and double click on the sub folder ‘Task Business Object’.

The task name for the ‘Remediate Issue’ is ‘TS75900006’.

2) Personalizing the Workflow Task

Execute the transaction ‘PFTC’ and chose the ‘Task Type’ as ‘Standard Task’ and Task as ‘75900006’.

Choose ‘Edit ‘to personalize the Workflow task.

Variable '&_WI_OBJECT_ID.MS_CASE_ATTR.CASE_TITLE&’ has information about the case/issue title. Hence this can be merged with existing text variable. Use this variable with the existing variable used under field 'Work Item Text'. For example,

‘&_WI_OBJECT_ID.GET_MV_TEXT()& &_WI_OBJECT_ID.MS_CASE_ATTR.CASE_TITLE&’

As shown in the below screenshot:

Save this window.

Create a new issue  for ‘Manual Test of Effectiveness’ related to control. The new workflow text would have enhanced text, which will include issue name.

For example,  I  created an issue ‘MTOE_ISSUE1’ for ‘Manual Test of Effectiveness’ related to control and the personalized workflow text
‘Remediate Issue: Manual Test MTOE_ISSUE1’ appears in the Inbox.

Applies to: SAP GRC Process Control 10.1.

Summary

This document provides information about the different Jobs that can be monitored in GRC  Process Control 10.1 for replacement and signoff.

Author :           Amit Saini

Created on: April 21, 2015

In this article, I have listed different jobs which can be activated and monitored in Process Control 10.1.

1          Transfer Work Items to replacement

In this activity you schedule the program GRPC_REPLACEMENT_MASS_ACTIVATE to transfer the work items from persons no
longer working on the specific work items to replacement persons entered in the system.

2 Maintain Workflow Notification

This job leverages workflow notification to ensure that the deadlines are met.

In this Customizing activity, you schedule the program SWN_SELSEN. The program:

1) checks whether or not there exist new work items for the scenario GRCNOTIFICATION, which is maintained in the Customizing activity Maintain Workflow Notifications.

2) Determines the e-mail addresses of the work item recipients .

It should be possible for customer to send the reminder to the receiver for the workflow tasks . For example, pre-define the reminder for Signoff workflow. Once signoff process started, send the reminder to the signoff performer.

1  Activate or deactivate the reminder for a specific workflow should be configurable. For example, customer should be able to choose to activate/deactivate the reminder for signoff workflow .

2 After the user receive the workflow task in the work inbox. Every a period of time send the reminder to the receiver. The "time period" of reminder is configurable. The "time period" could be a number of minutes/hours/days/weeks/months/years or even a specific date.

- It should be possible for customer to send the escalation to associated user for specific workflow tasks. For example, The issue owner receive a task in the work inbox for issue remediation with a due date to be April 30^th, 2015. Once the due date is expired, send an escalation to internal control manager to let him to know about it.

3 Carry forward Open Issues after Sign off

In this Customizing activity, you set up the background job 'GRPC_SAP_JOB_AFTER_SIGNOFF' that is executed once sign-off has been completed, to perform the carry forward of open issues. This allows the open issues to be processed after the sign-off data freeze for the applicable timeframe.

Once the background job is scheduled, it is executed every time the sign-off is completed. The issues that are carried forward include the assessment, testing and remediation plans.

The  system automatically creates the carry forward case for the pending cases.

a) Close assessments without issue - When there is no issue for an assessment, the assessment will be closed directly.

b) Clone the open issues - Only open issue will (with corresponding assessment , testing , remediation plan if exists) be cloned. Closed issue is
kept as it was.

c) Workflow replacement - The old issue (and the corresponding remediation plan if exists) will be removed or from work inbox(logically deleted) , and general new work item for the new cloned case.

4 Copy Documents After Carry Forward

In this Customizing activity, you set up the background job 'GRPC_DOCUMENTS_CLONING_JOB'  to carry forward cases' documents. This is executed after the carry forward of issues has been completed. This applies to assessment, testing, issue and remediation plan cases.

This process allows the document attachments from the cases to be available when the cases are carried forward. Once the background job is
scheduled, it is executed every time the background job to carry forward open issues has completed.

Applies to: GRC Process Control 10.0 / Process Control 10.1.

Summary

This document provides information “How to implement Enhancement for Custom defined field(s) in GRC Process Control 10.0 and 10.1.

Author: Amit  Saini

Created on: April 2015

Prerequisite(s) Custom Defined Field(s) are already defined.

Audience

GRC Process Control consultants, partners.

Introduction 

With SAP GRC Process Control 10.0/10.1, there is added flexibility in defining the customer-specific fields. You can define them as: ‘Single value’ or multiple values’ for either a HR entity, for example, “Organization” or a non-HR entity, for example, “Issue” In order to control the visibility of CDF fields on UI, for example to mark CDF fields as ‘Required’, ‘Hidden’, or ‘Read Only’,  we need to implement the enhancement spot.

Implementing ‘Enhancement’ spot

Firstly, we need to define a class
[Transaction ‘Se24’] which implements the interface: ‘IF_GRFN_API_CUSTOMFIELD_BADI’.

There are changing attributes CT_CUSTOMFIELD_MDATA and CT_CUSTOMFIELD_DATA available in method AFTER_RETRIEVE that can be modified.

Table CT_CUSTOMFIELD_MDATA is used adjust the following fields:

• HIDDEN can be used to hide the field on UI
• READONLY can be used to set the field “Display only”.
• REQUIRED can be used to make the field required.
• VALUESET can be used to define text for dropdown.
• FIELDLABEL can be used to adjust label of the field.

Table CT_CUSTOMFIELD_DATA is used to adjust following field: "VALUE" and  can be used for value defaulting .

By the method BEFORE_UPDATE, we can modify the value entered by user or can implement the “input check” and raise the exception; in
case the user entry does not pass the check.

Secondly, we need to implement the new BADI using enhancement spot ‘GRFN_API_CUSTOMFIELD ‘.

This enhancement spot is called during the ‘Retrieve’ and ‘Update’ of Custom Defined fields for both HR and non-HR entities.

The transaction used is SE19.

Choose enhancement as ‘GRFN_API_CUSTOMFIELD’ and click on button ‘Create Implementation’.

Enter the name and text for ‘Implementation’, we want to create and do not select the option‘Composite Enhancement
Implementation’.

An "Enhancement Implementation" can only contain one type of "Enhancement Implementation Element". Therefore, for a project where
you must implement enhancements to both an Enhancement Point, and a Function Module Interface, you cannot group them in the same Enhancement Implementation. Instead, you must create two separate Enhancement Implementations, and in turn group those in a "Composite Enhancement Implementation". For our example, we require to implement BADI and hence did not select the option ‘Composite Enhancement Implementation’.

Enter the implementation class ‘ZBADI_USER_DEFINED” defined in first step and continue.

Save and activate the ‘Enhancement Implementation’.

Now we could define the IF_GRFN_API_CUSTOMFIELD_BADI~AFTER_RETRIEVE and IF_GRFN_API_CUSTOMFIELD_BADI~BEFORE_UPDATE in implemented class ZBADI_USER_DEFINED to control the CDF on UI.

Let us understood this, with an example .Execute program ‘GRFN_CHECK_CDF’ to know the metadata created.

I want to set field ‘ZTEST_VALUE’ defined for ‘Issue’ as mandatory using my enhancement point.

So I have implemented the methods IF_GRFN_API_CUSTOMFIELD_BADI~AFTER_RETRIEVE and IF_GRFN_API_CUSTOMFIELD_BADI~BEFORE_UPDATE in class ZBADI_USER_DEFINED.

Now I perform ‘Manual Test of effectiveness’ task for a manual control.

And create issue for the control.

Method ‘API_RETRIEVE_CUSTOMFIELD’ of class ‘CL_GRFN_UTIL_CDF’
is used to modify the CDF metadata. It further calls the enhancement point ‘GRFN_API_CUSTOMFIELD’.

If method  IF_GRFN_API_CUSTOMFIELD_BADI~AFTER_RETRIEVE is implemented, it will modify the CDF metadata.

Once the source code highlighted, is executed, the metadata is changed.

CDF is enabled as mandatory with “Enhancement point’ implementation.

Now user submits data without entering mandatory custom defined fields.

A check has been implemented in IF_GRFN_API_CUSTOMFIELD_BADI~BEFORE_UPDATE  of class

‘ZBADI_USER_DEFINED’ to check the input values for CDF. This has been called via ‘API_UPDATE_CUSTOMFIELD’ of class ‘CL_GRFN_UTIL_CDF’.

User is not able to submit data without entering the Custom Defined Field(s).

Purpose of User Defaults:

When a new user is being created in the target system, all users of that system might require few common user defaults like Logon Language, Time Zone, Decimal Notation, Date Format, Parameters etc. Hence when a user is getting created through GRC, based on the request type these user defaults can be assigned to the users.

By including user defaults as part of request type (mostly New Account), user gets created with required user defaults in the target system.

Important SAP notes regarding User Defaults to refer before configuring User Defaults:

1615552 - GRC 10.0 How to set User Default

1665585 - User Defaults BRF+ rule not working correctly

2020712 - UAM: User group not provisioned after request provisioning

Steps to Implement User Defaults:

Step 1: Maintain “User Defaults “action as part of your Request Type. My Request Type 36 is for “New Account” and I have assigned “User Defaults” as shown below.

SPRO =>Governance, Risk and Compliance =>Access Control =>User Provisioning =>Define Request Type

Step 2: Go to SPRO -> IMG -> GRC -> Access Control -> User Provisioning -> Maintain User Defaults

Define User defaults for different connectors connected to your GRC system. One example as shown below:

You can assign default User Group and default Parameters based on the connector by using options “Set the User Group” and “Set Parameter ID” in the above screen as per your requirement.

Once you define the User Defaults as mentioned above and save it, a unique “Default-Id” gets created as shown below. This is the User Default Id which will be used in BRF+ decision table while configuring User Defaults.

Step 3: Existing BRF+ User Defaults application “GRAC_BRFP_USER_DEFAULTS” provided by SAP will be used during configuration of user defaults.

Copy the Function Id of USER_DEFAULT_FUNCTION from BRF+ application.

Now map the BRF+ Application for user defaults under the IMG configuration shown below:

Go to IMG->Governance, Risk and Compliance->Access Control->Maintain AC Applications and BRFPlus Function Mapping

Step 4: Add Decision Table and Loop expression to BRF+ User Defaults function as shown below:

Decision Table: In the decision table maintain entries as shown below

Loop: For using "System" as one of the fields in setting the conditions for User Defaults, SAP suggested for implementing a LOOP in BRF+ Rule. This might be needed since "System" field is not available under Request Header attributes, rather it is available as Role Attributes which are called as line-item fields while calling the BRF Rule. So, in such cases LOOP is a suggested solution, rather than using the Decision Table directly. Though within the LOOP, we can still call the Decision Table or implement IF/ELSE conditions.

Ruleset: When a Function is in event mode, it looks for additional logic execution depending on the Rule-set defined.

Once all above things are done, activate the Decision table, Loop, Ruleset, Function and Application.

Step 5:  Now Create an Access request to test the User defaults and once the User is created please cross check the User Defaults in SU01 to check if everything is fine. If all the above steps are followed properly, User defaults will get updated properly as below in SU01.

Reference Links: http://wiki.scn.sap.com/wiki/display/GRC/Setting+up+User+Defaults

RELEASED NOTES AND KBAs

GRC-SAC-ARA

   2119685  Add multiple client support for data load for Role Search

   2104079  While copying a role  in role mitigation, the role name which contains ampers

   2113066  Role level Risk Analysis not working for input with '*' in them

   2116308  CX_SY_CONVERSION_OVERFLOW error while running role simulation with include user

   2117916  Incorrect status in Access rule detail report

   2120491  Text incorrect for a check box in the Risk Analysis simulation screen

   2120686  T-Code search is slow while opening a function

   2121438  GRAC_DELETE_REPORT_SPOOL doesn't delete all data

   2121521  Mitigation on Business Role Level does not work

   2122162  Analysis Criteria section does not collapse

GRC-SAC-ARQ

   1168508  Compliant User Provisioning 5.3 Support Package (VIRAE)

   1907636  UAM: Distribution list as role onwer was not supported in UAR jobs.

   1976652  Repository sync job is deleting business role assignment data

   2056973  UAM: Incorrect provisioning action is displayed when roles are selected from existing assignments

   2068412  UAM: Approval action not working correctly for mapped role

   2096567  UAM: UAR request are displaying indirectly assigned derived roles and incorrect

   2108896  UAM: Role range in role import is not considered

   2110815  Copy multiuser request not working correctly in case of multiuser request

   2118201  UAM: Re-login required when clicking role name from existing assignments

   2119463  UAM: 'Add comment' hyperlink not available during request approval

   2119407  UAM: Incorrect validity dates when business role is added in the simplified access request

   2120231  UAM: Submission notification variable not filled correctly for business role

   2120438  UAM: Dump while adding business role to access request

   2121176  UAM: User group not provisioned while creating/changing user in CUA

   2122128  User Defaults error: "Entry ALL does not exist in GRFNCCICONNECTOR (check entry)"

   2122132  HR Trigger error "Roles not present in request. No request can be created."

   2122134  MSMP Notification Agent of type "PFCG User groups"

   2122147  Approval error: "Line item comments are mandatory for rejection for assignment"

   2122152  SAP Enterprise Portal SSO does not work for the GRC notification variable links

GRC-SAC-BRM

   1897889  Job Status empty after deleting the role in background.

   1971192  "Role Search” is not consistent with role search in “Roles by Owners and Approver" report

   1987973  The “List of Approvers” check box is not enabled

   2031203Option to add org value map name is not available in naming convention for derived roles
                      and Enhancement implementation is not called

   2045102  Description for single role is empty when import is manually

   2045597  Role Comparison is Incorrect on Actions for Roles with no transactions

   2050347  Role Comparison - role and landscape link work incorrect

   2100042  Critical Roles/Profiles create in ZH can't be display in EN

   2103555  Useless spaces in authorization Error message in role search

   2109444  Language not considered while fetching role description during role import.

   2115671  AC10.1 SP04: GRAC_ROLED object check issues

   2117294  AC10.1 - Poor performance of Repository Sync

   2117340  Default role import not working

   2118711  GRACUSERROLE table not getting updated

   2120396  Unable to import Non PFCG role

GRC-SAC-EAM

   1902228  Irrelevant GRC TCodes are showing in transaction logs

   1962440GRC EAM - Change Log Collection Performance Enhancement

   1988760  Remote login is happing with FFID without using Fire Fighter application

   2015290  FFuser and controller canont be same person via Emergency access request

   2026907  Invalid Super user report Inconsistency

   2118517  Firefighter ID description is coming blank in access request

   2119915  GRC 10.1 EAM: Add button on firefighter assignment screen in inactive

   2118517  Firefighter ID description is coming blank in access request

   2122027  How to identify the workflow generated for a given FFID session?

GRC-SAC-UAR

   2090183  UAM: Incorrect request type action display in template based request

   2103580  UAM: Multiple UAR request generate UAR role rejection for single request

GRC-SAC-UPG

   1731987  GRCPINW V1000_731 Install/Delta Upg/SP on SAP_BASIS 731

GRC-SAC-WF

   2009630  UAM: Company attribute is not available in BRF rule structure for Role Approval

GRC-FRA             

   2118928  Collective Note Error Corrections for DU SAPFRA_CM_FND Fraud Management 1.1 SP05

   2119471  HANA Rules Framework Support Package 2 in Fraud Mangement SP5 verwenden

   2118244  Performance Improvement for Claim Facette UI

   2120209  Network Analysis Doesn't Show Navigation Targets

   2121072  SAVE in Decision Fecett of the alert details is not working

GRC-SPC-AC

   1869786  Currency Conversion not working for BRF+ in AMF

   1902686  Conversion routine does not work in Programmed rules

   1917806  Value for column comes blank for change log check scenario

   1930781  Adhoc query on table TSTC do not return results in data source

   1972490  Currency field value is not displayed correctly in Adhoc query

   2048491  Exception List is not editable for Multiple Deficiency

   2096980  Unreserve the work item for process control work items

GRC-SPC-AD

   2120661  Policy Attachment is Not Attaching in PDF Survey in correct form

GRC-SPC-AP

   1948002  PC task get reserved on Approver Delegation to a AC user

GRC-SPC-IU

   1912569  Problem in upgrade at step GRPC_30_2010_UPG_P1_LOCAL_CHG

GRC-SPC-MD

   1914305  Multi Language support issues

   1923467  Duplicated issues on Issue Status Report

   2025068  GRPC_PSTEP_SYNCHRONIZE creates delinkage of objects at local level

   2032790  Frequency is not updated when control type is changed to Event based

   2120592  The replacement functionality dumps for some users

   2119204  Valid From date of Sub Process with respect to the Timeframe selected.

GRC-SPC-MT

   2121735  Custom Defined Field is not enable when Remediation Plan is editable

GRC-SPC-PR

   2112810  Copy function of ad hoc issue management does not work

GRC-SPC-RE

   2010446  Control Test of effectiveness Dashboard report does not show complete data

   2083218  Column Owner displays only one user

   2109409  How to debug the reporting engine for Process Control and Risk Management

    2113340  Dump when searching for Organization unit in Policy Profile

GRC-SPC-SA

   1777657  Policy survey result report shows time in UTC

   1897216  Remediation Plan populated the incorrect user

   2031859  Sorting does not work as expected after filter is used in Planner

   2070990  Applog handling for OWP inbound processing

   2119746  Error in Sending Surveys due to invalid E-mail address of recipient

   2120558  Checkman error SP09

   2121796  This note is technically required to be implemented and avoid delta in 'Role Assignment' correction

GRC-SPC-SC

   2065101  Organization maintenance is not possible for the user with ability to do subprocess assignment

    2119901  Authorization check on Plan Activity field in Planner Monitor

GRC-RM              

   1657668  Checkman error in migration tool

   2109176  Authorization check for analysis create displays description instead of the name of the risk

   2118237  New IMG entry - Activate Work Inbox Task Grouping

   2120642  Popup window with error when deleting loss event

   2120510  Reporting: Multiplicated results for non-power user in LEM hierarchical reports

   2119756  Checkman

   2120121  Reporting: Authorization check improvement

   2113131  Interface Note for Enhanced Risk Graphic View

   2120552  Risk change history - underlying risks

   2120819  Risk change history - attachments and links

RELATED INFORMATION

    2094723 - Consolidated Note for SAP Access Control 10.0 Master Note

   2096196- Consolidated Note for SAP Access Control 10.1 Master Note

   2104086 - Consolidated Note for Process Control 10.0 Master Data

   2105791 - Consolidated Note for Process Control 10.1 Master Data

This document has been written to explain how you can customise the ROLE METHODOLOGY steps depending on role criteria. The configuration requires the use of a BRF+ rule that using CND_GRP (condition group) as the rule result.

Please note, that this is not the same as Condition Group Mappings for Default Approvers (specified via NWBC screens). If you are interesting in the condition group mappings for default approvers then click here: BRM Default Approvers via Condition Groups

What’s it all about?

Business Role Management makes use of the role maintenance process steps known as the Role Methodology. You have two options with configuring Role Methodology:

• Default only – every role will have the same set of methodology steps. You can alter the default in IMG, however the steps apply to all roles. The default is also the methodology steps that is loaded when you first choose to create a new role.
• Custom BRF+ - configure use of condition groups and map different role methodologies depending on the role criteria. This provides great flexibility to have different steps depending on role information; require approval for some and not others; and a different sequence of steps.

Why isn’t the default enough?

This all comes back to your BRM design (funny that). If you have business rules that determine different scenarios for roles then you will want a set of steps to match them. For example, you might decide the Process Owner (i.e. Role Content Owner) does not need to approve Derived Roles so you don’t need an approval step. You might have decided Business Roles don’t need Test Documentation (random example here). You might even decide you’d rather a different sequence of steps depending on the role (i.e. Approve role before making a change).

Put simply, default methodology is inflexible and may not match your business process for role management. Configuring multiple methodologies allows you to match process to steps in the system.

Just a few lessons learned before we hit the configuration

From configuring this functionality and also responding to questions in SCN, there a few lessons learned I thought I’d share relating to this topic.

Why do some roles miss some role methodology steps?

Okay, I’m going to contradict myself to what I said above. The default methodology is meant to apply the same steps to all roles regardless of role criteria. However, the GRC component has an additional mapping table in the back-end that determines which methodology steps apply to the specific role. For example, a business role is a non-technical role and therefore, would never require a step to “Maintain Authorisations”. As a result, if you were to add “Maintain Authorisations” as a step for a Role Methodology that applies to business roles, it still will not appear in your NWBC screens.

When is the role methodology going to take place?

When you build a role for the first time, the calculation of the role methodology does not occur until after you press save on the DEFINE ROLE stage. Only the attributes related to the definition phase can be used as the criteria for the role methodology. Initially, the default methodology will appear. On save of the Define Role stage a “recalculation” of the methodology will occur.

The Role Methodology is not determined until:

• Create New Role > After the Role Definition is saved (default methodology will load)
• Maintain Role > On open the methodology will load (possibly you may need to Reapply Methodology if the configuration has changed)
• Reapply Methodology – it will check if layout needs to change and adjust accordingly

My approach has been to include 1 step for the default methodology – Define only. This removes all other steps from the user. When they press save, the role is then evaluated and the process steps are calculated and added to the NWBC screen to continue role maintenance. My thought was this makes it clear to the user that the steps will be defined once they specify the role attributes.

What does this mean in the NWBC?

The Default Role Methodology (box selected in Define Methodology Processes and Steps in IMG) will load when a new role is created, regardless of role type (as per screen shot below).

On completing and saving of the Define Role > Details information, the BRFplus rule is executed and the methodology is updated. The GRACROLE table stores the methodology for the role and the step is it up to.

If changes are made to the role methodology, the administrator can choose to “Re-Apply”. The Role Definition in GRACROLE table is re-evaluation and if it does not match the methodology, the methodology will reset.

Summary of Steps to configure Methodology

This section does not capture the Business Role Manage configuration steps for other aspects of BRM (such as role type, project, etc). This is a high level overview of the step intended to show you how the configurations comes together. It is not meant to act as step by step instructions.

1. Activate BC Set GRAC_ROLE_MGMT_METHODOLOGY
2. BRFplus Function for METHODOLOGY
3. Assign Condition Groups to BRFplus Functions
4. Define Methodology Processes and Steps
5. Associate Methodology Process to Condition Group

[1] Activate BC Set GRAC_ROLE_MGMT_METHODOLOGY

Activating this BC Set will provide the baseline configuration date for role types, steps, etc is populated. Regardless of your design, it is best to activate this BC Set and then make the necessary configuration changes.

[2] BRFplus Function for METHODOLOGY

The IMG provides a step to automate creation of the BRF+ rule by creating the application, function and decision table structure.

Transaction: GRAC_GEN_ERM_BRFRULE

Program: GRAC_GENERATE_ERM_BRFRULE

IMG Navigation: Governance, Risk and Compliance > Access Control > Role Management > Generate BRFPlus Applications, Approvers, and Methodology Functions

One the program has created the BRF+ function and decision table, you can then maintain the decision table. In this, you will need the CND_GRP as your output. Create a rule for each different role scenario you need to handle.

The Column Name for GRAC_CNGP is the return result. These values must match the Condition Group Id in Associate Process Methodology to Condition Group.

[3] Assign Condition Groups to BRFplus Functions

IMG Navigation: Governance, Risk and Compliance > Access Control > Role Management > Assign Condition Groups to BRFPlus Functions

Within the IMG you need to tell GRC which BRF+ function to execute when Methodology is evaluated. Again, Condition Group is used but it is not the same as the CND_GRP that you mapped out in the previous step. You only need to create one entry for METHODOLOGY and map it to the Application/Function that you created. Unlike the MSMP, you do not enter the Application or Function Ids (alphanumeric number).

If this step is not completed, then BRM will only use default methodology.

From a background table point of view, the GRACCNDGPTYPE contains technical information used to build/evaluate the Methodology rule.

[4] Define Methodology Processes and Steps

In this step you build each methodology scenario. For each scenario, you then define the necessary steps including the sequence. The Define step information will come as part of the BC Set. There should be no need to update this configuration unless you need to add the elusive Provisioning Step.

[5] Associate Process Methodology to Condition Group

IMG Navigation: Governance, Risk and Compliance > Access Control > Role Management > Associate Methodology Process to Condition Group

In this step of the configuration, you need to map the BRFPlus Results for Condition Group (CND_GRP) to the Methodologies that you just configured. You are able to map multiple condition group outputs to the same methodology step.

Useful Tables

Happy role building with Access Controls

Regards

Colleen

P.S I would love to hear your thoughts on designing the role methodology configuration and lessons learned.

Hi All,

This document is to discuss OBJECTS_OBJREF_NOT_ASSIGNED dump we have encountered on our GRC system(GRC 10).

We had a scenario where certain users are unable to display/process their GRC request from the browser with HTTP 500 - Internal Server error ( Screen-1) on the browser and OBJECTS_OBJREF_NOT_ASSIGNED  dump in the GRC system(ABAP Stack).

Our security team investigated this for missing authorizations and they also deleted and recreated the user, but users still have this issue.

Screen 1 : Error user received

Screen 2 : ABAP dump on GRC system

Dump : OBJECTS_OBJREF_NOT_ASSIGNED

Runtime Errors OBJECTS_OBJREF_NOT_ASSIGNED

Excetion : CX_SY_REF_IS_INITIAL

ABAP Program CL_POWL_UI_HELPER=============CP

Application Component CA-GTF-SGF-POW

Reason for dump:

     On further investigation of this issue we understood that this issue was caused due the old query/queries cached for that particular user id and got corrupted. Hence when user tries to open his/her GRC session, system was executing these corrupted query and hence dumps in the system. As these quires are stored at database level against the user name, the attempt to delete and recreate the user id will not work in this case.

Resolution :

     We have run a report POWL_D01 to fix this issue. This report is used to clear the cache for the users to delete the all old queries .

This report allow you to input affected user id( multiple selection available) and you can run in display mode to view the current queries.

Screen 3 : POWL_D01 selection screen

Check box 'DISPLAY' will allow you to view the queries before deleting them, remember to un-tick this box to cleat the user cache

Screen 4 : Report output on deleting the user cache

Result :

     User will be able to run new queries from browser without any dumps.

References :

• If you are interested to know more about report on POWL(Personal Object Worklist) please go though the below link

http://wiki.scn.sap.com/wiki/display/WDABAP/POWL+Reports

• FAQ on POWL

http://wiki.scn.sap.com/wiki/display/WDABAP/FAQ+ABOUT+POWL

Please comment and let me know if you have faced similar errors and resolution details.

Purpose

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.

Overview

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 Location field and Role Name. Common scenario is that the PFCG roles will be the same but depending on Locations approvers should be different, hence to achieve this scenario, custom BRF+ agent rule is used.

Steps to build the BRF Rule:

Creating BRF+ Rule for determining Agent based on Location Field

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.

Or

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.

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 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.

Second Rule

Second 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.

Once above things are done activate your Loop and Finally Ruleset expression looks as below. Just simulate your function and check if the data is proper.

Purpose of User Defaults:

When a new user is being created in the target system, all users of that system might require few common user defaults like Logon Language, Time Zone, Decimal Notation, Date Format, Parameters etc. Hence when a user is getting created through GRC, based on the request type these user defaults can be assigned to the users.

By including user defaults as part of request type (mostly New Account), user gets created with required user defaults in the target system.

Important SAP notes regarding User Defaults to refer before configuring User Defaults:

1615552 - GRC 10.0 How to set User Default

1665585 - User Defaults BRF+ rule not working correctly

2020712 - UAM: User group not provisioned after request provisioning

Steps to Implement User Defaults:

Step 1: Maintain “User Defaults “action as part of your Request Type. My Request Type 36 is for “New Account” and I have assigned “User Defaults” as shown below.

SPRO =>Governance, Risk and Compliance =>Access Control =>User Provisioning =>Define Request Type

Step 2: Go to SPRO -> IMG -> GRC -> Access Control -> User Provisioning -> Maintain User Defaults

Define User defaults for different connectors connected to your GRC system. One example as shown below:

You can assign default User Group and default Parameters based on the connector by using options “Set the User Group” and “Set Parameter ID” in the above screen as per your requirement.

Once you define the User Defaults as mentioned above and save it, a unique “Default-Id” gets created as shown below. This is the User Default Id which will be used in BRF+ decision table while configuring User Defaults.

Step 3: Existing BRF+ User Defaults application “GRAC_BRFP_USER_DEFAULTS” provided by SAP will be used during configuration of user defaults.

Copy the Function Id of USER_DEFAULT_FUNCTION from BRF+ application.

Now map the BRF+ Application for user defaults under the IMG configuration shown below:

Go to IMG->Governance, Risk and Compliance->Access Control->Maintain AC Applications and BRFPlus Function Mapping

Step 4: Add Decision Table and Loop expression to BRF+ User Defaults function as shown below:

Decision Table: In the decision table maintain entries as shown below

Loop: For using "System" as one of the fields in setting the conditions for User Defaults, SAP suggested for implementing a LOOP in BRF+ Rule. This might be needed since "System" field is not available under Request Header attributes, rather it is available as Role Attributes which are called as line-item fields while calling the BRF Rule. So, in such cases LOOP is a suggested solution, rather than using the Decision Table directly. Though within the LOOP, we can still call the Decision Table or implement IF/ELSE conditions.

Ruleset: When a Function is in event mode, it looks for additional logic execution depending on the Rule-set defined.

Once all above things are done, activate the Decision table, Loop, Ruleset, Function and Application.

Step 5:  Now Create an Access request to test the User defaults and once the User is created please cross check the User Defaults in SU01 to check if everything is fine. If all the above steps are followed properly, User defaults will get updated properly as below in SU01.

Reference Links: http://wiki.scn.sap.com/wiki/display/GRC/Setting+up+User+Defaults

Emergency Access Management (EAM) is basically designed to support ABAP based applications. Hence there are lot of limitations and issues if it is used for Webdynpro and Web based applications.

Please go through below SAP notes when trying to implement EAM for Webdynpro or Web-based applications to understand the GRC EAM limitations.

1796682 - 'User Type must be Dialog User' Dump comes when FFID tries to login to NWBC

1905295 - Launching firefighter application from NWBC not working

Object Services icon not available in Firefighter ID session

Important points to be considered

1. Firefighter approach will not work for Webdynpro and Web based applications if Firefighter ID is a service UserID. Please check the below SAP note for the same

1588075 - SSO fails for service type users in FF session.

2. Since SAP is not supporting SSO for service UserIDs, in GRC 10 SAP is suggesting a work around to convert Firefighter IDs from Service to Dialog user type to make them work properly.

3. When Firefighter ID is made as dialog user type, make sure that no password aging policy is implemented in that system.If you have password aging active in your system, then you will be requested to change the password at regular intervals.

4. Maintain some unknown password to the Firefighter ID after converting to dialog user type or generate the password and save it. Now this Firefighter ID can be used to login as Firefighter.

5. Once the above changes are made and when Firefighter user executes NWBC or CRM_UI transactions, web links shows a screen with Change password for Firefighter IDs. To avoid this issue implement the below SAP note.

1736116 - Password change window pops up after Firefighter ID launches NWBC

6. The log for the activities performed by Firefighter id are picked first from STAD and then from CDHDR. If the same details are not available in these 2 then activity details will not be picked at all. I believe that such information is not captured in above 2 if the firefighter id logs onto web applications and that is why it will not be picked.

Before gathering the above information, i have gone through lot of discussion on this forum regarding the same.

Does SPM (firefighter) support transactions CRM_UI, WUI, START_BSP using SSO?

Risk Analysis, SPM for CRM UI ( CRM 2007)

EAM Issue

Configure Emergency Access (EAM) in GRC 10 | SCN

There is a idea submitted in the Idea place requesting SAP to enhance GRC 10 to support EAM for CRM,SRM, TM etc which uses Web UI. Please check it out.

EAM - Firefighter not works for portal system such SRM - CRM , etc : View Idea

Hi All

If you are wondering what this document is all about then please refer to: Community Collaboration for GRC Blogs and Documents - you will find an overview of what this community collaboration is about and the rules on how you can contribute. You are still encouraged to write your own blogs and documents without participating in this process (it would be nice if you could update this document to let the community know you are working on something).

You are also welcome to be both the person who suggests the topic and the author. This can advertise you are working on the topic and hold yourself accountable to a deadline that the community is aware of.

Remember: Add a row below the 3rd row of the table to included your suggestion. Please do not change the first three heading rows as these rows indicate the title and a short summary of the content below. When including your name, please include your SCN profile as a hyperlink (easiest way to open your Profile in a new browser tab and copy the URL)

Sign off is Process of freezing the data for particular timeframe. Once the signoff is done data cannot be changed. All
the pending tasks including pending issues and plans will be cloned and the previous tasks for the user will be logically deleted.

1.Close assessments without issue - When there is no issue for an assessment, the assessment will be closed directly.

2.Clone the open issues - Only open issue will (with corresponding assessment , testing , remediation plan if exists) be cloned. Closed issue is
kept as it was.

3.Workflow replacement - The old issue (and the corresponding remediation plan if exists) will be removed or from work inbox(logically deleted) , and general new work item for the new cloned case.

For example, at the moment of sign off, Assessment didn’t finish and it had one issue and Remediation Plan to be working.

This task was blocked during the signoff. When this activity was finished, the remediation plan owner is apt to update the remediation plan
progress and conclude the task. So the system automatically creates the carry forward case for the pending cases.

The flow diagram above explains that all the pending tasks including pending issues and plans will be cloned and the previous tasks for the user will be logically deleted.

Functionality:

Signoff will be performed for whole system which means all the organization in standard hierarchy.

Workflow:

1 Sign off is bottom up process.

2 Sign off for Organization is only triggered if Subject to signoff is Yes for that particular regulation

3 Workflow will be sent lowest level of organization.

4 Once the lowest level is completed the workflow is triggered to parent and finally reaches the corporate. Even if multiple corporate is present it follows the same process.

5 Process will end once it finds the corporate node.

6 For corporate the workflow will be sent the CEO/CFO of the company

7 For Organization unit normally be triggered to Organization owner.

IMG:

Below two screenshot explains how the workflow is triggered:

Duer Org 2 is child of Duer Corp.

After Planning Sign off from Planner:

1. Take the task plan id from GRFNTASKPLAN using timeframe and year.

2 Enter the task plan id noted above and query GRPCSIGNOFFPLAN.All the organization to be signed off will present once the plan is
completed.

3 Once the signoff is done from inbox, data is stored in GRPCSIGNOFF,GRPCCLOSING, andGRPCCLOSINGBG.

4 ENTRY in GRPCCLOSING is responsible for setting locking of data in frontend.

After signoff all the data Organization and local sub process, local control and respective Central sub process, central Control, Risk Template, Control
Objective, Account Group are locked for the timeframe and cannot be changed.

4.1 Sign off is regulation specific.

4.2 If organization is signed off and if one of Control assigned to Organization belongs to different regulation then the local control should be
editable.

5 Org id will be stored in GRPCCLOSINGBG for carry forward job, once the job is completed the entry is removed from the table GRPCCLOSINGBG.

6  For the Corporate Org if more than on user (CEO/CFO) is assigned then both the user should signoff the Corporate.

7 In carry forward a new case id will be created and relationship is maintained in GRPCCASERELA table.

Carry forward is to move the open issues and remediation plan of an assessment or testing to future timeframe. This is taken care by Background job.

In this Customizing activity, you set up the background job that is executed once sign-off has been completed, to perform the carry forward of open
issues. This allows the open issues to be processed after the sign-off data freeze for the applicable timeframe.

Once the background job is scheduled, it is executed every time the sign-off is completed. The issues that are carried
forward include the assessment, testing and remediation plans.

JOB NAME: GRPC_SAP_JOB_AFTER_SIGNOFF

8 Attachments  will also be carry forwarded.

In this Customizing activity, you set up the background job to carry forward cases' documents. This is executed after the carry forward of issues has
been completed. This applies to assessment, testing, issue and remediation plan cases.

This process allows the document attachments from the cases to be available when the cases are carried forward. Once the background job is scheduled, it is executed every time the background job to carry forward open issues has completed.

JOB NAME:
GRPC_DOCUMENTS_CLONING_JOB

8.1 In the signed off timeframe below screenshot;

8.2. In the non- signed OFF timeframe the attachments is

9 The CF status of an assessment or testing will be Initially ^: No carry forward

Once Sign off is Done -

Old case id CF status ^is Carry Forward.

New Case id CF status  Carry forward without target timeframe. ( because timeframe can be anything next month or year).

10 After the signoff is planned if we change the Radio button in Organization to “ Not Subject to sign off”

Then when we open the work item of signoff task a new button called Close without signoff will appear

Report:

Signoff is done for the Organization in August 2012 .Organization has an open issue and remediation plan.

If we run the report for example remediation plan in August the carry forward status will be as below:

If we run the same report in September the status will be as below:

Points to be note:

1 Sign off cannot be planned for single Organization and it will be planned for all organizations

2 Organization should not be created in the same timeframe once the sign is planned for the signoff (If created will give an error while signing off
from the inbox)

3 Signoff task should not be forwarded manually using standard workflow functionality Transaction codes.

4 Even if the user is authorized to single Org- unit if the user plans sign off the signoff will be planned for all organization(s).

Dear all,

the motivation to write this document comes with the GRC Document Collaboration Topics project. Leo has requested more information about EAM audit trails and utilisation from a business point of view.

SAP Access Control with its module Emergency Access Management (EAM) enables users to perform activities outside their job role under a Firefighter ID in a controlled and auditable environment. A Firefighter ID can be checked out temporarily by assigned users (Firefighters) directly in the plug-in systems (if decentralized approach is set up) or from the GRC box. The application then tracks, monitors and logs the activities performed with the Firefighter ID and sends the logs to a pre-defined controller for subsequent audit trails.

The following flowchart provides a high-level overview of the EAM utilisation and log review process.

Some notes and clarifications of the process and its decisions:

Additional information
In case of inappropriate usage, or also when the Firefighter ID Controller wants more information, the work item can be forwarded to the Firefighter. The Firefighter can then provide more details in the Notes tab and return the work item back to the Controller.

Further actions

In case of inappropriate usage the Firefighter ID Controller has to decide whether the Firefighter ID needs to be removed, the Firefighter to be trained properly, or to impose sanctions against the Firefighter. In addition most of the cases the inappropriate actions need to be withdrawn/corrected.

EAM Reporting

More information and what data gets logged can be seen here: Emergency Access Management Reporting

Looking forward to your valuable feedback.

Thanks for reading.

Best regards,

Alessandro

Dear all,

SAP Customers Influence program gives you the opportunity of collaborating closely with SAP development teams in development projects. To emphazie important ideas we have collected the most importants to get your support and your subscription. As this program closes shortly we encourage you to review and subscribe as soon as possible.

Influence program from GRC can be found here: https://influence.sap.com/ct/c_ent_homex.bix?level_id={811F71D3-900C-45FA-9AE7-A8545B9BF94C}&a=OD5979

Most important ideas

Mitigation Control Assignment vs Access Request

https://influence.sap.com/D8577

BRM - Deletion of Roles/Deactivation of roles process has to be improved

https://influence.sap.com/D8382

Set a maximum time span for delegation

https://influence.sap.com/D8609

Provision roles as they approved

https://influence.sap.com/D8367

Handling of Acesss Request Management while system are not available (e.g. inspection windows)

https://influence.sap.com/D8338

Role validity period is not considered for risk analysis in access request

https://influence.sap.com/D8318

Fire Fighter ID Review (Similar to User Access Review)

https://influence.sap.com/D8137

Intergrate ST03N transaction usage statistics into access risk analysis

https://influence.sap.com/D7213

Provide a tcode like SU10 to make mass changes to FF owners and controllers, Role Approvers, etc.

https://influence.sap.com/D7638

UAR - No Export Function

https://influence.sap.com/D7367

GRC - ARQ - Multi-User Requests Should Have Removals Per Users

https://influence.sap.com/D7640

AC 10.1 Roles Search / Mass update - Enhance search criteria by 'Between'

https://influence.sap.com/D8114

Mass Update Business Role Assignments

https://influence.sap.com/D8574

Thanks for your support in advance.

Best regards,

Alessandro & Madhu

Applies to:

SAP GRC Process Control 10.1.

Summary

This document covers “How to customize Workflow name for ‘Manual Test of Effectiveness’ in GRC Process Control 10.1”?

Author: Amit Saini

Created on: April 21st, 2015

Problem Statement: Business users perform ‘Manual Test of Effectiveness’ for manual controls. In turn, multiple issues are being created for same control. For example, business users create 5-6 issues for a single control.

When users go to inbox to manage the issues, they are not able to differentiate the issues from Workflow Task text. Since GRC PC inbox does not have “Issue name“as the personalized field.

The workflow task name ‘Remediate Issue: Manual Test’ is identical for all the Workflow Tasks. It is confusing to end users, as the user need to open each task separately and identify the corresponding issue, which he needs to Remediate.  Suppose user needs to work on priority on 1 issue out of 6 issues created. So, the workflow name could be added to the workflow task and users could work on the task, according to their priority. They could differentiate the workflow tasks, if the issue name is merged with Workflow task text.

In the below screenshot, there are multiple workflow tasks, with same text :

  
Customization of the Workflow Task : Follow the below steps to personalize the text of Workflow Item.

1) Identifying  the task name for ‘Remediate issue: Manual Test’.

This can be identified by using transaction ‘SPRO’ and following the path

Governance, Risk and Compliance-> General Settings->Workflow-> Workflow Task Names-> Maintain Custom Task Names.

The technical name could be found by selecting the Inbox Task at position 53 and double click on the sub folder ‘Task Business Object’.

The task name for the ‘Remediate Issue’ is ‘TS75900006’.

2) Personalizing the Workflow Task

Execute the transaction ‘PFTC’ and chose the ‘Task Type’ as ‘Standard Task’ and Task as ‘75900006’.

Choose ‘Edit ‘to personalize the Workflow task.

Variable '&_WI_OBJECT_ID.MS_CASE_ATTR.CASE_TITLE&’ has information about the case/issue title. Hence this can be merged with existing text variable. Use this variable with the existing variable used under field 'Work Item Text'. For example,

‘&_WI_OBJECT_ID.GET_MV_TEXT()& &_WI_OBJECT_ID.MS_CASE_ATTR.CASE_TITLE&’

As shown in the below screenshot:

Save this window.

Create a new issue  for ‘Manual Test of Effectiveness’ related to control. The new workflow text would have enhanced text, which will include issue name.

For example,  I  created an issue ‘MTOE_ISSUE1’ for ‘Manual Test of Effectiveness’ related to control and the personalized workflow text
‘Remediate Issue: Manual Test MTOE_ISSUE1’ appears in the Inbox.

Applies to: SAP GRC Process Control 10.1.

Summary

This document provides information about the different Jobs that can be monitored in GRC  Process Control 10.1 for replacement and signoff.

Author :           Amit Saini

Created on: April 21, 2015

In this article, I have listed different jobs which can be activated and monitored in Process Control 10.1.

1          Transfer Work Items to replacement

In this activity you schedule the program GRPC_REPLACEMENT_MASS_ACTIVATE to transfer the work items from persons no
longer working on the specific work items to replacement persons entered in the system.

2 Maintain Workflow Notification

This job leverages workflow notification to ensure that the deadlines are met.

In this Customizing activity, you schedule the program SWN_SELSEN. The program:

1) checks whether or not there exist new work items for the scenario GRCNOTIFICATION, which is maintained in the Customizing activity Maintain Workflow Notifications.

2) Determines the e-mail addresses of the work item recipients .

It should be possible for customer to send the reminder to the receiver for the workflow tasks . For example, pre-define the reminder for Signoff workflow. Once signoff process started, send the reminder to the signoff performer.

1  Activate or deactivate the reminder for a specific workflow should be configurable. For example, customer should be able to choose to activate/deactivate the reminder for signoff workflow .

2 After the user receive the workflow task in the work inbox. Every a period of time send the reminder to the receiver. The "time period" of reminder is configurable. The "time period" could be a number of minutes/hours/days/weeks/months/years or even a specific date.

- It should be possible for customer to send the escalation to associated user for specific workflow tasks. For example, The issue owner receive a task in the work inbox for issue remediation with a due date to be April 30^th, 2015. Once the due date is expired, send an escalation to internal control manager to let him to know about it.

3 Carry forward Open Issues after Sign off

In this Customizing activity, you set up the background job 'GRPC_SAP_JOB_AFTER_SIGNOFF' that is executed once sign-off has been completed, to perform the carry forward of open issues. This allows the open issues to be processed after the sign-off data freeze for the applicable timeframe.

Once the background job is scheduled, it is executed every time the sign-off is completed. The issues that are carried forward include the assessment, testing and remediation plans.

The  system automatically creates the carry forward case for the pending cases.

a) Close assessments without issue - When there is no issue for an assessment, the assessment will be closed directly.

b) Clone the open issues - Only open issue will (with corresponding assessment , testing , remediation plan if exists) be cloned. Closed issue is
kept as it was.

c) Workflow replacement - The old issue (and the corresponding remediation plan if exists) will be removed or from work inbox(logically deleted) , and general new work item for the new cloned case.

4 Copy Documents After Carry Forward

In this Customizing activity, you set up the background job 'GRPC_DOCUMENTS_CLONING_JOB'  to carry forward cases' documents. This is executed after the carry forward of issues has been completed. This applies to assessment, testing, issue and remediation plan cases.

This process allows the document attachments from the cases to be available when the cases are carried forward. Once the background job is
scheduled, it is executed every time the background job to carry forward open issues has completed.

Applies to: GRC Process Control 10.0 / Process Control 10.1.

Summary

This document provides information “How to implement Enhancement for Custom defined field(s) in GRC Process Control 10.0 and 10.1.

Author: Amit  Saini

Created on: April 2015

Prerequisite(s) Custom Defined Field(s) are already defined.

Audience

GRC Process Control consultants, partners.

Introduction 

With SAP GRC Process Control 10.0/10.1, there is added flexibility in defining the customer-specific fields. You can define them as: ‘Single value’ or multiple values’ for either a HR entity, for example, “Organization” or a non-HR entity, for example, “Issue” In order to control the visibility of CDF fields on UI, for example to mark CDF fields as ‘Required’, ‘Hidden’, or ‘Read Only’,  we need to implement the enhancement spot.

Implementing ‘Enhancement’ spot

Firstly, we need to define a class
[Transaction ‘Se24’] which implements the interface: ‘IF_GRFN_API_CUSTOMFIELD_BADI’.

There are changing attributes CT_CUSTOMFIELD_MDATA and CT_CUSTOMFIELD_DATA available in method AFTER_RETRIEVE that can be modified.

Table CT_CUSTOMFIELD_MDATA is used adjust the following fields:

• HIDDEN can be used to hide the field on UI
• READONLY can be used to set the field “Display only”.
• REQUIRED can be used to make the field required.
• VALUESET can be used to define text for dropdown.
• FIELDLABEL can be used to adjust label of the field.

Table CT_CUSTOMFIELD_DATA is used to adjust following field: "VALUE" and  can be used for value defaulting .

By the method BEFORE_UPDATE, we can modify the value entered by user or can implement the “input check” and raise the exception; in
case the user entry does not pass the check.

Secondly, we need to implement the new BADI using enhancement spot ‘GRFN_API_CUSTOMFIELD ‘.

This enhancement spot is called during the ‘Retrieve’ and ‘Update’ of Custom Defined fields for both HR and non-HR entities.

The transaction used is SE19.

Choose enhancement as ‘GRFN_API_CUSTOMFIELD’ and click on button ‘Create Implementation’.

Enter the name and text for ‘Implementation’, we want to create and do not select the option‘Composite Enhancement
Implementation’.

An "Enhancement Implementation" can only contain one type of "Enhancement Implementation Element". Therefore, for a project where
you must implement enhancements to both an Enhancement Point, and a Function Module Interface, you cannot group them in the same Enhancement Implementation. Instead, you must create two separate Enhancement Implementations, and in turn group those in a "Composite Enhancement Implementation". For our example, we require to implement BADI and hence did not select the option ‘Composite Enhancement Implementation’.

Enter the implementation class ‘ZBADI_USER_DEFINED” defined in first step and continue.

Save and activate the ‘Enhancement Implementation’.

Now we could define the IF_GRFN_API_CUSTOMFIELD_BADI~AFTER_RETRIEVE and IF_GRFN_API_CUSTOMFIELD_BADI~BEFORE_UPDATE in implemented class ZBADI_USER_DEFINED to control the CDF on UI.

Let us understood this, with an example .Execute program ‘GRFN_CHECK_CDF’ to know the metadata created.

I want to set field ‘ZTEST_VALUE’ defined for ‘Issue’ as mandatory using my enhancement point.

So I have implemented the methods IF_GRFN_API_CUSTOMFIELD_BADI~AFTER_RETRIEVE and IF_GRFN_API_CUSTOMFIELD_BADI~BEFORE_UPDATE in class ZBADI_USER_DEFINED.

Now I perform ‘Manual Test of effectiveness’ task for a manual control.

And create issue for the control.

Method ‘API_RETRIEVE_CUSTOMFIELD’ of class ‘CL_GRFN_UTIL_CDF’
is used to modify the CDF metadata. It further calls the enhancement point ‘GRFN_API_CUSTOMFIELD’.

If method  IF_GRFN_API_CUSTOMFIELD_BADI~AFTER_RETRIEVE is implemented, it will modify the CDF metadata.

Once the source code highlighted, is executed, the metadata is changed.

CDF is enabled as mandatory with “Enhancement point’ implementation.

Now user submits data without entering mandatory custom defined fields.

A check has been implemented in IF_GRFN_API_CUSTOMFIELD_BADI~BEFORE_UPDATE  of class

‘ZBADI_USER_DEFINED’ to check the input values for CDF. This has been called via ‘API_UPDATE_CUSTOMFIELD’ of class ‘CL_GRFN_UTIL_CDF’.

User is not able to submit data without entering the Custom Defined Field(s).

Purpose of User Defaults:

When a new user is being created in the target system, all users of that system might require few common user defaults like Logon Language, Time Zone, Decimal Notation, Date Format, Parameters etc. Hence when a user is getting created through GRC, based on the request type these user defaults can be assigned to the users.

By including user defaults as part of request type (mostly New Account), user gets created with required user defaults in the target system.

Important SAP notes regarding User Defaults to refer before configuring User Defaults:

1615552 - GRC 10.0 How to set User Default

1665585 - User Defaults BRF+ rule not working correctly

2020712 - UAM: User group not provisioned after request provisioning

Steps to Implement User Defaults:

Step 1: Maintain “User Defaults “action as part of your Request Type. My Request Type 36 is for “New Account” and I have assigned “User Defaults” as shown below.

SPRO =>Governance, Risk and Compliance =>Access Control =>User Provisioning =>Define Request Type

Step 2: Go to SPRO -> IMG -> GRC -> Access Control -> User Provisioning -> Maintain User Defaults

Define User defaults for different connectors connected to your GRC system. One example as shown below:

You can assign default User Group and default Parameters based on the connector by using options “Set the User Group” and “Set Parameter ID” in the above screen as per your requirement.

Once you define the User Defaults as mentioned above and save it, a unique “Default-Id” gets created as shown below. This is the User Default Id which will be used in BRF+ decision table while configuring User Defaults.

Step 3: Existing BRF+ User Defaults application “GRAC_BRFP_USER_DEFAULTS” provided by SAP will be used during configuration of user defaults.

Copy the Function Id of USER_DEFAULT_FUNCTION from BRF+ application.

Now map the BRF+ Application for user defaults under the IMG configuration shown below:

Go to IMG->Governance, Risk and Compliance->Access Control->Maintain AC Applications and BRFPlus Function Mapping

Step 4: Add Decision Table and Loop expression to BRF+ User Defaults function as shown below:

Decision Table: In the decision table maintain entries as shown below

Loop: For using "System" as one of the fields in setting the conditions for User Defaults, SAP suggested for implementing a LOOP in BRF+ Rule. This might be needed since "System" field is not available under Request Header attributes, rather it is available as Role Attributes which are called as line-item fields while calling the BRF Rule. So, in such cases LOOP is a suggested solution, rather than using the Decision Table directly. Though within the LOOP, we can still call the Decision Table or implement IF/ELSE conditions.

Ruleset: When a Function is in event mode, it looks for additional logic execution depending on the Rule-set defined.

Once all above things are done, activate the Decision table, Loop, Ruleset, Function and Application.

Step 5:  Now Create an Access request to test the User defaults and once the User is created please cross check the User Defaults in SU01 to check if everything is fine. If all the above steps are followed properly, User defaults will get updated properly as below in SU01.

Reference Links: http://wiki.scn.sap.com/wiki/display/GRC/Setting+up+User+Defaults