Wednesday 30 October 2013

SAP Access Control 10.1 Q&A with Deloitte's Kurt Hollis in sapinsider

Q1.Besides being HANA enabled, what are the major changes of 10.1 compared to 10.0 ?

Ans: Kurt Hollis

Here is the major changes below.
Also, it is based on NW 7.40, includes support for the new User Interface based on HTML5.

Simplified Access Request - SAP Access Control 10.1 features a new, simplified, and intuitive Access Request form allowing you to define Request Reasons and to use these reasons for request selection. You can click the role name and access critical information such as Tcodes and you can save a draft version of the request. You can also add comments for each role.
New side panels provide additional information such as the details of risk analysis.

Custom User Groups from SU01 Attributes - You can now create custom user groups based on SU01 attributes. You can use these groups when performing risk analysis.

System-Specific Org Rule Analysis - You can now define and activate the Org Rules for specific systems only. Using organizational rules in risk analysis can be time consuming especially in batch risk analysis. In most cases, Org Rules only apply to some of the connected ERP systems. By having system-specific Org Rules, only the relevant rules are used for risk analysis resulting in highly improved run times.

Org Rule Maintenance Wizard - The Org Rule Maintenance Wizard makes creating organizational rules faster and easier and eliminates possible invalid entries due to manual input errors. The wizard allows you to select the desired ERP system, select the Rule Sets, select the Organizational Levels from existing risks, and select Organizational Level values from the ERP system. You can then review and edit the new rule before generating it.

Context-Based Side Panels - This new user interface feature, an alternative to the dialog box, provides more on screen information about the process you are using without requiring you to leave the main screen. For example, while working on the access risk screen, you can use the Violation Historic View side panel to display the number of users associated with this access risk over time and also the number of mitigations over time.

Access Control for SAP HANA - This feature enables SAP Access Control to manage access and risk analysis for SAP HANA based authorizations to support SAP HANA Performance Applications and SAP HANA Business Analytics.

Role Search Personalization - You can now add custom fields to the role search criteria for access requests and configure the field attributes to the following values: Display only, Hidden, or Default.

Context Sensitive Help - You can directly access the help topics for the process you are executing by clicking on the application screen and accessing the Help Center.Enhanced Features

Improvements to Access Risk Analysis and Remediation:
1. Access Risk Root Cause Analysis - The access risk root cause analysis remediation view enables easier identification and remediation of access risks. It offers a set of tools for segmenting risk violations so you know which risks to target first. You can enable remediation workflow processes from the remediation view to ensure that the processing and auditing of remediation activities are followed and tracked.

2. Extended Remediation Capabilities - Remediation capabilities are extended by allowing reviewers to initiate removing roles or editing role validity dates directly from the access risk analysis results. These two new workflow processes are fully configurable and may reuse routing and approval rules from any other GRC workflow process. This functionality is available for both SAP Access Control and the integrated access risk analysis portion of SAP Process Control.

Reporting & Dashboard Authorization - Reports and dashboards are now secured using role-based authorizations. In addition, users’ authorizations can be displayed in a dialog box when desired. An administrator can enable or disable this link for display.


Q2Does GRC 10.1 work in at multiclient environment  at my former employer we used GRC in a single client environment  and it worked fine. But at my current employer they have had some problems with GRC in a multiclient environment  so the are not using it anymore. so does GRC 10.1 work in at multiclient environment  Or what are the challenges with GRC in a multi client environment?

Ans:   Kurt Hollis: 

      Yes, GRC works great in a multi-client environment. FOr the Development system this is very much recommended. I usually setup a golden client, a dev client, and a test client for using for refining rule set or trying new config items

Q3. When AC 10.1 will be available to all SAP customers who currently use AC 10.0?

Ans.Kurt Hollis: 
Rampup for 10.1 is available now and completed 1/31/2014. It will be availble to all customers.

Q4.
What is the reason for the release of 10.1 version of AC when AC10.0 was released in 2011? If new features were added then they could have been added to 10.0 via updates?

