3/Nov/2016 blog updated for re-tagging due to SCN migration
SAP GRC 10.0 introduced the new concept (well not so new now) of MSMP workflow engine as a configurable layer that sits on top of SAP Standard Workflow for Access Controls. This provides flexibility to enable a single request to be split and routed to different approvers in parallel as well as multiple approval steps depending on business requirements.
I must admit, I found the MSMP a little confusing at first. To the logical me, numbers and steps must imply sequence. Lesson learned: they do not. The sequence you follow is entirely dependent on what you are trying to achieve. This document is an attempt to explain the relationships between the steps for rules, agents and notifications.
The diagram below maps the steps 1 through to 6 of the MSMP. Step 7 has been excluded as it is the final step of any MSMP change to generate a new version. It has been drawn using the names of items in MSMP but at a higher level (for example in Notifications Settings does not specify the notification template or notification event). Green has been used to represent Agents used for Approval and Notification; Red for Path mappings; and purple for the use of the rules. BRFPlus has been used to represent the Initiator rule; however, this could easily have been a SE37 Function Module, etc.
Rule to Path Mappings
For the purposes of explaining the MSMP, I am basing this on a simple BRFPlus flat line Initiator Rule with two Request Types: (01) New User and (02) Change User.
BRFPlus
The intention of this initiator rule is to route the entire request to a different path depending on the type of request type. In this example, a decision table has been used to capture three returns results: NEW_REQ; CHANGE_REQ and OTHER_REQ. The additional scenario (OTHER_REQ) has been included as a catch all – if another request type is activated without updating the BRF+/MSMP then the request will still be handled without error on request submission.
[1] Process Global Settings
The Process Global settings step must reference the Initiator Rule for the Process Id (i.e. SAP_GRAC_ACCESS_REQUEST). Each Process Id has one and only one active Initiator Rule. The Initiator rule is the first one called by the workflow engine for the Access Request. Although not shown in the diagram, a global notification rule is also specified. Agent and Routing Rules are not mentioned in this step.
[2] Maintain Rules
The BRFPlus Function Id is defined as a rule in the MSMP. For Initiator and Routing Rules, the Rule Results table must be maintained. This table must map each result from the function (i.e. the BRFPlus decision table) to a Trigger Value which is handled in the route mappings (skip to step 6).
[6] Maintain Route Mappings
The trigger value results specified in the Maintain Rules Step are mapped to a specific path and stage (stage not shown on the diagram). This mapping determines which path is executed. Each trigger value must be specified in this step to identify the path to direct the request to. Different results for the rule can be mapped to the same path/stages.
[5] Maintain Paths
Multiple paths are defined depending on requirements. For example, a different path has been defined for each request type (NEW_PATH, CHANGE_PATH and OTHER_PATH). Within each Path, Stages are defined for each approval level. The Stage can then be configured to determine screen layout (end user personalisation button, etc.), routing of request (via routing rule), escalation and notifications. A Path with No stages will trigger automatic approval.
Agents for Approval and Notifications
For this example, an Agent Rule based on PFCG User role has been defined for Manager. Any user assigned to the security role is considered a Manager.
[3] Maintain Agents
Agent rules are defined for each set of users to approver requests or receive notifications. The role is either Approval or Notifications. Therefore, if the same Agent is required for both then two Agents Rules must be defined. In this example agents have been shown using the colour purple/blue for the Approval Agents and green for the Notification Agent. In this example, agents are defined based on a PFCG Role.
[5] Maintain Paths
For each Stage of a Path, an Approval Agent is specified (except for automatic approval where no agent is mentioned). The Manger Approval Agent will receive the request in their POWL inbox in GRC. An additional Agent can be specified within task settings for escalation (in this example, Senior Manager) if the Approval Agent for the stage does not respond in the specified time.
Multiple notifications can also be defined at each Stage for specific events (such as NEW_WORK_ITEM). The Agent must be of notification type. In this situation, a notification is defined for each combination of Agent, Event and Template. This provides flexibility to send different communications to the agents depending on the stage of the path.
[1] Process Global Settings
Notifications can also be defined on this step for specific event types. Similar to Maintain Paths, the combination of Agent, Event and Template is specified. This notification is sent for REQUEST_SUBMISSION (at the start) or END_OF_REQUEST (once all paths have been completed and the request has finished processing).
[4] Variable & Templates
This step is used to define the notification templates and fields. They template references the SE61 Document where the contents of the email is specified. The Variables are configured in the MSMP and referenced within the SE61 document to personalise the message to the specifics of the request.
Starting out with the MSMP?
SAP delivers default MSMP configuration via the following BC Sets below:
- GRC_MSMP_CONFIGURATION - BC Set for msmp workflow for standard and sample Config
- GRC_MSMP_SAMPLE_CONF - BC Set for MSMP workflow configuration for sample paths
- GRC_MSMP_STD_CONF - BC Set for standard MSMP workflow configuration
As a starting point, I recommend you activate the BC sets so you can see the examples provided. They do not include BRFPlus rules and the Initiator Rule only has one result value. However, this configuration is a good starting point to work out how to use MSMP before you configure your system. Once you have mastered MSMP you challenge is more related to defining your business process for access request approvals which will determine what rules, paths and stages you need to configure.
Time to get Technical?
The following SAP document provides the technical steps to create and maintain a BRF+ initiator rule and the add and maintain it within the MSMP. It does not exactly follow the example here but key difference is the decision table. My document has kept it simple with request type whilst this one include additional request attributes.
BRF plus Flate Rule - GRC Integration - Governance, Risk and Compliance - SCN Wiki
Constructive feedback is welcomed. Please suggest how this document can be improved or topics that may be worth discussing. I am attempting to produce material that explains some of the concepts rather than include each step on how to configure a scenario. By understanding the MSMP, it is then through practise that you can master configuring complex scenarios. I hope this document helps you to understand MSMP a bit better.
- SAP Managed Tags:
40 Comments