Ans:   Kurt Hollis: 

 Main reason is for native HANA support and support for the new HTML 5 and UI5 , these required a new Netweaver release.

Q5. Is it possible to use the same backend plugin for versions 10.0 and 10.1?



Ans:   Kurt Hollis:

Yes.
GRC Plugin 10.0 can be used with GRC 10.1 systems and GRC Plugin 10.1 can be used with GRC 10.0 systems:
Backward Compatibility for Access Control 10.0
The backward compatibility of GRCFND_A V1000 for Access Controls starts with Support Pack 10. Until SP10 both GRCFND_A and plug-in addons GRCPINW & GRCPIERP needs to be one the same level.
However, from SP10 onwards this is not required. Which means that the addon GRCFND_A on GRC system can be upgraded without the need to upgrade the plug-in addon to the same level, provided the plug-in is at a minimum SP level of SP10.
In other words, once the plug-in is on SP10, the GRC add-on GRCFND_A can be upgraded to SP11 or higher without upgrading the plug-in.

Backward Compatibility for Process Control 10.0
The backward compatibility of GRCFND_A V1000 for Process Controls has been introduced from support pack 12. Once the GRC system and GRC plug-ins are on SP12, it will no longer be mandatory to upgrade the plug-in in case the support pack in GRC system is upgraded to higher levels.
Please note the following points before upgrade to the AC 10.1 Plug-Ins.
Recommendation is to upgrade both front-end (GRCFND_A) and back-end plug-in (GRCPINW & GRCPIERP) components to AC 10.1 which also contains the AC 5.3 RTA.
During the time of transition, you can still connect to AC 10.1 Plug-in (GRCPINW & GRCPIERP) from AC 10.0 front-end.
And also, you can connect to AC 10.0 Plug-in (GRCPINW & GRCPIERP) from AC 10.1 front-end as long as support pack of AC 10.0 plug-in is SP10 and above. However, some new AC 10.1 functionalities such as Organization Rule Wizard, Custom User group creation and EAM DB log collection will not work.
(from SAP notes) 

Q6. What differences should we expect when we migrate from GRC 5.3 AC to AC 10.1 ? Can we migrate the data easily ?


Ans:  Kurt Hollis

There is a guide from SAP the Migration guide, you should get this guide on the help.sap.com website in the GRC area.

Yes the data can be migrated easily. Use the Java based migration tool to get the data out.

Some projects instead, just setup the new GRC 10.1 and transfer only the ruleset.

The workflow is thought to be better redone using the new MSMP and BRF delivered workflows and building on them rather then migrate these.

Not all data can transfer from the AC 5.3, some is historic data. The older systems is left running to access some of that data for audit purposes.


Q7. Do you control ITAR and EAR thru GRC 10.1?

Ans:  Kurt Hollis

 More from a regulation standpoint in PC.
You can use PC to comply with ITAR and EAR
also the GTS piece helps with actual compliance of those

Q8.What are the new features in AC10.1?

Ans:  Kurt Hollis

 Simplified Access Request - SAP Access Control 10.1 features a new, simplified, and intuitive Access Request form allowing you to define Request Reasons and to use these reasons for request selection. You can click the role name and access critical information such as Tcodes and you can save a draft version of the request. You can also add comments for each role.
New side panels provide additional information such as the details of risk analysis.

Custom User Groups from SU01 Attributes - You can now create custom user groups based on SU01 attributes. You can use these groups when performing risk analysis.

System-Specific Org Rule Analysis - You can now define and activate the Org Rules for specific systems only. Using organizational rules in risk analysis can be time consuming especially in batch risk analysis. In most cases, Org Rules only apply to some of the connected ERP systems. By having system-specific Org Rules, only the relevant rules are used for risk analysis resulting in highly improved run times.

Org Rule Maintenance Wizard - The Org Rule Maintenance Wizard makes creating organizational rules faster and easier and eliminates possible invalid entries due to manual input errors. The wizard allows you to select the desired ERP system, select the Rule Sets, select the Organizational Levels from existing risks, and select Organizational Level values from the ERP system. You can then review and edit the new rule before generating it.

Context-Based Side Panels - This new user interface feature, an alternative to the dialog box, provides more on screen information about the process you are using without requiring you to leave the main screen. For example, while working on the access risk screen, you can use the Violation Historic View side panel to display the number of users associated with this access risk over time and also the number of mitigations over time.

Access Control for SAP HANA - This feature enables SAP Access Control to manage access and risk analysis for SAP HANA based authorizations to support SAP HANA Performance Applications and SAP HANA Business Analytics.

Role Search Personalization - You can now add custom fields to the role search criteria for access requests and configure the field attributes to the following values: Display only, Hidden, or Default.

Context Sensitive Help - You can directly access the help topics for the process you are executing by clicking on the application screen and accessing the Help Center.Enhanced Features

Improvements to Access Risk Analysis and Remediation:
1. Access Risk Root Cause Analysis - The access risk root cause analysis remediation view enables easier identification and remediation of access risks. It offers a set of tools for segmenting risk violations so you know which risks to target first. You can enable remediation workflow processes from the remediation view to ensure that the processing and auditing of remediation activities are followed and tracked.

2. Extended Remediation Capabilities - Remediation capabilities are extended by allowing reviewers to initiate removing roles or editing role validity dates directly from the access risk analysis results. These two new workflow processes are fully configurable and may reuse routing and approval rules from any other GRC workflow process. This functionality is available for both SAP Access Control and the integrated access risk analysis portion of SAP Process Control.

Reporting & Dashboard Authorization - Reports and dashboards are now secured using role-based authorizations. In addition, users’ authorizations can be displayed in a dialog box when desired. An administrator can enable or disable this link for display.

Q9. How have you seen Access Control 10.1 integrated with BPC 10?

Ans:  Kurt Hollis

You can integrate with BPC 10 since it is a SAP ABAP Netweaver based system using the Plugin GRCPINW and manage security access controls same as other systems.

Q10. Hello Kurt! We are currently running GRC 5.3. We have recently joined ramp-up for 10.1 and are building out an entirely new landscape due to the switch from Java to ABAP. Do you know of a place where I can get more information on setting up the new plug-in connector settings say in an ECC system? I can't find anywhere on what to enter for Plug-In Connector and GRC Connecter parameter values. Just that it must match what is in the GRC system. Also, I've heard that once the new plug-ins are installed that your connections from the 5.3 system will break, however a future support pack may allow you to run both an AC 10.1 system and an AC 5.3 system in parallel until cutover is complete. Have you heard if that's definitely going to be a possibility?

Ans:  Kurt Hollis

The setup of the connectors includes 6 steps and it is all in the SPRO transaction. 3 of the steps are in the integration section and the other 3 steps are in the Access Control section.

1. First, set up RFC Connections to the Plug-In systems, such as the ERP system (the name of the connector will be critical)

2. Second, Each rule set is activated and linked into a separate logical group (technical name in brackets):
GRAC_RA_RULESET_SAP_R3: Rules for ERP including Basis and HR (SAP_R3_LG)
GRAC_RA_RULESET_SAP_HR: Rules for HR only (SAP_HR_LG)
GRAC_RA_RULESET_SAP_NHR: Rules for ERP excluding HR and Basis (SAP_NHR_LG)
GRAC_RA_RULESET_SAP_BASIS: Rules for Basis (SAP_BAS_LG)
GRAC_RA_RULESET_SAP_APO: Rules for APO (SAP_APO_LG)
GRAC_RA_RULESET_SAP_CRM: Rules for CRM (SAP_CRM_LG)
GRAC_RA_RULESET_SAP_ECCS: Rules for ECCS (SAP_ECC_LG)
GRAC_RA_RULESET_SAP_SRM: Rules for SRM (SAP_SRM_LG)
GRAC_RA_RULESET_JDE: Rules for JD Edwards (JDE_LG)
GRAC_RA_RULESET_ORACLE: Rules for Oracle Apps (ORACLE_LG)
GRAC_RA_RULESET_PSOFT: Rules for PeopleSoft HRMS (PSOFT_LG)

3. Next, set up Connector Assignments and Connector Groups
The Connector Group is important for the Rule Set activated (from Step 2)

4. Set up the Connector Assignment for each of the Integration Scenarios
Note: Must perform all scenarios’ setup regardless of using or not

5. Simple Setting to Map the Target Connector to the Application Type

6. Assign the Connector Group the Actions and the Target Connectors
Usually Assign all Actions, set default


The connector instructions are in the SPRO transaction in the text boxes in front of each step. No more config guide from SAP like with AC 5.3 had.

Yes, the VIRSA code is included in the new plugins for 10.1 and it is backwards compatible with GRC AC 5.3, SP18 and higher. THe exact version matching needs to be checking in the SAP notes
1662113 Using Access Control 5.3 with your 10.0 plug in systems
1590030 GRC10 Plug-in & 5.3 VIRSA Plug-in (RTA) Co-Existence 
1352498 Support Pack Numbering – GRC Access Control 

Q11. Today we only unitize RAR & CUP in 5.3. Do you recommend a "technical" upgrade with GRC 10 and then  implement BRM functionally later?

Ans:  Kurt Hollis

Your situation is common. RAR and CUP most popular. Of course the Firefighter is too.

You can implement the new ARA and EAM in 10.0 or 10.1 now and add the role management piece later. It is advised to plan the needed business configuration decisions into the new EAM setup to support the added role management to avoid going back and refitting the EAM to the Role management later.


Q12. I'm not sure if my last question got thru, but can you recommend any ways of validating the migration was successful, like any reports?

Ans:  Kurt Hollis

 During the import of the migrated data, it is validated and logs exist. Once the data is imported, you can view the data either in the application setup screens or view the contents of the tables. You can also download the data and compare them using spreadsheets if not to large of data. This is one area that is ore intensive work. The migration tool adis in both filtering, transformation of data, the validation of the loading of the data. But detailed verification and comparing is much manual work.

Q13. Have you been able to connect Access Control to BPC and implement it successfully at a client? Can you share details?

Ans:  Kurt Hollis

 I personally have not connected to BPC systems, but I see it no different then any other source system. The roles may be unique and the rule set may require more custom work, but that is the case with some systems not included in the delivered rule sets from SAP.

Q14. Have you already migrated a client from AC 10.0 to AC 10.1? How smooth was the migration? Any pitfalls to avoid ?

Ans:  Kurt Hollis

  The upgrade from GRC 10.0 to 10.1 involves mostly the Netweaver upgrade from 7.02 or 7.31 to 7.40 version. One struggle I had was generating the correct stack.xml file for the upgrade in solution manager. I had to update my solution manager content first. Then it was OK. No big issue really. Very smooth. I did not migrate it to HANA DB but that can be done using the system copy migration process.

Q15. Any new feature in 10.1 with respect to HR Triggers. also now can we have multiple rule for single HR trigger in BRF+ decision table?

Ans:  Kurt Hollis

 yes, based on a single trigger received on something like a new user creation, you can define multiple conditions on what access needs to be assigned to them based on business requirement.

Q16 .Kurt, any insight into the most pressing business case for moving to HANA-enabled Access Control? What does HANA bring to AC that changes its performance?

Ans:  Kurt Hollis

The main reason for HANA platform is to support custom reporting and queries not available in the standard delivered packages. Some of which are below. The BW custom reporting was available in the past, and this is a natural progress.

The (building blocks) prerequisites for creating ad hoc reports for analyzing the access risks, access risk violations, incidents of SoD risk and mitigating control risk violations, org rules, mitigating controls, actions, functions, critical actions/roles/profiles, action usage, incidents, Segregation of Duties (SoD) and user access risk. Analysis areas include risks library, rules library, users, roles

Based on this virtual data model, you can generate reports to answer the following business questions.

What are the access risk violations over the past six months?

What are the risk violations for a specific role?

What mitigating activities have been performed over the past three months?

What unmitigated risks exist in the system?

What is the history for SoD reviews?

What is the history for user access reviews?

For access requests:
How many access requests were created for the last three months?

What types of access requests were created: User Access, reviews of Segregation of Duties, Emergency Access?

What was the length of time for the access requests to be completed for the last five months?

What access requests are still pending? How long have they been open?

How many users and roles were provisioned for the last four months?

What are the most frequently requested roles?

What are the service level agreements for the requests?


Q17. Is there any reason with the new GRC 10.0 or 10.1 applications to have a plug-in installed on the same system as the GRC Access Control 10.1 application if it is a standalone ABAP system?

Ans:  Kurt Hollis

It is not required to have this plugin on the new GRC 10.1 system. Only needed if you wish to use the Access control features on the GRC  system itself, just like any other connected system.

Q18. When will GRC AC 10.1 certification available?

Ans:  Kurt Hollis

GRC 10.0 certification is available now and it usually takes 6-12 months until next one. I would go for the GRC 10.0 certification.

Q19.What are the new reporting capabilities in GRC AC 10.1 and What is the process to migrate GRC AC 10.1 From all Previous versions?

Ans:  Kurt Hollis

  The reporting capabilities in GRC AC 10.1 are similar to 10.0 and expanded once integrated with SAP HANA. See the post about the GRC HANA reporting prior.

The upgrade from GRC 5.3 is a Java to ABAP migration and involves extra steps to migrate the Java based data into a new build of GRC 10.1 on ABAP.

The upgrade from GRC 10.0 to GRC 10.1 is more straight forward ABAP NW 7.02 or 7.31 to NW 7.40 ABAP based systems upgrade, basically on version upgrade. The data and application will not be changed much and then you can take advantage of the new release features of 10.1. See the prior post on the new release fatures of 10.1


Q20.Is it comparable in terms of workload to set up user request workflows compliant user provisioning tool (CUP 5.3) or Manage and Provision users (10.X), for a workflow of similar complexity? How different is the set up from one GRC version to the other? Are there predefined templates available in 10.X?

Ans:  Kurt Hollis

  The workflows are pre delivered and can be almost ready to use out of the box just like in AC 5.3. There are steps to make assignments and configure them before using. They are delivered in the BCSET. You can setup using the SPRO and IMG. The setup is more of a learning curve and a bit more complex but a lot more powerful.

Q21.Do you suggest any kind of validation reporting to use when validating the migration was successful?

Ans:  Kurt Hollis

 During the import of the migrated data, it is validated and logs exist. Once the data is imported, you can view the data either in the application setup screens or view the contents of the tables. You can also download the data and compare them using spreadsheets if not to large of data. This is one area that is ore intensive work. The migration tool adis in both filtering, transformation of data, the validation of the loading of the data. But detailed verification and comparing is much manual work.
Not as automated as we would prefer, but still a good process to work with during migration. The best practice is to make sure the export is clean as possible before the import, this saves cleanup later in the new system.

Thanks to Mr.Kurt Hollis....



Kurt Hollis: 

If you go to the GRC conference in 2014, there is a new GRC Hands on lab where each person gets their own GRC system to configure and get the applications up and running for the first time. This is a great way to quickly learn how to setup GRC 10.1 easily from experienced people. I am the speaker and instructor for this lab exercise.

The lab is based on GRC Access Control 10.1.

















  

  




































Release Information Note for SAP Access Control 10.1

Note:   1870233 
Symptom
Release information for SAP Access Control 10.1

Other Terms
AC, AC 10.1, GRC AC, Access Control

Reason and Prerequisites
SAP Access Control 10.1 is based on SAP NetWeaver 7.40 SP02. SAP Access Control 10.1 runs on NetWeaver 740 SP02 (on non-HANA or HANA databases.) SAP NetWeaver 740 SP02 is a prerequisite for the implementation of the functionalities of SAP Access Control 10.1.

Solution
SAP Access Control is an enterprise software application that enables organizations to manage segregation of duties (SoD), critical and sensitive access, and superuser access effectively and efficiently.
Access Control automates the process of detecting, remediating, and ultimately preventing access risk violations. Access Control software can give you real-time visibility into your current risk position and allow you to confidently manage and reduce unauthorized access, fraud, and the cost of compliance across your enterprise.

  • Access Control for HANA (Information Governance with SAP Access Control)
  •  Access Control on HANA, the following processes were optimized for HANA:
  • Access Risk Analysis (optimization)
  • oEmergency Access Management - Consolidated Log (optimization)

For further information about GRC and Access Control refer to our home page at http://www.sap.com/grc.

Read the installation or upgrade information for SAP Access Control 10.1 first. Use the SAP Access Control 10.1 Master Guide as the starting point for planning an SAP Access Control 10.1 landscape.

For installation and upgrade of SAP Access Control 10.1, refer to the installation and upgrade guides at SAP Help Portal http://help.sap.com/grc-ac   > Installation and Upgrade Information. For specific issues regarding installation or upgrade of SAP Access Control 10.1, see the latest SAP Notes listed in the Access Control 10.1 Master Guide at SAP Help Portal http://help.sap.com/grc-ac  >Installation and Upgrade Information.

To access the current online documentation, see SAP Help Portal at http://help.sap.com/grc-ac  >Application Help. The Release Notes for SAP Access Control 10.1, which describe new functions and changes, are also available at the SAP Help Portal http://help.sap.com/grc-ac  > What's New - Release Notes or at SAP Service Marketplace at http://service.sap.com/releasenotes >Analytics>Governance, Risk, Compliance > SAP Access Control.

To download Access Control v10.1 software for installation, go to the SAP Software Distribution Center on SAP Service Marketplace at http://service.sap.com/swdc  > Installation and Upgrades -> A to Z Index -> "g" ' SAP GRC Access Control-> SAP Access Control 10.1.

SAP Service Marketplace contains SAP Notes providing detailed solutions for known problems and or additional information. Refer to the Installation Guide for SAP Access Control, Process Control, and Risk Management 10.1 for relevant SAP Note numbers.

You can search for and read SAP Notes at http://service.sap.com/notes using the GRC-AC component:
You can also access SAP Notes using the SAP Notes Search function under Additional Information found on the SAP Help Portal http://help.sap.com/grc-ac .

For additional information about SAP Access Control, see SAP Help Portal at http://help.sap.com/grc-ac or SAP Service Marketplace at http://service.sap.com/instguides.

GooD Link For GRC 5.3,10.0,10.1 Information

GRC AC10.0/10.1: Create Rule Based on Risk Violation in Request, Using BRF+ Procedure Calls


AC10.0/10.1: Create Rule Based on Risk Violation in Request, Using BRF+ Procedure Calls


In Access Request, sometimes you would want to route your request based on the risk violations present in the request. There are some standard function module based detour/initiator rules which are available in MSMP like 'GRAC_INITIATOR_SOD_VIOLATIONS' and 'GRAC_MSMP_DETOUR_SODVIOL' where you can route your request based on risk violations. But these standard rules are inflexible, so if you want to add another condition for routing along with risk violation then you will have to change the abap logic within these function modules.
So using these standard rules you can route request based on risk violation only. If you want to create an initiator rule based on risk violation and 'Sensitivity' of role or if you want to create a routing rule based on the 'Risk Level' of violations then it is not possible using standard rules unless you change ABAP logic.
In this document we will see how we can utilize power of BRF+ by creating a very flexible initiator/routing rule where we can check combination of multiple conditions and not just Risk Violations. We will be taking example of following business scenario :  
Business Scenario :
If an access request contains risk violations with Risk Level as 'High', then the request should be routed to a special path, and if no violations with Risk Level  'High' are found, then continue with normal path
We will use BRF+ procedure call to get risk violations in the request. In BRF+ Procedure call, we will use one of the standard function module to get risk violation details of a request.
Untitled.png
Follow steps below to create a BRF+ flat rule to achieve above scenario
1.) Generate BRF+ Shell for Access Request Initiator from transaction 'GRFNMW_DEV_RULES'
  • Fill generation criteria (Process ID, Rule type, etc.)
  • Specify Generation options and select any field from Header or Item to ensure decision table is generated automatically
  • Generate rule shell (Execute button)
Untitled.png


2.) Activate Empty BRF+ Rule using transaction BRF+
  • To locate the generated function, use menu, 'Workbench -> Open Object' and specify object ID from previous step
  • Activate the function
  • Change the mode to “Event Mode”
Untitled.png
3.) Change Result Data Object of BRF Function
  • 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_S_ROUTING
Untitled.png
Untitled.png
4.) Function Module to Get Risk Violation Details
  • We will be calling function module  “GRAC_IDM_RISK_WITH_NO_SERVICES” in BRF+ rule to get violations details 
  • It returns a table with violations; so first, we will create a table in BRF rule which will hold the result of the function call
Untitled.png
5.) Create Data Object
  • From context menu of BRF+ application, create a Data Object of type “Table”
  • This data object will hold the risk analysis result

Untitled.png


Untitled.png
  • Select DDIC Binding and provide name of DIDC Table Type of “GRAC_T_WS_RA_OP_RISK_ANLYS_ID”
  • Activate the Data Object
Untitled.png


6.) Create Procedure Call to Get Risk Analysis Result
  • Create a procedure call from context menu of BRF application
Untitled.png
Untitled.png

  • Within procedure call, select Call Type of “Function Module” and provide Function module name as “GRAC_IDM_RISK_WITH_NO_SERVICES.” Press “Enter” key after providing function module name.
  • Add parameters to the procedure call
Untitled.png

  • Select the Data Object created in step 5 as “Result Data Object” for this procedure call
Untitled.png
Untitled.png

Map Parameters to Context Fields
  • Click on Mapped parameters to expand the details
  • Assign value to these parameters using BRF+ context parameters
  • Activate procedure call

Untitled.png
Untitled.png


7.) Create Expression — Table Operation : Check Risk Analysis Result Table for Risks
  • Create an expression of type “Table Operation”
  • This expression will read the result table of procedure call to check if any violations exist
Untitled.png


Untitled.png

  • This expression will read the result table of procedure call “RISK_ANALYSIS_RESULT” to check if any violations exist
  • Additionally, here we are checking for any risk with “High” risk level
  • Activate “Table Operation” expression

Untitled.png


8.) Add Condition Column to Decision Table

  • Go to Decision Table that was generated automatically
  • From decision table settings, add a column from expression and use expression “READ_RISK_VIOLATION,” which is a table operation
Untitled.png

Untitled.png


9.) Add Business Logic to Decision Table
  • Add conditions to the decision table
  • Based on the result of “Table Operation,” which checks whether any “High” risk violations exist in request or not, the path of request is decided

Untitled.png


10.) Create Ruleset

  • Go to BRF+ function and create a new ruleset
Untitled.png
  • Add variable “RISK_ANALYSIS_RESULT,” which was created in previous steps, to the ruleset
Untitled.png
Untitled.png
Untitled.png


11.) Add Rule to Ruleset

  • Create new rule within ruleset
  • Within this new rule, call the procedure that was created in previous steps
Untitled.png
Untitled.png

Untitled.png

12.) Add Second Rule to Ruleset

  • Within same ruleset, create second rule that will call the “Table Operation” expression “READ_RISK_VIOLATION”
  • This table operation will read the violations, which are returned by procedure call

Untitled.png
Untitled.png


13.) Add Third Rule to Ruleset

  • Within same ruleset, create third rule that will call the “Decision Table” expression
  • Decision table operation will internally call table operation to check if any violation was returned by procedure call and, based on the result, it can decide the path of request

Untitled.png
14.) Check sequence of rules within ruleset
  • Check the sequence of rules within ruleset
  • First rule in the sequence should be procedure call, second should be table operation, and last should be decision table
  • Activate all objects
Untitled.png

Now you can configure this rule in msmp configuration and use it as routing or initiator rule